English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC062
钱包画面不能展示完整的控制安排。使用界面的人可能自己持有签名权限，也可能依赖掌握权限的服务，或者参与需要多方同意的政策。恢复和管理路径又可能改变这一安排。
从技术角度理解托管，应问谁能授权动作、谁能阻止动作、谁能恢复或替换权限，以及什么证据证明请求结果已经发生。与产品标签相比，这些答案更有解释力。
本篇比较控制目录账户的三种虚构方式，不涉及真实密钥、资产转移、钱包设置、服务推荐或金融决策。目标是在进一步讨论恢复之前，先看清控制依赖。
选择适合你的阅读路线
本篇目录
- 1. 把界面与权限分开
- 2. 用同一个无害任务比较
- 3. 对每种安排问五个问题
- 4. 安排 A：用户持有普通权限
- 5. 安排 B：服务控制权限
- 6. 安排 C：共享普通动作，并配置恢复路径
- 7. 用同一种中断检验三张案例卡
- 8. 检查政策变化与替代执行路线
- 9. 能阻止与能行动，是两种能力
- 10. 在真正完成的边界要求证据
- 11. 写一份简明控制记录
- 12. 练习与参考答案
- 资料来源与延伸阅读
第 1–3 节区分界面、账户与权限。第 4–6 节比较用户控制、服务控制和共享政策安排。第 7–10 节检验中断、恢复、替代执行路径与完成证据。练习要求按精确给定规则，判断谁能做什么。
前面的密钥课解释签名机制，共享控制课比较多重签名与门限设计。这里的学习任务是机制周围的责任图：控制权、阻止能力、恢复和政策改变。
1. 把界面与权限分开
钱包界面可以准备请求、显示账户信息，并与签名或网络服务通信。这些功能不会告诉我们账户动作所需权限究竟在哪里。
以太坊钱包介绍把钱包描述为与账户互动的工具。本文只采用这项界面区分；其中面向消费者的概括，不能替代对具体产品控制与恢复安排的检查。该页面更新于 2026 年 2 月 24 日。以太坊钱包
手机上显示的应用可能访问用户控制的签名器、向服务发送指令，或为可编程账户收集审批。看起来相似的按钮，可能启动完全不同的权限路径。
地址在网络上下文中识别账户或目的地。知道地址或查看历史，不证明能够授权下一次动作。同样，登录网站也不自动等于持有链所认可的权限。
先问一个实际问题：如果这个界面消失，还有什么独立可用能力，可以让获授权动作满足账户规则？不要从界面名称推断答案。
2. 用同一个无害任务比较
虚构目录账户可以请求修改一个公开标签。三种安排使用的应用操作都已正确规定。除非案例明确说明，链、应用和所需提交资源均可用。
假设签名、政策检查和请求上下文绑定都正确工作，没有案例依赖密码学伪造。还假设所请求更新满足应用普通有效性条件，让我们能专注于谁可授权。
下文的“能够行动”，表示能够满足该安排的授权条件，不保证立即纳入、在所有可能后续状态下都执行成功，或已经取得最终性。这些仍是不同阶段。
虚构参与者为用户 U、服务 S 和恢复方 G。字母代表角色，不是真实人物或服务商。需要两方合作时，独立控制是应检查的明确假设，不是起两个不同名字就会成立的事实。
我们区分技术能力与组织许可。某一方在技术上可能能够授权，政策却规定它不该这样做。单凭技术图不能确定法律权利、合同履行或读者的权益。
3. 对每种安排问五个问题
第一，谁能满足普通授权规则？第二，谁可以拒绝提供必要贡献，进而阻止这条路径？第三，已经配置了什么恢复能力？第四，谁能改变参与者或政策？第五，什么证据证明指令完成？
这些问题应覆盖所有已启用路径，不只覆盖平常使用的路径。恢复路线是控制系统的一部分；能替换获授权方的管理功能也是。
答案可能是个人、组织、设备、合约规则或组合。应准确说明决定发生在哪一层。客服可能可以恢复服务登录，却没有独立重建用户自持签名密钥的能力。
反过来，即使界面把账户描述为属于用户，链认可的签名权限仍可能由服务掌握。双方关系可能包含服务义务，但这些义务与链上的授权检查不是一回事。
本比较不是从最好到最差的排名。不同安排把责任和失败模式移到不同参与者。有效评估应识别这种移动，而不是用一个托管标签掩盖它。
4. 安排 A：用户持有普通权限
在安排 A 中，目录账户普通动作所需签名权限完全由 U 控制。界面供应商和服务 S 没有签名材料副本，也没有其他授权路径。基础案例没有另行配置的恢复方或政策替换权限。
按这些假设，U 可以不经 S 批准就授权更新。S 不能仅靠拒绝批准，便否决账户授权规则，因为该规则不要求 S 同意。
但是，用户仍可能依赖界面或 RPC 服务商准备和传递请求。下面的特定中断案例明确给出：U 有正确运作的替代界面与提交路径。这个可用性是新增事实，不是“用户自持”几个字自动保证的。
如果 U 丢失全部可用签名材料，而且没有替代恢复规则，案例就没有剩余授权能力。只能恢复网站登录的客服，不能制造丢失的签名权限。
这不规定备份方法，也不声称所有用户控制系统的恢复设计相同。它只说明本案例刻意限定安排的后果。下一篇会分别检查不同损失与恢复情况。
5. 安排 B：服务控制权限
在安排 B 中，S 控制链认可的签名权限。U 有 S 服务的登录能力，可以向它发送指令，但对该账户没有独立签名材料或链上授权路径。
普通流程可能要求 U 在服务界面批准指令。这可以是重要的组织保障。不过，在本案例中，链检查的是 S 的权限，不会另外验证 U 的服务登录审批。
因此，S 在技术上能授权目录更新；U 仅知道账户地址或服务密码，不能独立授权。S 也可以不采取行动，从而阻止普通流程。
如果 U 丢失服务登录，S 可能按规定的账户恢复程序恢复登录。这改变的是服务访问，不改变 S 控制链上权限的基本事实。案例不承诺真实服务商会多快恢复，或要求什么证据。
一份写着“已收到指令”的服务回执，只是指令接收边界上的证据。它还不证明 S 已签名、交易已纳入或目录标签已改变。即使界面只用一个简单状态词，也应保留阶段区别。
6. 安排 C：共享普通动作，并配置恢复路径
在安排 C 中，正确强制的政策要求普通动作同时得到 U 和 S 授权。任何一方都不能独自授权普通目录更新。这里不规定实现采用独立签名还是其他机制，重点是给定访问规则。
账户还预先配置恢复路线。G 和 S 可以共同批准，在规定延迟及其他必要条件满足后，替换 U 的授权位置。将该规定延迟记作 D；D 是虚构政策参数，不是普遍时长。这条路线不能替换 S、改变普通动作必须两方参与的要求，或修改无关政策。题目没有提供额外隐藏路径。
当 U 的旧权限丢失时，只要 G 和 S 合作且全部条件满足，这条恢复路径就能恢复用户位置。它不是重建旧秘密，而是按既有规则改变由哪个权限占据用户位置。
同一能力也意味着：如果满足给定恢复条件，即使原始 U 反对，G 和 S 也能一起替换原始 U。替换后，新用户位置的权限与 S 可以满足普通规则。这是技术能力，不表示组织允许这样使用。
本案例的普通动作和恢复都需要 S。因此 S 拒绝或不可用时，两条路线都受阻。G 单独不能执行普通更新，也不能替换 U。如果只把账户描述为“用户必须签名”，这些后果很容易被漏掉。
7. 用同一种中断检验三张案例卡
假设 S 不可用，但链和题目明确给出的替代工具仍可用。在 A 中，U 仍能满足授权条件，因为不需要 S。在 B 中，U 没有链认可的签名权限，无法绕过 S。在 C 中，普通动作和恢复都需要 S，因此这两条路线不能完成。
再假设只有界面供应商的网站不可用。对于 A，给定替代界面与提交路径允许 U 继续。对于 B，换一个显示界面不会把 S 的签名权限交给 U。对于 C，替代界面仍需要规定参与者和政策执行路径。
最后，假设在 U 持有签名能力的安排中，U 丢失了该能力。A 的基础案例没有替代权限；C 中，预配置的 G 与 S 恢复路径可以在条件满足后替换用户位置。B 中，U 原本就没有链上密钥，丢失服务登录是另一问题。
这些是能力比较，不是成功交付保证。替代路径、合作和政策条件必须真实存在并可用。架构图无法提供从未配置过的能力。
8. 检查政策变化与替代执行路线
若没有说明共享规则怎样改变，“共享控制”就是不完整描述。如果某个管理员可以悄悄减少所需审批集合，它就拥有超出普通签名路径的权限。
C 案例刻意限定恢复范围：只替换 U 的位置，而且仍需要 G 和 S。另一张允许 G 单独修改所有规则的案例卡，会有不同控制图。不能因为两者都使用“恢复”一词，就把它们混为一谈。
Safe 文档提供了为什么需要检查已启用路径的具体例子。它描述所有者数量门槛执行，也描述可采用其他访问模式的模块。模块文档提醒，模块与安全高度相关，可能执行具有广泛权限的交易。这些事实要求检查实际配置，并不表示每个 Safe 都有相同模块或恢复权限。Safe 账户概览、Safe 模块
同样，可编程账户的签名验证可能取决于政策。ERC-1271 规定合约报告某个代表它的签名是否有效的方式，验证可以依赖上下文或状态。它不强制某种托管或恢复安排。ERC-1271
应一起检查普通审批、恢复、管理员和所有已启用替代执行路径。只统计平常的签名方，可能低估实际控制能力。
9. 能阻止与能行动，是两种能力
在 C 中，S 不能单独授权普通更新，却能拒绝提供必需贡献来阻止更新。这是不同权力。某一方可以没有单方面支出或更新能力，同时仍是关键可用性依赖。
G 的角色又不同。普通动作不需要 G，因此 G 日常缺席不会阻止 U 与 S 合作。特定恢复路线需要 G，所以替换 U 位置时，它的缺席就很重要。
B 中，S 同时有普通行动权限和阻止能力。A 中，界面供应商按账户规则两者都没有，不过如果界面是唯一渠道且没有替代，不可用仍可能构成运行障碍。我们的特定 A 中断案例提供了替代，所以只在该案例中移除了这项障碍。
好的责任图同时记录正向和否定能力：能授权、能拒绝必要贡献、能改变权限，以及能提供或扣留必要信息。任何一项都不自动意味着全部其他能力。
不要把服务承诺变成技术不可能性判断。“服务承诺只按我的指令行动”与“协议使它无法在没有我独立授权时行动”不同。两种说法都需要证据，但证据类型不同。
10. 在真正完成的边界要求证据
对目录任务，完成是预期标签更新出现在身份明确的已接受历史中，并具有所需保证。显示已准备请求、已收集审批或服务已确认的画面，都属于更早阶段。
A 中，U 的签名证明授权，不自动证明执行。B 中，S 的指令回执不证明链上行动。C 中，收集到规定审批，不等于政策执行已发生且应用已接受更新。
验证记录应连接请求身份、网络、账户、预期操作、纳入上下文与应用结果。如果最终性属于所需保证，就单独保留该证据，不从钱包界面推断。
这也有助于说明服务商究竟能恢复什么。恢复登录、恢复未来动作的授权能力，以及撤销过去已接受的效果，是不同任务。能做其中一项，不证明能做其他项。
更广泛的数字韧性课强调恢复可信功能，而不只是恢复画面。这里的具体检验是：按照安排的实际规则，能否建立所声称权限与已完成目录效果的证据。
11. 写一份简明控制记录
对 A，写明：只有 U 能满足普通授权；S 不是必需方；题目没有替代恢复；独立可用工具只在明确给出的中断案例中假设存在。没有证据就不要加入服务商恢复权限。
对 B，写明：S 持有链权限；U 有服务指令访问能力；S 可以行动或不行动；服务登录恢复与链权限分开。在把服务声明视作已执行更新前，仍需要相应完成证据。
对 C，写明：普通动作同时需要 U 和 S；G 与 S 可经配置的延迟路线替换 U 位置；S 可以阻止两条路线；G 单独不能行动。恢复能改变实际用户控制，所以应与普通签名放在同一记录中。
评估真实系统时，还应识别软件和已部署政策版本、已核验参与者、已启用路径，以及未知配置。未知不等于不存在。即使某功能宣传为可选，也要回答它是否在被评估账户中启用。
记录应保持描述性。它不是选择某种安排的建议，不判断法律所有权，也不承诺某种金融服务可以向读者提供。
12. 练习与参考答案
问题 1。 S 离线，但 A 中的用户权限和明确给出的替代工具可用，是否需要 S 批准？
答案。 不需要。按 A 的规则，U 可独立满足普通授权。纳入与应用执行仍需要其他条件。
问题 2。 B 中，U 知道账户地址和服务密码，这提供独立链权限吗？
答案。 不提供。案例把该权限交给 S。
问题 3。 C 中，G 能单独替换 U 位置吗？
答案。 不能。配置的路线要求 G、S、延迟和其他条件。
问题 4。 C 中原始 U 总能阻止 G 与 S 替换用户位置吗？
答案。 按给定规则不能。只要全部条件成立，G 与 S 可不经原始 U 批准完成该路线。这是技术能力，不是滥用许可。
问题 5。 C 已收集 U 与 S 审批，是否证明目录更新完成？
答案。 没有。仍需要执行以及相应应用和链证据。
问题 6。 为什么除普通签名方外，还要检查已启用模块和管理路径？
答案。 它们可能提供另一条执行动作或改变权限的路线，实际范围可以改变控制图。
资料来源与延伸阅读
资料核对日期：2026 年 10 月 12 日。
- 以太坊钱包，页面更新于 2026 年 2 月 24 日，仅用于区分钱包界面与账户。
- Safe 账户概览，用于所有者与替代路径概念，不采用安全宣传或普遍账户判断。
- Safe 模块，用于已启用替代执行权限及其风险。
- ERC-1271，状态为 Final，创建于 2018 年 7 月 25 日，用于合约签名验证，不作为强制恢复设计。
A、B、C 是原创控制安排，不描述特定产品。下一篇恢复课会区分设备丢失、权限丢失、应用状态缺失，以及仍可使用的权限已经被他人掌握。