把智能合约读成状态机：核对调用者、条件与边界

English version · 区块链学习导航 · 上一篇

区块链学习 · 文章 BC037

学习场景配图；不代表照片中的学生正在学习区块链。

智能合约是在区块链规则下操作状态的可执行代码。它的有效承诺是具体的：执行被触发时，代码检查已经写入的条件，并应用允许的变化。它不会自动知道物理事件是否发生，也不会自动判断规则是否构成公平约定。

本篇跟踪一件虚构档案物品，从可用到已预约，再到已领取。你将检查谁能请求每种变化、截止边界如何处理，以及暂停期间哪些操作仍然允许。练习把笼统的自动化说法转化为能够实际检验的条件。

选择适合你的阅读路线

本篇目录

1. 代码、状态与触发是三个不同要素
2. 先定义档案记录，再定义函数
3. 精确定义预约与领取规则
4. 明确退出路径和暂停行为
5. 跟踪普通成功路径
6. 边界测试：越过截止值不会自行改写存储
7. 暂停测试：标志只影响实际检查它的操作
8. 可以公开调用，不等于可以无限制成功
9. 部署与后续调用承担不同任务
10. 有效声明不等于已核验的物理事件
11. 测试通过是证据，不是安全证书
12. 练习：判断转移，而不只看标签
13. 常见问题
14. 资料来源与后续阅读

先看状态字段和操作规则，再跟踪成功预约，比较到期与暂停情形。答案关注边界条件和缺失权限，而不是要求背诵智能合约定义。

这是纸面模型，不是可部署代码。不使用真实密钥、地址、支付或个人资料。签名验证、费用、账户 nonce 和详细虚拟机失败行为，都不属于这份应用状态练习。

1. 代码、状态与触发是三个不同要素

以太坊智能合约入门将合约描述为与链上地址关联的代码和状态。程序可以提供函数，按规则处理调用并修改记录。

代码定义可能行为，状态记录调用开始时的情况，触发则让某次执行实际发生。只知道其中任何一项，都不能得到完整结果。

例如，相同的领取记录操作，在物品已预约时可能成功，在已领取时可能失败。截止规则可以让某次调用在后续区块不再符合条件，但规则存在，并不表示程序会在过期时自发执行一笔清理交易。

应保持承诺具体：程序检查可以按照执行规则一致应用。检查是否足以满足真实机构需求，是另一项设计问题。稳定执行一个不合适的条件，并不会使它变得合理。

2. 先定义档案记录，再定义函数

虚构物品名为 ArchiveItem-7，应用记录包含四个字段：

status：Available（可用）、Reserved（已预约）或 Collected（已领取）。
holder：符号化读者标识，或 none（无）。
deadline：预约截止区块号，或 none。
paused：布尔暂停标志，初始为 false。

练习有三类角色。R、S 是给定的获授权读者，C 是管理员工中的保管员，A 是暂停管理员。它们是不同的符号化行动者，本文不声称完成了链上地址与真人身份的核验。

初始状态为 Available，holder 为 none，deadline 为 none，paused 为 false。应用能够读取这些存储值，却没有眼睛去检查架子，也不能自行识别站在柜台前的访客。

因此，状态名称只是记录状态，并非自动证明物理事实。转为 Collected，表示模型接受了按要求提交的领取声明调用。物品是否真的离开档案馆，需要外部证据。

3. 精确定义预约与领取规则

Reserve 只能由获授权读者调用，且要求 status 为 Available、paused 为 false。成功后，将 status 改为 Reserved，holder 设为该调用者，deadline 设为当前给定区块号加 20。

Record collection 只能由保管员 C 调用，要求 status 为 Reserved、paused 为 false，并且当前区块号小于或等于 deadline。成功后，status 改为 Collected，保留 holder，并把 deadline 清为 none。

截止边界包含等号，这是有意规定的。deadline 为 120 时，区块 120 的领取调用可以通过，121 则不行。如果不明确比较式，只说“到期之前”过于模糊。

两项规则都先检查全部条件，再改变所列应用字段。玩具模型中，条件失败会让这些字段保持不变。这不表示真实的已纳入失败交易没有费用或发送者计数器影响。

规则规定谁能改变记录，不是规定谁亲手搬走物品。保管员角色是模型里的技术权限；机构政策还需另行说明 C 应在何时使用权限、查看什么证据。

