Aujourd’hui, nous sommes ravis de rendre publics nos plans détaillés pour le déploiement du réseau Flare. Ces plans peuvent être pleinement explorés en plongeant dans nos projets de livres blancs couvrant le réseau et son jeton natif, Spark (ici) et l’intégration sans confiance de XRP avec Flare (ici). Les documents sont sous forme de projet et il y aura des changements d’optimisation d’ici la mise en ligne de Flare. Il ne devrait pas y avoir de changements qui s’écartent sensiblement de l’aperçu fourni ci-dessous. Dans cet article, nous visons à mettre en évidence ce que nous considérons comme les aspects les plus importants de Flare. Un aperçu technique minimal de chaque composant important sera publié au cours des semaines suivantes, à partir de cette semaine avec une présentation pas à pas de l’intégration sans confiance de Flare de XRP, FXRP. Attachez-vous!

(Un TL; DR est à la fin de ce post.)

Qu’est-ce que Flare et pourquoi la construisons-nous ?

Flare existe pour résoudre deux problèmes clés:

Tout d’abord, et d’une importance immédiate pour la construction de notre industrie, c’est que 75% de la valeur qui existe dans la blockchain publique ne peut actuellement pas être utilisée de manière fiable avec des contrats intelligents.

Deuxièmement, et de conséquence à court et à long terme, il existe des problèmes potentiels avec la mise en œuvre de la mise à l’échelle des réseaux de contrats intelligents aujourd’hui. La majorité des nouveaux réseaux utilisent la preuve d’enjeu ou ses variantes. Ces protocoles dérivent la sécurité du réseau de leur jeton natif.

Le problème immédiat inhérent à la preuve d’enjeu est que la conception consensuelle ne permet pas encore d’utiliser de manière sûre le jeton natif. Si un détenteur de jeton peut obtenir un rendement plus élevé (et sans possibilité de réduction) en fournissant une garantie pour créer un stablecoin qu’il ne le peut en jalonnant, alors en tant que rationalistes économiques, il le fera probablement. Cela détourne les jetons du jalonnement et cannibalise la sécurité du réseau. (Un article très perspicace sur ce sujet est ici.) Nous soupçonnons que c’est peut-être la raison principale pour laquelle, malgré des coûts de transaction relativement plus élevés et un débit de transaction beaucoup plus faible, Ethereum est toujours en tête dans DeFi.

Un problème à plus long terme est qu’à mesure qu’un réseau de preuve de mise gagne en utilisation et que la valeur construite sur celui-ci augmente, la valeur du jeton de jalonnement doit augmenter ou le réseau deviendra dangereux. C’est génial pour les investisseurs dans le jeton, mais mauvais pour les personnes qui veulent voir la décentralisation faire partie de la façon traditionnelle de faire des affaires. Pourquoi? Parce que pour que la valeur du jeton qui sécurise le réseau augmente, le capital doit être détourné d’une autre utilisation pour acheter le jeton. Au point de terminaison logique, si les réseaux de contrats intelligents utilisant la preuve d’enjeu devenaient la méthode omniprésente de faire des affaires, l’ampleur du détournement du capital requis d’autres entreprises, juste pour sécuriser la valeur construite sur ces réseaux, rendrait le coût du commerce irréalisable. élevé. Pour cette raison, il est extrêmement peu probable que cela se produise. La preuve de participation et les variantes peuvent faire évoluer le débit des transactions, mais les implémentations existantes ne peuvent pas évoluer en fonction de la valeur. À notre avis, la preuve d’enjeu est plus un obstacle qu’une solution.

Comment Flare résout-il ces problèmes ?

Flare est à la base une nouvelle façon de faire évoluer les plates-formes de contrats intelligents qui ne lie pas la sécurité à la valeur de son jeton. Flare nécessite toujours un jeton pour le fonctionnement du réseau, principalement pour dissuader les transactions de spam. Le jeton de Flare s’appelle Spark. Parce que Spark n’a pas d’implications pour la sécurité du réseau, il est bien adapté pour permettre l’utilisation sans confiance de jetons complets non Turing avec des contrats intelligents.

