Flare Confidential Compute vote pour un lancement sur Songbird

FCC est la première livraison de la vision Flare 2.0 présentée en mars 2025, qui étend le consensus de Flare au‑delà de sa propre chaîne en combinant les Environnements d’Exécution Confiés (TEEs) avec les protocoles de données de Flare. Le lancement se fait par étapes. Cette première étape apporte deux piliers de la vision à un réseau canari en direct : les Portefeuilles Gérés par le Protocole (PMW), qui donnent aux protocoles une exécution contrôlée sur des chaînes externes à partir de XRPL, et un cadre d’extension de calcul pour un calcul vérifiable et confidentiel. Un Flare Data Connector amélioré (FDC V2) fournit les preuves signées rapides qui lient les deux ensemble.

C’est l’architecture que Flare a publiée il y a un an, désormais accessible aux développeurs.

L’origine

Flare 2.0 a défini trois objectifs que Flare souhaitait étendre sans sacrifier la décentralisation : l’exécution inter‑chaînes, les données à haute intégrité et le calcul substantiel. Elle nomme deux moyens de les réaliser, tous deux basés sur les TEEs et les protocoles de données de Flare. Les Portefeuilles Gérés par le Protocole prendraient en charge l’exécution inter‑chaînes. Le Calcul Vérifiable s’occuperait du côté calcul.

FCC fournit les deux. Le lancement sur Songbird déploie les PMW pour le pilier d’exécution inter‑chaînes et le cadre d’extension de calcul pour le pilier de calcul vérifiable, avec le FDC V2 comme couche de données améliorée entre les deux. L’architecture annoncée en mars 2025 est maintenant déployée sur un réseau canari en direct.

Ce qu’est FCC

FCC est une couche qui se situe au‑dessus de Flare. Elle donne aux applications on‑chain l’accès aux Environnements d’Exécution Confiés : des environnements de calcul sécurisés, isolés matériellement, qui conservent les secrets de façon privée et peuvent prouver qu’ils exécutent le bon code. Cela permet aux développeurs de créer des fonctionnalités qu’un contrat intelligent public ne peut pas supporter seul, notamment une logique confidentielle, un calcul plus lourd, une gestion sécurisée des clés et des actions qui atteignent d’autres chaînes.

Comme les clés privées sont générées et gérées à l’intérieur de ces TEEs, cette couche permet aux protocoles sur Flare d’exécuter des actions sur des chaînes externes sous le consensus de Flare. FCC n’est pas un produit unique. C’est le système autour des TEEs : les contrats intelligents, le relais, la vérification et les applications construites au‑dessus.

Ce qui sera mis en ligne sur Songbird

Un vote de gouvernance est nécessaire parce que le déploiement ajoute de nouveaux contrats on‑chain et de nouvelles responsabilités pour les fournisseurs de données de Songbird. Le vote est un STP, qui fonctionne selon un principe de rejet : il passe à moins que le seuil de quorum de 75 % soit atteint et qu’au moins la moitié des votes soient contre.

S’il est adopté, trois composantes seront mises en service, formant ensemble le système décrit ci‑dessus.

1. Contrats intelligents sur Songbird. Ils régissent l’enregistrement des machines TEE, reçoivent les instructions des utilisateurs et vérifient les résultats. Le protocole relaie les instructions aux TEEs mais ne publie pas les résultats on‑chain. Les consommateurs récupèrent les résultats signés depuis le TEE et les soumettent.
2. Fournisseurs de données en tant que relayeurs. C’est la nouvelle responsabilité. Chaque fournisseur participant exécute un client de relais et un serveur de vérification FDC V2. Ils transmettent les instructions de Songbird aux TEEs et signent ce qu’ils relaient. Un TEE n’exécute que lorsqu’une majorité pondérée de fournisseurs a signé, et cette étape de consensus rend la commande légitime. Les fournisseurs gèrent également l’augmentation, en empaquetant l’instruction de l’utilisateur avec les données supplémentaires nécessaires, on‑chain ou off‑chain, avant de la soumettre.
3. Machines TEE. Elles exécutent le code d’extension à l’intérieur de VMas confidentiels et renvoient des résultats signés. Au lancement sur Songbird, elles sont hébergées sur Google Confidential Compute et exploitées par la Fondation Flare. C’est le point de départ du bootstrap. Le design est prévu pour diversifier les opérateurs et les fournisseurs de matériel au fil du temps, et ce n’est pas l’état final.

La rémunération débute simplement. Plutôt que d’introduire une nouvelle émission de tokens, le lancement compense les fournisseurs de données participants à partir d’un pool de participation financé par la Fondation Flare et par des frais d’attestation pendant la période de bootstrap, avec un système de récompense permanent qui suivra une fois que des données opérationnelles seront disponibles pour le concevoir. Et parce qu’il s’agit de Songbird, le déploiement suit le modèle des déploiements canari : sur un réseau en direct, avant un audit final, avec des rapports d’audit intermédiaires publiés au fur et à mesure. Songbird est l’endroit où le système est prouvé ; un déploiement Flare en découle.

