To be honest I’m really exciting to read this because it exactly matches with I was thinking about in the past months.
It tries to build a practical Decentralized Cloud Service protocol, which is exactly what Web3 was talking about since day1.
Although many predecessors have tried on this direction, most of them lack the most important component: verifiability. With no verifiability, then it’s a distributed protocol rather than decentralized, it makes a significant difference here.
I’d like to comment on the following 4 aspects:
-
thoughts on what makes it cost-effective and scalable:
The underlying reason comes from Non-replicated work, i.e. the number of nodes solving the same task is independent to the network size. New joined nodes will contribute most to network capacity, by solving new tasks, and less to consensus enhancement, by replaying existing tasks.
Consensus roots in replicated work, Scalability roots in Non-replicated work.
Since it doesn’t need to maintain a universal ledger, the network consensus cost is saved and transformed to the scalability capacity.
-
Updating the State:
I agree that to build a stateful computation layer based on Ethereum, it may ultimately require a layer2 or layerN to reduce the storage cost.
I’d like to add that, probably what we need to manage the state is a DA layer in general, which doesn’t have to be coupled with the computation layer, i.e. the Decentralized Cloud Service network in this scenario. Correct me if I misunderstood it.
Just like the post mentioned, we can store the program files to a DA layer, the state can be managed in the same way, the only thing left is to prove that data io is correct (we’ve seen some solutions in zk oracles).
-
Onchain Arbitration
This is the most important design that distinguishes from other solutions from my perspective.
It uses Ethereum as the consensus layer to build verifiability, which is critical for decentralization.Challenge-based verification protocol is a practical design for web3, it’s an on-demand verification protocol that gives the choice back to the users over the tradeoff between security and cost. In other words, it is decoupled from and can work with different types of verification protocols like ZK, TEE, Fraud Proof, as the post mentioned.
-
Task Dependency
As another future discussion item following the stateful computation design, we may consider the situation where tasks have dependencies. If we manage to organize tasks into parallel-able partitions, we may enable the slicing of large tasks into smaller ones and remain the efficiency. In this way, we may achieve a promising decentralized training solution, or as the post mentioned, decentralized gaming etc.
With these comments added, the Decentralized and Verifiable Cloud Service can be viewed as a Scalable Decentralized Computation Network (CPN) layer, aims to handle complex Turing-complete computation tasks. It can work with a DA network as a Storage Network (STN) layer, and use Ethereum as the Consensus Network (CSN), i.e. the finalization Layer. In this sense, it shares the same vision with the World Supercomputer architecture. The service provider in this Decentralized Cloud Service protocol is like a Decentralized Processing Unit (DPU) in the World Supercomputer.
Anyway, it doesn’t matter how we describe it, the core idea behind is what we believed in that will pave the way towards the mass adoption. Thank you for sharing it out.