Flare Confidential Compute 投票在 Songbird 上启动

FCC 是在2025年3月提出的Flare 2.0愿景的首次交付，旨在通过将受信执行环境（TEEs）与 Flare 的数据协议相结合，将 Flare 的共识扩展到其自身链之外。发布分阶段进行。第一阶段将愿景的两个支柱引入实时金丝雀网络：协议管理钱包（PMW），它为协议在外部链（从 XRPL 开始）上提供受控执行，以及用于可验证和保密计算的计算扩展框架。升级后的 Flare Data Connector（FDC V2）提供将两者关联的快速签名证明。

这就是 Flare 一年前公布的架构，如今正面向构建者。

起源

Flare 2.0 确立了 Flare 想要在不放弃去中心化的前提下扩展的三件事：跨链执行、高完整性数据和大规模计算。它提出了两种实现方式，均基于 TEEs 和 Flare 的数据协议。协议管理钱包（PMW）负责跨链执行。可验证计算负责计算部分。

FCC 同时提供这两者。Songbird 的发布为跨链执行支柱提供 PMW，为可验证计算支柱提供计算扩展框架，FDC V2 作为升级后的数据层连接两者。2025年3月宣布的架构现在正走向实时金丝雀网络。

FCC 是什么

FCC 是位于 Flare 之上的一层。它为链上应用提供受信执行环境（TEEs）的访问：安全、硬件隔离的计算环境，能够私密保存机密并证明其运行了正确的代码。这使开发者能够构建公共智能合约自行无法支持的功能，包括保密逻辑、更强大的计算、安全的密钥管理以及跨链操作。

由于私钥在这些 TEEs 内生成和管理，该层使得 Flare 上的协议能够在 Flare 共识下在外部链上执行。FCC 并非单一产品，它是围绕 TEEs 的系统：智能合约、转发、验证以及其之上构建的应用。

Songbird 上将上线的内容

由于部署会新增链上合约并为 Songbird 的数据提供者增加责任，需要进行治理投票。该投票采用 STP，属于拒绝式投票：除非达到 75% 的法定人数且至少有一半的投票反对，否则视为通过。

如果投票通过，三个组件将上线，它们共同构成上文描述的工作系统。

1. Songbird 上的智能合约. 这些合约管理 TEE 机器的注册、接收用户指令并验证结果。协议将指令转发给 TEEs，但不在链上发布结果。消费者从 TEE 获取签名结果并提交。
2. 数据提供者作为中继者. 这是新的职责。每个参与的提供者运行一个中继客户端和一个 FDC V2 验证服务器。它们将指令从 Songbird 传递到 TEEs 并对转发的内容进行签名。只有当加权多数提供者签名后，TEE 才会执行，这一步共识确保指令的合法性。提供者还负责增强，将用户指令与所需的额外数据（链上或链下）打包后再提交。
3. TEE 机器. 这些机器在保密虚拟机中运行扩展代码并返回签名结果。Songbird 启动时，它们托管在 Google Confidential Compute 上，由 Flare Foundation 运营。这是引导阶段的起点。该设计旨在随时间在运营商和硬件供应商之间实现多样化，这并非最终状态。

奖励机制从简单开始。发布并未引入新的代币发行，而是通过 Flare Foundation 资助的参与池以及引导期间的证明费用，补偿参与的数据提供者，随后将在有运营数据可供参考后引入永久奖励体系。由于这是 Songbird，它遵循金丝雀部署的方式：在实时网络上发布，最终审计之前先进行，期间的审计报告会随时公布。Songbird 是系统得到验证的地方，随后将进行 Flare 的部署。

为何此时重要

此时正值行业整合期以及链上隐私兴趣的重新升温。同时，XRPL 正在成为真实资产发行的主要平台，以快速结算、低费用和原生合规特性吸引机构资本。但 XRPL 只被设计用于发行和转移资产，并不具备编程能力。这一空白正是突破口：资产可以在 XRPL 上发行后，通过 Flare 进行运作，Flare 提供了 XRRL 本身缺乏的逻辑、验证和执行层。

人们的需求已超越更便宜或更快的交易。他们需要能够保持敏感逻辑和密钥保密，并仍能证明正确执行的基础设施。保密性与可验证性相结合正是 FCC 所构建的目标，即通过将 TEEs 与 Flare 的数据协议相结合来实现。

发布实现的功能

Flare Data Connector V2. 当前的 FDC 通过将证明请求批量为约 90 秒一轮的方式进行处理，签署 Merkle 根并将其链上发布，以验证 Flare 上的外部事件。FDC V2 通过 FCC 对每个请求单独处理，降低了轮次延迟。TEE 在获得足够的签名确认后签署证明响应，用户随后获取并提交。FDC V2 搭载四种证明类型，涵盖 TEE 可用性和 PMW 支付验证。Songbird 启动时，这意味着更快、单独处理的证明，并作为使协议管理钱包可信赖的证明层。

