Difference between revisions of "Libbitcoin Blockchain"
(stub) |
m (Initial content.) |
||
Line 1: | Line 1: | ||
− | + | The [https://github.com/libbitcoin/libbitcoin-blockchain libbitcoin-blockchain] library is a dependency of [[Libbitcoin_Node|libbitcoin-node]] and [[Libbitcoin_Server|libbitcoin-server]]. It was originally contained within [[Libbitcoin_Common|libbitcoin]]. | |
+ | |||
+ | ==Example== | ||
+ | #include <string> | ||
+ | #include <bitcoin/blockchain.hpp> | ||
+ | |||
+ | // Initialize the blockchain | ||
+ | int main(int argc, char* argv[]) | ||
+ | { | ||
+ | std::string prefix("blockchain"); | ||
+ | |||
+ | if (argc > 1) | ||
+ | prefix = argv[1]; | ||
+ | |||
+ | bc::chain::initialize_blockchain(prefix); | ||
+ | bc::chain::db_paths paths(prefix); | ||
+ | |||
+ | constexpr size_t history_height = 0; | ||
+ | bc::chain::db_interface interface(paths, { history_height }); | ||
+ | interface.start(); | ||
+ | const auto genesis = bc::genesis_block(); | ||
+ | interface.push(genesis); | ||
+ | |||
+ | return 0; | ||
+ | } | ||
+ | |||
+ | ==Design== | ||
+ | The original implementation used [http://leveldb.org LevelDB]. Following a redesign in late 2014 by [[Amir_Taaki|Amir Taaki]] (genjix) the database was replaced by a memory-mapped I/O implementation. Logical queries are performed using a set of hash tables. The number of hash buckets is optimized to minimize hash collisions, though collisions are accommodated. These changes resulted in a substantial performance increase for queries against the blockchain. Insert performance is was not materially affected and queries are near constant time. | ||
+ | |||
+ | [[Image:Libbitcoin-blockchain-gets.png|500px]] [[Image:Libbitcoin-blockchain-gets-normalised.png|500px]] | ||
+ | |||
+ | ==Considerations== | ||
+ | * There is no mechanical hard drive optimization. The implementation is intended for solid state drives ([http://en.wikipedia.org/wiki/Solid-state_drive SSD]). | ||
+ | * There is a possibility of index corruption during hard shutdown. There is no means of detecting corruption aside from catastrophic fault. However given that the entire blockchain is a cache this is not considered significant. Repair can be accomplished by re-synchronizing the blockchain. | ||
+ | * Data files are append only, with logical deletions only. Therefore file size is not minimized following blockchain reorganization although the impact is typically small. Defragmentation can be accomplished by re-synchronizing the blockchain. | ||
+ | * The database is effectively locked during write operations. As these operations are anticipated on a period of approximately ten minutes this is not typically significant. However during a period of catch-up synchronizing the server can become continuously unresponsive to requests. | ||
+ | |||
+ | ==Dependencies== | ||
+ | * [http://www.boost.org boost] | ||
+ | * [https://github.com/bitcoin/secp256k1 libsecp256k1] | ||
+ | * [[Libbitcoin_Consensus|libbitcoin-consensus]] (optional) | ||
+ | |||
+ | ==See Also== | ||
+ | * [[Libbitcoin]] | ||
+ | |||
+ | ==References== |
Revision as of 05:52, 14 May 2015
The libbitcoin-blockchain library is a dependency of libbitcoin-node and libbitcoin-server. It was originally contained within libbitcoin.
Example
#include <string> #include <bitcoin/blockchain.hpp> // Initialize the blockchain int main(int argc, char* argv[]) { std::string prefix("blockchain"); if (argc > 1) prefix = argv[1]; bc::chain::initialize_blockchain(prefix); bc::chain::db_paths paths(prefix); constexpr size_t history_height = 0; bc::chain::db_interface interface(paths, { history_height }); interface.start(); const auto genesis = bc::genesis_block(); interface.push(genesis); return 0; }
Design
The original implementation used LevelDB. Following a redesign in late 2014 by Amir Taaki (genjix) the database was replaced by a memory-mapped I/O implementation. Logical queries are performed using a set of hash tables. The number of hash buckets is optimized to minimize hash collisions, though collisions are accommodated. These changes resulted in a substantial performance increase for queries against the blockchain. Insert performance is was not materially affected and queries are near constant time.
Considerations
- There is no mechanical hard drive optimization. The implementation is intended for solid state drives (SSD).
- There is a possibility of index corruption during hard shutdown. There is no means of detecting corruption aside from catastrophic fault. However given that the entire blockchain is a cache this is not considered significant. Repair can be accomplished by re-synchronizing the blockchain.
- Data files are append only, with logical deletions only. Therefore file size is not minimized following blockchain reorganization although the impact is typically small. Defragmentation can be accomplished by re-synchronizing the blockchain.
- The database is effectively locked during write operations. As these operations are anticipated on a period of approximately ten minutes this is not typically significant. However during a period of catch-up synchronizing the server can become continuously unresponsive to requests.
Dependencies
- boost
- libsecp256k1
- libbitcoin-consensus (optional)