1. Introduction

2. Related Work

3. A Decentralized Marketplace for Distributed Computing

4. Signatures & Digital IDs

5. Protocol Design for Distributed Computing and AI Directories

5.1. Distributed Computing on the NOSTR Protocol

Herein, we discuss the existing dedicated protocol messages and protocol flow for distributed computing. We mainly focus on five components that we will utilize later with slight extensions or variations, these include job request events, job result events, job feedback events, events for service provider discoverability and job chaining rules. These type of events consist the core of the communication messages between customer and service providers. We refer the reader to the NOSTR Implementation Possibility - 90 (NIP-90 [24]) for further details.

Basic Protocol Flow for Data Vending Machines (DMVs) [24]

• Customer publishes a job request (e.g. kind:5000, speech-to-text).
• Service Providers may submit job-feedback events (kind:7000, e.g. payment-required, processing, error, etc.).
• Upon completion, the service provider publishes the result of the job with a job-result event (kind:6000).
• At any point, if there is an amount pending to be paid as instructed by the service provider, the user can pay the included bolt11 invoice [25] of the job result event that the service provider has sent to the user.

The above protocol is designed to be deliberately ambiguous. For instance a customer may choose a set of service providers and restrict or not restrict the job request to be completed by this specific set of service providers. Also, a service provider may not start a job until they receive a form of payment, or their response can depend on the other participants reputation based on their public key. The flexibility of the protocol flow allows us to extend parts of it, and implement additional communication steps for the design of on demand LLMs training over a decentralized marketplace. Next we proceed by presenting the existing events as appear in the protocol flow for DMVs.

Job Request (DVMs)

A Job Request for Data Vending Mchines is an event, published by a customer through a set of relays. This event signals that a customer is interested in receiving the result of some kind of computation by an AI tool. The reserved range for job request events is $\#5000-\#5999$. The field with label "content" is empty, while, all the required information should be provided in the field with label "tags". The field "tags" contains all the required information from an AI-agent in order to process the data.

• {
•   "kind": 5xxx // kind in range 5000 - 5999,
•   "content": "",
•   "tags": [
•      ["i", " <data> ", "<input-type>, "<relay>", "<marker>"],
•      ["output", "<mime-type>"],
•      ["relays", "wss://..."],
•      ["bid", "<msat-amount>"],
•      ["t", "bitcoin"]
•   ]
• }

     Event Type 1: Job Request Event with kind in range 5000 -5999

For completeness, we provide additional explanation regarding each tag of the events. We first present the existing events structure. Then we introduce any necessary changes or additions that we will consider in the protocol flow and in the algorithm. For the Job Request event (Event Type 1) there are the following tags: <i>: All the required input data for the job appear here. Specifically, the inputs of the AI algorithm. <data>: The argument for the input. <input-type>: The type of the argument input, it must be one of the following: url: A URL to be fetched of the data that should be processed. event: A Nostr event ID. job: The output of a previous job with the specified event ID. The determination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.) text: <data> is the value of the input, no resolution is needed <relay>: The relay where the event/job was published <marker>: An optional field indicating how this input should be used within the context of the job <output>: Expected output format. <param>: Optional parameters for the job. Different job request kind defines this more precisely. (e.g. [ "task", "run option", "initial state" ]). <bid>: Customer MAY specify a maximum amount (in millisats) they are willing to pay <relays>: List of relays where Service Providers SHOULD publish responses to. p: Service providers the customer is interested in. Other service providers might still choose to process the job.

Job Request (AI VMs)

The existing job request events include a large number of different jobs, dedicated to data processing applications. Such job request have a certain structure (see Event Type 1). For clarity and for efficacy of our approach, we propose to introduce the kinds 8000 - 8999 as Job Request events for federated learning, LLM training and distributed optimization. Although, each kind can correspond at a different algorithm or variation of an algorithm, specific details can be considered by introducing additional fields in the tags. As an example, notice that the predefined structure of Event Type 1, requires a single input data type as we discussed earlier, while additional information may be included in parameters field (<param>).

     Event Type 2: Job Request Event for training AI models, kind in range 8000 -8999

