Source: Wuyue, Geek Web3
Imagine a public chain expansion solution with the following characteristics:
There is no Gas fee and the usage cost is 0.
The security of funds is high, far exceeding that of centralized facilities such as exchanges, inferior to Rollup but 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 solid foundation for mass adoption of Web3. The foundation basically eliminates the gap between Web2 and Web3 usage experience.
However, at present, we seem to be unable to think of any solution that can be so complete, because there is indeed too little mainstream discussion and practice. This article will prospectively introduce this very excellent and advanced next-generation Web3 computing platform design paradigm - Storage-based Consensus Paradigm (SCP).
We used the issue of expansion, which is very familiar to everyone, as an introduction above, but in fact, SCP is not limited to expansion use, and its design inspiration does come from Discussions with the community on expansion plans for public chains such as Bitcoin and Ethereum. Its vision and practical application is to build a new generation of public chain or non-blockchain structured computing platform.
Data availability layer: A widely recognized and proven public chain or permanent storage facility serves as the data availability layer, such as Ethereum, Arweave et al.
Execution layer: A server is used to receive user transactions and execute them, and at the same time, the user's signed The original transaction data is submitted to the DA layer in batches, which is highly similar to Rollup's sorter. However, this execution layer does not necessarily need to have blockchain data structures, or blockchain-related concepts such as EVM compatibility. It can also be completely a Web2 database + computing system, but the entire computing system must be open source.
Consensus confirmation layer: It is composed of a group of nodes that pull the execution layer and submit it to the DA layer. Original data, and use the same algorithm of 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 of the execution layer. Users can also use the data returned from each node in the consensus confirmation 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, used for user recharges Entering the SCP and withdrawing money from the SCP. Nodes also need to run the same algorithm in the execution layer and pull data for verification. Nodes control the withdrawal function of the deposit address through multi-sign contracts or TSS-based addresses. When recharging, the user recharges to the specified address in the chain, and when withdrawing, sends a request to the execution layer. After the settlement layer node reads the data of the DA layer, it performs multi-signature or TSS to release the assets. The security level of the settlement layer is the same as the cross-chain mechanism of the side chain or cross-chain bridge, and they also use the same or equivalent withdrawal settlement system.
everPay is the pioneer of SCP and has taken the lead in building its own products based on SCP. Currently The main functions of everPay are recharge, transfer, withdrawal, and swap. On this basis, almost any Web3 and Web2 functions can be expanded in the future.
Now we can fully understand the storage consensus paradigm through everPay’s workflow.
everPay’s DA layer uses permanent The storage facility Arweave is the large circle in the picture.
Coordinator is 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 same algorithm as 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 that the consensus reached by the entire system is all off-chain. This is the essence of the storage consensus paradigm - it abandons blocks The chain-type consensus system between nodes allows the execution layer to get rid of the heavy consensus communication and confirmation process, and only needs to do the work of one server, thereby achieving almost unlimited TPS and economy. This is very similar to Rollup, but SCP can be said to have made the concept of Rollup more abstract and elevated, turning it from a use case exclusive for capacity expansion into the design paradigm of a new generation of Web3 computing platforms.
The coordinator of everPay 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. This itself is because the state transition function (STF) is a deterministic function, input —> STF —> output. As long as everyone has the same STF and the same input (all submitted to DA, cannot be tampered with, and publicly visible), then the output must be the same.
Under this architecture, a centralized server and database do not pose a fundamental challenge. This is also another essence of the SCP paradigm, which binds and decouples the two concepts of "centralization" and "single entity" - in a decentralized system, there can be centralized components, and even A core component, but this does not affect the overall decentralization.
From this we can shout a sensational but logical slogan - "The next generation of blockchain does not have to be a blockchain." Because the original intention of people inventing and using blockchain is the commonplace fundamentals such as decentralization, consistent ledgers, non-forgery, traceability, etc., so whether it is an expansion plan for an old public chain or a brand new public chain, everyone has formed A certain mindset: What we do must be a blockchain (consisting of consensus among nodes), or a solution like Rollup that looks like a chain (it just has the data structure of a blockchain, but no nodes. communication consensus). But looking at it now, even if the SCP-based solution is not a blockchain, it can still meet a series of requirements such as centralization, consistent ledgers, non-forgery, traceability, etc.
The execution layer is crucial in the entire system, it undertakes It determines the throughput and operation of the entire system, and also determines what kind of applications can be run on the entire system.
Infinitely possible execution environments
Theoretical execution The execution environment in the 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 unlimited 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 loader/contract. Any developer can deploy any application on it, share all user data with other programs and operate according to the user's instructions.
Because users completely get rid of the blockchain wallet and only interact with the server, its user experience is consistent with traditional Internet applications, but at the same time it goes Centralized.
You can see that the above process already includes similar concepts such as cross-chain swap and account abstraction. Of course, they are just similar. We only understand them in the context of SCP. In particular, concepts like account abstraction are naturally unnecessary for SCP. This should be said to be the baggage left by Ethereum. After many rounds of efforts, the Ethereum community finally launched the EIP-4337 standard to solve one of the problems with the large-scale adoption of Web3 - the account problem. Moreover, EIP-4337 is just a standard, and its application practice has yet to be tested. 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.
Transparency and Asymmetry
The account system is mentioned above. Sensitive readers should have discovered that although SCP can It uses Web2's account system, but 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 the entire system having no security at all. 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"). The username, salt, and hash 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 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 identifier (such as a cookie or token) to the user's browser or application. The user no longer needs to re-enter their username and password for subsequent operations: the browser or application saves the identifier and sends it with every request.
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. After connecting to the wallet, some dApps will require the user to perform signature verification on the identity of the connected wallet to ensure that the user actually holds the private key of the wallet, 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 is 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? What about combining 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 not build this password saving module into 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 manufacturers for identity authentication. When logging in using a third party for the first time, register the fields in the JWT that represent the user's identity and the service provider's 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 when he logs in next time, so there is no need to keep it. 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 not to have these designs, because decentralization is not black and white, but exists. The gray area in the middle.
Privacy
The transparency just mentioned above The problem not only affects the user's interaction paradigm, but also affects the user data. User data is directly exposed. Although not a problem in blockchain, this is less acceptable in some applications, so developers can also build private transaction systems.
Charging
How the execution 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 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 floods and DDoS.
The execution layer can customize various charging strategies, such as completely free or partially charged, and can also profit from other behaviors such as MEV (very mature in the sequencer), market activities, etc.
Resistance to censorship
The execution layer is not censorship-resistant and can theoretically reject user 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 correct this problem, which is a problem with the SCP paradigm.
This layer is composed of loose nodes. These nodes do not actively form any network, so they are not a consensus layer. They are just used To confirm the status of the current execution layer to the outside world (such as users). For example, if you have any doubts about everPay's operational status, you can download its detector client, which runs the same STF as the coordinator.
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 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 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 does not rely on the instant finality of the Rollup sequencer.
In addition to being used to confirm results, the consensus confirmation layer also plays an important role, which 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 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 a stable and reliable node as the execution layer server.
Since SCP is not a Rollup, it cannot achieve the same differences as the Rollup withdrawal settlement layer. Trustless withdrawals that require human intervention and are completely based on mathematics and smart contract code. Its level of security is the same as the cross-chain mechanism of side chains or cross-chain bridges. It relies on authorized observers to release assets, which we call the witness mode.
Make the Witness Bridge the best it can be Perhaps decentralization 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 a reputable decentralized bridge multi-signature partner in practice. For example, everPay has in-depth cooperation with MPC service provider Safeheron.
Someone may ask why SCP does not use a chain with smart contracts as the DA layer? In this way, a completely trustless settlement layer can be created based on the contract.
In the long run, as long as some technical difficulties are overcome, if the DA layer is placed on a contracted DA layer such as Ethereum and the corresponding contract for verification can be constructed, SCP can also obtain the same benefits as Rollup The same settlement security without the need to use multi-signatures.
But in practice this may not be the best choice:
1. Ethereum is not specifically used for data storage. Compared with pure data storage companies, The price is too high for the chain. For the SCP paradigm, sufficiently low or fixed storage costs are crucial.
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, which currently has no fraud proof 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.
Another more critical point is that the so-called settlement security that is the same as Rollup is only for the chain itself with smart contract DA layer, such as Ethereum, because all the original data is passed to Ethereum, then your settlement contract on Ethereum can "reference" the original input data to prove the correctness of the final state (note, it is not a direct reference but an indirect reference through a hash or accumulator, etc. The status mark of the original calldata, because the calldata of historical transactions itself cannot be referenced by the contract). But for other chains, they cannot enjoy the same security because there is no data on them. If you want to cross other chains, you can only use the witness mode cross-chain bridge.
So the Rollup solution only has better settlement security from a specific perspective, that is, when you regard one chain as your parent chain. SCP is not a certain public chain expansion plan, but a larger Web3 computing platform architecture, so it does not necessarily have to be implemented from the perspective of a certain chain-centrism. If the settlement layer is built on a smart contract, it cannot guarantee the settlement security of other chains except the parent chain. If you are not specifically here to expand the capacity of this chain, this seems completely unreasonable.
A picture comparing SCP with other paradigms.
SCP is a brand new Web3 The computing platform paradigm is comparable to the application speed of traditional Web2 transactions, and the transaction cost is negligible. Infinite possible applications can be built on it, and the security is consistent with mainstream solutions. At present, a number of applications have emerged under the SCP paradigm, such as everPay, PermaSwap, Mind Network, etc. Based on their excellent design concepts, they are very promising to usher in explosive growth in this and the next bull market.
Cryptocurrency security firms, decentralized finance and cross-chain platforms are stressing the importance of improved defense mechanisms after a spate of hacks and exploits targeting the ecosystem.
CointelegraphAfter last week's Slice covered the expansion of the existing sports deal between crypto exchange OKX and powerhouse footy club ...
BitcoinistSports and crypto continue to see major crossover, and while some deals come to an impending close, other doors have ...
BitcoinistAs we kick a new week into gear, there's some high-flying sports deals that keep our Sports Slice delivered to ...
BitcoinistOne platform has raised $10M to build the next blockchain sports game, while several other sports crypto platforms have fallen. ...
BitcoinistIt was a relatively quiet week in the sports and crypto crossover of content that we aim to cover each ...
BitcoinistA little bit of sports and crypto activity across quite a few major league sports this week, from teams to ...
BitcoinistMarkets go up and down, but sports fandom lasts a lifetime. That makes our job easier each week with The ...
BitcoinistBitcoinistAthletes are slowly becoming more and more interested in contracts paid out in crypto. What’s their reasoning and how does this impact the blockchain industry?
Cointelegraph