TODO: Decide on varint Implementation about runestone HOT 8 CLOSED

I am a large proponent of VLQ, it matches the UTF-8 endianness, and is used a lot everywhere.

from runestone.

Here is my JS/TS implementation of PrefixVarint: https://gist.github.com/revofusion/ba74dc11e0b007feba84b7b492e5ee87

Similar rust implementation at: https://github.com/otake84/dlhn/blob/22ce82ab3740328ff7041b63f77ee70020605b1c/dlhn/src/prefix_varint.rs#L5

from runestone.

I'm writing a prefix varint implementation that supports u128. Prefix varints are nice, fast, and compact, but they are quite tricky, so implementation complexity is a downside.

from runestone.

@revofusion the only problem I have for this implementation is that it only supports max_uint64, when we need to support at least max_uint128 for transfer amount. I would be ok with a generic prefix varint impl that doesn’t stop at any integer size limit.

from runestone.

Please provide a high level overview of your prefix varint for u128 when you get a chance so those interested can provide any feedback or gain consensus, especially since the runestone is essentially a lot of varints.

from runestone.

I've been fooling around with u128 varints, and found them very complex, and no more compact than LEB128 and VLQ. (I thought that a 128 bit prefix varint could save 1 byte over LEB128, but it turns out that only works for a 64 bit prefix varint.)

I opened PR #24 implementing VLQ varints. It's still a draft, it only contains the varint implementation, and does not integrate it into the runestone encoder or decoder.

from runestone.

This is very dependent on the distribution of values. For example if we use deltas extensively, as in #9, then zero is likely to be a common value. We could use a varint implementation where zero is encoded as a single bit as an optimization.

from runestone.

Closing in favor of #53.

from runestone.