第23章　監査・是正・責任の追跡

第二十三章　审计、纠错与责任追溯

共同创造进入制度系统后，每一项权益结果都应能够回答三个问题：它根据什么事实形成，依据哪一版有效规则计算，由谁作出必要确认并承担后续履行责任。共享账本可以保存部分答案，却不能单独保证答案正确。事实可能被误报，计算可能采用错误版本，签名也可能出自无权操作的人。制度的可信度，取决于这些问题被发现后能否说明、纠正并落实责任。

上一章讨论了制度从提案、授权到执行和修订的过程。本章把视线移到执行结果：组织怎样追溯从业务证据到权益凭证的每一步，怎样在保留历史的同时处理错误，以及当合约或人员操作导致损害时，怎样划分责任、暂停风险并恢复正常治理。

审计并非事后给账本盖章。它从事前的证据设计开始，在运行中核对规则与操作，出现争议时重建事实，最后检验纠正是否真正到达受影响者。能够留下痕迹，是审计的条件；能够解释痕迹的意义，才是制度审计的任务。

一、从业务证据到权益结果的审计链

利益相关者资本治理中的审计对象，是一条从共同创造活动到权益安排的可追溯关系。承诺与任务规定参与边界，投入和交付形成业务事实，验证和复核决定哪些贡献得到确认，计量与资本判断决定它们能否进入后续安排，授权规则再决定是否生成具体权益，最后由履行记录说明请求获得了什么结果。任一环节缺少依据，终端凭证都不能替上游环节补证。

审计链首先需要有稳定的对象标识。任务、交付、证据、确认、评价、权益决定、支付请求与执行操作，应当能够彼此引用；同一任务有多项交付，同一项贡献影响多个结果，也要保留一对多或多对多的关系。若系统只展示参与者的最终分数，审查者就很难查明数字来自哪些事件，更无法区分重复记录与真实的共同贡献。

证据的来源、形成时间、保管者和证明范围，应在进入审计链时说明。一份签收记录可能证明某项材料已交付，未必证明质量合格；一项使用数据可能显示有人使用成果，未必证明使用的经济价值完全由单个贡献者创造。审计应检查证据被用来支持的具体判断，不能把“有证据”当作对全部结论的通用认可。

业务事实还需要独立于系统录入状态。记录被接受，说明它符合当时的输入和确认程序；如果原始资料错误、核验人失职或相关主体串谋，系统可能一致地接受错误结论。美国国家标准与技术研究院将区块链描述为具有篡改可见性与抗篡改性的共享账本，其说明针对记录的改变难度，并不能推导出链下输入天然真实。NIST：区块链技术概述〔1〕

因此，审计至少需要分别检查记录完整性、事实可靠性和制度适用性。完整性关注记录是否被替换、遗漏或重复；可靠性关注输入是否有独立来源和必要交叉核验；适用性关注采用的规则是否有效、确认者是否有权，以及计算范围是否正确。三类检查相互支持，但不能互相代替。

涉及贡献计量时，还应能重建计算。采用哪一版权重、哪个期间、哪些已确认事件，是否存在合格上限或时间调整，都需要可核对。最终分数相同的两个人，可能经历了完全不同的证据质量和裁量程序；审计不能仅以结果相同判定过程一致。

资本形成更需保留独立判断。贡献被确认，不代表它已成为跨期使用的资源或能力；被记录为资本来源，也不代表贡献者自动取得所有权。审查者应检查资源是否确被组织吸收、能否持续作用、相关风险由谁承担，以及任何权益是否另有授权依据。这些判断应分别留有责任主体与支持材料，避免用一张凭证覆盖全部经济和制度意义。

权益审计则从结果反向追问：谁是权利主体，谁承担相应义务，权益覆盖什么对象，何时成立，是否附带条件，以及转移或终止依照哪份安排。持有账户的控制者、实际受益者和代理操作人可能不同。若只审计通证余额，便无法判明一项收益请求是否已经成立或由谁实际兑现。

对于收益分配，审计还要连接资源来源、资格名单、计算规则、支付清单与真实支付。已发放单位、已登记应付、已提交转账和已完成履行，是不同状态。即使总额相符，也要核查个体层面的漏付、重复支付、错误地址与退回款项，才能判断制度承诺是否落到具体参与者身上。

审计链需要分层开放。受影响者应能核验自己的依据与结果，具有授权的审查者需要足以复核总体关系的材料，公众或其他协作方则可在适当范围内看到汇总和必要证明。不是把所有合同、身份与账户明细都放到公开链上，才能实现可核验。重要的是证明与原始材料能以受控方式对应，且有人负责保存和提供。

审计结果还应标出不确定性。资料暂缺、来源相互冲突、规则解释有争议和已经确认错误，是不同状态。审查者应说明已完成哪些核验、哪些范围未被覆盖，以及结论依赖什么条件。审计不能让一枚“通过”标记掩盖尚未核查的重要链下事实。

一条有效的审计链，允许审查者从一个权益结果向上查到其事实和授权，也允许从某项被推翻的证据向下找出受影响的全部计算与支付。前者解释制度为何作出结果，后者决定纠错能否完整展开。制度技术提供连接和留痕，审计则赋予连接以可复核的判断。

二、错误数据的标注、冲正与补偿

错误不只有一种。原始事实可能不准确，证据可能属于错误主体，评价可能重复计入，参数可能取错版本，账户可能映射失误，支付也可能转至错误路径。修正前应先确定错误位于哪一环节、影响哪些下游结果。若只改终端余额，上游仍保持错误，下次计算就可能再次产生同样的偏差。

发现疑似错误时，应先保全现有记录和相关证据，再标注其争议状态。标注不是立即认定参与者有过错，而是告知后续使用者该项资料需要核验。对于可能继续触发分配的记录，可以在有效权限内限制相关操作，并说明限制范围、起始时间和复核责任。无关权益不应因局部疑点被一并冻结。

确认错误需要受影响者有机会了解问题并提供材料。自报、他人举报、系统检测和独立审查都可能启动核验，但启动方式不能替代最终证明。若错误由组织自身录入或程序造成，也应如实记录，而不能默认由领取者承担全部证明与损失。调查中应区分事实争议、规则解释争议与已发生的执行差错。

链上记录难以按传统数据库方式无痕改写，纠错应保留原记录并添加有依据的更正联系。冲正适合表达某项先前计入结果在后续核算中被撤回或抵消，但需要同时指向原记录、原因、批准者与影响范围。保留历史不是持续展示一个明知错误的当前余额；当前有效结果应能清楚反映更正后的状态。

冲正也有层次。更正贡献事实与重算评价、调整资本记录、修改权益账户和追认支付结果，分别属于不同环节。上游事实改变后，应沿审计链检查下游是否确实依赖它；有些权益已经独立成立，未必随某次评价修正自动消灭。是否能够撤销或调整已成立请求，要看其有效依据、适用规则和必要的处理程序。

若错误涉及多个期间，应保留跨期影响。旧期间的记录可加更正说明，新期间的核算则纳入经确认的调整；任何回填处理都应让人分辨当时实际采用了什么结果、后来为何改变。不能把新规则伪装成旧规则，也不能用重算结果覆盖已经完成的支付事实。

已经执行的错误支付，需要分别处理多付、少付和未能交付。少付部分应确认责任和补付路径；多付部分若需追索或在未来抵扣，必须检查其权利依据、受领者状态和适用程序；支付指令虽已提交但未到达约定对象，也不应被视为已经足额履行。技术上可以增减余额，不等于经济结果已经恢复。

补偿更进一步，关注错误造成的实际影响。被延迟的款项、无法使用的服务机会、因错误停权而错过的治理参与，以及不当披露造成的损害，可能需要不同处理。组织应当先查明可恢复的原状态，再依据有效规则和具体事实判断是否需要额外补救；不能把一次补发通证当成所有损害的通用结案方式。

部分纠错可以自动化，例如识别重复编号或在确认新的输入后按同一版本重新计算。但涉及事实取舍、既有权利调整与责任争议时，仍需要有权主体给出理由。自动更正应能说明其触发依据、允许范围和影响对象，必要时提供暂停与申诉途径。

纠错之后还要检查再发生风险。同类错误是否来自身份核验薄弱、审查流程过于集中、参数含义不清，或系统没有处理退款和跨期变更的能力？如果根因仍在，只为当前受影响者补齐差额，制度仍会继续生产新的错误。复核应同时提出程序或技术修正，并说明何时检验其效果。

透明纠错不是让个人错误永久暴露于所有人面前。审计者可以保留必要证据及修订历史，参与者获得与自身相关的说明，对外披露则限定在监督所需范围。记录可追溯与个人信息适当保护，可以通过权限、摘要和受控查询共同实现。

三、合约缺陷、越权操作与责任划分

智能合约可以按照预设条件执行，但同一个错误结果可能来自不同原因。制度文本本身有缺陷，程序错误实现了正确规则，外部输入不真实，操作人超越了授权，或者有效操作与其他系统的记录未能衔接，都可能在链上表现为一个“成功”的状态变化。责任追溯应从原因与职责出发，不能仅看交易由哪个地址发起。

先要区分规则设计与技术实现。若有效规则要求两名独立审批者确认，而程序只检查一个签名，问题主要出在执行条件未准确实现；若程序忠实执行了经批准却明显遗漏受影响群体的规则，技术团队并不能单独解释整个制度选择。两类问题都可能需要及时止损，但责任审查的对象和修订程序不同。

