Wir freuen uns, heute unsere detaillierten Pläne für den Einsatz des Flare-Netzwerks veröffentlichen zu können. Diese Pläne können vollständig erforscht werden, indem Sie in unsere White Paper eintauchen, die das Netzwerk und sein natives Token, Spark (hier) und die vertrauenslose Integration von XRP mit Flare (hier) abdecken. Die Papiere sind in Entwurfsform und es wird keine Änderungen zwischen jetzt und dem Tag Flare live geht. Es dürfen keine Änderungen vorgenommen werden, die wesentlich von der nachstehenden Übersicht abweichen. In diesem Beitrag möchten wir hervorheben, was wir für die wichtigsten Aspekte von Flare halten. Ein minimal technischer Überblick über jede wichtige Komponente wird in den folgenden Wochen veröffentlicht, beginnend später in dieser Woche mit einer Komplettlösung von Flares vertrauensloser Integration von XRP, FXRP. Schnall dich an!

(Ein TL; DR befindet sich am Ende dieses Beitrags.)

Was ist Flare und warum bauen wir es?

Flare existiert, um zwei Schlüsselprobleme zu lösen:Erstens und von unmittelbarer Bedeutung für den Aufbau unserer Branche ist, dass 75% des Wertes, der in der öffentlichen Blockchain vorhanden ist, derzeit nicht vertrauenslos mit intelligenten Verträgen verwendet werden kann.Zweitens, und zwar sowohl kurzfristig als auch langfristig, gibt es potenzielle Probleme bei der Implementierung der Skalierung für intelligente Vertragsnetzwerke. Die Mehrheit der neuen Netzwerke verwendet Proof of Stake oder seine Varianten. Diese Protokolle leiten die Netzwerksicherheit von ihrem nativen Token ab.Das unmittelbare Problem, das dem Proof of Stake innewohnt, besteht darin, dass das Konsensdesign alternative Verwendungen des nativen Tokens noch nicht sicher zulässt. Wenn ein Token-Inhaber durch die Bereitstellung von Sicherheiten zur Schaffung einer stabilen Münze eine höhere Rendite erzielen kann (und ohne die Möglichkeit einer Kürzung), als dies durch Abstecken möglich ist, werden sie dies wahrscheinlich als wirtschaftliche Rationalisten tun. Dies lenkt Token vom Staking ab und kannibalisiert die Sicherheit des Netzwerks. (Ein sehr aufschlussreiches Papier zu diesem Thema ist hier .) Wir vermuten, dass dies vielleicht der Hauptgrund dafür ist, dass Ethereum trotz vergleichsweise höherer Transaktionskosten und weitaus geringerem Transaktionsdurchsatz bei DeFi immer noch führend ist.Ein längerfristiges Problem ist, dass, wenn ein Proof-of-Stake-Netzwerk an Nutzung gewinnt und der darauf aufbauende Wert steigt, der Wert des Staking-Tokens steigen muss oder das Netzwerk unsicher wird. Dies ist großartig für Investoren in den Token, aber schlecht für Leute, die Dezentralisierung Teil der Mainstream-Art der Geschäftstätigkeit sehen wollen. Warum? Denn damit der Token-Wert, der das Netzwerk sichert, steigt, muss Kapital von einer anderen Verwendung abgezweigt werden, um das Token zu kaufen. Wenn intelligente Vertragsnetzwerke, die Proof of Stake verwenden, zur allgegenwärtigen Methode der Geschäftstätigkeit werden sollten, würde das Ausmaß der Umleitung von Kapital, das von anderen Bemühungen benötigt wird, nur um den auf diesen Netzwerken aufgebauten Wert zu sichern, die Kosten des Handels undurchführbar hoch machen. Aus diesem Grund ist es äußerst unwahrscheinlich. Proof of Stake und Varianten können den Transaktionsdurchsatz skalieren, aber vorhandene Implementierungen können den Wert nicht skalieren. Unserer Meinung nach ist Proof of Stake eher eine Notlösung als eine Lösung.

