Storage Consensus Paradigm: Next-Generation Blockchains Don't Have to Be Blockchains

Author: Misty Moon

Imagine a public chain scaling solution with the following characteristics:

• Speed comparable to traditional Web2 applications or exchanges, far exceeding any public chain, L2, rollup, side chain, etc.
• No gas fees, with a usage cost of zero.
• High capital security, far exceeding centralized facilities like exchanges, inferior to Rollup but equal to side chains.
• User experience identical to Web2, requiring no understanding of blockchain public/private keys, wallets, infrastructure, etc.

Such a solution is indeed very exciting: on one hand, it has essentially achieved the ultimate in scaling; on the other hand, it lays a solid foundation for the mass adoption of Web3, essentially eliminating the gap in user experience between Web2 and Web3.

However, we currently seem unable to think of any solution that can achieve such completeness, as mainstream discussions and practices are indeed too few. This article will prospectively introduce this excellent and advanced next-generation Web3 computing platform design paradigm—Storage-based Consensus Paradigm (SCP).

We used the familiar topic of scaling as a lead-in, but in reality, SCP is not limited to scaling; its design inspiration indeed comes from the scaling solutions and community discussions of public chains like Bitcoin and Ethereum. Its vision and practical application are to build a new generation of public chains or non-blockchain structured computing platforms.

Basic Components and Working Principles of SCP

• Data Availability Layer: A widely recognized and time-tested public chain or permanent storage facility as the data availability layer, such as Ethereum, Arweave, etc.
• Execution Layer: A server used to receive user transactions and execute them, while batch submitting the raw transaction data signed by users to the DA layer, which is highly similar to Rollup's sequencer. However, this execution layer does not necessarily need to have blockchain data structures or blockchain-related concepts like EVM compatibility. It can also be a completely Web2 database + computing system, but the entire computing system must be open source.
• Consensus Confirmation Layer: Composed of a group of nodes that pull the raw data submitted by the execution layer to the DA layer and perform calculations on this data using the same algorithm as the execution layer to confirm whether the output of the execution layer is correct, and can serve as disaster redundancy for the execution layer. Users can also return data from various nodes in the consensus confirmation layer to ensure that the execution layer has not committed fraud.
• Settlement Layer: Composed of a group of nodes and contracts or addresses on other chains, used for users to deposit into and withdraw from SCP. Nodes also need to run the same algorithms as the execution layer and pull data for verification. Nodes control the withdrawal function of the deposit address through multi-signature contracts or TSS-based addresses. When depositing, users deposit to a designated address on the chain, and when withdrawing, they send a request to the execution layer. After the nodes in the settlement layer read the data from the DA layer, they perform multi-signature or TSS to release the assets. The security level of the settlement layer is the same as that of side chains or cross-chain bridges, which also use the same or equivalent withdrawal settlement systems.

everPay

everPay is a pioneer of SCP, having built its own product based on SCP. Currently, everPay's main functions include deposits, transfers, withdrawals, and swaps, and on this basis, it can almost expand into any Web3 and Web2 functionality in the future.

Now let's fully understand the Storage-based Consensus Paradigm through the workflow of everPay.

• The DA layer of everPay uses the permanent storage facility Arweave, represented by the large circle in the diagram.
• Coordinator, i.e., the execution layer. Users submit transactions to the coordinator, which performs calculations and presents the results, then batch submits the user's raw input data to the DA layer.
• Detector, which pulls the raw transaction data submitted by the coordinator from Arweave and uses the same algorithm as the coordinator to verify the data and results. The client's detector is also open source, and anyone can run it.
• Watchmen, a group of detectors that manage the multi-signature of the withdrawal system. They verify and release 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 essence of the Storage-based Consensus Paradigm— it discards the consensus system between nodes typical of blockchains, allowing the execution layer to avoid the burdensome consensus communication and confirmation process, only needing to perform the work of a single server, thus achieving nearly unlimited TPS and economic efficiency. This is very similar to Rollup, but SCP can be said to have abstracted and elevated the concept of Rollup, transforming it from a scaling-specific use case into a design paradigm for the next-generation Web3 computing platform.