程序缺陷还须进一步确认影响范围。代码中存在一条潜在错误路径，与该错误已经被触发并造成资源损失，不是一回事。审查者需要核对部署版本、可调用权限、触发输入、链上操作、实际资金或权益变化，以及同一逻辑在其他期间是否被使用。技术调查应保存可重现条件，不应靠“合约存在漏洞”的笼统结论代替损害核算。

越权操作关注行为人与授权的关系。某个账户在程序中拥有管理员角色，只能证明它在当时具有相应技术权限；该角色是如何授予、操作者是否受组织委托、此次行动是否落在委托范围内，仍需分别查证。OpenZeppelin 的访问控制文档说明了按角色授予、撤销和检查权限的机制，它有助于限制可执行动作，但不能自行证明每一次角色使用均符合组织制度。OpenZeppelin：访问控制与角色权限〔2〕

多方签署也需要实际核验。多个地址背后可能是同一控制者，签署者也可能在不明白内容时一起签名。因此应审查签署者身份与独立性、请求内容是否清楚、签署前能否看到所需证据，以及异常操作是谁发起和谁审核的。技术门槛可以减少单点风险，制度上的职责分离还需要组织条件支持。

链下输入责任则应落实到提供与确认事实的主体。数据提供者可能只保证资料来自指定系统，业务核验者则负责核查服务确已发生，审批者还需判断该事实是否满足权益条件。把这些职责合并成一个“预言机负责”标签，会使各方在错误发生后互相推卸。每个输入接口都应标明证明范围和负责核验的环节。

责任可以通过一张关系图重建：谁制定规则，谁开发与测试，谁批准部署，谁持有密钥并执行，谁提供事实数据，谁监督异常，谁负有对参与者的履行义务。不同主体可以兼任多个角色，但角色合并不能消除各项职责。相反，若一个人同时控制输入、批准与支付，更需要说明如何避免自我证明和自我监督。

责任分析应避免两种简单化：把全部后果归于“代码不会犯错”，或将一切技术故障自动归于开发者个人。实际义务可能来自合同、组织规则、职责安排及适用法律，需要结合具体事实确定。技术层面的缺陷定位有助于说明因果，但赔偿、补救和纪律处理仍须经过有权程序。

在调查中应保全程序版本、参数、相关交易、系统日志、审批材料、密钥权限变更与受影响者的通知记录。保全也要注意接触权限和资料完整性：调查人员不能为了取证而继续扩大风险，不能让被调查者单独控制唯一证据。必要的独立复核能够提高结论可信度，但其权限、范围和与当事者的关系同样应接受说明。

出现实际损害时，先行补救与最终责任认定可以分别推进。组织对参与者已承担的履行责任，不应仅因还未确定哪个承包方写错代码而长期悬置；各责任方之间如何分担费用，可以在证据完整后处理。若补救需要动用共同资源，则仍需说明授权、金额、受益对象与事后追偿安排。

责任还包含预防义务。设计者应说明可预见的失效情形，维护者应监测重要异常，具有暂停权限者应按既定触发条件行动，治理机构应及时处理持续出现的问题。并非每一次意外结果都意味着有人应被归责，但长期忽视已经可见的风险，会改变对其行为的评价。

因此，追溯的终点不只是找出一个“背锅者”，而是让受影响者获得事实解释和有效补救，让制度知道需要修改哪一层安排，并让有权主体对自己的决定承担可检查的后果。代码、密钥、账本和组织职责共同构成责任链，缺一环都可能使问责流于形式。

四、紧急暂停、恢复与治理接管

当错误正在扩大、资金持续流失或资格系统出现系统性误判时，组织需要能够及时阻止进一步损害。紧急暂停是为核验和补救争取时间的临时措施，不是对异常事实或最终责任的裁决，也不是持有暂停密钥者取得长期治理权的方式。

暂停前应界定触发条件与受影响范围。某个自动分配模块发生异常，不意味着所有查询、历史证据和无关业务都必须停止；一项外部数据源不可信，也不必然要求锁住全部已经独立成立的支付请求。暂停的颗粒度应与风险相称，同时考虑过窄的暂停是否会留下继续损害的路径。

第十一章已经说明，暂停模块只有被实际接入的功能才会受暂停状态约束。本章不再讨论实现方式，而把暂停视为事故处置权限：是否配置、覆盖哪些操作、由谁启动、怎样通知和恢复，都必须能够进入审计。

暂停权限可由特定职责主体掌握，并配以多人确认、事后批准或其他约束。紧急情况可能无法等待完整的常规表决，因此制度可以授予范围受限的先行处置权；同时应规定可核验的触发事实、即时记录、通知义务、最长持续时间和续期程序。不能让“紧急”成为没有结束日期的常态治理模式。

