English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC081
要了解谁治理一个区块链应用，可以选择一项具体变更，从提议一直追踪到可观察的实际效果。谁能提出建议？谁能批准这项确切变更？谁能阻止、排期或执行？谁又能更换这些角色的担任者？“社区治理”这样的单一标签，无法回答全部问题。
本课使用一个虚构目录应用：把每次提交的条目上限从四项改为六项。这个小例子揭示了更普遍的问题：提案、支持性的审查意见、已批准的决定、软件发布以及运行中系统的改变，分别属于不同证据。
练习关注技术权限与证据，不指导读者配置真实管理员、提交治理交易、获取投票代币或改变真实网络。下文的人物、时间与权限均为虚构。
选择适合你的阅读路线
本篇目录
- 1. 先明确改变的究竟是什么
- 2. 给提案一个确切身份
- 3. 用动词描述权限
- 4. 审查与发布是有意义的中间结果
- 5. 等待期带来执行资格，不会自动完成操作
- 6. 继续追踪到用户实际看到的系统
- 7. 在正确时点检验否决权
- 8. 批准不会自动延伸到另一份变更内容
- 9. 谁能替换掌权的角色
- 10. 建立别人能够核对的证据链
- 11. 练习与答案
- 12. 常见问题
- 13. 资料来源与延伸阅读
- 阅读第1至3节，明确变更对象，并区分参与者的权限。
- 跟随第4至6节，理解批准、等待期、执行与采用之间的关系。
- 用第7至9节检验取消、变更内容不匹配与角色替换的情形。
- 最后完成证据清单、练习与常见问题。
1. 先明确改变的究竟是什么
“改变区块链”过于宽泛，难以分析。团队可能改变网页标签、应用中保存的参数、合约实现、节点的本地策略，或者底层网络的验证规则。这些行为的效果不同，负责授权的人也可能完全不同。
本例改变应用登记簿C中的一个参数。C当前为修订版7，每次最多允许提交四个目录条目。提案P要把上限设为六项，并把登记簿推进到修订版8。它不改变底层区块链的共识规则或验证规则。
门户可能需要新的显示软件包，才能向用户解释六项上限。但仅改变门户，不会改变C。反过来，改变C也不保证所有门户马上显示新值。
因此，治理分析的第一行应明确对象与范围。“C的提交上限”可以检验；“整个生态已经升级”则不够具体。
这个区分也有助于分清应用治理与协议治理。以太坊官方治理说明将其协议变更过程描述为链下治理，并与部分应用使用的链上治理区分开来。这是有范围的描述，不表示所有应用都采用同一种流程。以太坊治理说明
2. 给提案一个确切身份
虚构提案P明确绑定以下字段：
- 指定的网络与登记簿C。
- 预期当前修订版为7。
- 当前上限四项，拟改为六项。
- 执行后修订版为8。
- 指定的门户显示软件包R2。
- 明确不包含管理员或执行者角色变更。
假设提案的表示方式能无歧义地绑定这些字段，并且练习提供的证据真实，且已满足相关记录终局性的假设。本课集中分析治理关系，而不是要求读者认证真实链上记录。
为什么需要预期修订版？因为针对某一状态批准的变更，不一定获准覆盖期间发生的另一项变更。为什么要识别软件包？因为文件名或发布标签可能掩盖不同的实际文件。
批准P，并不等于批准“一切有助于改善目录的行为”。按照本模型，把上限设为九项、改动另一个登记簿，或额外替换角色，都属于不同提案。
哈希可以帮助绑定文件身份，但不能证明适当的主体已批准该文件、理解其效果或执行了它。这些结论各自需要证据。
3. 用动词描述权限
虚构系统设置七个变更控制角色（D、T、A、S、G、E和M），另有门户运营者U和V。这些是练习给定的规则，不是推荐用于生产系统的设计。
作者D可以提出P并解释意图。技术审查者T可以发表发现，并建议接受或拒绝。两者都不能仅靠发表文字改变C。
委员会A可以依照既定决策程序批准确切提案。凡案例写明“有效批准”，即假设该程序的条件已满足；本课不另行虚构投票公式。
排期者S可以把已批准的提案加入应用的变更队列。队列检查排期内容是否与批准的字段组合一致。成功排期后开始48小时等待期。
守护者G可以在操作执行前取消尚未完成的操作，包括等待期已结束、但仍未执行的操作。G不能修改已批准的数值，也不能借取消权限安装另一个数值。
执行者E可以触发符合条件的排队操作。执行时仍检查操作身份、时间、取消状态以及预期登记簿修订版。E不能自行选择其他数值。
角色管理主体M可以通过另一套已授权的角色变更程序替换E。已知规则没有赋予M直接修改C目录上限的权限。M的完整程序不在模型范围内；使用该程序的案例会明确给定其已经成功完成。
门户运营者U和V分别决定何时采用发布的显示软件包。显示层面的决定，不会赋予它们修改C参数的权限。
这七个变更控制角色的标签，不证明七家独立机构。某一机构可能同时控制多个角色。这里先识别权限；若要判断实际控制是否独立，还需要更多证据。
4. 审查与发布是有意义的中间结果
在第2小时，T报告拟议变更通过了所述测试。这支持其审查范围内的发现，却不等于委员会批准、成功排期或C已发生改变。
在第4小时，D发布R2。按照练习假设，这证明指定文件已经可用，却不证明U或V已经安装，也不会把C的上限设为六项。
在第8小时，A有效批准P。此时，关于确切变更已有获授权的决定。但在执行条件满足且状态转换发生之前，C仍是修订版7、上限四项。
这些区别并非多余手续。测试报告说明检查过什么行为；发布说明有什么文件；批准说明允许做什么；执行说明实际状态发生了什么变化。
EIP流程提供了一个真实例子，说明为何文档状态与实现工作应分别看待。EIP-1定义提案类型、审查阶段与职责，并说明核心变更如何与实现者协调。其状态标签属于特定标准流程，不能替代关于本课虚构C的证据。EIP-1
5. 等待期带来执行资格，不会自动完成操作
在第10小时，S成功排期已批准的P。虚构等待期恰好为48小时，因此最早符合时间条件的执行时刻是第58小时。
到了第57小时，只过去47小时。执行尝试会被模型的时间检查拒绝。C仍是修订版7、上限四项。
到了第58小时，等待期结束。如果尚未执行，C仍是修订版7、上限四项。操作已经就绪，但就绪不等于状态转换已发生。
现在假设E在第58小时执行P，所有检查通过，并且已提供被接受的执行后状态。C变为修订版8、上限六项。该操作被标记为完成，不能再次应用同一操作。
这里的小时是抽象练习时间，不是在规定真实区块链的时间戳策略。网络收录、费用、拥堵与失败恢复，均刻意排除在这个小模型之外。
OpenZeppelin固定版本的TimelockController实现，具体区分等待、就绪与完成，并分别检查排期、取消与执行权限。本例借用的是角色和操作状态需要区分这一一般教训，不是该合约及其角色配置的完整实现。OpenZeppelin Contracts v5.4.0
6. 继续追踪到用户实际看到的系统
第58小时成功变更后，U在第60小时采用R2，显示六项上限。练习没有提供V是否采用的观察。
能够支持的结论很具体：C的新参数已经生效，U被观察到的界面采用了相应软件包。不能因此声称所有门户都已更新。
如果V仍显示四项，这本身不能证明C回退。它可能只是显示过时。进一步调查应比较V的软件包、查询上下文与指定登记簿状态。
同样，如果U在第58小时前显示六项，也不会使六项提交在尚未改变的C上有效。用户界面的承诺，不能赋予应用规则尚未提供的许可。
因此，采用是工作流中的另一条路径。文件需要到达运营者，运营者需要选择或完成安装，然后还要观察实际行为。单凭发布公告，不能填补后续任何一项证据缺口。
本例不表示应用参数变更一定需要门户更新。这里明确给定这一依赖，是为了让读者分清登记簿生效与界面采用。
7. 在正确时点检验否决权
考虑一个独立变式：重新从第10小时已排期P的状态开始。第57小时，G成功取消P。第58小时，E不能执行已经取消的操作。C保持修订版7、上限四项。
G阻止了待执行变更，但没有设置新上限、删除旧目录条目，也没有获得委员会的批准权。
本模型中，再次尝试需要满足适用程序的有效批准，并重新成功排期，开始新的48小时等待期。不能直接沿用已取消操作之前积累的等待时间。
例如，一个满足条件的新尝试在第61小时排期，最早也要到第109小时才符合时间条件。这是模型明确给定的规则，不是所有治理系统通用的规则。
再考虑另一变式：P已经在第58小时成功执行，G在第59小时试图取消。模型没有赋予G撤销已完成操作的权限。要恢复四项上限，需要针对新状态另行进行获授权的变更。
所以，描述否决权时必须说明对象与时间。“G可以阻止升级”可能掩盖一个重要差别：阻止尚未执行的操作，与逆转已经完成的操作，并不是同一种能力。
8. 批准不会自动延伸到另一份变更内容
回到基准情形中已批准的P。假设E在第58小时提交把上限设为九项的请求。该请求与已批准、已排期的字段不一致，因此失败。等待期结束不能修复身份不匹配。
在第二个独立变式中，另一项已授权行为在P执行前，把C改到了修订版8。我们无需虚构那项行为设置了什么新上限。P要求当前修订版为7，前置条件已经不成立，所以P不能应用。
这个结论有明确边界：P没有通过预期状态检查。它不证明期间的变更是恶意的，不证明委员会最初的判断愚蠢，也不表示C应自动恢复。
工作流现在需要针对实际状态重新评估。要复用旧批准，必须有明确允许复用的规则；本模型没有提供。
因此，治理决定不能只看支持性的标题。身份与前置条件决定批准了什么；状态观察决定这项批准是否仍能按原意应用。
9. 谁能替换掌权的角色
假设E无法工作。新闻稿宣布F是“新执行者”，不足以让F的执行请求通过。实际角色状态仍然重要。
在一个独立变式中，M的另一套获授权程序在第55小时完成，撤销E并把执行角色授予F。按照给定规则，这次角色变更不会取消P，也不会重启P的等待期。
第58小时，E的尝试因不具备当前角色而失败。只要其余检查通过，F可以执行未改变的P。但F仍不能把六项改成九项、绕过取消状态或忽略预期修订版。
这区分了直接执行某行为的权限，与任命行为执行者的权限。M可以影响谁有能力执行符合条件的操作；即使没有直接编辑参数的权限，这种能力仍然重要。
但不能据此推断M能批准P、撤换G或改写48小时规则。那些都是需要另行证据的权限。
完整的真实权限图还应追问：谁能替换M？这个过程受什么控制？本模型到给定规则的边界就停止。把未明确的权限关系记录为未知，比直接假设它安全或无限制更诚实。
10. 建立别人能够核对的证据链
基准情形可以用一份简洁清单记录，每项结论对应一类证据：
- 提案：确切网络、C、修订版、上限与文件身份。
- 审查：T的报告、受测版本、范围与未解决发现。
- 批准：A的决策记录，以及程序条件已满足的证据。
- 排期：确切操作、成功排期时间与要求的等待期。
- 取消状态：执行时点对应的操作状态。
- 执行：当前执行权限、成功操作与C的结果状态。
- 采用：具体门户、文件与观察时间。
清单应标明证据的局限。写着“已批准”的截图，不如经过认证的决策记录；交易已经提交，不如已被接受的成功执行；关于U的观察，不是关于V的观察。
权限与问责也有区别。技术角色可能使某个行为可执行，但机构政策可能禁止在当前情况下使用该权限。本课分析模型能力与给定批准，不裁定法律权利或责任。
学习时可以追问：增加什么证据，才能改变结论？对于已经就绪但尚未执行的操作，缺少的不是又一份审查报告，而是执行及其结果状态的证据。
11. 练习与答案
练习一：过早的公告
第9小时，一则公告因为A已在第8小时批准P，就声称“六项规则已上线”。此时没有排期或执行。公告是否有证据支持？
没有。批准的决定存在，但C仍是修订版7、上限四项。公告把许可与实际效果混为一谈。
练习二：时间边界
P在第10小时排期。假设E有权限，P没有取消，其他检查也都通过，比较第57小时与第58小时的执行尝试。
第57小时没有满足等待期。第58小时通过时间条件。该时刻成功执行才会改变C；仅仅到达这个时刻不会改变C。
练习三：取消后重新尝试
G在执行前取消操作。一个满足条件的新尝试在第61小时排期。它能否在第100小时执行？
不能。只经过39小时。若其他条件继续满足，最早符合时间要求的时刻是第109小时。
练习四：新执行者
M完成的角色变更在第55小时把E替换为F。第58小时谁可以执行待处理的P？
F可以，但仍须满足其余检查。E不可以。更换执行者不会扩大P已批准的效果。
练习五：只有一个门户更新
C的成功变更已经得到证实。U运行R2，V的状态未知。是否已经证明所有门户采用了新版本？
没有。证据支持登记簿生效与U的采用，V需要单独证据。采用状态未知，也不证明V拒绝了变更。
练习六：对象改变
一份其他字段相同的请求，针对C2而不是C。P的批准是否涵盖它？
不涵盖。目标对象是获批准身份的一部分。新上限相同，不能替代操作身份一致。
12. 常见问题
治理一定意味着代币投票吗？
不是。流程可能涉及技术审查、机构批准、角色控制的执行或更广泛的协调。必须识别具体机制。
发布代码会改变运行中的网络吗？
发布说明指定文件可用。实际运行行为还取决于采用、激活以及相应状态转换。
等待期越长就一定越安全吗？
本课不能得出这个结论。等待期可以提供响应窗口，也会推迟必要变更。效果取决于监测、权限与具体行为。
否决权可以逆转历史吗？
只有系统另行赋予这种效果才可以。本例的G只能取消待执行操作，不能撤销已完成的变更。
成功执行能证明决定明智吗？
不能。它说明给定技术条件满足，且所述转换发生。变更的价值与后果需要另行评估。
13. 资料来源与延伸阅读
资料核对日期为2026年10月12日。目录、权限、小时数与案例均为原创虚构教学内容。
- EIP-1：状态为Living，创建于2015年10月27日；支持提案流程与实现协调的说明。
- 以太坊治理说明：页面更新于2026年6月6日；支持协议治理与应用治理的区分。
- OpenZeppelin TimelockController，Contracts v5.4.0：固定版本实现，用于说明角色检查与操作状态的区别。
有用的治理说明，应追踪到可观察的效果，并交代可核对的授权路径。尚未解决的环节也应保持可见，而不能把提案、投票或发布，直接写成所有参与者都已完成改变。