Introduction: This article will prospectively introduce a seemingly maverick Web3 infrastructure design paradigm - Storage-based Consensus Paradigm (SCP) Although this product design model is theoretically quite different from mainstream modular blockchain solutions such as Ethereum Rollup, it is very feasible in terms of ease of implementation and difficulty of connecting with Web2 platforms, because he does not intend to limit himself to a narrow implementation path like Rollup from the beginning, and wants to integrate Web2 platforms with Web3 facilities in a broader and more open framework, which can be said to be a brain-opening and imaginative approach.
Body: Let's imagine a public chain scaling scheme with the following characteristics:
- It has a speed comparable to that of traditional Web2 applications or exchanges, far exceeding any public chain, L2, rollup, sidechain, etc.
- There are no gas fees, and the cost of use is almost zero.
- The security of funds is high, far exceeding centralized facilities such as exchanges, etc., inferior to Rollup but greater than or equal to sidechains.
- The same user experience as Web2, without any knowledge of the blockchain's public and private keys, wallets, infrastructure, etc.
This solution is really exciting: on the one hand, it has basically achieved the ultimate in scaling, and on the other hand, it has laid a solid foundation for Web3's mass adoption, which basically eliminates the gap between Web2 and Web3 experience.
However, it seems that we can't think of many solutions that can be so complete, because there is really too little mainstream discussion and practice.
In fact, SCP is not limited to scaling, and its design inspiration does come from the scaling scheme and community discussions of public chains such as Bitcoin and Ethereum. Its vision and practical application is to build a new generation of trustless infrastructure, and even a non-blockchain computing platform.
SCP basic components and how they work
Generally speaking, SCP is also like the "modular blockchain" as the Ethereum and Celestia communities call it, with a data availability layer, an execution layer, a consensus layer, a settlement layer and other modules.
- Data availability layer: It is undertaken by a widely recognized and proven public chain, or storage facilities as the data availability layer, such as Ethereum, Arweave, Celestia, etc.
- Execution layer: A server that receives and executes user transactions, and submits transaction data signed by users to the DA layer in batches, similar to the sequencer of Rollup. However, the execution layer does not have to have a blockchain-style linked list structure, it can be completely a Web2 database + computing system, but the entire computing system must be open source and transparent.
- Consensus layer: It consists of a group of nodes, which pull the data submitted to the DA layer by the execution layer, and use the same algorithm as the execution layer to calculate the data to confirm whether the result output of the execution layer is correct, and can be used as disaster prevention redundancy of the execution layer. Users can also read the data returned by each node in the consensus layer to ensure that there is no fraud in the execution layer.
- Settlement Layer: Composed of a group of nodes and other contracts or addresses on other chains, it is used to handle the behavior of users depositing into SCP or withdrawing out from SCP, somewhat similar to the operation mode of cross-chain bridges. The settlement layer node controls the withdrawal function of the deposit address through the multi-signature contract or TSS-based address. When depositing, the user deposits assets to the designated address of the chain, and sends a request when withdrawing, and the settlement layer node reads the data and releases the assets through multisig or TSS. The degree of security of the settlement layer depends on the cross-chain mechanism employed.
The framework of practice for the SCP
The SCP paradigm can be understood through the following framework. A product that satisfies the SCP framework can have major functions such as deposits, transfers, withdrawals, swaps, etc., and can be further expanded on this basis. The following diagram is a schematic of such a product:
The DA layer of the project uses the permanent storage facility Arweave, the large circle in the diagram. Coordinator, that is, the execution layer. The user submits the transaction to the coordinator, who performs the calculation and presents the result, and then submits the user's original input data to the DA layer in batches. Detector pulls the raw data of transactions submitted by the coordinator from Arweave and verifies the data and results using an algorithm consistent with the coordinator. The Detector client is also open source and can be run by anyone. Watchmen, a group of detectors in charge of multi-signature in the withdrawal system. Withdrawal requests are validated and released based on transaction data. In addition, the watchman is also responsible for signing the proposal.
We can see the whole system, and the consensus they reach is all off-chain, which is the core of the storage consensus paradigm - it abandons the blockchain-style node consensus system, so that the execution layer gets rid of the heavy consensus exchange and confirmation process, and only needs to do the work of a server, so as to achieve almost unlimited TPS and economy. This is very similar to Rollup, but SCP has taken a different path from Rollup, trying to move from a scale-specific use case to a new transition model from Web2 to Web3. The coordinator mentioned above is a server, but this does not mean that the coordinator can do whatever he wants. Similar to Rollup's sequencer, after submitting user-submitted raw data to Arweave in batches, anyone can run a tester program to verify it and compare it to the state returned by the coordinator. To some extent, this is the same idea as the application of inscriptions. In this architecture, a centralized server or database does not pose a fundamental challenge. This is another aspect of the SCP paradigm, which decouples the concepts of "centralization" and "single entity" - in a trustless system, there can be a centralized component, or even a core component, but this does not affect the overall trustlessness.
We can shout the slogan - "The next generation of trustless infrastructure does not have to rely on consensus protocols, but should be open-source systems and P2P node networks". The original intention of people to invent and use blockchain is to be trustless, ledger consistent, non-forgeable, traceable and other clichéd fundamentals, which are clearly stated in the Bitcoin white paper. But after Ethereum, whether it is the scaling scheme of the old public chain, or the Rollup or modular blockchain, everyone has formed a mindset: what we do must be a blockchain (composed of the consensus protocol of the node), or a scheme that seems to be a chain like Rollup (only there is a data structure of the blockchain, but the nodes do not have a direct consensus message exchange). But now, under the framework of SCP, even if it is not a blockchain, a series of requirements such as trustlessness, ledger consistency, non-forgeability, traceability and so on can be realized, of course, the premise is that there are more clear implementation details.
Execution layer
The execution layer is crucial in the overall system, it undertakes the computational process of the entire system, and also determines what kind of applications can be run on the system.
Endless execution environments
Theoretically, the execution environment in the execution layer can be made in any form, and the possibilities are endless, depending on how the project team positions its project:
- Exchange. Based on SCP, an open, transparent, and high-TPS exchange can be built, which can not only have the characteristics of CEX speed and zero cost, but also maintain the decentralization of DEX. The distinction between CEXs and DEXs becomes blurred here.
- Payment Networks. Similar to Alipay, PayPal, etc.
- Support for virtual machines/blockchains that load programs/contracts. Any developer can deploy any application on it, share all user data with other programs, and operate according to the user's instructions.
SCP's design pattern of supporting arbitrary execution environments has its unique benefit: it no longer has to rely on certain components with historical baggage, especially the concept of "account abstraction" that is unique to the Ethereum community, which is inherently undesirable for SCP. Under the SCP architecture, there is no such thing as an account abstraction - you can use Web2 standard accounts, blockchain accounts, etc. From this perspective, many mature Web2 use cases don't need to be rethought and built to work directly on SCP. This may be the benefit of SCP over Rollup.
Transparency and asymmetry
The account system mentioned above, and sensitive readers should have noticed that although SCP can take advantage of Web2's account system, it seems to be problematic to use it as it is. Because the whole system is completely transparent, using the user-to-server interaction model directly will cause serious problems, resulting in no security at all. Let's start by reviewing how the traditional server-user model works:
1. Account registration: The user enters the username and password on the registration page of the application. In order to protect the user's password, the server will process the password through a hash function after receiving it. To increase the complexity of the hash and defend against rainbow table attacks, each user's password is typically concatenated with a randomly generated string of strings (called "salts") and hashed together. Usernames, salts, and hashes are stored in the service provider's database in clear text and are not publicly available. But even so, it is necessary to add salt and safe treatment, one to prevent internal ghosts, and the other to prevent attacks.
2. User Login: Users enter their username and password on the login form. The system compares the processed password hash with the hash value stored in the database. If the two hashes match, indicating that the user has provided the correct password, the login process continues.
3. Operation authentication: After the login verification is passed, the system will create a session for the user. Typically, session information is stored on a 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 the username and password for the next step: the browser or app saves the cookie identifier and attaches an identifier to each request, indicating that they have permission from the server to which the cookie is associated.
Let's review the typical Web3 blockchain-user interaction system:
1. Account Registration: There is virtually no account registration process, and there is no username-password system. Accounts (addresses) do not require registration, they exist naturally, and whoever holds their private key controls the account. The private key is randomly generated locally by the wallet and does not involve the networking process.
2. User login: The use of blockchain does not require login, and most dApps do not have the login process, but connect to the wallet. Some dApps will require users to sign and verify after connecting to the wallet to ensure that the user really holds the private key, rather than just passing a wallet address to the frontend.
3. Operation authentication: The user directly submits the signed data to the node, and the node will broadcast the transaction to the entire blockchain network after verification, and the user's operation will be confirmed after the consensus of the blockchain network is satisfied.
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 secrets. Although the execution layer of SCP may not be a blockchain, all data needs to be synchronized to the publicly visible DA layer, so the authentication method used by SCP for login and operation must be asymmetrical. However, because we don't want to have cumbersome actions and poor experience that affect mass adoption, such as letting users keep their private keys and use wallets, and the application built on SCP also has a strong need to use traditional ID passwords or OAuth three-party authentication to log in, so how to combine the two? Since asymmetric cryptography and zero-knowledge proof pairs are asymmetrical, I envision two possible scenarios:
- If you want to use the ID-password system, you can leave this password storage module out of the SCP so that no one else can see it. The SCP execution layer still uses the blockchain's public and private key accounts and operation logic, 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 stored on the project side, and the more feasible solution is to use 2-3 MPC to solve the problem of centralized storage, and at the same time do not let users have the burden of using private keys.
- When you rely on OAuth login, you can use JWT (Json Web Token) as a method of authentication. This method will be slightly more centralized than the above, because it essentially needs to rely on the third-party login service provided by Web2 manufacturers as identity authentication.
- The first time you log in with a third party, the fields in the JWT that characterize the user's identity and the service provider's identity are registered in the system. In the user's subsequent operations, the operation instruction is used as the public input, and the JWT as a whole is used as a secret witness to verify each user's transaction with ZKP.
- Each JWT has an expiration date, and the next time the user logs in, it will apply for a new JWT, so there is no need to keep it forever. In addition, this system also needs to rely on JWK, which can be understood as the public key provided by the big factory to verify JWK. It is also worth exploring how the JWK is decentralised into the system and how to deal with the rotation of private keys in the future.
Either way, it's more expensive to develop and compute than traditional methods, but it's also a necessary price to pay for decentralization. Of course, if the project team does not believe that extreme decentralization is necessary, or there are different milestones at different stages of development, it is okay to do without these designs, because decentralization is not black and white, but there is a gray area in the middle.
Privacy
The transparency issues mentioned above have an impact not only on the user's interaction paradigm, but also on the user's data. The user's data is directly exposed. While this is not a problem in blockchains, it is not very acceptable in some applications, so developers can also build private transaction systems.
toll
How the execution layer charges is another point of concern. This is because there are also costs associated with submitting data to the DA layer, including the operation of its own servers. The first core purpose of traditional blockchains to charge users gas fees is to prevent users from swiping a large number of duplicate transactions to disrupt the transaction network, and the second is to sort transactions according to gas. Web2 doesn't have similar concerns, so there are only basic concepts like floods and DDoS. The execution layer can customize various charging strategies, such as completely free or partially charged, and can also monetize other behaviors such as MEV (which is very well established in the sequencer), campaigns, etc.
Censorship resistance
The execution layer is not censorship-resistant, and can theoretically reject users' transactions indefinitely. In Rollup, censorship resistance can be ensured by the forced aggregation function of the L1 contract, while the sidechain or public chain is a complete distributed blockchain network, which is also difficult to review. There is currently no clear solution to the problem of censorship resistance, which is a problem with the SCP paradigm.
Consensus layer
This layer is made up of loose nodes that do not actively form the network, so it is not strictly a consensus layer, but only used to confirm the current state of the execution layer to the outside world (such as users). For example, if you have doubts about the operational state of these nodes, you can download their detector client, which runs the same program code as the coordinator. However, this is similar to Rollup, because the data is submitted in batches, the execution layer always returns a newer state to the user than the DA layer. This involves a pre-confirmation problem: the execution layer gives the user the result of pre-confirmation and soft finality, because it has not yet been submitted to the DA layer, while the consensus layer provides the user 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 will not trust the data broadcast by the Rollup serializer off-chain, and must wait for the data to be uploaded to Ethereum before it is recognized. In addition to being used to confirm results, the consensus layer also plays an important role, which is disaster redundancy as an execution layer. If the execution layer strikes permanently and does serious evil, theoretically any consensus 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 to serve as the server for the execution layer.
Settlement layer
Since SCP is not a rollup, it cannot be a trustless withdrawal based on cryptography and smart contract code without human intervention, like Rollup's withdrawal settlement layer. The security level of SCP cross-chain bridge is the same as that of sidechain or third-party witness cross-chain bridge, and it needs to rely on a multi-signature manager with authority to release assets, which we call the witness model.
Making the witness bridge as decentralized as possible is a topic of many cross-chain bridge researches. Space is limited, so I won't expand on it here. A well-designed SCP platform must also have a reputable decentralized bridge's multi-signature partners in practice. One might ask why SCP doesn't use chains with smart contracts as the DA layer, which allows for a completely trustless settlement layer that gives contracts. In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on top of a DA layer with contracts such as Ethereum, and the corresponding contract for verification can be built, SCP can also obtain the same settlement security as Rollup, without the need to use multi-signature.
In practice, however, this may not be optimal:
1. Ethereum is not specifically used for data storage, and the price is too high compared to the pure data storage public chain. For the SCP paradigm, a sufficiently low or fixed storage cost is crucial. Only in this way can it be possible to support Web2-level throughput.
2. Prove that the system is very difficult to develop, because SCP can not only simulate EVM, but implement any logic. Looking at the fact that the fraud proofs of teams like Optimism are still not online, and the development of zkEVM is difficult, we can imagine that it is extremely difficult to implement the proofs of various systems on Ethereum.
If you plan to implement a broader and more open approach that moves away from the EVM system and incorporates more Web2 features, the idea of Ethereum Rollup is not suitable. SCP is not a public chain scaling solution, but a larger Web3 computing platform architecture, so there is obviously no need to follow the idea of Ethereum Layer 2.
A diagram comparing SCP with other paradigms