Libbitcoin Blockchain: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Evoskuil (talk | contribs)
stub
 
Evoskuil (talk | contribs)
m Initial content.
Line 1: Line 1:
This page is a stub.
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

See Also

References