Wie löst Flare diese Probleme?

Flare ist im Kern eine neue Art der Skalierung intelligenter Vertragsplattformen, die die Sicherheit nicht mit dem Wert ihres Tokens verknüpft. Flare benötigt weiterhin ein Token für den Betrieb des Netzwerks, hauptsächlich um Spam-Transaktionen abzuschrecken. Das Token von Flare heißt Spark. Da Spark keine Auswirkungen auf die Netzwerksicherheit hat, ist es gut geeignet, die vertrauenslose Verwendung von Nicht-Turing-Complete-Token mit Smart Contracts zu ermöglichen.Flare ist das weltweit erste Turing Complete Federated Byzantine Agreement (FBA) Netzwerk. Knoten führen das Avalanche Consensus-Protokoll mit einer Schlüsselanpassung an die FBA-Consensus-Topologie aus. FBA ist als Konsenstopologie insofern einzigartig, als es Sicherheit erreicht, ohne auf wirtschaftliche Anreize angewiesen zu sein, die hochwertige und risikoreiche Anwendungsfälle beeinträchtigen können. Eine Kritik an reinem FBA ist, dass es zu fragilen Strukturen der einzelnen Knoten führt, was Topologieszenarien ermöglicht, in denen ein Ausfall eines einzelnen Knotens einen netzwerkweiten Ausfall verursachen kann. Aus diesem Grund wird eine bestimmte Einstellung von FBA, die als UNL-Topologie (Unique Node List) bezeichnet wird, priorisiert, die die Klarheit und Benutzerfreundlichkeit betont und gleichzeitig die Open-Membership-Eigenschaft von FBA beibehält. Die prozentuale Überlappung der UNL ist ein von der Governance definierter Parameter, wobei eine geringere Überlappung die Eigenschaft der offenen Mitgliedschaft des Netzwerks verbessert. Das Flare-Netzwerk nutzt die Ethereum Virtual Machine (EVM), mit der das Netzwerk Turing Complete Smart Contracts ausführen kann.

Beim Netzwerkstart wird auf Flare ein Protokoll aufgebaut, um die vertrauenslose Ausgabe, Verwendung und Rücknahme von XRP auf Flare sicher zu ermöglichen. Dieses Protokoll wird FXRP genannt. XRP wird sicher und vertrauenslos zu FXRP auf Flare, gesichert durch Flares natives Token Spark. XRP existiert jetzt effektiv in einem Turing-vollständigen Netzwerk und sobald es dort ist, ist eine vertrauenslose Interoperabilität mit anderen Netzwerken möglich, sowohl durch Interoperabilitätsprotokolle wie Cosmos und Polkadot als auch mit Ethereum über gut definierte Bridge-Protokolle. Kurz: Flare kann als intelligente Vertragsplattform für XRP oder als vertrauenslose Pipeline für XRP zu anderen Netzwerken verwendet werden.Darüber hinaus ist die allgemeine Methodik von FXRP auf jedes Nicht-Turing-Complete-Token erweiterbar, und die Möglichkeit, zu entscheiden, welche anderen Token unterstützt werden sollen, und dann die Mittel dazu zu erweitern, ist in die Systeme und die Governance des Netzwerks integriert.Flare vereint den Wert der Nicht-Turing-Complete-Token mit der transformativen Kraft intelligenter Verträge in einem Netzwerk, das sowohl den Wert als auch den Transaktionsdurchsatz skalieren kann.

FXRP-Übersicht

Die Komplexität, XRP auf den Markt zu bringen, besteht darin, dass es für einen intelligenten Vertrag in einer öffentlichen Blockchain keine Möglichkeit gibt, eine Adresse im XRP-Ledger zu steuern. Der Grund dafür ist, dass Smart Contracts derzeit keine angemessene Möglichkeit haben, einen geheimen Schlüssel wirklich geheim zu speichern. Um XRP nur mit Code auf Flare zu bringen, müsste eine Gruppe von Teilnehmern mit einer Multi-Signatur-Adresse zusammenkommen, die sie gemeinsam kontrollieren, wobei, wenn k von n Parteien eine Transaktion unterzeichnen, die Transaktion autorisiert ist. Jeder Benutzer eines Assets, der von dieser Multisig-Adresse ausgegeben wird, müsste dann dieser Sammlung von Benutzern vertrauen, und somit wäre das Asset weder vertrauenslos noch dezentralisiert.FXRP ermöglicht es einem XRP-Inhaber (einem Originator), sein XRP sicher an eine Reihe von Adressen (Agenten genannt) im XRP-Ledger zu senden. Die FXRP Smart Contracts auf Flare geben dann den Originator FXRP auf Flare aus, der 1: 1 mit XRP konvertierbar und mit Spark gesichert ist. Wenn ein Inhaber von FXRP es gegen XRP (einen Erlöser) einlösen möchte, sendet er es an die FXRP Smart Contracts auf Flare zurück. Die Agenten senden dann den XRP an die Adresse des Einlösers im XRP-Ledger. Wenn die Agenten diese Einlösung nicht schnell genug abschließen, erhält der Einlöser den Wert seines XRP zuzüglich eines Betrags zum Ausgleich der Transaktionskosten für den Rückkauf des XRP.

Mit FXRP ist kein zentraler Vermittler erforderlich.

FXRP funktioniert wie folgt:

Besitzer von Flares nativem Token, Spark, können ihre Token an eine Sammlung von Smart Contracts auf Flare senden, die als FXRP-System bezeichnet werden. Benutzer, die dies tun, stellen Sicherheiten für das FXRP-System bereit. Sie werden Agenten genannt. Nennen wir einen der Agenten Bob. Es wird viele Agenten im FXRP-System geben.Angenommen, Bob hat 5000 Spark-Token in das FXRP-System eingefügt. In diesem Beispiel können aktuell 10 Spark Token für 1 XRP Token gekauft werden. Das FXRP-System verlangt ein Collateral Ratio von 2,5, was bedeutet, dass ein Agent dem System jederzeit das 2,5-fache des Wertes des FXRP zur Verfügung gestellt haben muss, den das System ihnen in Spark-Token zugewiesen hat. FXRP wird hier als 1: 1 mit XRP bewertet. Daher ermöglicht Bobs 5000 Spark Token dem System, 200 FXRP auszugeben.

Wenn jemand, sagen wir Alice, FXRP erstellen möchte, sendet er eine Transaktion an das FXRP-System mit einer festen Gebühr von 0.1% des Wertes von XRP, den er in FXRP prägen möchte. Alice wird als Urheberin bezeichnet. Die Transaktion teilt dem FXRP-System auch mit, an welche Adresse das FXRP bei Flare gesendet werden soll, sobald es geprägt wurde, und von welcher Adresse das XRP im XRP-Ledger stammt. Wenn im FXRP-System verfügbare Kapazität vorhanden ist, werden Sicherheiten zur Sicherung des zu erstellenden FXRP-Betrags für einen bestimmten Zeitraum gegen die bevorstehende Transaktion von Alice gesperrt. Auf diese Weise muss Alice Bob nicht vertrauen. Im Gegenzug wird eine Reihe von Anweisungen für Alice generiert, die ihr mitteilen, an welche Adresse (Bobs Adresse) das XRP im XRP-Ledger gesendet werden soll und welcher letzte Ledger-Index verwendet werden soll. Wenn das System nicht in der Lage ist, den gewünschten Betrag an FXRP auszugeben, wird Alice die Gebühr zurückerstattet.

Alice sendet dann den korrekten Betrag an XRP plus eine Erstellungsgebühr in XRP an Bobs Adresse im XRP-Ledger. Die Erstellungsgebühr macht den Großteil des Geldes aus, das Bob für die Sperrung seiner Spark-Sicherheiten verdient. Flare beobachtet diese Transaktion mithilfe eines Systems namens State Connector, das in Abschnitt 2 des Flare-Whitepapers (und Gegenstand eines zukünftigen Blogbeitrags) definiert ist. Der FXRP wird dann vom System geprägt und an Alices nominierte Adresse auf Flare geliefert.

Das 2,5-fache Collateral Ratio muss jederzeit eingehalten werden. Wenn der Preis von XRP gegenüber Spark steigt, so dass der Wert von Bobs Sicherheiten unter 2 fällt.5-fache des ausgegebenen FXRP, dann hat Bob eine begrenzte Zeit, um entweder mehr Spark-Token als Sicherheit hinzuzufügen oder FXRP-Token zu kaufen und einzulösen, um sein Sicherheitsverhältnis wieder in Einklang zu bringen. Angenommen, 200 FXRP-Token werden gegen Bobs 5000 Spark-Token ausgegeben, und der Preis für XRP / Spark steigt auf 12. Bob muss nun entweder 1000 Spark zum System hinzufügen oder 33.34 FXRP kaufen und einlösen, um seine Aufteilung der ausgegebenen FXRP auf 166.66 zu reduzieren.

Wenn Bob keinen Zugang zu zusätzlichen Spark-Token hat, ist es für ihn finanziell nicht belastend, den von seiner Adresse unterstützten FXRP-Saldo zu reduzieren. Bobs Sicherheiten ermöglichten es dem FXRP-System, 200 FXRP-Token auszugeben, wobei Bob 200 XRP-Token auf dem XRP-Ledger erhalten hat. Wenn Bob also kein zusätzliches Kapital zum Kauf von Spark-Token hat, kann er entweder ausreichend XRP für FXRP an einer Börse verkaufen, so dass er mindestens 33,34 FXRP einlösen kann, oder in einer rein dezentralen Umgebung bleiben, wenn es andere Agenten im FXRP-System gibt mit ausreichenden überschüssigen Sicherheiten in Er kann genügend FXRP prägen und sofort einlösen. Das zweite Szenario verschiebt die Verpflichtung im Wesentlichen auf den Rest des Systems. Wenn Bob nichts unternimmt und gegenüber dem Collateral Ratio in Verzug bleibt, werden Bobs Sicherheiten automatisch um den Betrag des FXRP versteigert, der in diesem Fall 200 beträgt. Bob behält alle verbleibenden Sicherheiten nach dieser Operation.

Nehmen wir an, Bob hat sich entschieden, zusätzliche Spark als Sicherheit hinzuzufügen. Jetzt, einige Zeit später, möchte Alice, die alle 200 ausgegebenen FXRP besitzt, den gesamten Betrag zurück in das XRP-Ledger einlösen. Alice macht einfach eine Transaktion mit dem FXRP-System, das den FXRP an das System sendet und ihm mitteilt, welche Adresse sie gutschreiben möchte. Das System gibt dann eine Reihe von Anweisungen an Bob, die ihm sagen, wie viel XRP zu senden und wo zusammen mit zwei XRP-Ledger-Nummer Fristen, bis zu denen die Transaktion abgeschlossen sein muss. Wenn Bob die Transaktion innerhalb der ersten Frist abschließt, sind seine Sicherheiten vollständig freigeschaltet. Wenn Bob innerhalb der ersten Frist versagt, aber bis zur zweiten erfolgreich ist, wird ihm eine kleine Strafgebühr berechnet und der Rest seiner Sicherheiten wird freigeschaltet. Die Strafgebühr wird verbrannt.

Wenn Bob die Transaktion nicht innerhalb der zweiten Frist abschließt, wird dies als Rückzahlungsfehler bezeichnet. Alice wird dann mit Spark-Token zum Wert ihres eingelösten XRP plus einer 1% igen Erhöhung zur Deckung der Transaktionskosten für den Rückkauf des XRP entschädigt, die aus Bobs Sicherheiten stammen. Von Bobs verbleibenden Sicherheiten werden 50% als Strafe verbrannt und die anderen 50% an ihn zurückgegeben. Alice kann dann Ersatz-XRP an einer Börse kaufen. Alternativ können Sie, vorausgesetzt, es gibt andere Agenten auf Flare mit ausgegebenem FXRP und Personen, die es verkaufen möchten, mehr FXRP auf Flare kaufen und gegen diese Agenten einlösen.

Spark und abhängige Anwendungen

FXRP ist das erste Beispiel für etwas, das wir als Spark Dependent Application (SDA) bezeichnen. Ein SDA ist definiert als eine Anwendung, die in ihrer Konstruktion eine Kombination aus Spark für Sicherheiten, der Flare Time Series Oracle und Spark Token Holders für Governance verwendet. Jedes dieser Elemente ist völlig optional und eine Anwendung kann mit Flare arbeiten, indem sie nur mit Spark interagiert, um die Transaktionskosten zu bezahlen. Beispielsweise verwendet FXRP Spark als Sicherheit, die Flare Time Series Oracle für den XRP / Spark-Preis und den Spark Token Ownership Set für die Governance über bestimmte Parameter wie die FXRP-Erstellungsgebühr und das Collateral Ratio. Das SDA-Modell soll eine Vorlage für die Erweiterung jeder der drei Komponenten auf eine beliebige Anzahl von Anwendungen bereitstellen. Die Verwendung von Spark als Sicherheit für alle Anwendungen ist unkompliziert, Das wichtigste Element war zu überlegen, wie eine sichere Oracle-Methodik über mehrere Zeitreihen hinweg erstellt werden kann.

Flare Time Series Oracle

Der Besitz des Spark-Tokens ermöglicht den Beitrag zum Flare Time Series Oracle (FTSO). Der Zweck des FTSO besteht darin, genaue Schätzungen von Daten über Flare aus Off-Chain unter Beibehaltung der Dezentralisierung zu erstellen. Das FTSO ist so strukturiert, dass es viele Schätzungen einzelner Zeitreihen liefert. Der XRP / Spark-Preis ist ein Beispiel für eine einzelne Zeitreihe.

Jede vom FTSO ausgegebene Zeitreihe wird in der Regel zwei Gruppen von Teilnehmern haben: die ersten sind Spark-Token-Inhaber und die zweiten sind die Inhaber des abhängigen Anwendungstoken, das als F-Asset bezeichnet wird. In der FXRP-Anwendung ist das F-Asset das FXRP-Token selbst. Für eine komplexere Anwendung wie eine Derivateanwendung, bei der die Anwendung mehrere Zeitreihen erfordert, kann das F-Asset eher einem ausgegebenen Governance-Token ähneln.

Für jede Zeitreihe fordert das FTSO jede relevante Gruppe von Teilnehmern auf, eine Schätzung abzugeben. Spark-Inhaber geben Schätzungen für alle Zeitreihen an, und F-Asset-Inhaber geben Schätzungen nur für die Zeitreihen an, die sich auf ihr F-Asset beziehen. Diese Schätzungen werden dann wie in Abschnitt 4 des Flare-Whitepapers definiert verarbeitet und vom System ausgegeben.

Der Anreiz für F-Asset-Inhaber, dem System Daten zur Verfügung zu stellen, ist die Sicherheit ihrer Anwendung. Inhaber von Spark-Token erhalten Anreize durch das Potenzial, etwas zu verdienen, das als Oracle-Belohnung bezeichnet wird. Dies ist eine Menge von Spark-Token, die vom System geprägt werden. Die Oracle-Belohnung ist eine jährliche Rate, die gleichmäßig über jeden FTSO-Schätzzeitraum aufgeteilt wird. Wenn die Rate beispielsweise 10% beträgt, es 365-Schätzungen in einem Jahr und eine Startnummer von Spark-Token von 100 gibt, werden 10-Spark in 1-Jahr erstellt und ~ 0.03-Spark pro Tag geprägt und belohnt. Mitwirkende von Spark Token können diese Belohnung verdienen, indem sie Daten beitragen, die als „korrekt“ gelten. Die genauen Mechanismen sind im Weißbuch dargelegt. Wichtig ist, dass alle Spark-Token-Inhaber implizit im System eingesetzt werden, als ob sie die Belohnung entweder durch Nichtbeitrag oder durch „falsche“ Schätzungen nicht verdienen, verlieren sie an Wert für Token-Inhaber, die belohnt werden. Dies ist Flares Version von Block Rewards.Das FTSO wird initiiert, um die folgenden Preise für XRP / Spark, USD / Spark, BTC / Spark und XLM / Spark bereitzustellen. Nur XRP / Spark wird zu Beginn ein entsprechendes F-Asset haben. Zusätzliche Zeitreihen und die damit verbundenen F-Assets können im Rahmen des Governance-Prozesses vorgeschlagen und akzeptiert werden.

Delegation

Das FTSO wird in Wirklichkeit alle paar Sekunden Schätzungen abgeben. Nicht jeder Spark-Inhaber möchte oder kann Hardware ausführen, um zum FTSO beizutragen, und separat sind sie möglicherweise nicht daran interessiert, für die Netzwerk-Governance zu stimmen. Daher können die Stimmen für beide Verantwortlichkeiten vom Token selbst getrennt und separat an andere Parteien delegiert werden. Die Delegation kann jederzeit storniert werden, und wenn ein Token von einer Adresse an eine andere übertragen wird, wird die Delegation automatisch storniert, sodass die Stimmrechte mit dem Token einhergehen. Der Mechanismus ermöglicht es SDAs wie FXRP auch, Spark-Stimmen an den ultimativen Eigentümer zurückzudelegieren, der diese Stimmen dann erneut an Entitäten delegieren kann, die er in seinem Namen abstimmen möchte. Wenn Bob also 5000 Spark-Token in der FXRP-Anwendung hat, werden die Stimmen dieser Token an eine von Bob angegebene Adresse delegiert. Wenn Bob möchte, dass ein dedizierter Datenanbieter in seinem Namen zum FTSO beiträgt, kann Bob seine Stimmen für das FTSO erneut an den Datenanbieter delegieren. Wichtig ist, dass Bob sich nicht entscheiden muss, ob er Spark verdient, indem er Sicherheiten für die FXRP-Anwendung bereitstellt und möglicherweise die Belohnung vom FTSO erhält. Jede SDA, die Spark-Token für ihre zugrunde liegenden Eigentümer nicht verfügbar macht, kann das Delegierungsverfahren implementieren, sofern in der Anwendung definiert ist, wer der zugrunde liegende Eigentümer ist.

Governance & Stiftung

Flare wird vollständig von Spark-Token-Inhabern durch Abstimmung geregelt. SDAs können optional beantragen, von Spark-Token-Inhabern verwaltet zu werden.Bestimmte Entscheidungen können automatisiert in der Kette getroffen werden, z. B. die Änderung der Transaktionskosten, der Oracle-Belohnungssatz oder, wenn man FXRP als SDA betrachtet, die Änderung des Collateral Ratio und der Erstellungsgebühr. Andere Entscheidungen wie das Hinzufügen einer neuen Zeitreihe zum FTSO und die Verknüpfung seines vorgeschlagenen F-Asset, das Ändern von Netzwerkkonsensusparametern oder komplexere langfristige Aktualisierungen erfordern eine Codeänderung. Das Flare-Weißbuch enthält einen Vorschlag, ein Entwicklungs- und Testregime für manuelle Änderungen, die von Spark-Token-Inhabern initiiert und abgestimmt werden können. Um diesen Prozess zu implementieren und die vereinbarten Änderungen durchzuführen, wird es eine Flare Foundation geben. Die Stiftung wird eine gemeinnützige Organisation sein, die in den kommenden Monaten gegründet werden soll. Es ist verantwortlich für 5 Schlüsselbereiche: Zuschüsse, Investitionen, Forschung und Entwicklung, Bildung, Öffentlichkeitsarbeit und Partnerschaften.