4. 明确退出路径和暂停行为

Cancel 仅允许当前 holder 在 status 为 Reserved 时调用。成功后恢复 Available，并清除 holder、deadline。即使 paused 为 true 也允许取消；本模型没有为取消增加额外截止条件。

Expire 允许任何调用者使用，但要求 status 为 Reserved，而且当前区块号严格大于 deadline。成功后同样恢复 Available，并清除 holder、deadline。暂停期间仍然允许调用。

Record return 仅允许 C 在 status 为 Collected 时调用。成功后恢复 Available，清除 holder、deadline，暂停期间也继续允许。

Set pause 仅允许 A 调用。它只改变 paused，不改变 status、holder、deadline。模型并未另外授予 A 记录领取、把预约转给其他读者，或任意重写其他字段的权限。

这些是给定设计，不是适用于所有系统的安全建议。它体现一种具体取舍：暂停阻止新预约和领取记录，但不阻止指定的现有状态处理路径。其他应用可能需要不同紧急行为，必须独立分析。

5. 跟踪普通成功路径

在给定区块 100，获授权读者 R 调用 Reserve。物品可用且未暂停，调用成功。结果为 Reserved、holder R、deadline 120、paused false。

区块 110，C 调用 Record collection。物品已预约、暂停标志为 false，且 110 不大于 120，因此成功。结果为 Collected、holder R、deadline none、paused false。

区块 130，C 调用 Record return。所需 Collected 状态成立，记录恢复 Available，holder、deadline 均为 none。旧预约截止值不会阻止归还，因为给定归还规则并无该条件。

最后一步说明，函数的实际前提比“物品过期了”这种概括故事重要。预约截止值只约束从 Reserved 状态记录领取的操作；领取成功时已清除，不是所有后续动作共用的截止日期。

轨迹只报告应用状态转移，并给定调用按所列顺序处理。它不能证明物理交接、柜台身份核对成功，或某个真实区块已具备最终性。

6. 边界测试：越过截止值不会自行改写存储

重新从 R 在区块 100 完成预约开始，此时 status 为 Reserved，deadline 为 120。假设直到区块 121，都没有进一步调用。

在模型中，存储状态仍为 Reserved。区块推进改变了哪些调用能够通过条件，却没有执行恢复 Available 所需的字段更新。

区块 121，任意调用者 X 可以调用 Expire。状态为 Reserved，且 121 严格大于 120，因此成功并清除预约。X 不会因此获得所有权或预约，规则规定的结果只是 Available、无 holder。

区块 120 的相同 Expire 调用则失败，因为 120 不大于 120。若其他条件满足，C 在区块 120 记录领取仍可成功。两组比较构成清晰边界，而不是相互重叠的矛盾规则。

某个服务可以替应用提交触发到期处理的交易，但这增加了行动者、交付路径和可用性依赖。代码中存在条件，并不保证有人提交调用，也不保证调用及时纳入区块。

7. 暂停测试：标志只影响实际检查它的操作

再次从 R 在区块 100 的预约开始。区块 105，A 将 paused 设为 true。记录仍为 Reserved、holder R、deadline 120；暂停并未删除预约。

区块 110，C 的 Record collection 因暂停条件失败。具备保管员角色且仍在截止范围内并不够，因为规则要求所有条件同时成立。

同一区块中，R 仍可取消。规则明确允许暂停时取消。成功后，记录变为 Available、holder none、deadline none、paused true。此时 S 仍不能预约，因为 Reserve 要求 paused 为 false。

这揭示两种常见误读：名叫 paused 的变量不一定关闭所有函数；能暂停的管理员也不自动拥有其他角色的全部权限。应逐项阅读条件，不能由一个名称推断广泛能力。

OpenZeppelin Contracts 5.x 权限控制指南介绍所有者和基于角色的权限机制，有助于区分“存在某函数”和“有权成功执行”。它不会认证本课堂设计，也不能替代对管理权限的实际核查。

8. 可以公开调用，不等于可以无限制成功

函数可以允许外部调用者到达，同时在内部执行角色或状态检查。接口可访问性与授权是两个问题。

Solidity 0.8.30 合约参考说明可见性和函数修饰器。这些语言机制有助于表达调用边界和条件，但应用仍必须正确实现预期检查。

例如，X 可能能够提交尝试 Record collection 的调用，但这不会把 X 变成 C。练习中，调用者检查失败，应用字段不变。

