The nature of the blockchain is that it is a public ledger, meaning that anyone is able to conduct activity on the blockchain. With the amount of activity that occurs on the blockchain (for instance, at full capacity the Solana blockchain alone can generate 4 PB of data per year!), there are bound to be issues that arise when ingesting the data. Whether you are running ETL processes, hitting APIs, or building your own nodes, there is always a potential risk of ingesting incorrect data due to reorgs, smart contract bugs, or general human error, among other potential vulnerabilities on the blockchain.

This is where SonarX comes in! SonarX (formerly Sonarverse) underscores its unwavering commitment to superior data quality through the Data Quality Trust Center, showcasing the comprehensiveness of its data quality procedures. Through rigorous checks applied to datasets, SonarX upholds the highest standards of data completeness and accuracy. Continue reading to understand the types of blockchain issues that SonarX’s Data Quality process effectively identifies and addresses.

Managing Reorgs at the Block Level

Impacted Chains:

• Ethereum Classic
• All other chains

Issue:

Reorgs, or reorganizations, occur on a blockchain when a longer valid chain replaces a shorter one. This is usually due to the addition of new blocks or resolution of network forks. Blockchain reorgs help maintain consensus and integrity by ensuring that the majority of network participants agree on the valid transaction history.

Example: Ethereum Classic

Block 19250154’s parent hash doesn’t match the hash of block 19250153. After reingesting, we found that Block 19250153’s parent hash did not match the hash of Block 19250152, and so on until back in Block 19250102. This meant that a reorg had occurred on the chain at Block 19250154.

Block Hash of Block 19250153 at time of first ingestion: 0x2e40b8fd0c3dd79d3fb23346261b3f56b00294ed5eabed6584eaa1d917a14ba0

Parent Hash of Block 19250154 according to Ethereum Classic Explorer:

0xf766edf23809ad9597ad9ac37135113d214fe57f9dfb370c8e2b6eda5d8b9add

This indicates that at Block 19250154, a reorg occurred causing there to be an incorrect lineage for ~50 blocks, meaning that these blocks contained incorrect data.

How SonarX Addresses:

SonarX handles reorganizations by validating each block hash - parent hash pairing to ensure that the chain is complete and accurate from genesis to tip.

Null Receipt Data on a Valid Transaction

Impacted Chains:

• Polygon
• EVM Chains

Issue:

When pulling transaction data off the blockchain, for certain blocks all transaction fields show up as null, even when it is a valid transaction.

Example: Polygon

When ingesting receipts data block 53085376, the output was “null,” as demonstrated below:

{
   "block_number": 53085376,
   "data": null
}

However, according to the Polygon Explorer, this block contains valid transactions.

How SonarX Addresses:

SonarX validates that each transaction has a matching receipt and checksums on the receipts.

Upon reingestion, we were able to get the correct data.

{
   "block_number": 53085376,
   "data": [{
           "blockHash": "0xc2c119387cca7c8b87caa67761380a35a127ffb7dfc6c40f709cdbd05ac7f687",
    "blockNumber": "0x32a04c0",
    "contractAddress": null,
    "cumulativeGasUsed": "0x5208",
    "effectiveGasPrice": "0x1014a3e4422",
    "from": "0x866618685a15359c55acb5be0127bcb177e12aa9",
    "gasUsed": "0x5208",
    "logs": [..]
    },...,]
}

Mismatch in Raw Parity Trace Data

Impacted Chains:

• Binance
• EVM Chains

Issue:

Raw Parity Trace data has a block number that does not match the expected block number based on parent-child linkage.

Example: Binance

Transaction Hash: 0x642fcc448a15c82393448655a80eee3c59de4d3a9b25e92e92d0cc0593a5e2ff

Expected block number: 18706219

Correct block number when cross-checked on BNB Smart Chain Explorer: 26776399

How SonarX Addresses:

SonarX employs checksums to verify the expected parity traces against the raw parity traces. Checksums serve as a method to ensure the integrity and accuracy of data by calculating the sum total of transactions, receipts, logs, or any relevant field. The calculated checksums are compared with the expected values derived from raw parity traces to ensure that the correct data is attributed to a sequence.

Mismatched Block Hash on Receipt Data

Impacted Chains:

• Binance
• Polygon

Issue:

When initially ingesting raw receipt data on EVM-compatible chains, an incorrect block hash value was assigned to receipts when making calls for a transaction hash on a specific block number.

Example: Binance

Block: 33057998

Initially ingested block hash value from receipt data: 0x04bbd0e10c7031fed638ef5d7cd971cf5cef6b7a6e12f2623c70c28cfc7381d2

Correct block hash when cross-checked on BNB Smart Chain Explorer: 0xf504d4a96e5415a02668fd2f3c14a457a4748e9ce247642d0fc0b9abde183cf8

How SonarX Addresses:

SonarX uses match checks to validate that all transactions and receipts ingested from the node are consistent with one another and to the block they are ingested from. This ensures consistent data across all data ingested, even when separate calls are needed to ingest the full dataset.