This article provides a forward-looking introduction to a somewhat unconventional Web3 infrastructure design paradigm: the Storage-based Consensus Paradigm (SCP). This design model significantly diverges from mainstream modular blockchain solutions like Ethereum Rollups in theory. However, it demonstrates high feasibility in terms of simplicity in implementation and integration with Web2 platforms. SCP does not intend to limit itself to a narrow path of realization like Rollups. Instead, it aims to adopt a broader and more open framework to merge Web2 platforms with Web3 infrastructure. This approach can be seen as highly imaginative and innovative.

Let’s envision a public blockchain scaling solution with the following characteristics:

It has speeds comparable to traditional Web2 applications or exchanges, far surpassing any public blockchain, Layer 2 (L2), rollups, sidechains, etc.
There are no gas fees, and the usage cost is almost zero.
High financial security, surpassing centralized facilities like exchanges, inferior to Rollups but greater than or equal to sidechains.
A user experience identical to Web2, without requiring any knowledge of blockchain public and private keys, wallets, infrastructure, etc.

Such a solution is indeed very exciting: on one hand, it has essentially reached the pinnacle in terms of scaling; on the other hand, it lays a solid foundation for the mass adoption of Web3, essentially bridging the gap between the user experiences of Web2 and Web3. However, we seem to have few comprehensive solutions like this, as mainstream discussions and practices are indeed too few.

We use the well-known topic of scaling as an introduction above, but SCP is not limited to scaling use cases. Its design inspiration indeed comes from the scaling solutions and community discussions of public blockchains like Bitcoin and Ethereum. Its vision and practical application is to build a new generation of trustless infrastructure, even computational platforms not based on blockchain structures.

SCP Basic Components and Working Principles

Generally speaking, SCP, like the “modular blockchain” mentioned by the Ethereum and Celestia communities, has various modules such as a data availability layer, execution layer, consensus layer, and settlement layer.

Data Availability Layer: Handled by a widely recognized and well-tested public blockchain, or storage facilities serving as the data availability layer, like Ethereum, Arweave, Celestia, etc.
Execution Layer: A server, used to receive user transactions and execute them, while also batch submitting the signed transaction data to the DA layer, similar to the sequencers in Rollups. However, the execution layer doesn’t necessarily need a blockchain-style chain structure; it can be entirely a Web2 database + computing system, but the entire computing system must be open source, with transparency.
Consensus Layer: Composed of a group of nodes that pull data submitted to the DA layer by the execution layer and use the same algorithm as the execution layer to process this data, confirming whether the output of the execution layer is correct and can serve as a disaster recovery redundancy for the execution layer. Users can also read data returned by the consensus layer nodes to ensure there’s no fraudulent behavior in the execution layer.
Settlement Layer: Composed of a group of nodes and contracts or addresses on other chains, responsible for handling user deposits into SCP, or withdrawals from SCP, somewhat similar to the operation of cross-chain bridges. The settlement layer nodes control the withdrawal function of the deposit address through multisig contracts or TSS-based addresses. For deposits, users transfer assets to a designated address on their chain; for withdrawals, they send a request, and after the settlement layer nodes read the data, they release the assets through multisig or TSS. The security level of the settlement layer depends on the cross-chain mechanism used.

SCP Practice Framework

We can understand the SCP paradigm through the following framework. A product that meets the SCP framework can have main features like deposit, transfer, withdrawal, swap, etc., and can be further expanded upon. Below is a schematic diagram of such a product:

The DA layer of this project uses the permanent storage facility Arweave, represented by the large circle in the diagram.
The Coordinator, or the execution layer, is where users submit their transactions. The Coordinator executes calculations, displays the results, and then batches the original input data from users and submits it to the DA layer.
The Detector pulls the original transaction data submitted by the Coordinator from Arweave, and using the same algorithm as the Coordinator, validates the data and results. The client of the Detector is also open source, allowing anyone to run it.
The Watchmen, a group of Detectors, manage the multi-signature system of the withdrawal system. They validate and authorize withdrawal requests based on transaction data. Additionally, the Watchmen are responsible for signing proposals.

We can see that the consensus achieved by the entire system is entirely off-chain, which is the core of the storage consensus paradigm. It abandons the node consensus system typical of blockchains, freeing the execution layer from the burdensome consensus communication and confirmation process. This allows it to function efficiently as a single server, thereby achieving nearly unlimited TPS and cost-effectiveness. This aspect is very similar to Rollups, but SCP (Storage Consensus Paradigm) takes a different path than Rollups. SCP attempts to transition from a scaling-specific use case to a new transitional mode from Web2 to Web3. The aforementioned Coordinator is a server, but this does not mean that the Coordinator can act arbitrarily. Similar to the sequencer in Rollups, after batch submitting the original data from users on Arweave, anyone can run the Detector program to verify it and compare it with the state returned by the Coordinator. In some ways, this is akin to the approach of inscription-type applications. In this architecture, a centralized server or database does not pose a fundamental challenge. This is another point of the SCP paradigm: it decouples the concepts of “centralization” and “single entity” — in a trustless system, there can be centralized components, even a core component, without affecting the overall trustlessness of the system.

We can shout out this slogan: “The next generation of trustless infrastructure doesn’t necessarily have to rely on consensus protocols, but it should be an open-source system with a Peer-to-Peer (P2P) node network.” The original intention of inventing and using blockchain was to achieve decentralization, ledger consistency, immutability, and traceability, as explicitly stated in the Bitcoin whitepaper. However, post-Ethereum, whether it’s the old public chain’s expansion solutions, Rollups, or modular blockchains, there’s been a fixed mindset: what we’re creating must either be a blockchain (comprised of nodes’ consensus protocols) or something like Rollup (which appears to be a chain with blockchain data structures, but without direct consensus message exchanges between nodes). Now, under the framework based on SCP (Stellar Consensus Protocol), it’s evident that even without being a blockchain, it’s possible to achieve decentralization, ledger consistency, immutability, and traceability, provided there are more explicit implementation details.

Execution Layer

The execution layer is crucial in the entire system as it undertakes the system’s computational processes and determines the types of applications that can run on the system.

Infinite Possibilities in the Execution Environment

Theoretically, the execution environment in the execution layer can take any form, with endless possibilities, depending on how the project’s developers position their project:

Exchanges. Using SCP, one can build a public, transparent exchange with high Transaction Per Second (TPS) rates, combining the rapid, zero-cost features of a Centralized Exchange (CEX) and the decentralization of a Decentralized Exchange (DEX). Here, the distinction between CEX and DEX becomes blurred.
Payment Networks. Similar to Alipay, PayPal, etc.
Virtual Machines/Blockchains Supporting Loadable Programs/Contracts. Any developer can deploy any application on it, sharing all user data with other programs and operating according to user instructions.

SCP’s design pattern, which supports any execution environment, has its unique advantages: there’s no need to rely on components with historical baggage, especially concepts like the “account abstraction” unique to the Ethereum community. For SCP, the concept of account abstraction is inherently unnecessary. In the SCP architecture, there is no concept of account abstraction—you can freely adopt Web2 standard accounts and blockchain accounts, etc. From this perspective, many mature Web2 use cases don’t need to be rethought and rebuilt to be directly applicable to SCP. This aspect might be where SCP has an advantage over Rollups.

Transparency and Asymmetry

The account system was mentioned above, and perceptive readers might have noticed that while the SCP (Stellar Consensus Protocol) can utilize the Web2 account system, using it as is appears problematic. This is because the entire system is completely transparent! Directly employing the user-server interaction model from Web2 leads to serious security issues, rendering the system utterly insecure. Let’s review how the traditional server-user model works:

Account Registration : Users enter a username and password on the application’s registration page. To protect the user’s password, the server processes it through a hash function upon receipt. To increase the complexity of the hash and to defend against rainbow table attacks, a randomly generated string (known as a “salt”) is usually appended to each user’s password before hashing. The username, salt, and hash are stored in plaintext in the service provider’s database and are not made public. However, even so, salting and secure processing are necessary to prevent insider threats and attacks.

