Step 6 / Ethereum & Shared Applications
How proof of stake reaches agreement.
Follow a deposit, a checked block, and two steps toward a settled history.
Maya sees her ticket purchase in a block. The purchase followed the rules. But the network also needs to agree on which valid history to keep if two branches compete.
In proof of work, proposing an accepted history involves costly computing. In proof of stake, participants put assets under rules that reward certain work and penalize certain failures. Those assets help support agreement; they do not let someone ignore the transaction rules.
A deposit supports a job.
An Ethereum validator commits ETH and runs software that helps the network agree. Its deposit is the stake. The protocol gives validators duties and applies rewards or penalties under its rules.
For one duty, a validator proposes a block. For another, validators sign statements about the chain. These signed statements are called attestations. They let others check which validator supported which view of the history.
The amount of stake counted by the rules is called effective stake. It affects selection and influence. Making a thousand empty wallets does not create a thousand equal shares of influence; the deposit weight matters.
Now suppose a large validator puts an unauthorized transfer in its block. A node checking the block still rejects it. More stake cannot create someone else’s valid signature.
So keep two questions apart. Validity asks whether the proposed change is allowed. History selection asks which valid branch to follow. Both belong to the wider agreement system, or consensus. Deciding to change that system’s rules is a third question, called governance.
Checking validity comes before selecting and finalizing an accepted history. This is not a stake-voting simulator.
Deposit size and smaller staking services
A validator needs at least 32 ETH to activate. After Pectra, an eligible compounding validator can have an effective balance as high as 2,048 ETH. The minimum needed to start and the maximum counted for this kind of validator are different limits.
A pool or service may let a user contribute less than 32 ETH. That adds questions about its code, operator, custody, or any token representing the stake. Smaller entry amounts do not remove those risks.
A person can also run a node to independently check Ethereum without putting down a 32 ETH validator deposit. Checking the rules and joining the staked validator duties are different activities.
Agreement grows in stages.
The newest block is not the same as settled history. Nodes first need to choose the current end of the chain, called its head. Ethereum’s fork-choice rule uses validator statements to help choose that head.
The network also marks certain points in history as checkpoints. Validators can sign a link from an earlier checkpoint to a later one. Enough support for these links moves the checkpoints through stages of agreement.
How much is enough? A qualifying link needs at least two-thirds of the relevant effective stake. Imagine three groups with equal stake. One group is too little. Two groups meet the threshold. Count the stake represented, not the number of people or wallets.
Now use three checkpoints in consecutive time periods: A, B, and C. Start with A already justified. This means A has passed an agreement stage; it does not mean someone has merely proposed it.
First, enough valid support links A → B. In this ordinary consecutive-checkpoint example, B becomes justified and A becomes finalized. The network has now made a stronger commitment to A and the history before it.
Notice which point is finalized: the earlier point, A. B has just reached the justified stage. The incoming link does not instantly finalize its newest target.
Next, enough valid support links B → C. C becomes justified, and B becomes finalized. B’s history includes the earlier transactions on that branch, so finalizing B commits to that history too.
This is a common simplified path. The full rules also cover less tidy sequences. Missing enough support can delay finality even while valid blocks keep appearing. A bad signature is different: it breaks a validity rule and cannot be fixed by waiting for more support.
Our starting checkpoint is already justified.
First, it needs a qualifying link from A.
Later, it needs a qualifying link from B.
Choose stake support for A → B
2 of three equal stake groups reach the threshold. Apply A → B to see which checkpoint becomes justified and which becomes finalized.
Each group represents one-third of effective stake, not one validator or one person. A, B and C are consecutive epoch checkpoints. This example assumes otherwise valid votes and shows a common finalization path; other protocol conditions and paths are outside this model.
Try one supporting group, then two. After applying both links, read B’s result: the first link justified it, and the later link finalized it. C is still only justified in this example.
The clock behind checkpoints
Ethereum divides time into twelve-second slots. Each slot is an opportunity for a block, but a slot can be empty. Thirty-two slots form an epoch.
Calculate the period: 32 × 12 = 384 seconds. Divide by 60 to get 6.4 minutes per epoch. These periods organize the proposing and signing work.
Finality normally develops over roughly two epochs. Missing participation or network problems can delay it. A twelve-second slot is therefore not a promise that a payment becomes final in twelve seconds.
Why two groups must overlap.
Keep the group fixed at 90 stake units. Divide 90 into three equal parts: 90 ÷ 3 = 30. Two of those parts total 60, so 60 units meet the two-thirds threshold.
Suppose one group of 60 supports a checkpoint. There are only 30 units outside that group. Now another group wants 60 units to support a conflicting checkpoint for the same target epoch.
The second group cannot get 60 from the 30 left outside. At least 30 units must appear in both groups. The same fact can be written as 60 + 60 − 90 = 30.
This overlap matters because validators sign their statements. Certain contradictory statements can be shown as evidence of a rule violation. Creating another identity does not create another deposit to stand behind it.
Under the protocol’s safety assumptions, conflicting finalized histories imply punishable behavior by at least one-third of the stake. Our fixed-group example shows why overlap matters. It does not cover changing validator groups, every attack, or every rule used to finalize history.
Starting a node after a long time away
A new node, or one that has been offline long enough, starts from a trusted recent checkpoint and checks forward from there. It can cross-check independent sources to help establish that starting point. This extra starting assumption is called weak subjectivity.
The concern is about old history. Former validators might present a competing history after their deposits and economic position have changed. This is different from choosing between recent blocks.
The full analysis of these long-range attacks is more advanced. The useful point here is that starting to verify the network includes an additional trust assumption about a recent checkpoint.
Different failures have different penalties.
Validators can earn protocol rewards and income connected to transactions. They can also miss rewards or lose part of their balances. The result depends on what happened and what the rules require.
A validator missing an ordinary duty is not the same as one signing contradictory statements. Specified violations can lead to slashing: a penalty to the stake and removal from the validator set.
The punishment depends on the violation and the circumstances. An ordinary harmless outage does not automatically destroy a whole deposit. Having a deposit also does not make every harmful act impossible.
Compare this with Bitcoin’s proof of work. A miner pays for computing attempts. An Ethereum validator commits assets under reward and penalty rules. Both systems still need computers to independently check whether proposed changes are valid.
Rewards, supply, and a pause in finality
Rewards vary with the protocol rules, participation, and the amount of active stake. Transaction revenue also varies. A staking service may charge fees, and penalties or a fall in ETH’s price can outweigh the income received.
Validator rewards create new ETH. Fee burning and some penalties remove ETH. Additions minus removals determine whether the total supply rises or falls over a period. Proof of stake does not promise a fixed return or a supply that always falls.
If finality stalls for a prolonged period, inactivity rules reduce the relative weight of stake that is not participating. This can help the remaining participants regain enough weight to restore finality under the protocol’s conditions.
That is why “51 percent controls everything” is too simple. Accepting valid changes, keeping the chain moving, and finalizing history involve different rules and thresholds.
People still choose the rules.
A constitution or shared rulebook is a useful comparison, with limits. The software says which actions it permits. Its history-selection procedures help participants agree on a record under those rules. Governance is the human process of considering and adopting changes.
Software is not a court. It does not settle human intent or legal legitimacy. It also does not make every participant accept a proposed rule change.
Changing Ethereum takes proposals, implementation, testing, and adoption. A large validator cannot simply replace the software rules on everyone else’s computer.
Proof of stake reduces the need for energy-intensive mining. It puts more of the security process into the asset and staking system. That leaves questions about large operators, pooled stake, failed infrastructure, and the ability to delay or block some requests.
Proof of work has its own pressures: specialized machines, electricity costs, mining-pool concentration, and revenue needed to pay for security. Neither label guarantees that power is spread evenly.
Compare the actual system. Who can join? Who can stop progress? What does misconduct cost? And who must accept a change before new rules take effect?
The execution history continues. This switch depicts a coordinated protocol upgrade, not an automatic change or required token exchange.
Ownership shares and the price of stake
Suppose someone owns 10 out of 100 units. That is a 10 percent share. If every balance grows by the same 10 percent, this person has 11 out of 110. Their share is still 10 percent.
So equal percentage growth alone does not increase someone’s share. In practice, people differ in participation, operating costs, delegation, fees, and penalties. Those differences can change ownership and concentration.
Proof of stake also uses its own native asset as part of security. If that asset’s market value falls, buying or sacrificing a given amount of stake can cost less in outside buying power.
That feedback matters alongside available liquidity, concentration, penalties, and the practical difficulty of an attack. It does not prove that every fall in price causes an attack.
The idea to keep
Proof of stake gives validators duties backed by deposits, rewards, and penalties. Nodes still check whether a block is valid. Fork choice selects a current end of the chain, and checkpoint links build stronger agreement about its past.
People still decide which software rules to adopt. Stake, transaction permission, and control over future rule changes are related questions, but they are not the same power.