Eth2.0-specs: Could SSZ be replaced through protocol buffers?

[decanus]

Abstract

The goal of this issue is to start a discussion on whether abandoning SimpleSeralize and replacing it with ProtocolBuffers is a possibility, and whether this change should be adopted.

Motivation

The reason for proposing this, would be to reduce the amount of new standards created by eth2.0 and fallback on robust technologies with already various implementations in the languages currently being used to build eth2.0 clients.

Changes

Changes to the specification would include changing all DataStructures to Protocol Buffer proto's, this could also help reduce the requirement of implementation as anyone would be able to generate the data structures for their specific implementation from these protos.

The hash function could remain as is, but the way it is called could be changed. Changing it to being called with the already byte encoded proto.

[paulhauner]

See: https://github.com/ethereum/eth2.0-specs/issues/129

TLDR;

1. Protobuf is non-deterministic, therefore not suitable for hashing.
2. It's potentially a good candidate for network serialization, but there are some downsides with fixed-length array support and it being key-value.

[decanus]

@paulhauner yeah, I spoke with @prestonvanloon and he mentioned that the fact that they are non-deterministic means they can't be used. I still question if we should discuss reducing the usage of SSZ over all and stick to protocol buffers for all p2p communication.

Potentially discussing changing SSZ to define a seralization standard for Protocol Buffers would also be a possibility.

[paulhauner]

See also some brief analysis here: https://github.com/sigp/serialization_sandbox/blob/report/report/serialization_report.md. That is from a spec many moons ago, so it's very outdated!

Protobuf is marginally bigger on the wire than SSZ. You'd probably want to do some more analysis before you make a firm judgement on that, though.

If we really want to see gains from proto we'd make SSZ an encode-only format. Whilst that's probably cpu-cycles-optimal, I'm not sure it's meeting-project-deadlines-optimal.

Personally, I'm fine for either SSZ or protobuf across the wire -- I'm using protos for the node API so it's minimal effort for me to switch between them.

[djrtwo]

Another reason for SSZ for consensus is the tree hashing algorithm. We need to be able to cache large portions of the state that _do not_ change at state updates to reduce load of hashing the large state object at each slot/epoch

[JustinDrake]

Could SSZ be replaced through protocol buffers?

I think the answer is pretty clear: "No" :) Closing for now!