第11章　スマートコントラクト：制度上のルールをどう執行するか

第十一章　智能合约：制度规则如何被执行

共同账本为多方提供了可以核验的状态，但共同创造还需要行动。已经有效批准的资源怎样分配，满足条件的权益怎样取得，已经撤销的权限怎样停止使用，都要求制度从记录进入执行。智能合约为其中能够明确表达的一部分规则，提供了按程序处理的能力。

这里讨论的智能合约，是部署在相应执行环境中、按照调用和协议规则处理数据与状态的程序。以太坊开发文档将其描述为位于特定地址的代码与状态，使用者通过交易调用其中的功能。它能够执行被写入程序的条件，但“合约”这一技术名称并不直接证明其构成完整的法律合同，或已经取得约束有关主体的全部依据。Ethereum开发文档：智能合约简介〔1〕

智能合约的制度价值，在于使某些已经明确的承诺减少对临时操作意愿的依赖。要实现这种价值，需要把条款转化为准确条件，为执行提供必要资源，并为裁量、错误和变化保留有权处理的路径。本章沿着这一过程，讨论技术怎样执行制度，以及执行能力本身怎样受到制度约束。

一、从制度条款到条件、权限与状态转换

一项自然语言条款，通常同时包含目标、判断标准和行动要求。程序需要的表达则更加具体：哪些数据作为输入，什么条件成立时允许执行，由谁调用，以及执行后哪些状态发生变化。制度条款进入智能合约，需要完成这两种表达之间的转换。

转换首先需要确定采用对象。倡议、讨论稿和已经生效的规则，不能因为都可以写成程序就取得相同地位。开发者应当能够识别自己实现的是哪个版本，哪些事项已经获得批准，哪些仍待决定。否则，代码中的默认值就可能把尚未解决的制度问题提前固化。

接下来需要明确主体和权限。谁能够提交材料，谁能够确认事实，谁有权批准分配，谁只能执行已经批准的结果，应当分别表达。将这些角色映射为地址、凭据或其他技术权限，还需要保留它们与现实授权的对应关系。程序中的一个管理角色，不应被默认为可以处理全部制度事项。

条件表达需要说明事实怎样进入系统。“贡献得到确认”可能要求有权审核者签署，也可能要求多方核验或异议期间届满。程序能够检查的是这些已经表达的条件，不能自行填补“确认”的含义。若制度需要专业判断，就应当把专业判断的形成程序和结果输入方式一并说明。

数量和时间也需要明确。计算基数、计量单位、精度、取整方式、适用期间及边界时点，都可能改变实际结果。对零值、缺失信息、过期授权和分母为零等情形的处理，也属于规则表达的一部分。技术人员可以指出可能后果，涉及权益的实质选择仍需要有权决定。

状态转换随后表达执行前后有什么不同。提交材料可以使事项进入待审核状态；有效批准可以形成待履行安排；满足支付条件并完成相应转移，才可能更新履行状态。每次转换都需要明确前置条件，防止某个入口跳过必要阶段。

本书将这一转换概括为条款与执行条件的对应关系。

资源条件需要特别检查。合约拥有某项资产的操作权限，与它已经具备足够可用资源，并不相同；记入应付数额，与完成实际支付也不相同。没有可支配资源时，程序可以准确保存尚未履行的义务，却不能通过改变显示状态使义务变成已经履行。

在利益相关者资本治理中，贡献确认也不自动产生全部权益。程序应当分别表达贡献记录、评价结果、资本安排和具体权利。取得收益请求权、获得资源使用权和进入治理程序，可能具有不同条件，不能因为采用同一个积分或凭证，就把它们合并为一种无边界的资格。

执行规则还需要保持一些持续成立的约束。已经完成的同一笔支付不得被重复执行，未获授权的主体不得改变分配对象，已承诺资源与后续可用额度需要相容。这些约束需要覆盖所有相关入口，而不只是正常操作路径。一个被忽略的管理功能或例外入口，也可能改变相同状态。

业务层面的防重复尤其重要。同一请求可以通过不同交易多次到达，交易序号不同也不意味着对应不同义务。合约需要根据明确的业务标识和状态检查，识别某项履行是否已经发生。否则，账本可以正确处理每一笔交易，业务却仍然出现重复支付或重复授予。