Pourquoi cela importe maintenant

Cela intervient à un moment de consolidation de l’industrie et d’intérêt renouvelé pour la confidentialité on‑chain. Cela coïncide également avec le fait que XRPL s’impose comme une plateforme majeure d’émission d’actifs du monde réel, attirant des capitaux institutionnels grâce à un règlement rapide, de faibles frais et des fonctionnalités de conformité natives. Mais XRPL a été construit pour émettre et déplacer des actifs, pas pour les programmer. Cette lacune constitue l’ouverture : les actifs peuvent être émis sur XRRL puis exploités via Flare, qui fournit la logique, la vérification et la couche d’exécution que XRRL ne possède pas.

Ce que les utilisateurs réclament ne se limite plus à des transactions moins chères ou plus rapides. Ils veulent une infrastructure qui garde la logique sensible et les clés confidentielles tout en pouvant prouver que l’action correcte a eu lieu. Confidentialité et vérifiabilité ensemble sont ce que FCC a été conçu pour offrir, en associant les TEEs aux protocoles de données de Flare.

Ce que le lancement permet

Flare Data Connector V2. Le FDC actuel valide les événements externes sur Flare en regroupant les demandes d’attestation en cycles d’environ 90 secondes, en signant une racine Merkle et en la publiant on‑chain. Le FDC V2 supprime cette latence de cycle en traitant chaque demande individuellement via FCC. Un TEE signe la réponse d’attestation une fois qu’il a reçu suffisamment de confirmations signées, et l’utilisateur récupère et soumet la réponse. Le FDC V2 est lancé avec quatre types d’attestation couvrant la disponibilité du TEE et la vérification du paiement PMW. Au lancement sur Songbird, cela signifie des attestations plus rapides, traitées individuellement, et il constitue la couche de preuve qui rend les Portefeuilles Gérés par le Protocole fiables.

Portefeuilles Gérés par le Protocole. Les PMW permettent à un protocole sur Flare de créer et d’opérer un portefeuille sur une chaîne externe, contrôlé par les règles du protocole plutôt que par une personne ou un serveur backend. Les clés sont générées et conservées à l’intérieur des TEEs, et elles ne signent que lorsqu’une majorité pondérée de fournisseurs de données relaie l’instruction. Le portefeuille est donc sécurisé à la fois par le consensus de Flare et par les garanties matérielles du TEE, et les utilisateurs soucieux de la sécurité peuvent ajouter des cosignataires à un compte PMW, obligeant les TEEs à collecter les signatures à la fois des fournisseurs de données et des cosignataires avant de signer. Cela va plus loin que les schémas d’interopérabilité existants et s’oriente vers l’abstraction de chaîne : l’utilisateur n’interagit qu’avec Flare, et le protocole s’exécute partout ailleurs. À ce stade, les PMW sont lancés avec le support de XRRL.

Les deux fonctionnent comme une capacité unique : agir sur des chaînes externes depuis Flare, avec une preuve que l’action a eu lieu. Les PMW assurent l’action et le FDC V2 fournit la preuve. Comme le décrivait Flare 2.0, chaque modèle d’utilisation des PMW s’appuie sur le Flare Data Connector pour prouver qu’une transaction donnée a eu lieu. C’est pourquoi trois des quatre types d’attestation du lancement du FDC V2 servent les PMW. Le FDC V2 n’est pas un produit séparé qui accompagne simplement les PMW. Mais le FDC V2 est plus qu’une couche de preuve pour les PMW. C’est une version améliorée du Flare Data Connector en soi : des attestations plus rapides, traitées individuellement, disponibles pour tous les développeurs construisant sur Flare, pas seulement pour FCC.

Ce que cela ouvre

Les PMW et le FDC V2 sont les premières applications, pas le but ultime. Elles fonctionnent sur un cadre dont les mécanismes sont en place dès le départ. Au lancement, les machines TEE ne servent que ces applications système, et la possibilité pour les constructeurs de déployer leurs propres machines TEE et d’enregistrer des extensions personnalisées est présente dans les contrats mais activée plus tard pendant la période de bootstrap. Lorsqu’elle sera activée, un constructeur pourra définir une extension avec un contrat recevant les instructions, un ensemble de machines TEE enregistrées et une liste de versions de code supportées, et exécuter sa propre logique confidentielle avec les mêmes garanties de relais‑et‑signature que celles qui sécurisent les PMW.

