第二十二章 制度的制定、执行与修订
共同创造需要稳定的规则，也需要在事实、能力与协作关系变化时修订规则。区块链可以使一部分规则以程序形式执行，使参与者核验决定与状态变化；它无法自行决定一项规则应当由谁提出、经什么程序获得承认，或何时可以改变已经形成的承诺。制度技术要发挥作用，必须把规则从形成到退出的全过程连接起来。
上一章区分了账本验证权与企业治理权，并讨论了代表、表决与利益保护。本章沿着这些权力关系继续追问：提案如何成为适用的规则，参数改变怎样取得权限，自动执行与人工判断怎样配合，出现根本分歧时组织如何继续承担责任。技术确认的对象是某个版本下的有效操作；制度需要解释这个版本为什么有效，以及它对谁有效。
本书把制度规则理解为包含主体、行为、权利义务、程序与责任的安排。规则可以写在章程、协议、专项制度或业务流程中，其中适合形式化的部分可以进入软件与智能合约。文件、程序和现实行为必须相互指向，才能让共同创造者知道自己应遵守什么、可以请求什么，以及遇到错误时由谁处理。
一、提案、审议、授权与规则形成
规则形成首先要有明确的问题。提案不应只写“优化分配”或“提高效率”，还应说明现行安排在哪些事实下不足、拟改变哪些关系、受影响者是谁，以及如果维持原状会发生什么。只有目标与问题清楚，参与者才能比较不同方案，事后也才能检验修订是否实现了原来承诺的效果。
提出问题与起草条款可以由不同主体完成。实际承担工作、提供资源、使用服务或监督执行的人，可能最早发现制度漏洞；具有起草能力的人则负责将问题转换为清楚的权利义务和操作条件。制度应为前者保留提出问题的渠道，同时要求后者说明取舍，避免起草权悄然变成独占议程的权力。
一项完整提案至少应说明适用对象、拟改变的规则、现实与技术执行方式、生效安排、资源和成本影响，以及对原有承诺的处理。若涉及计算方法，还需提供可复核的口径；若涉及身份或数据，还应说明核验与访问边界。条款正文和解释材料可以分开，但不能让关键限制只留在参与者难以发现的技术说明里。
审议需要兼顾可比较性与充分性。不同参与者应尽可能基于同一份文本讨论；提出实质修改时，应展示变化及其后果。对资源、代表资格或收益条件具有不同影响的方案，不宜只给出一个笼统的“赞成或反对”。审议可以通过书面意见、专业复核与正式会议展开，但意见的收集、回应和未采纳理由都要留下可以检查的联系。
多方参与并不要求所有人对所有事项拥有相同表决权。有关主体至少应能了解对其关系有重大影响的调整，在既定范围内表达意见，并在需要时使用异议或复核渠道。审议程序的要求应与事项重要性相称：日常技术修补不必重复制定基本规则的全部程序；改变参与边界、分配依据或责任承担，则不能用日常维护的程序快速通过。
程序中还需要识别利益冲突。提案发起者、负责测算的人与直接受益者可以参与说明事实，但是否有权作最终审查或计票，仍需依据有效安排判断。披露并处理这些关系，有助于提高理由的可信度；若只记录投票数而不记录明显的利益影响，形式上的多数可能掩盖问题。
规则获得授权，至少需要回答四件事：作出决定的机构是否有权处理该事项，参与和计票是否符合既定程序，决定内容是否越过已有权利与适用制度的边界，以及有无还必须取得的同意或批准。某一环节通过，不能代替其余环节。组织希望采用一项规则，与该规则已经对特定主体发生效力，也可能相隔多个步骤。
尤其应注意修订权限本身的来源。现有规则可以规定自己的修订程序，但持有一般事务决策权的人，不能仅凭一次普通决定降低基本权利的保护门槛，再以新门槛处理同一议题。若保护条款需要改变，应依其当时有效的修订条件处理，并说明受影响主体的参与方式。这样才能避免通过先改程序、再改内容的顺序安排绕开原有约束。
规则形成可以用一条状态链描述：问题被提出，文本进入审议，有权主体作出决定，必要条件得到满足，规则在确定范围内生效，执行结果接受复核。各环节可能退回或终止，不应因为提案获得关注就把它展示为“已获批准”。账本可以保留文本摘要、决定记录与状态变化，但真实授权仍需要与身份、权限和程序证据核对。
以太坊的 EIP-1 将提案、审阅、最后征求意见和最终状态区分，并强调技术规范要说明动机、取舍及安全影响。它是协议改进提案的程序资料，可以启发本书对提案版本和审议记录的设计；企业中的制度效力仍应由其自身的授权关系和适用规则决定。EIP-1：提案目的与流程〔1〕
形成规则以后，应把规范性文本与解释、操作手册和程序代码建立对应关系。规范性文本说明应当怎样做，操作手册说明由谁按何步骤办理，代码执行其中可明确表达的条件。三者出现差异时，需要事先规定由谁发现、怎样暂停有风险的执行以及如何修正，不能简单让“运行中的代码”替代所有人的权利依据。
参与者还需要可达的规则入口。只公布一串摘要值或合约地址，无法使大多数人理解期限、资格和救济条件；只公布文字而不给出当前执行版本，也不能让人判断实际系统遵守什么。有效发布应指明完整文本、适用范围、生效时间、执行版本与负责解释的主体，重大变化还应有适当通知。
形成规则不是结束治理。组织应保存当初的目的、重要反对意见与预期影响，安排实施后的复核节点。如果某项新规则没有改善它要处理的问题，或者让新的负担集中于未充分参与的主体，后续修订就有了可讨论的证据，而不必把早期决定视作无法质疑的终局。
二、参数权限、版本管理与生效程序
制度中的可变内容并不具有相同性质。结算周期、信息通知期限、贡献评价权重、可分配资源口径、表决门槛和紧急暂停条件，可能都被写成系统参数，但它们改变的权利关系不同。参数是否容易在界面上修改，不应决定它需要哪一级授权；真正重要的是修改后谁的行动空间、权益或风险发生变化。
本书建议按作用范围区分参数。纯粹的显示或性能设置，可以在明确运维职责内调整；影响个别业务流程但不改变基本权利的设置，需要业务负责人与必要复核；涉及资格、计量、分配和决策权重的设置，应进入相应制度审议；改变基本原则或保护机制的事项，则需适用更严格的修订程序。这是分析框架，不是替任何组织预设具体机构和门槛。
每项参数应有可识别的名称、含义、单位、适用范围、允许的取值、责任主体及变更方法。孤立地记录“权重从二变成三”，不足以解释它是比例、评分系数还是表决权重，也无法说明影响哪些期间。参数登记应指向其上位规则，使执行人员和参与者可以知道某个数值究竟在实现哪项制度决定。
关键在于权力不能自我扩张。能调整分配比例的人，不应仅凭该权限改变“哪些主体有资格分配”；能延后执行时间的人，也不应因此获得取消已经成立请求的权力。对于新增参数、扩大取值范围或改变参数解释，应判断是否构成规则修订，而不是一概交由原参数管理员处理。
组织制度版本、计算规则版本与程序代码版本应分别编号并保持映射。一次代码修复可能不改变既定权利；一次制度修订也可能需要多个系统协同更新。版本关系应说明采用哪份制度文本、哪组参数、哪份执行程序以及哪个数据口径。若它们不同步，不能只用“最新版本”四个字掩盖差异。
| 版本或状态 | 主要回答的问题 | 应保留的连接 |
|---|---|---|
| 制度文本版本 | 哪一项权利义务和程序获得了授权 | 决定主体、适用对象、生效条件 |
| 参数集合版本 | 哪些可变规则取何数值 | 上位依据、变更权限、适用期间 |
| 程序执行版本 | 哪段系统逻辑实际处理操作 | 测试、部署、核验与回退记录 |
| 业务数据口径 | 哪批事实和资格进入计算 | 来源、截止时点、复核及更正记录 |
生效应当与批准、公布和部署分别记录。制度可能已经获批但仍待通知或约定条件；程序可能已部署，却尚未被授权用于正式分配；旧程序也可能在过渡期继续处理旧期间的请求。系统界面若只有“在线/离线”状态，就难以表达这些关系。需要明确哪个版本在何时、对哪些人和哪些事项开始适用。
时间规则应尤其注意跨期承诺。对新加入主体适用的新条件，与调整已经完成贡献、已经形成资格或已经成立的支付请求，属于不同效果。制度应说明旧规则下的事项如何结算，哪些环节进入新规则，必要时设置并行处理和过渡期限。不能通过回填生效日期，使新规则看起来从过去就一直存在。
版本并行需要确定一个归属规则。同一主体在一段过渡期内可能同时拥有旧期间形成的请求和新期间适用的资格，系统必须按请求来源和生效范围分别计算，而不能只根据当前账户显示的版本处理全部余额。对于尚未完成的任务，也需要说明采用开始时、完成时还是其他有依据的规则；其选择影响各方预期，应在改变发生前说清。
公开计划也未必等于已对每个主体成立的安排；但一旦组织已依据有效程序作出承诺，就需要判断修订是否触及该承诺。不能把“规则可以升级”解释为管理者永远有权单方重写一切。既有权利是否可变、由谁同意和如何补偿，应回到具体权利依据与适用法律制度。
有些变更可以通过延迟执行提供检视时间。OpenZeppelin 对 TimelockController 的说明表明，特定管理操作可以经过预设等待期再执行，并区分提案与执行角色。等待期提供发现问题和采取行动的机会，但是否适用、等待多久以及如何处理中止，仍是组织需要决定的制度问题。OpenZeppelin：延迟执行控制〔2〕
参数变更还需要检查执行前的条件。应验证有权决定是否已经完成、拟部署版本是否与审议文本一致、相关业务系统能否使用新口径、数据是否可以读取，以及重要的未了事项如何处理。代码通过技术测试，不能证明其业务结果符合授权；只通过一次投票，也不能证明代码准确实现了决定。
生效后需要持续对照实际运行。发布记录应让参与者查到当前版本和历史版本、变更理由、影响范围以及相关过渡安排；内部则要核对真实程序与已公布安排是否一致。发现配置错误时，纠正应保留原状态与处理依据，不能悄然覆盖历史。版本管理最终服务于权利可解释，而不仅是工程管理。
三、自动执行、人工审批与例外裁决
规则能够自动执行，通常意味着条件、输入、权限和结果已经形式化。资格在指定时点符合要求、金额按固定口径计算、审批签名齐备或某项资源在范围内转移，都可以设计为由系统直接处理。这样做能够减少重复核算和选择性执行，却只能覆盖规则已经准确表达的部分。
自动执行首先需要可靠的输入。业务事实、服务质量、损失归因和对现实资产的控制，不会因为进入共享账本就自然变真。系统可以核验输入来自被授权的主体、格式是否正确以及是否与已有记录冲突；事实判断仍需要证据、责任和可质疑的程序支撑。
本书将执行路径分为三类。第一类是条件清楚、风险可控的事项，由程序自动执行并保留结果；第二类需要人确认事实或授权，系统在取得有效审批后继续执行；第三类涉及例外和冲突，由有权主体作出理由明确的裁决，再让系统落实可执行的部分。这种分类取决于事项性质，而不是技术是否能够写出一个判断条件。
自动执行应受适用范围约束。分配程序能够为某类已确认资格计算份额，并不表示它可以处理没有证据支持的特殊贡献；支付程序能够按有效清单划转资源，也不表示它可以自行决定资源不足时的权利顺序。对未知情况，系统应清楚地返回“待核验”或“需裁决”，不能靠默认值制造已经通过审查的外观。
人工审批也不是任意决定的许可。审批人应有明示权限、必要资料和说明理由的责任。涉及多个职责时，需要区分事实确认、资源授权与支付操作，不能让一个人通过连续点击同时产生证据、批准方案和完成支出。多人签署可以降低单点控制风险，但只有在签署者确实履行不同职责时，才形成制度上的相互约束。
审批的证据应能够被追溯。何人以什么身份、依据哪份规则、核验了什么材料、批准了哪个范围和额度，决定了日后能否复查。系统可以核验签名和时间，却不能从签名本身推断审批人已经看过材料。对重大事项，制度可以要求材料摘要、审查结论与必要的独立复核相互对应。
在链下审批、链上执行的安排中，还需要避免批准对象与执行对象脱节。审批材料所指的收款主体、金额、资源用途或截止时间，应该与实际发起的操作建立可核验联系。若执行前相关事实发生实质变化，应回到原权限范围判断批准是否仍然适用，而不能把一份旧批准当作任何后续操作的通行凭证。
例外裁决处理的是一般规则无法充分覆盖的情形，例如身份被冒用、证据矛盾、服务中断、紧急风险或两项既有承诺冲突。例外程序的目的，是在特定事实下给出可以说明的处理，而不是让管理者绕开平常规则。启动条件、受理主体、可采取措施、期限和事后复核，应在例外发生之前确定基本边界。
例外记录至少应说明触发事实、受影响者、临时措施、裁决理由、所依据的权限和后续救济。需要迅速处置时，可以先采取范围受限的止损行动，再在限定时间内补充复核；若事后未获得有效确认，应明确怎样恢复和补偿。紧急措施可以暂时改变操作状态，但不能自行改写事实，也不应自动成为永久的新规则。
自动化与人工裁量之间需要一条可见的回路。人工确认产生可核验的输入，系统执行有范围的结果，异常再次返回有权程序。只有在这个回路里，参与者才能知道是算法计算了一个已定金额，还是有人判断某种事实成立。混淆两者，会使错误既难归于代码，也难归于作出判断的人。
| 执行情形 | 适合的处理方式 | 核验重点 |
|---|---|---|
| 明确且重复的条件 | 自动核验与执行 | 输入来源、规则版本、结果一致性 |
| 需要事实或资源确认 | 有权审批后执行 | 审批权限、证据范围、职责分离 |
| 出现冲突或特殊损害 | 例外裁决并记录 | 启动依据、比例适当、理由与复核 |
| 无法确定适用条件 | 暂停相关操作并补充事实 | 保全状态、通知、责任与处理期限 |
若例外不断重复，就说明一般规则可能已不适用。组织应分析例外的类型、成本和对不同主体的影响，再决定是否进入修订程序。不能通过一连串个别裁决，实际上建立一套没有公开审议的新规则；也不能为了减少例外数量，强迫不同事实进入同一个失真的自动判断。
参与者所见的界面，应如实显示事项所处的执行阶段。申请已提交、证据已确认、人工审批已通过、链上操作成功和现实履行完成，各自含义不同。能够看见责任主体和下一步处理，往往比只看一个“完成”标记更有助于建立可持续信任。
四、分歧、分叉与组织连续性的维护
制度会遇到分歧。参与者可能不同意目标、权重、资源配置或对旧承诺的解释；技术参与者也可能对协议升级和安全措施有不同判断。分歧不是账本核验失败的同义词。一个共同承认的历史记录，可以同时成为不同制度主张所引用的事实基础。
处理分歧应先判断争议对象。若是事实或计算错误，应通过证据和复核纠正；若是现行条款含义不清，应通过有权限的解释程序处理；若是未来制度方向不同，则应让各方依据既有提案和修订机制表达立场。将所有分歧都称为“技术问题”，会使真正需要协商的权利变化失去讨论空间。
对重要争议，应保留原问题、不同意见、所依据的证据和形成决定的理由。系统可以记录提交与回应，但若没有让持不同意见者得到公平表达的程序，公开记录也可能只放大已有权力差距。对仍能继续履行的无争议事项，组织应尽量维持处理，使局部分歧不至于使所有参与者的日常合作停摆。
分叉有多种含义。网络协议可能因各方采用不同规则而形成不同链；应用可以迁移到新合约或新账本；组织也可能因目标与权益安排分歧而分立。这些变化的对象、控制者和后果不同。技术上复制数据或启动另一套系统，不会自动复制现实资源、合同、品牌、人员义务或对外承诺。
以太坊的治理资料说明，当重大协议变化无法取得共同接受时，技术网络可能形成不同版本。这个事实帮助我们理解分叉作为一种技术与社会协调结果，但企业或多方组织的分立，还必须另行解决资产、权利与责任的归属。Ethereum：协议分歧与分叉〔3〕
因此，组织在迁移或分立前应建立事项清单：哪些资源由谁控制，哪些权益与支付请求已经形成，哪些服务仍须继续提供，哪些数据可以移转，以及各方怎样获知并选择。尤其要确认对尚未作出选择的参与者负有什么义务。一个新系统把历史余额复制过去，并不意味着原系统中的请求已经履行或消失。
历史事实也需要保持可核验。迁移时可以将旧记录的证据链和必要状态映射到新系统，但应说明映射原则、未完成事项与异常处理。复制两份记录可能用于连续审计，不能让同一项资源或义务在两个系统中被无依据地重复兑现。技术兼容与经济清偿，应分别核对。
维持组织连续性不等于要求所有主体永远采用同一个技术平台。关键是角色和责任能否在更换系统时延续：谁承担未付请求，谁有权确认新系统，谁能恢复必要服务，谁负责保存和开放历史证据。系统迁移应服务于这些已有关系，不能把技术停机解释为制度关系已经终止。
对于重大升级，本书主张事先准备有限的连续性安排。它应包括触发条件、临时负责者、可动用的资源范围、最长处理期限、通知方式、原有决定的延续性，以及事后审查和交还权限的办法。安排越容易在紧急状态下启动，越需要防止临时权力因缺少退出条件而固化。
连续性还取决于外部关系。支付服务、数据保管者、合作组织和实际资产管理者，可能并不会因为内部系统完成迁移就同步接受新安排。组织应核对通知、授权更新和服务交接的实际结果，并为暂不能迁移的事项保留可履行路径。由此可以看出，技术部署只是迁移中的一个环节，组织是否继续有效履约，需要在各类关系中分别确认。
共同规则失去广泛认可时，可以通过补充协商、限定范围的试行、独立评估或依有效程序作出修改，争取恢复合作基础。无法继续共同运行时，也应尽量有序处理分离和退出。维护连续性既包括让愿意继续合作的人可以协作，也包括让不愿继续的人能按适用安排结清关系，而不是被迫接受未获授权的新条件。
本书进一步提出一个有待检验的研究方向：将制度的提案、授权、生效、执行、异议、修订与退出构造成相互引用的公开责任链，让参与者不仅看到当前数值，还能追问“是谁、根据什么、对谁改变了什么”。这种安排是否改善治理，需要观察规则误用是否减少、变更是否更容易被理解、例外能否及时纠正以及弱势参与者的救济是否真正可用。记录更完整只是检验的起点。
制度技术的成熟，不表现为所有判断都被永久写死，也不表现为任何变化都可以由少数人即时推送。它表现为稳定承诺与必要修订之间有清楚的程序，执行能够服从有效授权，异常能够回到负责的人，分歧出现时组织仍能面对历史和现实义务。这样的制度才可能让共同创造在变化中保持合作。
下一章将继续讨论审计、纠错与责任追溯，具体检验从业务证据到权益结果的链条，以及当数据、代码或操作发生错误时，如何标注、修正、补偿并说明责任。
定稿补强：规则层级与紧急权力期限
制度规则应至少分为四层。基本规则保护主体资格、基本权利、代表结构和修订权限；政策规则决定资源与行为的一般安排；参数规则在授权范围内调整数值；操作指令处理日常执行。每一层分别规定提出者、审议门槛、冷静期、生效方式和复核渠道。参数权限不得被用于绕过基本规则。
紧急权力只能在明确证据和有限范围内启用。启动记录应写明事件、权限、受影响对象、替代方案和最长期限；到期自动失效，续期需要更高门槛。事后必须完成独立记录、治理追认、损失与补偿审查、恢复验证和临时权限撤销。紧急状态不能成为长期改变权利结构的便捷通道。
本章注释
[SRC-023] Ethereum Improvement Proposals：EIP-1：提案目的与流程。原文或官方页面
- 本章引证：EIP-1：提案目的与流程。
- 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：EIP-1：提案目的与流程。
- 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
- 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。
[SRC-018] OpenZeppelin：延迟执行控制。原文或官方页面
- 本章引证：OpenZeppelin：延迟执行控制。
- 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：OpenZeppelin：延迟执行控制。
- 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
- 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。
[SRC-044] Ethereum.org：协议治理与参与主体。原文或官方页面
- 本章引证：Ethereum：协议分歧与分叉。
- 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：以太坊治理说明、Ethereum：协议治理与参与主体、Ethereum：协议分歧与分叉。
- 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
- 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。