English version · 区块链学习导航 · 上一篇：分布式系统与区块链
区块链学习 · 文章 BC004
信任模型说明一个系统依赖哪些参与者与组件、它们拥有什么权限，以及系统声称的保证能够承受哪些故障。它把“记录值得信任”这样的概括说法，转化为可以检查的问题。
对于区块链应用，模型不能只画到链为止。用户还可能依赖网站、签名设备、身份服务、管理员、文件存储和外部信息来源。账本能够很好地达成一致，不等于周边每个环节都可靠。
目的不是认定所有人都不可信，而是把依赖说清楚，限制不必要的权力，并为假设失效设计合理应对。本文通过一个虚构的研究报告档案系统，演示这套方法。
选择适合你的阅读路线
本篇目录
- 1. 信任模型不是声誉排行榜
- 2. 报告档案案例：一个需求，多道边界
- 3. 从读者真正需要的判断开始
- 4. 按角色列出参与者，而不只是写品牌名称
- 5. 沿着一份报告走完整条路径
- 6. 区分依赖项与信任假设
- 7. 检查普通用户看不到的权限
- 8. 假设失效时，会发生什么？
- 9. 完整性、可用性与保密性，需要分别回答
- 10. 外部事实需要可追责的来源
- 11. 一份可以实际填写的信任模型工作表
- 12. 检查独立性，而不只是统计人数
- 13. 系统变化后，信任模型也应更新
- 练习：改写三个模糊说法
- 常见问题
- 资料来源与范围
- 理解概念：先看假设、参与者和报告档案案例。
- 评估应用：沿着一份记录的完整路径，检查依赖和控制权限。
- 准备项目讨论：使用信任模型工作表与故障复盘。
- 复习要点：完成模糊宣传语的改写练习，再核对答案。
1. 信任模型不是声誉排行榜
可靠的人也会犯错，信誉良好的机构也会停机。一个正常运行的服务，还可能拥有超出任务需要的权限。
因此，信任模型不只是把参与者分成好人与坏人，而是说明具体依赖。例如，“档案系统依赖实验室的签名权限来识别所提交的报告”，比“我们信任实验室”更有用。
前一种说法可以检查：谁控制签名权限？作者是否批准了准确的文件版本？密钥泄露后怎么办？核验者能否区分旧签名与后来未经授权的提交？
后一种说法则过于宽泛，把身份、授权、科学质量和运行可靠性都藏进了一个词里。
可以先把“我们信任X”改成：“我们依赖X完成Y；如果X失效，可能发生Z。”这是信任模型最小而有用的表达单位。
2. 报告档案案例：一个需求，多道边界
设想三家独立实验室共同维护研究报告档案。它们希望读者能够识别某一版本由哪个机构提交、看到后续更正，并取得对应文档。
它们考虑在共同维护的账本中记录报告指纹和签名提交声明，完整文件则保存在另一个文档存储系统中。这是虚构案例，不是在描述eduKate已经部署的服务。
方案包含几种不同承诺。指纹可以帮助比较下载文件与登记版本；签名可以支持对签名权限的归属判断；账本可以确定被接受的提交顺序；存储系统则必须让文件能够被获取。
这些承诺都不能证明实验设计合理，或报告结论正确。科学评审仍然是独立过程。一个可靠档案系统，也可能准确保存一份存在缺陷的报告。
有用的信任模型，会保留这些边界，而不是让“已验证”涵盖一切。
3. 从读者真正需要的判断开始
画参与者和箭头之前，先写出用户应当能够依赖什么结论。
对于档案系统，一个范围明确的判断可以是：“这份文件与A实验室通过其认可提交权限登记的版本一致。”它不同于“A实验室的结论为真”，也不同于“每位作者都亲自批准了公开发布”。
接着，找出支持这个判断的证据。核验者需要文件、指纹计算方法、已登记的值，以及相关授权信息。如果网站只显示一个绿色标记，就要说明标记如何产生，其结论能否独立检查。
最后，说明不保证什么。档案系统可能不检查实验方法、发布同意或全部材料的法律权属。这些不一定都是系统缺陷，但不能被伪装成已经提供的保证。
清楚的判断范围，能够防止技术系统把没有完成的工作也算到自己名下。
4. 按角色列出参与者，而不只是写品牌名称
档案案例中的角色包括报告作者、实验室审批人、签名服务、账本参与者、网站运营者、文件存储服务商和读者。
一家机构可能承担多个角色，一个角色也可能分给多个机构。模型应当同时展示这两种情况，因为同一品牌不证明权限相同，不同名称也不证明真正独立。
对每个角色，都要问它实际上能做什么。网站运营者只是显示记录，还是也能授权新增条目？存储服务商能否替换文件、删除文件或拒绝访问？实验室管理员能否不经其他人批准就更换签名密钥？
应记录权限，而不是职位名称。“维护人员”听起来权限不大，但能够替换应用代码的账户，实际控制力可能超过一个没有执行权限的委员会。
应用建立在公有区块链上时，这一点尤其重要。底层网络开放，并不能说明具体应用由谁控制。
5. 沿着一份报告走完整条路径
形成报告：作者编写文件。档案系统不会自动观察实验如何进行，也不知道报告是否存在错误。
审批版本：实验室决定授权提交哪一版。如果审批发生在邮件里，而上传的是另一份文件，就需要发现不一致的办法。
签署声明：获授权的主体对选定版本签署声明。声明必须含义清楚：提交、批准、作者身份和质量认证，是不同断言。
记录入账：账本按照规则接受声明。有效记录能够说明授权与顺序方面的结果，却不能证明报告里的每一项科学命题。
保存文件：完整文件需要在某处持续可访问。已记录的指纹不是备份，也不能重建丢失的报告。
界面展示：网站向读者展示记录。即使底层账本正常，界面仍可能出错或被篡改。
核验结论：读者取得必要证据，检查目标判断。结果强度取决于整条路径，而不是其中最令人印象深刻的组件。
6. 区分依赖项与信任假设
依赖项是应用需要的东西；信任假设则说明，为了让某项保证成立，预期这个东西应怎样运行。
档案系统依赖文件存储。对于可用性，它假定需要文件时至少有一个合适来源能够提供文件。对于完整性，如果读者能够独立把文件与可信承诺比较，系统对存储商的依赖就可能减少。
这个区别会揭示设计机会。只要替换可以被发现，而且读者确实执行检查，就不一定要相信存储商绝不会悄悄改动字节。但仍然需要拿到正确字节的方法。发现问题与恢复内容，是两种不同能力。
同样，读者可以通过独立核验签名记录，减少对网站所显示状态的依赖。但这把工作和假设转移到了核验软件、数据访问和密钥信息，并没有让系统变成毫无依赖。
目标是理解依赖移到了哪里，而不是简单宣布它已经消失。
7. 检查普通用户看不到的权限
应用界面通常突出提交、查看、下载等日常动作。信任模型还必须覆盖特权操作。
谁能升级合约或应用规则？谁能暂停提交？谁能改变哪些实验室密钥被认可？谁能替换网站的数据来源，或改变“已验证”标记的含义？
其中一些权限可能确实必要。密钥泄露或严重软件缺陷之后，恢复往往需要授权干预。设计问题在于：干预是否受到约束、是否可见，以及能否复核。
例如，变更实验室认可的签名权限，可以要求不同主体分别批准。但只有审批人真正独立，而且实现确实执行该政策时，才能减少单方权力。若多份批准都由一个人控制，保护可能弱于图上所暗示的程度。
Solidity安全指南提醒读者，合约运行在更广泛的技术环境中；应用代码正确，也不能排除所有风险。审查和测试应当被理解为针对特定代码与假设的证据，而不是永久保证。Solidity安全注意事项。
8. 假设失效时，会发生什么？
考虑档案系统中的四种情况。
实验室密钥泄露。攻击者可能提交具有技术上有效签名的声明。应对需要区分发现泄露、更换未来授权，以及解释受影响的旧记录。账本不能仅凭签名自动推断密钥何时失陷。
网站显示错误状态。独立核验可能发现不一致，但前提是读者能够通过其他路径访问证据，并理解检查方法。理论上可以核验，却没人实际会用，提供的现实保障就有限。
文档存储丢失文件。账本仍可保留指纹，报告却无法获取。冗余存储与取回测试，解决的是不同于记录完整性的问题。
报告需要更正。档案系统需要关联不同版本，并说明当前采用哪项声明。保留旧版可以支持问责，但访问和保留仍需适当政策。
这些情景不是对故障的预测，而是检查工具：假设失效后，原来的保证是否成立？如果不成立，后果是否可以接受，能否恢复？
9. 完整性、可用性与保密性，需要分别回答
完整性关注信息是否被未经授权地改变，或所呈现结果是否符合相关证据。
可用性关注获得授权的用户，能否在需要时取得信息或服务。
保密性关注哪些信息向谁公开。
在档案案例里，公开指纹可能支持完整性检查，却不保证报告能够下载。公开全文可能改善访问，却违背披露限制。加密文件可以在具体设计下保护内容，同时引入密钥管理和恢复要求。
不要在没有说明的情况下，用一种性质替换另一种性质。“记录很安全”应改成一组有边界的说法：哪些修改可以发现、怎样获取文件、暴露什么信息，以及每项结论依赖什么假设。
2018年10月发布的NIST区块链技术综述，有助于建立记录完整性相关概念，但不能替代对具体应用隐私和运维安排的分析。
10. 外部事实需要可追责的来源
假设档案增加“同行评审已完成”的标签。智能合约不能直接知道评审者是否认真完成了评审，必须由某个主体或机制提供相关声明。
信任模型应确定来源、声明范围和更正程序。“完成”究竟表示报告已送审、意见已经收到，还是正式决定已经批准？即使执行完全一致，模糊输入也只会形成模糊保证。
多个报告者如果都复制同一个上游状态，也不自动形成独立性。关键是信息怎样获得，以及报告机制能够应对哪些失败模式。
以太坊预言机文档解释了为什么外部数据引入额外信任假设。档案例子把这个边界应用到普通信息流程中，并没有假定账本能够判断研究质量。
11. 一份可以实际填写的信任模型工作表
为每个重要角色或组件写一段简短记录，回答六个问题。
- 角色：谁或什么组件执行这项功能？
- 权限：它能够做什么，能否单独行动？
- 依赖：用户依靠它保持什么行为？
- 证据：相关动作或结果怎样检查？
- 故障：它停止、说谎或被入侵时会怎样？
- 应对：谁能发现问题、限制损害并恢复？
文档存储的条目可以写成：提供报告文件；能够拒绝访问；用户依赖取回文件；指纹支持完整性比较；删除会破坏可用性；独立保留的副本可能支持恢复。
实验室审批人的条目可以写成：授权特定版本；用户依赖有实际意义的审批过程；签名声明提供授权证据；权限失陷可能导致虚假提交；撤销和事件说明规定后续处理。
条目应简短到便于讨论，也具体到能够被质疑。如果每个应对方案都只写“区块链会处理”，模型就还没有完成。
12. 检查独立性，而不只是统计人数
图上可能有五名审批人，但五个账户都由同一服务管理。三个存储商可能共用同一份上游文件。多个预言机报告者也可能只是重复同一个数据库条目。
应当问：哪一种共同故障，会同时影响这些看起来独立的主体？共享凭证、软件、托管、数据来源和决策过程，都可能重要。
独立性还与目标有关。不同建筑里的两份副本，可能应对局部设备故障，却无法防止共同管理员把两份都删掉。独立机构可能约束单方政策变更，却不能防护共同软件缺陷。
现实的模型会说明针对哪一种故障，不会暗示参与者更多就意味着无限安全。
13. 系统变化后，信任模型也应更新
只有假设仍然符合现实，模型才有用。应用更换管理员、升级重要代码、引入跨链桥、改变身份服务或迁移文档存储时，都应重新检查。
声明范围变化时，同样需要复审。档案原本只证明版本匹配，后来却开始宣传科学质量认证。这项更强的承诺需要不同证据与责任，即使底层账本完全没变。
为主要假设保留日期，并记录变化原因。运行模式已经改变后，简短说明新增依赖，比继续挂着旧的“去中心化”标记更有帮助。
这是本文的治理建议，并不是说所有应用都需要相同审查周期。合适的触发条件取决于变更后果。
练习：改写三个模糊说法
说法A：“我们的报告经过区块链验证。”
更清楚的版本：“档案为每个版本记录指纹与经过授权的提交声明；读者可以把取回文件与记录比较。科学准确性由其他过程评估。”
说法B：“没有人需要信任运营者。”
更清楚的版本：“读者取得所需数据和核验工具后，可以独立检查指定记录。运营者仍然控制网站及其可用性。”
说法C：“五个签名就能让更新安全。”
更清楚的版本：“更新需要满足政策规定的五项批准。保护效果取决于谁控制批准权限、审批检查什么，以及权限失陷后如何处理。”
练习不是要求把每句话都写得很长，而是让读者获得真正能够评估的判断。
常见问题
信任模型能证明系统安全吗？
不能。它把假设和依赖说清楚，便于设计、测试和审查。精确模型仍可能描述一个薄弱系统；价值在于薄弱之处更容易被发现。
信任总是应该消除的吗？
不是。可追责的机构和明确权限可能很有用。目标是减少隐蔽或不必要的依赖，并让剩下的依赖符合任务需要。
签名能建立身份吗？
签名支持与签名权限之间的联系。把权限对应到真实机构或个人，需要身份安排。W3C凭证模型区分签发者、持有者和核验者，并不自动保证签发者诚实。可验证凭证数据模型v2.0。
初学者先画什么？
先画用户、用户需要的判断、收到的证据，以及每个能够改变或扣留证据的主体。区块链只应出现在它确实对这条路径有贡献的位置。
资料来源与范围
基础技术参考资料的研究日期为2026年10月12日，时区为新加坡。档案案例、工作表和改写练习属于假设性教学分析，不是在描述已部署产品，也不构成应用认证。
- NIST IR 8202：区块链技术综述，2018年10月：基础记录与信任概念。
- 以太坊：预言机，持续更新文档：外部输入与额外假设。
- Solidity：安全注意事项，持续更新文档：代码、平台和运维风险。
- W3C可验证凭证数据模型v2.0，2025年5月15日推荐标准：签发者、持有者与核验者角色。
好的信任模型不会停在“相信这条链”。它解释的是：从用户的问题，到支持答案的证据，整条路径如何成立。