条款与代码的对应应当接受审查。审核者需要检查正常条件、边界情况、权限失效和异常输入下的行为，并核对程序结果是否符合已经采用的制度。形式化验证可以对明确写出的规范提供更严格的检查，但证明程序符合规范，不等于证明规范已经完整表达制度意图。Ethereum开发文档：智能合约的形式化验证〔2〕

这一区别要求保留不同层次的验收。制度审查关注规则的依据和后果，技术审查关注实现与明确规范是否一致，部署核验则需要检查实际使用的程序、初始参数和管理权限是否对应已经批准的版本。草案通过讨论、程序通过测试和实际执行安排已经生效，应当分别记录。

代码最终承载的是被准确表达并实际部署的规则。转换过程越清楚，参与者越容易判断程序正在执行什么，也越容易在结果偏离预期时找到原因。智能合约由此成为制度的一种执行形式，而制度仍需为这种形式提供完整的含义与依据。

二、共识确认与合约执行的分工

共识确认和合约执行相互依赖，但承担的工作不同。合约执行根据既定状态、输入和程序计算结果；共识机制则帮助参与者形成可以共同采用的记录与顺序，并按相应规则确认结果。前者回答程序怎样处理一项请求，后者回答多方怎样共同采用相容的处理历史。

这是一种职责分工，不能简单理解为所有系统都先完成共识，再执行程序。在一些架构中，提议者先执行候选交易，其他参与者进一步核验，结果才进入共同确认；另一些架构会先模拟执行和收集背书，再排序并验证。具体阶段取决于系统设计。

Hyperledger Fabric的交易流程说明了后一种安排：交易先经过提议与执行背书，随后进入排序，提交时还需要检查背书策略及有关状态是否已经变化。某次模拟执行成功，不代表它最后一定形成有效的状态更新。Hyperledger Fabric文档：交易流程〔3〕

无论采用何种路径，共同执行都需要明确输入。相同程序若面对不同的前置状态、规则版本或外部数据，可能得到不同结果。系统需要把相关环境条件纳入可共同核验的范围，使验证者能够检查结果来源，而不是仅接受某个执行者声称已经算对。

共识不会纠正程序中已经存在的制度错误。如果程序把批准额度写错，多个节点可以重复得到同样的错误业务结果；如果程序的权限设置过宽，按权限实施的操作也可能通过协议检查。因此，共同确认能够支持结果的一致性，却不能替代对程序及其制度依据的审查。

执行结果也需要与调用结果区分。请求被接收、交易被纳入、调用成功和预期业务完成，并非同一状态。合约可以成功记录一项申请，而申请仍需审核；一个程序调用也可以返回失败状态，而交易本身仍然存在于账本。使用者需要知道成功对应的是哪一步。

在以太坊一类执行环境中，发生相应异常可以撤销当前调用及其子调用中的状态修改，但子调用错误也可能被上层程序捕获并按其他路径继续处理。因此，不能笼统地认为一次局部失败必然撤销整个业务过程。Solidity文档对异常传播、捕获和低层调用的差异作了明确说明。Solidity文档：异常与状态回退〔4〕

这也限定了原子执行的范围。被同一有效事务边界覆盖的一组操作，可以按照相应语义整体成立或撤销；多笔交易、跨网络消息以及现实中的交付，不会自动获得相同保障。程序需要准确处理已经完成的部分和仍待完成的部分，不能把一个局部成功扩张为全部义务完成。

外部动作尤其需要等待适当的确认条件。某个系统观察到合约事件后立即安排不可轻易撤回的履行，如果相关记录随后发生重组，就可能面临记录变化与现实后果不一致。应当在制度中说明后续行动依据何种确认程度，以及出现异常时由谁协调处理。

执行记录本身也需要准确解释。一个事件可以说明程序发出了相应记录，却未必足以证明目标资产实际到账，或链下服务已经交付。核验应当结合实际状态、必要回执和有关证据。记录设计需要让参与者能够追踪结果，而不是只提供一个容易被误解的成功通知。

程序可执行，还需要请求进入相应执行环境。对于通常由交易驱动的链上合约，日期到达不会使它在没有调用的情况下自行醒来。定时服务、使用者或其他程序需要触发相应请求；费用、网络和调用权限也需要可用。“自动”描述的是触发后按规则处理的能力，并不消除触发和持续运行的责任。

这一区别对长期承诺具有实质影响。组织可以把定期释放、到期结算等条件写入程序，但仍需安排谁监测条件、谁提交请求、失败后谁继续处理。将这些工作交给外部服务时，也需要说明服务中断后的替代路径。部署完成之后的运行维护，仍然属于履约基础。

