# Merge implementers call 2
Thu April 15. Summary notes by @protolambda.
Note: Simultaneous OpenEthereum Berlin problem, not as many eth1 devs on call.
- Consensus (eth2), Execution (eth1), Application (dapps)
- Engine or Sub-system, not layer
RPC spec: use rayonism-merge spec doc, not the Old RPC draft.
### Error handling
Error handling necessary in the spec. E.g. assemble-block producing bad data.
- 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
- RPC changes ok
- Starting sync from head is fairly easy
- Main problem in new sync and forkchoice management
- 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.
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.
- 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.
- 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.
- 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.
Genesis tool ready, devnet setup guide, and example configs.
Join the office-hour calls for bleeding-edge of rayonism work.
### Client updates
Will keep prototype work of Guillaume for first devnet. Directly injects data into chain.
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.
Working on Teku update, testing with Catalyst first, then Nethermind. Would like to test with Turbo geth.
Need to update to latest API. Prepared a reference project for a testnet faucet (dockerized).
Recently started working on Rayonism. Open PR, experimenting with Catalyst.
Not clear if/when ready yet. Still some RPC work to do.
Lighthouse/TurboGeth not present, updates for another time.
#### 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