Das FTSOv2 ist ein Upgrade des Flare Time Series Oracle mit regelmäßigeren Updates, besserer Leistung, einer größeren Auswahl an Datenfeeds und hochfrequenten Updates. Es ist ein Sprungbrett zur Verwirklichung der Vision von Flare als Blockchain für Daten.

In diesem Blogbeitrag stellen wir die Vorteile des neuen Protokolls vor und fassen die technischen Optimierungen zusammen, die es möglich gemacht haben. Unser neuestes Whitepaper bietet eine detailliertere Übersicht über die Mechanismen und Vorteile des FTSOv2-Designs.

Die Blockchain für Daten erweitert ihren Anwendungsbereich

Flare's aktualisiertes Orakel, FTSOv2, stellt einen bedeutenden Fortschritt im On-Chain-Datenzugriff für Unternehmen dar, die im dezentralen Finanzwesen (DeFi) tätig sind, wie z.B. Kredit- oder Handels-Dapps. Durch die Verbesserung des Datenzugriffs und die Senkung der Nutzungskosten stellen die Orakel von Flare eine deutliche Verbesserung gegenüber bestehenden Orakel-Technologien dar und setzen einen neuen Maßstab für Dezentralisierung und Erschwinglichkeit im Datenaustausch.

Flare konzentriert sich auf vollständig dezentralisierte Orakel, um Anwendungen zu unterstützen, die sowohl auf Flare als auch auf anderen Ketten aufgebaut sind. Durch die Verankerung von Orakeln in der Flare-Blockchain profitieren sie von der inhärenten Sicherheit, die durch die vollständige Dezentralisierung geboten wird, was wiederum den kritischen Bedarf an zuverlässigen, dezentralen Datenfeeds in DeFi und dem weiteren Web3-Raum anspricht.

Nachdem Flare eine solide Grundlage entwickelt hat, erweitert es nun seine Datenkapazitäten, um ein breiteres Spektrum von Vermögenswerten, wie Aktien und Rohstoffe, einzubeziehen und die Latenzzeit, mit der diese Feeds geliefert werden können, zu verringern. Dies ist eine Vorbereitung auf weitere Fortschritte bei der Verbindung von Daten über Blockchains hinweg und zwischen Web2 und Web3.

Diese Initiativen zielen darauf ab, die Sicherheit zu erhöhen, die Kosten zu senken und die Entwicklungsprozesse zu vereinfachen, was dem Ziel des Netzwerks entspricht, einen sicheren und effizienten kettenübergreifenden Datenaustausch zu ermöglichen.

Dezentralisierung des Oracle-Zugriffs

Orakel sind ein entscheidender Baustein von DeFi. Sie sichern riesige Mengen an Werten, indem sie genaue Off-Chain-Daten in Echtzeit für On-Chain-Smart Contracts bereitstellen. Alle großen Orakel sind von einer begrenzten Anzahl von Datenanbietern abhängig, und die größten Orakel arbeiten effektiv in einem Netzwerk mit Zugangsberechtigung. Dies untergräbt die Kernvision des dezentralen Finanzwesens und setzt die Nutzer im Extremfall katastrophalen Verlusten aus, aber auch schleichenden, aber ebenso bösartigen Verlusten durch Marktmanipulation.

FTSOv2 ist die Lösung von Flare für den Aufbau eines Orakels, das hochfrequente Aktualisierungen ermöglicht und gleichzeitig eine breite Palette von Datenfeeds unterstützt und die Dezentralisierung aufrechterhält.

Im Gegensatz zu einigen heute auf dem Markt erhältlichen Lösungen, bei denen ein Datenfeed mit nur 5 Knoten gesichert werden kann, garantiert FTSOv2, dass jeder Datenfeed durch das gesamte Netz, bestehend aus 100 Knoten, gesichert wird. Diese Garantien machen es für Entwickler und Nutzer wesentlich sicherer und einfacher, sich auf FTSOv2-Kursfeeds zu verlassen, ohne die spezifischen Eigenheiten des jeweiligen Feeds verstehen zu müssen.

Häufig verfolgen Orakel einen genehmigungspflichtigen Ansatz und nehmen nur große Institutionen und Handelsunternehmen als Datenanbieter in ihr Netzwerk auf, was die Dezentralisierung des Netzwerks zugunsten der Latenz beeinträchtigt. Flare geht keine solchen Kompromisse ein - der Onboarding-Prozess der verschiedenen Datenanbieter ist völlig genehmigungsfrei und wird durch offene Delegationen von Nutzern des Flare-Netzwerks unterstützt. Darüber hinaus befinden sich andere Orakel, die vielleicht das Potenzial eines dezentralisierten Proof of Stake (PoS) Layer 1 wie Flare erkannt haben, derzeit in einem frühen Stadium der Umstellung auf PoS. Allerdings haben diese Netzwerke im Vergleich zu Flare einen geringen Prozentsatz an nativen Token, die für die Sicherheit des Orakels eingesetzt werden; etwa 7% im Vergleich zu 66% bei Flare.

Upgrade des Flare Time Series Oracle

Die aktuelle Iteration des Flare Time Series Oracle, FTSOv1, aktualisiert eine Sammlung von 18 Preis-Feeds alle 3 Minuten. Die neue Iteration des FTSO verbessert diesen Prozess, indem sowohl die Häufigkeit der Aktualisierungen als auch die Anzahl der verfügbaren Feeds skaliert werden. Außerdem werden jetzt zwei verschiedene Arten von Aktualisierungen unterstützt:

• Anker Updates, die regelmäßig aktualisierten FTSO-Datenfeeds, die Schätzungen von mehreren Anbietern wie in FTSOv1 kombinieren.
• Stream Aktualisierungen, eine neue Funktion, die eine schnelle Aktualisierungstechnik nutzt, um inkrementelle Aktualisierungen der Datenfeeds in jedem Block zu veröffentlichen.

Die Aktualisierungen der Verankerung werden durch eine Reihe von Verbesserungen des Abstimmungsprozesses unterstützt, die eine bessere Leistung ermöglichen, ohne die Schlüsselkonzepte des Prozesses zu verändern. Die Verbesserungen wurden so konzipiert, dass die wünschenswerten Merkmale des FTSO erhalten bleiben: Dezentralisierung, Genauigkeit und Sicherheit. Wie im ursprünglichen Entwurf wird jeder Datenfeed-Wert weiterhin aus individuellen Schätzungen von 100 Datenanbietern im Flare-Netzwerk aggregiert. Die geänderte Anreiz- und Kappungsstruktur hindert die Anbieter daran, die aggregierten Werte böswillig zu beeinflussen, und ermutigt die Anbieter, genaue Schätzungen zu ermitteln.

Die neuen Stream-Werte werden aus einer Abfolge von inkrementellen Aktualisierungen pro Block gebildet, die einen schnelleren Zugriff auf Aktualisierungen mit einem einfacheren Aggregationsmechanismus ermöglichen. Der Stream-Feed stützt sich auf ein Verfahren, das als schnelle Aktualisierung bekannt ist und bei dem rotierende, per Los ausgewählte Anbieter jeweils inkrementelle Aktualisierungen der Daten übermitteln. Die Größe dieser Inkremente kann durch die Finanzierung durch die Community geändert werden, so dass Stream-Updates nach Bedarf funktionieren: Dapps und andere Nutzer zahlen eine Gebühr für den Zugriff auf immer genauere Datenfeeds.

Sowohl die Verbesserungen der Anker-Updates als auch die Einführung von Stream-Updates wurden so konzipiert, dass sie den Gasverbrauch des Protokolls nicht beeinträchtigen, d.h. dass das FTSO weiterhin nachhaltig ist und nicht zu viel des verfügbaren Gasdurchsatzes des Fackelnetzes verbraucht.

