I think it’s more like we shifted from P2P serialization to asking ourselves if we should use the same serialization for P2P message and consensus layer objects: what are the requirements for both, are they compatible and what are the pros and cons of each library with regards to both hence the latest questions of both @hwwhww and me to try to understand all concerns.
Now regarding your initial remarks for the alternative scheme I proposed:
-
The JSON can be constrained to lexicographical order for our needs. Also it includes the offset at which the data start, combining it with the type/size in the schema you have the offset. Alas computing the offset wouldn’t work if dynamic length fields are to be serialized.
-
External agreement take several forms:
- Specification defined. Then everyone implements the specs. Serialization should include at least spec version and then can be only binary in this case.
- Before sending raw data, send the schema, then the data. This is similar to what I proposed.
-
True, we need to read the schema to deserialize, it’s replacing the need of external agreement, everything is done in a single handshake.
Regarding consensus layer objects, a colleague reminded me that the following properties were desirable which prevents using an off-the-shelf solution at all: Blob serialisation - #5 by vbuterin