User Login : Users input their username and password on the login form. The system compares the processed password hash with the stored hash in the database. If the two hashes match, it indicates that the user has provided the correct password, and the login process proceeds.
Operation Authentication : After successful login verification, the system creates 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 app. During subsequent operations, users no longer need to repeatedly enter their username and password: the browser or app saves the cookie identifier and includes it in every request, indicating that they have the server’s permission associated with the cookie.

Let’s review the typical Web3 blockchain-user interaction system:

Account Registration: In reality, there is no account registration process, nor a username-password system. Accounts (addresses) do not need to be registered; they inherently exist, and whoever controls the private key controls the account. The private key is randomly generated locally by the wallet and does not involve an online process.
User Login: Using the blockchain does not require logging in. Most dApps do not have a login process but connect to a wallet instead. Some dApps, after connecting to a wallet, may require users to sign a verification to ensure they actually hold the private key, rather than just having submitted a wallet address to the frontend.
Operation Authentication: Users directly submit signed data to nodes. After validation, the nodes broadcast the transaction to the entire blockchain network. Once the operation is confirmed by the blockchain network consensus, it is finalized.

The difference between these two modes is caused by symmetric and asymmetric factors. In a server-user architecture, both parties hold the same secret. In a blockchain-user architecture, only the user holds the secret. Although the execution layer of SCP (Smart Contract Platform) may not be a blockchain, all data needs to be synchronized to a publicly visible DA (Data Availability) layer. Therefore, the SCP’s login and operation verification methods must be asymmetric. However, to avoid cumbersome actions like managing private keys and using wallets, which might hinder widespread adoption due to a poor user experience, there’s a strong demand for traditional ID-password or OAuth third-party authentication logins in applications built on SCP. So, how do we combine the two? Due to the asymmetric nature of cryptography and zero-knowledge proofs, I envision two possible solutions:

If an ID-password system is desired, the password-saving module could be excluded from SCP, making it invisible to others. Internally, the SCP execution layer still uses the blockchain’s public-private key accounts and operational logic, with no registration or login. The user’s ID would actually correspond to a private key. This private key, of course, should not be stored by the project side. A feasible solution is to use 2-3 MPC (Multi-Party Computation) to solve the problem of centralized storage while not burdening the user with the use of a private key.
When relying on OAuth login, JWT (JSON Web Token) can be used as a means of identity authentication. This method is slightly more centralized than the above, as it essentially relies on third-party login services provided by Web2 giants for identity verification.
The first time a third-party login is used, the JWT fields representing user and service provider identities are registered in the system. In subsequent user operations, the operation command is treated as public input, while the JWT as a whole is a secret witness, using ZKP (Zero-Knowledge Proof) to verify each of the user’s transactions.
Each JWT has an expiration limit, and users will request a new JWT the next time they log in, so there’s no need for permanent storage. Additionally, this system relies on JWK (JSON Web Key), which can be understood as the public key provided by the giants for JWK verification. How JWK is decentralizedly input into the system and methods for future private key rotation are also worth exploring.

Regardless of the method used, both are more costly in terms of development and operation than traditional methods, but this is a necessary price to pay for decentralization. Of course, if the project does not consider extreme decentralization necessary, or has different milestones at different development stages, it’s possible to proceed without these designs, as decentralization is not black and white but exists in a grey area.

Privacy Issues

The transparency issues mentioned above not only affect the user interaction paradigm but also impact user data. User data is directly exposed. While this is not a problem in the blockchain, it is unacceptable in some applications. Therefore, developers can also build private transaction systems.

Fees

How the execution layer charges fees is another point of interest. Submitting data to the Data Availability (DA) layer also incurs costs, including the operation of its own servers. The primary purpose of charging gas fees in traditional blockchains is to prevent users from spamming the network with numerous redundant transactions, with transaction ordering based on gas fees being secondary. In Web2, similar concerns do not exist, only basic concepts like flooding and DDoS attacks. The execution layer can customize various charging strategies, such as being completely free or partially charged, or profit from other activities like Maximal Extractable Value (MEV), which is already very mature in sequencers, and market activities.

