签名究竟证明了什么，为什么不能证明余额充足？
课程使用的例子一笔转账，凭什么被所有人接受？
我们把签名、Nonce、余额、交易和区块拆成连续状态，观察节点为什么能拒绝篡改和重放。
例子中的参与者
- 你发送者：用密钥授权状态变化
- 收接收者：等待状态被写入
- 节节点：验证签名、Nonce 与余额
- 块区块：固定交易顺序与状态根
课程目录
每章集中解释一个问题
章节按概念的先后关系排列，建议第一次学习时按顺序阅读。
- 01SIGNATURE · NONCE · STATE12 MIN
谁授权了这笔转账？
本章问题签名完全正确，交易为什么还是可能失败？
从签名交易到区块状态，说明篡改、重放和余额不足的交易为什么会被拒绝。
→ - 02MEMPOOL · NONCE · REPLACEMENT13 MIN
交易池怎样处理相同 Nonce 的交易？
本章问题钱包显示两笔相同 Nonce 的 Pending，会不会真的支付两次？
说明同一个 Nonce 的交易如何被替换，以及无效交易为什么不会进入区块状态。
→ - 03ORDER · REPLAY · STATE ROOT15 MIN
同一组交易，为什么必须同一个顺序？
本章问题完全相同的一组交易，只换顺序，余额为什么会不同？
用区块哈希和状态根重放整条链，看到顺序或执行结果出现分歧时节点如何发现问题。
→ - 04CONFIRMATIONS · FINALITY14 MIN
确认数和最终性有什么区别？
本章问题确认数已经很多，为什么还要区分最终性？
连续生产区块，再推进教学模拟中的最终性，理解‘已经看见’与‘可以安全依赖’不是一回事。
→
这门课会回答这些问题
Nonce 如何阻止同一笔交易被重复执行？
交易进入区块后，余额和状态根如何变化？
为什么广播、验证、打包和最终确认是不同步骤？