Closed ralexstokes closed 1 day ago
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.
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:
forkchoiceUpdatedWithWitnessV1,2,3
with same params and returns as forkchoiceUpdatedV1,2,3
, but triggering a stateless witness building if block production is requested.getPayloadV2,3
to return executionPayloadEnvelope
with an additional witness
field of type DATA
iff created via forkchoiceUpdatedWithWitnessV2,3
.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.payloadStatusV1
with a witness
field of type DATA
if returned by newPayloadWithWitnessV1,2,3
.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:
forkchoiceUpdatedWithWitness
instead of forkchoiceUpdated
to trigger witness creation too.getPayload
as before to retrieve the new block and also the above created witness.executeStatelessPayload
against another client to cross-validate the block.Cross validating locally processed blocks:
newPayloadWithWitness
instead of newPayload
to trigger witness creation too.executeStatelessPayload
against another client to cross-validate the block.Block production for stateless clients (local or MEV builders):
forkchoiceUpdatedWithWitness
instead of forkchoiceUpdated
to trigger witness creation too.getPayload
as before to retrieve the new block and also the above created witness.Stateless validator validation:
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.
I’d like to announce the following PR:
* [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 :partying_face:
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.
max_blobs_per_block
https://github.com/ethereum/consensus-specs/pull/3800base_fee_per_blob_gas
https://github.com/ethereum/consensus-specs/pull/3813closing in lieu of #1096
Consensus-layer Call 136
prev: call 135
Meeting Date/Time: Thursday 2024/6/27 at 14:00 UTC Meeting Duration: 1.5 hours stream