Interpretation of SCP: A trustless infrastructure paradigm that breaks out of the Rollup stereotype

Introduction:This article will prospectively introduce a Web3 infrastructure design paradigm that seems a bit unique—Storage Consensus Paradigm SCP (Storage-based Consensus Paradigm)Although this product design model is theoretically quite different from mainstream modular blockchain solutions such as Ethereum Rollup, it is not as easy to implement as it is compatible with In terms of the difficulty of connecting to the Web2 platform, the feasibility is very high, because from the beginning he did not intend to limit himself to a narrow implementation path like Rollup, but wanted to use a broader and more comprehensive approach. The open framework Integrating the Web2 platform with Web3 facilities can be said to be a very creative and 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 plan is indeed very exciting: on the one hand, it has basically done the expansion On the other hand, it has also laid a 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 the issue of expansion, which is very familiar to everyone, as an introduction. In fact,SCP is not limited to expansion. Its design inspiration It does come from the expansion plans and community discussions of public chains such as Bitcoin and Ethereum. Andits vision and practical application is to build a new generation of trustless infrastructure, even a non-blockchain structured computing platform.

SCP basic components and working principles

Generally speaking,SCP is also like what the Ethereum and Celestia communities call a "modular blockchain",with module divisions such as data availability layer, execution layer, consensus layer, and settlement layer.

• Data availability layer: consists of Widely recognized and time-tested public chains can be used as the responsibility, or storage facilities can be used as the data availability layer, such as Ethereum, Arweave, Celestia, etc.

• Execution layer:A server for receiving user transactions And execute, while submitting 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 consists of a group of nodes that pull and execute The DA layer submits data to the DA layer, and uses 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 it 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 consists of a group of nodes and contracts on other chains Or address composition, used to handle the behavior of users recharging into SCP, or withdrawing money from SCP, which is somewhat similar to the operation mode of 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 recharges 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 Practical 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 following picture is a schematic diagram of such a product:

• DA layer usage for this project The permanent storage facility Arweaveis installed, which is 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 Detector, pulls the coordinator submission from Arweave The original transaction data is used to verify 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 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 allows the execution layer to get rid of the heavy consensus communication and confirmation process, and only needs to do the work of a server. Yes, thus 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 the same idea as inscription applications.

Under this architecture, a centralized server and database do not pose a fundamental challenge. This is 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, even It can be a core component, 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. This is true in Bitcoin It is clearly stated in the 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 block Chain(composed of the consensus protocol of 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, it can also achieve trustlessness, ledger consistency, non-forgery, traceability, etc. Waiting for a series of requirements, of course, the premise is that there must be more clear implementation details.

Execution layer

The execution layer is in the entire system It is crucial, it undertakes the computing process of the entire system, and also determines what applications can be run on the system.

Infinitely possible execution environments

Theoretical execution layer The execution environment in can be made into any shape, and the possibilities are endless, depending on how the project party positions its project:

< li>

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.

• Supports 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 pattern that supports arbitrary execution environments, has its own unique features Benefits:No need to rely on certain components with historical baggage, especially the concept of "account abstraction" unique to the Ethereum community, which is inherently unnecessary for SCP.

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 is mentioned above. Sensitive readers should have discovered that SCP Although the Web2 account system can be used, there seems to be a problem 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 their username and password on the application's registration page. 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"). Usernames, salts, and hashes are stored in clear text in the service provider’s database and are not made 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 verification 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 the user name and password in the next operation: The browser or application will save the cookie identifier, and attach it to each request to indicate that it has obtained the cookie associated with the server. license.

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 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, and the node will broadcast it to the entire blockchain network after verification. The user's operation will be confirmed after the transaction meets the consensus of the blockchain network.

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 SCP uses The authentication method for login and operation 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. Strong, so how to combine the two?

Due to the asymmetry between asymmetric cryptography and zero-knowledge proofs, I imagined two possible solutions:

• If you want to use the ID-password system, you can use this module to save passwords Do not enter the SCP so that others cannot see it. 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, you can use JWT (Json Web Token) as Identity 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 manufacturers for identity authentication.

  When using a third-party to log in for the first time, the user's identity and identity will be represented in the JWT The field of service provider identity is registered 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 when he logs in next time, 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 operation costs are higher than the traditional method, but This is also the 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 affects the user's interaction paradigm, but also affects 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.

Charging

How the execution layer charges is another worthwhile Point of concern. Because submitting data to the DA layer also requires costs, including the operation of its own server. The first core purpose of traditional blockchains to charge gas fees to users 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 it only has 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 choose from other behaviors such as MEV (very mature in sorters), market events, etc. to monetize.

Censorship resistance

The execution layer is not censorship resistant sex, and can theoretically refuse 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.

Currently there is no clear solution to solve the problem of censorship resistance, which is a problem of the SCP paradigm.

Consensus layer

This layer is It is composed of loose nodes. These nodes do not actively form a network, so they are not a consensus layer in a strict sense, but are 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 code.

However, this is similar to Rollup. Since the 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-confirmation and soft-final results,because It has 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, that is, as a disaster prevention redundancy for the execution layer. If the execution layer goes on permanent 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 is impossible to achieve trustless withdrawals that do not require manual intervention and are completely based on cryptography and smart contract codes 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 details here. A well-designed SCP platform must also have reputable multi-signature partners on the 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 users can be built For verified contracts, SCP can also obtain the same settlement security as Rollup without the need to use multi-signature.

But in practice this may not be the best choice:

1. Ethereum is not specifically used for data storage, and the price is too high compared to a pure data storage public chain. Andfor 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. Looking at the fact that teams like Optimism currently have no fraud proof online, and the development difficulty of zkEVM, we can imagine that it is extremely difficult to implement proof of various systems on Ethereum. one thing.

So Rollup is more practical and feasible only under specific circumstances. If you plan to implement a If it is broader and more open, getting rid of the EVM system and integrating more Web2 features, the idea of ​​​​Ethereum Rollup is not suitable.

SCP is not some kind of public chain expansion plan, but a larger Web3 computing platform architecture, so there is obviously no need to go to Ethereum Layer2 ideas.

A picture comparing SCP with other paradigms