第6章　制度技術の適用条件と選択の限界

第六章　制度技术的适用条件与选择边界

将区块链理解为制度技术，需要进一步回答一个选择问题：什么样的制度安排值得由区块链承载？前五章已经讨论共同状态、数字控制、资本形成和规则来源，但这些讨论不能直接推出所有共同创造都应当上链。制度目标相同，技术路径仍可能不同；采用相同技术，也可能形成差异很大的权力结构。

利益相关者资本治理关注的是共同创造怎样获得持续的组织条件，贡献怎样经过确认进入适当的权益安排，以及长期投入怎样得到维护。技术的价值，应当放在这些关系中判断。如果一项系统增加了记录数量，却没有改善确认、履行与监督，新增记录未必形成治理上的进步。如果它降低了记账成本，却使参与者更难提出异议，也需要重新评价这种效率。

因此，制度技术的选择需要同时辨认三件事：共同事业需要解决什么协作困难，候选技术究竟能改变其中哪些条件，以及改变之后由谁承担成本、获得权限和承受风险。本章据此建立区块链的适用边界，并为后续讨论密码学、分布式账本和共识机制确定评价尺度。

一、多方协作何时需要共享账本

多方协作通常需要交换信息，但交换信息的需要与共享账本的需要有所区别。参与者阅读同一份说明、相互传递材料，主要解决信息到达和理解问题。共享账本则进一步要求，各方能够依据一组共同承认的记录，判断哪些事项已经发生、哪些承诺仍然有效，以及接下来允许实施什么行动。

这里的“共享”，首先指记录具有跨主体的共同用途，并不必然要求所有信息公开，也不要求每个参与者保存全部数据。“账本”也不限于金额的增减。它可以记录资源承诺、授权变更、履行确认和权益状态，但不同记录的意义应当分别定义，不能因为被放入同一个系统就取得相同效力。

共享账本需求首先来自状态之间的相互依赖。当一个主体的行动会改变另一个主体能够采取的行动，各方就需要知道正在依据哪个状态协作。某项资源是否已经被承诺，某项权限是否仍在有效期内，同一事项是否已经完成结算，都可能影响后续行动。若各方分别保存的记录长期不一致，合作就需要反复核对，甚至会在相互冲突的前提下继续执行。

这种依赖在涉及排他性状态时尤其突出。一项有限资源不能在同一适用范围内被当作两份可用资源，一项已经撤销的权限不能继续被视为有效权限。此时，系统需要共同处理互斥关系与先后顺序。单纯交换签署过的文件，可以证明各方分别表达过什么，却未必足以使所有参与者及时知道当前应当采用哪一种状态。

不过，并非所有记录都需要进入同一条全局顺序。互不影响的贡献材料可以分别收集，部分统计结果可以稍后汇总。只有当记录之间存在冲突、依赖或共同执行要求时，才需要确定相应范围内的顺序与确认规则。把原本可以独立处理的事项全部交给同一个确认过程，会扩大协调负担。

第二个条件是共同记录需要具有可核验性。不同主体可能愿意接受某个运营者负责日常服务，但希望能够独立检查重要记录，确认自己提交的材料是否被纳入，决定所用的版本是否正确，以及已有记录是否被悄然替换。共享账本在这里回应的是持续核验的需要，而不仅是集中查询的便利。

第三个条件涉及单方控制是否可以被接受。一个组织拥有统一的责任体系、适当的内部控制和可行的审计安排时，由该组织管理数据库可能已经足够。如果参与者不愿让任何一方独自决定共同状态，或者共同事业需要在某个运营者退出后继续保留可核验记录，就有必要研究更分散的控制安排。

不接受单方控制，仍然需要说明具体担忧。担心记录被事后修改，与担心有效请求被拒绝，所需机制不同；担心运营者失去服务能力，与担心多个运营者合谋，也不能采用完全相同的保障。技术选择应当明确准备承受哪些故障、限制哪些行为，以及在什么条件下保障可能失效。笼统的“不信任”不足以形成可执行的系统要求。

区块链更值得考虑的情形，是共同状态对多方具有持续影响，各方需要独立验证，且不愿将状态确认权完全交给单一主体，同时能够在明确的参与和故障假设下共同维护确认过程。这些条件形成采用区块链的理由，但尚未证明它优于其他方案。是否采用，还需要比较替代机制和长期成本。

共同维护也需要实际承担者。谁运行必要的设施，谁能够检查规则，谁负责软件更新，出现争议时谁组织处理，都需要有明确安排。如果全部节点、更新权限和服务入口始终由同一方实际控制，增加节点数量可能改善故障恢复，却不一定减少对该方的制度依赖。

多方之间还需要具有最低限度的共同规则。参与者可以对利益分配持有不同意见，但必须能够识别当前有效的规则、验证所依据的材料和决定程序。若各方尚未就“记录代表什么”形成可用约定，系统最多帮助保存不同主张，不能凭借共同记账把相互冲突的主张变成已经解决的关系。

在利益相关者资本治理中，这一点表现为贡献记录与权益状态之间的距离。共同保存一项贡献的申报，能够减少申报材料散失或被单方遗漏的风险；该贡献是否成立、是否已经获得报酬、是否满足进一步权益的取得条件，仍需要相应制度。共享账本应当准确表达这些阶段，而不应使“已提交”被读取为“已确权”。

本书据此提出“最小必要共同状态”的设计原则：只将确实需要跨主体共同确认、持续核验或约束后续行动的状态纳入共同维护。原始材料、专业判断过程和内部工作信息，可以依据各自用途保留在适当的系统中，并通过明确标识和证据关系与共同状态衔接。这是一项制度设计主张，其效果需要通过实际运行检验。

这个原则为共享划定了范围。决定共同维护什么，也是在决定哪些事项进入共同约束、哪些事项保留主体自主。范围过窄，关键承诺可能无法核验；范围过宽，参与者可能被迫暴露不必要的信息，并为无关事项承担确认成本。共享账本的边界，因而也是合作边界的一部分。

二、区块链、数据库与签名日志的比较

比较三种技术，首先需要避免把它们当作完全互斥的类别。数据库是存储、查询与管理数据的系统，可以集中部署，也可以分布式运行；签名日志是在记录及其验证方式上作出的安排，可以建立在数据库之上；区块链也需要存储系统，并通常结合签名、哈希和分布式协调机制。真正需要比较的是具体架构中的信任条件与控制方式。

数据库的优势在于成熟的数据管理能力。它能够支持权限控制、关联查询、并发处理以及一组操作的整体提交。在正确设计和运行的前提下，数据库完全能够维护资产账户，检查余额并约束重复支出。PostgreSQL的事务文档说明，一组操作可以作为整体成功或失败，未完成的中间状态不会作为已完成结果对其他事务呈现。这表明，受约束的状态转换并非区块链独有。PostgreSQL：事务〔1〕

数据库架构的制度问题主要在于，谁掌握管理权限，以及其他参与者怎样监督这些权限。备份、权限分离、操作审计和外部核对，可以显著改善其可靠性与可追责性。评价数据库时，应当把这些现实可行的措施纳入基准，不能用一个缺少所有控制的数据库，与一个假定治理完善的区块链作比较。

签名日志进一步把记录与签名密钥联系起来，使核验者能够检查所签内容是否变化，以及签名是否与相应公钥匹配。若签署者身份和权限另有可靠依据，签名还能支持对责任主体的识别。日志可以为提交、批准、撤回和更新保留相互关联的证据，让记录接收者不必完全依赖提供查询界面的一方。

但对每条记录签名，不等于证明记录完整。日志管理者仍可能不收录某项提交、隐瞒部分记录，或者向不同接收者提供不同版本。哈希关联、只追加结构和外部保存的检查点，可以帮助发现某些修改；要发现不同接收者看到的记录相互矛盾，还需要适当的交叉核对或见证安排。每增加一种保障，都应当说明新增机制及其依赖。

RFC 9162描述的证书透明度协议，使用可审计日志以及包含性和一致性证明，支持检查某条记录是否进入日志、后续日志是否延续已有记录。该文档同时指出，日志向不同客户端提供不一致视图的问题，不能仅由其中的日志审计机制消除。这个技术参照说明，可核验日志具有独立价值，但其保障范围需要准确表达。RFC 9162：证书透明度协议，第1节〔2〕

签名日志更直接地回答“某方留下了什么可验证的记录”。区块链则可以进一步支持多个维护者，依据共同验证规则，对互相竞争的状态变更形成可采用的顺序。这样，各方在规定条件下能够核验共同状态，而不只是在争议发生后比较各自持有的凭据。对于必须共同约束后续行动的资产状态，这种能力可能具有重要价值。

这种区别仍然具有条件。数据库可以使用分布式共识，签名日志也可以增加多方共同确认；区块链的关键控制权也可能集中于少数主体。名称本身不能证明独立性、安全性或治理质量。应当检查哪些参与者能够提出更新，谁能够拒绝更新，确认需要哪些条件，以及实际控制者是否具有足够独立性。

下表比较的是常见安排中的主要侧重点，具体系统仍需要单独核验。

如果主要困难是管理者的记录缺乏可核验性，数据库结合签名、独立留存和定期审计，可能已经足以改善问题。如果主要困难是多个独立主体需要共同维护互斥状态，并限制任何一方单独改变确认结果，区块链才具有更明确的比较理由。若事实认定和分配规则本身尚未明确，三种技术都需要等待相应制度工作。

技术组合往往比单项替代更符合实际需求。高频操作和敏感原始材料可以在适当的数据库中管理；重要承诺和批准过程可以形成签名记录；确需跨主体共同确认的状态，可以进入共同账本。组合设计同时产生新的责任：系统之间的标识、版本和状态需要对应，不能在一个系统已经撤回后，另一个系统仍继续按旧状态执行。

比较时还需要追踪保障在哪里结束。把一份内部记录的摘要写入区块链，可以帮助核验后来取得的材料是否与摘要匹配，却不会使未公开的原始材料自动可得，也不会让内部系统的全部过程获得共同验证。所声称的保障，应当限于实际被证明的对象。

技术选择由此成为一项具体的制度判断：在哪些环节接受委托管理，在哪些环节要求独立留证，又在哪些环节需要共同限制状态变更。对这些环节作出清楚安排，比为整个组织选定一个统一的技术标签更有意义。

三、记录一致、事实真实与制度正当的区别

共享账本容易带来一种认识上的跳跃：既然许多参与者已经确认同一份记录，这份记录所描述的事情就应当真实，记录所依据的制度也应当合理。然而，记录一致、事实真实与制度正当分别回答不同问题。它们可以相互支持，却需要各自的判断依据。

记录一致关注的是，在特定规则、网络条件和确认阶段下，参与者是否采用相容的记录与状态。对尚未确认的请求，各方可能暂时具有不同认识；对已经达到相应确认条件的结果，则需要具备协议所承诺的稳定性。因而，一致性判断应当说明对象、范围和确认条件，不能将某个节点此刻显示的内容直接当作所有主体已经共同确认的事实。

这里的一致还应当区分形式相同与理解相同。各方保存相同字段，不代表对字段具有相同解释。“贡献已确认”究竟表示材料收讫、行为核实，还是权益取得条件已经满足，需要由明确的数据含义和制度规则说明。共同账本只有与共同可理解的语义衔接，才能成为协作依据。

事实真实关注记录与其所指对象的关系。对于完全由协议定义的链上状态，核验者可以依据可得数据和有效规则检查某项状态是否成立。对于现实中的交付、劳动、质量、身份和实际控制关系，则需要相应的外部证据。协议可以核验某个有权限的地址提交了确认，却不能仅凭这次提交判断它所描述的现实情况是否准确。

NIST的区块链技术概述把这一困难列为超出数字系统边界的问题：现实数据进入链上时，人或设备都可能提供错误信息，而区块链自身未必能够判断输入是否反映实际事件。这里的限制涉及外部信息进入数字系统的过程，并非通过增加记录副本就能消除。NIST IR 8202：第7.3节〔3〕

事实核验需要追溯信息的形成过程。谁观察或完成了有关事项，材料是否能够相互印证，确认者是否具有必要能力，是否存在影响判断的利益关系，以及反对材料怎样被处理，都决定一项记录值得获得何种程度的信赖。多个签名如果只是重复同一来源的错误信息，并没有形成同等数量的独立证据。

还应当区分事实与评价。某项投入是否发生，可以通过材料核实；它对长期共同成果贡献了多少，则可能涉及归因方法和反事实判断。后者即使经过多人讨论，也不一定具有唯一、精确的答案。制度可以形成可采用的评价结果，但应当保留评价口径、适用范围和复核条件，使共同采用不被误认为已经消除认识上的不确定性。

制度正当关注规则和决定凭什么要求相关主体接受。制定者是否具有相应权限，受影响利益是否得到适当考虑，程序是否提供必要参与和异议条件，权利与义务是否具有可以说明的理由，都属于这一层面的判断。签名齐全、计票准确和执行一致，可以支持程序核验，却不能单独回答规则本身应当如何评价。

这种正当性也不能完全压缩为一次赞成比例。表决资格可能排除了重要的受影响者，信息披露可能不足，代表可能超越委托范围，某些责任也可能不能由内部多数决定免除。判断需要回到权力来源、事项性质和适用边界。技术能够保存这些过程，但不能因为保存得完整，就替代对过程的实质审查。

三个层次可以分别发生错误。一组记录可以高度一致，却共同保存了不准确的事实；有关事实可以得到充分证实，却被用于缺少适当依据的分配安排；一项制度可以具有充分理由，但其执行记录仍可能遗漏、冲突或被错误计算。因此，不能用某一层的成功为另外两层作无条件担保。

这一区分直接影响资本治理。贡献申报进入账本，首先说明某项申报被记录；经有权程序核实，才可能形成可采用的贡献认定；是否进一步构成权益依据，还取决于具体规则和其他必要条件。即便权益凭证已经生成，也仍需检查其表达的是什么权利、对应谁的义务，以及履行基础是否存在。

同样，长期能力不能由记录的累积数量直接证明。持续形成的专业能力、合作可靠性和资源使用能力，需要从组织实际运行中评价。账本能够保存有关形成过程的证据，但记录存续与资本存续可能不同步。维护活动停止、关键关系瓦解或资源失去用途时，历史记录仍然完整，相关资本的现实条件却可能已经变化。

系统表达应当帮助使用者保持这些区别。本书主张，对重要事项分别展示记录状态、事实核验状态和决定效力状态，并关联适用规则、责任主体和未完成条件。一个笼统的“已完成”标签，容易使申报、确认、批准和履行混为一谈。较准确的状态表达，可以减少技术界面本身制造的制度误解。

纠错机制也需要按层次安排。事实发生更正时，应当说明原判断为什么改变，并依有效程序调整由它支持的后续状态；规则需要修订时，应当说明新旧安排怎样衔接；账本发生技术冲突时，则先按照相应协议识别可以继续采用的状态。不同处理可以相互触发，但每一步都应当保留自己的权限和证据。

共同账本因而可以成为一种有边界的公共依据：它让已表达、已确认和已执行的事项更容易被共同检查，同时为事实调查和制度审查保留入口。这样的边界有助于建立可纠正的信赖，使参与者既能够依据记录行动，也能够在有理由时挑战记录及其制度后果。

四、成本、效率、隐私与权力结构的权衡

制度技术的选择最终需要进入资源与权力的现实条件。技术具备某种能力，尚不意味着组织能够以可承担的代价长期获得这种能力。评价应当覆盖建设、运行、参与、纠错和退出，使最初的部署决定与后续责任相互对应。

成本首先包括设施、软件、安全维护和人员投入。分布式维护可能增加数据复制、通信和共同验证的工作，但具体负担取决于架构。不能把所有区块链的资源消耗等同于某一种共识机制，也不能将没有向使用者单独收费理解为没有成本。费用可能由组织预算、维护者投入或其他安排承担。

制度运行还包含核验事实、更新规则、处理异议和协调不同主体的成本。技术可以减少部分重复核对，却可能增加密钥管理、权限变更和跨系统状态衔接的工作。若只计算写入一条记录的费用，就容易遗漏维持这条记录能够被正确理解和有效使用所需的投入。

对长期共同创造而言，还应当观察成本由谁承担。组织减少的管理支出，可能转化为参与者的操作时间；自动执行节省的处理工作，可能伴随较高的错误纠正负担；维护要求可能使资源较少的主体逐步依赖大型服务商。成本评价需要同时说明总量和分布，否则总体节约也可能伴随参与条件恶化。

效率则需要明确终点。请求提交、进入记录、达到确认条件、形成有效决定和完成实际履行，属于不同阶段。每秒处理多少条请求，只能描述其中一部分。资本治理更需要知道，一项承诺从提出到获得可靠履行需要多久，重复核对是否减少，异常事项是否能够及时恢复，以及参与者是否因此获得更稳定的预期。

共享账本即使增加了单次确认的等待，也可能减少跨主体核对和争议处理的总时间；一个响应很快的系统，也可能把大量不确定性留给后续人工处理。这些都是需要验证的可能性。评价应当沿着完整流程测量，并把正常运行与故障、拥堵、异议出现时的表现分别观察。

隐私的权衡从信息用途开始。共同验证一项资格，不一定需要公开形成资格的全部材料；确认一项承诺，也不一定需要让所有维护者获得全部商业细节。制度设计应当先确定谁为了什么目的需要知道什么，再选择记录内容、披露范围和验证方式。

