Flare Confidential Compute stimmt für die Einführung auf Songbird

FCC ist die erste Umsetzung der Flare 2.0‑Vision, die im März 2025 vorgestellt wurde und den Konsens von Flare über die eigene Chain hinaus erweitert, indem Trusted Execution Environments (TEEs) mit Flare‑Datenprotokollen kombiniert werden. Der Start erfolgt in Phasen. Diese erste Phase bringt zwei der Säulen der Vision in ein Live‑Canary‑Netzwerk: Protocol Managed Wallets (PMW), die Protokollen kontrollierte Ausführung auf externen Chains ab XRPL ermöglichen, sowie ein Compute‑Extension‑Framework für verifizierbare und vertrauliche Berechnungen. Ein aufgerüsteter Flare Data Connector (FDC V2) liefert die schnellen, signierten Nachweise, die beide verbinden.

Dies ist die Architektur, die Flare vor einem Jahr veröffentlicht hat und die nun Bauherren erreicht.

Der Ursprung

Flare 2.0 definierte drei Dinge, die Flare erweitern wollte, ohne Dezentralisierung aufzugeben: Cross‑Chain‑Ausführung, hochintegritätsdaten und signifikante Rechenleistung. Es nennt zwei Wege, diese zu liefern, beide basierend auf TEEs und Flare‑Datenprotokollen. Protocol Managed Wallets würden die Cross‑Chain‑Ausführung übernehmen. Verifiable Compute würde den Rechen‑Teil abdecken.

FCC liefert beides. Der Songbird‑Start bringt PMW für die Säule der Cross‑Chain‑Ausführung und das Compute‑Extension‑Framework für die Säule des verifizierbaren Compute, wobei FDC V2 als aufgerüstete Datenschicht dazwischen dient. Die im März 2025 angekündigte Architektur kommt nun in ein Live‑Canary‑Netzwerk.

Was FCC ist

FCC ist eine Schicht, die über Flare liegt. Sie ermöglicht On‑Chain‑Anwendungen den Zugriff auf Trusted Execution Environments: sichere, hardware‑isolierte Rechenumgebungen, die Geheimnisse privat halten und nachweisen können, dass der korrekte Code ausgeführt wird. Das erlaubt Entwicklern, Dinge zu bauen, die ein öffentlicher Smart Contract nicht allein unterstützen kann, darunter vertrauliche Logik, rechenintensive Prozesse, sichere Schlüsselverwaltung und Aktionen, die andere Chains erreichen.

Da private Schlüssel innerhalb dieser TEEs generiert und verwaltet werden, ermöglicht diese Schicht Protokollen auf Flare die Ausführung auf externen Chains unter Flare‑Konsens. FCC ist kein einzelnes Produkt. Es ist das System rund um TEEs: die Smart Contracts, das Relaying, die Verifizierung und die darauf aufgebauten Anwendungen.

Was auf Songbird live geht

Eine Governance‑Abstimmung ist erforderlich, weil die Bereitstellung neue On‑Chain‑Contracts und neue Verantwortlichkeiten für Songbirds Datenanbieter hinzufügt. Die Abstimmung ist ein STP, das ablehnungsbasiert ist: Sie wird angenommen, es sei denn, die 75 %‑Quorum‑Schwelle wird erreicht und mindestens die Hälfte der Stimmen dagegen ist.

Wenn sie angenommen wird, gehen drei Komponenten live und bilden zusammen das oben beschriebene funktionierende System.

