You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A brief overview of our current database structure, our issues with it and my plans to change it. Only the block tables are mentioned below - The other tables are not relevant.
Current Structure (SQLite)
Table
Key
Value
Notes
blocks
block_hash
(block_without_txns, is_canonical)
is_canonical means the block was on the most recently executed fork. It is not related to finalization.
transactions
txn_hash
txn
receipts
txn_hash
(receipt, block_hash)
Issues
'canonical' is not a meaningful property of blocks. It should not exist. It causes confusion and bugs.
It is impossible to represent some valid states of the chain. Multiple unfinalized blocks may exist which contain overlapping transactions, but there is no way to represent this. This is no longer true as of Don't delete transaction receipts when a block is 'reverted' #2588.
Table keys are not efficient. Perhaps this isn't such an issue in SQLite, but generally databases are happier when keys are contiguous sequences of numbers. This is especially true in B-tree-based databases such as redb.
is_canonical means the block was on the most recently executed fork. It is not related to finalization.
transactions
txn_hash
txn
receipts
txn_hash
receipt
This has most of the same issues with the existing structure, but moving the block -> transaction mapping lets us fix issue (2) above in the next version...
Version 2.5 Structure (No migration needed)
Table
Key
Value
Notes
blocks
view
block
Only finalized blocks are stored. Unfinalized blocks are stored in memory.
transactions
txn_hash
txn
Only transactions in finalized blocks are stored.
receipts
txn_hash
receipt
Only receipts in finalized blocks are stored.
This version removes all mentions of 'canonical' from our code base and fixes the transaction-representation issue (i.e. fixes issues (1) and (2)). We can move to this version without any data migration, by just dropping the is_canonical blocks table.
Version 3 Structure (Migration needed)
Table
Key
Value
Notes
headers
height
header
Only finalized blocks are stored. Unfinalized blocks are stored in memory.
txn_indices
height
(first_txn, txn_count)
Stores an index and count into the transactions/receipts table, representing the transactions contained in this block.
aggregate_qcs
height
[qc]
Stores the aggregate QC for a block, as a list of QCs, if there is one.
transactions
txn_index
txn
Only transactions in finalized blocks are stored.
receipts
txn_index
receipt
Only receipts in finalized blocks are stored.
This makes all table keys contiguous integers (fixes issue (3)) and splits blocks into a fixed-length header, plus a variable number of transactions and QCs. It also unlocks large speed ups when syncing, by allowing block headers to be downloaded separately straight into the database and means blocks which don't contain transactions or QCs can be skipped.
The text was updated successfully, but these errors were encountered:
A brief overview of our current database structure, our issues with it and my plans to change it. Only the block tables are mentioned below - The other tables are not relevant.
Current Structure (SQLite)
block_hash
(block_without_txns, is_canonical)
is_canonical
means the block was on the most recently executed fork. It is not related to finalization.txn_hash
txn
txn_hash
(receipt, block_hash)
Issues
It is impossible to represent some valid states of the chain. Multiple unfinalized blocks may exist which contain overlapping transactions, but there is no way to represent this.This is no longer true as of Don't delete transaction receipts when a block is 'reverted' #2588.Version 2 Structure (Migration to redb) #2646
view
(block, is_canonical)
is_canonical
means the block was on the most recently executed fork. It is not related to finalization.txn_hash
txn
txn_hash
receipt
This has most of the same issues with the existing structure, but moving the
block -> transaction
mapping lets us fix issue (2) above in the next version...Version 2.5 Structure (No migration needed)
view
block
txn_hash
txn
txn_hash
receipt
This version removes all mentions of 'canonical' from our code base and fixes the transaction-representation issue (i.e. fixes issues (1) and (2)). We can move to this version without any data migration, by just dropping the
is_canonical
blocks table.Version 3 Structure (Migration needed)
height
header
height
(first_txn, txn_count)
height
[qc]
txn_index
txn
txn_index
receipt
This makes all table keys contiguous integers (fixes issue (3)) and splits blocks into a fixed-length header, plus a variable number of transactions and QCs. It also unlocks large speed ups when syncing, by allowing block headers to be downloaded separately straight into the database and means blocks which don't contain transactions or QCs can be skipped.
The text was updated successfully, but these errors were encountered: