Skip to main content

Celo L1 → L2

Node operators​

In the Celo L1 node, operators simply needed to run the celo-blockchain client, a single service that was a fork of go-ethereum. Moving to the Celo L2 node operators need to run an op-geth instance for execution, an op-node instance for consensus and an eigenda-proxy for data availability. Instructions on operating nodes are here.

Deprecated transaction types​

Sending these transaction types is no longer be supported, however you can still retrieve any historical instances of these transactions.

  • Type 0 (0x0) Celo legacy transaction. These are type 0 transactions that had some combination of the following fields set ("feeCurrency", "gatewayFee", "gatewayFeeRecipient") and "ethCompatible" set to false.
  • Type 124 (0x7c) Celo dynamic fee transaction.

More details on supported transaction types here.

Native bridge to Ethereum​

An important benefit of becoming an L2 is having a native bridge to Ethereum. Celo will become an ERC20 token on Ethereum and users will be able to use the native bridge to move between the Celo L2 and Ethereum. The Alfajores testnet bridge can be accessed here.

Consensus​

The BFT consensus protocol has been removed and replaced with a centralized sequencer. Although validators are no longer needed to secure consensus, the election / voting mechanism and validator set will remain for the time being.

This is a temporary situation, and we will be working on re-introducing active roles for validators after Mainnet launch. For now, validators will serve as community rpc providers and do not need to run any special L2 infrastructure beyond full nodes.

Validator fees and staking rewards​

After the L2 transition, transaction fees will go to the sequencer but validators and stakers will still receive some rewards. Previously, rewards were emitted on epoch blocks but as Celo L2 does not have epoch blocks, rewards will be distributed through periodic calls to a smart contract. The amount of rewards to be distributed has not been decided. However, rewards will likely be lower than in the Celo L1 to reflect lower infrasture requirements.

Hardforks​

See here for the list of hardforks that will be enabled in the first block of the L2.

Precompiled contracts​

All Celo specific precompiles have been removed except for the transfer precompile which supports Celo token duality (the native asset CELO is also an ERC20 token)

Randomness​

The random contract has been removed. If randomness is needed then the PREVRANDAO opcode can be used. See here for more details.

Blocks​

  • Block interval has changed from 5s to 1s
  • Block gas limit has changed from 50m to 30m
note

Note this results in a 300% increase in gas per second due to the shortened block time

Added fields​

  • withdrawals & withdrawalsRoot - These fields are inherited from Ethereum but not used by the op-stack or Celo. Withdrawals will always be an empty list and withdrawalsRoot will always be the empty withdrawals root (0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421).
  • blobGasUsed & excessBlobGas - These fields are also inherited from Ethereum but not used by the op-stack or Celo. They will always be zero.
  • parentBeaconBlockRoot - Set to the parentBeaconRoot of the L1 origin block.

Removed fields​

  • randomness - Not needed since the randomness feature has been removed
  • epochSnarkData - Not needed since the Celo L2 does not support Plumo.
  • extraData - The BLS aggregated signature has been removed as it is no longer required.

EIP-1559 implementation​

Previously our implementation used a smart contract (here) to calculate the base fee which allowed for governable parameters. Now we use the standard EIP1559 algorithm with the parameter values being defined in the chain config.

For chain specific parameters see the deployment information in the Celo specs.

RPC API​

Pre-transition data​

Old blocks, transactions, receipts and logs are still be accessible via the RPC API but differ a bit from the corresponding objects retrieved from the L1 RPC API.

In general the changes involve additional extra unset fields that have been added upstream but were not present on historical Celo L1 objects, and the removal of some unnecessarily set fields on Celo L1 objects.

For in depth details of what has changed see here.

Block receipts​

Historically, the Celo L1 generated block receipts when system contract calls emitted logs. The Celo L2 does not have block receipts, but pre-migration block receipts are still retrievable via the RPC API eth_getBlockReceipt method.

Pre-transition execution and state access​

RPC API calls for pre-transition blocks that are performing execution or accessing state are not directly supported by the new Celo L2 implementation. However, you can configure your Celo L2 node to proxy to an archive Celo L1 node for these calls. See the archive node docs.