因此，应当分别检验执行正确性、共同确认和履行可达性。执行正确性关注计算是否符合规定，共同确认关注多方是否采用相容结果，履行可达性则关注必要条件具备时，有关主体是否确实能够完成行动。程序永远拒绝越权操作，并不意味着它不会把所有正当请求一起锁住。

对于利益相关者资本治理，三者需要形成连续关系。有效制度提供应当执行什么的依据，程序把可计算部分转化为状态变化，共识机制支持对有关历史的共同采用，组织再使剩余资源和现实责任进入履行。技术分工明确，才能使自动化真正缩短承诺与兑现之间的距离。

三、自动履行、人工裁量与例外处置

自动履行适合那些条件可以清楚表达、输入能够可靠取得、结果能够由系统控制的事项。它可以减少重复操作和执行时的任意拖延，使参与者更容易预期满足条件之后会发生什么。其适用范围应当由这些条件决定，而不能仅以减少人工为目标不断扩大。

制度中也存在需要理解情境的判断。交付是否达到约定质量，某项贡献应当如何归因，延误是否具有可以接受的原因，以及多种利益发生冲突时如何处理，都可能需要专业审查和说明理由。把这些判断压缩为一个数值，可以便于计算，却不保证保留了原制度需要考虑的内容。

因此，可以将执行事项区分为三种关系：条件已经明确且证据具备时按程序处理；需要裁量时交由有权主体作出判断，再把结果输入执行程序；证据不足或争议尚未解决时，保留明确的待处理状态。这种分工使自动化与裁量分别承担适当工作。

人工裁量也需要受到制度约束。谁可以判断，判断哪些事项，需要取得什么材料，是否存在利益冲突，以及结论怎样接受复核，都应当事先说明。技术可以把这些程序条件作为后续执行的前提，防止一条未经适当形成的人工指令直接触发重大变更。

裁量权限需要与事实材料和具体事项对应。审核者对某项履行作出认可，不意味着其可以调整整个分配规则；复核者纠正一项事实，不意味着其可以自行免除其他主体的义务。人工处理越可能改变权益，越需要明确判断范围与理由。

处理结果进入系统时，应当能够关联决定主体、适用规则、证据范围和时间。必要时还应当说明有效期限及后续复核条件。敏感原始材料可以按适当权限保存，但系统应当让受影响者知道决定依据在哪里、通过什么路径提出异议。

例外处置需要区分规则内的例外与规则本身的修改。既有制度已经授权在特定条件下调整履行时间，属于按规则处理；事后增加新的分配依据或改变基本责任，则可能属于制度修订。不能把所有变更都命名为例外，以绕过更严格的决定程序。

暂缓状态可以为调查提供必要空间，但应当限定范围。某一事项发生争议，不应在没有依据的情况下阻断全部无关履行。制度可以研究把待核部分、已确认部分与尚未到期部分分别管理，并说明哪些动作继续、哪些动作等待。暂缓的目的，是防止在关键条件不明时扩大后果。

暂缓也需要有处理责任和复核时点。谁继续收集材料，谁在什么期间作出回应，超期后由谁接手，都影响参与者能否实际获得解决。规定复核期限不必意味着到期后不问原因一律自动放行；它可以触发进一步审查或替代程序，使等待不至于无人负责。

履行资源不足，需要准确表达为未完成或部分完成。系统不能因为可用余额耗尽，就默认相应义务已经消灭；也不能在没有有效依据时自行降低已经成立的请求数额。后续怎样补足资源、调整安排或处理责任，应当进入相应程序。

面对技术错误，程序中的失败状态也不等于业务责任已经终结。调用因网络、费用或程序条件失败，可能只意味着需要在核对后再次处理；如果已经完成部分外部动作，则需要先识别哪些后果仍然存在。重试前应当检查既有记录，避免恢复过程造成重复履行。

纠错可以通过新增的有效操作改变当前状态，并保留原有历史。错误付款后的返还、错误授予后的调整，以及遗漏义务的补充履行，都需要相应权限和资源。确认曾经发生过某个错误，与系统现在能否将其实际后果纠正，仍是两件不同的事。

人工裁量还可能被自动辅助工具支持。软件可以整理材料、发现不一致并提示规则适用问题，但如果某项判断涉及尚未形式化的标准，工具输出不能仅因被写入链上就取得最终决定效力。组织需要说明谁对采用结果负责，以及什么条件下必须进一步审查。