Flare est le premier réseau d’Accords Byzantins Fédérés complets de Turing (FBA) au monde. Les nœuds exécutent le protocole de consensus Avalanche avec une adaptation clé à la topologie de consensus FBA. La FBA est unique en tant que topologie consensuelle en ce sens qu’elle assure la sécurité sans compter sur des incitations économiques pouvant interférer avec des cas d’utilisation à haute valeur et à haut risque. Une critique de la FBA pure est qu’elle conduit à des structures fragiles de nœuds constitutifs, permettant des scénarios de topologie où une défaillance d’un seul nœud peut provoquer une défaillance à l’échelle du réseau. Pour cette raison, un paramètre spécifique de FBA appelé topologie de Liste de nœuds uniques (UNL) est priorisé qui met l’accent sur la clarté et la facilité d’utilisation tout en conservant la propriété d’adhésion ouverte de FBA. Le pourcentage de chevauchement de l’UNL est un paramètre défini par la gouvernance, un chevauchement plus faible améliorant la propriété d’adhésion ouverte du réseau. Le réseau Flare exploite la machine virtuelle Ethereum (EVM), ce qui permet au réseau d’exécuter des contrats intelligents complets de Turing.

Au lancement du réseau, construit sur Flare est alors un protocole permettant en toute sécurité l’émission, l’utilisation et l’échange sans confiance de XRP sur Flare. Ce protocole s’appelle FXRP. XRP en toute sécurité et sans confiance devient FXRP, sur Flare, sécurisé par le jeton natif de Flare, Spark. XRP existe désormais effectivement sur un réseau Turing complet et une fois sur place, une interopérabilité sans confiance avec d’autres réseaux est réalisable, à la fois via des protocoles d’interopérabilité tels que Cosmos et Polkadot ou avec Ethereum via des protocoles de pont bien définis. Bref: Flare peut être utilisé comme plate-forme de contrat intelligent pour XRP ou comme pipeline sans confiance pour XRP vers d’autres réseaux.

En outre, la méthodologie générale de FXRP est extensible à tout jeton complet non Turing et la capacité de décider quels autres jetons prendre en charge et d’étendre ensuite les moyens de le faire est intégrée aux systèmes et à la gouvernance du réseau.

Flare associe la valeur des jetons complets non Turing à la puissance transformatrice des contrats intelligents sur un réseau qui peut évoluer pour la valeur ainsi que le débit des transactions.

Aperçu du FXRP

La complexité de la mise en place de XRP sur Flare est qu’il n’existe aucun moyen pour un contrat intelligent sur une blockchain publique de contrôler une adresse sur le grand livre XRP. La raison en est que les contrats intelligents n’ont actuellement aucun moyen adéquat de stocker une clé secrète d’une manière véritablement secrète. Pour obtenir XRP sur Flare en utilisant uniquement du code, il faudrait qu’un groupe de participants se réunisse avec une adresse à signatures multiples qu’ils contrôlent collectivement, de sorte que si k de n parties signent une transaction, la transaction est autorisée. Tout utilisateur d’un actif émis par cette adresse multisig devrait alors faire confiance à cette collection d’utilisateurs et donc l’actif ne serait ni sans confiance ni décentralisé.

FXRP permet en toute sécurité à un titulaire de XRP (un initiateur) d’envoyer son XRP à un ensemble d’adresses (appelées agents) sur le grand livre XRP. Les contrats intelligents FXRP sur Flare émettent ensuite l’initiateur FXRP sur Flare qui est convertible 1: 1 avec XRP et sécurisé avec Spark. Lorsqu’un détenteur de FXRP souhaite l’échanger contre XRP (un échangeur), il le renvoie aux contrats intelligents FXRP sur Flare. Les agents envoient ensuite le XRP à l’adresse des échangeurs sur le grand livre XRP. Si les agents ne terminent pas ce rachat assez rapidement, le racheteur reçoit la valeur de son XRP plus un montant pour compenser les coûts de transaction pour racheter le XRP.

