Skip to main content

​
Overview

BlockDB’s indexers do far more than persist raw blockchain payloads.
Every dataset export passes through multi-layer cryptographic verification that:
  • recomputes Ethereum receipts roots,
  • reconstructs RLP-encoded logs from every contract emission,
  • validates per-transaction log blooms, and
  • enforces block continuity with zero gaps or mismatched parent hashes.
These checks ensure that all exported data is provably identical to what was produced on-chain - not just at ingest time, but at every stage of archival and replication. Verification breadcrumbs - including recomputed receipts roots and validation timestamps - are persisted directly in the blockdb0101_blocks_v1 table for transparent inspection.
BlockDB’s API exposes dedicated verification endpoints so clients can independently validate exported data on their side. See the Verification overview and endpoint docs for Verify receipt root and Verify logs bloom.

​
Self-verify a block (example)

curl -X POST "https://api.blockdb.io/v1/evm/verify/receipt-root" \
  -H "Authorization: Bearer $BLOCKDB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain_id": 1,
    "block_number": 12345678,
    "receipts": [ /* supply full receipt set */ ]
  }'
Compare the verification response against the block’s _computed_receipt_root in blockdb0101_blocks_v1. A match confirms integrity for that block.

​
Receipts-Root Recomputations

BlockDB independently reconstructs each block’s receipts trie to verify that the persisted transactions and logs exactly match the canonical chain state.

​
Verification Steps

1

Canonical Ordering

Transactions are sorted by their transactionIndex before encoding.
Any missing or duplicated index immediately fails verification.
2

Receipt Encoding

Each receipt is rebuilt from its persisted fields:
  • status (or legacy root)
  • cumulativeGasUsed
  • logsBloom
  • the RLP-encoded log list (LogsRlp), which is itself reconstructed from each log’s contract address, topics, and data.
3

Merkle Patricia Trie Rebuild

The reconstructed receipts feed into a deterministic trie builder that produces the canonical receipts trie root RLP.
4

Cryptographic Match

A Keccak-256 hash of the rebuilt root is compared against the chain-supplied receiptsRoot.
Any mismatch triggers an immediate blocking incident and is surfaced in the export logs.

​
Proof of Verification

Each successfully verified block stores two immutable breadcrumbs in blockdb0101_blocks_v1:
ColumnDescription
_computed_receipt_rootThe receipts root recomputed from verified transaction receipts.
_computed_receipt_timestamp_utcUTC timestamp when the recomputation occurred.
These fields allow consumers and auditors to independently confirm that BlockDB’s recomputation matched the chain-provided root at the time of export.

​
Log Bloom Coverage

Ethereum’s log blooms summarize who emitted logs and what topics were referenced in a block.
During receipts verification, BlockDB recomputes each transaction’s 2048-bit bloom filter by hashing:
  • the emitting contract address (20 bytes), and
  • every indexed topic (32 bytes) from its log entries.
A single differing bit causes the transaction to fail validation.
This mechanism detects subtle forms of corruption such as:
  • truncated topics,
  • mis-ordered logs, or
  • partial processing bugs
that might otherwise pass unnoticed if only receipts were checked.

​
Independent Archive Validation

In addition to live verification, BlockDB performs offline re-validation of data already exported to the Persistence Layer.
This validator replays all verification logic using only the data present in the Database — without depending on live node responses. It ensures that:
  • Long-term consistency across cold storage and replicas is preserved.
  • Block continuity remains intact — block numbers increment without gaps, and every parent_block_hash matches the previous block.
  • Data lineage between transactions and logs stays cryptographically valid even after archival compaction.
  • Historical reproducibility is maintained, proving that what left the exporter remains self-consistent at rest.
Because this process operates solely on exported data, it confirms integrity post-ingestion — a unique capability among blockchain data platforms.
Operators can safely run it on lagged replicas or analytical nodes without affecting live indexing performance.

​
Integrity Guarantees

The combination of LogsRlp reconstruction, receipts-root recomputation, and block continuity validation makes BlockDB’s verification pipeline uniquely resistant to silent corruption.
SafeguardEnsuresPrevents
LogsRlp rebuilt from each log’s address, topics, and dataLog-level completeness and byte-accurate reproduction of on-chain payloads❌ Missing or truncated logs
Receipts root recomputed from all transactionsTransaction-level integrity and Merkle proof consistency❌ Missing transactions
Block continuity validationContinuous block sequence and parent hash linkage❌ Missing or orphaned blocks
Archive re-validation using exported Database dataLong-term consistency and reproducibility independent of live nodes❌ Data drift, replica inconsistency, or corruption after export
These layers form a cryptographically auditable chain of evidence, far stronger than checksum-based or row-count validation methods.
By validating every byte that contributes to the receipts root, BlockDB ensures the exported dataset is both deterministic and verifiably complete.

​
Canonical Primary Keys (De-duplication)

To prevent duplicates across ingestion, BlockDB enforces stable, domain-correct primary keys:
  • blockdb0101_blocks_v1: block_number
  • blockdb0102_transactions_v1: tx_hash
  • blockdb0103_logs_v1: composite key (block_number, tx_index, log_index)
This mirrors how identity is defined on-chain and guarantees deterministic joins and idempotent re-ingestion.

​
Reorg-Tolerant Consistency

Our archive indexing operates with a bounded backoff from the chain tip (typically 20-100 blocks, chain-dependent).
This buffer provides consistency under chain reorganizations, ensuring that:
  • short-range reorgs don’t leak transient data into GA exports,
  • duplicate or orphaned records are avoided by primary-key constraints, and
  • final datasets reflect post-reorg canonical history.
Combined with LogsRlp reconstruction, full receipts-root recomputation across all transactions, and block continuity checks, this design robustly prevents:
  • missing or truncated logs,
  • missing transactions, and
  • missing or orphaned blocks.

​
Assurance Model

Together, these safeguards ensure that every BlockDB dataset remains trustworthy, reproducible, and independently auditable.
We recompute what matters — receipts roots, log blooms, and block continuity — and we store cryptographic evidence directly in the blockdb0101_blocks_v1 table so that integrity can be verified at any time.
For organizations that require deeper insight into the end-to-end verification pipeline or custom validation tooling, our team is happy to help.
You can reach us at [email protected] to discuss verification details, compliance documentation, or integration support.