The coordinator of everPay is a single server, but this does not mean the coordinator can act arbitrarily. Similar to the sequencer of Rollup, after batch submitting the raw data submitted by users to Arweave, anyone can run the detector program to verify it and compare it with the status returned by the coordinator. This is because the state transition function (STF) is a deterministic function: input ---> STF ---> output. As long as everyone's STF is the same and the input is the same (all submitted to DA, immutable, and publicly visible), the output must be the same.

In this architecture, a centralized server or database does not pose a fundamental challenge. This is another essence of the SCP paradigm, decoupling the concepts of "centralization" and "single entity"—in a decentralized system, it is entirely possible to have centralized components, even a core component, without affecting the overall decentralization.

Thus, we can shout a sensational yet logical slogan—"The next generation of blockchain does not have to be a blockchain." Because the original intention of inventing and using blockchain is decentralization, ledger consistency, immutability, traceability, and other basic principles, whether it is the scaling solution of old public chains or a brand new public chain, people have formed a certain mindset: what we create must be a blockchain (composed of consensus through node communication) or a solution like Rollup that appears to be a chain (only having the data structure of a blockchain but lacking node consensus communication). However, it seems that solutions based on SCP can meet a series of requirements such as centralization, ledger consistency, immutability, and traceability even if they are not blockchains.

Execution Layer

The execution layer is crucial in the entire system, bearing the throughput and computation of the entire system, and determining what applications can run on the entire system.

Infinite Possibilities of Execution Environment

Theoretically, the execution environment in the execution layer can take any form, with endless possibilities, depending on how the project team positions their project:

• Exchanges. Based on SCP, a public, transparent, and infinitely TPS exchange can be built, which can have the speed and zero cost characteristics of CEX while maintaining the decentralization of DEX. The distinction between CEX and DEX becomes blurred here.
• Payment networks. Similar to Alipay, PayPal, etc.
• Virtual machines/blockchains that support loading programs/contracts. Any developer can deploy any application on it, sharing all user data with other programs and operating based on user instructions.

Since users are completely free from the blockchain form of wallets and only interact with the server, their user experience is consistent with traditional internet applications, while also being decentralized.

It can be seen that the above process already includes concepts like cross-chain swaps and account abstraction. Of course, these are merely similar concepts, and we are only understanding them in the context of SCP. Especially for concepts like account abstraction, they are inherently unnecessary for SCP; this should be regarded as a burden left by Ethereum. The Ethereum community has gone through many rounds of efforts and finally introduced the EIP-4337 standard to address one of the issues of large-scale adoption of Web3—the account issue. Moreover, EIP-4337 is merely a standard, and its application practices still need to be tested. In the SCP architecture, the concept of account abstraction does not exist—users can freely adopt Web2 standard accounts and blockchain accounts. From this perspective, many mature Web2 use cases can be directly used on SCP without rethinking and rebuilding.

Transparency and Asymmetry

The aforementioned issue of accounts should make sensitive readers realize that although SCP can utilize the Web2 account system, using it unchanged seems problematic.

Because the entire system is completely transparent! Directly using the user-server interaction model would lead to serious issues, resulting in a complete lack of security for the entire system. Let's first review how the traditional server-user model works:

1. Account registration: Users enter a username and password on the application's registration page. To protect the user's password, the server processes the password using a hash function upon receipt. To increase the complexity of the hash and resist rainbow table attacks, a randomly generated string (called "salt") is usually appended to each user's password for hashing. The username, salt, and hash are stored in plaintext in the service provider's database and are not publicly visible. However, even so, salting and security measures are necessary to prevent insider threats and attacks.
2. User login: Users enter their username and password on the login form. The system compares the processed password hash with the hash stored in the database. If the two hashes match, it indicates that the user has provided the correct password, and the login process continues.
3. 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 application. The user does not need to re-enter their username and password for subsequent operations: the browser or application saves the identifier and includes it with each request.