Zusammenfassend lässt sich sagen, dass der FTSOv2 in dreierlei Hinsicht besser ist als die vorherige Version:

• Anker-Updates werden alle 90 Sekunden bereitgestellt, wodurch sich die Latenzzeit zwischen der Veröffentlichung von Datenwerten halbiert.
• Die Anzahl der unterstützten Bewertungen hat sich drastisch erhöht, wobei anfangs über 50 Datenfeeds unterstützt wurden und das Design für eine Skalierung auf 1000 Feeds ausgelegt ist.
• Stream-Updates werden zwischen den Anker-Updates zur Verfügung gestellt, so dass ein optionaler Zugang zu Updates mit höherer Frequenz möglich ist, was jedoch zu Lasten der Genauigkeit gehen kann.

Oracle Access auf Flare im Maßstab

Der Gesamtablauf einer FTSO-Runde bleibt unverändert: 100 Datenlieferanten schätzen den Wert der einzelnen Dateneinspeisungen, deren einzelne Schätzungen dann mit Hilfe eines gewichteten Median-Algorithmus zu einer Reihe von endgültigen Werten zusammengefasst werden. Auch hier verbraucht der verbesserte Prozess kein unhaltbares Gas, obwohl er mehr Dateneinspeisungen und schnellere Aktualisierungen unterstützt. Wie funktionieren also diese kostengünstigen Verbesserungen? Das Geheimnis liegt darin, dass schwerfällige Berechnungen aus der Kette ausgelagert werden und nur die Überprüfungsinformationen in der Kette veröffentlicht werden. Auf diese Weise wird die harte Arbeit, die für die Durchführung der Berechnungen erforderlich ist, auf die Anbieter verlagert, wodurch die Berechnungen auf der Kette minimiert werden. Die Anbieter laden dann Verifizierungsdaten in die Kette hoch, um zu beweisen, dass die Off-Chain-Berechnungen korrekt durchgeführt wurden. Eine Abstimmungsrunde des FTSOv2 läuft also wie folgt ab:

• Jeder Anbieter berechnet seine Schätzung für jeden der unterstützten FTSO-Datenfeeds und lädt in die Kette einen einzelnen Hash hoch, der seine individuellen Schätzungen festlegt.
• Jeder Anbieter legt seine Liste der Kostenvoranschläge offen und lädt die Informationen in die Kette hoch.
• Außerhalb der Wertschöpfungskette berechnen die Anbieter den Gesamtwert für jeden Feed in der Abstimmungsrunde.
• Die Anbieter verpacken die Liste der Medianwerte in einen einzigen Hash-Wert und laden diesen Hash-Wert zusammen mit einer Signatur über den Hash-Wert in die Kette hoch.
• Sobald genügend Signaturen mit demselben Hash hochgeladen wurden, bestimmt dieser Hash die endgültigen Werte für die Dateneinspeisungen der Runde, die nun z. B. in intelligenten Verträgen verwendet werden können.

Aus dem Flussdiagramm geht hervor, wie das neue FTSO-Konzept den Gasverbrauch minimiert: Die meisten kostspieligen Berechnungen wurden ausgelagert und liegen in der direkten Verantwortung der Anbieter. Die Speicherkosten werden dadurch minimiert, dass die Ergebnisse dieser Berechnungen nach Möglichkeit in einer komprimierten, gehashten Form in die Kette hochgeladen werden. Durch diese beiden Optimierungen ist die FTSOv2-Neugestaltung in der Lage, eine höhere Geschwindigkeit und einen größeren Erfassungsbereich zu unterstützen, ohne dass dabei unüberschaubare Gaskosten entstehen.

Gewichte und Obergrenzen: Gleichgewicht zwischen Dezentralisierung und Genauigkeit

