信任边界
只有当授权、签名、执行和证据没有集中在一个不受限制的管理员手中时，Luvion 才真正有价值。逻辑流程如下：
合作方操作员
|
v
控制面 —— 策略、角色、请求状态
|
v
授权协调器
|
+----> 签名域 A
+----> 签名域 B
+----> 签名域 C……达到门限
|
v
执行适配器 ----> 合作方钱包、协议或区块链
|
+----> 证据见证服务
+----> 运维告警接收端
箭头表示允许的协议消息，不表示可以共享 root 权限。
各安全域职责
| 安全域 | 持有或控制 | 失陷后可能造成 | 单独失陷时不应能够 |
|---|---|---|---|
| 控制面 | 策略版本、身份、审批和请求状态 | 提交错误流程数据或破坏可用性 | 生成门限证书或绕开适配器执行 |
| 协调器 | 规范签名包、尝试状态和注册表生命周期 | 选择请求、中断轮次或拒绝完成 | 伪造签名份额或静默修改已绑定意图 |
| 签名域 | 一个参与者份额和身份 | 拒绝服务或滥用该份额 | 单独达到门限、改写策略或执行 |
| 执行适配器 | 服务商或链集成及核对 | 提交已授权操作或错误报告可用性 | 接受不匹配请求、绕过证书检查或盲目重试不确定执行 |
| 证据见证 | 仅追加签名回执流 | 延迟证据最终确认 | 授权或执行操作 |
| 告警接收端 | 运维通知 | 压制或泄露有限健康元数据 | 收到密钥、凭据、金额、地址或原始内部错误 |
当前试点拓扑
受控试点可以证明协议行为和恢复属性，但部分进程可能仍位于同一台主机和同一管理故障域。当前部分位置使用文件系统密钥或本地 sidecar，而生产环境应使用 HSM、KMS、TEE 或同等保护服务。远程 mTLS 证明了网络协议边界；如果两端仍由同一管理员控制，它不等于已经证明独立运营。
因此，试点能够证明软件会拒绝意图不匹配、过期纪元、无效参与者、回滚和不安全重试；但它不能证明系统能够抵抗同时控制所有主机、密钥文件、见证服务和执行凭据的单一管理员。
设计合作伙伴目标拓扑
生产候选部署应具备：
- 分别管理的控制面、签名服务和见证基础设施；
- 分布于独立机器和故障域的签名份额；
- 不可导出的受保护密钥句柄，而非普通文件密钥；
- 技术上必须校验 Luvion 证书的执行入口；
- 独立保留的证据流；
- 发送到合作方值班系统的告警。
部署审查必须记录每个安全域由谁管理、密钥放在哪里、允许哪些网络路径、如何轮换以及如何批准紧急撤销。
必须故障关闭的边界
- 审批后不得改变请求摘要、策略版本、密钥纪元、链、目标、参数和有效期。
- 签名人、适配器、见证服务和外部服务商的响应必须绑定精确请求和配置身份。
- 执行结果不确定时必须先核对，不能因为超时就用新的幂等键重新提交。
- 证据锚定或见证失败时，不得声称终态已经获得独立锚定。
- 任何绕开 Luvion 的 Owner、紧急密钥、旧模块或服务商凭据，都必须明确记录为保护边界之外。