The one-sentence version
If a system relies on a single data source, and that source makes an error, is compromised, or lies, the system will "confidently" make the wrong decision. There are two layers of countermeasures: Multi-source cross-validation (ask two or more independent sources and stop if the answers do not match) and independent implementation (have critical calculations performed by two separately written pieces of code to prevent the same bug from occurring in both). Aviation, aerospace, finance, and blockchain all follow this principle.
This article has three layers:
- Layer 1: The Intuition: The person who only looks at one watch
- Layer 2: Real-World Use: Boeing 737 MAX, Ariane 5, and DeFi oracle attacks
- Layer 3: Principles and Engineering Key points
Layer 1: The Intuition
1.1 Only Looking at One Watch
There is an old saying from the age of navigation: "When going to sea, either take one watch or take three; never take two."
- One watch: If it is wrong, you won't know, but at least you will follow it;
- Two watches: If they disagree, you won't know which one to trust;
- Three watches: The minority follows the majority, allowing you to identify the faulty one.
In software, "two watches" can actually be very useful, provided you establish a rule: If they disagree, stop and make no decision. For security decisions, "stopping" is often much better than "choosing incorrectly."
1.2 Two Types of Redundancy
| Redundancy | Protects against | Example |
|---|---|---|
| Multi-source: Asking different sources the same question | A source being wrong, compromised, or lying | Blockchain nodes from two different companies |
| Multi-implementation: The same calculation performed by different code | Bugs within your own code | Frontend and backend calculating amounts independently |
Layer 2: Real-World Use
| Event | Lesson |
|---|---|
| Boeing 737 MAX (2018, 2019) | The MCAS automated trim system relied on only one Angle of Attack (AoA) sensor. When the sensor failed, the system repeatedly pushed the nose down, resulting in two crashes and 346 fatalities. The improved design now compares two sensors and disables MCAS if they disagree. |
| Ariane 5 Maiden Flight (1996) | The rocket had two inertial reference systems as backups, but they ran the same software. When they encountered the same numerical overflow bug, they failed almost simultaneously, causing the rocket to disintegrate about 40 seconds after liftoff. Hardware redundancy without software independence is not redundancy. |
| DeFi Oracle Attacks | In several 2020 incidents like bZx, protocols read prices from only one exchange. Attackers used flash loans to manipulate the price on that specific exchange, causing the protocol to make incorrect liquidations or loans. Subsequently, the industry shifted toward oracles like Chainlink that use multi-source aggregation. |
| Airbus Fly-by-Wire | The primary flight control computers are implemented by different teams using different processors and different software to supervise each other, specifically to avoid common-mode failures like those seen in the Ariane 5. |
Application in Blockchain Wallets: Wallets read balances and preview transactions via RPC nodes. If a wallet uses only one RPC, and that node fails, is hijacked, or lies, the wallet will display incorrect information to the user. Using two independent RPCs to read and compare data at the same block height can detect such issues.
Layer 3: Principles and Engineering
3.1 What Constitutes "Independence"
| Appears Independent | Actually Not Independent |
|---|---|
| Two APIs with different domains | Both backed by the same cloud provider or the same upstream node |
| Two different libraries | Both calling the same underlying dependency |
| Two different servers | Running the same code and reading the same configuration |
| Two different teams | Both copying the same reference implementation |
True independence means: The cause of a failure in one is unlikely to cause the same failure in the other.
3.2 Comparison Must Occur at the "Same Moment"
Blockchain data changes every few seconds. If two nodes are reading different blocks, it is perfectly normal for the results to disagree. Therefore, you must first determine a specific block height and then have both nodes query at that height. The same applies to other systems: you are comparing snapshots of the same moment in time.
3.3 What to Do When They Disagree
| Scenario | Action |
|---|---|
| Security-related (e.g., allowing a transfer, risk control results) | Reject and alert (fail-closed, see Fail-closed) |
| Display-related (e.g., balance display) | Display "Data sources temporarily inconsistent" rather than picking one |
| Three or more sources | Majority vote is possible, but the minority must still be logged and alerted |
3.4 Client-Side Independent Verification
A particularly useful pattern: The browser calculates it again itself.
A server calculates "this transfer will result in -100 USDC for you and +100 USDC for the recipient." The browser does not trust this directly; instead, it connects directly to the on-chain node to calculate it again. If they disagree, the transaction is rejected. This way, even if the server is compromised or reports false results, the critical information seen by the user comes from the browser's own calculation.
Its limitations must be clear: if the page code itself is tampered with, the verification code will be changed along with it. Therefore, it protects against "server compromise," but not "frontend compromise" (see Bybit Incident and Frontend Integrity).
3.5 Trade-offs in Independent Implementation
Independent implementation (N-version programming) is expensive: two sets of code, two sets of tests, and double the maintenance. Therefore, it should only be used in the most critical and error-prone areas, such as:
- Amount and decimal conversions (USDC has 6 decimals, ETH has 18; a single decimal error is a million-fold difference);
- Parsing and validating receiving addresses;
- Encoding of signature content.
Furthermore, specialized tests must cover the edge cases between the two implementations.
Summary
| Layer | Key points |
|---|---|
| Principle | Do not rely on a single source; stop if they disagree |
| Two types of redundancy | Multi-source prevents "source lying"; multi-implementation prevents "your own bugs" |
| Independence | Must have different failure causes to be independent; Ariane 5 is a cautionary tale |
| Practice | Compare at the same moment; fail-closed for security decisions; client-side independent verification |