Create Non-Indexing Module #7
Labels
enhancement
New feature or request
funded
Sponsorship goal reached for this issue
funding wanted
Sponsorship is requested for this issue
mining
Related to mining / pools
Create Non-Indexing Module
GitHub Issue #7
Problem Description
Currently Bitcoin Verde indexes large parts of the blockchain.
Indexed components include (but are not limited to):
Keeping indexes on these components greatly increases the disk footprint of the node, as well as increases the initial block download (and validation) time.
Indexing these fields with modern hardware, including an M.2 SSD, can take over a week.
These indexes also increase the CPU and RAM resources required to optimally run the node.
Despite being very useful for explorers and wallet services, these indexes are mostly unneeded for blockchain validation and provide no value for mining nodes.
Value Proposition
This solution will provide the following benefits:
Solution Overview
Running the non-indexing module inherently runs the node with the
cacheBlocks
option enabled.With
cacheBlocks
, blocks are stored serialized on-disk.Many of the transaction-, address-, and slp-related SQL tables will be removed.
A new
transactions
table will be created with columns that can be used to point to the location on disk where the transaction's block is stored, and an offset of where the transaction is within the block flat file.This migrates mined transactions from the database (which is indexed and normalized, which is space inefficient and less performant) to a more compact format in a flat file.
In order to keep mempool/unconfirmed-transaction logic consistent between modules, the former
transaction_*
tables will be renamed and reused for unconfirmed transactions.Having unconfirmed transactions indexed and normalized allows Bitcoin Verde to keep its infinite transaction-chaining limit, without any additional development.
As transactions are mined in a block they will be removed from the
unconfirmed_transactions_*
table, and will be only stored in block flat files.Since the transaction SQL tables will not be large, indexing only unconfirmed transactions nominally increases the disk footprint of the node, while still allowing extensibility for future features and complex decisions to be made regarding next-block inclusion of unconfirmed transactions.
Additionally, total transaction size and fee amount will be added to the transaction table to improve block template generation.
Changes will affect mostly the data-layer, which is encapsulated by the
TransactionDatabaseManager
and related classes. Validation logic and network logic may be minimally affected.Many of the existing tests depend on direct manipulation of the database's data for their setup.
With a different schema, these tests will be broken when run with the schema changes for this module.
The above schema changes won't cause the original test suite to break since the test suite loads the indexing schema by default.
However, with this configuration, many of the tests will not be run against the new schema, causing a fairly large gap in test coverage for critical functionality.
This proposal also includes extension to existing tests to include coverage of the non-indexing schema as well as the indexing schema.
Solution Milestones
SQL schema refactoring and data-layer migrations.
The first milestone will consist of the SQL schema and logic changes discussed in the solution overview. This milestone is considered completed once the tables are removed and the node successfully completes its initial block download on main-net.
Updating tests for new data-layer.
The second milestone consists of updating all broken tests to ensure existing regression tests pass.
Additionally, the second milestone includes expanding the existing test suite to run against both indexing and non-indexing schemas.
Month-long main-net tests ran via the block template aggregator.
The third milestone will conclude after the node is synced to main-net and its template block is deemed compatible with both Bitcoin ABC and Bitcoin Unlimited nodes. Completion of this milestone requires the node be updated for the new sigops ruleset included in the 2020-05 upgrade, and requires the template block aggregator be completed so that the template block generated by Bitcoin Verde may be automatically validated by other node implementations against current main-net nodes. After a month of creating main-net template blocks without incompatibility, the milestone will be deemed completed.
Estimated Relative Complexity
Budget
This proposal does not have a minimum starting budget.
Completing this proposal will require approximately
180 hours
.At a rate of
0.5 BCH/hr
, the total requested budget for this proposal is90 BCH
.Funding Address
Funding this proposal may be sponsored by sending Bitcoin Cash to the following address:
1716CkGxHLVj2q9b4hKxRb3KgY11xReiv8
(
bitcoincash:qpqa2x8cmrd2c6h6acnf7euqgkkl4prvwu7quzc4cc
)Authorization Signature:
The signature is signed with our primary donation address,
1VerdeMuXH1ApSZsQDkuHHZrwJaAtXTVn
, which can be found on bitcoinverde.org.The signature message consists of a Bitcoin Signed Message with the following format:
Issue-Number | Issue Title | Funding Address | Estimate Hours | Budget BCH
Notes:
Pre-image:
7|Create Non-Indexing Module|1716CkGxHLVj2q9b4hKxRb3KgY11xReiv8|180|90
Signature:
HO1xu3BDJopi/PsAK2sqql0pHD62KtnmmhqoVyzJWkuAA9N6vhla4Pz4ABkCWU+3Qw/fpY+9wsLwM1zR1XO1oDQ=
The text was updated successfully, but these errors were encountered: