-
-
Published
Linked with GitHub
# Rayonism early-bird Call
Wed 7 April 2021
Attendees: Alex S., Ansgar, Artem Z. Collin M, Danny, Gary S., Hsiao-Wei, Joseph C., Lakshman, Matt G., Marek M., Marius VDW, Mikhail, Paul H., Pawan, Petter, Proto, Raul, Ryan, Sean, Terence, Tim B. Tomasz, Trent van Epps, Zahary, Lukasz
## Spec draft
- Latest Merge specs in Eth2 repository available. We will pin a commit.
- Mikhail made a more concrete draft for Rayonism: https://notes.ethereum.org/@n0ble/rayonism-the-merge-spec
- First target is to run a devnet in post-merge:
- Empty eth1 and eth2 genesis state
- Communicate between clients from start of the chain.
- Simple block sync
### Total-difficulty & chain management
The Eth2 forkchoice is fundamentally different from Eth1:
- Attestations define the weights, not blocks
- Even without blocks, the chain can reorg (due to votes for empty slot processing)
Notes:
- A constant difficulty, or an increasing difficulty (same thing here really) would mean that some reorgs in Eth2 cannot be handled in the Eth1 side.
- Needs more review before decision of first devnet approach. Previous catalyst used constant-difficulty work around, assuming no reorgs.
This may be good enough, and then un-blocks other work on Merge that relies on having a testnet.
- Deeper discussion for next calls
### Genesis & deposits
- Chicken-egg problem with Eth1 and deposit contract
- Prater was launched without deposit contract
- Tooling: https://github.com/protolambda/eth2-testnet-genesis
- Clients have options for embedding a contract in genesis state, but not events
- Deposit approaches:
- Basic approach:
- Start with pre-mined genesis validator set (with above tooling)
- No changes in validator set, no deposits, no eth1 chain tracking
- Medium approach:
- Start with pre-mined genesis validator set (with above tooling)
- Deploy deposit contract on-chain after genesis
- Allow eth1 data and deposit processing like normal. Eth2 node uses Eth1 RPC to pull deposit logs. No follow distance changes.
- Advanced approach:
- Start with pre-mined genesis validator set (with above tooling)
- Embed empty deposit contract
- Geth, Parity and Nethermind have configuration ability to do this (TODO: look into details in next office hour calls)
- Point to Eth1 genesis block at Eth2 genesis
- Start processing deposits from genesis, as soon as first eth1 data change
- Follow distance / deposit processing approach may change later in hackathon
- Likely basic for first testnet, unless someone with Eth1 genesis expertise can help with contract embedding.
- Minimal genesis validator set, at `2**14 (= 16,384)` validators.
## Clients intro
Paul - Lighthouse
Able to run with Catalyst
Gary - Besu
Started today, digesting specs. Looking at RPC support.
No Teku phase0 members on Rayonism - edit: still TXRX + some exceptions.
Terence, Raul - Prysm
Same as lighthouse, align with latest steps. Waiting for Geth to catch up with RPC.
Mikhail - Teku/TXRX
Teku/TXRX, working on the merge.
Anton - working on sharding
Dmitry - working on wirthdrawal contracts
Zahary - Nimbus
Working on RPC, recently got started with Catalyst
Marius - Geth
Guillaume, updating to latest spec, and best point of contact.
Sina is helping as well.
Peter/Gary are looking into sync mode.
Marius will look at EVM fuzzing of possible new opcodes during hackathon.
Lukasz - Nethermind
Not started yet, but have an understanding of the spec. Lukasz and others will get started next week.
## Scheduling
- Quick and short (about a week) devnet first, about a week into the hackathon. Implement any work-arounds to unblock others. TBD in next pre-hackathon calls.
- More concrete devnet date next week
- Short lived, try longer testnet after (with more community, i.e. testnet instead of devnet)
- Office hour calls will be at alternating times, two or three per week, optional. Proto and a few others will bridge conversation and keep others in sync.
- Please share progress in chat as well.
- Sharding closer to the end of the hackathon, parallel to fork-transition work, different group.
- A lot of Eth2 protocol work. For Eth1 it just involves a KZG pre-compile, no other changes.
- Proto updated sharding specs, reach out if you can help with implementation.
- After initial testnets, we will re-evaluate the fork-transition approach. Currently building on phase0, rebasing on Altair may be possible in a month from now.
- Eth2 engineering complexity: quick phase0 type changes vs. actual fork update support
- No visible changes to Eth1 client, hence the motivation to get them running quick, even before rebasing to Altair.