The current encoding of Currency uses an 8-byte length prefix followed by a variable-length big-endian encoding of the integer. This is inherently wasteful, as currency values never require more than a 1-byte prefix. Variable-length encodings can also hurt performance in certain use cases, and make it harder to predict the real-world size of various encoded payloads.
This PR adds an alternative fixed-width (16-byte) little-endian encoding for Currency. This matches the actual struct definition of Currency in core: two uint64s. Surprisingly, this is not quite as efficient as simply reducing the 8-byte prefix to a 1-byte prefix; the currency values currently present in the blockchain would encode to between 11-15 bytes on average. Still, the advantages of fixed width outweigh the slightly larger size imo.
As a side effect, I also ended up changing the encoding of SiafundOutput to be more compact in v2.
The current encoding of
Currencyuses an 8-byte length prefix followed by a variable-length big-endian encoding of the integer. This is inherently wasteful, as currency values never require more than a 1-byte prefix. Variable-length encodings can also hurt performance in certain use cases, and make it harder to predict the real-world size of various encoded payloads.This PR adds an alternative fixed-width (16-byte) little-endian encoding for
Currency. This matches the actual struct definition ofCurrencyincore: twouint64s. Surprisingly, this is not quite as efficient as simply reducing the 8-byte prefix to a 1-byte prefix; the currency values currently present in the blockchain would encode to between 11-15 bytes on average. Still, the advantages of fixed width outweigh the slightly larger size imo.As a side effect, I also ended up changing the encoding of
SiafundOutputto be more compact in v2.