How to break out of the Rollup mindset and integrate the Web2 platform with Web3 with a broader and more open framework?
Written by Wuyue, Geek Web3
**Introduction: **This article will prospectively introduce a Web3 infrastructure design paradigm that seems a bit unique - Storage-based Consensus Paradigm (SCP). Although this product design model In theory, it is quite different from mainstream modular blockchain solutions such as Ethereum Rollup, but it is very feasible in terms of ease of implementation and ease of connection with the Web2 platform, because it has From the beginning, I did not intend to limit myself to a narrow implementation path like Rollup. I wanted to use a broader and more open framework to integrate the Web2 platform and Web3 facilities, which can be said to be a brain A wide-open, imaginative approach.
Text: Let us imagine a public chain expansion solution with the following characteristics:
- It has a speed comparable to traditional Web2 applications or exchanges, far exceeding any public chain, L2, rollup, side chain, etc.
- There is no gas fee, and the usage cost is almost 0.
- The security of funds is high, far exceeding that of centralized facilities such as exchanges, inferior to Rollup but greater than or equal to side chains.
- The same user experience as Web2, without any knowledge of the public and private keys, wallets, infrastructure, etc. of the blockchain.
Such a solution is indeed very exciting: on the one hand, it has basically achieved the ultimate in capacity expansion; on the other hand, it has also laid a very solid foundation for mass adoption of Web3, basically eliminating the gap between Web2 and Web3 usage experience.
However, we can’t seem to imagine how many solutions can be so complete, because there is indeed too little mainstream discussion and practice.
We used expansion, a very familiar topic, as an introduction above. In fact, SCP is not limited to expansion. Its design inspiration does come from the expansion plans 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, even a non-blockchain computing platform. **
SCP basic components and working principles
Generally speaking, **SCP is also like what the Ethereum and Celestia communities call a “modular blockchain”. **It has module divisions such as data availability layer, execution layer, consensus layer, and settlement layer.
- Data availability layer: It is assumed 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 used to receive user transactions and execute them, and at the same time submit user-signed transaction data to the DA layer in batches, similar to Rollup’s sequencer. But the execution layer does not necessarily have a blockchain-style linked list structure. It can be completely Web2 database + computing system, but the entire computing system must be open source and transparent.
- Consensus layer: It is composed of a group of nodes. They pull the data submitted by the execution layer to the DA layer, and use the same algorithm as the execution layer to operate on these data to confirm whether the result output of the execution layer is correct, and Can be used as disaster prevention redundancy for 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: It is composed of a group of nodes and contracts or addresses on other chains. It is used to handle the behavior of users recharging into SCP or withdrawing money from SCP. It is somewhat similar to the operation mode of a cross-chain bridge. The settlement layer node controls the withdrawal function of the recharge address through multi-sign contracts or TSS-based addresses. When recharging, the user deposits assets to the designated address on the chain, and when withdrawing, a request is sent. After the settlement layer node reads the data, it releases the assets through multi-signature or TSS. The security level of the settlement layer depends on the cross-chain mechanism adopted.
SCP’s practice framework
We can understand the SCP paradigm through the following framework. A product that meets the SCP framework can have main functions such as recharge, transfer, withdrawal, swap, etc., and can be further expanded on this basis. The picture below is a schematic diagram of such a product:
- The DA layer of the project uses the permanent storage facility Arweave, the large circle in the picture.
- **Coordinator, the execution layer. **The user submits the transaction to the coordinator, the coordinator performs the operation and displays the operation results, and then submits the user’s original input data to the DA layer in batches.
- Detector, pulls the original transaction data submitted by the coordinator from Arweave, and uses the algorithm consistent with the coordinator to verify the data and results. The detector client is also open source and can be run by anyone.
- **Watchmen, a group of testers who are in charge of the multi-signature of the withdrawal system. **Withdrawal requests will be verified and released based on transaction data. In addition, the watchman is also responsible for signing the proposal.
We can see the entire system, and the consensus they reached is all located off-chain. This is the core of the storage consensus paradigm - it abandons the blockchain-style node consensus system and frees the execution layer from heavy consensus. The communication and confirmation process only requires the work of one server, thereby achieving nearly unlimited TPS and economy. This is very similar to Rollup, but SCP has taken a different path from Rollup, turning it from a dedicated use case for capacity expansion 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 sorter, after the original data submitted by users are submitted in batches on Arweave, anyone can run the detector program to verify it and compare it with the status returned by the coordinator. **To some extent, this is exactly the same as the idea of inscription applications. **
Under this architecture, a centralized server and database do not pose a fundamental challenge. This is also another point of the SCP paradigm, which binds and decouples the two concepts of “centralization” and “single entity” - **In a trustless system, there can be centralized components, **it can even be a core components, but this does not affect the overall trustlessness.
We can shout out such a 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 inventing and using blockchain is to distrust, consistent ledgers, unforgeable, traceable and other commonplace fundamentals, which are clearly stated in the Bitcoin white paper. **But after Ethereum, **whether it is the expansion plan of the old public chain, or Rollup or modular blockchain, everyone has formed a mindset: what we make must be a blockchain ( It consists of the consensus protocol of the nodes), or a solution like Rollup that looks like a chain (it just has the data structure of the blockchain, but the nodes do not directly exchange consensus messages).
But now, under the SCP-based framework, even if it is not a blockchain, a series of requirements such as trustlessness, ledger consistency, non-forgery, traceability, etc. can be achieved. Of course, the premise is that there must be clearer implementation details.
Execution layer
The execution layer is crucial in the entire system. It undertakes the computing process of the entire system and determines what applications can be run on the system.
Endless possible execution environments
Theoretically, the execution environment in the execution layer can be made into any shape, and the possibilities are endless, depending on how the project party positions its project:
*Exchange. Based on SCP, an open, transparent, and high-TPS exchange can be built. This exchange can not only have the characteristics of CEX’s speed and zero cost, but also maintain the decentralization of DEX. The distinction between CEX and DEX becomes blurred here.
- Payment network. Similar to Alipay, PayPal, etc.
- Support virtual machine/blockchain for loading 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, a design model that supports arbitrary execution environments, has its unique benefits: **You no longer have to rely on certain components with historical baggage, especially the “account abstraction” concept unique to the Ethereum community, which is very important to SCP. It is said that it is not necessary by nature.
Under the SCP architecture, there is no concept of account abstraction - you can use Web2 standard accounts and blockchain accounts at will. From this perspective, many mature Web2 use cases can be directly used on SCP without rethinking and building. This may be the benefit of SCP compared to Rollup. **
Transparency and Asymmetry
The account system was mentioned above. Sensitive readers should have discovered that although SCP can use the Web2 account system, there seem to be problems with using it unchanged.
Because this entire system is completely transparent! Directly using the user-to-server interaction model will cause serious problems, resulting in no security for the entire system. Let’s first review how the traditional server-user model works:
1. Account registration: The user enters the 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 the complexity of the hash and protect against rainbow table attacks, each user’s password is often concatenated with a randomly generated string (called a “salt”) and hashed together. **The username, salt, and hash are stored in clear text in the service provider’s database and are not disclosed to the public. **But even so, salting and security treatment are still needed to prevent insiders and attacks.
2. User Login: Users enter their username and password on the login form. The system compares the processed password hash value with the hash value stored in the database. If the two hashes match, the user provided the correct password and the login process continues.
3. 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 identification (such as a token) to the user’s browser or application. Users no longer need to re-enter their username and password in subsequent operations: the browser or application will save the identifier and include it with each request to indicate that they have permission from the associated server.
Let’s review the typical Web3 blockchain-user interaction system:
1. 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.
2. User login: The use of blockchain does not require login. Most dApps do not have the login process, but connect to the wallet. Some dApps will require users to perform signature verification after connecting to the wallet to ensure that the user actually holds the private key, rather than just passing a wallet address to the front end.
**3. 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. After meeting the consensus of the blockchain network, 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. **But because we don’t want users to keep private keys, use wallets, and other cumbersome actions and poor experiences that affect large-scale adoption, 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 to combine the two?
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 can not include this password saving module in the SCP, so that it will not 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 relying on 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 manufacturer for identity authentication.
- When using a third-party to log in for the first time, register the fields in the JWT that represent the user identity and service provider identity in the system. In the user’s subsequent operations, the operation instructions are used as 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 time limit, and the user will also apply for a new JWT the next time he logs in, so there is no need to keep it permanently. In addition, this system also needs to rely on JWK, which can be understood as the public key provided by the manufacturer to verify JWK. So how to input JWK into the system in a decentralized manner and how to deal with private key rotation in the future are also worth exploring.
**No matter which method is used, the development and computing costs are higher than the traditional method, but this is also a necessary price to pay for decentralization. **Of course, if the project party does not think that extreme decentralization is necessary, or there are different milestones at different stages of development, it is okay without these designs, because decentralization is not black and white, but There is a gray area in between.
Privacy
The transparency issues mentioned above not only affect the user’s interaction paradigm, but also affect user data. User data is directly exposed. Although not a problem in blockchain, this is not acceptable in some applications, so developers can also build private transaction systems.
TOLL
How the executive layer charges is another point worthy of attention. Because submitting data to the DA layer also requires costs, including the operation of its own server. The first core purpose of traditional blockchain charging users with gas fees is to prevent users from damaging the transaction network by making a large number of repeated transactions, and the second is to sort transactions based on gas. Web2 does not have similar concerns, so there are only basic concepts such as flooding and DDoS.
**The execution layer can customize various charging strategies, such as completely free or partially charged. **It 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 and can theoretically 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 complete distributed blockchain network and is difficult to censor.
**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 composed of loose nodes. These nodes do not actively form a network, so it is not a consensus layer in a strict sense, but is only used to confirm the current execution layer status to the outside world (such as users).
For example, if you have any doubts about the health of these nodes, you can download their detector client, which will run the same program code 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 pre-confirmation issue:
**The execution layer gives users pre-confirmed, soft-final results, **because they have not yet been submitted to the DA layer;
**The consensus 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 will not believe the data broadcast off-chain by the Rollup sequencer. It must wait until the data is uploaded to Ethereum before it is recognized.
In addition to being used to confirm results, the consensus layer also plays a very important role, which is as a disaster prevention redundancy for the execution layer. **If the execution layer permanently goes on strike and commits serious crimes, in theory 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 as the execution layer server.
Settlement layer
Since SCP is not a Rollup, it cannot achieve trustless withdrawals that do not require manual intervention and are completely based on cryptography and smart contract code like Rollup’s withdrawal settlement layer. **The security level of SCP cross-chain bridge is the same as that of side chain or third-party witness cross-chain bridge. **It needs to rely on authorized multi-signature managers to release assets, which we call the witness mode.
Making the witness bridge as decentralized as possible is a topic of many cross-chain bridge studies. Due to space limitations, we will not go into detail here. A well-designed SCP platform must also have a reputable multi-signature partner of a decentralized bridge in practice.
**Someone may ask why SCP does not use a chain with smart contracts as the DA layer? **This allows a contract-based, completely trustless settlement layer.
In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on the DA layer with contracts such as Ethereum, and corresponding contracts for verification can be constructed, SCP can also obtain the same settlement security as Rollup. 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. **Only in this way can it be possible to support Web2-level throughput.
2.** 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, whose fraud proof is still not 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. thing.
Therefore, **Rollup is a solution that has better practical feasibility only under specific circumstances. **If you plan to implement a broader and more open solution, get rid of the EVM system and integrate more Web2 features, then Ethernet The idea of Fang Rollup is not suitable.
**SCP is not a certain public chain expansion plan, but a larger Web3 computing platform architecture, so it is obviously not necessary to follow the Ethereum Layer 2 idea. **
A picture comparing SCP and other paradigms
