Libbitcoin Blockchain: Difference between revisions
Jump to navigation
Jump to search
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)