Censorship Resistance

The execution layer does not possess censorship resistance and can theoretically reject user transactions indefinitely. In Rollups, censorship resistance can be ensured by the mandatory aggregation function of the L1 contract, while sidechains or public chains are complete distributed blockchain networks, making censorship difficult. Currently, there is no clear solution to address the issue of censorship resistance, which is a problem in the SCP paradigm.

Consensus Layer

This layer consists of loosely connected nodes that do not actively form a network, so it is not strictly a consensus layer, but merely confirms the current state of the execution layer to the outside world (such as users). For example, if you doubt the operational status of these nodes, you can download their detector client, which runs the same program code as the coordinator. However, similar to Rollups, since data is submitted in batches, the state returned by the execution layer to users is always more up-to-date than that on the DA layer. This involves the issue of pre-confirmation: the execution layer provides users with pre-confirmation, soft finality results, as they have not yet been submitted to the DA layer; while the consensus layer provides hard finality. Users may not be particularly concerned about this, but for applications like cross-chain bridges, hard finality must be adhered to. For example, the deposit and withdrawal system of exchanges does not trust data broadcast off-chain by Rollup sequencers; they wait for this data to be on Ethereum before acceptance. Besides confirming results, the consensus layer also plays a crucial role as a disaster redundancy for the execution layer. If the execution layer permanently stops working or acts maliciously, theoretically any consensus layer can take over the work of the execution layer and accept user requests. If such a severe situation occurs, the community should choose stable and reliable nodes as the execution layer’s servers.

Settlement Layer

Since SCP is not Rollup, it cannot achieve trustless withdrawals like Rollup’s withdrawal settlement layer, which is based entirely on cryptography and smart contract code without manual intervention. The security level of SCP cross-chain bridges is the same as that of sidechain or third-party witness cross-chain bridges, which rely on authorized multi-signature managers to release assets, known as the witness mode.

Making the witness bridge as decentralized as possible is a topic of research for many cross-chain bridges. Due to space limitations, this will not be elaborated here. A well-designed SCP platform in practice must also have reputable decentralized bridge multi-signature partners. Some might ask why SCP doesn’t use a chain with smart contracts as the DA layer? This would allow for trustless settlement layers based on contracts. In the long run, overcoming some technical difficulties, if the DA layer is placed on Ethereum or other contract-enabled DA layers and corresponding verification contracts can be built, SCP can also achieve the same settlement security as Rollup, without the need for multi-signatures.

In practice, this may not be the best choice:

Ethereum is not specifically designed for data storage, and compared to blockchains dedicated solely to data storage, it is quite expensive. For the SCP paradigm, a sufficiently low or fixed storage cost is crucial. Only then can it support Web2-level throughput.
Developing proof systems is extremely difficult because, in SCP, one can simulate not only EVM (Ethereum Virtual Machine) but also implement any logic. Considering the current state of projects like Optimism, where their fraud proofs are still not launched, and the complexity of developing zkEVM (zero-knowledge Ethereum Virtual Machine), one can imagine the immense difficulty in implementing various proof systems on Ethereum.

Therefore, the Rollup solution is only more practically viable in specific circumstances. If you plan to implement a broader, more open system, moving away from the EVM framework to integrate more Web2 features, then Ethereum Rollup’s approach is not suitable. SCP is not just an expansion plan for a certain public blockchain, but a larger Web3 computing platform architecture. Therefore, it clearly does not need to follow the Ethereum Layer2 approach.

An illustration compares SCP with other paradigms

Disclaimer：

This article is reprinted from [极客Web3]. All copyrights belong to the original author [雾月，极客Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.

Start Now

$100

Voucher!

Create Account

Interpreting SCP: A Paradigm Shift in Trustless Infrastructure Beyond Rollup