1. Smart Contracts auf Songbird. Sie regeln die Registrierung von TEE‑Maschinen, erhalten Benutzeranweisungen und verifizieren Ergebnisse. Das Protokoll leitet Anweisungen an die TEEs weiter, veröffentlicht jedoch keine Ergebnisse on‑chain. Verbraucher holen die signierten Ergebnisse von der TEE ab und reichen sie ein.
2. Datenanbieter als Relayer. Das ist die neue Verantwortung. Jeder teilnehmende Anbieter betreibt einen Relay‑Client und einen FDC V2‑Verifizierungs‑Server. Sie übermitteln Anweisungen von Songbird zu den TEEs und signieren das Weitergeleitete. Eine TEE wird nur ausgeführt, sobald eine gewichtete Mehrheit der Anbieter unterschrieben hat; dieser Konsensschritt verleiht dem Befehl Legitimität. Anbieter kümmern sich auch um die Aufbereitung, indem sie die Anweisung des Nutzers mit allen zusätzlichen Daten, die sie benötigen, on‑chain oder off‑chain verpacken, bevor sie sie einreichen.
3. TEE‑Maschinen. Sie führen den Erweiterungscode innerhalb vertraulicher VMs aus und liefern signierte Ergebnisse zurück. Beim Start auf Songbird werden sie von Google Confidential Compute gehostet und von der Flare Foundation betrieben. Das ist der Ausgangspunkt des Bootstraps. Das Design ist darauf ausgelegt, im Laufe der Zeit über Betreiber und Hardware‑Anbieter hinweg zu diversifizieren, und dies ist nicht der Endzustand.

Die Vergütung beginnt einfach. Anstatt neue Token-Emissionen einzuführen, kompensiert der Start die teilnehmenden Datenanbieter aus einem Teilnahmepool, der von der Flare Foundation und durch Attestationsgebühren während der Bootstrap‑Phase finanziert wird, mit einem permanenten Belohnungssystem, das später folgt, sobald operative Daten vorliegen, um es zu konzipieren. Und weil dies Songbird ist, erfolgt die Auslieferung so, wie Canary‑Deployments gedacht sind: auf einem Live‑Netzwerk, vor einem finalen Audit, mit Zwischenaudit‑Berichten, die veröffentlicht werden, sobald sie vorliegen. Songbird ist der Ort, an dem das System bewiesen wird; ein Flare‑Deployment folgt daraus.

Warum es jetzt wichtig ist

Dies geschieht in einer Phase der Konsolidierung in der Branche und erneuten Interesse an On‑Chain‑Privatsphäre. Gleichzeitig etabliert sich XRPL als wichtiger Ort für die Ausgabe von realen Vermögenswerten, wodurch institutionelles Kapital durch schnelle Abwicklung, niedrige Gebühren und native Compliance‑Funktionen angezogen wird. XRPL wurde jedoch zum Ausgeben und Verschieben von Assets gebaut, nicht zum Programmieren. Diese Lücke ist die Chance: Assets können auf XRPL ausgegeben und anschließend über Flare genutzt werden, das die Logik, Verifizierung und Ausführungsschicht liefert, die XRPL von selbst nicht besitzt.

Was die Nutzer verlangen, geht über günstigere oder schnellere Transaktionen hinaus. Sie wollen eine Infrastruktur, die sensible Logik und Schlüssel vertraulich hält und gleichzeitig nachweisen kann, dass das Richtige geschehen ist. Vertraulichkeit und Verifizierbarkeit zusammen sind das, wofür FCC gebaut wurde, indem TEEs mit Flare‑Datenprotokollen kombiniert werden.

Was der Start ermöglicht

Flare Data Connector V2. Der aktuelle FDC validiert externe Ereignisse auf Flare, indem Attestationsanfragen in etwa 90‑Sekunden‑Runden gebündelt, ein Merkle‑Root signiert und on‑chain veröffentlicht werden. FDC V2 reduziert diese Rundenlatenz, indem jede Anfrage einzeln über FCC bearbeitet wird. Eine TEE signiert die Attestationsantwort, sobald sie genügend signierte Bestätigungen hat, und der Nutzer holt sie ab und reicht sie ein. FDC V2 startet mit vier Attestation‑Typen, die TEE‑Verfügbarkeit und PMW‑Zahlungs‑Verifizierung abdecken. Beim Songbird‑Start bedeutet das schnellere, einzeln bearbeitete Attestationen und es dient als Nachweisschicht, die Protocol Managed Wallets vertrauenswürdig macht.

