Data Trust Assumption

The authoritative data layer a system relies on for state verification. This is the root of all trust.

• On-chain: Trust is placed in the underlying blockchain's consensus (e.g., Ethereum blocks).
• Off-chain: Trust is placed in external oracles, committees, or data providers (e.g., price feeds from Chainlink).

The choice between these sources is the fundamental trade-off between decentralization and cost/latency.

The cryptographic or economic process used to prove data is correct relative to the source of truth.

• Fraud Proofs: Assume data is valid unless a watcher submits cryptographic proof of fraud (optimistic approach).
• Validity Proofs: Require a cryptographic proof (like a ZK-SNARK) that attests to correctness before state is accepted.
• Economic Slashing: Use bonded stakes that can be destroyed if a provider submits incorrect data.

This mechanism defines how trust is enforced.

The specific group of participants whose honesty is required for the system's security.

• 1-of-N Trust: Security requires at least one honest participant (e.g., a single honest validator in an optimistic rollup).
• M-of-N Trust: Security requires a threshold of honest participants (e.g., a 4-of-7 multisig bridge).
• N-of-N Trust: Requires universal honesty (impractical for large, permissionless sets).

Quantifying this set is crucial for risk assessment.

The core trade-off between system availability and state correctness, dictated by the trust model.

• Strong Safety: Prioritizes never accepting incorrect data, even if it means delays (common with validity proofs).
• Strong Liveness: Prioritizes always making progress and providing data, accepting a window for fraud challenges (common with fraud proofs).

Most systems optimize for one, creating an explicit security fault in the other.

The contingency plans and control structures that exist outside the primary trust model.

• Timelock Escrow: Allows users to withdraw funds after a delay if the system halts.
• Multi-sig Upgrade Keys: A committee can unilaterally change contract logic, representing a centralization risk.
• DAO Governance: Changes are voted on by token holders, distributing but not eliminating trusted control.

These features represent residual trust assumptions that can override the system's normal operation.

Light clients, like those in wallets, operate under a 1-of-N trust assumption. They rely on a single honest node from a large, decentralized peer-to-peer network to provide them with correct block headers and proofs. This is considered a weak subjective trust model, as the client must initially find at least one honest peer. The security scales with the size and decentralization of the full node network they query.

Optimistic rollups like Arbitrum and Optimism employ a 1-of-N trust assumption for their fraud proof mechanism. They assume at least one honest, vigilant node (a verifier) in the system will detect and submit a fraud proof if invalid state transitions are proposed. All other users can then safely adopt the corrected state. This creates a crypto-economic security game where it only takes one honest actor to keep the system secure.

Decentralized oracle networks are designed to minimize the Data Trust Assumption. Instead of trusting a single data source, they use a N-of-M or Byzantine Fault Tolerant (BFT) model. For example, a smart contract may require data from a decentralized price feed that aggregates responses from multiple independent nodes. The system is secure as long as a threshold (e.g., a majority or supermajority) of these oracle nodes is honest and accurate.

Bridge security models are defined by their trust assumption, which is a major vulnerability point. Trust-minimized bridges (like light client bridges) may have a 1-of-N assumption similar to the underlying chain's validators. Multisig bridges have an M-of-N assumption, trusting a specific committee. Liquidity network bridges often have a 2-of-2 assumption, trusting the security of both connected chains. The weaker the assumption (fewer trusted parties), the more secure the bridge.

Data Availability Sampling (DAS) is a technique that allows light nodes to verify data availability with a high probability without downloading all data. It transforms the trust model: instead of assuming 1-of-N full nodes are honest about data availability, each light node performs random checks. Security becomes cryptographically guaranteed with enough samples, moving from a social/majority trust assumption to a cryptographic trust assumption in the sampling protocol itself.

The Inter-Blockchain Communication (IBC) protocol, used by Cosmos and other chains, establishes a 1-of-N trust assumption per connected chain. A light client on Chain A tracks the validator set of Chain B. For a message to be trusted, it must be signed by a sufficient quorum (e.g., >2/3) of Chain B's validators. The trust is not in intermediaries, but in the security of the counterparty chain's consensus mechanism. This makes trust explicit and minimal.

The primary risk where an attacker corrupts the data feed an application depends on. This can be achieved by compromising the oracle's data source, its node operators, or the transmission mechanism. Consequences include:

• Price feed manipulation to trigger unfair liquidations or enable profitable arbitrage.
• Random number generation attacks in gaming or lottery dApps.
• Conditional logic failure for contracts that execute based on real-world events.

Many data providers introduce single points of failure, contradicting blockchain's decentralized ethos. Key vectors include:

• Single Oracle: Relying on one data source creates a critical vulnerability.
• Permissioned Node Set: If oracle nodes are run by a known, small set of entities, they can collude.
• Centralized Data Source: Even decentralized oracle networks often pull from traditional APIs, which can be censored or hacked.

The assumption that critical data will be delivered when needed. Failures include:

• Data Feed Stalling: Oracles failing to update, causing protocols to operate on stale, incorrect data.
• Transaction Censorship: Malicious actors preventing oracle update transactions from being included in blocks.
• Network Outages: Downtime in the source API or the oracle network itself, causing systemic failure for dependent smart contracts.

Mitigating trust assumptions requires cryptographic verification of data's provenance and integrity. Common methods:

• TLSNotary Proofs: Cryptographic proof that data was fetched from a specific HTTPS endpoint at a specific time.
• Zero-Knowledge Proofs (ZKPs): Prove the correctness of computed data (e.g., a price average) without revealing all inputs.
• Attestation Signatures: Data is signed by a known, possibly decentralized, set of attesters whose reputation is at stake.

Aligning incentives so that providing correct data is more profitable than attacking the system. Key models:

• Staking/Slashing: Node operators post collateral (stake) that is slashed for provably malicious behavior.
• Reputation Systems: Oracles build a reputation score over time; losing it destroys future earning potential.
• Dispute Resolution: A challenge period where anyone can post a bond to dispute a data point, triggering a verification game.

A crucial distinction in trust models:

• Authenticity: Proving the data came unaltered from a specific source (e.g., a signed feed from the NYSE). This is often solvable with cryptography.
• Correctness: Proving the data accurately reflects the real-world state it claims to represent (e.g., that the NYSE feed itself is correct). This is fundamentally harder and often requires social consensus or robust fallback mechanisms. Most oracle failures are failures of correctness.