Avec FXRP, aucun intermédiaire centralisé n’est nécessaire.

FXRP fonctionne comme suit :

Les propriétaires du jeton natif de Flare, Spark, peuvent envoyer leurs jetons à une collection de contrats intelligents sur Flare appelés système FXRP. Les utilisateurs qui le font fournissent des garanties au système FXRP. Ils sont appelés agents. Appelons l’un des agents Bob. Il y aura de nombreux agents dans le système FXRP.

Disons que Bob a inséré 5000 jetons Spark dans le système FXRP. Dans cet exemple, 10 jetons Spark peuvent actuellement être achetés pour 1 jeton XRP. Le système FXRP exige un rapport de garantie de 2,5, ce qui signifie qu’à tout moment un agent doit avoir fourni au système 2,5 fois la valeur du FXRP que le système leur a attribué en jetons Spark. FXRP est évalué ici comme 1: 1 avec XRP. Par conséquent, les 5000 jetons Spark de Bob permettent au système d’émettre 200 FXRP.

Lorsque quelqu’un, par exemple Alice, veut créer FXRP, il envoie une transaction au système FXRP avec des frais fixes de 0,1% de la valeur de XRP qu’il souhaite convertir en FXRP. Alice est appelée une initiatrice. La transaction indique également au système FXRP à quelle adresse envoyer le FXRP sur Flare, une fois qu’il est frappé, et à quelle adresse le XRP proviendra du Grand livre XRP. S’il existe une capacité disponible dans le système FXRP, la garantie pour sécuriser le montant de FXRP en cours de création est verrouillée pendant une certaine période contre la transaction à venir d’Alice. De cette façon, Alice n’a pas à faire confiance à Bob. En retour, un ensemble d’instructions est généré pour Alice lui indiquant à quelle adresse (l’adresse de Bob) envoyer le XRP sur le grand livre XRP et quel dernier index de grand livre utiliser. S’il n’y a pas de capacité dans le système pour émettre le montant souhaité de FXRP, Alice est remboursée des frais.

Alice envoie ensuite le montant correct de XRP plus des frais de création en XRP à l’adresse de Bob sur le grand livre XRP. Les frais de création représentent la majeure partie de l’argent que Bob gagnera pour avoir verrouillé sa garantie Spark, notez que ses gains sont principalement en XRP. Flare observe cette transaction à l’aide d’un système appelé Connecteur d’État, défini dans la section 2 du livre blanc Flare (et objet d’un futur article de blog). Le FXRP est ensuite frappé par le système et livré à l’adresse désignée d’Alice sur Flare.

Le rapport de garantie de 2,5x doit être maintenu à tout moment. Si le prix du XRP augmente par rapport à Spark, de sorte que la valeur de la garantie de Bob tombe en dessous de 2.5 fois le FXRP émis contre lui, alors Bob a un temps limité pour ajouter plus de jetons Spark en garantie ou acheter et échanger des jetons FXRP pour ramener son ratio de garanties en ligne. Par exemple, disons que 200 jetons FXRP sont émis contre 5000 jetons Spark de Bob et que le prix de XRP / Spark augmente à 12. Bob doit maintenant ajouter 1000 Spark au système ou acheter et échanger 33,34 FXRP pour réduire sa répartition de FXRP émis à 166,66.