本书据此提出，把裁量的边界本身纳入可执行程序。程序可以检查必要批准是否齐备、判断者是否具备资格、决定是否超出额度及期限，并为异议保留入口；具体判断则由有权主体在这些边界内作出。这样，技术不仅执行确定答案，也支持形成答案的程序。

这一设计仍需接受实际检验。裁量入口可能减少僵化执行，也可能成为绕过规则的通道；自动条件可能提高处理一致性，也可能遗漏重要情境。评价应当关注判断是否更可解释、问题是否得到处理，以及受影响者能否有效使用相关程序。

自动履行、人工裁量和例外处置共同构成制度的执行能力。它们分别处理可计算条件、需要判断的事项和正常路径无法覆盖的情况。将三者衔接起来，才能使共同承诺既具有稳定性，也具备应对现实变化的能力。

四、合约升级、紧急暂停与制度修订

智能合约需要在长期运行中面对错误修复、业务变化和制度更新。参与者既希望既有承诺不被任意改变，也希望严重缺陷能够得到处理。升级与暂停机制因此需要在最初设计时进入权力安排，明确哪些内容可以改变、谁能够启动，以及怎样维护已经成立的关系。

合约升级不必表现为直接改写原有地址中的程序。常见方式包括部署新合约并迁移有关状态，或者通过代理结构，让使用者继续与原入口交互，而实际调用另一份执行逻辑。以太坊的升级文档对这些结构作了区分。地址保持不变，不代表实际执行规则从未变化。Ethereum开发文档：智能合约升级〔5〕

参数变化也可能产生制度上的实质影响。即使程序代码没有改变，调整计算比例、资格名单、到期时间或资源使用上限，也可能改变参与者处境。因此，技术上被称为配置的操作，仍需要按其实际后果判断应当经过何种授权。

升级权限具有较强控制力。能够改变执行逻辑的主体，可能有能力调整资产操作、角色限制和状态解释。日常功能具有严格权限，并不意味着升级入口也受到同等约束。需要一并检查代理管理、角色授予、参数修改和外部依赖替换等能够改变实际行为的路径。

制度修订则回答这些技术变化凭什么可以发生。修复实现偏差、调整既有授权范围内的参数、改变权益规则和迁移长期安排，可能需要不同程序。开发者判断某项修改是修复，并不足以自动证明它不影响权益；其判断需要有明确的旧规则、新行为和影响说明支持。

本书主张，重要变化应当分别识别以下权限。

紧急暂停的技术能力应当准确表达。OpenZeppelin的暂停模块要求把相应检查实际接入需要控制的功能；仅引入模块，并不会使所有功能自动受到暂停限制。暂停能阻止什么，取决于具体执行路径，而非界面上是否存在一个暂停按钮。OpenZeppelin文档：Pausable〔6〕

暂停通常也不会撤销已经完成的交易，更不会自动冻结其他系统中的全部行动。在链上执行的暂停请求，本身仍需被网络处理，不能保证一定先于其他竞争请求生效。组织需要根据实际覆盖范围制定处置安排，避免把暂停能力当作可以消除任何后果的保证。

暂停权与恢复权可以分别设置。发现风险时迅速限制特定操作，和确认处理充分后恢复运行，需要的信息与判断可能不同。但权限分开之后，也需要避免无人能够完成恢复，或者任何一方可以无限期阻断处理。运行责任、替代路径和复核安排应当同时明确。

暂停的范围尤其需要与风险对应。可以研究限制新增承诺、限制某类资产操作或只暂缓争议部分，而保留必要查询和申诉渠道。是否继续允许领取、撤回或其他动作，应当结合漏洞与义务关系判断，不能预设所有情况下全面冻结或全面开放都适当。

对常规升级，延迟执行可以提供检查变化的时间。OpenZeppelin的时间锁安排，将已排定的操作置于最低等待期间之后执行，为使用者审查提供机会。但时间经过不会自动使修改取得正当性；参与者是否能够理解变化、提出异议或实际退出，还取决于具体制度与资源条件。OpenZeppelin文档：延迟操作与时间锁〔7〕

延迟机制还需要覆盖真正能够改变结果的权限。如果管理者可以通过另一入口直接升级、替换管理者或绕过延迟，表面等待期就可能失去预期作用。相反，所有关键角色都失去操作能力时，严格的权限结构也可能阻断必要维护。因此，共同控制应当同时考虑防止滥用与持续履职。

