Published Social post

Ming Wu (@spark_ren): 0G has released its compute network and service marketplace for a while (docs.0g.ai/build-with-0g/…). This is the foundation of @0G_labs' decentralize…

Estimated coin impact

Scores are not price-change percentages. High impact means a score of +70 or more, or -70 or less.

Impact unavailable

0G has released its compute network and service marketplace for a while (docs.0g.ai/build-with-0g/…). This is the foundation of @0G_labs' decentralized model inference and training/fine-tuning platform which in turn is the foundation of the agent interaction and evolution. Here I am going to briefly introduce the principle and rationale behind its design. 0G compute network adopts a free marketplace where users and service providers decide the prices of the services through a peer-to-peer fashion. The service provider is free to quote their services, and then users are free to choose the services that are priced appropriately for them to use. We consider the case where any service result can be verified by the user who submits the request or by the smart contract. For light weight service with short latency, we let users directly verify the service results by themselves to avoid on-chain verification overhead. We treat the service providers as more trustworthy than users and less powerful to apply sybil attack. Therefore, a user may face the risk of losing the cost of a single request. In other words, when a user submits a request and sends fee to smart contract, she may spend the fee but fail to get the service result if the service provider is malicious, since the user cannot prove that to others. In this case, the user can choose other service providers in the network to retry the request. This would work well since the cost of a single request is very cheap. For large request with long latency, the service result verification can be conducted in the smart contract so that users will never lose the fees. The overhead of the on-chain verification can be ignored in this case. Here is the specific flow of the process. The service provider should first register into the smart contract the service types that it provides, the price of each type, and the verification mechanism. When a user wants to access the service, she pre-charges some amount of fees to the smart contract for this service provider. The user then can issue requests to the service provider and the service provider decides to respond with the serving results based on whether the remaining fee is enough. Any request and response have the signatures of the user and the service provider, respectively. The user can verify each response and decide to stop sending further request if the verification is failed. The service provider can decide at any point to send the request traces with user’s signature to the smart contract for settlement. Once settlement is done, the corresponding portion of the pre-charged fee can be sent to service provider’s account. The performance trade-off is how often the service provider submits the settlement request to the smart contract. For the high-latency services, the provider can submit settlement per user request. But for the low-latency services, the provider may need to batch more user requests for one settlement. Another consideration is how the user request trace should be organized as the smart contract input for settlement. Plainly submitting all the requests in the trace may involve too much on-chain gas consumption. Therefore 0G employs zk-proof mechanism for the settlement process to minimize on-chain verification cost. The model inference, pre-training, and fine-tuning can be the decentralized services deployed in 0G compute network. This is how we work with @ai16zdao, @shawmakesmagic to adapt #Eliza and other agents to live in the marketplace of trust.

Back to news archive