Trust Assumptions

The core goal of most decentralized systems is to minimize trust in any single entity. This is achieved by shifting reliance from individuals or corporations to cryptographic proofs and economic incentives. For example, Bitcoin's Proof-of-Work replaces trust in a central bank with trust in the economic cost of electricity and the honesty of the majority of hash power.

Systems exist on a spectrum from fully trustless to highly trusted.

• Trustless: Relies solely on code and cryptography (e.g., Bitcoin settlement).
• Cryptoeconomic: Trusts in the game-theoretic security of a decentralized validator set (e.g., Ethereum PoS).
• Federated/Multi-Sig: Trusts a known, permissioned set of entities (e.g., many sidechains, bridges).
• Centralized: Trusts a single operator (e.g., a traditional database).

A formal trust assumption about the maximum number of malicious or faulty nodes a network can tolerate and still reach consensus. Practical BFT (pBFT) and its variants assume that less than one-third (or sometimes one-half) of the validating nodes are Byzantine (acting arbitrarily). This is a critical assumption for many Proof-of-Stake and permissioned blockchain networks.

These are two key properties governed by trust assumptions.

• Safety (Consistency): The guarantee that validators will not finalize conflicting blocks. Compromised if too many validators are malicious.
• Liveness: The guarantee that the network can continue to produce new blocks. Can be halted by network partitions or censoring validators. Different consensus models make different trade-offs between these properties under adversarial conditions.

In Proof-of-Stake systems, security is based on the economic trust assumption that validators are rational actors seeking to preserve their staked capital. Slashing is a penalty mechanism that destroys a validator's stake for provably malicious actions (e.g., double-signing). The system assumes the slashing penalty outweighs any potential profit from an attack.

Some cryptographic systems require a trusted setup ceremony to generate initial parameters (e.g., for zk-SNARKs). This creates a one-time trust assumption that the ceremony participants did not collude to create a backdoor. If compromised, the entire system's privacy or security can fail. Newer constructions like zk-STARKs aim to be transparent, eliminating this need.

The core design goal of reducing the number and strength of trust assumptions required for a system's security. This is achieved through cryptographic proofs, economic incentives, and decentralized consensus.

• Cryptographic Trust: Relies on the computational hardness of problems like integer factorization (RSA) or discrete logarithms (ECDSA).
• Economic Trust: Uses financial staking and slashing to align participant incentives with honest behavior.
• Architectural Trust: Distributes trust across many independent nodes instead of a single authority.

Different consensus mechanisms impose distinct trust models on their participants.

• Proof of Work (PoW): Trusts that no single entity controls >50% of the network's hashrate (honest majority assumption).
• Proof of Stake (PoS): Trusts that no coalition controls >33% or 66% of the staked tokens, depending on the protocol's fault tolerance.
• Proof of Authority (PoA): Trusts a pre-approved, known set of validators to behave honestly, a higher-trust model suitable for private networks.

A critical distinction between systems that require an initial trusted ceremony and those that are trustless from genesis.

• Trusted Setup: Protocols like ZK-SNARKs (e.g., Zcash's original ceremony) require that the initial parameter generation is performed honestly and the 'toxic waste' is destroyed. A compromised setup can undermine all future proofs.
• Trustless Setup: Systems like Bitcoin's genesis block or some newer ZK-STARKs require no such initial trust; security is based solely on public cryptographic assumptions.

Cross-chain bridges and oracles introduce external trust assumptions, often becoming critical security bottlenecks.

• Bridge Trust Models: Can be trust-minimized (using light clients & cryptographic proofs), federated (trusting a multisig council), or custodial (trusting a single entity).
• Oracle Trust: Data feeds from services like Chainlink rely on a decentralized network of node operators. Users must trust that a majority of these nodes are honest and that the data source (API) is correct.

Ultimate trust in a blockchain often rests with its community and developers, manifesting during contentious forks.

• Code is Law vs. Social Consensus: While protocol rules are encoded, major bugs or exploits (e.g., The DAO hack) often lead to social consensus forks where the community decides on a new canonical chain.
• Client Diversity: Trust is distributed across multiple, independent client implementations (e.g., Geth, Erigon, Nethermind for Ethereum) to avoid a single point of failure.

A key spectrum in blockchain design contrasting cryptographically provable claims with faith-based promises.

• Verifiable Trust: Claims that can be independently checked by any participant, such as the validity of a ZK-proof or a Merkle inclusion proof. This is the gold standard.
• Fiduciary Trust: Requires faith in a third party's future behavior or honesty, such as trusting a bridge's multisig signers not to collude or an oracle to report accurate data.

This assumption posits that participants are economically rational and will act to maximize their financial gain, making attacks unprofitable. It's the basis for cryptoeconomic security in Proof-of-Stake, where validators risk losing their staked assets (slashing) for malicious behavior. The model fails if an attacker is irrational (e.g., state-sponsored) or if the cost of attack is lower than the potential reward from a double-spend or governance takeover.

Users must trust that their client software (wallets, nodes) is correctly implemented and not malicious. Similarly, DeFi protocols and smart contracts relying on oracles (e.g., Chainlink, Pyth) assume the oracle provides accurate, tamper-proof external data (price feeds). A compromised client can lead to fund loss, while a manipulated oracle (oracle attack) can drain an entire protocol, as seen in historical exploits.

The "code is law" principle assumes smart contract code is the final arbiter, with no possibility of intervention. This relies on the immutability of the underlying blockchain. Risks emerge from bugs or unforeseen interactions, leading to irreversible losses. This has led to the practice of including upgradeable proxies or emergency pause functions, which themselves introduce new trust assumptions in the governance or admin keys controlling them.

This is a fundamental trade-off. Safety assumes the network never confirms incorrect transactions (requires synchronous network periods). Liveness assumes the network will eventually confirm new transactions (tolerates asynchrony). Most blockchains prioritize liveness under asynchrony, which can temporarily compromise safety (reorgs). Protocols explicitly define their synchrony assumptions (synchronous, partially synchronous, asynchronous) which dictate their resilience to network delays and partitions.