Add EigenDA , native Bridging

[GigaHierz]

1. Adding EigenDA
2. Adding Native Bridging

Open questions here, related to the spec:

- Should we use Superchain docs for WETH bridging? Harpal did the docs for this, but in the spec, you mention using optimism sdk: 
  - https://docs.celo.org/what-is-celo/using-celo/native-ETH-bridging

  - https://docs.optimism.io/stack/transactions/deposit-flow
- Intro:
    - Does CELO have different addresses on Ethereum than Celo? 
    - Don’t understand that sentence: The L2 version is the native token on the L2 Celo chain, preserving the balances from the Celo L1 chain. How does it preserve the balances from the Celo L1 chain? 
    - Do we have an address for CeloDistributionSchedule?
- Bridging tokens
    - Bridging CELO will be different from ERC20 tokens, even if CELO is also an ERC20 token?
    - Where is the fee abstraction happening? During the bridging? Only on Celo? Is this specific to bringing or all Fee Currency? 
    - What are the explorer tools for checking bridging? 

[netlify]

❌ Deploy Preview for celo-docs failed. Why did it fail? →

Name	Link
🔨 Latest commit	33c8e0e
🔍 Latest deploy log	https://app.netlify.com/projects/celo-docs/deploys/6887fc92d4148c00087a675f

[karlb]

Does CELO have different addresses on Ethereum than Celo?

Yes
Celo mainnet: https://celoscan.io/address/0x471ece3750da237f93b8e339c536989b8978a438
Ethereum: https://etherscan.io/address/0x057898f3C43F129a17517B9056D23851F124b19f

We can't freely choose an address on Ethereum and we would break existing usage if we changed the address on Celo, so those have to be different.

Don’t understand that sentence: The L2 version is the native token on the L2 Celo chain, preserving the balances from the Celo L1 chain. How does it preserve the balances from the Celo L1 chain?

The Celo L2 started with the same state that the Celo L1 had in its last block. So all native balances (CELO) carry over from the Celo L1 to the Celo L2.

Do we have an address for CeloDistributionSchedule?

It's not registered in the Registry contract for mainnet. @pahor167 can probably answer this one.

Bridging CELO will be different from ERC20 tokens, even if CELO is also an ERC20 token?

Yes, unlike other bridged tokens, the CELO ERC20 token does not allow the bridge to mint and burn tokens as part of the bridging process. This can't be implemented in the CELO smart contract without additional precompiles and we don't want to add any unless absolutely necessary.

Where is the fee abstraction happening? During the bridging? Only on Celo? Is this specific to bringing or all Fee Currency?

Bridging and fee abstraction as concepts are completely unrelated. A token can be bridgeable without being a fee currency and it can be a fee currency without being bridgeable (as well as both or neither).

Our fee abstraction only exists on Celo. Ethereum does not have support for it and does not "see" anything about it happening on Celo. The fee abstraction ins handled as part of the execution of txs on a Celo chain (when debiting and crediting fees right before and after the execution of the actual tx)