BlockDB Canonical Raw Logs (Lineage-Verified) | Ethereum & EVM Chains | Historical, EOD, ...

Dataset Overview
Each row represents a unique log emitted during transaction execution:
• Canonical positioning: (block_number, tx_index, log_index)
• Emitting contract address
• Primary event topic (topic_zero)
• Additional topics (data_topics)
• Raw event data payload

All fields are stored exactly as produced by the node, with direct RLP verifiability for topics, data, and contract address.

Every log includes a deterministic _tracing_id that links the record to its genesis event and upstream transaction, forming the foundation for decoded events, swaps, liquidity, NFT events, and custom protocol decoders in downstream BlockDB products.

Chains and Coverage
ETH, BSC, Base, Arbitrum, Unichain, Avalanche, Polygon, Celo, Linea, Optimism (others on request).
Full history from chain genesis; reorg-aware real-time ingestion and updates.

Schema
List of columns exactly as delivered:
• block_number BIGINT – Block number that contains the emitting transaction
• tx_index INTEGER – Zero-based index of the transaction within the block
• log_index INTEGER – Zero-based position of the log within the transaction
• contract_address BYTEA – 20-byte address of the contract that emitted the log
• topic_zero BYTEA – 32-byte primary topic hash identifying the event type (NULL for anonymous events)
• data_topics BYTEA[] – Array of additional topics (topics[1..n]), as raw bytes
• data BYTEA – Raw event data payload as emitted on-chain
• _tracing_id BYTEA – Deterministic lineage identifier of this log record
• _created_at TIMESTAMPTZ – Record creation timestamp
• _updated_at TIMESTAMPTZ – Record last update timestamp

Notes
• Primary key: (block_number, tx_index, log_index) guarantees canonical ordering and uniqueness.
• Foreign key: (block_number, tx_index) links each log directly to its canonical transaction record.
• Indexes on contract_address, topic_zero, and (contract_address, topic_zero) support fast protocol- or event-specific scans.
• Binary values can be rendered as hex via encode(column, 'hex') in SQL for display or downstream joins.

Lineage & Integrity
Direct RLP-verifiable fields: contract_address, topic_zero, data_topics, data, and log_index are all directly or indirectly validated against node RLP.

_tracing_id provides a deterministic, cryptographic handle for each log row, enabling:
• Provenance tracking from raw logs to decoded events and higher-level features
• Reproducible analytics and signal extraction
• Cross-system consistency checks (RPC vs. indexers vs. internal warehouses)

Common Use Cases
• Building decoded event layers (swaps, LP actions, mints, burns, governance events, NFT activity)
• Reconstructing DEX activity and liquidity flows directly from raw logs
• Protocol-specific analytics (AMMs, lending, perpetuals, bridges, staking) from first principles
• Detecting MEV patterns, liquidations, and arbitrage events at log-level resolution

Quality
• Verifiable lineage: deterministic cryptographic hashes per row
• Reorg-aware ingestion: continuity and consistency across forks
• Complete historical coverage: from chain genesis to present

搜集汇总

背景与挑战

背景概述

该数据集提供以太坊及EVM兼容链的原始日志数据，每条记录包含规范定位信息、合约地址、事件主题和原始负载，支持从链创世至今的完整历史覆盖。数据集具有可验证的完整性和确定性追踪标识，适用于构建解码事件层、协议分析及MEV检测等多种应用场景。