新旧版本之间最重要的是状态和责任的衔接。已经取得的权益、尚未完成的义务、正在处理的申报以及已提出的异议，需要分别确定适用规则。不能仅因新算法上线，就默认旧规则下已经形成的全部关系失效；也不能让新旧系统同时把同一项未结义务重复当作可履行余额。

状态迁移需要核对主体对应、数量、单位、状态含义和处理位置。旧系统何时停止有关操作，新系统从哪个依据继续，迁移失败时如何处理，都应当明确。即使采用保持原状态的代理升级，也需要检查新逻辑是否按同样含义读取已有数据，避免记录仍在而解释发生无意变化。

验证需要围绕这些实质后果展开。权限变化是否符合批准，既有权益是否按安排延续，边界情况下是否发生重复处理或永久阻断，以及实际部署是否对应审查版本，都是重要检查对象。一次技术测试通过，不能替代制度批准；一项制度批准，也不能证明实际部署没有偏差。

升级完成后的结果还需要可以追踪。参与者应当能够识别当前规则和程序版本、变更依据、生效位置及尚待处理事项。界面更新、部署完成和迁移核对结束属于不同进展，准确表达这些状态，有助于继续核验共同承诺。

智能合约的长期可靠性，由执行规则和约束执行权力的规则共同支持。它可以使确定条件下的行动更加稳定，也需要让裁量、暂停和修订始终具有清楚依据。下一章将转向现实连接，进一步讨论事实、证据和履行结果怎样进入链上制度，使程序所处理的状态能够与共同创造的实际过程衔接。

定稿补强：升级不变量与应急权限

规则经过有效治理程序批准，并不保证技术升级一定正确。合约升级至少要保持六类不变量：权利和义务的语义不被无意改变，接口对既有调用保持明确兼容，存储布局与状态迁移可验证，权限不会在迁移中扩大，账实余额能够前后勾稽，历史证据和版本关系可以追溯。任何不能保持的不变量都应在提案中列为显式变更，而不能隐藏在部署细节里。

升级流程应包含代码或配置审查、测试、迁移演练、时间锁、受影响主体通知、部署人和批准人分离、迁移前后快照、失败停止条件和撤权证明。所谓回滚也要说明边界：程序版本可以恢复，已经发生的外部付款、现实交付或第三人权利未必能够自动回到原状。

紧急暂停是限制损失的工具，不是无限期治理授权。其触发证据、作用范围、最长时间、续期门槛、事后追认、补偿和恢复后的权限撤销，应与升级规则一起公开。

本章注释

1. [SRC-038] Ethereum.org：Ethereum开发文档：智能合约简介。原文或官方页面

   • 本章引证：Ethereum开发文档：智能合约简介。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：以太坊智能合约文档、Ethereum开发文档：智能合约简介。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

2. [SRC-039] Ethereum.org：Ethereum开发文档：智能合约的形式化验证。原文或官方页面

   • 本章引证：Ethereum开发文档：智能合约的形式化验证。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Ethereum开发文档：智能合约的形式化验证。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

3. [SRC-050] Hyperledger Fabric：Hyperledger Fabric文档：交易流程。原文或官方页面

   • 本章引证：Hyperledger Fabric文档：交易流程。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Hyperledger Fabric文档：交易流程。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

4. [SRC-021] Solidity Documentation：Solidity文档：异常与状态回退。原文或官方页面

   • 本章引证：Solidity文档：异常与状态回退。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：Solidity文档：异常与状态回退。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。

5. [SRC-040] Ethereum.org：Ethereum开发文档：智能合约升级。原文或官方页面

   • 本章引证：Ethereum开发文档：智能合约升级。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Ethereum开发文档：智能合约升级。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

6. [SRC-019] OpenZeppelin：OpenZeppelin文档：Pausable。原文或官方页面

   • 本章引证：OpenZeppelin文档：Pausable。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：OpenZeppelin文档：Pausable。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。

7. [SRC-016] OpenZeppelin：OpenZeppelin文档：延迟操作与时间锁。原文或官方页面

   • 本章引证：OpenZeppelin文档：延迟操作与时间锁。
   • 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：OpenZeppelin文档：延迟操作与时间锁、OpenZeppelin：访问控制与角色权限、OpenZeppelin：角色与访问控制。
   • 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
   • 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。