Understanding SimpleSerialize (SSZ) in Ethereum 2.0

Amsterdam

SimpleSerialize, commonly referred to as SSZ, is a pivotal serialization format employed in Ethereum 2.0. This article delves deep into the intricacies of SSZ, its objectives, and its practical applications.

graph TD A[root] B[node_1] C[node_2] D[id] E[bytes_root] F[next] G[ZERO_LEAF] H[bytes] I["len(bytes)"] A --> B A --> C B --> D B --> E C --> F C --> G E --> H E --> I

What is SimpleSerialize (SSZ)?

SSZ is the canonical serialization format that Ethereum 2.0 relies on. It serves two primary functions:

  • Encoding/Decoding: This pertains to the conversion of Ethereum 2.0 data structures, such as BeaconBlock or BeaconState, into byte strings. These byte strings can then be transmitted across networks or archived in databases.
  • Merkleization: This process determines the hash of a specific data structure. It's worth noting that this is a Merkle root, distinct from a conventional hash.

Goals of SSZ

While there hasn't been an official declaration regarding the objectives of SSZ, the following can be inferred as its primary goals:

  • Simplicity: SSZ was conceived as a more straightforward alternative to RLP, Ethereum 1.0's encoding scheme.
  • Bijectiveness: Each type instance should have a unique SSZ representation, ensuring that different byte sequences don't represent the same BeaconBlock. This bijectiveness ensures that the SSZ encoding acts as an identifier for that instance.
  • Compactness: Given that SSZ bytes are transmitted over networks, they need to be concise without compromising on simplicity.
  • Merkle-first Design: SSZ is inherently compatible with Merkle-proof schemes, which will be more prominent in Ethereum 2.0's later phases.
  • Efficient Traversal: The inclusion of the "offsets" scheme in SSZ ensures that serialized structures can be navigated efficiently. This is particularly beneficial for environments with constraints, such as the Ethereum Virtual Machine (EVM), which might need to access a single struct field without decoding the entire entity.

Encoding/Decoding with SSZ

To elucidate the encoding and decoding process, consider the following hypothetical data structure:

Solidity
class Example:
    id: uint64,
    bytes: List[uint8, 64]
    next: uint64

For instance, if we instantiate it as:

Solidity
my_example = Example(id=42, bytes=List[0, 1, 2], next=43)

The serialized output would be:

Solidity
[
  42, 0, 0, 0,  # `id` encoded in little-endian format.
  12, 0, 0, 0,  # Offset indicating the start of `bytes`.
  43, 0, 0, 0,  # `next` encoded in little-endian format.
  0, 1, 2       # Value of the `bytes` field.
]

Merkleization in SSZ

Instead of using a straightforward SHA256 hash of a block's encoding for identification, Ethereum 2.0 employs Merkle-roots. This decision was made to facilitate light clients and execution environments with Merkle-proofs, enabling them to access parts of the Ethereum 2.0 state.

However, using Merkle-roots as the standard hash introduces computational challenges. For instance, in the Lighthouse client, the primary syncing bottleneck is executing these Merkle-hashes.

FAQs

  • What is the primary purpose of SSZ in Ethereum 2.0? SSZ is used for encoding and decoding data structures and for Merkleization in Ethereum 2.0.
  • How does SSZ differ from Ethereum 1.0's RLP? SSZ is designed to be simpler and more efficient than RLP, with a focus on Merkle-first design and efficient traversal.
  • Why does Ethereum 2.0 use Merkle-roots instead of simple hashes? Merkle-roots are used to provide light clients and execution environments with Merkle-proofs, allowing them to access specific parts of the Ethereum 2.0 state.

Author