Qu’est-ce que Flare (FLR) ? Une explication simple

Qu’est-ce que Flare (FLR) ?

Flare est une blockchain Layer 1. Cela signifie que Flare est un réseau blockchain autonome sur lequel les transactions sont traitées et les applications peuvent fonctionner.

Flare a été développé principalement pour donner aux smart contracts accès à des données provenant de l’extérieur de son propre réseau. Pensez par exemple à des données de prix ou à des informations sur des transactions effectuées sur d’autres blockchains.

Le réseau est compatible EVM. EVM signifie Ethereum Virtual Machine. Grâce à cette compatibilité, Flare permet aux développeurs d’utiliser de nombreux outils et smart contracts également employés dans l’écosystème Ethereum.

Le token natif de Flare s’appelle FLR. Natif signifie que FLR est le token propre au réseau. Vous utilisez notamment FLR pour payer les frais de transaction et pour contribuer à sécuriser le réseau via le staking.

FLR est aussi utilisé pour la gouvernance. Cela permet aux détenteurs de tokens de voter sur certaines propositions et modifications au sein du réseau.

Pour certaines fonctions, FLR peut être converti un pour un en WFLR. On appelle cela le wrapping. Vous détenez alors toujours la même valeur sous-jacente, mais sous une forme qui peut être utilisée dans certains smart contracts.

WFLR peut par exemple être utilisé pour la délégation à des fournisseurs de données du Flare Time Series Oracle, ou FTSO. Il s’agit d’acteurs qui fournissent des données, comme des données de prix, au réseau. Dans le cadre de la délégation, vous ne cédez pas vos tokens, mais vous attribuez simplement votre pouvoir de vote à un tel fournisseur de données.

Tous les frais de transaction payés en FLR sont brûlés. Cela signifie que ces tokens sont retirés définitivement de la circulation.

Un élément important de Flare consiste donc à rendre les données externes disponibles pour les smart contracts. Les applications sur Flare peuvent ainsi utiliser des informations qui ne se trouvent pas directement sur la blockchain Flare elle-même.

À retenir

• Flare est une Layer 1 compatible EVM pour les smart contracts et les données externes.
• FLR est le token natif utilisé pour les frais de transaction, le staking, la gouvernance et la délégation.
• Le FTSO fournit notamment des données de prix pour les applications sur Flare.
• Le FDC aide les smart contracts à vérifier des données provenant de l’extérieur de Flare.
• Le staking des validateurs et la délégation FTSO sont deux façons différentes d’utiliser FLR.

Comment fonctionne Flare ?

Flare repose sur deux environnements principaux. Les smart contracts et les applications fonctionnent sur la C-Chain. La P-Chain est utilisée pour le staking et la gestion des validateurs.

Flare utilise Proof of Stake pour sécuriser le réseau. Les validateurs verrouillent des FLR et aident à vérifier les transactions et les blocs.

Le protocole de consensus de Flare s’appelle Snowman++. Ce protocole provient de la famille Avalanche et permet aux validateurs de s’accorder sur l’ordre et la validité des transactions et des blocs.

En plus de cette couche réseau, Flare dispose du Flare Systems Protocol. Ce système est utilisé pour les protocoles de données intégrés de Flare, notamment le Flare Time Series Oracle, ou FTSO, et la Flare Data Connector, ou FDC.

Des fournisseurs de données y apportent des données. Leur influence au sein du système dépend notamment du WFLR qui leur est délégué et du FLR mis en staking via les validateurs sur la P-Chain. La délégation FTSO et le staking sont donc deux processus distincts.

Aperçu de Flare (FLR)

Quel rôle joue FLR au sein de Flare ?

FLR est le token natif du réseau Flare et remplit plusieurs fonctions au sein de l’écosystème.

Tout d’abord, FLR est utilisé pour payer les frais de transaction sur Flare. Ces frais sont brûlés, ce qui retire définitivement de la circulation les FLR utilisés.

FLR joue également un rôle dans la sécurité du réseau. Les validateurs verrouillent des FLR sur la P-Chain et d’autres utilisateurs peuvent déléguer des FLR à un validateur. En échange, ils peuvent recevoir des récompenses de staking.

FLR est aussi utilisé pour la gouvernance et pour la délégation à des fournisseurs de données au sein du réseau Flare. Pour ces usages, FLR peut être wrappé un pour un en WFLR.

FLR a donc un rôle dans les transactions, la sécurité du réseau, les données et la gouvernance de Flare.

Comment fonctionne l’infrastructure de données de Flare ?

Flare dispose de protocoles de données intégrés directement au réseau. Deux éléments importants sont le Flare Time Series Oracle, généralement appelé FTSO, et la Flare Data Connector, ou FDC.

Le FTSO fournit des données qui évoluent régulièrement, comme des données de prix. Les applications et les smart contracts sur Flare peuvent utiliser ces données sans devoir collecter eux-mêmes des données directement auprès de sources externes.

FTSOv2 utilise notamment des block-latency feeds et des anchor feeds.

Les block-latency feeds sont des flux de prix rapides qui sont mis à jour à peu près à chaque nouveau bloc. Flare produit environ un bloc toutes les 1,8 secondes. Cela signifie que de nouvelles données de prix peuvent être disponibles très régulièrement. Pour chaque mise à jour, une sélection de fournisseurs de données est choisie pour fournir les données.

Les anchor feeds fonctionnent plus lentement et visent à parvenir à une valeur commune à des moments fixes. Les fournisseurs de données envoient d’abord leurs données sans les rendre publiques immédiatement. Plus tard, ils révèlent la valeur qu’ils ont soumise. Cela s’appelle commit-reveal et cela aide à empêcher les fournisseurs d’ajuster leur soumission après avoir vu celle des autres.

Ensuite, toutes les soumissions valides sont agrégées en une seule valeur. Flare utilise pour cela une médiane pondérée. Cela signifie que tous les fournisseurs de données n’ont pas le même poids. Les fournisseurs disposant de plus de pouvoir de vote comptent davantage dans la détermination de la valeur finale.

Les anchor feeds sont mis à jour toutes les 90 secondes. Ils servent aussi de point de contrôle pour les block-latency feeds plus rapides et aident à les maintenir précis sur le long terme.

Les fournisseurs de données jouent donc un rôle important au sein du FTSO. Les utilisateurs peuvent déléguer le pouvoir de vote de leur WFLR à un ou deux de ces fournisseurs. Les tokens restent alors dans leur propre wallet. Cela s’appelle la délégation FTSO.

La Flare Data Connector a une autre fonction. La FDC permet de vérifier des données provenant de l’extérieur de Flare avant qu’un smart contract ne les utilise. Il peut s’agir par exemple de transactions et de paiements sur d’autres blockchains.

Après vérification, les données sont intégrées dans un Merkle tree. Seule la Merkle root est stockée sur Flare. Grâce à une Merkle proof, un smart contract peut ensuite vérifier si certaines données faisaient partie de l’ensemble de données vérifié.

Quel rôle jouent le FTSO et les FAssets au sein de Flare ?

Le FTSO permet aux applications sur Flare d’accéder à des données comme des flux de prix. Ces données peuvent ensuite être utilisées par d’autres éléments de l’écosystème Flare.

Les FAssets en sont un exemple. Les FAssets sont des représentations surcollatéralisées d’actifs provenant d’autres blockchains. Surcollatéralisé signifie qu’une valeur de garantie supérieure à la valeur des FAssets émis est conservée en collatéral.

Les FAssets sont conçus pour rendre des actifs issus de réseaux aux fonctionnalités de smart contracts limitées utilisables dans les applications sur Flare.

À l’heure actuelle, FXRP, la version FAsset de XRP, est en ligne. Le système FAssets est conçu pour pouvoir également prendre en charge à l’avenir d’autres actifs ne disposant pas de fonctionnalités avancées de smart contracts.

Un FAsset n’est pas la même chose que l’actif d’origine sur sa propre blockchain. FXRP est par exemple un token sur Flare qui représente XRP. Les utilisateurs peuvent utiliser FXRP au sein de l’écosystème Flare et l’échanger à nouveau contre XRP via le protocole FAssets sur le XRP Ledger.

Le fonctionnement des FAssets nécessite plusieurs éléments de Flare. Le FTSO fournit des données de prix et la FDC aide à vérifier les transactions sur la blockchain sous-jacente. En outre, un collatéral est utilisé pour couvrir les FAssets émis.

Le collatéral se compose de différents types de garanties. Les agents utilisent pour cela des tokens approuvés, tandis que le FLR peut être utilisé comme collatéral supplémentaire dans des pools de collatéral.

Les FAssets dépendent donc de plusieurs éléments du système et ne sont pas la même chose que la détention directe de l’actif d’origine.

Comment fonctionnent le staking et la délégation sur Flare ?

Le staking des validateurs et la délégation FTSO sont deux façons différentes d’utiliser FLR au sein du réseau Flare.

Dans le staking des validateurs, vous verrouillez des FLR pendant une certaine période afin de soutenir un validateur sur la P-Chain. Les validateurs aident à sécuriser le réseau et à traiter les transactions et les blocs.

Pour déléguer directement des FLR à un validateur, vous avez besoin d’au moins 50 000 FLR. Ces tokens sont verrouillés pendant au moins 14 jours. Pour faire fonctionner vous-même un validateur, un self-bond d’au moins 1 million de FLR est nécessaire, avec une durée minimale de 60 jours.

Les récompenses de staking sont déterminées par reward epoch et dépendent notamment des performances du validateur choisi. Sur Flare Mainnet, un reward epoch dure environ 3,5 jours.

La délégation FTSO fonctionne différemment. Pour cela, vous wrappez FLR sur la C-Chain un pour un en WFLR. Vous pouvez ensuite déléguer le pouvoir de vote de votre WFLR à un ou deux fournisseurs de données FTSO.

Vous ne transférez pas votre WFLR au fournisseur de données. Les tokens restent dans votre propre wallet, tandis que le pouvoir de vote délégué compte pour le fournisseur choisi.

Les fournisseurs de données FTSO peuvent conserver une partie des récompenses à titre de rémunération. Le montant reçu par un délégateur dépend donc notamment des performances du fournisseur et des frais fixés.

Comment Flare est-il né ?

Flare a été fondé en 2019 par Hugo Philion, Sean Rowan et Naïri Usher. Le projet s’est d’abord concentré sur la mise à disposition de fonctionnalités de smart contracts et de données externes pour des applications liées à différents réseaux blockchain.

Le genesis du mainnet de Flare a eu lieu le 14 juillet 2022. Le réseau a alors d’abord commencé dans une phase d’observation. Le Token Distribution Event public, au cours duquel FLR a été distribué aux utilisateurs, a suivi le 9 janvier 2023.

Lors du genesis, le premier bloc du réseau, 100 milliards de FLR ont été créés. FLR comporte 18 décimales.

Après une modification de la répartition des tokens via FIP.01, une partie des FLR a été distribuée via FlareDrops sur 36 mois. Cette distribution s’est terminée le 30 janvier 2026.

La fin des FlareDrops ne signifiait pas l’arrêt de toutes les récompenses. Les récompenses du protocole pour le staking et la délégation FTSO, entre autres, ont continué ensuite.

Quels sont les avantages de Flare ?

• Smart contracts et données dans un seul réseau : Flare combine un environnement compatible EVM avec des protocoles intégrés pour les flux de prix et la vérification de données externes.

• Flux de prix rapides et périodiques : FTSOv2 propose des block-latency feeds mis à jour à peu près à chaque nouveau bloc et des anchor feeds qui déterminent périodiquement une valeur commune. Les applications peuvent ainsi utiliser différents types de données de prix.

• Données vérifiables provenant d’autres blockchains : FDC peut vérifier des données provenant de réseaux pris en charge, notamment Bitcoin, Dogecoin, XRP Ledger et Ethereum.

• Utilisation d’actifs provenant d’autres réseaux : les FAssets sont conçus pour rendre utilisables dans les applications sur Flare des représentations surcollatéralisées d’actifs provenant d’autres blockchains.

• Délégation sans transfert de tokens : avec la délégation FTSO, vous pouvez déléguer le pouvoir de vote de votre WFLR à des fournisseurs de données tout en conservant les tokens dans votre propre wallet.

Quels sont les inconvénients de Flare ?

• Étapes supplémentaires pour le staking des validateurs : pour le staking direct à un validateur, il faut transférer FLR de la C-Chain vers la P-Chain. À la fin, les FLR doivent être renvoyés vers la C-Chain si vous souhaitez utiliser les tokens à cet endroit.

• Seuil élevé pour la délégation à un validateur : la délégation directe à un validateur nécessite au moins 50 000 FLR et impose un lock-up minimal de 14 jours. Cela rend cette forme de staking moins accessible aux petits détenteurs.

• Les FAssets dépendent de plusieurs éléments : le système utilise notamment des agents, du collatéral, des flux de prix et des données de la blockchain sous-jacente. Des problèmes sur l’un de ces éléments peuvent avoir un impact sur le fonctionnement des FAssets.

• Dépendance aux fournisseurs de données : le FTSO et la FDC utilisent plusieurs fournisseurs de données pour fournir et vérifier les données. Les applications qui utilisent ces données restent donc dépendantes de la disponibilité et du bon fonctionnement de ces systèmes.

• Les récompenses de délégation ne sont pas fixes : le rendement de la délégation FTSO dépend notamment des performances et des frais du fournisseur de données choisi.

En résumé

Flare est une blockchain Layer 1 compatible EVM qui combine les smart contracts avec une infrastructure intégrée pour les données externes. FLR est le token natif du réseau et est utilisé pour les frais de transaction, le staking, la gouvernance et la délégation.

Deux éléments importants sont le FTSO et la FDC. Le FTSO fournit notamment des données de prix, tandis que la FDC permet aux smart contracts de vérifier des données provenant de l’extérieur de Flare. Les FAssets s’appuient sur cela en rendant utilisables dans Flare des représentations d’actifs provenant d’autres réseaux.

Cela s’accompagne aussi de risques et d’étapes supplémentaires. Le staking des validateurs nécessite un lock-up et le transfert de FLR vers la P-Chain. La délégation FTSO et les FAssets dépendent en outre de différents éléments et participants au sein du réseau Flare.