一旦团队接受了自己需要可独立验证的记录完整性，下一个问题就属于运营层面，而非密码学层面：是我们自己运行，还是交给别人替我们运行？两种模式产出的证明是相同的——一个锚定在公链上、任何人都能验证的默克尔树根。不同的是谁持有密钥、数据存放在哪里，以及谁背着传呼机随时待命。本指南梳理这些权衡，让你走进采购对话时就已经清楚哪种模式适合自己。
用一段话说清两种模式
自托管意味着完整性平台运行在你自己的基础设施内——你的 Kubernetes 集群、你的云账户或数据中心、你的密钥管理服务。由你来运维，供应商授权软件并提供支持。托管则意味着供应商在其基础设施上以专用的单租户实例运行该平台，你通过 API 与之集成。两种情况下，锚定目标都是同一条公链，证明在两种模式下都可由第三方验证。
认为自托管“更安全”、托管“更省事”的直觉，太过粗糙，不足以据此决策。真正的决策取决于四个具体维度，而对大多数组织来说，其中一两个会起主导作用。
真正起决定作用的四个维度
在每个维度上给自己的处境打分。只要其中任何一个是硬约束，它往往就能单独定调：
- 数据驻留——如果法规或合同要求记录数据绝不能离开你的环境或某个特定司法管辖区，那么自托管就直接消除了这个问题。托管通常也能通过区域专用实例满足驻留要求，但这就成了一条需要谈判的条款，而非一个架构上的既定事实。
- 密钥保管——谁持有签名密钥，才是真正的安全边界。自托管把它保存在你自己 IAM 管控下的 KMS 中。托管则代你把它保存在一个隔离的、单租户的 KMS 里。如果“必须由我们成为唯一可能持有密钥的一方”是不可让步的，那就指向自托管。
- 运维能力——自托管意味着你要运行一个高可用的签名服务、管理密钥轮换、并固定保存证明包。如果你没有一支尚有余力的平台团队，托管会把这些义务变成别人 SLA 里的事。
价格差异反映了什么
两种模式定价不同，是因为成本结构不同，而不是因为一个是另一个的打折版。托管包含了基础设施、可用性与运维人力。自托管则是针对你在自己已付费硬件上运行的软件所收取的许可费。
自托管标价更高，恰恰是因为它不包含你自己承担的那部分运维——也因为需要它的买家通常正是那些对驻留与保管有最严格强制要求的机构。如果你的驱动因素纯粹是成本，那么一旦你诚实地把自身运维人力计入，托管几乎总是总拥有成本更低的那一个。
实践中决策如何流转
对大多数团队来说，路径很短。按顺序走过这些维度，在第一个硬约束处停下：
一家奉行“数据留在我们租户内”政策的受监管银行，在成本进入对话之前就已落到自托管上。一家希望获得完整性保证、却又不想再立起一个高可用服务的医疗健康规模化企业，则会落到托管上，并谈下一份 BAA。大多数组织都属于这两类之一；介于两者之间的情况，才是真正需要一次深入对话的地方。
哪种画像适配哪种模式
作为一份粗略的对照图——而非铁律——这些受监管的画像往往会聚成几类：
- 自托管适合 — 大型银行、政府机构，以及任何有绝对数据驻留或独占密钥保管强制要求、且拥有一支胜任的平台团队的实体。
- 托管适合 — 金融科技与医疗健康规模化企业、审计与合规团队，以及任何想要这份保证、却不愿再运维一个有状态服务的机构。
- 两种皆可的是 — 需求适中的中端市场机构——在这里，决策真正是一桩成本与偏好的取舍，而一次试点能最快把它解决。
带着答案来，而不是带着问题来
由于两种模式都只能询价获取，最高效的对话，是你已经清楚自己的驻留与密钥保管约束、以及运维能力的那一次。手握这三个答案，部署模式通常一句话就显而易见，余下的讨论就关乎用量与时间表，而非架构。如果你确实在两者之间举棋不定，那么在托管实例上做一个范围明确的试点，是在你承诺自行运维之前、了解自己究竟需要什么的最廉价方式。
两种模式产出的证明是相同的。要决定的不是密码学——而是谁持有密钥、数据住在哪里，以及谁背着传呼机随时待命。