46 – FlareNetwork Community Update #1

         Comme vous le savez probablement, Flare a tenu sa première « Flare Community Update » récemment sur Twitter. 2h40 de contenu très dense que je vais tâcher de vous synthétiser ici. Hugo l’a dit, il aimerait que la communauté relaie les informations qui ont été données et même s’il ne l’avait pas demandé je l’aurais quand même fait ! C’est aussi dans ce but que j’ai tenu sur le Discord CFN une AMA le dimanche 01/05 d’ailleurs.

          Essayons de nous souvenir de quoi il était question il y a un an. Leur projet était initialement de lancer FlareNetwork, une blockchain de Layer 1 sur laquelle il y aurait le FTSO afin de résoudre le problème des prix, le State Connector qui allait permettre de connaître l’état des autres blockchains, et les F-Assets, qui allaient permettre aux tokens dont les blockchains étaient dépourvues de smart-contracts, d’en bénéficier. « Unlocking value ». Les F-Assets alors annoncés étaient XRP, XLM, LTC et DOGE. D’autres pourraient être ajoutés plus tard via les votes de gouvernance. Le lancement de FlareNetwork était prévu fin juin 2021.
          Il n’était alors pas question de Layer Cake, de connecter le web2 au web3 et encore moins de Songbird. Beaucoup de chemin parcouru donc sur leur feuille de route, ils ont voulu voir grand et je dois dire que je suis très, très séduit. Vous le savez, j’étais déjà très enthousiaste sur leur projet, inutile de vous dire que mon sentiment n’a fait que se renforcer.

          Alors avant de plonger dans les nouveautés, commençons par reposer les bases, ce qui était initialement prévu. J’essaye de faire court sur les rappels, promis.

Leur token, le SGB sur Songbird, et FLR sur FlareNetwork

          Sans trop rentrer dans les détails, il dispose d’un atout important. Le vote détachable. Là où sur Ethereum par exemple vous devez stacker, et donc bloquer, vos tokens pour participer, le SGB lui dispose d’un vote FTSO détachable du token lui-même. Cela signifie donc que vous pouvez voter pour un Data Provider, tout en continuant de profiter de vos tokens en les stackant ailleurs, en les mettant en collatéral dans des protocoles de DeFi, en étant agent pour miner des F-Assets et j’en passe.
          Sur Ethereum vous sackez vos ETH et… ben c’est tout.

Le problème des prix – Le FTSO

          Compte tenu de la multitude des marchés existants, j’entends par là le nombre d’échanges existants, il est très difficile de connaître le prix exact d’un token, disons le BTC pour faire consensus, de façon fiable. Il y a parfois un écart important sur le prix d’une plateforme à l’autre. D’autre part les plateformes sont actuelles sont centralisées et en cas de défaillance de la plateforme sur laquelle une dApp se base pour obtenir le prix d’un token, elle peut ne plus fonctionner correctement. Enfin le prix peut être manipulé sur un échange pouvant causer des problèmes importants sur la dApp en question. (C’est l’expérience qui parle).
          Pour résoudre ce problème, Flare a implémenté le FTSO. Des Data Providers ou DP (100 aujourd’hui), comme vous et moi, soumettent toutes les 3 minutes le prix des paires comme BTC/USD au FTSO. Le FTSO supprime les prix les plus hauts et les plus bas, fait une moyenne des autres, et les DP les plus proches sont récompensés en SGB ou FLR. Leurs rewards proviennent de l’inflation du token, fixée à 10% initialement, mais qui sera probablement revue à la baisse au travers des votes de gouvernance.
          Nous nous retrouvons ainsi avec des prix décentralisés dans la mesure où ils proviennent de multiples DP, et sécurisés puisque les DP récupèrent leurs prix de différentes sources. Ainsi la défaillance d’une source ou d’un DP n’a que peu ou pas d’impact sur les prix fournis par le FTSO.

Le State Connector

          Cette brique du réseau devait uniquement permettre de garantir qu’un événement s’était bien produit sur une autre blockchain. Notez l’emploi de l’imparfait. Imaginez par exemple une dApp sur FlareNetwork qui va s’assurer qu’un NFT a bien été miné sur OpenSea par un Wallet afin de débloquer une récompense sur FlareNetwork.
          Il est utilisable par n’importe qui, de n’importe où. Une dApp sur Solana pourrait très bien l’utiliser sans pour autant interagir avec FlareNetwork directement. C’est un outil communautaire.