Now let's review the typical Web3 blockchain-user interaction system:

1. Account registration: In fact, there is no account registration process, nor is there a username-password system. Accounts (addresses) do not need to be registered; they naturally exist, and whoever holds the private key controls the account. The private key is randomly generated by the wallet locally and does not involve any online process.
2. User login: Using the blockchain does not require logging in; most dApps do not have a login process but instead connect wallets. Some dApps may require users to sign to verify the identity of the connected wallet after connecting, ensuring that the user indeed holds the private key of that wallet and has not merely passed a wallet address to the front end.
3. Operation authentication: Users directly submit signed data to nodes, which verify it and broadcast the transaction to the entire blockchain network. Once the blockchain network reaches consensus, the user's operation is confirmed.

The differences between the two modes arise from symmetry and asymmetry. In the server-user architecture, both parties hold the same secret. In the 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, so the login and operation verification methods used by SCP must be asymmetric. However, since we do not want to burden users with managing private keys and using wallets, which negatively impacts mass adoption, there is also a strong demand for applications built on SCP to use traditional ID-password or OAuth third-party authentication login. So how can we combine the two?

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

• If you want to use the ID-password system, you can keep the module that saves passwords out of SCP, making it invisible to others. The internal execution layer of SCP still uses blockchain public/private key accounts and operation logic, with no registration or login. The user's ID will correspond to a private key. This private key should not be stored by the project team; a more feasible solution is to use 2-3 MPC to solve the problem of centralized storage while avoiding the burden of using private keys for users.
• When relying on OAuth login, JWT (Json Web Token) can be used as a means of identity authentication. This method may appear slightly more centralized than the above because it essentially relies on third-party login services provided by Web2 giants for identity authentication. When using third-party login for the first time, the fields representing user identity and service provider identity in the JWT are registered in the system. In subsequent operations, the operation instructions are treated as public input, while the entire JWT serves as a secret witness, using ZKP to verify each user transaction. Each JWT has an expiration limit, and users will apply for a new JWT the next time they log in, so there is no need to manage it. Additionally, this system relies on JWK, which can be understood as the public key provided by the big companies for verifying JWK. How to decentralize the input of JWK into the system and methods for handling private key rotation in the future are also worth exploring.

Regardless of which method is used, this will incur higher development and operational costs than traditional methods, but this is a necessary price for decentralization. Of course, if the project team does not believe that achieving extreme decentralization is necessary, or if there are different milestones at different stages of development, these designs can be omitted, as decentralization is not black and white but exists in a gray area.

Privacy

The transparency issue mentioned above not only affects the user interaction paradigm but also impacts user data. User data is directly exposed. While this is not a problem in blockchain, it may be unacceptable in certain applications, so developers can also build privacy transaction systems.

Charging

How the execution layer charges is another point worth noting. Submitting data to the DA layer also incurs costs, including the operation of its own server, etc. The primary core purpose of traditional blockchains charging users gas fees is to prevent users from flooding the network with a large number of duplicate transactions, and the second is to sort transactions based on gas. Web2 does not have similar concerns, so it only addresses basic concepts like floods and DDoS.

The execution layer can customize various charging strategies, such as being completely free or partially charged, and can also profit from other activities like MEV (which is already very mature in sequencers), market activities, etc.

Anti-Censorship

The execution layer does not possess anti-censorship capabilities and can theoretically refuse users' transactions without limits. In Rollup, anti-censorship can be guaranteed by the mandatory aggregation function of L1 contracts, while side chains or public chains are complete distributed blockchain networks, making censorship difficult.

Currently, there is no clear solution to rectify this issue, which is a problem of the SCP paradigm.

