Consensus, Network Security and Cross-Chain Dependencies

Advanced awareness means recognising a security assumption before relying on it. It does not require you to design a consensus protocol. This lesson revisits work, stake, finality and cross-chain routes with a wider view of concentration and failure. It also connects liquid staking and restaking to the dependency maps you have already built.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Consensus incentives and different designs

Proof of work uses computational effort within a valid-history selection process. Proof of stake uses committed stake and protocol-defined voting or participation. Both require software validation, network communication and assumptions about participant behaviour. Concentration in mining pools, validators, operators or software clients can affect these assumptions in different ways.

Count the relevant control rather than only the number of visible names. Several validators can use the same operator or client, and several miners can coordinate through one pool. Protocol governance also involves people adopting software and changes. A soft fork commonly tightens validity rules in a way older nodes can accept under the relevant design; a hard fork changes rules incompatibly for participants that do not adopt them. Actual upgrade consequences depend on the system and adoption.

Ask how strangers agree on one record

Picture forty relatives in Mexico City planning a reunion in a group chat, with messages arriving out of order. Unless the family has a rule for deciding which date is final, the chat never settles.

A blockchain has the same problem, at a much larger scale and with strangers who may lie. Its consensus mechanism must make it costly to pretend to be many people at once, and give everyone the same rule for picking the right chain when two versions compete.

The analogy stops working at one point. Relatives forgive mistakes; a blockchain assumes some participants will cheat on purpose, so its rules must make cheating expensive. The first big choice is between spending energy and putting money at risk.

Compare proof of work and proof of stake

You know proof of work from the mining and fee lessons in Level 1: miners spend electricity guessing hashes, and the winner adds the next block. What is at risk is the cost of machines and power.

Proof of stake replaces that race with a deposit. Think of a market in Lyon where every stallholder pays a large bond to the town hall. Anyone caught using false scales loses part of the bond. Ethereum has worked this way since The Merge in September 2022 (the Ethereum and contract lessons in Level 4). A validator deposits 32 ETH, and ethereum.org explains that time is divided into slots of 12 seconds and epochs of 32 slots. In each slot one validator proposes a block, and a randomly chosen committee votes on it. Honest work earns rewards; provable cheating, such as signing two different blocks for the same slot, triggers slashing, where part of the stake is destroyed and the validator is removed.

The benefit is lower energy and hardware costs. The matching risk is that influence follows wealth, and pooled staking services (the lending and staking lessons in Level 6) can gather a big share. The bond analogy also breaks down: a town hall is a trusted referee, while proof of stake has only rules that every node enforces for itself.

Other designs go further and hand the work to a small group.

Meet delegated and BFT style systems

Some networks use elected or delegated block producers. Others use BFT-style voting rules that aim to tolerate specified faulty participants. These categories can overlap: a proof-of-stake system can use a BFT-style finality process.

A classroom model with n equally weighted participants and the usual n ≥ 3f + 1 assumption can tolerate f Byzantine faults under its specified network and protocol assumptions. With 60 equal-weight participants, the bound is 19. That is not a universal rule for all blockchains.

Real systems may weight votes by stake, use different quorums, or distinguish honest offline participants from actively conflicting ones. Safety and continued progress have different conditions, especially during network disruption. Inspect voting power and the protocol's actual assumptions rather than counting validator names alone.

Safety, liveness, finality and availability

Safety concerns avoiding conflicting accepted outcomes under the protocol's assumptions. Liveness concerns continuing to make progress. Finality concerns when an outcome is treated as settled under defined conditions. Availability concerns access to the information or service needed to use or verify the system. A network can preserve one property while temporarily losing another.

For example, a halt can stop new confirmations without automatically authorising theft from all wallets. A data-availability failure can prevent participants from reconstructing needed state even if a proof or headline result is displayed. Recovery procedures may involve software, governance or operational choices. Read the actual incident and protocol, rather than describing every delay as identical to a theft or every finality label as unconditional certainty.

Finality describes when a protocol treats a result as settled under defined assumptions. In Bitcoin, additional confirmations increase the work needed to remove a payment through a competing valid history. There is no universal confirmation count that makes every theoretical risk vanish.

Ethereum has a proof-of-stake checkpoint finality process. Normal timing is often described in epochs and slots, but participation and network conditions can delay finalisation. Block inclusion, wallet display and finalisation are distinct observations.

A majority-work attack can attempt to reorganise valid recent history, censor transactions or reverse the attacker's own payments under appropriate conditions. It does not provide every user's private key or make compliant nodes accept arbitrary invalid issuance. Proof-of-stake attacks have their own voting thresholds, penalties and recovery assumptions; do not transfer a single percentage slogan to every network.

Security discussions should identify the capability, required resources, affected property and limits. A signature forgery is different from an ordering attack, and a compromised administrator is different from a consensus failure. These distinctions matter for custody decisions and incident response. A remedy must address the actual authority or assumption that failed, not simply the most dramatic term in the news report.

Count the cost of attacking a network

