Was ist Flare (FLR)? Eine einfache Erklärung

Was ist Flare (FLR)?

Flare ist eine Layer-1-Blockchain. Das bedeutet, dass Flare ein eigenständiges Blockchain-Netzwerk ist, auf dem Transaktionen verarbeitet werden und Anwendungen laufen können.

Flare wurde vor allem entwickelt, um Smart Contracts Zugriff auf Daten außerhalb des eigenen Netzwerks zu geben. Denk zum Beispiel an Preisdaten oder Informationen über Transaktionen auf anderen Blockchains.

Das Netzwerk ist EVM-kompatibel. EVM steht für Ethereum Virtual Machine. Weil Flare damit kompatibel ist, können Entwickler viele Tools und Smart Contracts nutzen, die auch im Ethereum-Ökosystem verwendet werden.

Der native Token von Flare heißt FLR. Native bedeutet, dass FLR der eigene Token des Netzwerks ist. Du nutzt FLR unter anderem, um Transaktionskosten zu bezahlen und das Netzwerk über Staking bei der Absicherung zu unterstützen.

FLR wird auch für Governance verwendet. Damit können Tokenhalter über bestimmte Vorschläge und Änderungen innerhalb des Netzwerks abstimmen.

Für einige Funktionen kann FLR eins zu eins in WFLR umgewandelt werden. Das nennt man Wrapping. Du besitzt dann weiterhin denselben zugrunde liegenden Wert, aber in einer Form, die innerhalb bestimmter Smart Contracts genutzt werden kann.

WFLR kann zum Beispiel für die Delegation an Dataprovider des Flare Time Series Oracle, kurz FTSO, verwendet werden. Das sind Parteien, die Daten wie Preisdaten an das Netzwerk liefern. Bei der Delegation gibst du deine Tokens nicht ab, sondern weist nur deine Stimmkraft so einem Dataprovider zu.

Alle Transaktionskosten, die in FLR bezahlt werden, werden verbrannt. Das bedeutet, dass diese Tokens dauerhaft aus dem Umlauf genommen werden.

Ein wichtiger Bestandteil von Flare ist also, externe Daten für Smart Contracts verfügbar zu machen. Dadurch können Apps auf Flare Informationen nutzen, die nicht direkt auf der Flare-Blockchain selbst liegen.

Wichtigste Erkenntnisse

• Flare ist eine EVM-kompatible Layer 1 für Smart Contracts und externe Daten.
• FLR ist der native Token für Transaktionskosten, Staking, Governance und Delegation.
• FTSO liefert unter anderem Preisdaten für Apps auf Flare.
• FDC hilft Smart Contracts, Daten von außerhalb von Flare zu verifizieren.
• Validator-Staking und FTSO-Delegation sind zwei verschiedene Arten, wie FLR genutzt werden kann.

Wie funktioniert Flare?

Flare besteht aus zwei wichtigen Umgebungen. Auf der C-Chain laufen Smart Contracts und Anwendungen. Die P-Chain wird für Staking und die Verwaltung von Validatoren genutzt.

Flare verwendet Proof of Stake, um das Netzwerk abzusichern. Validatoren sperren FLR und helfen dabei, Transaktionen und Blöcke zu überprüfen.

Das Konsensprotokoll von Flare heißt Snowman++. Dieses Protokoll stammt aus der Avalanche-Familie und sorgt dafür, dass sich Validatoren über die Reihenfolge und Gültigkeit von Transaktionen und Blöcken einigen können.

Neben dieser Netzwerkschicht hat Flare das Flare Systems Protocol. Dieses System wird für die eingebauten Datenprotokolle von Flare verwendet, darunter das Flare Time Series Oracle, kurz FTSO, und den Flare Data Connector, kurz FDC.

Dafür liefern Dataprovider Daten an. Ihr Einfluss innerhalb des Systems hängt unter anderem von WFLR ab, das an sie delegiert wurde, und von FLR, das über Validatoren auf der P-Chain gestakt wurde. FTSO-Delegation und Staking sind dabei zwei verschiedene Prozesse.

Flare (FLR) Überblick

Welche Rolle spielt FLR innerhalb von Flare?

FLR ist der native Token des Flare-Netzwerks und hat verschiedene Funktionen innerhalb des Ökosystems.

Zunächst wird FLR verwendet, um Transaktionskosten auf Flare zu bezahlen. Diese Kosten werden verbrannt, wodurch das verwendete FLR dauerhaft aus dem Umlauf genommen wird.

FLR spielt außerdem eine Rolle bei der Absicherung des Netzwerks. Validatoren sperren FLR auf der P-Chain, und andere Nutzer können FLR an einen Validator delegieren. Im Gegenzug können sie Staking-Belohnungen erhalten.

FLR wird auch für Governance und für die Delegation an Dataprovider innerhalb des Flare-Netzwerks verwendet. Für diese Anwendungen kann FLR eins zu eins in WFLR gewrappt werden.

FLR hat damit eine Rolle bei Transaktionen, Netzwerksicherheit, Daten und der Verwaltung von Flare.

Wie funktioniert die Dateninfrastruktur von Flare?

Flare hat Datenprotokolle, die direkt in das Netzwerk eingebaut sind. Zwei wichtige Bestandteile sind das Flare Time Series Oracle, meist FTSO genannt, und der Flare Data Connector, kurz FDC.

FTSO liefert Daten, die sich regelmäßig ändern, etwa Preisdaten. Apps und Smart Contracts auf Flare können diese Daten nutzen, ohne selbst direkt Daten aus externen Quellen sammeln zu müssen.

FTSOv2 verwendet unter anderem Block-Latency-Feeds und Anchor-Feeds.

Block-Latency-Feeds sind schnelle Preisfeeds, die ungefähr bei jedem neuen Block aktualisiert werden. Flare erzeugt ungefähr alle 1,8 Sekunden einen Block. Das bedeutet, dass neue Preisdaten sehr regelmäßig verfügbar sein können. Für jedes Update wird eine Auswahl von Dataprovidern ausgewählt, die Daten liefern.

Anchor-Feeds arbeiten langsamer und sind dafür gedacht, zu festen Zeitpunkten zu einem gemeinsamen Wert zu kommen. Dataprovider senden ihre Daten zunächst ein, ohne sie direkt öffentlich zu machen. Später geben sie bekannt, welchen Wert sie eingereicht haben. Das nennt man Commit-Reveal und es hilft zu verhindern, dass Provider ihre Eingabe anpassen, nachdem sie die anderer gesehen haben.

Danach werden alle gültigen Eingaben zu einem Wert zusammengeführt. Flare verwendet dafür einen gewichteten Median. Das bedeutet, dass nicht jeder Dataprovider den gleichen Einfluss hat. Provider mit mehr Stimmkraft gehen stärker in die Bestimmung des endgültigen Werts ein.

Anchor-Feeds werden alle 90 Sekunden aktualisiert. Sie dienen auch als Kontrollpunkt für die schnelleren Block-Latency-Feeds und helfen dabei, sie langfristig genau zu halten.

Dataprovider spielen also eine wichtige Rolle innerhalb von FTSO. Nutzer können die Stimmkraft ihres WFLR an einen oder zwei dieser Provider delegieren. Die Tokens bleiben dabei in der eigenen Wallet. Das nennt man FTSO-Delegation.

Der Flare Data Connector hat eine andere Aufgabe. FDC macht es möglich, Daten von außerhalb von Flare zu verifizieren, bevor ein Smart Contract sie nutzt. Das können zum Beispiel Transaktionen und Zahlungen auf anderen Blockchains sein.

Nach der Verifizierung werden die Daten in einem Merkle Tree verarbeitet. Nur die Merkle Root wird auf Flare gespeichert. Mit einem Merkle Proof kann ein Smart Contract danach prüfen, ob bestimmte Daten Teil des verifizierten Datensatzes waren.

Welche Rolle spielen FTSO und FAssets innerhalb von Flare?

FTSO sorgt dafür, dass Apps auf Flare Zugriff auf Daten wie Preisfeeds haben. Diese Daten können dann von anderen Teilen des Flare-Ökosystems genutzt werden.

Ein Beispiel dafür sind FAssets. FAssets sind überbesicherte Repräsentationen von Assets anderer Blockchains. Überbesichert bedeutet, dass mehr Wert als Sicherheit hinterlegt wird, als der Wert der ausgegebenen FAssets beträgt.

FAssets sollen Assets aus Netzwerken mit eingeschränkter Smart-Contract-Funktionalität innerhalb von Apps auf Flare nutzbar machen.

Aktuell ist FXRP, die FAsset-Version von XRP, live. Das FAssets-System ist so konzipiert, dass es künftig auch andere Assets ohne umfangreiche Smart-Contract-Funktionalität unterstützen kann.

Ein FAsset ist nicht dasselbe wie das ursprüngliche Asset auf der eigenen Blockchain. FXRP ist zum Beispiel ein Token auf Flare, der XRP repräsentiert. Nutzer können FXRP innerhalb des Flare-Ökosystems verwenden und ihn über das FAssets-Protokoll wieder gegen XRP auf dem XRP Ledger eintauschen.

Für die Funktionsweise von FAssets sind mehrere Bestandteile von Flare nötig. FTSO liefert Preisdaten und FDC hilft dabei, Transaktionen auf der zugrunde liegenden Blockchain zu verifizieren. Außerdem wird Sicherheit hinterlegt, um die ausgegebenen FAssets zu decken.

Die Sicherheit besteht aus verschiedenen Arten von Collateral. Agents verwenden dafür genehmigte Tokens, während FLR als zusätzliche Sicherheit in Collateral Pools genutzt werden kann.

FAssets hängen damit von mehreren Teilen des Systems ab und sind nicht dasselbe wie das direkte Halten des ursprünglichen Assets.

Wie funktionieren Staking und Delegation bei Flare?

Validator-Staking und FTSO-Delegation sind zwei verschiedene Möglichkeiten, FLR innerhalb des Flare-Netzwerks zu nutzen.

Beim Validator-Staking sperrst du FLR für einen bestimmten Zeitraum, um einen Validator auf der P-Chain zu unterstützen. Validatoren helfen dabei, das Netzwerk abzusichern und Transaktionen und Blöcke zu verarbeiten.

Um FLR direkt an einen Validator zu delegieren, brauchst du mindestens 50.000 FLR. Diese Tokens werden mindestens 14 Tage lang gesperrt. Für den Betrieb eines eigenen Validators ist ein Self-Bond von mindestens 1 Million FLR nötig, mit einer Mindestlaufzeit von 60 Tagen.

Belohnungen für Staking werden pro Reward Epoch festgelegt und hängen unter anderem von der Leistung des gewählten Validators ab. Auf dem Flare Mainnet dauert eine Reward Epoch ungefähr 3,5 Tage.

FTSO-Delegation funktioniert anders. Dafür wrappst du FLR auf der C-Chain eins zu eins zu WFLR. Anschließend kannst du die Stimmkraft deines WFLR an einen oder zwei FTSO-Dataprovider delegieren.

Du überträgst deinen WFLR dabei nicht an den Dataprovider. Die Tokens bleiben in deiner eigenen Wallet, während die delegierte Stimmkraft für den gewählten Provider zählt.

FTSO-Dataprovider können einen Teil der Belohnungen als Gebühr einbehalten. Wie viel ein Delegator erhält, hängt daher unter anderem von der Leistung des Providers und der festgelegten Gebühr ab.

Wie ist Flare entstanden?

Flare wurde 2019 von Hugo Philion, Sean Rowan und Naïri Usher gegründet. Das Projekt konzentrierte sich anfangs darauf, Smart-Contract-Funktionalität und externe Daten für Anwendungen rund um verschiedene Blockchain-Netzwerke verfügbar zu machen.

Die Mainnet-Genesis von Flare fand am 14. Juli 2022 statt. Das Netzwerk begann damals zunächst in einer Beobachtungsphase. Das öffentliche Token Distribution Event, bei dem FLR an Nutzer verteilt wurde, folgte am 9. Januar 2023.

Bei der Genesis, dem ersten Block des Netzwerks, wurden 100 Milliarden FLR geschaffen. FLR hat 18 Dezimalstellen.

Nach einer Änderung der Token-Verteilung über FIP.01 wurde ein Teil von FLR über FlareDrops auf 36 Monate verteilt. Diese Verteilung endete am 30. Januar 2026.

Das Ende von FlareDrops bedeutete nicht, dass alle Belohnungen aufhörten. Protokollbelohnungen für unter anderem Staking und FTSO-Delegation bestehen danach weiterhin.

Was sind die Vorteile von Flare?

• Smart Contracts und Daten in einem Netzwerk: Flare kombiniert eine EVM-kompatible Umgebung mit eingebauten Protokollen für Preisfeeds und die Verifizierung externer Daten.

• Schnelle und periodische Preisfeeds: FTSOv2 bietet Block-Latency-Feeds, die ungefähr bei jedem neuen Block aktualisiert werden, und Anchor-Feeds, die regelmäßig einen gemeinsamen Wert bestimmen. Apps können dadurch verschiedene Arten von Preisdaten nutzen.

• Verifizierbare Daten von anderen Blockchains: FDC kann Daten von unterstützten Netzwerken verifizieren, darunter Bitcoin, Dogecoin, XRP Ledger und Ethereum.

• Nutzung von Assets aus anderen Netzwerken: FAssets sind darauf ausgelegt, überbesicherte Repräsentationen von Assets anderer Blockchains innerhalb von Apps auf Flare nutzbar zu machen.

• Delegation ohne Übertragung von Tokens: Bei der FTSO-Delegation kannst du die Stimmkraft deines WFLR an Dataprovider delegieren, während die Tokens in deiner eigenen Wallet bleiben.

Was sind die Nachteile von Flare?

• Zusätzliche Schritte beim Validator-Staking: Für direktes Staking an einen Validator muss FLR von der C-Chain auf die P-Chain verschoben werden. Nach Ablauf muss FLR wieder zurück auf die C-Chain geschickt werden, wenn du die Tokens dort nutzen möchtest.

• Hohe Hürde für Validator-Delegation: Für die direkte Delegation an einen Validator sind mindestens 50.000 FLR nötig, und es gilt eine minimale Lock-up-Phase von 14 Tagen. Das macht diese Form des Stakings für kleinere Halter weniger zugänglich.

• FAssets hängen von mehreren Komponenten ab: Das System nutzt unter anderem Agents, Sicherheit, Preisfeeds und Daten der zugrunde liegenden Blockchain. Probleme mit einer dieser Komponenten können die Funktionsweise von FAssets beeinflussen.

• Abhängigkeit von Dataprovidern: FTSO und FDC nutzen mehrere Dataprovider, um Daten zu liefern und zu verifizieren. Anwendungen, die diese Daten nutzen, bleiben dadurch von der Verfügbarkeit und dem reibungslosen Betrieb dieser Systeme abhängig.

• Delegationsbelohnungen sind nicht fest: Die Rendite der FTSO-Delegation hängt unter anderem von der Leistung und der Gebühr des gewählten Dataproviders ab.

Fazit

Flare ist eine EVM-kompatible Layer-1-Blockchain, die Smart Contracts mit einer eingebauten Infrastruktur für externe Daten kombiniert. FLR ist der native Token des Netzwerks und wird für Transaktionskosten, Staking, Governance und Delegation verwendet.

Zwei wichtige Bestandteile sind FTSO und FDC. FTSO liefert unter anderem Preisdaten, während FDC Smart Contracts ermöglicht, Daten von außerhalb von Flare zu verifizieren. FAssets bauen darauf auf, indem sie Repräsentationen von Assets anderer Netzwerke innerhalb von Flare nutzbar machen.

Dem stehen auch Risiken und zusätzliche Schritte gegenüber. Validator-Staking erfordert eine Lock-up-Phase und die Verschiebung von FLR auf die P-Chain. FTSO-Delegation und FAssets sind außerdem von verschiedenen Komponenten und Teilnehmern innerhalb des Flare-Netzwerks abhängig.