Die STP.06- und FIP.06-Governance-Vorschläge werden bald zur Abstimmung freigegeben. Sie beinhalten Aktualisierungen, die erforderlich sind, um die Kapazität von Flare Time Series Oracle (FTSO) sowohl für das Flare- als auch das Songbird-Netzwerk zu skalieren.

Die FTSO

Das FTSO ist ein System, das auf Flare läuft und dezentralisierte Datenfeeds an Dapps auf Flare liefert, ohne sich auf zentralisierte Anbieter zu verlassen. Derzeit sind nur Datenfeeds für Kryptowährungspreispaare verfügbar, zum Beispiel BTC USD. Die unterstützten Feeds sind ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, FLR (auf Flare), SGB (auf Songbird), LTC, MATIC, SOL, USDC, USDT, XDC, XLM, und XRP.

Unabhängige Infrastrukturanbieter, darunter Google Cloud, Ankr und Figment, spielen eine wichtige Doppelrolle im System: Sie sind sowohl für die Sicherung des Netzwerks als Validierer als auch für die Bereitstellung von Daten für die in Flare verankerten Orakel verantwortlich.

Um ein sicheres, dezentralisiertes System zu erreichen, rufen sie Daten aus externen Quellen, wie zentralen und dezentralen Börsen, ab und stellen sie dem FTSO-System zur Verfügung. Diese Informationen werden entsprechend der Stimmkraft jedes Anbieters (Menge der von der Gemeinschaft delegierten Token) gewichtet, und es wird ein gewichteter Median berechnet, um die endgültige Schätzung zu erhalten.

FTSO-Skalierbarkeit

Der aktuelle FTSO (v1) ist hauptsächlich als On-Chain-Smart-Contract implementiert. Wir bieten derzeit alle 180 Sekunden Aktualisierungen für 18 Datenfeeds an.

Zur Unterstützung neuer Anwendungsfälle, die schnellere Aktualisierungen und eine größere Vielfalt an Daten erfordern, war eine skalierbarere Neugestaltung des Systems erforderlich. Mit der FTSO-Skalierung können Datenanbieter alle 90 Sekunden bis zu 1000 Datenfeeds (Kryptowährungspreispaare, Aktienkurse, Wetterdaten und mehr) bereitstellen.

Das vorgeschlagene neue Konzept ist sparsamer, da die Berechnungen außerhalb der Kette durchgeführt werden und nur eine zusammengefasste Darstellung aller Ergebnisse der Datenanbieter, ein so genannter Merkle-Root-Hash, auf der Kette gespeichert wird. Eine solche Darstellung macht die On-Chain-Daten leichter und skalierbarer als die Durchführung von Berechnungen auf der Kette und die Speicherung aller einzelnen Preise auf der Kette.

Das verbesserte Protokoll ermöglicht die Bereitstellung von mehr Datenfeeds. Zunächst werden Feeds für etwa 25 Kryptowährungspreispaare hinzugefügt. Es ist auch geplant, schrittweise weitere Krypto-Assets wie Aktien, Anleihen, Rohstoffe und Devisen aufzunehmen, je nach Nachfrage der Entwickler.

FTSO Scaling sollte nicht mit FTSO Fast Updates verwechselt werden, die Gegenstand eines zukünftigen Governance-Vorschlags sein werden. FTSO Fast Updates wird es Dapps ermöglichen, Daten bei Bedarf mit 1-2 Block Latenz (ca. 1-3 Sekunden) anzufordern und zu bezahlen. Wenn die Governance-Vorschläge von der Flare-Community genehmigt werden, wird die Kombination von FTSO Scaling und FTSO Fast Updates unsere Vision für FTSO v2 liefern.

Die Rolle der Flare-Gemeinschaft

Die Flare-Gemeinschaft wird sich weiterhin auf dieselbe Weise mit dem FTSO beschäftigen. Diese Änderungen sind technische Änderungen. Sie können weiterhin an FTSO-Datenanbieter delegieren und Delegationsprämien beanspruchen, wie Sie es zuvor getan haben.

Die Rolle des Datenanbieters

Mit der FTSO-Skalierung liefern die Datenanbieter weiterhin nützliche Informationen wie Preispaare. Daten, die zu weit vom Median entfernt sind (Ausreißer), werden weiterhin entfernt. Die daraus resultierenden Datenschätzungen werden belohnt und auf der Kette zur Verfügung gestellt. Die Datenanbieter verwenden weiterhin einen Commit- und Reveal-Prozess, der es ermöglicht, alle Daten zu übertragen. Die Commit-Phase ermöglicht die Übermittlung von Schätzungen, ohne dass einige Datenanbieter durch Einsicht in die Schätzungen anderer Datenanbieter schummeln können. In der Reveal-Phase können die Datenanbieter zur Überprüfung auf die übermittelten Schätzungen zugreifen.

Wird die FTSO-Skalierung genehmigt, werden zwei neue Phasen eingeführt: Die Signierungsphase und die Finalisierungsphase.