Protocol Managed Wallets. PMW 允许 Flare 上的协议在外部链上创建并运营钱包，由协议规则而非个人或后端服务器控制。密钥在 TEEs 内生成并保存，只有在加权多数数据提供者转发指令时才会签名。因此钱包同时受 Flare 共识和 TEE 硬件保证的保护，注重安全的用户可以为 PMW 账户添加共签者，要求 TEEs 收集数据提供者和共签者的签名后才进行签名。这超越了现有的互操作方案，迈向链抽象：用户仅与 Flare 交互，协议在其他链上执行。目前，PMW 在启动时支持 XRPL。

两者协同提供一项功能：从 Flare 对外部链进行操作，并提供操作已发生的证明。PMW 负责执行，FDC V2 提供证明。正如 Flare 2.0 所述，PMW 的每种使用模型都依赖 Flare Data Connector 来证明特定交易已发生。这也是 FDC V2 四种启动证明类型中有三种服务于 PMW 的原因。FDC V2 并非随 PMW 一同发布的独立产品，但它不仅是 PMW 的证明层，而是 Flare Data Connector 的升级版——更快、单独处理的证明，可供所有在 Flare 上构建的人使用，而不仅限于 FCC。

它开启的可能性

PMW 和 FDC V2 是首批应用，而非最终目标。它们运行在从一开始就已具备机制的框架上。启动时，TEE 机器仅为这些系统应用服务，构建者部署自定义 TEE 机器并注册扩展的能力已写入合约，但会在引导期后期才开启。届时，构建者将定义一个包含指令接收合约、已注册的 TEE 机器集合以及支持的代码版本列表的扩展，并以同样的转发‑签名保障运行其保密逻辑，确保与 PMW 相同的安全性。

PMW 的首要任务最能说明其意义。它让 Flare 上的协议直接持有并运营 XRPL 账户，为在 Flare 上将 XRP 引入 DeFi 而无需用户进行桥接奠定基础。这是框架的一个应用。同样的机制——封闭密钥、已批准的代码、签名并经过验证的结果——将被任何未来的扩展继承。Songbird 是在 Flare 主网上端到端验证的环境。

开发者可在Flare Dev Hub查阅完整的技术细分、架构以及逐步构建指南。

投票详情

通知期间: 2026年6月29日 - 7月5日

投票期间: 2026年7月6日 - 7月13日

在以下地址查看 STP.13 提案：https://proposals.flare.network/STP/STP_13.html

FTSOBest 分析

新增内容是什么？

• Songbird 上的三个链上合约组：
  1. TEE 注册与验证合约 – 管理机器身份并验证签名结果。
  2. 数据提供者中继合约 – 每个提供者运行一个 FDC V2 验证器和中继客户端；在 TEE 执行前需要多数签名的加权共识。
  3. 扩展框架合约 – 暴露计算层使用的指令接收 API。
• TEE 机器 – 最初在 Google Confidential Compute 上托管的机密虚拟机，由 Flare 基金会运营。
• FDC V2 – 用每请求签名取代 90 秒批量证明模型，降低证明延迟。
• 协议托管钱包 (PMW) – 允许 Flare 协议拥有并支出 XRPL 钱包，密钥在 TEE 内生成，签名受中继共识控制。
• 奖励池 – 由 Flare 基金会和证明费用资助；在引导阶段没有新的代币发行。

技术依赖

• 可信执行环境 (TEE) – 硬件隔离对密钥机密性和证明生成至关重要。
• Flare 数据连接器 (FDC) V2 – 提供执行证明层；其验证服务器必须由数据提供者运行。
• 加权多数中继共识 – 确保只有足够的提供者签名时才执行指令，将执行绑定到 Flare 的共识。
• Google Confidential Compute（最初） – 作为首个 TEE 运营商；未来的多元化将需要额外的硬件合作伙伴和合约更新。

实际影响

• 对用户：XRPL 上的资产可在 Flare DeFi 应用中直接使用，无需跨链桥；私钥永不离开 TEE，降低攻击面。
• 对开发者：Dev Hub (https://dev.flare.network/fcc/overview) 包含完整架构和分步指南。构建者在引导期解除合约开关后，可注册自己的 TEE 机器和自定义扩展。
• 对网络：新合约会增加链上调用次数（注册、证明验证、奖励分配）。但设计保持 gas 使用与现有 FDC 调用相似，因为每个请求单独处理，而非大批量。

风险考虑

• 系统安全取决于 TEE 硬件的正确性以及引导期间中继集合的诚信。任何对初始 Google Confidential Compute 节点的妥协都可能影响早期证明。
• 加权多数规则需要可靠的数据提供者集合；参与不足可能导致执行停滞。
• 审计仍为中期。最终安全审计将在 Songbird 验证后进行，因此仍存在审计风险窗口。

路线图提示（非承诺）

• 在 Songbird 成功验证后，Flare 计划使用相同合约在主网推出。
• 后续阶段将让构建者部署自己的 TEE 运营商和扩展，超出对 XRPL 的支持。

关键要点

1. FCC 通过 TEE 为 Flare 引入机密、可验证的计算。
2. PMW 在 XRPL 上提供链上受控钱包，弥合资产发行的鸿沟。
3. FDC V2 提供更快的每请求证明，提升所有应用的证明延迟。
4. 此次启动是金丝雀测试；其成功将指导主网部署以及更广泛的 Flare 2.0 愿景。