Data Submission

Data submission distinguishes between on-chain data, which is permanently recorded on the ledger (e.g., a transaction hash), and off-chain data, which is referenced but stored externally (e.g., a large file's hash). Submitting data on-chain is expensive and slow but provides ultimate immutability. Off-chain storage with on-chain anchoring is a common pattern for cost efficiency.

• On-Chain Example: An NFT's ownership record.
• Off-Chain Example: The high-resolution image file linked by an NFT's metadata URI.

The primary vehicle for data submission is a transaction. Data is embedded within a transaction's calldata or input data field. This payload can contain anything from simple token transfer instructions to complex encoded function calls for smart contracts. Miners/validators include this transaction in a block, thereby committing the data to the chain.

• Key Fields: to (contract address), data (encoded function call and arguments).
• Cost Factor: The size of the data payload directly impacts the gas fee.

A critical challenge is ensuring that data referenced in a transaction is actually available for verification. Data Availability (DA) solutions, like Ethereum's danksharding or Celestia, separate data publication from consensus. Validity proofs (e.g., zk-SNARKs) allow a prover to submit a cryptographic proof that a computation over some data is correct, without revealing the underlying data itself.

• Goal: Enable scalable, secure data submission with lower costs.
• Layer 2 Role: Rollups submit compressed transaction data and validity proofs to Layer 1.

Smart contracts do not directly return data to external applications. Instead, they emit events (or logs) during execution, which are a low-cost form of data submission stored in transaction receipts. These logs are not directly queryable from the EVM but are indexed by indexing services (e.g., The Graph) to provide efficient, historical data access for dApp frontends.

• Structure: Contains topics (indexed parameters) and data (non-indexed parameters).
• Primary Use: Informing off-chain systems of on-chain state changes.

The cost and feasibility of data submission are governed by gas. Sending data in a transaction's calldata consumes gas, with costs scaling post-EIP-1559 and the London fork. To optimize, protocols use data compression, batching, and signature aggregation to reduce the byte-size of submitted data.

• EIP-4844 (Proto-Danksharding): Introduces blobs for a dedicated, cheaper data channel, separating data cost from execution gas fees.
• Economic Incentive: High data costs secure the network against spam but limit application design.

Data is submitted directly to a smart contract via a user-signed transaction. This is the most common and trust-minimized model.

• Trust Model: Inherits the full security of the underlying blockchain (e.g., Ethereum, Solana).
• Finality: Data is final upon block inclusion and confirmation.
• Cost: Users pay full network gas/transaction fees.
• Examples: Submitting a vote in a DAO, executing a token swap on a DEX, or registering a domain name on ENS.

Off-chain data is fetched and submitted by a decentralized oracle network (like Chainlink) to a consuming smart contract.

• Trust Model: Relies on the economic security and decentralization of the oracle network.
• Process: A smart contract requests data, oracles fetch it off-chain, report back, and the network aggregates responses into a single on-chain value.
• Use Cases: Price feeds for DeFi, randomness for NFTs/gaming, real-world event outcomes for prediction markets, and cross-chain communication.

A third-party (relayer) pays the transaction fee on behalf of the user, who may not hold the native blockchain token.

• Mechanism: User signs a meta-transaction, which is forwarded and submitted by a relayer. The relayer is reimbursed via a fee or another token.
• Benefits: Improves user experience by abstracting gas complexity and enabling gasless interactions.
• Architectures: Includes systems like Gas Station Network (GSN), ERC-2771 meta-transactions, and application-specific relayers.

Transactions are executed off-chain on a Layer 2 (L2) but data is posted to Layer 1 (L1) for security and finality.

• Data Availability: The core security guarantee. For Optimistic Rollups, all transaction data is posted to L1. For ZK-Rollups, state diffs and validity proofs are posted.
• Trust Model: Security is derived from the L1, assuming data is available for verification or fraud proofs.
• Purpose: Drastically reduces cost and increases throughput while maintaining L1 security.

In PoS blockchains and many L2s, a designated entity (validator, sequencer) is responsible for ordering and submitting batches of transactions or blocks.

• Role: The sequencer provides instant pre-confirmations and batches user transactions for efficient L1 submission.
• Trust Considerations: Users trust the sequencer for liveness and correct ordering. Decentralized sequencer sets mitigate this risk.
• Examples: Arbitrum and Optimism sequencers, Solana validators, and Cosmos app-chains.

Specialized networks like Celestia or EigenDA that provide cheap, scalable storage for transaction data, separate from execution.

• Function: Rollups and L2s post their compressed transaction data here instead of directly to a monolithic L1 like Ethereum.
• Security Model: Relies on data availability sampling and cryptographic proofs to ensure data is published and retrievable.
• Impact: Enables modular blockchain architectures, further reducing data submission costs for high-throughput chains.

At the protocol level, data submission is executed via a specialized transaction that is validated and ordered by the network's consensus mechanism.

• Transaction Structure: Includes the data payload, a fee for network resources (gas), and a signature from the submitter.
• Consensus Integration: The transaction is broadcast to the network, validated by nodes, and included in a block. For oracle data, this often follows a reporting round where multiple submissions are aggregated.
• Finality: Once the block is finalized, the submitted data becomes part of the immutable ledger and is readable by smart contracts.

In rollup architectures, sequencers are responsible for ordering and submitting batches of transactions to the parent chain (L1).

• Role: Collect user transactions, execute them off-chain, generate a state root and cryptographic proof, and submit this batch data to the L1.
• Centralization Risk: A single sequencer can censor or reorder transactions. Decentralized sequencer sets mitigate this by using a PoS mechanism or committee rotation to share submission duties.
• Example: Optimism's Bedrock architecture includes plans for a decentralized sequencer set to submit transaction batches to Ethereum.

Proposer-builder separation is a design pattern, notably in Ethereum's consensus layer, that decouples the role of building a block (including its data) from the role of proposing it.

• Builders: Specialized nodes that construct full blocks, maximizing value via MEV extraction and including transaction/data payloads.
• Proposers (Validators): Simply choose the most valuable block header from a builder marketplace (like mev-boost) and propose it to the network.
• Impact on Data Submission: Creates a competitive market for block space, influencing the cost and reliability of getting data included in a block.

Various network participants are incentivized to submit data correctly through cryptographic proofs and economic staking mechanisms.

• Oracle Node Operators: Stake collateral (LINK, etc.) and earn fees for providing accurate data. Incorrect data leads to slashing of stake.
• Rollup Sequencers: Earn transaction fees and potential MEV. They must post data to L1 as a bond to prove honest execution.
• DA Layer Validators: Stake tokens to attest to data availability. Providing false attestations results in stake loss.
• Users: Pay gas fees to submit their transaction data to the mempool for inclusion.

Ensuring data is submitted correctly and cannot be altered after the fact is a core security challenge. This relies on cryptographic hashing and the immutability of the blockchain ledger. Key considerations include:

• Hash commitment schemes to prove data existed at a specific time.
• Data availability to ensure the raw data is retrievable for verification.
• Oracle security when using external data feeds, as compromised oracles can submit false data.

Public blockchains expose all submitted data by default, creating significant privacy risks. Mitigation strategies involve:

• Zero-knowledge proofs (ZKPs) to prove a statement about data without revealing the data itself.
• Trusted Execution Environments (TEEs) for confidential computation.
• Data encryption before submission, though this limits on-chain utility.
• Private or permissioned blockchains for consortium use cases where data must remain within a known group.

Malicious actors can create many fake identities (Sybils) to spam the network with low-value or fraudulent data submissions, potentially overwhelming the system. Common defenses are:

• Proof-of-Work (PoW) or Proof-of-Stake (PoS) mechanisms that attach a real-world cost (energy or capital) to submissions.
• Transaction fees to economically disincentivize spam.
• Reputation systems that weight submissions based on a user's historical behavior and stake.

The logic governing data submission is often encoded in a smart contract, which can contain bugs or design flaws. Critical vulnerabilities include:

• Reentrancy attacks where malicious callbacks can drain funds or corrupt state.
• Input validation failures allowing malformed or oversized data to be submitted.
• Access control flaws permitting unauthorized parties to submit or modify data.
• Front-running where an attacker sees a pending data submission and submits their own transaction to profit from it.

Many data submission systems rely on centralized components, creating single points of failure. This includes:

• Oracles that act as a bridge between off-chain data and the on-chain contract.
• Sequencers in Layer 2 rollups that batch and submit data to the main chain.
• Data committees in validity-proof systems that attest to data availability. A compromise of these trusted entities can lead to incorrect data being finalized on-chain.

Submitting certain types of data to a public ledger may create unforeseen legal liabilities. Key areas of risk are:

• Data sovereignty laws (e.g., GDPR) that conflict with blockchain immutability and global accessibility.
• Financial regulations if the data pertains to securities or transactions.
• Intellectual property infringement if copyrighted or proprietary data is published on-chain.
• Sanctions compliance risks if the network is used by prohibited entities.

A node in a rollup (Layer 2) network responsible for receiving, ordering, and batching user transactions before submitting a compressed proof to the parent chain (Layer 1).

• Primary Role: Ensures fast pre-confirmations and reduces costs.
• Centralization Consideration: Often a single entity in optimistic rollups, though decentralized sequencer sets are a key research area.

The guarantee that all data necessary to reconstruct a blockchain's state (e.g., transaction data in a rollup) is published and accessible to network participants. It is a critical security property distinct from data validity.

• DA Problem: If data is withheld, nodes cannot verify state transitions.
• Solutions: Data Availability Sampling (DAS), Data Availability Committees (DACs), and dedicated DA layers like Celestia or EigenDA.

In Ethereum, calldata is a read-only, non-modifiable data area used to pass arguments to function calls, including transaction input data. It is the primary and most secure location for rollups to post transaction data on Layer 1.

• Cost: Historically cheaper than storage, making it ideal for data submission.
• Post-EIP-4844: Superseded for rollups by blobs (binary large objects) which are even more cost-effective for temporary data availability.

A cryptographically signed statement of validity or a claim about a piece of data or state. In consensus mechanisms like Ethereum's proof-of-stake, validators submit attestations to vote on the canonical chain.

• Use Case: Acts as a lightweight proof or vote, often aggregated before final submission to chain.
• Example: Zero-knowledge proofs can generate attestations about off-chain computation for on-chain verification.