Unlocking Value – Les F-Assets

          70% des blokchains actuelles sont dépourvues de contrats intelligents. Cela veut dire que lorsque que l’on détient des tokens sur ces blockchains, on ne peut que HOLD. Pas de stacking, pas de farming, pas de délégations, pas de NFT, pas de rien du tout. L’idée des F-Assets est donc de porter sur Flare ces tokens afin de leur donner une cape de super héro leur permettant d’être compatible avec les contrats intelligents. Un DOGE va donc pouvoir être porté sur Flare en F-DOGE et on va pouvoir s’en servir sur n’importe quelle dApp construite sur Flare, comme par exemple pour acheter des NFTs ou les stacker dans un protocole de DeFi. Unlocking value prend alors tout son sens car la valeur qui jusque là dormait dans les wallets va pouvoir être mise au travail.

          Si vous souhaitez vous replonger plus en détails sur ces bases je vous invite à aller consulter mes premiers articles sur Flare : https://cryptapero.fr/category/defi/flarenetwork/

          Depuis il s’est passé beaucoup de choses. Nous sommes en avril 2022 et FlareNetwork n’est toujours pas lancé. WEN FLR ??!! Le 4 juillet si les résultats de l’audit dont la fin est prévue fin juin se passe comme attendu.e

                                      Quoi de neuf sous le soleil ?

          Et bien Flare a souhaiter résoudre deux problèmes majeurs en plus des autres. Celui des bridges entre blockchains, qui ne peuvent être que bilatéraux et manquent de sécurité, et celui de la connexion entre web2 et web3.

State Connector, part 2

          Le State Connector est « permisionless » ce qui signifie que n’importe qui peut s’improviser « Attestation Provider » ou AP. Le principe est le suivant :

          Ce mécanisme se décompose en trois phases et est appelé le protocole RCR.  

1. Le State Connector ou SC ne peut répondre que par oui ou non. Il va accumuler les questions qui lui sont posées (1) et soumettre (2) toutes les 90 secondes le bloc de questions aux AP.
2. Pendant que les AP cherchent la réponse (3) il va accumuler un nouveau bloc de questions (1). Une fois que les AP ont leurs réponses ils les envoient de façon chiffrée au SC (4). De cette façon il n’est pas possible pour un AP de tricher sur un autre. 
3. La réponse qui aura un retour de plus de 50% des AP sera déclarée la bonne et fera consensus. Une Attestation Proof sera alors délivrée par le SC (5) et sera rendue publique.

           Nous avons donc ainsi les 3 phases qui s’exécutent en parallèle.

          Quel est l’intérêt de devenir Attestation Provider me direz-vous ? Tout simplement parce que si vous donnez la réponse qui au final fait consensus, vous êtes récompensés. En quoi ? SGB/FLR. De combien ? Nous n’en savons rien à ce stade. Enfin si vous avez l’info, n’hésitez pas à m’en faire part !

          Alors jusque là c’était déjà prévu. Le SC était déjà annoncé et devait déjà pouvoir confirmer un événement sur une autre blockchain. La réelle nouveauté, c’est qu’il sera possible de confirmer un événement sur le web2 dès lors que l’information sera en base de données et qu’elle sera accessible au travers d’une API. Et ça mes amis c’est « Game Changer » comme on dit. Imaginez par exemple une dApp de paris sportifs sur Flare qui récupèrera le résultats des matchs sur le web2 Les possibilités sont vraiment énormes.
           Il a été fait mention d’une dApp d’échecs en cours de développement et de pouvoir aller consulter le résultat des matchs d’échecs sur le web2. On retrouve d’ailleurs cette catégorie sur la page d’accueil du State Connector. Une démo live du State Connector est disponible sur le stream de Flare.

Attaquons nous maintenant au problème des bridges

          Un bridge est un smart-contract dans lequel on va bloquer nos tokens pour en avoir d’autres. Les tokens obtenus seront compatibles avec la blockchain sur laquelle vous souhaitez interagir. Ils sont beaucoup utilisés dans les stratégies de DeFi où l’on va emprunter un token en déposant un collatéral sur une plateforme X d’une blockchain A, puis les bridger ou wrapper sur une autre blockchain pour aller les stacker sur une autre plateforme de DeFi sur une blockchain B. Dans cet exemple on rentre avec des ETH sur Ethereum et on en ressort avec des sETH sur Solana. Jusque là tout va bien. 

          Premier problème, la sécurité. En l’état les bridges sont centralisés, qu’importe le nombre de signataires. Vos fonds sont bloqués dedans mais peuvent techniquement être volés ou exploités par les détenteurs du bridge d’une part mais surtout le bridge peut se faire hack. 
          Autre problème de sécurité, seules les entêtes des blocs sont transmises aujourd’hui aux bridges afin d’accélérer le processus. Ce manque d’information ouvre aussi la porte à des failles pouvant être exploitées par les attaquants.
          Et voici le résultat. Ok une partie des sommes volées ont été restituées mais ça n’enlève en rien les risques liés à l’utilisation des bridges actuels.

          Le second problème majeur des bridges actuels est qu’ils sont bidirectionnels uniquement. Pour reprendre l’exemple du dessus, on va de Ethereum à Solona, de Solana à Ethereum et c’est tout. Si on souhaite aller sur une autre blockchain il va falloir utiliser un autre bridge. Pire, si on envoie nos sETH de Solana vers Cosmos on se retrouve avec des scETH. Or le scETH, même s’il a la même valeur que l’ETH ou le cETH est en réalité un token différent, avec un contrat différent. Il est donc fort probable qu’une plateforme de DeFi qui prenne en charge le cETH sur Cosmos ne prenne en revanche pas en charge le scETH. V’la le bordel !
          C’est ce que l’on appelle la liquidité fragmentée. De la liquidité en ETH, d’autre en sETH, d’autre en cETH, tout ça pour la même valeur et même token à la base. Si on devait créer un bridge traditionnel entre chaque blockchain du top100 il en faudrait, tenez-vous bien : 4950 !