An attack should be named by the capability it needs and the property it threatens. A majority-work attacker can attempt to reorganise valid recent history, reverse its own payments or censor transactions. It cannot make full nodes accept arbitrary invalid issuance or derive every user's signing secret.

A smaller share of mining power can still have a non-zero chance of a competing-history attack. The phrase 51% describes a majority advantage, not a sharp boundary below which every attack is impossible.

Proof-of-stake thresholds concern particular actions and stake weights. Conflicting finality in Ethereum exposes at least a substantial slashable stake under the protocol's accountability rules. Disrupting progress, causing conflicting outcomes and changing rules are different scenarios. Do not turn total stake divided by three into a universal cash cost of every attack.

Ask who pays for security

Think of the guards at a shopping centre in Toronto. If the shops inside become far more valuable but the guards' wages stay the same, robbery starts to look tempting.

A blockchain's security budget is what it pays, each day, to the people who protect it. For Bitcoin that is the block subsidy plus fees (the supply and halving lesson in Level 1).

Economist Eric Budish argued that this security is expensive by design: the recurring "flow" paid to miners must stay large compared with the one-off "stock" an attacker could gain. Security does not build up like a bank's reputation; it depends on the computing power deployed that day. As the subsidy shrinks, either fees must rise or the budget falls.

In proof of stake, the stake that could be slashed plays that role. Either way, security costs something, and that cost sits inside a wider trade-off.

Weigh the decentralisation trade off

Diners in Seoul joke that a restaurant can be fast, cheap or excellent, but only two of the three. Blockchains face a similar trade-off.

This is often called the scalability trilemma. A chain wants scalability (processing more than one ordinary laptop could check), decentralisation (no dependence on a small group of large actors) and security (resisting attack even if a large share of participants try). Bitcoin keeps decentralisation and security but limits scale; small-validator chains gain scale but lean on a few operators; many separate chains split their security. Layer 2s (the scaling and bridge lesson in Level 4) try to escape the trade-off.

Unlike a kitchen, the triangle can be stretched by new research, so treat the trilemma as a thinking tool, not a law.

Check who really runs the network

A city with a hundred bakeries is safe from one bad batch of bread, unless all hundred buy flour from the same mill. So count the operators, and also count what they share.

Mining pools gather hashing power (the mining and fee lessons in Level 1), and staking pools gather stake (the lending and staking lessons in Level 6). Less visible is client software, the program a node runs. Ethereum has several clients written by different teams, so a bug in one need not hit the whole network.

ethereum.org's client diversity page explains the thresholds for consensus clients. If one client with more than a third of stake has a bug, the chain can stop finalising. If a client with more than two thirds has a serious bug, the chain could finalise the wrong history and many validators could be slashed. It gives a dated example: in 2016, a denial-of-service attack in Shanghai hit Geth, then the dominant execution client, while other clients kept running. Its figures for October 2025 showed Geth at about 41% of execution clients and Lighthouse at about 43% of consensus clients.

Concentration also matters when rules change, because whoever runs the software decides which rules it enforces. That brings you to forks.

Tell a soft fork from a hard fork

Think of a football league changing its rules. If it bans a type of tackle, old referees can still follow the matches, because every game under the new rules is still valid under the old ones. If it allows something new, such as a fifth substitute, old referees would call the matches invalid.

Bitcoin's terms, met in the keys and signing lesson in Level 1, follow the same logic. A soft fork makes only previously valid blocks or transactions invalid; it tightens the rules, so older nodes still accept new blocks. A hard fork changes the rules so that nodes that don't upgrade can't validate the new blocks, which can cause a permanent split.

The football analogy breaks down because a league has a governing body. Bitcoin has none, which is why one fork became a years-long argument.

Revisit the blocksize wars

Around 2015 to 2017, Bitcoin users argued about how to grow. One side wanted bigger blocks. The other feared bigger blocks would make nodes too costly to run, the trilemma in action, and preferred SegWit plus layer 2s such as Lightning.

Bitcoin Optech describes how the SegWit upgrade got stuck. Its activation needed 95% of recent blocks to signal miner support, and signalling stalled below that level. Some users proposed a user-activated soft fork (BIP148), in which their nodes would reject blocks that did not signal. Miners then adopted BIP91, which lowered the threshold, and SegWit activated in August 2017. Those who wanted bigger blocks created Bitcoin Cash through a hard fork the same month. Taproot, by contrast, used a shorter "Speedy Trial" signal, locked in during June 2021 and activated in November 2021 without a similar fight.

The lesson is not who was right. In a decentralised network, changing the rules means persuading miners, node operators, exchanges and users, and failed persuasion can end in two coins. How that persuasion is organised is called governance.

Follow how protocols change BIPs EIPs and on chain votes

Think of neighbours in Melbourne proposing a playground. Someone writes a plan and people debate it, but nothing changes until people act on it.