Protocol Managed Wallets. PMW ermöglicht einem Protokoll auf Flare, ein Wallet auf einer externen Chain zu erstellen und zu betreiben, das von Protokollregeln statt von einer Person oder einem Backend‑Server kontrolliert wird. Schlüssel werden innerhalb der TEEs generiert und gehalten und signieren nur, wenn eine gewichtete Mehrheit der Datenanbieter die Anweisung weiterleitet. Das Wallet ist somit sowohl durch Flare‑Konsens als auch durch die Hardware‑Garantie der TEE gesichert, und sicherheitsbewusste Nutzer können Cosigner zu einem PMW‑Konto hinzufügen, sodass die TEEs Signaturen von sowohl Datenanbietern als auch Cosignern sammeln müssen, bevor sie signieren. Das geht über bestehende Interoperabilitäts‑Schemata hinaus und bewegt sich in Richtung Chain‑Abstraktion: Der Nutzer interagiert nur mit Flare, das Protokoll führt überall sonst aus. In diesem Stadium startet PMW mit Unterstützung für XRPL.

Die beiden arbeiten als eine Fähigkeit: Aktionen auf externen Chains von Flare ausführen, mit dem Nachweis, dass die Aktion stattgefunden hat. PMW führt die Aktion aus und FDC V2 liefert den Nachweis. Wie Flare 2.0 sagte, stützt jedes Anwendungsmodell von PMW auf den Flare Data Connector, um zu beweisen, dass eine bestimmte Transaktion erfolgt ist. Deshalb dienen drei der vier Start‑Attestation‑Typen von FDC V2 PMW. FDC V2 ist kein separates Produkt, das zufällig neben PMW ausgeliefert wird. Doch FDC V2 ist mehr als PMWs Nachweisschicht. Es ist eine eigene, verbesserte Version des Flare Data Connector — schnellere, einzeln bearbeitete Attestationen, die jedem, der auf Flare baut, zur Verfügung stehen, nicht nur FCC.

Was es eröffnet

PMW und FDC V2 sind die ersten Anwendungen, nicht das eigentliche Ziel. Sie laufen auf einem Framework, dessen Mechanismen von Anfang an vorhanden sind. Beim Start bedienen die TEE‑Maschinen ausschließlich diese Systemanwendungen, und die Möglichkeit für Entwickler, eigene TEE‑Maschinen zu deployen und benutzerdefinierte Erweiterungen zu registrieren, ist in den Contracts vorhanden, wird jedoch später im Bootstrap‑Zeitraum aktiviert. Sobald das geschieht, definiert ein Entwickler eine Erweiterung mit einem Befehl‑empfangenden Contract, einem Satz registrierter TEE‑Maschinen und einer Liste unterstützter Code‑Versionen und betreibt seine eigene vertrauliche Logik mit denselben Relay‑und‑Sign‑Garantien, die PMW sichern.

PMWs erste Aufgabe ist das klarste Beispiel dafür, warum das wichtig ist. Es ermöglicht einem Protokoll auf Flare, ein XRPL‑Konto direkt zu halten und zu betreiben, was die Grundlage dafür bildet, XRP in DeFi auf Flare zu bringen, ohne dass Nutzer ein Bridging durchführen müssen. Das ist eine Anwendung des Frameworks. Die gleiche Maschinerie — versiegelte Schlüssel, genehmigter Code, signierte und verifizierte Ergebnisse — erbt jede zukünftige Erweiterung. Songbird ist der Ort, an dem das End‑zu‑End‑auf dem Flare‑Mainnet bewiesen wird.

Entwickler finden die vollständige technische Aufschlüsselung, Architektur und schritt‑für‑schritt Build‑Anleitungen im Flare Dev Hub.

Abstimmungsdetails

Kündigungsfrist: 29. Juni – 5. Juli 2026

Abstimmungszeitraum: 6. Juli – 13. Juli 2026

Siehe den STP.13‑Vorschlag unter: https://proposals.flare.network/STP/STP_13.html

FTSOBest-Analyse

Was wird hinzugefügt?

• Drei On‑Chain‑Vertragsgruppen auf Songbird:
  1. TEE-Registrierungs‑ und Verifikationsverträge – verwalten Maschinenidentitäten und prüfen signierte Ergebnisse.
  2. Daten‑Provider‑Relayer‑Verträge – jeder Provider betreibt einen FDC V2‑Verifier und einen Relay‑Client; eine gewichtete Mehrheit an Signaturen ist erforderlich, bevor ein TEE ausgeführt wird.
  3. Extension‑Framework‑Verträge – stellen die von der Compute‑Schicht genutzte API zum Empfang von Anweisungen bereit.