Si Bob n’a pas accès à des jetons Spark supplémentaires, il n’est pas financièrement onéreux pour lui de réduire le solde de FXRP pris en charge par son adresse. La garantie de Bob a permis au système FXRP d’émettre 200 jetons FXRP, ce faisant, Bob a reçu 200 jetons XRP sur le grand livre XRP. Ainsi, si Bob n’a pas de capital supplémentaire pour acheter des jetons Spark, il peut soit vendre suffisamment de XRP pour FXRP sur un échange de sorte qu’il puisse racheter au moins 33.34 FXRP ou rester dans un environnement purement décentralisé s’il y a d’autres agents dans le système FXRP avec une garantie excédentaire suffisante, il peut monnayer suffisamment de FXRP et le racheter immédiatement. Le deuxième scénario déplace essentiellement l’obligation vers le reste du système. Si Bob ne fait rien et reste en défaut par rapport au ratio de garantie, la garantie de Bob sera automatiquement mise aux enchères pour le montant de FXRP émis contre elle, qui dans ce cas est de 200. Bob conserve toute garantie restante après cette opération.

Disons que Bob a choisi d’ajouter Spark supplémentaire comme garantie. Maintenant, quelque temps plus tard, Alice qui possède tous les 200 FXRP émis veut racheter la totalité du montant dans le grand livre XRP. Alice effectue simplement une transaction avec le système FXRP en envoyant le FXRP au système et en lui indiquant l’adresse à laquelle elle souhaite être créditée. Le système émet ensuite un ensemble d’instructions à Bob lui indiquant combien de XRP envoyer et où, ainsi que deux dates limites de numéro de registre XRP auxquelles la transaction doit être complétée. Si Bob termine la transaction avant la première date limite, sa garantie est entièrement débloquée. Si Bob échoue à la première échéance mais réussit à la seconde, il est facturé une petite pénalité et le reste de sa garantie est débloqué. Les frais de pénalité sont brûlés.

Si Bob ne termine pas la transaction avant la deuxième date limite, on parle d’échec de rachat. Alice est ensuite indemnisée avec des jetons Spark à la valeur de son XRP racheté plus une augmentation de 1% pour couvrir les coûts de transaction du rachat du XRP, qui est tiré de la garantie de Bob. De la garantie restante de Bob, 50% est brûlé à titre de pénalité et les 50% restants lui sont retournés. Alice peut alors acheter du XRP de remplacement sur un échange. Alternativement, en supposant qu’il y ait d’autres agents sur Flare avec du FXRP émis et des personnes qui souhaitent le vendre, Alice peut acheter plus de FXRP sur Flare et l’échanger contre ces agents.

Applications dépendantes et Spark

FXRP est le premier exemple de quelque chose que nous appelons une Application dépendante Spark (SDA). Un SDA est défini comme une application qui utilise dans sa construction une combinaison de: Spark pour la garantie, la série chronologique Flare Oracle et les détenteurs de jetons Spark pour la gouvernance. Chacun de ces éléments est entièrement facultatif et une application ne peut fonctionner sur Flare qu’en interagissant avec Spark pour le paiement des coûts de transaction. Par exemple, FXRP utilise Spark comme garantie, l’Oracle de la série chronologique Flare pour le prix XRP / Spark et la propriété du jeton Spark définie pour la gouvernance sur certains paramètres tels que les frais de création FXRP et le ratio de garantie. Le modèle SDA est destiné à fournir un modèle pour étendre chacun des trois composants à un nombre arbitraire d’applications. L’utilisation de Spark comme garantie dans toutes les applications est simple, l’élément le plus important était de considérer comment une méthodologie oracle sécurisée pouvait être créée sur plusieurs séries chronologiques.

Flare Time Series Oracle

La propriété du jeton Spark permet la contribution à l’Oracle Flare Time Series (FTSO). Le but du FTSO est de former des estimations précises des données sur les torchères hors chaîne tout en conservant la décentralisation. Le FTSO est structuré de manière à fournir de nombreuses estimations de séries chronologiques individuelles. Le prix XRP/Spark est un exemple de série chronologique unique.