Consensus Confirmation Layer

This layer is composed of loosely connected nodes that do not actively form any network, so it is not a consensus layer; it is merely 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 status of everPay, you can download its detector client, which will run the same STF as the coordinator.

However, similar to Rollup, since the data is submitted in batches, the status returned to users by the execution layer is always more updated than that on the DA layer. This involves a soft and hard finality issue. The execution layer provides users with soft finality because it has not yet been submitted to the DA layer; while the consensus confirmation layer provides users with hard finality. Users may not be particularly concerned about this, but for applications like cross-chain bridges, hard finality must be followed. For example, the deposit and withdrawal system of exchanges will not rely on the instantaneous finality of Rollup sequencers.

In addition to confirming results, the consensus confirmation layer also plays a very important role as disaster redundancy for the execution layer. If the execution layer permanently malfunctions or severely misbehaves, theoretically any consensus confirmation layer can take over the work of the execution layer and receive user requests. If such a serious situation occurs, the community should choose stable and reliable nodes to serve as the execution layer's server.

Settlement Layer

Since SCP is not Rollup, it cannot achieve a trustless withdrawal based on mathematics and smart contract code without human intervention, like the withdrawal settlement layer of Rollup. Its security level is the same as that of side chains or cross-chain bridges, relying on authorized observers to release assets, which we call the witness model.

Making the witness bridge as decentralized as possible is a topic of much research in cross-chain bridges. Due to space limitations, we will not elaborate on it here. A well-designed SCP platform must also have reputable decentralized bridge multi-signature partners, such as everPay's deep cooperation with MPC service provider Safeheron.

Some may ask why SCP does not use a chain with smart contracts as the DA layer? This could create a trustless settlement layer for contracts.

In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on Ethereum or other contract-enabled DA layers and corresponding contracts for verification can be constructed, SCP can achieve the same settlement security as Rollup without needing multi-signature.

However, in practice, this may not be the optimal choice:

1. Ethereum is not specifically designed for data storage, and its costs are too high compared to purely data storage public chains. For the SCP paradigm, having sufficiently low or fixed storage costs is crucial.
2. Developing a proof system is very challenging because SCP can not only simulate EVM but can implement any logic. Looking at large teams like Optimism, which still have not launched their fraud proofs, and the difficulty of developing zkEVM, it can be imagined that implementing various systems' proofs on Ethereum is extremely challenging.

Another key point is that this so-called settlement security equivalent to Rollup only applies to the chain itself with smart contracts, such as Ethereum, because the original data is entirely transmitted to Ethereum. Therefore, only the settlement contract on Ethereum can "reference" the original input data to prove the correctness of the final state (note that it is not a direct reference but an indirect one through hashes or accumulators, leaving a state marker for the original calldata, as historical transaction calldata itself cannot be referenced by contracts). However, for other chains, they cannot enjoy the same level of security because they do not have any data on them. If cross-chain transactions are to be made to other chains, the witness model cross-chain bridge must still be used.

Thus, the Rollup solution only has superior settlement security from a specific perspective, namely when you view one chain as your parent chain. SCP is not a scaling solution for a specific public chain but a larger Web3 computing platform architecture, so it does not necessarily need to be implemented from a certain chain-centric perspective. Establishing the settlement layer on smart contracts cannot guarantee the settlement security of other chains besides the parent chain, making it completely unreasonable if you are not specifically expanding this chain.

Conclusion

A diagram comparing SCP with other paradigms.

SCP is a brand new Web3 computing platform paradigm, comparable to the speed of traditional Web2 trading applications, with negligible transaction costs, capable of building infinitely possible applications, and maintaining security consistent with mainstream solutions. Currently, a batch of applications such as everPay, PermaSwap, Mind Network, etc., have emerged under the SCP paradigm, and based on its excellent design philosophy, it is very likely to experience explosive growth in this and the next bull market.