Storage Consensus Paradigm: Non Blockchain for the next generation of blockchain
Web3 is booming, and Arweave is becoming a popular infrastructure choice for developers. PermaDAO is a community where everyone can contribute to the Arweave ecosystem. It's a place to propose and tackle tasks related to Arweave, with the support and feedback of the entire community. Join PermaDAO and help shape Web3!
Author: Wuyue @ Contributor of PermaDAO
Translator: Jomosis @ Contributor of PermaDAO
Reviewer: John Khor @ Contributor of PermaDAO
This article will introduce a Web3 infrastructure design paradigm with a difference — Storage Consensus Paradigm (SCP) . Although SCP was a similar solution as Rollup, it implements totally differently. It’s much easier to use and integrate with Web2 platforms.
Suppose there’s a public blockchain scaling solution with the following features:
Rivaling the speed of traditional Web2 applications and exchanges, faster than any public blockchain, L2, Rollup, and side chains
No gas fee and cost-free
The security of funds is high, far surpassing centralized facilities such as exchanges, inferior to Rollup but equal to side chains.
Providing the same user experience as Web2, no need for users to be aware of public/private key, wallet or any infrastructure
It’s indeed an amazing solution since it’s almost the end game for scaling, which lays solid foundation for mass adoption and eliminates the user experience gap between Web2 and Web3.
We could hardly think of another solution to handle the situation so perfectly since there are seldom mainstream discussions and practices on this. This article takes us to foresee this excellent and advanced design paradigm for the next Web3 computing platform — SCP (Storage-based Consensus Paradigm).
We’re using scaling which is a familiar topic for us as a lead, but SCP is in fact not limited to scaling problems. Although it originated from the scaling solutions of public blockchains like Bitcoin and Ethereum, it aims to build a new generation of public blockchain or computing platform of nonblockchain structure.
Basic Components Of SCP And How It Works
Data Availability Layer: Use a widely acknowledged and firmly tested blockchain or permanent storage infrastructure as a data availability layer, such as Ethereum or Arweave.
Execution Layer: Use a server to receive user transactions and execute them and submit the raw transaction data signer by users to DA layer in batches, which works similarly like sequencer in Rollup. While this execution layer does not necessarily have a data structure as blockchain or any related concepts of blockchain such as EVM compatible, it could be a Web2 database combined with a computing system which is definitely open-sourced.
Consensus Confirmation Layer：It is formed of nodes which pull raw data submitted to DA layer from the execution layer, compute the data using the same algorithm as the execution layer to validate the output and set a backup for the execution layer. User can also check the validity of the execution layer through the data returning from nodes of the consensus confirmation layer.
Settlement Layer: It is combined with a group of nodes and other onchain contracts and addresses, which helps users to deposit and withdraw in SCP. Nodes also need to execute the same algorithm as the execution layer to validate the pulled data. Nodes control the withdrawal of deposit addresses through multisig contracts or addresses based on TSS. During the deposit, user needs to deposit to the specific address for the current chain, and send the request to the settlement layer. Then nodes on settlement layer retrieve the data from DA layer. Assets will be released after the multisig or TSS process.
everPay
everPay is the pioneer of SCP, which took the lead in building its own products using SCP. Now it supports the main functions of deposit, transfer, withdrawal and swap, which allows any expansion of Web3 and Web2 functions based on them.
Now let’s learn to fully understand SCP through the workflow of everPay.
The DA layer of everPay uses the permanent storage infrastructure, Arweave, which is the big circle in the picture.
Coordinator as execution layer. The user commits the transaction to the coordinator. Then the coordinator computes and displays the results, submitting the raw input data of users to DA layer.
The detector pulls the raw transaction data submitted by the coordinator, then validates the data and results using the same algorithm as the coordinator. The client of the validator is open-sourced which allows anyone to run.
Watchmen takes charge of a group of validators for system multisig. It will validate and approve withdrawal requests according to the transaction data. Also, it’s responsible for signing the proposal.
We could see that the whole system confirms their consensus off the chain which displays the core of SCP. It abandons the blockchain like consensus system between nodes so that the execution layer could focus on working as a server instead of dealing with heavy communication and verification process of consensus. This provides unlimited TPS and economical efficiency. Such point is similar to Rollup, while SCP improves it from a scaling-only solution to a design paradigm for the new generation of computing platform.
The coordinator of everpay is a server and that doesn’t mean it can act maliciously. It works almost the same as Rollup sequencer. After submitting the raw data of users to Arweave in batches, anyone can run the validator scripts to validate the data and compare the state return from the coordinator. This relies on the state transferring function (STF) , which is an absolute function including the process: input -> STF -> output. As long as everyone owns the same input and STF (all submitted to DA , immutable and transparent), the output must be same.
Under such structure, a centralized server or database won’t break the decentralization, which is another core concept of SCP. It extracts the binding concept of decentralization and single entity. It’s reasonable to have centralized components in a decentralized system. The whole decentralization won’t be affected even when a core component is centralized.
Therefore, we could shout out a terrifying but logical slogan - Non-Blockchain for the next generation of blockchain. People invent and use blockchain to fulfill the basic needs of decentralization, consensus ledger, immutability and traceability. No matter scaling solutions for old public blockchain or building a new public chain, people always think inside the box of building a blockchain combined with the consensus between the communication of nodes, or the blockchain like solution of building a Rollup which only has the data structure of blockchain instead of consensus between nodes. Now considering the solution provided by SCP, all the basic needs above can be satisfied even without blockchain.
The execution Layer
The execution layer plays a vital role in the whole system, which is responsible for the capacity and computation for the whole system, and also decides what application could run in the system.
Infinite possibilities of the execution environment
The execution environment in the execution layer can be built in any form of products, which depends on the interest of builders:
Exchange. Building an open and transparent exchange with unlimited TPS based on SCP, it can be fast and cost-free as CEX, and also be decentralized as DEX, which blurs the difference between CEX and DEX.
Payment network. Like Alipay and PayPal.
The virtual machine /blockchain supporting programs/contracts. Developers can deploy any applications on it, share data of all users with other applications and operate according to the order of users.
Since users only interact with the server instead of wallets on the blockchain, its user experience is consistent with traditional Internet applications, but decentralized at the same time.
It can be seen that the above process already includes similar concepts such as cross-chain swap and account abstraction. Of course, they are only similar. We only understand them in the context of SCP. In particular, concepts like account abstraction are naturally unnecessary for SCP. This should be said to be the baggage left by Ethereum. After many rounds of effort, the Ethereum community finally launched the EIP-4337 standard to solve one of the problems with the mass adoption of Web3 - the account problem. Moreover, EIP-4337 is just a standard, and its application practice has yet to be tested. Under the SCP architecture, there is no concept of account abstraction - you can seamlessly switch between Web2 standard accounts and blockchain accounts. From this perspective, many mature Web2 use cases can be directly used on SCP without reinventing the wheel.
Transparency and Asymmetry
The account system was mentioned above. Sensitive readers should have discovered that problems will occur if using the current Web2 account system.
Because this entire system is completely transparent! Directly using the user-to-server interaction model will cause serious problems, resulting in the entire system having no security at all. Let's first review how the traditional server-user model works:
Account registration: Users enter their username and password on the registration page of the application. To protect the user's password, the server processes the password through a hash function after receiving it. To increase hashing complexity and protect against rainbow table attacks, each user's password is often hashed together by concatenating a randomly generated string (called a "salt"). The username, salt, and hash are stored in plain text in the database of the service provider and are not made public.
User login: Users enter their username and password in the login form. The system compares the hash value of the processed password with the hash value stored in the database. If the two hashes match, it means that the user provided the correct password and the login process continues.
Operation authentication: After the login authentication is passed, the system will create a session for the user. Typically, session information is stored on the server, and the server sends an identifier (such as a cookie or token) to the user's browser or application. The user no longer needs to re-enter their username and password for subsequent operations: the browser or application saves the identifier and sends it with every request.
Let’s review the typical Web3 blockchain-user interaction system:
Account registration: There is actually no account registration process, and there is no username-password system. Accounts (addresses) do not need to be registered, they exist naturally, and whoever has the private key controls the account. The private key is randomly generated locally by the wallet and does not involve the networking process.
User login: The use of blockchain does not require login. Most dApps do not have the login process, but connect to the wallet. After connecting to the wallet, some dApps will require the user to perform signature verification on the identity of the connected wallet to ensure that the user actually holds the private key of the wallet, rather than just passing a wallet address to the front end.
Operation authentication: The user directly submits the signed data to the node. After verification, the node will broadcast the transaction to the entire blockchain network. Once the blockchain network consensus is met, the user's operation will be confirmed.
The difference between the two modes is caused by symmetry and asymmetry. In a server-user architecture, both parties hold the same secrets. In a blockchain-user architecture, only the user holds the secret. Although the execution layer of SCP may not be a blockchain, all data needs to be synchronized to the publicly visible DA layer. Therefore, the login and operation verification methods used by SCP must be asymmetric. We don’t want users to be aware of the complicated operation and bad experience because of mass adoption, like storing the private key and using the wallet. At the same time, there is also a strong demand for applications built on SCP to use traditional ID passwords or OAuth three-party authentication to log in. So how can we combine these two demands?
Due to the asymmetric nature of asymmetric cryptography and zero-knowledge proofs, I envisioned two possible solutions:
If you want to use the ID-password system, you could abort the module to save the password in the SCP, so that it won’t be visible to others. The SCP execution layer still uses the public and private key accounts and operation logic of the blockchain, and there is no registration, no login, etc. The user's ID actually corresponds to a private key. Of course, this private key cannot be saved on the project side. A more feasible solution is to use 2-3 MPC to solve the problem of centralized storage without letting users have the burden of using private keys.
When using OAuth to log in, JWT (Json Web Token) can be used as the authentication method. This method will be slightly more centralized than the above, because it essentially relies on the third-party login service provided by the major Web2 tech giants for identity authentication.When the user log in with a third party for the first time, the system will register the fields in the JWT that represent the user's and the service provider's identity. Subsequently, user will use operation instructions as public input, the JWT as a whole as a secret witness and verify each user's transaction with ZKP. Each JWT has an expiration time limit, and the user will also apply for a new JWT when they log in next time, so there is no need to keep it. It’s similar to validate JWK by the public key provided by Web2 tech giants.
No matter which method is used, the development and computing costs are higher than the traditional method. But it’s worth paying for decentralization. Of course, if the project party does not prefer extreme decentralization, or have different milestones at different stages of development, they don’t have to follow these designs. Decentralization is neutral, but does have some gray area in it.
Privacy
The transparency issue just mentioned above not only affects the user's interaction paradigm, but also affects user data. User data is directly exposed. Although it’s not a problem in blockchain, it’s less acceptable in some applications. So developers can build transaction privacy systems.
Profit Model
How the execution layer charges is another attracting point. Submitting data to the DA layer and running its own server require cost. Traditional blockchain charge users for gas fees for two core reasons. One is to prevent users to submit repeated transactions to damage the transaction network, the other is to sort transactions according to gas fee cost. While it’s not that complex in Web2, only basic concepts such as floods and DDoS are facing it.
The execution layer can be customized with various charging strategies, such as completely free or partially charged, and can also profit from other behaviors such as MEV (very mature in the sequencer), market activities, etc.
Censorship Resistance
The execution layer is not censorship-resistant, so it can deny users’ transactions without limit. In Rollup, censorship resistance can be guaranteed by the forced collection function of the L1 contract, while the side chain or public chain is a fully decentralized blockchain network which is difficult to be censored.
There is currently no clear solution to solve this problem, which remains to be solved by SCP paradigm.
Consensus confirmation layer
This layer is composed of loose nodes, which do not actively form any network. It’s not a consensus layer, but only serve as confirming the status of the current execution layer with the outside world (such as users). For example, if you have any doubts about everPay's operational status, you can download its detector client, which runs the same STF as the coordinator.
However, this is similar to Rollup. Since data is submitted in batches, the status returned to the user by the execution layer is always newer than that on the DA layer. This involves a soft and hard finality issue. The execution layer provides users with soft finality because it has not yet been submitted to the DA layer; while the consensus confirmation layer provides users with hard finality. Users may not particularly care about this, but for applications such as cross-chain bridges, hard finality must be followed. For example, the exchange's deposit and withdrawal system does not rely on the instant finality of the Rollup sequencer.
In addition to being used to confirm results, the consensus confirmation layer also plays an important role, which is to serve as disaster prevention redundancy for the execution layer. If the execution layer goes on permanent strike and commits serious crimes, in theory any consensus confirmation layer can take over the work of the execution layer and receive user requests. If such a serious situation occurs, the community should choose a stable and reliable node as the execution layer server.
Settlement layer
Since SCP is not a Rollup, it’s not able to provide trust-free withdrawals that are free of manual intervention and completely based on mathematics and smart contracts like the Rollup withdrawal settlement layer. Its level of security is the same as the cross-chain mechanism of side chains or cross-chain bridges. It relies on authorized observers to release assets, which we call the witness mode.
Making the witness bridge as decentralized as possible is a target for many cross-chain bridges. Due to space limitations, we will not go into details here. A well-designed SCP platform must also collaborate with a reputable multi-signature partner of decentralized bridges in use cases. For example, everPay has in-depth cooperation with MPC service provider Safeheron.
Someone may ask why SCP doesn’t use a chain with smart contracts as the DA layer, since fully trustless settlement layer can be created based on the contract.
In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on a contracted DA layer such as Ethereum and the corresponding contract for verification can be constructed, SCP can also obtain the same settlement security as Rollup, and No need to use multiple signatures.
But in practice this may not be the best choice:
Ethereum is not specifically used for data storage, and the price is too high compared to a pure data storage public chain. For the SCP paradigm, sufficiently low or fixed storage costs are crucial.
It proves that the system is very difficult to develop, because SCP can not only simulate EVM, but also implement any logic. And when we look at teams like Optimism, which currently has no fraud proof online, and how difficult it is to develop zkEVM, we can imagine that it is extremely difficult to implement proof of various systems on Ethereum.
Another more critical point is that the so-called settlement security that is the same as Rollup is only for the DA layer chain itself with smart contracts, such as Ethereum, because all original data is passed to Ethereum. Then your settlement contract on Ethereum can "reference" the original input data to prove the correctness of the final state (note that it is not a direct reference but an indirect reference through a hash or accumulator, etc. to leave the status mark of the original call data, because The call data of historical transactions itself cannot be referenced by the contract). But for other chains, they cannot enjoy the same security because there is no data on them. If you want to cross other chains, you can only use the witness mode cross-chain bridge.
Therefore, the Rollup solution only has better settlement security from a specific perspective, that is, when you regard one chain as your parent chain. SCP is not a certain public chain expansion plan, but a larger Web3 computing platform architecture, so it does not necessarily have to be implemented from the perspective of a certain chain-centrism. If the settlement layer is built on a smart contract, it cannot guarantee the settlement security of other chains except the parent chain. If you are not specifically here to expand the capacity of this chain, this seems completely unreasonable.
Summary
A picture comparing SCP to other paradigms.
SCP is a new Web3 computing platform paradigm, which is comparable to the application speed of traditional Web2 transactions. The transaction cost is negligible. Infinite possible applications can be built on it, and the security is consistent with mainstream solutions. At present, several applications have emerged under the SCP paradigm, such as everPay, PermaSwap, Mind Network, etc. Based on their excellent design concepts, they are very promising to usher in explosive growth in this and the next bull market.
🔗 More about PermaDAO：Website | Twitter | Telegram | Discord | Medium | Youtube
