HomeEIPs
EIPsEIP-6465
EIP-6465

SSZ Withdrawals Root

Migration of withdrawals MPT commitment to SSZ
DraftStandards Track: Core
Created: 2023-02-08
Requires: EIP-2718, EIP-4895, EIP-6493
Etan Kissling (@etan-status), Mikhail Kalinin (@mkalinin)
DiscussionsOriginal linkEdit
1 min read

The EIP-6465 proposal suggests adding a new Withdrawals Root to the Ethereum protocol using the Simple Serialize (SSZ) data structure. This would allow for more efficient and secure withdrawals from smart contracts. The proposal outlines the technical details of how this would be implemented, including changes to the Ethereum Virtual Machine (EVM) and the addition of new opcodes. The proposal also discusses potential benefits, such as reducing gas costs and improving scalability. However, as of February 2023, the proposal is still in draft form and subject to further review and revision.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This EIP defines a migration process of the existing Merkle-Patricia Trie (MPT) commitment for withdrawals to Simple Serialize (SSZ).

Motivation

While the consensus ExecutionPayloadHeader and the execution block header map to each other conceptually, they are encoded differently. This EIP aims to align the encoding of the withdrawals_root, taking advantage of the more modern SSZ format. This brings several advantages:

  1. Reducing complexity: The proposed design reduces the number of use cases that require support for Merkle-Patricia Trie (MPT).

  2. Reducing ambiguity: The name withdrawals_root is currently used to refer to different roots. While the execution block header refers to a Merkle Patricia Trie (MPT) root, the consensus ExecutionPayloadHeader instead refers to an SSZ root. With these changes, withdrawals_root consistently refers to the same SSZ root.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Existing definitions

Definitions from existing specifications that are used throughout this document are replicated here for reference.

NameSSZ equivalent
ValidatorIndexuint64
Gweiuint64
ExecutionAddressBytes20
WithdrawalIndexuint64
NameValue
MAX_WITHDRAWALS_PER_PAYLOADuint64(2**4) (= 16)
TRANSACTION_TYPE_SSZ0x04

SSZ Withdrawal container

The existing consensus Withdrawal SSZ container is used to represent withdrawals.

class Withdrawal(Container): index: WithdrawalIndex validator_index: ValidatorIndex address: ExecutionAddress amount: Gwei

Execution block header changes

The execution block header's withdrawals-root is updated to match the consensus ExecutionPayloadHeader.withdrawals_root.

withdrawals = List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD]( withdrawal_0, withdrawal_1, withdrawal_2, ...) block_header.withdrawals_root == withdrawals.hash_tree_root()

Typed withdrawal envelope

A typed withdrawal envelope similar to EIP-2718 is introduced for exchanging withdrawals via the Ethereum Wire Protocol.

withdrawal = {legacy-withdrawal, typed-withdrawal}

Untyped, legacy withdrawals are given as an RLP list as defined in EIP-4895.

legacy-withdrawal = [
    index: P,
    validator-index: P,
    address: B_20,
    amount: P,
]

Typed withdrawals are encoded as RLP byte arrays where the first byte is a withdrawal type (withdrawal-type) and the remaining bytes are opaque type-specific data.

typed-withdrawal = withdrawal-type || withdrawal-data

Networking

When exchanging SSZ withdrawals via the Ethereum Wire Protocol, the following withdrawal envelope is used:

  • Withdrawal: TRANSACTION_TYPE_SSZ || snappyFramed(ssz(Withdrawal))

Objects are encoded using SSZ and compressed using the Snappy framing format, matching the encoding of consensus objects as defined in the consensus networking specification. As part of the encoding, the uncompressed object length is emitted; the RECOMMENDED limit to enforce per object is 8 + 8 + 20 + 8 (= 44) bytes.

Rationale

This change was originally a candidate for inclusion in Shanghai, but was postponed to accelerate the rollout of withdrawals.

Why typed withdrawal envelopes?

The RLPx serialization layer may not be aware of the fork schedule and the block timestamp when withdrawals are exchanged. The typed withdrawal envelope assists when syncing historical blocks based on RLP and the MPT withdrawals_root.

Backwards Compatibility

Applications that rely on the replaced MPT withdrawals_root in the block header require migration to the SSZ withdrawals_root.

Clients can differentiate between the legacy withdrawals and typed withdrawals by looking at the first byte. If it starts with a value in the range [0, 0x7f] then it is a new withdrawal type, if it starts with a value in the range [0xc0, 0xfe] then it is a legacy withdrawal type. 0xff is not realistic for an RLP encoded withdrawal, so it is reserved for future use as an extension sentinel value.

Test Cases

TBD

Reference Implementation

TBD

Security Considerations

None

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by