Skip to main content
Knowledge mapWhy does “immutable” need conditions?Industry concepts and standards

You are here. See how this question connects to other ideas.

Select a node to open its page · Expand to read within the map

Knowledge mapFollow a connection. Understand a question.
← Blockchain and shared state

One question

Why does “immutable” need conditions?

Receiving a transaction, including it in a block and finalizing history provide different evidence.

A “success” message may mean that a node received a transaction, or that the transaction entered a block. An application relying on it for delivery needs to specify its confirmation conditions.

Chapter 6 of 《区块链实战》 already distinguishes resistance to tampering from absolute immutability. Carry that distinction further: editing a local file, changing the accepted branch and reaching protocol finality are different events.

Changing a copy is not making others accept it

You can edit your local copy. Other nodes check it against their rules and need not accept it. Hash links help expose changes; consensus determines which valid history participants accept.

Bitcoin compares cumulative work among valid candidate chains: the computational work represented by each history, not simply its number of blocks. When the network switches branches, a transaction included in a discarded block may leave the accepted history. This is a reorganization. Further confirmations generally reduce the risk, but no universal number of blocks makes change impossible.

Majority hash power can affect valid transaction ordering, obstruct confirmation or help an attacker reverse their own payment. It does not supply other people’s private keys or compel validating nodes to accept invalid transactions. Power over ordering is not permission to ignore every rule.

Finality has protocol conditions

Ethereum’s Gasper selects the history to follow and uses votes to finalize particular positions in that history, called checkpoints. Ordinary branch selection should not reverse a finalized checkpoint; doing so would represent a serious consensus safety failure, distinct from an ordinary temporary fork.

A confirmation policy therefore needs a chain, protocol conditions and a response to abnormal operation. A green checkmark on a screen does not specify those conditions for you.

Book and verification sources

This lesson develops a question from 《区块链实战》, Chapter 6, with the references below. It is a new explanation, not a book excerpt.

Check your understanding

Does majority hash power let an attacker forge other people’s signatures and transfer their assets at will?

Not by hash power alone. It can affect ordering, censorship or reorganizations, but validating nodes still reject invalid signatures and transactions that violate their rules.

Continue along a learning path

Referenced here

Terms

  • Blockchain

    A distributed ledger that links records cryptographically and uses shared validation and consensus rules to establish an accepted transaction history.