In der Sign-Phase filtern die Datenanbieter Enthüllungen heraus, die nicht mit Commits übereinstimmen. Nur gültige Enthüllungen werden für die Berechnung der Medianwerte und der Belohnungen verwendet. Die Ergebnisse werden durch einen Code ("hashed") dargestellt und von den Datenanbietern signiert.
In der Finalisierungsphase kann jedes Unternehmen, sobald eine ausreichende Anzahl von Unterschriften eingereicht wurde, diese sammeln und an den stimmberechtigten Smart Contract übermitteln. Es wird geprüft, ob die vorgeschlagenen Unterschriften kumulativ die erforderliche Gewichtsschwelle erreichen (mindestens 50 % des Gesamtgewichts aller zugelassenen Datenanbieter). Wenn dies der Fall ist, wird die Merkle-Wurzel auf dem Abstimmungsvertrag für eine bestimmte Abstimmungsrunden-ID veröffentlicht. Sie steht dann allen anderen Smart Contracts zur Verfügung, die die Daten zur Überprüfung der Berechnungsergebnisse verwenden können.

Belohnungen aufteilen

Wie in FTSO (v1) werden Datenanbieter weiterhin Belohnungen für die Übermittlung von Daten erhalten, die nahe am Medianwert liegen. Wenn der Vorschlag der Verwaltung angenommen wird und die FTSO-Skalierung vollständig umgesetzt ist, wird der größte Teil der insgesamt verfügbaren Belohnungen für die Bereitstellung von FTSO-Daten, nämlich 80 %, weiterhin an Datenanbieter verteilt, die dies erreichen.

Wenn die FTSO-Skalierung vollständig implementiert ist, wird sie auch die Einreichung von Signaturen in der Signierphase und die Auslösung der Finalisierung in der Finalisierungsphase belohnen. Für die Einreichung von Signaturen in der Sign-Phase werden 10 % der Belohnungen für die Datenbereitstellung an Datenanbieter ausgeschüttet, die eine einzige, gültige Signatur einreichen. Für die Auslösung der Finalisierung in der Finalisierungsphase können bis zu fünf Entitäten die Finalisierung durchführen: die ersten fünf, die die Schwellengewichtung erfolgreich erfüllen. 10 % der verfügbaren Datenbereitstellungsprämien gehen an diese Datenanbieter.

Sanktionen

FTSO Scaling bestraft Datenanbieter für Reveal Withholdings oder Double-Signing:

Offenlegung von Vorenthaltungen: Datenanbieter müssen in der Lage sein, zu überprüfen, ob der Hash der offengelegten Daten mit dem Hash der übertragenen Daten übereinstimmt. Wenn das Reveal für einen Commit ausgelassen wird oder nicht übereinstimmt, wird dies als Reveal Withholding bezeichnet und mit einer Strafe belegt.
Doppelunterzeichnung: Die Abgabe von ungültigen Unterschriften oder Unterschriften für mehr als ein Ergebnis im selben Wahlgang wird als Doppelunterschrift bezeichnet und bestraft.

In beiden Fällen beträgt die Strafe das 30-fache des erwarteten relativen Anteils des Datenanbieters an den Rewards in dieser Abstimmungsrunde und wird vom Gesamtbetrag der Rewards am Ende der Reward-Epoche abgezogen. Der Höchstbetrag, der abgezogen werden kann, entspricht dem gesamten Reward des Datenanbieters in der Epoche. Der abgezogene Betrag wird verbrannt.

Einsatz-Phasen

Die Skalierung des FTSO-Systems auf bis zu 1000 Dateneinspeisungen wird eine Reihe umfangreicher Aktualisierungen erfordern. Um der Flare Foundation Zeit zum Testen und den Datenanbietern Zeit zur Anpassung an die Änderungen zu geben, wird die Aktualisierung, sofern sie genehmigt wird, aus einer Testphase, einer Betaphase und einer Abschreibungsphase bestehen.

Während dieser Phasen werden aktuelle und aktualisierte Datenanbieter nebeneinander bestehen. Aktuelle Datenprovider sind diejenigen, die den existierenden FTSO (v1) Code verwenden und aktualisierte Datenprovider sind diejenigen, die den neuen Code verwenden, der FTSO Scaling beinhaltet. 70% der Gesamtinflation von Flare geht immer noch an die Belohnungen für die FTSO-Datenbereitstellung, aber es wird unter den Datenanbietern in der folgenden Weise aufgeteilt werden:

Erprobungsphase: Während dieser Phase ändert sich die Zuteilung der Prämien nicht: Die derzeitigen Datenanbieter erhalten weiterhin 100 % der unter ihnen verteilten Prämien für die Bereitstellung von FTSO-Daten, während die neuen Datenanbieter keine Prämien erhalten.
Beta-Phase: Während dieser Phase wird die Flare Foundation den Inflation-Vertrag so aktualisieren, dass die derzeitigen Datenanbieter 50% der gesamten FTSO-Datenbereitstellungsprämien erhalten und die neuen Datenanbieter die anderen 50%. Zu diesem Zeitpunkt werden alle Datenanbieter in der Lage sein, ihre Belohnungen einzufordern. Nehmen wir zum Beispiel an, dass wir während der Beta-Phase 100 FLR für Belohnungen haben. Die derzeitigen Datenanbieter erhalten 50 FLR und die neuen Datenanbieter erhalten die folgende Verteilung: 40 für die mediane Nähe, 5 für die Einreichung einer gültigen Signatur und 5 für den Beitrag zur Finalisierung.
Abschreibungsphase: Während dieser Phase wird die Flare Foundation den Inflationsvertrag erneut aktualisieren, so dass nur die aufgewerteten Datenanbieter Belohnungen erhalten werden. Mit dem Inflationsbetrag im obigen Beispiel, 100 FLR, erhalten die aufgewerteten Datenanbieter daher die volle Verteilung unter sich: 80 für den Medianwert, 10 für eine gültige Signatur und 10 für den Beitrag zur Finalisierung.