Der FTSO nimmt Eingaben von 100 Anbietern entgegen und gibt für jede Runde Werte aus, die auf der Aggregation dieser Schätzungen zu einem gewichteten Medianwert basieren. Für die Zwecke des FTSO entspricht das Gewicht eines Anbieters der Menge an umhüllten FLR (WFLR), die er entweder selbst angesammelt hat oder die ihm von anderen Nutzern des Flare-Netzwerks übertragen wurde. Der aggregierte Wert für jeden Feed ist dann ein gewichteter Median der Anbieterschätzungen: Schätzungen von Anbietern mit höherem Gewicht haben einen größeren Einfluss auf den aggregierten Preis als die von kleineren Anbietern, da Anbieter mit höherem Gewicht in der Vergangenheit qualitativ bessere Datenschätzungen abgegeben haben.

Um jedoch zu verhindern, dass einzelne Anbieter einen zu großen Einfluss auf eine Runde haben und die Dezentralisierung des Protokolls beeinträchtigen, legen wir eine Obergrenze von 2,5 % für das maximale Gewicht eines einzelnen Anbieters fest. Jeder Anbieter, dessen Gewicht diese Obergrenze überschreitet, wird bei der Berechnung des Medians mit 2,5% des Gewichts berücksichtigt, wobei das überschüssige Gewicht auf alle Anbieter verteilt wird. Für das Unterschriftsverfahren ist ein kombiniertes Gewicht von 50 % oder mehr der Anbietergewichtung erforderlich, damit ein Ergebnis endgültig ist.

Schnelle Updates: Aktualisierungen mit geringer Latenzzeit auf Abruf

Das FTSOv2-Design unterstützt nicht nur Aktualisierungen von bis zu 1000 Datenfeeds alle 90 Sekunden, sondern auch eine neue Funktion namens schnelle Aktualisierungen, einen zusätzlichen Datenstrom mit einem leichtgewichtigen Design, der regelmäßiger aktualisiert wird. Der Datenstrom, der mit schnellen Aktualisierungen arbeitet, unterstützt dieselben Datenfeeds wie der FTSO-Ankerfeed, aktualisiert sie aber auf eine andere Art und Weise - ein kontinuierlich aktualisierter Datenstrom anstelle periodischer Bewertungen. In jedem Block wird eine zufällige Auswahl von Anbietern getroffen, die schnelle Aktualisierungen liefern, wobei die Wahrscheinlichkeit der Auswahl proportional zu ihrem Gewicht ist. Jeder ausgewählte Anbieter sendet dann ein Inkrement für jeden Stream-Feed, das eine kleine Änderung seines Wertes darstellt; die Aggregation dieser Inkremente bestimmt den nächsten Stream-Wert. Die Größe eines einzelnen Inkrements und die Anzahl der Aktualisierungen sind Parameter, die geändert werden können, um die Volatilität des zugrundeliegenden Vermögenswerts zu einem bestimmten Zeitpunkt widerzuspiegeln, entweder durch die Verwaltung oder durch die Finanzierung der Gemeinschaft. Auf diese Weise können Dapps oder andere Nutzer, die an schnelleren Datenaktualisierungen interessiert sind, das Fast-Update-Protokoll finanzieren, um die Zuverlässigkeit des Stream Feeds zu erhöhen.

Das Diagramm veranschaulicht, wie eine fundierte Erhöhung der Parameter für die schnelle Aktualisierung, d. h. der erwarteten Anzahl von Aktualisierungen pro Block (e) und der Genauigkeit der Inkremente (p), dazu führen kann, dass die Stream-Werte dem volatilen Verhalten der realen Werte besser entsprechen als dies beim Standardverhalten der Fall wäre.

Der Hauptvorteil dieses Mechanismus ist seine Geschwindigkeit, da Aktualisierungen im Wesentlichen in jedem Block bereitgestellt werden können. Allerdings sind die Sicherheits- und Genauigkeitsgarantien des schnellen Aktualisierungsstroms weniger robust als die der Ankerwerte, da der Aggregationsprozess einfacher ist. Daher sind die Stream-Updates in erster Linie für Anwendungen gedacht, bei denen es auf aktuelle Informationen ankommt.