Le premier cas d’usage du PMW est l’exemple le plus clair de l’importance de cette fonctionnalité. Il permet à un protocole sur Flare de détenir et d’opérer directement un compte XRRL, jetant ainsi les bases de l’introduction de XRP dans la DeFi sur Flare sans obliger les utilisateurs à effectuer un pont. C’est une application du cadre. Le même mécanisme — clés scellées, code approuvé, résultats signés et vérifiés — est hérité par toute extension future. Songbird est l’endroit où cela est prouvé de bout en bout sur le réseau principal de Flare.

Les développeurs peuvent consulter le découpage technique complet, l’architecture et les guides de construction pas à pas sur le Flare Dev Hub.

Détails du vote

Période de préavis : du 29 juin au 5 juillet 2026

Période de vote : du 6 juillet au 13 juillet 2026

Voir la proposition STP.13 à l’adresse : https://proposals.flare.network/STP/STP_13.html

Analyse FTSOBest

Qu'est‑ce qui est ajouté ?

• Trois groupes de contrats on‑chain sur Songbird :
  1. Contrats d’enregistrement et de vérification TEE – gèrent les identités des machines et valident les résultats signés.
  2. Contrats de relais du fournisseur de données – chaque fournisseur exécute un vérificateur FDC V2 et un client de relais ; une majorité pondérée des signatures est requise avant qu’un TEE n’exécute.
  3. Contrats du cadre d’extension – exposent l’API de réception d’instructions utilisée par la couche de calcul.
• Machines TEE – machines virtuelles confidentielles hébergées initialement sur Google Confidential Compute, gérées par la Flare Foundation.
• FDC V2 – remplace le modèle d’attestation par lots de 90 secondes par une signature par requête, réduisant la latence des preuves.
• Protocol Managed Wallets (PMW) – permettent à un protocole Flare de posséder et de dépenser depuis un portefeuille XRPL, les clés étant générées à l’intérieur des TEEs et signées sous contrôle du consensus des relayeurs.
• Pool de récompenses – financé par la Flare Foundation et les frais d’attestation ; aucune nouvelle émission de jeton pendant la phase de démarrage.

Dépendances techniques

• Trusted Execution Environments – l’isolation matérielle est essentielle pour la confidentialité des clés et la génération des preuves.
• Flare Data Connector (FDC) V2 – fournit la couche de preuve d’exécution ; ses serveurs vérificateurs doivent être exploités par les fournisseurs de données.
• Consensus de relais à majorité pondérée – garantit qu’une commande n’est exécutée que lorsque suffisamment de fournisseurs ont signé, liant l’exécution au consensus de Flare.
• Google Confidential Compute (initialement) – agit en tant que premier opérateur TEE ; une diversification future nécessitera des partenaires matériels supplémentaires ainsi que des mises à jour de contrats.

Implications pratiques

• Pour les utilisateurs : les actifs sur XRPL peuvent être utilisés dans les applications DeFi de Flare sans passer par un bridge ; les clés privées ne quittent jamais le TEE, réduisant la surface d’attaque.
• Pour les développeurs : le Dev Hub (https://dev.flare.network/fcc/overview) contient l’architecture complète et des guides pas à pas. Les constructeurs pourront plus tard enregistrer leurs propres machines TEE et extensions personnalisées une fois que la période de démarrage aura levé les interrupteurs de contrat.
• Pour le réseau : les nouveaux contrats augmentent le nombre d’appels on‑chain (enregistrement, vérification d’attestation, distribution des récompenses). Cependant, la conception maintient une consommation de gaz similaire aux appels FDC existants, chaque requête étant traitée individuellement plutôt qu’en gros lots.

Considérations de risque

• La sécurité du système dépend de la correction du matériel TEE et de l’honnêteté du ensemble de relayeurs pendant le démarrage. Toute compromission des nœuds initiaux Google Confidential Compute pourrait affecter les premières preuves.
• La règle de majorité pondérée nécessite un ensemble fiable de fournisseurs de données ; une participation insuffisante pourrait bloquer l’exécution.
• Les audits sont encore intermédiaires. Les audits de sécurité finaux auront lieu après la validation de Songbird, laissant ainsi une fenêtre de risque d’audit.

Indices de feuille de route (sans engagement)

• Après une validation réussie sur Songbird, Flare prévoit un déploiement sur le main‑net en utilisant les mêmes contrats.
• Les phases futures permettront aux constructeurs de déployer leurs propres opérateurs TEE et extensions, élargissant le support au‑delà de XRPL.

Points clés

1. FCC apporte du calcul confidentiel et vérifiable à Flare via les TEEs.
2. PMW fournit des portefeuilles contrôlés on‑chain sur XRPL, comblant le fossé d’émission d’actifs.
3. FDC V2 offre des attestations plus rapides, par requête, améliorant la latence des preuves pour toutes les applications.
4. Le lancement est un test canari ; son succès orientera le déploiement sur le main‑net et la vision plus large de Flare 2.0.