English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC065
一项代币授权可能在用户原本想完成的动作结束后，仍留下可继续使用的权限。要理解这种权限，需要单独追踪授权额度记录：谁持有单位、哪个支出方可以行动、记录属于哪条链和哪个代币合约，以及在所检查状态中还剩多少权限。
余额回答账户当前持有多少单位；授权额度回答另一方获准使用这些单位的范围。批准一个数额不一定立即转移单位，完成一次转移也不一定消除其余额度。
本课使用没有货币价值的虚构整数单位，只进行状态与权限的纸面练习，不要求批准真实代币、连接钱包或修改实际账户。学习成果是一份准确账本，以及对各项记录允许什么行为的清楚解释。
选择适合你的阅读路线
本篇目录
- 1. 从身份完整的权限记录开始
- 2. 区分三种操作
- 3. 完整的虚构账本规则
- 4. 逐步完成八个步骤
- 5. 找出原定动作完成后留下的权限
- 6. 当前状态的上限，不是整个期间的上限
- 7. 改变权限本身也是状态变化
- 8. 签名批准也可能形成持续额度
- 9. 结合实现与已识别状态读取记录
- 10. 把最小权限转化为具体问题
- 11. 练习与答案
- 12. 来源与下一步问题
- 第1至3节明确身份、操作类型和完整教学规则。
- 第4至7节逐步计算账本，检查每次动作后还剩什么。
- 第8至12节讨论签名授权、证据、最小权限及练习答案。
1. 从身份完整的权限记录开始
在特定代币合约内，一项额度关系可以写成：持有者O允许支出方S使用指定数量。解释数值前，要先写明链和代币合约身份。另一条链上的代币即便具有相同符号或显示名称，也不会因此成为同一权限记录。
ERC-20区分transfer、approve、transferFrom与allowance。批准操作设置支出方额度，之后再次批准会替换已有值。该标准创建于2015年11月19日，本课核对时状态为Final。参见ERC-20标准。
本课虚构记录属于链C上的TokenT，持有者为O，支出方为S。这些名称是练习中的确切身份。授予支出方R的额度属于另一项记录；TokenU的额度也属于另一项记录，即使界面给TokenU与TokenT显示了相同符号。
因此，“我批准了这个应用”通常不足以构成技术说明。应用指定的是哪个链上支出方？哪个代币的规则解释这项权限？当前记录数值是多少？这些答案比产品标志或浏览器标签页更能界定权限范围。
2. 区分三种操作
在本练习中，直接转移是O通过自身获授权的动作，把单位转给另一个账户。它减少O的余额，但不消耗单独记录的O对S额度。
批准改变额度记录。它本身不把单位从O转给S，也不把单位存入一个独立预留池，更不保证后续委托转移一定成功。
模型中的委托转移由S发起，把单位从O转给指定接收方，同时要求余额和额度都足够。S是获授权支出方，不一定是最终接收方。这个区分很重要：界面可能展示一个接收对象，而另一项权限指定的是有权发起转移的主体。
这些定义是题目给定的教学规则，参考了一种常见代币接口。其他代币类别或扩展可以采用不同授权模型。不能假设本额度账本适用于所有区块链资产、账户模块或操作方权限。
3. 完整的虚构账本规则
初始时，O持有100个TokenT单位，O授予S的额度为零。所有接收方均与O不同，且在练习中有效。转入单位来自另一个余额充足的账户。
主流程始终遵循以下规则：
- 批准n会将额度替换为n，不是增加n。
- 成功委托转移n，要求O余额和S剩余额度都至少为n。
- 该转移使O余额及有限额度各减少n，接收方增加n。
- O成功直接转移n，会减少O余额并增加接收方余额，但不改变S额度。
- 转入增加O余额，不改变S额度。
- 被拒绝的动作不改变任何所追踪代币余额或额度。
全部数额均为非负整数。模型没有转移手续费、余额重定基、暂停、回调、自动到期、隐藏权限或最大值额度的特殊行为。交易费用和其他链记账不在本练习范围内。列为成功的步骤均已按照给定顺序被接受，而不只是等待中的请求。
明确这些假设，可以避免误导性的捷径。实际实现可能加入改变结果的行为。本课之所以能精确计算，是因为规则和顺序已被给定，而不是因为所有代币合约都可以互换。
4. 逐步完成八个步骤
初始状态为余额100，额度0。
步骤1：O批准S使用30。新状态为余额100、额度30，没有发生单位转移。不能从O余额减去30，也不能给S余额增加30。
步骤2：S从O向接收方A委托转移12。两项检查都通过：100不少于12，30也不少于12。O余额变为88，额度变为18，A收到12。
步骤3：O直接向接收方B转移5。O余额变为83，O对S额度仍为18。这次转移使用O自身的直接权限，没有消耗S额度。
步骤4：O把S额度替换为10。新状态为余额83、额度10。结果不是28，也不是8。这项操作设置替换值，既不是在原有18上加10，也不是减10。
步骤5：S尝试委托转移11。余额足够，但额度只有10，因此动作被拒绝，所追踪状态仍为余额83、额度10。不能先扣除11，再虚构一个负额度。
步骤6：S向A委托转移10。两项检查均通过，O余额变为73，S剩余额度为零。A在步骤2和6中合计收到22。
步骤7：O从另一个账户收到20。O余额变为93，S额度仍为零。收到单位本身不会为S创建新权限。
步骤8：S尝试从O转移1。即使O余额为93，额度检查仍会失败。最终所追踪状态保持余额93、额度零。
再独立核对O的算式：100 − 12 − 5 − 10 + 20 = 93。批准步骤和被拒绝尝试都没有造成余额移动。接收方A合计收到22，B收到5，而另一转入方提供了20。这些都是模型内转移，并没有凭空创建新单位。
5. 找出原定动作完成后留下的权限
假设学习者最初只想完成步骤2的12单位转移。该动作结束后，账本仍保留18的额度。原定任务完成，并没有抹去剩余权限。
这并不是预测S一定会使用余量。能力与已观察行为是两回事。它表示：按照给定代币规则，只要余额和其他条件满足，剩余数额范围内的委托转移仍被允许。
在步骤2后关闭界面，并不属于本模型的代币状态变化规则；断开浏览器会话同样如此。这些动作可能改变本地交互，但不会修改已经建立的额度。若要声称链上权限已改变，需要实际被接受、且影响该权限的状态变化证据。
同样，最终额度为零，只能说明链C上TokenT中的这一项O–S关系。它不能证明其他支出方、其他代币、其他链或另一种授权机制都不存在权限。清楚的检查应保留范围，不能把一个令人放心的数字扩展为普遍结论。
6. 当前状态的上限，不是整个期间的上限
现在使用一份与主流程无关的独立状态：O余额为20，授予S的有限额度为50。按照相同教学规则，立即可行的最大委托转移量为20，即余额与额度中较小的数值。
但20并不是S整个授权期间可使用数量的上限。假设尚未发生支出，O随后收到40，余额就变为60，额度仍为50。此时立即可行的最大委托转移量变为50。
另一种顺序是S先转走原有20。余额变为零，额度还剩30。如果O后来收到40，S仍可在相同规则下继续转移最多30。两次委托转移合计可能使用完整的50额度。
这不是对损失的预测，而是在计算范围：未来转入的单位可能落入已有权限可使用的范围。“账户现在余额很少”与“剩余权限很小”是两种不同说法。
余额为零，也不代表额度为零。前者表示当前没有持有单位，后者表示这一项剩余权限不存在。分开记录两列，就能避免混淆，而无需猜测未来行为。
7. 改变权限本身也是状态变化
在主流程中，步骤4明确先于步骤5被接受，所以11单位尝试看见的是10额度。如果手里只有两个待处理请求，以及希望它们按某个顺序发生的愿望，就还不能得出相同结论。
请求降低额度，并不能证明旧额度已经改变。界面宣布提交，也不能证明后续动作使用了新状态。需要核实的是：哪个更新被接受、顺序如何、尝试使用权限时实际读取哪个状态。
本课不提供实际额度修改流程。真实工作流存在实现与排序问题，ERC-20本身也提醒了改变额度时的风险。这里的教学重点较窄：不能把希望未来成立的权限，与当前已经建立的权限混为一谈。参见ERC-20批准语义与提醒。
在相关状态中，降低额度一旦已经成立，其作用按照本模型面向后续使用。它不会撤销先前被接受的转移，也不会收回已经到达接收方的单位。那些结果需要其他动作及相应权限，而且未必存在可行路径。
8. 签名批准也可能形成持续额度
批准并不总是由持有者直接调用approve而产生。ERC-2612定义了permit扩展，允许有效签名消息授权更新额度。它创建于2020年4月13日，当前核对状态为Final；规范包含nonce和接受permit的截止时间。参见ERC-2612 permit扩展。
这个截止时间约束的是permit的接受，而不是自动成为普通额度的失效时间。考虑一个独立教学变体：格式正确的permit在截止时间前被接受，建立了15额度。之后没有支出或额度修改，代币也没有独立到期机制，那么超过该截止时间并不会自动把已经建立的额度降为零。
反过来，持有一份尚未递交的签名消息，也不能证明额度已经改变。它只是某项可能获授权更新的证据，仍取决于扩展条件及实际接受。应将“已签名”“额度更新已被接受”“之后委托使用”分别记录为不同事件。
不要仅凭按钮标为“permit”或“签名”，就推断采用了这里的确切格式。扩展和实现可能不同。本课没有提供需要签署的消息，而是说明：理解一项签名请求，也包括理解它可能在之后建立什么权限。
9. 结合实现与已识别状态读取记录
本课特意使用会递减的有限额度，但不能据此推演所有实现细节。例如，固定版本OpenZeppelin Contracts v5.4.0的ERC20实现，对最大uint256额度采用特殊处理，在transferFrom时不减少该值。其普通有限额度消费路径，也不一定为每次递减发出新的Approval事件。参见OpenZeppelin ERC20 v5.4.0源码。
因此，除非已考虑相应实现和期间全部状态变化，“我找到了最新Approval事件”本身不足以推导当前剩余值。额度数值应关联正确合约和一个已识别状态，并说明该观察来自哪里。
单位同样重要。OpenZeppelin文档说明，小数位属于显示信息，不会改变合约算术。本课整数无需小数换算；实际显示比较则必须先统一两边单位惯例，再判断数值是否相等。参见OpenZeppelin ERC20文档。
首先需要解决的是证据问题，而不是急于给出安心结论。不完整的仪表板可能有助于寻找待检查记录，但缺少一行记录，并不能证明所有可能权限都不存在。
10. 把最小权限转化为具体问题
最小权限需要对应实际任务才有用。如果虚构任务只需要一次12单位委托转移，就应问：为什么提出30额度？哪个支出方得到它？任务结束后还剩多少？较宽额度可能是有意的设计选择，但这个选择应该被清楚说明，而不是藏在便捷功能名称中。
数额限制也不表达全部可能约束。在本模型中，12额度限制S可以使用的数量，却没有指定某个接收方、业务用途或截止时间。那些限制需要额外规则。因此，不能把有限数额描述为“已经限制了所有方面”。
有用的权限检查应记录原定任务、确切身份组合、所需数量、最终剩余权限，以及任何被声称存在的其他限制。它还应记录修改证据，包括已知修改生效的被接受状态。
目标不是假设最小数字总能解决整个问题，而是让授予的能力与所述任务相称，避免默默加入说明中没有提及的权力。任何额度数值都不能证明无关合约正确，也不能证明现实活动具有合法性。
11. 练习与答案
练习1：批准还是转移？
步骤1之后，O持有多少单位？S通过这次批准收到了多少？
答案：O持有100，S从批准中收到零。额度变为30，这是权限记录，不是转移。
练习2：哪一列改变？
步骤2后状态为88/18，O再直接转移5。下一组余额/额度是多少？
答案：83/18。直接转移改变余额，没有消耗S额度。
练习3：替换计算
额度原为18，一项已接受批准将其设为10。新值是28、8还是10？
答案：10。给定规则是替换，不是增加或扣减。
练习4：余额足够，权限不足
O余额83，S额度10。S尝试转移11，所追踪账本发生什么变化？
答案：没有变化，因为额度条件失败。交易费用记账不属于本教学模型。
练习5：未来转入单位
O余额20、额度50。S转移20后，O又收到40。相同规则下，S接着最多能使用多少？
答案：30。余额为40，剩余额度为30。先前转移并没有消除未使用权限。
练习6：permit截止时间
有效permit在截止时间前建立了15额度。之后没有使用或更新，也没有独立到期机制。截止时间过去后，额度会变成零吗？
答案：不会。该截止时间约束permit的接受，不约束已建立额度的持续时间。
练习7：符号相同，记录不同
TokenU与TokenT显示相同符号。TokenT的零额度能否证明TokenU额度也是零？
答案：不能。合约身份不同，每项权限都必须在自己的情境中获得证实。
12. 来源与下一步问题
来源核对于2026年10月12日。标准日期表示文件创建时间，不表示每个类似接口代币的上线日期，也不能代替其实际行为说明。
- ERC-20：转移、批准、替换与额度概念。
- ERC-2612：签名额度更新、nonce与接受截止时间。
- OpenZeppelin Contracts v5.4.0 ERC20源码：具体版本的额度与事件行为。
- OpenZeppelin ERC20文档：实现背景及显示单位区别。
如需广泛基础，可阅读How Blockchain Works。下一步可比较界面所说的动作，与签名或交易实际授予的权限。额度账本为这种比较提供了具体检查对象：权限可能持续存在，其确切范围值得单独说明。