Interpreting SCP: Trustless Infrastructure Paradigm Outside the Rollup Formula

Author: Wuyue, Geek Web3

**Introduction:**This article will prospectively introduce a Web3 infrastructure design paradigm that looks a bit maverick - 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, but in the simplicity of landing and the difficulty of connecting with the Web2 platform, the feasibility is very high Because he didn’t intend to limit himself to a narrow implementation path like Rollup from the beginning, he wanted to use a broader and more open framework to merge the Web2 platform with the Web3 infrastructure, which can be said to be a brain-opening and imaginative approach. Introduction: This article will prospectively introduce a somewhat maverick Web3 infrastructure design paradigm - Storage 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 simplicity 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 platform and Web3 facilities with 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 traditional Web2 applications or exchanges, far exceeding any public chain, L2, rollup, sidechain, etc.
• There is no gas fee, and the cost of use is almost zero.
• High security of funds, far beyond centralized facilities such as exchanges, inferior to Rollup but greater than or equal to Sidechain.
• Same user experience as Web2, without any knowledge of the Blockchain’s public and private keys, wallets, infrastructure, etc.

This solution is indeed very exciting: on the one hand, it has basically achieved the ultimate in scaling, and on the other hand, it has laid a solid foundation on Web3’s mass adoption, basically eliminating the gap between Web2 and Web3 experience.

However, we can’t seem to think of many solutions that can be so complete, because there is really too little mainstream discussion and practice.

We used the very familiar topic of scaling as an introduction above, in fact, **SCP is not limited to scaling, **its design inspiration does come from Bitcoin, Ethereum and other public chain scaling solutions and community discussions. Its vision and practical application is to build a new generation of Trustless infrastructure and even a computing platform with a non-Blockchain structure. **

SCP basic components and how they work

Generally speaking, SCP is also like what the Ethereum and Celestia communities call a “modular Blockchain”, with a data availability layer, an execution layer, a consensus layer, a Settlement layer and other modules.

Data availability layer: Undertaken by a widely recognized and proven public chain, or storage facilities as a data availability layer, such as Ethereum, Arweave, Celestia, etc. Execution Layer: A server that receives and executes user transactions, and submits the transaction data signed by users to the DA layer in batches, similar to Rollup’s sequencer. However, the execution layer does not have to 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 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: consists of a group of nodes and other contracts or addresses on the chain, which is used to process the behavior of users depositing into SCP or withdrawing out from SCP, somewhat similar to the operation mode of cross-chain interaction bridges. 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 specified Address of the chain, 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 interaction mechanism adopted.

SCP’s framework of practice

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 diagram of such a product:

• The DA layer of the project uses the permanent storage facility Arweave, which is the large circle in the diagram. Coordinator, i.e., 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, which pulls the raw transaction data submitted by the coordinator from Arweave and validates the data and results using a Algorithm consistent with the coordinator. The detector client is also open source and can be run by anyone.
• **Watchmen, a group of detectors who are in charge of the multi-signature of 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 achieve is all off-chain, which is the core of the storage Consensus paradigm - it abandons the Blockchain-style NodeConsensus system, and allows the execution layer to get rid of the heavy Consensus communication and confirmation process, and only need 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 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 a core component, but this does not affect the overall trustless.

We can shout 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 to invent and use Blockchain is to Trustless, the ledger is consistent, non-forgeable, traceable and other clichéd fundamentals, which are clearly stated in the BitcoinWhite Paper. But after Ethereum, whether it is the scaling scheme of the old public chain, or Rollup or modular Blockchain, everyone has formed a mindset: what we do must be a Blockchain (consisting of the Node’s Consensus Protocol), or Rollup, which seems to be a chain solution (only there is a Blockchain data structure, but the Node does not have a direct Consensus message exchange).

But now, based on the framework of SCP, even if it is not a Blockchain, a series of requirements such as trustless, consistent ledger, non-forge, traceability, etc. 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.

Infinite Possible Execution Environment

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 have the characteristics of CEX speed and zero cost, while maintaining the decentralization of DEX. The distinction between CEXs and DEXs becomes blurred here.