Lohnenswert für den FTSO

Wie bei der FTSOv1 werden die Anbieter für genaue Schätzungen und aktive Teilnahme belohnt. Die Anbieter werden auf folgende Weise belohnt, wobei sich die Höhe der Belohnungen nach dem Gewicht des Anbieters und der Bedeutung des Prozesses richtet:

• Anbieter, die genaue Angaben zu den Ankerdaten-Feeds machen, werden für die Übermittlung von Werten belohnt, die nahe am gewichteten Medianwert liegen - und da dies von größter Bedeutung ist, werden etwa 80 % der Belohnungen für die Anker-Updates für gute Übermittlungen reserviert
• Die verbleibenden Belohnungen für die Anker-Updates werden für die aktive Teilnahme an der Unterzeichnung und dem Abschluss der FTSO-Runden vergeben. Dadurch wird sichergestellt, dass das System korrekt und zeitnah funktioniert.
• Anbieter, die schnelle Aktualisierungen eingereicht haben, erhalten am Ende jedes 90-Sekunden-Fensters einen Anteil an der Genauigkeit des Datenstroms, sofern der Datenstrom eng mit dem Ankerwert für diese Runde übereinstimmt.
• Jede Teilnahme an schnellen Aktualisierungen wird belohnt, um die Anfangsinvestitionen in die Infrastruktur für schnelle Aktualisierungen zu fördern, unabhängig von der Genauigkeit. Diese Belohnungen können später wieder abgeschafft werden, wenn der Stream-Feed besser etabliert ist.

Neben den Belohnungen für die Anbieter werden die Nutzer, die ihre WFLR an einen Anbieter delegiert haben, für die Delegierung an erfolgreiche Anbieter belohnt. Jedem Anbieter werden Belohnungen im Verhältnis zu seinem Gewicht zugewiesen, wobei ein Teil dieser Belohnungen an die Delegierenden weitergegeben wird, und zwar im Verhältnis zu dem Anteil am Gewicht des Anbieters, den jede Delegation erbracht hat, abzüglich einer prozentualen Gebühr, die die Anbieter für ihre Dienste erheben.

Schlussfolgerung

Die Einführung von FTSOv2 ist ein wesentlicher Bestandteil der Bestrebungen des Netzwerks, Daten zu demokratisieren, indem sie leichter zugänglich, kostengünstiger und dezentraler gemacht werden. In diesem Blog-Beitrag haben wir die Verbesserungen im Design von FTSO v2 zusammengefasst, die eine breitere Palette von Dateneinspeisungen ermöglichen, die Abstände zwischen den Aktualisierungen verkürzen und die wünschenswerten Sicherheits- und Dezentralisierungsfunktionen von FTSO beibehalten. Das Hauptaugenmerk der Verbesserungen liegt auf der Verlagerung der Rechenlast aus der Kette, so dass der Gasverbrauch und die Latenzzeit minimiert werden. Darüber hinaus haben wir die neuartige Funktion für schnelle Aktualisierungen untersucht, die einen sekundären Stream-Feed als Ergänzung zum Anker-Feed bereitstellt, um Nutzer zu unterstützen, die einen besonderen Bedarf an schnell aktualisierten Datenfeeds haben.

Diese Verbesserungen verbessern nicht nur den Zugang zu Live-Daten mit hoher Sicherheit für dezentralisierte Finanzplattformen, sondern schaffen auch die Grundlage für ein umfassendes Framework, in dem Daten nahtlos über verschiedene Blockchain-Architekturen ausgetauscht werden können. Im Wesentlichen verkörpert die FTSOv2 das Engagement von Flare, eine symbiotische Integration zwischen konventionellen und Blockchain-basierten Daten-Ökosystemen zu ermöglichen und dadurch Unternehmen in die Lage zu versetzen, das transformative Potenzial der Blockchain-Technologie für Innovation, operative Optimierung und Expansion zu nutzen.