公开可验证与对所有人公开原始内容，是不同要求。系统可以研究分层访问、选择性披露以及链下材料与链上证明相结合的安排，但每种方式都有适用条件。验证者如果只能看到摘要，就需要知道摘要能够证明什么、原件由谁保存，以及争议发生时如何获得必要材料。保密不应使权利人失去检查自身处境的基本条件。

信息进入长期复制的记录后，其传播和保存范围也需要认真评估。NIST在适用性讨论中，将数据可见范围、交易历史以及原始记录难以直接删除列为选择因素；新增一条表示删除或更新的记录，并不等于原有内容已经从历史中消失。NIST IR 8202：第8.1节〔3〕

因此，敏感原始材料是否需要上链，应当在写入前作出判断。加密、去除姓名或仅保留摘要，都需要结合具体信息检查其保护效果，不能被当作一概充分的处理。对于长期合作，还应当明确保存期间、访问变更、材料交接和争议使用的责任，使核验需要与信息保护能够同时进入制度。

权力结构是另一项不能被性能指标代替的评价。谁决定参与资格，谁控制请求入口，谁可以调整规则，谁保管紧急权限，谁向系统输入外部事实，都可能影响参与者的实际处境。即便记录验证较为分散，这些其他环节仍可能集中。因此，权力分析应当贯穿从提交到履行的全过程。

还需要区分能够核验与有能力核验。理论上任何人都可以检查某项结果，如果实际需要承担远超普通参与者能力的设施、知识和时间成本，核验权就可能主要由少数服务机构行使。共同治理需要为必要的独立检查提供资源、易于理解的说明和适当的代表安排，并使受托核验者能够被监督和替换。

限制权力与保留纠错能力之间也存在张力。紧急停止和升级权限可以帮助处理严重故障，却可能成为改变承诺的集中入口；完全缺少调整路径，则可能使已知错误继续产生后果。选择时应当具体说明这些权限的触发条件、使用范围、共同控制方式和事后审查，而非仅将其标记为“安全功能”。

长期依赖还要求预先考虑退出与迁移。参与者能否取得可理解、可核验的记录，新的维护者能否继续识别已有承诺，系统停止后由谁保存证据，以及迁移期间怎样处理未完成事项，都影响共同事业的持续性。更换技术设施不会自动解除既有义务，技术方案应当帮助责任延续。

本书主张，选择应当先确认不可缺少的条件，再比较可以权衡的表现。权限依据不清、必要隐私无法保护、关键履行无人负责，不能仅因速度较快或费用较低就被一个较高的综合分数抵消。只有满足基本制度条件的方案，才适合进一步比较效率、成本和长期适应能力。

比较还应当设置真实的替代方案。可以把具备必要权限管理、签名留证和外部核验的数据库方案作为基准，再检验区块链增加了哪些保障。各方案应当面对相近的业务范围、负载和故障情形，并说明对单方拒绝、错误输入、维护者退出及权限滥用的处理。新增技术是否值得，应当由可观察的改进支持。

对于尚不确定的方案，可以在明确范围内试行，事先确定需要观察的结果、承担责任的主体和停止条件。试行应当能够回答共同核对是否减少、事实错误能否纠正、独立验证是否可行，以及成本是否挤压长期投入。若已有方案足以满足要求，可以继续采用；若制度条件尚未形成，应当先完成相应制度工作。

面向未来，本书提出一个有待检验的判断：当跨组织协作和自动代理参与增加时，技术选择的重要单位可能越来越多地落在特定的承诺、授权和共同状态上。组织可以围绕这些关系采用不同验证与执行机制，而无须使所有活动进入同一套账本。这个方向是否能够降低协调成本、保持责任连续并改善参与条件，需要在后续实践中逐项检验。

制度技术的适用边界由此回到本书的起点。共同创造需要可以理解的规则、能够实现的权利和持续承担的责任；区块链在其中的作用，应当体现为某些共同状态更容易核验，某些单方变更更难发生，某些承诺的履行过程更可检查。下一篇将进入这些能力的技术构成，从密码学开始，逐步说明授权、完整性与共同确认怎样实现，以及各自的保障在何处结束。

本章注释

1. [SRC-068] PostgreSQL Global Development Group：PostgreSQL：事务。原文或官方页面

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

2. [SRC-069] RFC Editor：Certificate Transparency Version 2.0（RFC 9162）。原文或官方页面

   • 本章引证：RFC 9162：证书透明度协议，第1节。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：RFC 9162：证书透明度协议，第1节、RFC 9162：默克尔树与包含性证明。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

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

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