#codec #string #decoding #encoding #leveldb #format-string #length

bitcoinleveldb-coding

endian-neutral encodings for the bitcoin leveldb -- fixed-length numbers are encoded LSB first. Strings are encoded prefixed by their length in varint format

3 releases

0.1.16-alpha.0 Apr 1, 2023
0.1.12-alpha.0 Jan 19, 2023
0.1.10-alpha.0 Jan 18, 2023

#42 in #leveldb

Download history 152/week @ 2023-12-13 190/week @ 2023-12-20 78/week @ 2023-12-27 99/week @ 2024-01-03 137/week @ 2024-01-10 161/week @ 2024-01-17 59/week @ 2024-01-24 55/week @ 2024-01-31 84/week @ 2024-02-07 152/week @ 2024-02-14 118/week @ 2024-02-21 144/week @ 2024-02-28 114/week @ 2024-03-06 114/week @ 2024-03-13 201/week @ 2024-03-20 267/week @ 2024-03-27

730 downloads per month
Used in 66 crates (via bitcoin-leveldb)

MIT license

390KB
821 lines

bitcoinleveldb-coding is a Rust crate that provides encoding and decoding functions for various data types used in the Bitcoin system. This crate is part of a direct translation from C++ to Rust of the Bitcoin Core, which means that some of the function bodies may still be in the process of translation. However, once the translation process is complete, this system will become testable.

Some of the tokens in this crate, such as coding_varint32, coding_varint64, and varint_length, involve the encoding and decoding of variable-length integers. These are useful for efficiently storing and transmitting integers that may have varying sizes. The encoding process involves splitting the integer into 7-bit chunks, with the high bit of each chunk set to 1 except for the last chunk. The chunks are then stored in a byte array in little-endian order. Decoding the integer involves reversing this process.

Other tokens, such as coding_fixed32, coding_fixed64, decode_fixed32, and decode_fixed64, involve encoding and decoding fixed-length integers. These are useful for efficiently storing and transmitting integers that have a fixed size.

There are also tokens related to encoding and decoding strings, such as coding_strings and get_length_prefixed_slice. These are useful for storing and transmitting variable-length strings in a compact and efficient way.

Overall, the bitcoinleveldb-coding crate provides useful encoding and decoding functions for various data types used in the Bitcoin system, making it a valuable tool for developers working with Bitcoin-related data.

28> thanks -- could you teach me more about these encoding/decoding formats in the context of leveldb

Sure! In the context of LevelDB, these encoding and decoding formats are used for storing and retrieving key-value pairs in a compact and efficient way. Specifically, LevelDB uses a combination of variable-length integer encoding and length-prefixed strings to achieve this.

Variable-length integer encoding, implemented by the coding_varint32, coding_varint64, and varint_length functions in the bitcoinleveldb-coding crate, is used to store integer values that may have varying sizes. In LevelDB, these integers are typically used as keys to identify a specific value in the database. By encoding these integers as variable-length integers, LevelDB can store the integers using fewer bytes than if they were encoded as fixed-length integers.

Length-prefixed strings, implemented by the get_length_prefixed_slice and put_length_prefixed_slice functions in the bitcoinleveldb-coding crate, are used to store string values in the database. In this encoding format, a string is prefixed by its length, which is encoded as a variable-length integer. This allows LevelDB to efficiently store and retrieve string values of varying lengths.

The coding_fixed32, coding_fixed64, decode_fixed32, and decode_fixed64 functions in the bitcoinleveldb-coding crate are used to encode and decode fixed-length integers. While these encoding formats are not used as frequently in LevelDB as variable-length integer encoding and length-prefixed strings, they are still useful for efficiently storing and retrieving integer values that have a fixed size.

Overall, these encoding and decoding formats are essential for efficient data storage and retrieval in LevelDB, and are therefore an important part of the LevelDB system.

Dependencies

~87MB
~801K SLoC