Es ist die Forschungs- und Entwicklungsfunktion, die es der Foundation ermöglicht, ein integraler Bestandteil des Netzwerkaktualisierungsprozesses zu sein, sogar so weit zu gehen, vorgeschlagene Netzwerkcodeänderungen zu analysieren, zu melden und dann zu erstellen, zu testen und bereitzustellen.

Die Stiftung muss sehr transparent sein und darf kein Geld verschwenden. Jährlich werden zwei Berichte über ihre Tätigkeiten und Ausgaben erstellt und veröffentlicht. Die Stiftung soll nur die Richtung von den Spark-Token-Inhabern nehmen und nicht die Agenda festlegen. Als solches darf es: in keiner Weise zum FTSO beitragen, seine Spark-Bestände als Sicherheit für eine Anwendung im Netzwerk einsetzen und seine Spark-Bestände nicht zur Abstimmung bei Governance-Abstimmungen verwenden. Es darf seine Spark-Token nicht anderen zuweisen, um dies zu tun. Darüber hinaus wird in die Verfassung der Stiftung die Verpflichtung aufgenommen, dass die Stiftung ihre Aktivitäten einstellen und alle verbleibenden Token-Bestände so schnell wie möglich verbrennen muss, wenn eine Governance-Abstimmung zustimmt, dass die Stiftung keinen wirtschaftlichen Zweck mehr erfüllt.

Spark Issuance

Die beste Community, um das Asset zu besitzen, das die Verwendung von XRP mit Turing Complete Smart Contracts ermöglicht, ist die Community, die es verwenden und davon profitieren wird: XRP-Inhaber. Flare macht kein ITO. Stattdessen macht es das, was wir eine Utility-Gabel nennen. Wir glauben, es ist das erste seiner Art.Eine Gabel hat traditionell versucht, die Benutzerbasis eines bestehenden Netzwerks zu nehmen und vollständig von diesem Netzwerk abzuweichen, um normalerweise eine antagonistische Beziehung zur ursprünglichen Kette zu haben. Im Gegensatz dazu soll eine Utility-Gabel der ursprünglichen Kette wieder Wert verleihen, anstatt sich von ihr zu entfernen. Mit Flare kann XRPL das tun, was es am besten kann, schnelle Abwicklung, während XRPL intelligente Verträge und die Möglichkeit bietet, eine vertrauenslose Pipeline zu anderen Blockchains zu erstellen. Wir denken, dass dies eine wirklich leistungsstarke Kombination und ein perfektes Beispiel für Nützlichkeit ist.

100 Milliarden Spark-Token werden erstellt, um die vorhandene Menge an XRP widerzuspiegeln. Es gibt ungefähr 45 Milliarden XRP-Token, die nicht zu Ripple Labs gehören. Ziel der Verteilung ist es, dass andere XRP-Inhaber als Ripple ungefähr einen 1: 1-Betrag an Spark für ihren XRP-Besitz beanspruchen können. 45 Bn Spark wird von XRP-Inhabern beansprucht (bekannte Ripple Labs-Adressen werden entfernt). 25 Mrd. Spark gehen an Flare Networks Limited, die gewinnorientierte Organisation von Flare. 30 Mrd. Euro gehen an die Flare Foundation.Da viele XRP-Besitzer tatsächlich Börsen nutzen, um ihre XRP-Token zu halten, besteht die Möglichkeit, dass ein Inhaber von XRP, der Spark-Token beanspruchen möchte, dies möglicherweise nicht kann, da entweder die Börse den Spark beansprucht und behält sie, anstatt sie weiterzugeben, oder sie alternativ überhaupt nicht beansprucht. Damit XRP-Besitzer an der Verteilung teilnehmen können, indem sie entweder ihren Austausch unter Druck setzen, die Spark-Token zu verteilen, oder den Austausch auf einen anderen verschieben, wird der Snapshot des XRP-Ledgers zu einem Zeitpunkt erstellt, der näher am Start liegt. Eine Liste der teilnehmenden Börsen wird auf der Flare-Website veröffentlicht und regelmäßig aktualisiert. Die Snapshot-Ledger-Nummer wird auf der Website veröffentlicht, wenn der Snapshot erstellt wurde.

