BaseChainDB no longer supports a header-only DB
See original GitHub issueWhat is wrong?
BaseChainDB._set_as_canonical_chain_head()
now expects the DB to contain transactions as well, and that breaks LightChain
since it only syncs headers.
When there’s a chain reorg, that method will try to remove tx lookups from the DB, but that crashes because we have no transactions in the DB
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Basic Usage Examples — BigchainDB Javascript Driver 0.0.1 ...
If the BigchainDB node requires special HTTP request headers (such as app_id and app_key ) ... the first node does not use custom...
Read more >bigchaindb/bigchaindb - Gitter
Hi, During the past few days, I started getting a "INTERNAL SERVER ERROR" response when posting transactions to the test network. I am...
Read more >bigchaindb/CHANGELOG.md at master - GitHub
The main BigchainDB Dockerfile (and its generated Docker image) now contains only BigchainDB Server. · Made separate schemas for CREATE and ...
Read more >The Transaction, Block and Vote Models — BigchainDB 0.5.1 ...
Currently, BigchainDB only supports indivisible assets. You can't split an asset apart into multiple assets, nor can you combine several assets together ...
Read more >A Survey of Ledger Technology-Based Databases - MDPI
Blockchain is an append-only ledger technology that endeavours to be ... database with tamper-evidence and non-repudiation features similar ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
We might want to take it a step further and have one DB containing just the headers and another one containing just the block bodies/receipts. That would potentially allow us to have a single header DB for both light/full modes. Also, given the way full-node sync should be implemented (i.e. fetching/validating header chains before fetching the block bodies), having separate DBs would make it easier for us to parallelize parts of it
We now have separate
HeaderDB
andChainDB
classes, and the former’s_set_as_canonical_chain_head()
method doesn’t expect the DB to contain transactions in case of a chain reorg, so this is fixed