Off-chain governance works like that. Bitcoin changes start as Bitcoin Improvement Proposals (BIPs). BIP 2, written by Luke Dashjr in 2016, describes a BIP as a design document. A BIP reaches "Final" only once it is adopted in practice: for a soft fork, a clear miner majority signalling on the blockchain; for a hard fork, adoption by the entire Bitcoin economy. Ethereum uses Ethereum Improvement Proposals (EIPs), which ethereum.org says are discussed in public forums and on AllCoreDevs calls, tested, then bundled into upgrades. Developers cannot force anyone to upgrade, so they tend to avoid changes whose contentiousness outweighs the benefits.

On-chain governance records votes as transactions, and the code often applies approved changes automatically. It is clearer and faster, but it gives most power to the largest token holders.

Ethereum's DAO fork shows both sides. ethereum.org notes that a community vote showed over 85% support for the fork, but turnout was low and only ETH holders could vote. Those who disagreed kept the old chain as Ethereum Classic. Today, on-chain voting is most visible in the descendants of The DAO, so it is worth opening one up.

Open diagram at original size ↗

Read diagram as text

Soft fork: tightened rules continue one chain, and old nodes can still accept blocks produced under the new rules. The picture cites SegWit, August 2017.

Hard fork: changed rules can produce separate old-rule and new-rule networks and coins if both survive. The picture cites Ethereum/Ethereum Classic, July 2016.

The split is a possible outcome, not a guarantee that every hard fork creates two lasting networks.

Cross-chain verification, data and exit paths

For a rollup, examine sequencer availability, proofs or challenge processes, data availability, upgrade authorities and withdrawal routes. For a bridge, examine verification, custody or liquidity mechanisms and administrative control. A proof can verify a defined statement while other components remain centralised or unavailable. A nominally valid state does not necessarily mean a beginner can exit immediately.

Map the current version and emergency powers. A fast third-party withdrawal can replace delay with counterparty risk. An unavailable front end may be bypassable in theory while still impractical for the learner's knowledge and tools. Record that operational constraint honestly. Advanced awareness is useful when it reveals what would be needed during a failure, not when it encourages a complex rescue the learner cannot assess.

Ask what you trust when you leave one chain

Think of each blockchain as a country with its own rules. The analogy helps explain why information crossing a border needs a separate verification process. Problems start at the border, where something else has to vouch for what crosses.

You met that border in the scaling and bridge lesson in Level 4. A bridge locks or burns an asset on one chain and mints or releases a matching one on another, and the vault of locked funds is a magnet for attackers. The Ronin bridge lost about US$625 million in March 2022, Wormhole about US$320 million in February 2022, and Nomad about US$190 million in August 2022. None of those losses needed a user to make a mistake.

This lesson asks who each design makes you trust, because that decides how it fails, then asks the same of price data and code.

Compare bridge designs by who you trust

To send a parcel from Ankara to Berlin, you could trust a private courier, which is fast and goes everywhere, or a system where both postal services check every handover themselves, which adds no new party to trust.

ethereum.org sorts bridges the same way. Trusted bridges rely on an outside group, such as a set of validators or a multisig, to confirm that funds were locked on one side before releasing them on the other. They are usually fast, cheap and connect many chains, but you inherit the security of that group, not of the blockchains. Trust-minimised bridges, often called trustless bridges, verify the connected chains' data or proofs instead of relying on an outside signer group. This can reduce one dependency, but the underlying chains, verification code, data availability and any upgrade powers still need review. The label alone does not describe every part of the deployed bridge.

Two other families matter. Message-passing bridges move arbitrary data, not only tokens, so an app on one chain can trigger an action on another. Liquidity networks swap assets using providers who hold funds on both sides; ethereum.org notes they are fast and cheap but cannot pass messages.

The parcel analogy breaks down at one point: a lost parcel affects one sender, while a bridge failure can hit everyone holding the bridged token, even people who never used the bridge.

See how cross chain risk spreads

Picture a gift voucher accepted in shops all over Rio de Janeiro. If the issuing shop goes bust, every shop that took the voucher as payment is suddenly holding paper.

ethereum.org calls this systemic financial risk. A bridged token, backed by a bridge vault, can be used as collateral in lending apps, paired in DEX pools and bridged again. If the vault is drained or someone mints tokens with nothing behind them, every place that accepted those tokens is exposed. ethereum.org lists three other risk types for bridges: smart-contract bugs, counterparty risk from trusted operators who could censor or steal, and open questions about how young bridges behave under stress.

Bridges move data between chains. Many contracts also need data from outside any chain, which raises a problem of its own.

Reused stake creates linked obligations

A liquid-staking representation links its value and redemption to underlying staking and its provider. Restaking can connect that stake or representation to additional services, with extra penalty, operator and contract rules. Using the resulting asset as lending collateral adds oracle and liquidation dependencies. Each layer can transmit a loss or access problem to the next.

Trace the whole chain and identify whether losses can occur together. More reward sources do not automatically diversify risk if they rely on the same collateral and operators. Record exit delays, receipt-token liquidity and the obligations added by each service. You can complete the exercise as a diagram without staking anything. The next lesson examines governance and audits so that reviewed code is not mistaken for reviewed control or economic behaviour.

Try the following questions aloud or on paper before opening the worked answers. Compare your reasoning as well as your final answer.

References and further reading