TL;DR

Flare ist das weltweit erste Turing Complete Federated Byzantine Agreement (FBA) Netzwerk. Es integriert die Ethereum Virtual Machine (EVM) und leitet keine Sicherheit von einem Token ab. Darüber hinaus wird ein Protokoll erstellt, um die vertrauenslose Ausgabe, Verwendung und Einlösung von XRP auf Flare sicher zu ermöglichen. Dieses Protokoll wird FXRP genannt. Die allgemeine Methodik des Protokolls und des Systems, das Flare mit anderen Netzwerken verbindet, ist auf jedes Nicht-Turing-Complete-Token erweiterbar. Eine vertrauenslose Interoperabilität mit anderen Netzwerken ist möglich, sowohl über Interoperabilitätsprotokolle wie Cosmos und Polkadot als auch mit Ethereum über klar definierte Bridge-Protokolle.Das Token von Flare, Spark, wird durch den möglicherweise ersten Utility-Fork erstellt, bei dem das Ursprungsnetzwerk, in diesem Fall das XRP-Ledger, durch einen erhöhten Nutzen profitiert. Zu Beginn des Flare-Netzwerks werden 100 Milliarden Spark-Token erstellt, von denen 45 Milliarden von bestehenden XRP-Inhabern ohne Ripple Labs beansprucht werden können. Dies spiegelt die vorhandene Menge an verteiltem XRP wider, sodass aktuelle XRP-Inhaber ungefähr 1 Spark-Token für jeden gehaltenen XRP-Token beanspruchen können. 25 Milliarden Token gehen an die Entwickler Flare und 30 Milliarden Token an eine gemeinnützige Stiftung namens Flare Foundation. Inhaber von Spark-Token können eine Rendite auf ihre Spark-Token erzielen, indem sie Spark-Token als Sicherheiten festlegen, um die vertrauenslose Ausgabe und Rücknahme von FXRP zu sichern, und indem sie Daten zum Flare Time Series Oracle beitragen. Diese Funktionen konkurrieren nicht miteinander.

Der Spark-Token wird zur Steuerung des Netzwerks durch Abstimmung verwendet. Mit Ausnahme von Zuschüssen und Investitionen zur Entwicklung von Flare übernimmt die Stiftung die technische Leitung von den Eigentümern der Spark-Token. Eine Schlüsselrolle der Stiftung besteht darin, Upgrades und Änderungen am Netzwerk durchzuführen, die durch Governance-Abstimmung vereinbart wurden und ohne Codeänderung nicht implementiert werden können. Wichtig ist, dass in die Verfassung der Stiftung eine Satzung geschrieben wird, dass die Stiftung abgewickelt und alle von der Stiftung gehaltenen Spark-Token verbrannt werden müssen, wenn die Spark-Token-Inhaber zustimmen, dass ihre Existenz für das Netzwerk nicht mehr vorteilhaft ist.Flare vereint den Wert der Nicht-Turing-Complete-Token mit der transformativen Kraft intelligenter Verträge in einem Netzwerk, das sowohl den Wert als auch den Transaktionsdurchsatz skalieren kann.

Antworten auf zwei Fragen:

Erstellt Spark einen Proof of Stake durch die Hintertür?

Nur ausgegebene Token, die Sicherheiten erfordern, wie FXRP, sind mit Spark gesichert. Das Netzwerk verwendet Spark nicht aus Sicherheitsgründen, um zu einem Konsens zu gelangen.

Wir hatten (was wir denken) sehr starke Konzepte für eine auf USD lautende stabile Münze, aber es erforderte ein umfangreiches Re-Engineering der Ethereum Virtual Machine, was den Start verzögert hätte und unvorhersehbare Auswirkungen auf die zukünftige Kompatibilität mit der EVM hätte. Spark, wie es strukturiert ist, bietet sowohl der XRP-Community als auch dem XRP-Ledger einen viel größeren Nutzen und Nutzen.