Execution Layer Meeting 156

[timbeiko]

Meeting Info

• Mar 2, 2023, 14:00-15:30 UTC
  • Note: as of the next ACD (Mar 16), DST will have ended in parts of the world. Double check your local time!
• Youtube Stream: https://youtube.com/live/GNhrb5txJ4M
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Shanghai Updates
  • Sepolia Upgrade Recap
  • Goerli Upgrade Date
• Cancun Updates
  • SSZ Transactions Breakout Room #2 #727
  • CFI Process
  • EIP-5920
  • EIP-6190
• Client Updates/Discussion
  • pending block/transaction support
  • eth/66 deprecation
  • sync non-merged networks

[karalabe]

Random idea to debate briefly: is there a specific reason to retain the notion of the pending block or pending transactions in EL clients? Historically it served as a glimpse into what the next block might be. However, even way back this became mostly moot when there are 4K txs in the pool and only a few fit into the block, but with MEV and the likes, it's even moot-er since we have no idea what sandwiches and other food types end up included.

The upside of getting rid of it is just a weird mechanism that's not really useful, but makes the code weird in various places (e.g. we need to exec txs to maintain the pending block even if nobody calls it; retrieving the pending txs is weird when considering the inclusion fields (block, txindex) or basefee; pending txs get even weirder if subscribed via a streaming API (ws) because then you just get a stream of txs that have no clear block boundary not block inclusion info).

We can most definitely maintain this thing, just wondering if there's no specific reason for this to exist, we might as well delete it? Do we have any secific use case that validators might need?

[karalabe]

Another topic, we've specced out eth/68 for 4844. Geth at least still speaks eth/66 and eth/67. Would be nice to know what status other clients have to maybe drop at least eth/66. Not that it's particularly bothersome, but in general it's healthy to remove old stuff that's not needed any more.

[karalabe]

Yet another interesting question wrt removing legacy code is the need to sync / transition non-merged networks. Even though all our maintained networks (apart from Rinkeby, scheduled for removal in Q3) is merged, we still maintain the capability to sync non-merged networks and to transition them.

There is a lot of code and logic around this old mode of operation (old sync, block proapgation, etc). Would be nice to remove it, but that would also entail that any new network we create should be merged already on genesis. Not sure how functional this is, I kind of remember that devops always schedules all the beacon forks on subsequent block numbers, not everything applied form the get go. Would it be possible to make this workable so we can long term remove all that legacy and transition logic?

[timbeiko]

@karalabe added all three to the agenda 👍

[etan-status]

For SSZ, open to discuss:

• Receipt: Is it alright to define a new receipt format that affects EL networking?
  • Remove logs_bloom for all receipts starting from block X
  • Add transaction_hash, from as ExecutionAddress, contract_address as Optional[ExecutionAddress]
  • devp2p receipts exchange would be affected; or if kept same as current, requires syncing transactions before receipts.
  • Rationale: Reduce size of consensus Transaction object by removing computed properties.
    • Is there a usecase where CL needs transaction_hash / from / contract_address?
• SSZ transaction signature scheme: Do we need both fork_version and genesis_hash? https://eips.ethereum.org/EIPS/eip-6493

[Pandapip1]

I would like to add EIP-5920 and EIP-6190 to the agenda.

[holgerd77]

For SSZ, open to discuss:

* `Receipt`: Is it alright to define a new receipt format that affects EL networking?
  
  * Remove `logs_bloom` for all receipts starting from block X
  * Add `transaction_hash`, `from` as `ExecutionAddress`, `contract_address` as `Optional[ExecutionAddress]`
  * devp2p receipts exchange would be affected; or if kept same as current, requires syncing transactions before receipts.
  * Rationale: Reduce size of consensus `Transaction` object by removing computed properties.
    
    * Is there a usecase where CL needs `transaction_hash` / `from` / `contract_address`?

* SSZ transaction signature scheme: Do we need both `fork_version` and `genesis_hash`? https://eips.ethereum.org/EIPS/eip-6493

These are pretty significant changes. Could you link to where these changes are coming from respectively where they have been discussed (call, chat, call notes or anything)? Thanks! 🙏

[parithosh]

I'd like to bring up a discussion over the date for the Shapella fork on Goerli.

Considering client teams usually take ~1 week for releases and we want to give users ~1-2 weeks to update, we could:

• Choose a safe date of around 22nd March (e.g Epoch 163840 should be a sync committee boundary but please check again)
• Choose a aggressive date of 14th March (e.g Epoch 162304 should be a sync committee boundary but please check again)

You can use this site to get the local time: https://slots.symphonious.net/

I'd additionally like to discuss what client teams want to see before they are comfortable in setting a mainnet fork date. If clients are fine with it, we could choose mainnet dates as well and make it a combined release for Goerli as well as Mainnet. Alternatively we wait to see how Goerli performs before choosing a mainnet date (at the cost of a later fork).

[timbeiko]

@holgerd77 I suspect Etan's comment is based on the discussion in #727, but we can give context on the call. @Pandapip1 @parithosh, noted & added.

[etan-status]

Could you link to where these changes are coming from respectively where they have been discussed (call, chat, call notes or anything)?

#typed-transactions on ETH R&D discord, and also the EIPs here: https://hackmd.io/y1MCA5Q-R4eMVyOBHiRH7Q