Similarly, for the purpose of training an LLM, the customer needs to provide a training data-set though a URL as input data, and additionally a set of parameters related to the training task, for instance initial model parameters, a URL to the source code of the training or optimization method, model specification (example "LLaMA-2"), rules for validation of the output. To maintain the existing protocol flow as much as possible, we consider the input data as a URL to the training dataset for the initial job request, or the output of a previous job with a specified event job id to declare a job chaining and multiple rounds of training. In both cases (initial or chain job request), we consider all the required information for executing algorithm in the parameters fields for consistency. Below some pieces of that information follow (Event Type 2):

• a source for the code: While the service provider may have its own code, there should be reference to a standard approach that guarantees consistency
• a source for the data: The customer splits and sends an encrypted URL to the service providers. The customer decides how to split the data. The way of splitting the data may be arbitrary.
• job details: expected execution type or hardware that is needed, rules related to time-out conditions.
• Declaration of validation process. This is how the customer will decide if the output is accurate or not.

Through the optimization process we introduce a new job request at each round. We also consider job chaining to speed up the process and most likely to execute the training by assigning the jobs to the same service providers, as long as they provide valid outputs. A running job will be assigned to new service provider, if a previous service provider goes offline, or fails to provide valid result. Finally, the customer has the option to encrypt all the parameters, and only the selected service provider(s) in the tag "p" will be able to decrypt them. We proceed by briefly discussing the Job Chaining rules, for a detailed description we refer the reader to [24, (NIP-90)].

Job Chaining

A Customer has the option to request multiple rounds of jobs to be processed as a chain, where the output of a job is the input of another job. In the context of data processing and DMVs this can be a sequence of processing as a podcast transcription by one service provider and then extracting a summary of the transcription by another. One way to implement this is by specifying as input an event id of a different job with the job type. In general, service providers may begin processing a subsequent job the moment they see the prior job result, but they will likely wait to receive a (partial) payment first.

In the case of federated learning and LLM training such options still exist, however we propose certain protocol rules to minimize the risk introduced by bad actors and malicious users. To do this, we consider necessary for the customer to validate the progress made by each service provider at every single round. After the validation is completed, each service provider who produced successful results receives a partial payment for the work done in the corresponding round. Then the customer updates the current state of model and submits a follow-up job request for the next round (and optionally a partial payment to the service providers upfront). Upon completion of the optimization task at each round, the service providers communicate with the customer through a Job Result event.

Job Result (kind: 6000-6999)

Service providers communicate with the customer through Job Result events, by providing the (optionally) encrypted output of the job. In the case of AI training, the output corresponds to an optimized version of the model parameters. The format of the Job Result event appears in the Event Type 3 above. The tag of the Job Result event include the original job request event id (stringified-JSON), the public key of the customer, amount that the Service Provider is requesting to be paid or an lightning invoice (bolt11 [25,26]), and the optimized model parameter as an encrypted output. Finally, a tag "i" may be considered for additional information related to the initial job request or for validation of the output by the customer.

     Event Type 3: Job Result Event

Job Feedback (kind:7000)

During the model training process, service providers can communicate and provide feedback for an ongoing job through the Job Feedback event. The Job Feedback events may be considered in order to avoid time-outs and ensure that a service provider has achieved some partial progress. Information about partial progress can be optionally included by introducing additional fields in the tags of the event format in the Event Type 4.

• {
•   "kind": 7000,
•   "content": "<empty-or-payload>",
•   "tags": [
•      ["status", " <status> ", "<extra-info>"],
•      ["amount", "<requested-payment-amount>", "<bolt11>"],
•      ["e", "job-request-id", "<relay-hint>"],
•      ["p", "<customer’s-pubkey>"],
•   ],
•   ...
• }

     Event Type 4: Job Feedback Event