Chaque série chronologique produite par le FTSO aura généralement deux groupes de participants: le premier étant les détenteurs de jetons Spark et le second étant les détenteurs du jeton d’application dépendant, appelé F-asset. Dans l’application FXRP, le F-asset est le jeton FXRP lui-même. Pour une application plus complexe comme une application de dérivés où l’application nécessite plusieurs séries chronologiques, l’actif F peut s’apparenter à un jeton de gouvernance émis.

Pour chaque série chronologique, le FTSO demande à chaque ensemble pertinent de participants de fournir une estimation. Les détenteurs de Spark fourniront des estimations pour toutes les séries chronologiques et les détenteurs d’actifs F fourniront des estimations sur uniquement les séries chronologiques liées à leur actif F. Ces estimations sont ensuite traitées comme défini à la section 4 du livre blanc sur les torches et produites par le système.

L’incitation des détenteurs de F-asset à fournir des données au système est la sécurité de leur application. Les détenteurs de jetons Spark sont incités par le potentiel de gagner quelque chose appelé la récompense oracle. Il s’agit d’une quantité de jetons Spark frappés par le système. La récompense oracle est un taux annuel réparti uniformément sur chaque période d’estimation FTSO. Par exemple, si le taux est de 10%, il y a 365 estimations en un an et un nombre de jetons d’étincelle de départ de 100, alors 10 Étincelles seront créées en 1 an et ~ 0,03 Étincelle frappée et récompensée par jour. Les contributeurs de jetons Spark peuvent gagner cette récompense en fournissant des données jugées  » correctes « . Les mécanismes précis sont exposés dans le livre blanc. Il est important de noter que tous les détenteurs de jetons Spark sont implicitement jalonnés dans le système comme s’ils ne gagnaient pas la récompense soit par non-contribution, soit en fournissant des estimations « incorrectes » qu’ils perdent de la valeur pour les détenteurs de jetons qui sont récompensés. Ceci est la version de Flare des récompenses de bloc.

Le FTSO sera lancé pour fournir les prix suivants pour: XRP / Spark, USD / Spark, BTC / Spark et XLM/Spark. Seul XRP/Spark aura un actif F correspondant au départ. Des séries chronologiques supplémentaires et leurs actifs F connexes peuvent être proposés et acceptés dans le cadre du processus de gouvernance.

Délégation

Le FTSO fournira en réalité des estimations toutes les deux secondes. Tous les détenteurs de Spark ne voudront pas ou ne pourront pas faire fonctionner du matériel pour contribuer à la FTSO et, séparément, ils pourraient ne pas être intéressés à voter pour la gouvernance du réseau. Par conséquent, les votes pour les deux responsabilités peuvent être détachés du jeton lui-même et délégués séparément à d’autres parties. La délégation peut être annulée à tout moment et lorsqu’un jeton est transféré d’une adresse à une autre, la délégation est automatiquement annulée de sorte que les droits de vote vont avec le jeton. Le mécanisme permet également aux ADS tels que FXRP de déléguer les votes Spark au propriétaire final qui peut ensuite déléguer à nouveau ces votes aux entités qu’il souhaite voter en son nom. Donc, si Bob a 5000 jetons Spark dans l’application FXRP, il déléguera les votes de ces jetons à une adresse spécifiée par Bob. Si Bob souhaite qu’un fournisseur de données dédié contribue au FTSO en son nom, Bob peut alors déléguer à nouveau ses votes pour le FTSO au fournisseur de données. Il est important de noter que cela signifie que Bob n’a pas à choisir entre gagner Spark en fournissant des garanties à l’application FXRP et potentiellement gagner la récompense du FTSO, il peut faire les deux. Tout SDA qui rend les jetons Spark indisponibles pour leurs propriétaires sous-jacents, à condition qu’il y ait une définition dans l’application quant à qui est le propriétaire sous-jacent, peut implémenter la procédure de délégation.

Gouvernance &Fondation

Flare est entièrement gouvernée par les détenteurs de jetons Spark par le biais du vote. Les SDA peuvent éventuellement demander à être régies par les détenteurs de jetons Spark.

Certaines décisions peuvent être prises de manière automatisée en chaîne, telles que la modification du coût de transaction, du taux de récompense oracle ou, en considérant le FXRP comme un SDA, la modification du ratio de garantie et des frais de création. D’autres décisions telles que l’ajout d’une nouvelle série chronologique à l’OSF et la liaison de son actif F proposé, la modification des paramètres de consensus du réseau ou des mises à jour plus complexes à long terme nécessitent un changement de code. Le livre blanc de Flare présente une proposition, un régime de développement et de test pour les modifications manuelles qui peuvent être initiées et votées par les détenteurs de jetons Spark. Pour aider à mettre en œuvre ce processus et à exécuter les modifications convenues, il y aura une fondation Flare. La fondation sera un organisme à but non lucratif, qui sera constitué dans les prochains mois. Il sera responsable de 5 domaines clés: subventions, investissements, recherche et développement, éducation, publicité et partenariats.

C’est la fonction de recherche et développement qui permet à la fondation de faire partie intégrante du processus de mise à jour du réseau, allant même jusqu’à analyser, rapporter puis construire, tester et déployer les modifications de code réseau proposées.

La fondation doit être très transparente et ne pas gaspiller d’argent. Deux rapports par an sur ses activités et ses dépenses seront respectés et publiés. La fondation est uniquement destinée à prendre la direction des détenteurs de jetons Spark et non à définir l’ordre du jour. En tant que tel, il ne peut pas : contribuer à la FTSO de quelque manière que ce soit, déployer ses participations Spark en garantie pour toute application sur le réseau et il ne peut pas utiliser ses participations Spark pour voter lors d’un vote sur la gouvernance. Il ne peut pas attribuer ses jetons Spark à d’autres pour le faire. En outre, la constitution de la fondation stipulera que si un vote de gouvernance convient que la fondation ne sert plus un objectif bénéfique, la fondation doit liquider ses activités et brûler toutes ses avoirs symboliques restants à la première occasion.

Spark Issuance

La meilleure communauté pour posséder l’actif qui permet l’utilisation de XRP avec des contrats intelligents complets Turing est la communauté qui l’utilisera et en bénéficiera : les détenteurs de XRP. Flare ne fait pas d’ITO. Au lieu de cela, il fait ce que nous appelons un fork utilitaire. Nous pensons que c’est le premier du genre.

Un fork a traditionnellement cherché à prendre la base d’utilisateurs d’un réseau existant et à s’en écarter entièrement, généralement pour avoir une relation antagoniste avec la chaîne d’origine. En revanche, une fourche utilitaire est destinée à ramener de la valeur à la chaîne d’origine au lieu de s’en éloigner. Flare permet à XRPL de faire ce qu’il fait de mieux, un règlement rapide, tout en apportant à XRPL, des contrats intelligents et la faisabilité de créer un pipeline sans confiance vers d’autres chaînes de blocs. Nous pensons que c’est une combinaison vraiment puissante et un parfait exemple d’utilité.

100 milliards de jetons Spark seront créés pour refléter la quantité de XRP qui existe. Il y a environ 45 milliards de jetons XRP qui n’appartiennent pas à Ripple labs. L’objectif de la distribution est que les détenteurs de XRP autres que Ripple puissent réclamer une quantité d’étincelle d’environ 1: 1 à leur holding XRP. 45 Bn Spark pourront être réclamés par les détenteurs de XRP (en supprimant les adresses Ripple labs connues). 25 milliards de Spark iront à Flare Networks Limited, l’organisation à but lucratif de Flare. 30 milliards d’étincelles iront à la fondation Flare.

