# Merge implementers call 2 Thu April 15. Summary notes by @protolambda. Note: Simultaneous OpenEthereum Berlin problem, not as many eth1 devs on call. ## Terminology - Consensus (eth2), Execution (eth1), Application (dapps) - Engine or Sub-system, not layer ## RPC RPC spec: use rayonism-merge spec doc, not the Old RPC draft. See https://notes.ethereum.org/@n0ble/rayonism-the-merge-spec ### Error handling Error handling necessary in the spec. E.g. assemble-block producing bad data. Examples: - Bad parent root - General execution failure during assembly ### NewBlock after AssembleBlock NewBlock (insert), containing the same assembled block, should still be called by the Eth2 node for a slot that has a locally produced block (AssembleBlock). ### Parent hash Question from Danny: valuable to put in assembleBlock? Alternative would be to assume head-block is the parent. Keep as-is, consistency checks are good. Proto: also consider multiple beacon nodes calling assemble concurrently. Assemble/SetHead can get out of sync. For now keep consistency, check the error. Supporting arbitrary parent block is more complex, maybe later. ### Finalize block Can function as constraint on parent-hash parameter in block assembly call. Not worth enforcing in execution engine, responsibility of consensus engine. Standard operation: 2 epochs worth of unfinalized data. =64 slots, ~13 minutes. Bad-case operation: days without finality (unhealthy chain). Dankrad: can be lower, depends on response on mainnet in such consensus failure event. ## Client updates ### Nethermind - RPC changes ok - Starting sync from head is fairly easy - Main problem in new sync and forkchoice management ### Geth - Guillaume PR for prototype next week - Updating it to latest spec soon - Gary has PR for consensus engine work - Started work on synchronization, need to be careful with production part of the code ## Spec discussion ### Block sync / state sync discussion The first devnet without modifications, assume in-sync. ### Gas limit Same functionality should remain for gas adjustment. No need to tweak during run-time currently. ### Slot-clock Beacon slot is converted to timestamp, and timestamp is necessary in block. Timestamp calculation: `genesis time + slot*12`. Transactions may use this to make the transaction look valid in local execution, but never be applicable to actual beacon chain. Timestamp is already included in header, not a problem for execution. But mempool may use other timestamp, and cause the transaction to change behavior based on environment. Mempool does not execute transactions, only checks balance and gaslimit. The pending-block should use the 12 second boundary (and account for genesis time offset). Regular nodes create the pending block, miners do not use it. Peter: pending-block is kind of useless. Mempool is too large, cannot trust miners to build the exact same block anyway. The pending-block functions as a nice cache layer though, making the storage hot for likely transactions. TODO: add expectation of pending-block timestamp constraint to spec. Miner cycle: - Empty block first - Create better blocks repeatedly PoS just needs one-time block production, PoW is more continuous. Block production can take about 1.5 seconds. Also consider caches being better filled in PoW type of repeated operation. Block preparation in advance may help. Mikhail: idea in specification addition: separate message with time update. Peter: just use previous block timestamp, calculate from there ### Slot-clock in Block propagation - Block production latency can be ok. Eth2 node can start production early. - Eth2 looks for sub-4-second delay from slot start to propagating it over the network - Beacon proposer can make block data before start of their proposal slot. If ready at the start of their proposal change, then it is ok. Beacon node can specify timestamp for block production. If Execution engine opportunistically makes a block, it must have clock synced well with beacon node. Peter: - Prepare-block message instead of poll with regular block assemble call. - Repeated assemble-block call is hard to garbage-collect. Better to keep assembly environment around until out-block. Alternative: - Use set-head or time as signal to stop producing. ### Fork Transition logic If we calculate transition total-difficulty after the trigger / dynamically (?), and embed it, then transition may improve: - Specify with epoch-number, like every eth2 fork. - Removes what miners can play with in regards to timing - No fork speed up or slow down. Just a set date. ### Block size Due to SSZ, the transaction list and transaction payloads all have max size. If you multiply these, you get a huge number (~16 GB). The p2p layer, and maybe consensus layer, should use some sanity limit. Peter: also consider bandwidth, things can get problematic with over half a megabyte messages. Gas limit should work, but sanity limit for DoS/bandwidth is good to have. ### Transaction types Since Berlin multiple types on eth1 mainnet. Eth2 by default will use `OpaqueTransaction`: encoded eth1 transaction (full envelope with selector). Just a string to eth2 consensus. We may want to structure them in SSZ later. Wrapping the `OpaqueTransaction` with a `Union` (current SSZ spec will improve first, reduce to 1 byte selector). ### Total difficulty usage in Beacon node Not encoded in SSZ or anywhere in Eth2. Big integer usage is new in Beacon node. Required for transition procedure. No math, just comparison. Total difficulty can be larger than the uint64 types. Uint256 should work. Prysm, Teku, Nimbus: all ok with bigint usage for this. Jacek: you can do byte-by-byte comparison. Easy if there is no other bigint math involved. ## Rayonism ### General Genesis tool ready, devnet setup guide, and example configs. Join the office-hour calls for bleeding-edge of rayonism work. ### Client updates #### Geth Will keep prototype work of Guillaume for first devnet. Directly injects data into chain. #### Nethermind Initial implementation of RPC done soon. Looking for Eth2 clients to test RPC with. Mikhail: guide to run Nethermind fork would be great. Will experiment with Teku. #### Besu No updates. #### Teku Working on Teku update, testing with Catalyst first, then Nethermind. Would like to test with Turbo geth. #### Prysm Need to update to latest API. Prepared a reference project for a testnet faucet (dockerized). #### Nimbus Recently started working on Rayonism. Open PR, experimenting with Catalyst. Not clear if/when ready yet. Still some RPC work to do. #### Other Lighthouse/TurboGeth not present, updates for another time. ### Questions #### When first devnet? First week of hackathon is the target. Just prototype, need to test RPC in more shared setting. It may be unstable, that is ok. Example devnet configuration is available here: https://github.com/ethereum/rayonism