主密钥离线，程序怎样代办？

一个程序需要每天替你处理几笔链上交易。把账户主私钥放进服务器，它就能自动运行；服务器一旦被入侵，攻击者也可能得到这把钥匙所控制的全部权限。每笔交易都由你亲自签名，则意味着你必须一直参与。

委托授权提供了另一种安排：你签署授予权限的交易，程序随后用自己的密钥，在获准范围内代表你执行。 系统需要同时判断“这个签名是否有效”和“签名者此刻有没有权做这件事”。少了后一项，换一把钥匙并不能产生有限授权。

ArcBlock 的 US11245514B1 描述了这种安排：权限保存在链上的委托状态中，受托人使用独立密钥签名，验证节点据此检查代办交易。该申请提交于 2019 年，2022 年获得授权；本文解释公开文本中的机制，不把它当作所有 ArcBlock 产品的当前功能表。完整书目信息见专利记录。

两把钥匙，各自证明什么

委托人是授权的一方，受托人是被允许代办的一方。两者可以是不同的人，也可以是同一个人控制的两个账户：一个保存主密钥，另一个供在线程序使用。

授权时，委托人用自己的私钥签名，说明把哪些操作交给哪个受托人。节点验证这笔授权交易后，更新相应的委托状态。后来程序提交代办交易时，使用受托人的私钥签名；交易还需要让节点知道，它是在代表哪个账户行事。

这两次签名承担不同的工作。第一次支持“账户所有者授予了这些权限”；第二次支持“这笔代办交易由持有受托密钥的一方签署，签名覆盖的内容未被改动”。第二次签名不会凭空带来第一次授权中没有的权限，也不能证明操作符合账户所有者没有写进规则的意图。

因此，验证节点既要检查受托签名，也要读取对应的授权状态。签名正确但权限已被撤销，交易仍不能按这项授权执行。权限存在但签名伪造，同样不能执行。原专利的权利要求 1 将权限检查与受托签名验证放在同一处理流程中。

跟着一笔代办任务走一遍

考虑一个用于解释机制的假设例子：某个账户允许一个程序在指定时间段内代办最多三次转移，累计不超过十个资产单位。这些数字只是教学设定，不是产品默认值；具体资产和操作能否这样限制，要看执行系统的支持。

开始之前，所有者需要把允许的操作和相应限制写进授权，签名并提交。只有授权已经按所用链的规则生效，程序才应开始依赖它执行任务。钱包弹出“已发送”，不等于授权状态已经更新。

假设第一次代办转移两个单位。程序用受托密钥签名提交后，系统要查对应的委托关系、检查操作类型与限制，并验证签名。如果这次操作获准执行，后续检查就应使用已更新的使用记录。第二次再转移三个单位，累计变成五个单位、两次操作。

原专利权利要求 7 描述按时间段限制交易次数和数量。表格把这些约束组合成便于理解的例子；实际系统仍需定义计量单位、时间边界，以及失败交易是否消耗额度，不能从例子推定。

并发也不能省略。两个请求可能同时到达，都声称只使用剩下的最后一次权限。实现需要让检查和使用记录的更新遵循一致的执行顺序，防止两次请求都凭同一份旧记录获准。这是实现累计限制时要验证的问题，不能仅凭界面上显示了“最多三次”就认定已经解决。

撤销什么时候开始起作用

原专利权利要求 2 描述通过后续交易撤销权限。撤销要改变验证节点执行下一笔交易时读取的授权状态；它不会让受托密钥本身消失，也不会把已经完成的操作倒回去。

假设程序正在提交第三笔交易，所有者同时发现异常并提交撤销。这时，点击按钮的先后不能直接决定结果：如果代办交易先按有效授权执行，后来生效的撤销不能抹去它；如果撤销先改变了执行所依据的状态，之后依赖这项权限的交易就应被拒绝。应用应按所用链的确认规则展示状态，不把提交撤销直接显示成所有风险已经结束。

受托密钥泄露时，攻击者仍可能使用尚未撤销的权限。次数、数量和操作范围可以缩小这把密钥能做的事，但实际保护取决于限制是否足够窄、是否被执行，以及所有者能否及时撤销。独立密钥降低了主密钥必须持续暴露在线上的需要；它不会让在线程序无需保护。

还有一个容易被忽略的问题：如果主密钥平时离线保存，异常发生时，谁能签署撤销交易？必须事先设计好这一步。离线保管可以降低暴露，却也可能增加重新取得签名能力的时间。

怎样把它用在一个实际系统里

先从一项具体任务开始，列清受托人、操作类型和必要限制，再核对系统究竟执行哪些规则。不要把写在说明文字里的“每日上限”当成验证节点已经实现的约束。

一次有意义的验收，应包含授权前请求被拒绝、授权后范围内请求成功、越界请求被拒绝，以及撤销生效后原先有效的请求被拒绝。还应观察并发请求怎样计数，确认失败如何返回。记录授权、执行和撤销的交易标识，才能在结果不符合预期时重建经过。

已有的委托权限指南提供了 SDK 的授予、代办和撤销示例，可以用来了解软件如何发起这三类操作。实际使用前，仍需核对所用软件版本、服务地址，以及支持哪些权限限制；这里不把旧指南中的测试服务当作今天仍可用的试验环境，也没有把上述假设数字写成可直接运行的配置。

《AI Agent 不只是需要一只钱包》讨论的是更大的问题：Agent 代表谁、依据什么授权、结果如何核对。链上委托能够处理其中一部分签名和权限检查，却不会自动给 Agent 增加判断业务意图的能力。程序在许可范围内做了一件错误的事，仍然可能通过验证。

什么时候不适合用它

如果任务只是读取相册或调用普通服务，就应先看服务自身的访问控制，不必为了“可以代办”而引入链上交易。有限代办权限这篇 Learning 从这样的日常场景讲起。

对偶发且后果重大的操作，逐笔由所有者确认可能更合适。委托带来自动化，同时要求所有者事先表达允许的范围；如果这个范围无法清楚描述，或者执行方根本不检查它，提前授予权限就未必值得。

主密钥遗失也属于另一个问题。委托让已有权限可以由另一个密钥使用，不等于自动建立账户恢复能力。能否更换密钥、迁移账户或取消旧权限，要看另外的规则，不能从“受托人还能执行几笔交易”推出“账户已经可以恢复”。

回到主密钥为什么可以离线

原专利权利要求 4 描述以离线方式保存委托人的私钥。关键在于：权限已通过授权交易进入系统，后续获准的交易可以依靠受托签名验证，因此不必每次唤起主密钥。创建授权、修改安排和应对异常需要什么签名，仍要分别解决。

同族的 US11838405B1 是延续申请，其权利要求也涉及条件检查和撤销。它不是“到第二件专利才有这些功能”；两件文献各自记载的权利要求应分别阅读，关系见延续申请记录。

程序能够自动代办，靠的是一份会被检查、可以发生变化的授权，以及程序自己的签名。主密钥可以少出现，授权依据必须一直在场。判断一个系统是否真的提供了有限委托，最有用的测试是：同一把受托密钥，在越界或撤销之后，是否还能把交易做成？