Consensus-layer Call 136

[ralexstokes]

Consensus-layer Call 136

prev: call 135

Meeting Date/Time: Thursday 2024/6/27 at 14:00 UTC
Meeting Duration: 1.5 hours
stream

0. Private client information update
1. Execution cross-validation
2. Electra
   • devnet-1
   • other electra updates
     • EIP-6110 updates: eip6110: Queue deposit requests and apply them during epoch processing consensus-specs#3818
   • anything to say about blob fee spike?
3. PeerDAS
   • Refactor blob count and blob fee handling across EL and CL
4. SSZ update
5. Research, spec, etc
6. Open discussion/Closing remarks

[jorem321]

Hello! On behalf of Nethermind Research, I would like to present the results of the research report "Allowing validators to provide client information privately". This work was sponsored by a grant from the Ethereum Foundation, and its presentation to the community is an important milestone for its completion.

(I will summarize the main results into a 15-minute presentation.)

This research discusses methods that can be used (with some changes to the Ethereum protocol) to gather client diversity data from validators in an anonymous fashion. We would greatly appreciate your feedback on this.

[karalabe]

Hey all,

I'd like to RFC a proposal I've made a number of months ago, and which we've since mostly fleshed out and completed Geth side. Although I could try to EIP it, it cross cuts EL and CL and extends the engine API, so I'm unsure what exactly the procedure is (or if I should be even the one driving the spec given other owners of the engine API).

The proposal (updated since originally brain-dumped) is Execution layer cross-validation, which is a fancy way of saying Stateless Ethereum before Verkle. The TL;DR is that whilst MPT witnesses are somewhat large for reliable propagation over the internet, they can still be immensely useful (before Verkle lands) for a) preventing validator slashing due to consensus fault; and b) preventing double spend type attacks on services relying on a consensus faulty client.

---

What concerns the consensus clients is the engine API extensions proposed. Note, the names were derived to be fully analogous to how the API works currently, but still create a separate subset to not clash with production use until the final schemes are agreed upon. This is where you come in:

• Add forkchoiceUpdatedWithWitnessV1,2,3 with same params and returns as forkchoiceUpdatedV1,2,3, but triggering a stateless witness building if block production is requested.
• Extend getPayloadV2,3 to return executionPayloadEnvelope with an additional witness field of type DATA iff created via forkchoiceUpdatedWithWitnessV2,3.
• Add newPayloadWithWitnessV1,2,3 with same params and returns as newPayloadV1,2,3, but triggering a stateless witness creation during payload execution to allow cross validating it.
• Extend payloadStatusV1 with a witness field of type DATA if returned by newPayloadWithWitnessV1,2,3.
• Add executeStatelessPayloadV1,2,3 with same base params as newPayloadV1,2,3 and one more additional witness param of type DATA. The method returns statelessPayloadStatusV1, which mirrors payloadStatusV1 but replaces latestValidHash with stateRoot and receiptRoot.

One new type mentioned above are (exemplified json):

// statelessPayloadStatusV1 is the result of a stateless payload execution.
var statelessPayloadStatusV1 = {
	status:          "same as payloadStatusV1.status",
	stateRoot:       "0x0000000000000000000000000000000000000000000000000000000000000000",
	receiptsRoot:    "0x0000000000000000000000000000000000000000000000000000000000000000",
	validationError: "same as payloadStatusV1.validationError",
}

---

The above primitives permit us to enable the following use-cases:

• Cross validating locally created blocks:

  • Call forkchoiceUpdatedWithWitness instead of forkchoiceUpdated to trigger witness creation too.
  • Call getPayload as before to retrieve the new block and also the above created witness.
  • Call executeStatelessPayload against another client to cross-validate the block.

• Cross validating locally processed blocks:

  • Call newPayloadWithWitness instead of newPayload to trigger witness creation too.
  • Call executeStatelessPayload against another client to cross-validate the block.

• Block production for stateless clients (local or MEV builders):

  • Call forkchoiceUpdatedWithWitness instead of forkchoiceUpdated to trigger witness creation too.
  • Call getPayload as before to retrieve the new block and also the above created witness.
  • Propagate witnesses across the consensus libp2p network for stateless Ethereum.

• Stateless validator validation:

  • Call executeStatelessPayload with the propagated witness to statelessly validate the block.

Again, note, the various WithWitness methods could also just be an additional boolean flag on the base methods, but this PR wanted to keep the methods separate until a final consensus is reached on how to integrate in production.

---

As you can see on the use cases above, I've tried to make the API design feel as natural as can be compared to the way the consensus clients communicate currently with the execution layer. You'd have complete control over how you cross validate across different client implementations.

Everything mentioned in this doc and the one linked is implemented in Geth and is fully functional. Currently the API integration is the only outstanding merge, which you can find in this PR.

You can also find benchmark results in the linked document wrt witness construction overhead in Geth (hint, 20ms on mainnet head); stateless execution performance in Geth (hint, 105ms on mainnet head); witness sizes (hint; 8MB JSON encoded) and encoding/decoding speeds (hint, 100ms for JSON, 5ms for RLP (ouch)).

For more details though, please check out the proposal.

[mkalinin]

I’d like to announce the following PR:

• eip6110: Queue deposit requests and apply them during epoch processing consensus-specs#3818

[etan-status]

• EIP-7688: Forward compatible consensus data structures
  • Include in Pectra devnet 2?
    • Lodestar, Nimbus, Teku already have full implementations
    • Grandine, Lighthouse, Prysm still working on it, but no opposition at this stage for Electra inclusion
    • Specs not locked in, feedback can still be addressed
  • Specs rebased on top of Electra devnet 1: https://github.com/ethereum/EIPs/pull/8691/files
• EIP-6493: SSZ Transaction Signature Scheme
  • 🎉 EthereumJS has implementation: https://x.com/Gajpower/status/1805260843308794303 @g11tech
  • Kurtosis devnet available: https://stabilitynow.box
• Light client specs updated for Electra: Update light client specifications for Electra consensus-specs#3811

[g11tech]

* [EIP-6493: SSZ Transaction Signature Scheme](https://eips.ethereum.org/EIPS/eip-6493)
  
  * 🎉 EthereumJS has implementation: https://x.com/Gajpower/status/1805260843308794303 @g11tech
  * Kurtosis devnet available: https://stabilitynow.box

ethjs impl 🥳

• fusaka light client: implement Ssz and Log EIPs to enable merkle proof generation and validation ethereumjs/ethereumjs-monorepo#3452

[hwwhww]

This has been discussed in #1070, but we hope to get broader attention on passing the blob max count in Pectra to make the PeerDAS feature easier to test and deliver.

• Solution 1: pass max_blobs_per_block EIP-7742: Uncouple blob limits per block across CL and EL consensus-specs#3800
• Solution 2: pass ​​base_fee_per_blob_gas Blobgas computation in CL consensus-specs#3813

[ralexstokes]

closing in lieu of #1096