Comme de nombreux propriétaires de XRP utilisent réellement des échanges pour conserver leurs jetons XRP, il est possible qu’un détenteur de XRP qui souhaite réclamer des jetons Spark puisse ne pas le faire car l’échange revendique l’Étincelle et les conserve plutôt que de les transmettre, ou ne les réclame pas du tout. Pour permettre aux propriétaires de XRP de participer à la distribution en faisant pression sur leur échange pour distribuer les jetons Spark ou pour déplacer l’échange vers celui qui le fait, l’instantané du grand livre XRP sera pris à une date plus proche du lancement. Une liste des échanges participants sera publiée sur le site Web de Flare et mise à jour périodiquement. Le numéro du grand livre de l’instantané sera affiché sur le site Web lorsque l’instantané aura été pris.

TL;DR

Flare est le premier réseau d’Accords Byzantins Fédérés complets de Turing au monde. Il intègre la machine virtuelle Ethereum (EVM) et ne tire pas de sécurité d’un jeton. En plus de cela, un protocole est construit pour permettre en toute sécurité l’émission, l’utilisation et l’échange sans confiance de XRP sur Flare. Ce protocole s’appelle FXRP. La méthodologie générale du protocole et du système qui connecte Flare à d’autres réseaux est extensible à tout jeton complet non Turing. L’interopérabilité sans confiance avec d’autres réseaux est réalisable, à la fois via des protocoles d’interopérabilité tels que Cosmos et Polkadot ou avec Ethereum via des protocoles de pont bien définis.

Le jeton de Flare, Spark, est créé via ce qui peut être le premier fork utilitaire de l’histoire grâce auquel le réseau d’origine, dans ce cas le Grand livre XRP, bénéficie d’une utilité accrue. 100 Milliards de jetons Spark seront créés au début du réseau Flare, dont 45 milliards pourront être réclamés par les détenteurs XRP existants, à l’exclusion de Ripple Labs. Cela reflète la quantité existante de XRP distribué de sorte que les détenteurs actuels de XRP pourront réclamer environ 1 jeton Spark pour chaque jeton XRP détenu. 25 milliards de jetons iront aux développeurs, Flare, et 30 milliards de jetons iront à une fondation à but non lucratif appelée Flare foundation. Les détenteurs de jetons Spark peuvent obtenir un rendement sur leurs jetons Spark à la fois en engageant des jetons Spark en garantie pour garantir l’émission et l’échange sans confiance de FXRP et en fournissant des données à la série chronologique Flare oracle. Ces fonctions ne sont pas en concurrence les unes avec les autres.

Le jeton Spark est utilisé pour la gouvernance du réseau par le vote. À l’exception des subventions et des investissements pour aider à développer Flare, la fondation prend la direction technique des propriétaires de jetons Spark. Un rôle clé de la fondation est d’aider à exécuter les mises à niveau et les modifications du réseau, convenues par un vote de la gouvernance, qui ne peuvent être mises en œuvre sans un changement de code. Il est important de noter que la constitution de la fondation contiendra un règlement stipulant que la fondation doit être liquidée et que tous les jetons Spark détenus par la fondation doivent être brûlés, si les détenteurs de jetons Spark conviennent que son existence n’est plus bénéfique pour le réseau.

Flare associe la valeur des jetons complets non Turing à la puissance transformatrice des contrats intelligents sur un réseau qui peut évoluer pour la valeur ainsi que le débit des transactions.

Réponses à deux questions:

Spark crée-t-elle une preuve d’enjeu par la porte dérobée?

Seuls les jetons émis qui nécessitent une garantie, tels que FXRP, sont sécurisés avec Spark. Le réseau n’utilise pas Spark pour la sécurité pour parvenir à un consensus.

Nous avions (ce que nous pensons être) des concepts très forts pour une pièce stable libellée en USD, mais cela a nécessité une refonte approfondie de la machine virtuelle Ethereum, ce qui aurait retardé le lancement et eu des effets imprévisibles sur la compatibilité future avec l’EVM. Spark, tel qu’il est structuré, offre une utilité et des avantages beaucoup plus importants à la fois à la communauté XRP et au grand livre XRP.