bincode is not optimal

[sakridge]

Problem

For serialize/deserialize the validator uses bincode in many cases but bincode is known to not be optimal.

Proposed Solution

Convert bincode use-cases to other faster serialization libraries like speedy/borsh/capnproto. A more universal format would be nicer for interconnection with other languages and environments as well.

• Transactions
• Repair
• Gossip
• Shred payload

[bw-solana]

The major hangup I've encountered hacking at this quickly is deriving traits for the GenericArray struct (part of Signature struct)

[bw-solana]

Quick comparison of SerDes methods running cargo test --release --package solana-ledger --lib -- shredder::tests::test_data_shredder --exact --nocapture
In all cases, 1000 entries of 64B were used to generate the shreds.

Bincode (Default)

• serialize_time = 209us
• 251 shreds with size 184
• deserialize_time = 845us

Borsh

• serialize_time = 169us
• 262 shreds with size 184
• deserialize_time = 311us

speedy

• serialize_time = 60us
• 288 shreds with size 184
• deserialize_time = 460us

postcard

• serialize_time = 193us
• 237 shreds with size 184
• deserialize_time = 383us

Code can be found on this branch. Note the SerDes library must be selected via feature (sdbincode, sdborsh, sdspeedy, sdpostcard) and does not include changes made to local version of GenericArray crate (trivial trait derivations)

[bw-solana]

Given how sensitive our system is to shred volume, I'm wondering if something like postcard is the best option

[bw-solana]

Some more challenges uncovered looking into converting Shreds to use a different SerDes library:

1. There are assumptions around being able to use static offsets into byte vector to extract fields. This doesn't work with postcard as variables will be sized dynamically (e.g. only 1 byte to store slot if the value is <=255 whereas bincode will always use the full 8 bytes)
2. There is heavy reliance on bincode functions such as serialize_into and serialized_size that don't have direct equivalents in other libraries.

I believe these things can be worked around, but it is messy. 1 in particular makes me concerned regarding latency of extracting fields such as index, slot, version with dynamic sizing (we would have to perform a full deserialization). However, the dynamic sizing is what allows for tighter packing and reduced number of shreds.