The predefined format of the Job Feedback event includes the following tags [24]: <content>: It may be empty, a final job-result or a partial-result (for a job in progress). This field will have an encrypted payload with p tag as key. <amount>: Requested payment amount. <status>: The service provider publishes the current status of the requested job. For instance: payment-required: Service Provider requires payment before continuing. processing: Service Provider is processing the job. error: Service Provider was unable to process the job. success: Service Provider successfully processed the job. partial: Service Provider partially processed the job. The content filed might include a sample of the partial results.

Discoverability

Service Providers have the option to announce availability or to advertise their support for specific job kinds by publishing discoverability events [27, (NIP-89)]. The format structure of the discoverability event appears in the Event Type 6. By including a field tag "i", service providers may provide additional information related to their available computational capabilities, hardware specification or execution time limits.

     Event Type 5: Discoverability Event

A possible extension follows:

     Event Type 6: Discoverability Event

6. Payments

7. Money-In AI-Out: Marketplace for Federated Learning and LLMs

7.1. Customer

A complete implementation of the customer routine appears in Algorithm 1. This includes the steps that the customer follows and the events that the customer publishes. First, the customer discovers and requests a set of service providers to run inner optimization part of the job to as we explained in the protocol flow above. Upon successful delivery of outputs, the customer proceeds to the outer optimization. The outer optimization for both FedAvg and DiLoCo is a single or double update of local variables respectively. However we consider the option for the customer to also assign this computation step to a service provider. This can be useful in practice if someone prefers to implement an outer optimizer with higher computational complexity (for instance multiple iterations) and the customer is not able to perform such computations locally. We proceed by explaining further three parts of the main customer routine: how the customer handles disconnections and failures of a service provider to respond (Algorithm 1), how the customer validates the output results given by a service provider at job completion (Algorithm 3), and how the customer reassigns a job to a different service provider if needed (Algorithm 2).

Handling Disconnections and Failures to Respond.

The customer may consider a time-out period. If a service provider did not provide the output within a certain time window (from the time point of receiving the initialization payment), then the customer proceeds to reassign the job to a different service provider (Algorithm 2). As an example of the time-out implementation see Algorithm 1 (lines 13-14). All the information regarding the time-out rules should be included in the Job Request event (Event Type 2).

The definition of failure to respond may vary from one implementation to another. As an example, the customer may choose to receive a valid output within a certain time period. Alternatively the time-out decision may depend on the periodic responses by the service provider through Job Feedback events (Event Type 4), that notify the customer about the status of the job and provide partial results of the computation.

Validation of the Output (Algorithm 3).

Upon receiving a Job Result event (Event Type 3) the customer proceeds to verify the accuracy of the output. In the context of training AI models with FEDAVG and DiLoCl, we consider two conditions that test the decay of the loss on a validation dataset. Specifically, Algorithm 3 requires as input the validation dataset, the current state of the model (model parameters), and a threshold for the two following policies. As a first option, we compare the loss decay progress relative to other service providers (see accuracy against service providers, Algorithm 3). This validation test has been introduced in [35, Accuracy Checking]. As a second option, we consider a test that checks if a moving average of loss decays with a certain rate (Algorithm 3). Alternative accuracy tests and approaches to identify malicious service providers appear in prior works [35,36,37,38]. Such implementations may be considered in parallel with our design but remain out of the scope of this work.

Reassigning the Job to a Different Service Provider (Algorithm 2).

Under a time-out or a failed validation instance, the customer reassigns the job to a different service provider. We provide an example of such implementation in Algorithm 2. Further, under perpetual time-outs and invalid output detection, the customer continues to reassign the job, until a service provider delivers a valid output. Then the routine returns the public key of new service provider and the customer updates the list of the service providers under consideration.

7.2. Service provider

Algorithm 4 is an implementation of the routine for the service providers. For announcement and advertisement of their service, the providers publish a discoverability event of kind 31990 (Event Type 6). Initially, the service providers wait until they receive a job request. Then they signal initiation through a job feedback event. Upon receiving any required payments they proceed with the optimization routine, as the customer has requested. The optimization procedure may be one of the run options (FEDAVG or DiLoCo) and the task for either run option may be Inner or Outer optimization. Depending on the run option the service providers calls the corresponding algorithmic routine (Algorithm 5 or Algorithm 6). Periodically the service provider announces the status of the job through a Job Feedback event and provides a progress of the computation, for instance see Algorithm 5. After the completion of the optimization routine the service providers respond with a job result event, and they expect any pending payment to be settled. If the customer does not complete payment(s) after a reasonable time period despite the delivery of accurate outputs, then the service providers may stop receiving job request from the specific customer immediately.