• TEE‑Maschinen – vertrauliche VMs, die zunächst auf Google Confidential Compute gehostet werden und von der Flare Foundation betrieben werden.
• FDC V2 – ersetzt das 90‑Sekunden‑Batch‑Attestationsmodell durch per‑Request‑Signaturen und reduziert die Latenzzeit für Beweise.
• Protocol Managed Wallets (PMW) – ermöglichen einem Flare‑Protokoll, ein XRPL‑Wallet zu besitzen und davon zu spendieren, wobei Schlüssel innerhalb der TEEs erzeugt und das Signieren vom Relayer‑Konsens gesteuert wird.
• Reward‑Pool – finanziert von der Flare Foundation und Attestationsgebühren; keine neue Token‑Emission in der Bootstrapping‑Phase.

Technische Abhängigkeiten

• Trusted Execution Environments – Hardware‑Isolation ist entscheidend für die Schlüssel‑Vertraulichkeit und die Erstellung von Beweisen.
• Flare Data Connector (FDC) V2 – stellt die Proof‑of‑Execution‑Schicht bereit; seine Verifier‑Server müssen von Daten‑Anbietern betrieben werden.
• Weighted‑majority‑Relayer‑Konsens – stellt sicher, dass ein Befehl nur ausgeführt wird, wenn genügend Anbieter signiert haben, und verknüpft die Ausführung mit Flare’s Konsens.
• Google Confidential Compute (initially) – dient als erster TEE‑Operator; zukünftige Diversifizierung erfordert zusätzliche Hardware‑Partner und Vertrags‑Updates.

Praktische Implikationen

• Für Nutzer: Vermögenswerte auf XRPL können in Flare‑DeFi‑Apps genutzt werden, ohne dass Bridging nötig ist; private Schlüssel verlassen nie das TEE, wodurch die Angriffsfläche reduziert wird.
• Für Entwickler: das Dev‑Hub (https://dev.flare.network/fcc/overview) enthält die komplette Architektur und Schritt‑für‑Schritt‑Anleitungen. Ersteller können später ihre eigenen TEE‑Maschinen und benutzerdefinierten Erweiterungen registrieren, sobald die Bootstrapping‑Phase die Vertragsschalter aktiviert.
• Für das Netzwerk: Die neuen Verträge erhöhen die Anzahl der On‑Chain‑Aufrufe (Registrierung, Attestations‑Verifizierung, Reward‑Verteilung). Das Design hält jedoch den Gasverbrauch ähnlich wie bei bestehenden FDC‑Aufrufen, da jede Anfrage einzeln und nicht in großen Batches verarbeitet wird.

Risiko‑Betrachtungen

• Die Sicherheit des Systems hängt von der Korrektheit der TEE‑Hardware und der Ehrlichkeit des Relayer‑Sets während des Bootstrappings ab. Jede Kompromittierung der anfänglichen Google Confidential Compute‑Knoten könnte frühe Beweise beeinträchtigen.
• Die Weighted‑Majority‑Regel erfordert ein zuverlässiges Set von Daten‑Anbietern; unzureichende Teilnahme könnte die Ausführung zum Stillstand bringen.
• Audits befinden sich noch im Zwischenschritt. Endgültige Sicherheitsprüfungen erfolgen nach der Songbird‑Validierung, sodass ein Audit‑Risiko‑Fenster bestehen bleibt.

Roadmap‑Hinweise (keine Verpflichtungen)

• Nach erfolgreicher Validierung auf Songbird plant Flare einen Main‑Net‑Rollout mit denselben Verträgen.
• Zukünftige Phasen ermöglichen es Erstellern, eigene TEE‑Operatoren und Erweiterungen zu deployen, und erweitern die Unterstützung über XRPL hinaus.

Wesentliche Erkenntnisse

1. FCC bringt vertrauliche, überprüfbare Compute‑Funktionen zu Flare via TEEs.
2. PMW bietet on‑chain‑gesteuerte Wallets auf XRPL und überbrückt die Lücke der Asset‑Emission.
3. FDC V2 bietet schnellere, per‑Request‑Attestationen und verbessert die Proof‑Latenz für alle Anwendungen.
4. Der Start ist ein Canary‑Test; sein Erfolg wird die Main‑Net‑Einführung und die breitere Flare 2.0‑Vision informieren.