网页隐藏某个按钮，不能代替合约检查；另一个界面仍可能尝试相同调用。状态机应在相关执行边界实施条件，而不能只依赖前端约定。

同样，把函数命名为 adminCollect，也不会自动产生权限限制。审查需要看到把调用者与所需角色连接起来的实际条件或机制。

9. 部署与后续调用承担不同任务

应用不仅需要转移规则，还需要初始配置。本练习直接给定初始字段和角色；真实部署必须按平台规则建立对应程序和初始状态。

Solidity 合约参考将构造函数作为合约创建的一部分，后续外部调用属于不同阶段。创建过程正确，不代表此后每次调用都已授权，也不代表后续状态永远适合某项操作。

评价演示时，这一区别很有用。展示部署标识，既不能证明角色分配符合机构意图，也不能证明每个状态转移都经过测试。初始化只是证据链中的一步。

模型的操作定义固定，没有升级机制，但不能概括为所有智能合约系统都如此。有些系统在架构中保留管理或升级能力。真实审查应分别识别这些路径及权限，而不是认为“合约”一词消除了持续控制。

10. 有效声明不等于已核验的物理事件

即使 C 对物理物品判断错误，也可能满足 Record collection 的技术条件。模型仍会一致地记录 Collected，因为设计本来就信任这个获授权声明。

这不意味着记录没有价值。它可以为哪项允许操作被接受、之后状态如何提供可审计线索。但它证明的是系统接受的声明，不会自动证明架子已空或正确的人收到了物品。

以太坊智能合约入门说明链外信息边界：外部数据需要某种进入执行环境的机制。增加传感器或签名报告会改变信任假设，却不会消除测量、身份、时效和故障问题。

对档案馆而言，完整运营设计可能需要收据、员工检查和争议处理。这些是组织选择，不是程序创造的事实。本篇不提供法律建议，也不声称某个状态标签会创设或转移法律权利。

11. 测试通过是证据，不是安全证书

状态机练习的价值在于明确允许与不允许的转移，帮助在把叙述误当实现之前发现遗漏条件。

它不覆盖可执行合约代码的所有风险。Solidity 0.8.30 安全注意事项讨论外部交互和资源限制等问题。模型有意不包含外部合约调用，因此不能证明引入回调等行为后仍然安全。

如果后续设计在领取过程中加入向另一个合约发送通知的调用，假设就改变了。必须检查控制权如何离开并返回、哪些状态已经改变，以及失败如何处理。不能仅因纸面练习通过，就把新功能直接附加上去。

同样，针对 R、C、A 的测试不能证明真实密钥由预期人员掌握、角色管理安全，或紧急访问可恢复。这些属于更大系统的审查范围。

12. 练习：判断转移，而不只看标签

严格使用上述规则。每题指出相关条件及结果字段；除非题目明确描述连续过程，否则各题视为独立情形。

R 在区块 100 从初始未暂停 Available 状态预约。status、holder、deadline 分别是什么？
从该预约开始，C 在未暂停的区块 120 记录领取。能通过吗？之后 deadline 是什么？
从该预约开始，X 在区块 120 调用 Expire。能通过吗？
从该预约开始，直到区块 121 都无人调用任何函数。存储状态会自动变为 Available 吗？
从该预约开始，A 在 105 暂停，C 在 110 尝试记录领取。此后 R 仍可取消吗？
物品状态为 Collected、holder 为 R，A 尝试 Record return。管理员角色足够吗？
C 成功记录领取。合约自身能证明物品已实际交给 R 吗？

答案与理由

status 为 Reserved，holder 为 R，deadline 为 120，paused 仍为 false。
可以，假设给定的 C 与 Reserved 条件成立。比较式包含等号。status 变为 Collected，holder 保持 R，deadline 清为 none。
不能。Expire 要求区块严格大于 120，而不是等于。预约字段保持不变。
不会。在允许操作执行前，记录仍为 Reserved。Expire 已符合调用条件，但符合条件不等于已执行更新。
可以。领取因 paused 为 true 而失败，但当前 holder R 明确可以在暂停期间取消。成功后恢复 Available、清除 holder 和 deadline，paused 仍为 true。
不够。模型仅允许 C 记录归还。A 的暂停权限不包含 C 的权限。
不能。按给定模型，它只证明获授权声明被接受及对应应用状态，物理交接需要独立证据。