Coinbase recently announced that it would launch Base, its layer 2 system for Ethereum [1]. According to Coinbase, the released system is a testnet (Beta) and it is developed based on the open source OP Stack[3] of Optismism[2]. The announcement has raised great awareness and hot discussions among the crypto space.

Most of the existing discussions around Base are centered around Coinbase’s business vision and ecosystem future. Few have touched on Base’s technical details and implementation.

Fairyproof’s research team attempts to discover some key technical details in Base’s implementation by studying OP Stack’s architecture and Coinbase’s description for Base.

First, we review OP Stack’s technical paper and list some key characteristics.

OP Stack is a framework that Optimism developed for its Ethereum layer 2 systems. Its architectural design is quoted from its technical paper and shown as follows:

Fig 1. The OP Stack Architectural Design. The circled items are proposed and will very likely be implemented in OP Stack’s second phase, i.e. “Superchain”.

We have listed the following items of interest upon reading its technical paper [3]:

1. OP Stack’s Iteration and Compatibility

OP Stack is implemented in two phases – “Bedrock” (The current implementation), and the second phase “Superchain”.

According to the technical paper, although OP Stack will be implemented in two phases, Bedrock will be compatible with Superchain. It also mentions that developers can make changes and develop their customized systems based on Bedrock, however, Optimism does not guarantee these customized systems will be compatible with Superchain. The changes that may result in incompatibility are also not described.

2. Centralization in OP Stack’s Mechanism

Decentralization plays a key role in ensuring a blockchain system’ overall security. In Bitcoin’s whitepaper, Satoshi Nakamoto rates decentralization with extremely high priority since it can mitigate single point of failure.

Therefore, when we study OP Stack, we will need to carefully search for its description on decentralization of various operations. Two operations in OP Stack come to attention: Sequencing, and attestation.

In the existing implementation, its sequencing mainly orders transactions before rolling them up and submitting to its layer 1 (Ethereum) system. By default, the sequencing is solely operated by one sequence – and this is centralized.

The paper also mentions an alternative solution which selects a sequences from multiple nominees, a proposal to be implemented in Superchain. Upon the implementation of this solution, its sequencing will be greatly decentralized.

Apart from sequencing, the existing attestation mechanism is, to some extent, centralized as well.

The existing OP Stack implementation uses a fault-proof mechanism where, when a threshold number of attestators submit a state that does not match the system submitted state, the system submitted state will be considered invalid.

However, OP Stack’s technical paper does not describe how these attestators are generated. Are they pre-designated or permissionlessly nominated?

We would expect they are pre-designated in the current phase. If so, this is a centralization issue. 

The Optimisim team proposes to adopt a “Fault Proof Optimistic Settlement” solution in the future. This proposed solution is said to be permissionless. However, regarding how it is permissionless, no further details are revealed in our research.

3. Multiple Proof Mechanisms

There are currently two types of Rollup solutions: Optimistic Rollups and ZK Rollups. Both require a submission of proof to a layer 1 (Ethereum) system in every time interval. The Optimistic Rollups submit a fault proof (or fraud proof) while the ZK Rollups submit a validity proof.

In the current OP Stack’s implementation, proofs are implemented in the Settlement Layer as fault proofs, more specifically as attestation-based fault proofs.

Optimism’s proposed road map indicates that the proof system will also support validity proofs in the future. As to when validity proofs will be supported, according to the technical paper, it is very likely when the industry has pretty much mature ZK Rollup solutions.

Hence, OP Stack has built in scalability for this and the future OP Stack (Superchain) will very likely support both proof systems.

4. OP Stack’s Security vs Liveness

OP Stack’s technical paper uses two metrics to measure a layer 2 system’s reliability or robustness: security and liveness.

The system security of OP Stack relies on its proof system. Its liveness relies on whether OP Stack can regularly submit transactions to a layer 1 (Ethereum) system.

When the sequencer is unable to work regularly in OP Stack, the system will seek an alternative functional sequencer to ensure that the overall system still operates. In the worst case, when the bridge between OP Stack and Ethereum shuts down (i.e. the system’s liveness is lost), users’ assets on Ethereum will be frozen. This is to ensure that when OP Stack loses its liveness users’ assets are still safe.

This reveals that a layer 2 system’s security has a higher priority than its liveness from the Optimism team’s point of view.

5. On-chain Governance

In OP Stack’s architectural design, there is a Governance Layer. According to the technical paper, this layer will be a decentralized security council. This council will be able to update each single chain (layer 2 system) ’s attestators, contract upgrades, emergent pause of bridges, etc, in Superchain’s ecosystem.

The security council has privileged access control to an OP Stack-based layer 2 system. No further details are revealed when detailing as to how this council is generated and how the council operates.

Most of all, if the council members’ private keys are compromised, the overall system will be exposed to huge risks.

Using multi-sig wallets or applying Multi-Party Computation (MPC) to manage their access control might greatly improve the council’s security. The Optimism team may adopt similar solutions.

These items are key points we think need attention when studying OP Stack. As Base is developed and built on OP Stack, Base would inherently inherit these characteristics and features. However, we think there are still more details worth discussion and exploration.

Here are the findings after careful studying of Coinbase’s announcement [1] for Base:

1. Payment Cryptocurrency in Base

Coinbase’s official announcement for Base states that there will be no tokens issued for Base. However, as a layer 2 system it should at least pay transaction fees to Ethereum and collect fees from users.

With regards to paying fees to Ethereum, typical systems would pay ETHs. When it comes to collecting fees from users, typical systems would issue a token and collect fees in the token from users.

Since Base will not have its own token, it is very likely Base would both collect fees and pay fees in ETH, which is the most straightforward way.

2. Permissionless Roles in Base

Coinbase’s announcement says that Base will be a permissionless layer 2 system.

Our understanding for “permissionless” is that project teams can permissionlessly deploy dApps on Base and users can permissionlessly interact with dApps deployed on Base.

As a permissionless layer 2 system, Base needs actors to participate to run and maintain its regular operations. These actors play key roles in ensuring Base’s overall system security and liveness.

Within Ethereum, these typical actors are validators. Within layer 2 systems like OP Stack, these typical actors are sequencers and attestators.

Can any actors permissionlessly be a sequencer or an attestator in OP Stack? According to our research, Coinbase does not reveal more details and it is very likely Base’s current version hasn’t implemented a decentralization mechanism for selecting either sequencers or attestators. It is most likely both the sequencer and the attestators are pre-designated.

3. Implementation for EVM and Account Abstraction

Coinbase’s announcement claims that Base fully supports EVM. This means that any smart contract that runs on Ethereum can be seamlessly ported to Base or be done with some slight changes. This inherits the features of OP Stack and can easily help grow Base’s ecosystem rapidly.

Regarding Base’s implementation for account abstraction, Coinbase does not reveal specific details.  

Our analysis is as follows:

There are multiple proposed solutions for implementing account abstraction in the current EIP system. The most prominent ones are EIP-2938[4] and EIP-4337[5]. EIP-2938 proposes a solution involving changes in Ethereum’s consensus mechanism, while EIP-4337 proposes a solution that can implement account abstraction via smart contracts without any change in Ethereum’s consensus mechanism. Obviously, an EIP-4337 based solution is easier and more efficient.

In addition, another popular layer 2 system zkSync[6] already implements support for account abstraction and describes its implementation similar to EIP-4337 in its technical paper[7].

Therefore, we think Base’s implementation for account abstraction is very likely based on or is like EIP-4337.

4. Support for Cross-chain Transactions

Coinbase’s announcement says that Base will not only bridge Ethereum, but also bridge other layer 2 systems and even other blockchain mainnets (layer 1 systems) such as Solana.

This implies that Base would support various cross-chain transactions. Since Base is based on OP Stack, we would explore Base’s support for cross-chain transactions by studying OP Stack’s support for it. 

With regard to implementing cross-chain transactions from OP Stack to a non-Ethereum blockchain mainnet, OP Stack’s technical paper does not reveal technical details. Therefore, we think this function may not be available now but is yet to be implemented.  

Regarding implementing cross-chain transactions from OP Stack to another layer 2 systems, we think this implies implementing three kinds of cross-chain transactions: cross-chain transactions between Optimistic Rollups, cross-chain transactions between ZK Rollups and cross-chain transactions between an Optimistic Rollup and a ZK Rollup.

In the current ecosystem, there are very few solutions available for either bridges between ZK Rollups alone or bridges between OP Rollups and ZK Rollups. OP Stack’s technical paper only describes a scenario in which cross-chain transactions happen in OP Stacked-based OP Rollups but does not provide more details about how to support cross-chain transactions between an OP Stack system and a non-OP Stack-based system. 

Therefore, we think in the foreseeable future that Base may first implement support for cross-chain transactions between OP Stack based systems.

5. Base’s Decentralization and POS Staking

Coinbase’s announcement says that Base will be decentralized gradually.

We think Base’s implementation for decentralization will initially be dependent on OP Stack’s decentralization.

According to OP Stack’s technical paper, its sequencer is designated in a centralized way. The future selection of the sequencer will be decentralized such as being selected by a round-robin algorithm.  

This will very likely be the path that Base will move forward in. Following this path, Base’s sequencer and attestator selections will be gradually decentralized as a Proof of Stake system.

According to the general rules that a Proof of Stake system runs on, actors who intend to work as a sequencer or an attestator need to stake crypto assets when these roles are decentralized. 

Within Ethereum, ETH is used as its staking asset. Within Optimism, OP is used as its staking asset.

As for Base what will be its staking asset if it becomes a POS system?

Our analysis is as follows:

Since Base will not issue its token, it is based on OP Stack which uses OP as its staking asset and it needs to pay ETHs to Ethereum, it is possible Base will use either ETH or OP as its staking asset.

6 On-chain Governance

In OP Stack, there is a security council which has great access control to perform on-chain governance on its system.

However, OP Stack’s technical paper does not share more details about how to manage this access control safely and securely.

If Base inherits this component, using multi-sig wallets or MPC signatures to manage this access control might be a good way to mitigate risks of access control being compromised.   

In summary, we think OP Stack-based Base has a great ambition to be a permissionless layer 2 system, and that Base has a great potential to be a big contributor to the overall Coinbase’s ecosystem.

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