Published on: 2015-09-23T00:10:50+00:00
Eric Lombrozo proposed a long-term plan for bitcoind in 2015, which involved several steps. The first step was to define an API for libconsensus, which would support an abstract DB model, track chain state, provide query mechanisms for blocks and transactions with optional pruning and indexing, expose a subscription mechanism for events such as NEW_TIP, REORG, etc., and contain a script interpreter. This library could be developed alongside Bitcoin Core without major changes to the core itself.The second step in the plan was to develop a peer services library that handles peer discovery and relay tasks. This library would use libconsensus for validation functionality and as a datastore for the consensus state, but maintain its own database for peer history and statistics.The third step involved providing high-level calls and pub/sub mechanisms for API/RPC. Additionally, the wallet was suggested to be split into a separate process that connects to the stack via the API/RPC layer.Jorge Timón supported this long-term vision and proposed that bitcoind becomes a subtree of bitcoin-wallet, which already includes bitcoin-qt. He also suggested that upper layers should be migrated to C++11. This architecture was believed to maximize the number of people who can contribute safely to the project.In a Bitcoin development mailing list, Wladimir J. van der Laan shared his vision for Bitcoind as a P2P node with validation and blockchain store. The idea was to have data sources that could be subscribed to or pulled from. Another contributor agreed with the long-term plan and suggested two steps for its implementation. The first step involved moving Libconsensus to a subtree, including libsecp256k1 as an internal subtree. The second step was to make Bitcoind a subtree of bitcoin-wallet. The proposed architecture had bitcoin-qt on top of bitcoin-wallet, which is on top of bitcoind and other components like bitcoin-cli and bitcoin-tx. Finally, bitcoind would be on top of libconsensus, which would be on top of libsecp256k1.The goal of this proposed architecture was to maximize the number of people who can safely contribute to the project. It was considered to align with the long-term vision shared by most contributors. However, criticisms and feedback for the plan were welcomed.
Updated on: 2023-08-01T16:14:01.670159+00:00