Why Must the Same Transactions Have the Same Order?
Replay a chain from genesis with block hashes and state roots, then see how nodes detect divergent execution.
- Explain how a block commits to its parent hash and transaction order
- Replay balances and nonces from genesis
- Use a state root to tell whether nodes reached the same result
- PREVIOUSWhy Do Pending Transactions Queue?
- CURRENTWhy Must the Same Transactions Have the Same Order?
Replay a chain from genesis with block hashes and state roots, then see how nodes detect divergent execution.
- NEXTWhat Is the Difference Between Confirmations and Finality?
Think about these questions first.
Choose an answer before opening the explanation. You can add anything unexpected to your review list.
Q01How can the same transaction set produce different balances when reordered?＋
Each transaction reads and changes the state left by earlier ones. Spending before receiving or calling before approval changes later validity, so consensus must fix both contents and order.
The important question is not who wrote to a database first. It is whether every node can derive the same output from the same input. Put transactions into consecutive blocks, replay them from genesis, and watch order, hashes, and state roots constrain one another.
Order is part of state
Alice paying you before you pay Bob is not always equivalent to the reverse. Nonces, balances, collateral, and liquidation boundaries can change after every step. A block therefore commits to transaction order, not merely to a set of transactions.
一笔交易如何变成状态？
交易先被签名和广播，再由节点验证并打包进区块。任何一步不满足规则，余额都不会改变。
- Nonce
- 0
- 公钥
- pk_alice_demo
- Nonce
- 0
- 公钥
- pk_bob_demo
- Nonce
- 0
- 公钥
- pk_you_demo
还没有交易。先用正确 Nonce 广播一笔转账。
把交易打进区块，再让节点从创世状态重放。验证会检查交易顺序、前序哈希、状态根和最终余额。
- TIP 哈希
- GENESIS
- 状态检查
- 重放一致
先看三张账户余额和 Nonce。签名只授权一组具体字段，节点还要在打包时检查 Nonce、余额和状态规则。
还没有区块。交易先在本地 Pending，等节点打包。
- 01
创世状态：三个账户各有 1,000 积分，Nonce 从 0 开始。
Use the slider to return to an earlier step. Continuing from there replaces the later history with a new sequence.
Mine a block, then verify the chain. The lab starts from three accounts with 1,000 points each, replays every transaction in block order, and recomputes balances, nonces, and the state root.
A state root compresses the execution result
A state root is not a list of every account in the block header. It is a deterministic digest of that state. Two nodes receiving the same prior state and order should derive the same root; otherwise they need to investigate the rule, input, or client implementation.
Expand: how this step works
replay(chain):
state = genesis
for block in chain:
require block.previousHash == previous.hash
for tx in block.transactionIds:
apply_or_reject(state, tx)
require block.stateRoot == hash(state)
The lab compresses the complexity of a Merkle Patricia Trie into a deterministic account digest, while preserving the engineering habit that execution and verification share pure rules and can be replayed.