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 will 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 transactions​

Sending these transaction types will no longer be supported, however you will still be able to 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 integral part of L2 design is that they have a native bridge to ethereum. Celo will become an ERC20 token on Ethereum and users will be able to use the native bridge to bridge between the Celo L2 and Ethereum. The Alfajores testnet bridge can be accessed here.

Consensus​

The BFT consensus protocol will be removed and replaced with a centralized sequencer. Although there will be no more need for validators the validator set, election mechanism and voting will remain, however validators will not need to run any infrastructure for the L2.

This is a temporary situation, after Mainnet launch we will be looking at re-introducing active roles for validators.

Validator fees and staking rewards​

Transaction fees will now go to the sequencer.

Validator and staking rewards will remain, previously rewards were emitted on epoch blocks, Celo L2 does not have epoch blocks so reward emissions will be handled through a smart contract that can be called to periodically distribute rewards. The amount of rewards to be distributed has not been decided, however during the time that validators are no longer required to run infrastructure rewards will likely be less than in the Celo L1.

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 removed except for the transfer precompile which supports Celo token duality (the native asset CELO is also an ERC20 token)

Randomness​

The random contract removed, if randomness is needed then the PREVRANDAO opcode can be used, more details here.

Blocks​

  • Block interval changed from 5s to 1s
  • Block gas 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, 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 is being removed
  • epochSnarkData - not needed since there will be no Plumo support in the Celo L2.
  • extraData - will have the BLS aggregated signature removed, this simplifies the L2 implementation and since we already trust those blocks and distributed rewards for them, the BLS signature is no longer required.

EIP1559 implementation​

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

The parameters we are using are:

  • Alfajores testnet:
    • EIP-1559 elasticity multiplier: 5
    • EIP-1559 denominator: 400
    • EIP-1559 floor: 25 Gwei (note that the floor is not part of the original EIP-1559 specification, but it did exist in the Celo L1 smart contract implementation)

RPC API​

Pre-transition data​

Old blocks, transactions, receipts and logs will still be accessible via the RPC API but they will 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 is changed see here - (TODO add section in specs covering this)

Pre-transition execution and state access​

RPC API calls for pre-transition blocks that are performing execution or accessing state will not be directly supported by the new Celo L2 implementation, however if this is required you can configure your Celo L2 node to proxy to an archive Celo L1 node for these calls. See here