Dapr 1.18 的 Verifiable Execution 解决什么问题

Dapr 1.18 的 Verifiable Execution 解决的不是“日志不够多”，而是分布式工作流在关键决策前缺少可验证的执行依据。它把工作流历史签名、来源传播和工作流证明组合起来，让下游系统能够判断：历史有没有被改动、请求从哪里来、是否经过了约定的工作流。

官方资料：

CNCF 介绍：https://www.cncf.io/blog/2026/06/11/introducing-verifiable-execution-in-dapr-1-18/

Dapr 文档：https://v1-18.docs.dapr.io/developing-applications/building-blocks/workflow/workflow-history-signing/

因此，它更像是 Durable Execution 和可观测性之上的信任层，而不是把现有日志、指标和 Trace 全部替换掉。

先区分“看见发生了什么”和“证明发生了什么”

日志适合解释业务动作，指标适合观察性能，Trace 适合还原跨服务路径，审计记录适合保留历史。但这些信息通常仍依赖存储系统、采集链路和运维权限的可信假设：记录可以被覆盖，跨服务转发时上下文也可能丢失。

Verifiable Execution 的关注点更窄也更硬：它不是再增加一种观测格式，而是让执行历史具有篡改可见性，并让执行来源可以随请求传递。可以这样理解：

Dapr 1.18 增加了哪三层能力

CNCF 对 Dapr 1.18 的介绍把新能力拆成三部分，它们不是三个重复的名字，而是分别解决完整性、来源和信任判断。

1. Workflow History Signing：让历史修改可被发现

工作流不断产生历史事件，历史签名会为这些记录建立可验证的签名链。后续加载工作流状态时，系统可以发现历史是否被修改、重排或删除。它提供的是完整性信号，不等于业务结果自动正确，也不替代业务审计。

2. Workflow History Propagation：让来源跟着工作走

一个工作流可能调用活动，活动再调用服务，服务又触发另一个工作流或 AI Agent。来源传播把执行起点、参与的工作流和相关上下文带到下游，减少只靠多套日志拼接调用链的情况。

3. Workflow Attestation：让下游按证明做判断

来源传播说明“这份工作从哪里来”，attestation 则让接收方基于可验证上下文做决定。例如付款、理赔或质量放行接口，可以要求请求确实经过审批、风控或质检流程，再继续后续动作，而不是只相信调用方口头附带的字段。

SPIFFE 身份与 Durable Execution 分别负责什么

Dapr 原有的 Durable Execution 解决“服务重启、崩溃或网络中断后怎样从状态继续”的问题；Verifiable Execution 进一步追问“这段状态和请求的来路是否可信”。两者是恢复能力与信任能力的分工。

Dapr 官方资料还把 SPIFFE 工作负载身份放在信任链的基础位置。可以用一句话记忆：SPIFFE 主要回答“你是谁”，Verifiable Execution 进一步回答“你是怎样走到这里的”。在 Dapr 1.18 的工作流历史签名文档中，mTLS 身份材料是签名与验证的重要前提；因此，启用相关能力时还要把根 CA 生命周期、证书轮换和验证失败处理纳入设计。

这也说明它不是一颗可以单独打开的“合规开关”：身份、工作流历史、来源上下文和下游策略必须处在同一条可解释的信任边界里。

哪些场景值得考虑，哪些场景不必急着采用

如果流程涉及跨团队审批、金融交易、医疗理赔、生产质检或 AI Agent 代替人调用工具，系统往往不只需要知道请求成功，还需要保留可复核的执行来源。这类场景更适合评估历史签名、来源传播和 attestation 的组合价值。

如果业务只是内部低风险接口，现有日志、Trace 和普通审计已经能满足排障与追责，就不必因为“可验证执行”这个新名词立刻重做架构。优先回答三个问题即可：哪些决策必须证明经过指定流程，哪些参与者需要可验证身份，验证失败时是拒绝、隔离还是转人工。

我的判断是，Dapr 1.18 的价值不在于把所有调用都加密包装，而在于把“执行历史”从可查询记录提升为可以被下游策略消费的信任信号。采用前先划定高风险工作流，再决定签名历史的保存范围和证明的消费位置，成本会更可控。

相关问题

Verifiable Execution 会取代日志和 Trace 吗？

不会。日志、指标和 Trace 仍负责解释系统行为与性能；Verifiable Execution 主要补充完整性、来源和证明关系。

只开启 Durable Workflow 就有可验证执行了吗？

不等同。Durable Workflow 解决故障恢复，历史签名、来源传播和 attestation 才分别补上完整性与信任判断能力，并且还需要身份和验证策略配合。