Federated Averaging vs Distributed Low-Communication Training of LLMs (DiLoCo)

The federated averaging algorithm [34] (FEDAVG) is a distributed and communication efficient learning method of AI models from decentralized data. This decentralized computation is known as federated learning; a set of different devices learn a shared model by aggregating locally-computed updates. In our design we consider as one optimization approach the FEDAVG. The customer provides a common model specification and the data to the servicce providers. The service providers have the role of different devices, they obtain a subset of the data-set and they train the shared model. Upon completion of the computation they return the optimized model parameters, and they receive a payment.

Although the FEDAVG is a successful approach for training neural netowrks and AI in a decentralized fashion, we also consider a variant of FEDAVG that has numerous advantages over the classical approach. Specifically, the DiLoCo algorithm [8] enables training of LLMs under constrained communication. In fact, the inner part of optimization (jobs by Service providers) requires the greatest amount of computation, while the request for a new job is being decreased significantly. This provides additional flexibility to our design since it minimizes the number of job requests by the customer. Nevertheless, the service providers have the option to frequently provide information (e.g. job status, partial output) to the customer through the Job Feedback events. We proceed by presenting the implementation of the Inner Optimization and Outer Optimization routines for both FEDAVG and DiLoCo algorithms.

Inner Optimization (Algorithm 5)

The Inner Optimization routine provides the implementation of the inner part of the computation. A service provider runs the inner part of FEDAVG (example SGD) or DiLoCo (AdamW [39]). The run option is provided by the customer through the job request event. The algorithm returns the updated model parameter.

Outer Optimization (Algorithm 6)

For the Outer Optimization routine, the customer has the option to run the outer optimization, or assign it to a service provider. Then the customer (or a service provider) runs the outer part of FEDAVG (example aggregation step) or DiLoCo [8,40]. The run option is determined by the customer. The algorithm returns the updated model parameter.

8. Conclusion

9. Funding

10. Notes

References

1. domain., P. NOSTR - Notes and Other Stuff Transmitted by Relays. https://github.com/nostr-protocol/nostr, 2023.
2. Briugeman, A. Nostr Real Time Statistics. https://stats.nostr.band, 2023.
3. domain., P. Bluesky Architecture. https://docs.bsky.app/docs/advanced-guides/federation-architecture, 2023.
4. Kleppmann, M.; Frazee, P.; Gold, J.; Graber, J.; Holmgren, D.; Ivy, D.; Johnson, J.; Newbold, B.; Volpert, J. Bluesky and the AT Protocol: Usable Decentralized Social Media. arXiv preprint arXiv:2402.03239, arXiv:2402.03239 2024.
5. Gilbert, S.; Lynch, N. Perspectives on the CAP Theorem. Computer 2012, 45, 30–36. [Google Scholar] [CrossRef]
6. Wei, Y.; Tyson, G. Exploring the Nostr Ecosystem: A Study of Decentralization and Resilience. arXiv preprint arXiv:2402.05709, arXiv:2402.05709 2024.
7. Poon, J.; Dryja, T. The bitcoin lightning network: Scalable off-chain instant payments. https://lightning.network/, 2016. [Google Scholar]
8. Douillard, A.; Feng, Q.; Rusu, A.A.; Chhaparia, R.; Donchev, Y.; Kuncoro, A.; Ranzato, M.; Szlam, A.; Shen, J. DiLoCo: Distributed Low-Communication Training of Language Models. arXiv preprint arXiv:2311.08105, arXiv:2311.08105 2023.
9. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized business review 2008. [Google Scholar]
10. Dembo, A.; Kannan, S.; Tas, E.N.; Tse, D.; Viswanath, P.; Wang, X.; Zeitouni, O. Everything is a race and Nakamoto always wins. Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, 2020, pp. 859–878.
11. Liu, Y.; Kishore, K.N. Sovereign Individual System (SIS): An Autonomous Digital Platform for Sovereign Individuals. Proceedings of the Future Technologies Conference. Springer, 2023, pp. 142–153.
12. domain., P. NIP-19: NOSTR - Notes and Other Stuff Transmitted by Relays. https://github.com/nostr-protocol/nips/blob/master/19.md, 2023.
13. Pieter Wuille, Jonas Nick, T.R. Schnorr Signatures for secp256k1. https://bips.xyz/340, 2019.
14. Deelman, E. Mapping Abstract Complex Workflows onto Grid Environments. Journal of Grid Computing 2003, 1, 25–39. [Google Scholar] [CrossRef]
15. Taylor, I.; Shields, M.; Wang, D. Resource Management of Triana P2P Services. Grid Resource Management 2003. [Google Scholar]
16. Anderson, D.; Korpela, E.; Walton, R. High-performance task distribution for volunteer computing. First International Conference on e-Science and Grid Computing (e-Science’05), 2005, pp. 8 pp.–203. [CrossRef]
17. Anderson, D.P. BOINC: A Platform for Volunteer Computing. Journal of Grid Computing 2019, 18, 99–122. [Google Scholar] [CrossRef]
18. The Gridcoin Network and Protocol Overview 2018.
19. Yakovenko, A. Solana: A new architecture for a high performance blockchain v0. 8.13. Whitepaper 2018. [Google Scholar]
20. Apps, N. Nostr Apps. https://www.nostrapps.com/, 2023.
21. domain., P. Data Vending Machines. https://github.com/nostr-protocol/data-vending-machines, 2023.
22. domain., P. VenData. https://vendata.io, 2023.
23. Maxwell, G.; Poelstra, A.; Seurin, Y.; Wuille, P. Simple schnorr multi-signatures with applications to bitcoin. Designs, Codes and Cryptography 2019, 87, 2139–2164. [Google Scholar] [CrossRef]
24. domain., P. NIP-90: NOSTR - Notes and Other Stuff Transmitted by Relays. https://github.com/nostr-protocol/nips/blob/master/90.md, 2023.
25. Antonopoulos, A.M.; Osuntokun, O.; Pickhardt, R. Mastering the lightning network; " O’Reilly Media, Inc.", 2021.
26. Andreas, M. Antonopoulos, Olaoluwa Osuntokun, R.P. Lightning Payment Requests. https://github.com/lnbook/lnbook/blob/develop/15_payment_requests.asciidoc, 2023.
27. domain., P. NOSTR Implementation Possibillities, 89. https://github.com/nostr-protocol/nips/blob/master/89.md, 2023.
28. O’Hare, J.J.; Fairchild, A.; Ali, U. Money &amp; Trust in Digital Society: Bitcoin, Nostr, Stablecoins, Digital Objects and Generative AI in B2B Spatial Mixed Reality. arXiv preprint arXiv:2207.09460 2022. [Google Scholar]
29. Robert, J.; Kubler, S.; Ghatpande, S. Enhanced Lightning Network (off-chain)-based micropayment in IoT ecosystems. Future Generation Computer Systems 2020, 112, 283–296. [Google Scholar] [CrossRef]
30. domain., P. NOSTR Implementation Possibillities, 57. https://github.com/nostr-protocol/nips/blob/master/57.md, 2023.
31. Zap, N. JeffG. https://nostr.how/en/zaps, 2023.
32. domain., P. LNURL. https://github.com/GaloyMoney/lnurl-pay, 2023.
33. domain., P. NIP-01: NOSTR - Notes and Other Stuff Transmitted by Relays. https://github.com/nostr-protocol/nips/blob/master/01.md, 2023.
34. McMahan, B.; Moore, E.; Ramage, D.; Hampson, S.; y Arcas, B.A. Communication-efficient learning of deep networks from decentralized data. Artificial intelligence and statistics. PMLR, 2017, pp. 1273–1282.
35. Bhagoji, A.N.; Chakraborty, S.; Mittal, P.; Calo, S. Analyzing Federated Learning through an Adversarial Lens. Proceedings of the 36th International Conference on Machine Learning; Chaudhuri, K.; Salakhutdinov, R., Eds. PMLR, 2019, Vol. 97, Proceedings of Machine Learning Research, pp. 634–643.
36. Demartis, M. Adversarial Attacks in Federated Learning, 2022.
37. Rathee, M.; Shen, C.; Wagh, S.; Popa, R.A. Elsa: Secure aggregation for federated learning with malicious actors. 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 1961–1979.
38. Awan, S.; Luo, B.; Li, F. Contra: Defending against poisoning attacks in federated learning. Computer Security–ESORICS 2021: 26th European Symposium on Research in Computer Security, Darmstadt, Germany, October 4–8, 2021, Proceedings, Part I 26. Springer, 2021, pp. 455–475.
39. Loshchilov, I.; Hutter, F. Decoupled weight decay regularization. arXiv preprint arXiv:1711.05101 2017, arXiv:1711.05101.
40. Huo, Z.; Yang, Q.; Gu, B.; Huang, L.C. ; others. Faster on-device training using new federated momentum algorithm. arXiv preprint arXiv:2002.02090, arXiv:2002.02090 2020.
41. Linus, R. BitVM: Compute Anything on Bitcoin. bitvm.org 2023. [Google Scholar]
42. Rasley, J.; Rajbhandari, S.; Ruwase, O.; He, Y. Deepspeed: System optimizations enable training deep learning models with over 100 billion parameters. Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, 2020, pp. 3505–3506.
43. Rajbhandari, S.; Rasley, J.; Ruwase, O.; He, Y. Zero: Memory optimizations toward training trillion parameter models. SC20: International Conference for High Performance Computing, Networking, Storage and Analysis. IEEE, 2020, pp. 1–16.
44. Fan, T.; Kang, Y.; Ma, G.; Chen, W.; Wei, W.; Fan, L.; Yang, Q. Fate-LLM: A industrial grade federated learning framework for large language models. arXiv preprint arXiv:2310.10049, arXiv:2310.10049 2023.
45. Lu, L.; Dai, C.; Tao, W.; Yuan, B.; Sun, Y.; Zhou, P. Exploring the Robustness of Decentralized Training for Large Language Models. arXiv preprint arXiv:2312.00843, arXiv:2312.00843 2023.
46. Tang, Z.; Wang, Y.; He, X.; Zhang, L.; Pan, X.; Wang, Q.; Zeng, R.; Zhao, K.; Shi, S.; He, B. ; others. FusionAI: Decentralized Training and Deploying LLMs with Massive Consumer-Level GPUs. arXiv preprint arXiv:2309.01172, arXiv:2309.01172 2023.
47. Agrawal, A.; Panwar, A.; Mohan, J.; Kwatra, N.; Gulavani, B.S.; Ramjee, R. Sarathi: Efficient LLM inference by piggybacking decodes with chunked prefills. arXiv preprint arXiv:2308.16369, arXiv:2308.16369 2023.
48. Shen, H.; Chang, H.; Dong, B.; Luo, Y.; Meng, H. Efficient LLM inference on cpus. arXiv preprint arXiv:2311.00502, arXiv:2311.00502 2023.
49. Spector, B.; Re, C. Accelerating LLM inference with staged speculative decoding. arXiv preprint arXiv:2308.04623, arXiv:2308.04623 2023.
50. Cai, T.; Li, Y.; Geng, Z.; Peng, H.; Lee, J.D.; Chen, D.; Dao, T. Medusa: Simple LLM inference acceleration framework with multiple decoding heads. arXiv preprint arXiv:2401.10774, arXiv:2401.10774 2024.
51. Del Corro, L.; Del Giorno, A.; Agarwal, S.; Yu, B.; Awadallah, A.; Mukherjee, S. Skipdecode: Autoregressive skip decoding with batching and caching for efficient LLM inference. arXiv preprint arXiv:2307.02628, arXiv:2307.02628 2023.