Mais, mais, mais…

                                            Layer Cake

          Flare va donc proposer une solution à ces problèmes grâce à Layer Cake. 

Mais comment père Castor ?!

          Tout d’abord il faut bien comprendre que les bridges actuels ne permettent de lier que deux blockchains prenant nativement en charge des contrats intelligents. Layer Cake s’adresse donc à elles. Pour les autres, on a les F-Assets
          Le principe va être le suivant. Une personne quelconque va lancer un bridge Layer Cake. Il va ensuite y déposer un collatéral qui va servir de garantie ou d’assurance aux futurs utilisateurs du bridge. Ce collatéral sera bloqué au sein de son bridge, et s’il essaye de partir avec la caisse le collatéral sera reversé à ceux qui y avaient des tokens bloqués.
          Le collatéral déposé dans le bridge va définir la « bande passante » maximum du bridge. Techniquement il va s’agir de la valeur maximum qui pourra circuler sur son bridge dans un temps donné fixé à 1h au départ. Pour éviter les attaques à 51%, une valeur maximale à ce collatéral sera fixée. De cette façon il ne sera jamais rentable pour un attaquant d’essayer d’exploiter le protocole.
          Le gestionnaire du bridge sera rémunéré à 37% d’APR. Cependant, faire tourner un bridge Layer demandera une infrastructure et des connaissances minimum en informatiques. Ca ne sera pas à la portée du premier venu.          Et que se passe-t-il s’il n’y a pas ou plus de gestionnaires de bridges ? Et bien le protocole rebascule en mode lent en transmettant non seulement les entêtes des blocs mais aussi l’ensemble des informations de chaque bloc.           Autre point important, et non des moindres, un ETH bridgé sur Laker Cake sera le même token qu’importe la blockchain sur laquelle il sera utilisé, du moment que la blockchain en question est prise en charge par Layer Cake. Flare ambitionne de bridger les 50 blockchains principales. Il sera tout à fait possible de bridger les autres, simplement les autres seront soumises au vote de gouvernance.          Enfin les tokens bridgés sur Layer Cake n’auront pas besoin de circuler sur FlareNetwork, ils pourront directement passer de Cosmos à Solana par exemple, mais il sera possible de les utiliser sur n’importe quelle blockchain, dont Flare. Flare se contente de sécuriser Layer Cake au travers de ses smart-contracts, libre à qui veut de l’utiliser.

          Bon, ça commence à faire beaucoup d’infos, essayons de récapituler tout ça. FlareNetwork c’est quoi aujourd’hui ?

