Switch integer encoding to big-endian

[carver]

Thoughts on changing the integer encoding to big-endian?

Everywhere else that I know of uses big-endian (like all the storage, balance, nonce, etc fields). Is there a benefit to introducing a different encoding that I'm missing?

[AlexeyAkhunov]

Yeah, it must have been a typo

[poemm]

Not a typo. Little-endian was chosen because <U32> represents a 32-bit unsigned integer, which most modern machines handle internally as little-endian. Using big-endian instead would require reversing bytes each time a <U32> is parsed or generated. Edit: Luckily, compilers can pattern-match to bswap.

There were similar endianness discussions in eth2 specs.

I consider this to be non-critical. Either way is fine. This change is OK with me. And it is OK to revert back to little-endian if people want this optimization later.

[poemm]

Another possibility is compressing <U32> with LEB128 encoding. (And avoid ambiguity in LEB128 by requiring the shortest encoding for each integer, but I am not sure whether this gets rid of all ambiguity.)

Edit: A similar variable-length encoding VLQ has a way to remove ambiguity.

[mandrigin]

I will merge it for now and add an issue to define uint compression.

[mandrigin]

the compression-related issue: #30