启动暂停时，应立即固定当时的状态：正在执行的任务、已提交但结果未明的交易、尚未支付的请求、相关钱包和密钥权限，以及链下服务是否继续运行。技术层面的暂停可能不覆盖外部系统，支付机构或业务部门也可能仍在处理旧指令。应建立跨系统核对责任，避免一边暂停、一边继续产生同类结果。

通知应说明已知事实、尚不确定之处、受影响的功能、可继续办理的事项，以及参与者如何提交证据或取得帮助。及时通知不等于提前宣告全部原因；为避免误导，可以公开事实状态和下一次更新时间。让参与者知道自己的请求是保留、延迟还是需要补充材料，比只显示“系统维护中”更有制度意义。

暂停期间的审查，既要查原因，也要查暂停本身的影响。停止某项转移可能保护资源，却也可能阻碍参与者履行已到期义务或退出某种关系。组织需要识别这些次生影响，必要时安排受控的替代履行或局部恢复，并说明为什么它不会重新打开原风险。

恢复不宜只依据“合约补丁已部署”。还要验证错误输入是否已清理，受影响记录如何纠正，资源是否足以履行原有请求，新版本是否经过授权和检验，操作权限是否重新配置，以及链下系统是否同步。恢复范围可以分阶段扩大，但每一步应说明检查通过了什么、仍由谁承担监测责任。

若原管理者失去操作能力、涉嫌严重越权，或长期不履行处置责任，治理接管才可能成为必要安排。接管应基于事先明确的权限或有效的有权决定，说明启动证据、移交对象、临时管理范围、监督者和退出条件。更换密钥控制者可以改变系统操作能力，却不能凭技术动作直接转移企业资产、合同地位或既有权利义务。

接管还需要双向核验：确认旧权限已经适当撤销或限制，也确认新责任主体确实有能力维护服务、保存证据和处理未了请求。若部分系统由合作方托管，应取得相应交接与确认。没有清楚的移交清单，接管可能在界面上完成，却让数据、资金和责任落在无人负责的缝隙里。

当严重分歧使正常治理机构无法有效决定时，接管程序尤其需要防止自己成为新的争议来源。临时权力应有明确目标和期限，只处理必要的安全与连续性事务；涉及永久改变权益结构的决定，应在恢复有效治理后按相应程序处理。接管者的行动、费用和与受影响者的关系，也应接受独立审查。

暂停与接管期间，原始历史和已有请求仍需保留。系统停止自动执行，不等于承诺消失；计算被暂停，也不意味着贡献事实被撤销。到期义务可能因故暂时无法履行，但状态、原因、负责主体和补救安排应持续可查。维持制度连续性，需要让参与者在困难时仍能知道自己的位置。

本书提出一个有待检验的方向：将事故处置设计为能够逐步证明的责任过程。发现异常、限定风险、保全证据、确定影响、作出更正、完成补偿和授权恢复，各阶段都留下可以复核的条件。评价这种制度，不看暂停开关有多快，而看实际损失能否被及时限制、受影响者能否获得说明和补救、恢复后同类错误是否减少。

审计、纠错与责任追溯共同揭示了制度技术的一条边界：技术能让许多动作留下可靠痕迹，却不能替组织免除辨认事实、解释规则和承担后果的责任。良好的制度让记录可以追问、错误可以纠正、权力可以监督，使共同创造者在系统出错时仍有途径维护自己的合法权益和继续合作的基础。

下一章将把视角扩展到跨组织协作与生态治理。共同事业可能连接多个企业和平台，贡献、结算与争议跨越不同制度边界；审计与责任链能否延伸到这些边界之外，将成为新的检验问题。

定稿补强：技术纠错、现实履行与法律救济分层

纠错应明确发生在哪一层。技术层可以追加更正记录、冲正账户或恢复权限；支付层需要追回、补付或重新结算；现实履行可能要求返还实物、停止使用、继续服务或恢复访问；法律救济还可能涉及确认、赔偿、临时措施和第三人关系。这些后果不能用一次链上冲正统一替代。

系统结案时，应列出哪些结果已经自动恢复，哪些需要责任人继续履行，哪些因第三人权利、不可逆交付或事实灭失无法恢复原状。每项未完成后果应有义务主体、期限、监督和申诉路径。技术历史保留与现实后果纠正可以同时成立，前者不应成为拒绝后者的理由。

本章注释

1. [SRC-078] 美国国家标准与技术研究院（NIST）：Blockchain Technology Overview（NIST IR 8202）。原文或官方页面

   • 本章引证：NIST：区块链技术概述。
   • 支持范围：用于说明公共机构对风险、身份、评估或技术能力的框架性要求，本书引用主题包括：NIST IR 8202：第7.3节、NIST IR 8202：第8.1节、NIST：区块链技术概述。
   • 使用边界：框架提供分析与控制依据，不替代组织对具体事实、成本和责任的独立判断。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

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

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