Recently, the well-known exchange Coinbase released news, announcing the launch of its own developed Ethereum second-layer extension system Base[1]. The news immediately aroused heated discussions and discussions in the industry.
According to Coinbase’s official announcement[1]the currently launched Base version is its test network, and the system is based on Optimism[2]OP Stack[3]technology development.
However, at present, the focus of hot discussion and discussion is mainly on its commercial layout and ecological planning, and there are not many discussions on its technical architecture characteristics, and there may be but only superficial discussions.
The Fairyproof technical team tries to explore the characteristics of the Base system and the points worthy of attention in terms of security from the OP Stack, the technology stack on which Base is based.
First, let’s look at some basic features of the OP Stack technology stack.
OP Stack is a technology stack developed by the Optimism team for building a second-tier extension system. Its architecture diagram is as follows:
official document[3]After explaining this technical architecture, we believe that the more important features are as follows:
1. Technical iteration and compatibility of OP Stack
According to Optimism’s official statement, this technology stack is implemented in two stages. The first is the current stage of Bedrock, and the second is the next stage of Superchain. The components marked with circles in the architecture diagram are proposed to be developed according to Optimism’s official statement, so they are more likely to be components that are currently being developed and will be released in the next stage, the Superchain stage.
Although the iteration of this technology stack is divided into two stages, according to the official documentation, the Bedrock version implemented at this stage will be well compatible with the Superchain version in the next stage.
However, the official document also mentions that developers can modify the Bedrock-based OP Stack code to develop a customized second-layer extension solution, but this customized second-layer extension solution may not be compatible with the future Superchain . Then, which part of the OP Stack components or architecture will be customized and modified to cause compatibility issues? The official documentation does not describe in detail.
2. The centralization problem in the operation mechanism of OP Stack
For blockchain systems, maintaining decentralization in terms of operation and technical architecture is important to its overall security. In the Bitcoin white paper, Satoshi Nakamoto put decentralization in an extremely important position. Because this is an important measure to ensure that the system avoids single point failures and attacks.
According to the official document of OP Stack, the current implementation scheme has two problems of centralized operation, one is the ordering of transactions (Sequencing), and the other is the selection of validators (Attestor).
In the OP Stack architecture, the current centralized operation is mainly in the transaction sequencing (Sequencing). This work is done by the Sequencer.
In the current OP Stack implementation, the default setting of the Sequencer is only one Sequencer, which sorts the transactions in the entire Optimism system. This is obviously a more centralized mode of operation.
In addition, the official document also mentions that there is another way to select a sorting task to execute transactions from multiple sorters. This is the solution that the future Superchain system aims to achieve. If this solution is implemented, it can further remove the centralized operation problem in the sorting process.
In addition to ordering, similar problems exist in the validator mechanism.
OP Stack currently implements the Fraut Proofs mechanism. In this mechanism, when the status certificate submitted by the verifier (Attestor) exceeding a certain threshold does not match the status submitted by the system to Ethereum, it can be proved that the status submitted by the system to Ethereum is invalid.
However, in the official document of OP Stack, it is not mentioned whether these verifiers (Attestator) are pre-selected or anyone can participate without permission.
We estimate that there is a high probability that the current validators are pre-selected by the team. If so, the current verifiers also have centralization issues.
In this regard, the team’s proposed future solution is “Fault Proof Optimistic Settlement”. The official document says that this mechanism uses a permissionless authentication mechanism, but details of how it is implemented are not disclosed.
3. The scalability of the proof mechanism
Among the two currently popular Rollup schemes, whether it is Optimistic or ZK, they all need to submit proofs to the Ethereum mainnet. The former submits error proofs (Fault Proofs or Fraud Proofs), and the latter submits valid proofs (Validity Proofs).
In the OP Stack, the realization of the proof is completed in the settlement layer (Settlement Layer). The currently implemented proofs are Fault Proofs, and more specifically, Attestation Based Fault Proofs.
But in the Optimism team’s plan, this part can also support Validity Proofs in the future. As for when effective proofs will be supported, according to official documents, it is necessary to wait until the ZK scheme based on zero-knowledge proofs matures.
It can be seen that OP Stack leaves room for imagination in this regard for scalability, and the future Optimism system (Superchain) may support both proof schemes at the same time.
4. The security and activity of the second layer system
In its official document, OP Stack proposes two measures for the reliability of the second-layer extension system: Security and Liveness.
The security of the system is guaranteed by the proof system, and the activity of the system is measured by whether the second-layer system can normally submit transactions to the (Ethereum) main network.
In a system based on the OP Stack architecture, when the sequencer (Sequencer) fails to work normally, in order to ensure that the second-layer system can still submit transactions to the Ethereum mainnet normally, the system supports finding other Sequencers that can work normally to submit transactions.
In more urgent cases, when the bridging function of the second-tier system to the Ethereum mainnet is frozen (that is, when the activity of the system cannot be guaranteed), the user’s assets on the blockchain mainnet will be frozen. This is to ensure that even in the event of liveness failure, the user’s (asset) security can still be guaranteed.
This reflects the result of the team’s trade-off between security and activity: security is higher than activity.
5. System governance
One layer in the architecture diagram is the Governance Layer. This governance layer is a decentralized security council in the official plan. In the future, this committee can update the Attestators of each Chain in Superchain, upgrade contracts, and suspend Superchain bridges in an emergency.
This committee has a strong control.
However, how this committee is composed and how it works has not revealed more details in the current official document.
We think that using multi-signature wallets on the chain or MPC technology off the chain in this committee to prevent permission leakage or intrusion may be the way the project party will adopt.
The points listed above are the more important features and elements of our artificial OP Stack technology stack. Since the Base system will be built based on the OP Stack, the Base system will also inherit the above characteristics. But in addition, we think there are some special details in the Base system that are worth discussing.
So next, let’s look at some special details and possible implementations of the Base system.
According to the official document released by Coinbase[1]we focus on the following points:
The payment currency of fees in the Base system
Coinbase publicly stated in the official document that the system will not issue tokens in the future, but the system and its various applications running in the system will have to pay fees to Ethereum when submitting transactions to the Ethereum mainnet. Therefore, the most direct and easiest way is to charge ETH to the application running on Base to pay the Ethereum fee. Therefore, in the future, when the project party deploys the application on the Base or the user interacts with the application on the Base, the fee paid will most likely be the direct payment of ETH.
The role involved in the permissionless system in the base system
Coinbase says Base, the second-layer scaling system, will be permissionless for users.
Here, the users understood by the Fairyproof technical team refer to the project teams who deploy projects on Base and the users who interact with these projects. For these users, they can carry out their above-mentioned activities without permission.
However, Base itself is a second-layer extension system, and the system itself also has some roles that require participants. These participants are mainly responsible for maintaining system security and ensuring the normal operation of the system. In the Ethereum main network, the most typical participant of this type is the validator (Validator), and in the second layer extension, the most typical participant of this type is the sequencer responsible for the ordering of transactions and the verification of the verification status. Attestor.
So can everyone act as an orderer and state validator without permission? The Fairyproof team believes that this condition is not met in the current Base scheme. It is more likely that certified-assigned orderers and state verifiers will still be used today.
Three Base system supports and implements Ethereum Virtual Machine (EVM) and account abstraction
The official documentation mentions that Base is fully compatible with the Ethereum Virtual Machine (EVM). The so-called compatibility with the Ethereum virtual machine means that all programs that can run on Ethereum can be run on Base directly or with only minor modifications. This point inherits the characteristics of the Optimism or OP Rollup technology genre, and it is very convenient for various project parties currently running on Ethereum to directly migrate their projects into the Base ecosystem.
The Coinbase team here points out Base’s support for account abstraction, but does not give detailed details about it.
In this regard, our speculation is as follows:
At present, in the Ethereum standard system (EIP), a variety of solutions are given for the realization of account abstraction, and the typical one is EIP-2938[4]、EIP-4337[5]. However, EIP-2938 involves modifications to the Ethereum consensus layer, while EIP-4337 only needs to be implemented at the smart contract level. Obviously, implementing support for account abstraction at the level of smart contracts is the most convenient and efficient solution.
In addition, another well-known second layer scaling system zkSync[6]It also implements support for account abstraction in its current version, and in its official documentation[7]It is clearly pointed out that its implementation is very similar to EIP-4337.
Therefore, we believe that Base’s implementation of account abstraction is more likely to be based on the implementation of EIP-4337.
Four Base’s support for cross-chain
The official document mentions that Base not only connects to Ethereum, but also connects to other layer-2 expansion solutions and even other blockchain mainnets (Layer 1) such as Solana.
This means that Base will have various cross-chain functions. The scope covered by these cross-chains will not only be limited to the cross-chains between the main chains of the more popular blockchains, but will also include the cross-chains between the second-layer extension systems of Ethereum that have not yet been implemented and promoted on a large scale.
Regarding the cross-chain between the main chains of the blockchain, the current official document published by OP Stack does not seem to provide too many details, and perhaps this part of the content is not convenient for the time being. Therefore, we believe that the blockchain main chain cross-chain function mentioned by Base is either based on the undisclosed content of the OP Stack, or it is a function to be developed by Base itself.
As for the cross-chain between the second-layer extensions, we think it can be divided into three categories: mutual cross-chain between Optimistic Rollup systems, mutual cross-chain between ZK Rollup systems, and cross-chain between Optimistic Rollup and ZK Rollup .
At present, few teams have proposed corresponding solutions for the cross-chain between ZK Rollup systems and the cross-chain between OP Rollup and ZK Rollup. As for the cross-chain between OP Rollups, the public document of OP Stack mentioned that in the future, the second-layer expansion system based on the Superchain architecture can realize convenient cross-chain.
Therefore, we believe that the cross-chain between the second-layer expansion systems mentioned by the Base system currently refers to the cross-chain between the second-level expansion systems based on the Superchain architecture. This is the easiest and fastest function to implement.
Decentralization and Implementation of Five Base
The official document mentions that Base will be decentralized, but it will be implemented in stages.
According to the official documentation of OP Stack, in the second-layer expansion system solution currently implemented, the Sequencer is specified in a centralized manner. OP Stack also mentioned that the Sequencer’s designation mechanism will be decentralized in the future (such as polling).
We think this is also the evolution direction of Base, which will gradually decentralize the centralized participants (such as Sequencer, Attestor, etc.) involved in system maintenance in the current OP Stack. When these participants are gradually decentralized, it means that there are multiple candidates for a role who are eligible to participate. For these participants to participate in activities, according to the rules of the general POS mechanism, they will need to mortgage tokens.
In the current Ethereum ecology and Optimism ecology, the asset that is mortgaged at the Ethereum mainnet level is ETH, and the asset that is mortgaged at the Optimism level is OP tokens.
What are the crypto assets that the Base system may mortgage?
Coinbase stated that it will not issue tokens for Base, so we judge based on the collateral assets of the Ethereum mainnet and the Optimism system. In the Base system, when further decentralization is realized in the future, the crypto assets that participants need to mortgage are more likely to be ETH or OP Token.
In summary, we believe that the OP Stack-based Base system has good potential in terms of scalability. In the future, if further decentralization mechanisms can be introduced in transaction ordering and Multi-signature wallet or MPC technology manages the authority of the security committee to ensure the security of authority, which will make the system more secure, reliable and credible in technology and operation.
references:
[1] Introducing Base, https://www.coinbase.com/blog/introducing-base
[2] Optimism, https://www.optimism.io/
[3] Welcome to the OP Stack, https://stack.optimism.io/
[4] EIP-2938, https://eips.ethereum.org/EIPS/eip-2938
[5] EIP-4337, https://eips.ethereum.org/EIPS/eip-4337
[6] zkSync, https://zksync.io/
[7] Account Abstraction Support,
https://era.zksync.io/docs/dev/developer-guides/aa.html#prerequisites