• Payment Network. Similar to Alipay, PayPal, etc.
• Support for virtual machines/Blockchain loaders/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 benefits: it no longer has to rely on certain components with historical baggage, especially the concept of “account abstraction” created by the Ethereum community, which is inherently undesirable for SCP.

Under the SCP architecture, there is no concept of account abstraction - you can freely adopt Web2 standard accounts and Blockchain accounts. 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 SCPs over Rollups. **

Transparency & 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 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. 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 connected to a randomly generated string of strings (called “salts”) and hashed together. **Usernames, salts, hashes are stored in plaintext in the service provider’s database 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 (e.g., 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 identifier and attaches an identifier to each request, indicating that they have permission from the associated server.

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. The account (address) does not require registration, it exists naturally, and whoever holds its 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 the Blockchain does not require a 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 WalletAddress 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 meeting 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 the Blockchain-User architecture, only the user holds the secrets.

Although the execution layer of SCP can not be a Blockchain, all data needs to be synchronized to the publicly visible DA layer, so the authentication method of login and operation used by SCP 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 private keys and use wallets, applications built on SCP also have a strong need to use traditional ID passwords or OAuth three-party authentication logins, so how to combine the two?

Due to the asymmetric nature of asymmetric cryptography and zero-knowledge proof pairs, 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, without registration, login, etc. The user’s ID actually corresponds to a private key. **Of course, this private key cannot be kept on the project side, and the more feasible solution is to use 2-3 MPC to solve the problem of centralized storage, while not allowing users to use the private key. When relying on OAuth login, JWT (Json Web Token) can be used as a means 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.

• When you log in with a third party for the first time, register the fields in the JWT that represent the identity of the user and the identity of the service provider 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 users will apply for a new JWT the next time they log in, 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 large factory to verify JWK. So how to input JWK Decentralization into the system, and how to deal with private key rotation in the future, are also worth exploring.

Either way, it is more expensive to develop and compute than traditional methods, but it is also a necessary price to pay for decentralization. **Of course, if the project team does not believe that the ultimate Decentralization is necessary, or there are different milestones at different stages of development, it is okay to have 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. Although this is not a problem in Blockchain, it is not very acceptable in some applications, so developers can also build private transaction systems.

Charge

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 Blockchain to charge users gas fees is to avoid users from swiping a large number of repetitive 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 partial charging, and can also monetize other behaviors such as MEV (which is very mature in the sequencer), marketing activities, etc.

Censorship Resistance

The execution layer is not censorship-resistant, and can theoretically reject users’ transactions indefinitely. In Rollup, censorship resistance can be guaranteed 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 censorship resistance problem, which is a problem with the SCP paradigm. **

Consensus Layer

This layer is made up of loose Node, and these Node 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 health status 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 issue:

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;

** The Consensus layer provides users with hard finality. Users may not particularly care about this, but for applications such as cross-chain interaction 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 this 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, at this time, 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 as the server for the execution layer.

Settlement Layer

Since SCP is not a Rollup, it cannot achieve Trustless withdrawals based entirely on Cryptography and Smart Contract code without human intervention like Rollup’s withdrawal settlement layer. SCP Cross-Chain Interaction Bridges are the same as Sidechain or Third-Party Witness Cross-Chain Interaction Bridges, and need to rely on authorized multi-signature managers to release assets, which we call the witness model.

Decentralization of the witness bridge as much as possible is the subject of many cross-chain interaction studies. Due to space limitations, I will not expand on it here. A well-designed SCP platform must also have reputable Decentralization Bridge multisig partners in practice.

One might ask why SCP doesn’t use chains with smart contracts as a DA layer? This can make a settlement layer that gives contracts and is completely trustless.

In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on 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.

But in practice this is not necessarily optimal:**

1. Ethereum is not specifically used for data preservation, 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 Web2-level throughput be supported.

2. Prove 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 are still not online for fraud proofs, and the difficulty of zkEVM development, we can imagine that it is extremely difficult to implement the proofs of various systems on Ethereum.

Therefore, the Rollup solution is only better practical in specific situations, and if you plan to implement a broader and more open approach that moves away from the EVM system and into more Web2 features, the idea of Ethereum Rollup is not appropriate.

**SCP is not a public chain scaling scheme, 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 to Other Paradigms