Data Observability and Testing Methodology

It is crucial to ensure the accuracy and integrity of data through thorough validation and verification processes. Cross-referencing the blockchain data with reputable third-party sources adds an additional layer of validation, reducing the risk of relying on potentially flawed information. Implementing redundancy measures ensures that data remains available and trustworthy even in the face of system failures.

Flipside Data employs self-healing techniques. Self-healing data refers to systems that automatically detect and repair errors or inconsistencies in data without manual intervention. It ensures data integrity and availability by employing techniques like replication, redundancy, and automated recovery processes. These mechanisms minimize the risk of data loss, improve system reliability, and reduce downtime. Self-healing data is crucial in critical applications where maintaining accurate and accessible data is essential.

By testing the data on a rigorous schedule and providing insight into that testing Flipside blockchain data has achieved a higher level of reliability and established itself as a trusted and immutable source of truth.

Methodology for Data Completeness Testing and Observability

Every chain is tested every 4 hours, with specific minutes allocated for each test. The look back period for this is three days. Exceptions include chains that are only processed once a day ie: Cosmos. Once a month, the entirety of the chain is once again retested.

Tests:

• Blocks
  • Ordered and checked for continuity, triggering a failure if there is a break in the sequence.
• Transactions
  • EVM: A call is done to the node 6 hours behind chainhead, to avoid and detect transaction re-organized. This call returns the transaction hashes per block, which is used to test if the transactions loaded into fact_transactions match exactly. Any differences between these two tables flags as a failure.
  • IBC: A separate call is made to get the transaction count for the block. That number is compared to the raw count available.. If those numbers do not match a failure is triggered.
• Receipts (EVM):
  • Every transaction should have a receipt. Any differences between the tables triggers a failure.
• Event_Logs (EVM)
  • Every receipt with logs should exist in fact_event_logs. Any differences between the tables triggers a failure.
• Traces (EVM)
  • Every receipt with logs should exist in fact_traces. Any differences between the tables triggers a failure.

Documented known issues and excluded from tests until can be resolved:

• Ethereum
  • 91 blocks from the 3.8m range unavailable from July 2017. Known issue and will be resolved by Flipside.
• Arbitrum
  • 2 blocks contain duplicate transaction hashes from previous blocks. These transactions do not have matching receipts. No known fix.
  • Tests starts at block 22,207,815 (August 31, 2022). Origin record is needed for test, which only started producing at a specific block. No known way to test before this date.
  • System transactions are excluded from 0x000000000000000000000000000000000000006e as they do not produce traces.
• Polygon
  • 2 blocks from the 31.6m range unavailable from August 2022. Known issue and will be resolved by Flipside.
  • System transactions from 0x0000000000000000000000000000000000000000 are excluded from the test as they do not produce traces.
• Optimism
  • Known blocks missing - update when the spreadsheet is updated.
• Cosmos
  • Cosmos 1-3 has not been ingested into Flipside data yet. The data starts at 12/11/2019. Goal is to have this data by the beginning of 2024.

All testing details can be found here.

Flipside SLAs

Flipside strives to have 100% of data that is available coming off the nodes. Data complexity can arise from the sheer volume of data being collected. Complex data structures, diverse data sources, or unstructured data formats can introduce challenges leading to missing or incomplete data. Certain data types or sources may pose technical difficulties in capturing or extracting data accurately. For example, data from external platforms or third-party systems that have limited accessibility or compatibility, which could result in missing data. Moreover, in cases where data is generated in real-time or near real-time, there may be instances of latency or delays in capturing and processing the data, leading to a slight data lag and resulting in a fraction of the data being missed. The way Flipside ingests and tests data, it should account for a lag or missed data, but it could happen.

Flipside has the computational capabilities to test the entire blockchain on a regular basis and have a comprehensive analysis on each of the chains with visual outputs to help understand if there are limitations on the data. Since each chain has different technical complexities Flipside aims to have at minimum:

• 99.5% complete data for EVM technology chains
• 99% complete data for all IBC technology chains
• 95% complete data for all other chains

When tests are failing - no matter how small the missing percentage missed, Flipside is dedicated to rectifying the missing data. If an immediate fix is not available, we make sure that it is well documented with annotations on whether there is a known fix or not.

Other tests not included in the data completeness testing and observability:

• Duplicate testing - making sure that there are no duplicates in the data.
• Null - key columns are checked to make sure they are no nulls where there should not be.