• Le FTSO : permet d’avoir des prix de façon décentralisée et sécurisée.
• Les F-Assets : permettent d’apporter les smart-contracts aux blockchains qui en sont dépourvues
• Le State Connector : permet de confirmer qu’un événement a bien eu lieu on-chain ou off-chain
• Le Layer Cake : permet de bridger toutes les blockchains pourvues de smart-contracts au sein d’un seul bridge en unifiant toute la liquidité disponible au sein de tokens uniques.

          Ainsi Flare ambitionne de connecter toutes les blockchains, qu’elles soient compatibles avec les smart-contracts ou non, le web2.0, et de proposer des prix fiables et résilients. #ConnectEverything

          Vous êtes prêts pour la suite ? Parce que non, ce n’est pas fini ! Parlons roadmap, WEN ?!

          D’ici mi-mai Trail of Bits commencera son audit du code de Flare. L’issue est prévue pour mi juin et Hugo a la conviction que cela va bien se passer. Si jamais il devait y avoir des choses à revoir, les problèmes seront corrigés puis la communauté sera tenue informée, cela pour éviter que les failles potentielles identifiées aient le temps d’être exploitées sur Songbird. En dehors de cela, FlareNetwork est prêt, le code est finalisé et ils seraient déjà en mesure de lancer la blockchain, lancement prévu pour le 4 juillet si l’audit se passe bien.

          Désolé pour la pauvre qualité de ces captures d’écran, elles sont issues de leur stream et je n’ai pas pu obtenir mieux.

          Pas beaucoup de dates sur cette roadmap vous en conviendrez, plutôt des milestones. On peut ainsi voir que le code du State Connector a été implémenté sur Songbird. Prochaine étape majeure, l’activation du client du State Connector pour que les AP puissent commencer à proposer des attestations. Viendront ensuite les F-Assets et le Layer Cake.

          Rien de prévu avant le 4 juillet pour FlareNetwork. On retrouve ensuite les mêmes étapes que pour Songbird.
          Par contre nous avons eu plus de détails sur ce à quoi s’attendre aux différentes étapes, et ce qu’il sera possible de faire.

          Ainsi au lancement de FlareNetwork  nous aurons le FTSO et le State Connector… Oh wait ! Si on a le State Connector au lancement de FlareNetwork, il aura bien fallu le lancer avant sur Songbird non ? Il y a donc fort à parier que les étapes SB02 et SB03 auront été franchies d’ici le 4 juillet.
          Et que peut-on faire avec ça ? De la gouvernance, les délégations au FTSO, créer des applications qui pourront utiliser les prix du FTSO et pourquoi pas des évènements confirmés au travers du State Connector. Autrement dit, non seulement tout ce qui existe aujourd’hui sur Songbird pourra être porté sur FlareNetwork, mais ces mêmes dApp pourront également tirer profit du State Connector, dès le lancement.

          Une fois les F-Assets lancés il sera possible de les utiliser sur les dApps qui les prendront en charge, et nul doute qu’elles le feront, nous pourrons également faire du crowfounding et se servir de nos FLR comme collatéral en tant qu’agent pour être récompensé dans le token que l’on souhaitera collatéraliser.
          Oh wait ! Du crowdfounding ? Effectivement. Il sera possible de déposer nos F-Assets dans des pools afin que les rewards de ces pools, et peut-être même les rewards FTSO, servent à financer le projet que l’on aura décider de soutenir. Ce même projet pourra en retour nous récompenser sous une autre forme comme leur propre token, des NFTs, des phygitals ou autre. (1 phygital, des phygitaux ?)

          Une fois Layer Cake lancé il sera possible de connecter une multitude de blockchains et d’utiliser ou proposer leurs tokens sur les dApps construite sur FlareNetwork.

          Vous en voulez encore ? Aller, quelques informations partagées vers la fin du stream, dont une qui risque de faire du bruit, je vous laisse deviner laquelle.

• La gouvernance ne sera lancée sur FlareNetwork que lorsqu’au moins 75% des FLR prévus lancement (soit 75% des 15%) auront été distribués, ce qui inclut évidemment ceux que les échanges vont devoir distribués.
• Tous les échanges partenaires ont confirmé leur intention de les distribuer, (ndla même Coinbase donc), mais il n’est techniquement pas possible pour un échange d’intégrer une blockchain avant qu’elle ne soit lancée. On ne peut donc pas exiger des échanges qu’ils soient en mesure de distribués les tokens dès le lancement.
• Ils envisagent la possibilité de faire de la collatéralisation avec des NFTs, nativement.
• Une fois FlareNetwork lancé il sera possible de modifier l’adresse attachée au compte XRP lors du snapshot du 12/12/20 pour que la distribution mensuelle des FLR soit envoyée vers un autre compte. Cela devra toutefois être soumis à un vote de gouvernance.
• Enfin, vous le savez sûrement, nous serons récompensés en FLR pour le simple fait de détenir des F-Assets. Il n’en sera pas de même sur Songbird. Je le reformule pour être sûr que tout le monde comprenne : Il n’y aura pas de rewards natifs à holder des S-Assets.

          Qu’est-ce que cette dernière information change ? Pas grand chose en réalité. L’intérêt à miner des S-Assets est certes un peu diminué mais cela n’enlève en rien qu’entre holder des DOGE, ou bien stacker des SDOGE par exemple, le calcul est vite fait.

          J’espère que ce contenu vous a plu et que vous y voyez plus clair sur le projet de FlareNetwork maintenant qu’au début de l’article Si c’est le cas, pensez à Like et Retweet, ce serait sympa 

See you soon

Cryptapero
XRP (Xumm Wallet) : rLpfeWYAq1Vk5RM2LAkQifUZKArt17oD1r
SGB : 0x2B2506bc4ea8BC053666c4db1C0c98803cF725E3