rețele Flare
astăzi suntem încântați să facem publice planurile noastre detaliate pentru desfășurarea rețelei Flare. Aceste planuri pot fi explorate pe deplin prin scufundarea în proiectele noastre de cărți albe care acoperă rețeaua și simbolul său nativ, Spark (aici) și integrarea fără încredere a XRP cu Flare (aici). Lucrările sunt în formă de proiect și vor exista modificări de optimizare între acum și Ziua Flare merge live. Nu ar trebui să existe modificări care să se abată semnificativ de la prezentarea generală furnizată mai jos. În această postare ne propunem să evidențiem ceea ce considerăm a fi cele mai importante aspecte ale Flare. O prezentare tehnică minimă a fiecărei componente importante va fi postată în următoarele săptămâni, începând cu sfârșitul acestei săptămâni, cu o prezentare a integrării fără încredere a lui Flare a XRP, FXRP. Pune-ți centura!
(un TL;DR este la sfârșitul acestui post.)
- ce este Flare și de ce îl construim?
- cum rezolvă Flare aceste probleme?
- Prezentare generală FXRP
- fxrp funcționează după cum urmează:
- Aplicații Spark și dependente
- Flare Time Series Oracle
- Delegația
- guvernanță& Fundația
- emiterea de scântei
- TL;DR
- răspunsuri la două întrebări:
- este Spark crearea dovada miza de backdoor?
ce este Flare și de ce îl construim?
Flare există pentru a rezolva două probleme cheie:
În primul rând, și de o importanță imediată pentru clădirea din industria noastră este că 75% din valoarea care există în blockchain-ul public nu poate fi utilizată în prezent într-o manieră fără încredere cu contracte inteligente.
În al doilea rând, atât pe termen scurt, cât și pe termen lung, există probleme potențiale cu modul în care scalarea este implementată astăzi pentru rețelele de contracte inteligente. Majoritatea rețelelor noi folosesc Proof Of Stake sau variantele sale. Aceste protocoale derivă siguranța rețelei din tokenul lor nativ.
problema imediată inerentă dovezii mizei este că designul consensului nu permite încă în siguranță utilizări alternative ale jetonului nativ. Dacă un deținător de jetoane poate obține un randament mai mare (și fără posibilitatea de a reduce) prin furnizarea de garanții pentru a crea un stablecoin decât pot de la miză, atunci ca raționaliști economici, probabil că vor face acest lucru. Acest lucru deviază jetoanele de la miză și canibalizează siguranța rețelei. (O lucrare extrem de perspicace pe acest subiect este aici.) Bănuim că acesta este probabil motivul cheie pentru care, în ciuda costurilor de tranzacție relativ mai mari și a transferului de tranzacții mult mai mic, Ethereum continuă să conducă în DeFi.
o problemă pe termen mai lung este că, pe măsură ce o dovadă a utilizării câștigurilor rețelei de miză și valoarea construită deasupra acesteia crește, valoarea tokenului de miză trebuie să crească sau rețeaua va deveni nesigură. Acest lucru este minunat pentru investitorii în token, dar rău pentru oamenii care doresc să vadă descentralizarea devenind parte a modului principal de a face afaceri. De ce? Deoarece pentru ca valoarea tokenului care asigură creșterea rețelei, capitalul trebuie deviat de la o altă utilizare pentru a cumpăra tokenul. Luate la punctul final logic, dacă rețelele contractuale inteligente care utilizează dovada mizei ar deveni metoda omniprezentă de a face afaceri, amploarea deturnării capitalului necesară altor eforturi, doar pentru a asigura valoarea construită pe aceste rețele, ar face costul comerțului imposibil de ridicat. Din acest motiv este extrem de puțin probabil să se întâmple. Dovada mizei și variantele pot scala tranzitul tranzacției, dar implementările existente nu pot scala pentru valoare. În opinia noastră, dovada mizei este mai mult o oprire decât o soluție.
cum rezolvă Flare aceste probleme?
Flare este în centrul său un nou mod de scalare a platformelor contractuale inteligente care nu leagă siguranța cu valoarea tokenului său. Flare necesită încă un jeton pentru funcționarea rețelei, în principal pentru a descuraja tranzacțiile spam. Jetonul lui Flare se numește Spark. Deoarece Spark nu are implicații privind siguranța rețelei, este foarte potrivit pentru a permite utilizarea fără încredere a jetoanelor complete non-Turing cu contracte inteligente.
Flare Este prima rețea completă a Acordului Bizantin federalizat Turing (FBA) din lume. Nodurile rulează Protocolul de consens Avalanche cu o adaptare cheie la topologia consensului FBA. FBA este unic ca topologie de consens prin faptul că atinge siguranța fără a se baza pe stimulente economice care pot interfera cu cazurile de utilizare cu valoare ridicată și cu risc ridicat. O critică a FBA pură este că duce la structuri fragile ale nodurilor constitutive, permițând scenarii de topologie în care un eșec al unui singur nod poate provoca un eșec la nivel de rețea. Din acest motiv, este prioritizată o setare specifică a FBA numită topologie unique Node List (UNL) care subliniază claritatea și ușurința de utilizare, menținând în același timp proprietatea de membru deschis a FBA. Suprapunerea procentuală a UNL este un parametru definit de guvernanță, cu o suprapunere mai mică îmbunătățind proprietatea de membru deschis a rețelei. Rețeaua Flare utilizează mașina virtuală Ethereum (EVM), permițând rețelei să ruleze contracte inteligente complete Turing.
la lansarea rețelei, construit pe partea de sus a Flare este apoi un protocol pentru a permite în condiții de siguranță emiterea trustless, utilizarea și răscumpărarea, de XRP pe Flare. Acest protocol se numește FXRP. XRP devine în siguranță și fără încredere FXRP, pe Flare, securizat de jetonul nativ al lui Flare, Spark. XRP există acum într-o rețea completă Turing și, odată ajuns acolo, interoperabilitatea fără încredere cu alte rețele este fezabilă, atât prin protocoale de interoperabilitate, cum ar fi Cosmos și Polkadot, fie cu Ethereum prin protocoale de punte bine definite. Pe scurt: Flare poate fi folosit ca o platformă de contract inteligent pentru XRP sau ca o conductă trustless pentru XRP la alte rețele.mai mult, metodologia generală a FXRP este extensibilă la orice token complet non-Turing și capacitatea de a decide ce alte token-uri să susțină și apoi să extindă mijloacele pentru a face acest lucru este încorporată în sistemele și guvernanța rețelei.
Flare reunește valoarea token-urilor complete non-Turing cu puterea transformatoare a contractelor inteligente într-o rețea care poate scala pentru valoare, precum și pentru transferul tranzacțiilor.
Prezentare generală FXRP
complexitatea obținerii XRP pe Flare este că nu există nicio modalitate pentru un contract inteligent pe un blockchain public de a controla o adresă din registrul XRP. Motivul pentru aceasta este că contractele inteligente nu au în prezent o modalitate adecvată de a stoca o cheie secretă într-un mod care este cu adevărat secret. Pentru a obține XRP pe Flare folosind doar codul ar necesita un grup de participanți să vină împreună cu o adresă cu mai multe semnături pe care o controlează colectiv, prin care, dacă K de N părți semnează o tranzacție, tranzacția este autorizată. Orice utilizator al unui activ emis de această adresă multisig ar trebui apoi să aibă încredere în acea colecție de utilizatori și, prin urmare, activul nu ar fi nici fără încredere, nici descentralizat.
FXRP permite în condiții de siguranță un suport XRP (un inițiator) pentru a trimite XRP lor la un set de adrese (numite agenți) pe registrul XRP. Contractele inteligente FXRP pe Flare emit apoi inițiatorul FXRP pe Flare, care este 1: 1 convertibil cu XRP și securizat cu Spark. Atunci când un titular de FXRP dorește să-l răscumpere pentru XRP ( un Răscumpărător) îl trimit înapoi la contractele inteligente fxrp pe Flare. Agenții trimit apoi XRP la adresa răscumpărătorilor din registrul XRP. Dacă agenții nu finalizează această răscumpărare suficient de repede, Răscumpărătorul este compensat valoarea XRP-ului lor plus o sumă pentru a compensa costurile tranzacției pentru a recumpăra XRP-ul.
cu FXRP, nu este nevoie de intermediar centralizat.
fxrp funcționează după cum urmează:
proprietarii jetonului nativ Flare, Spark, își pot trimite jetoanele la o colecție de contracte inteligente pe Flare care sunt denumite sistemul FXRP. Utilizatorii care fac acest lucru oferă garanții sistemului FXRP. Sunt numiți agenți. Să-l sunăm pe unul dintre agenții Bob. Vor fi mulți agenți în sistemul FXRP.
Să presupunem că Bob a introdus 5000 de Jetoane Spark în sistemul FXRP. În acest exemplu, 10 jetoane Spark pot fi cumpărate în prezent pentru 1 jeton XRP. Sistemul fxrp cere un raport de garanție de 2,5, ceea ce înseamnă că în orice moment un agent trebuie să fi furnizat sistemului de 2,5 ori valoarea FXRP pe care sistemul le-a repartizat în jetoane Spark. FXRP este evaluat aici ca 1: 1 cu XRP. Prin urmare, jetoanele 5000 Spark ale lui Bob permit sistemului să emită 200 FXRP.
când cineva, să zicem Alice, vrea să creeze FXRP, trimite o tranzacție către sistemul FXRP cu o taxă fixă de 0,1% din valoarea XRP pe care doresc să o introducă în FXRP. Alice este numit un inițiator. Tranzacția spune, de asemenea, sistemului FXRP la ce adresă să trimită FXRP la Flare, odată ce este bătută și de la ce adresă va proveni XRP din Registrul XRP. Dacă există o capacitate disponibilă în sistemul FXRP, garanția pentru a asigura cantitatea de FXRP creată este blocată pentru o anumită perioadă împotriva tranzacției viitoare a lui Alice. În acest fel, Alice nu trebuie să aibă încredere în Bob. În schimb, sunt generate un set de instrucțiuni pentru ca Alice să-i spună la ce adresă (adresa lui Bob) să trimită XRP în registrul XRP și la ce ultimul index al Registrului să folosească. Dacă nu există capacitatea în sistem de a emite suma dorită de FXRP, atunci Alice este rambursată taxa.Alice trimite apoi suma corectă de XRP plus o taxă de creare în XRP la adresa lui Bob din registrul XRP. Taxa de creare este cea mai mare parte a banilor pe care Bob îi va câștiga pentru blocarea garanției Spark, rețineți că câștigurile sale sunt predominant în XRP. Flare observă această tranzacție folosind un sistem numit conector de stare, definit în secțiunea 2 a Cărții albe Flare (și subiectul unei viitoare postări pe blog). FXRP este apoi bătut de sistem și livrat la adresa nominalizată a lui Alice pe Flare.
raportul colateral de 2,5 x trebuie menținut în permanență. În cazul în care prețul de XRP crește împotriva Spark, astfel încât valoarea garanției Bob scade sub 2.De 5 ori FXRP emis împotriva acestuia, atunci Bob are un timp limitat fie pentru a adăuga mai multe jetoane Spark ca garanție, fie pentru a cumpăra și răscumpăra jetoane FXRP pentru a-și readuce raportul de garanție. De exemplu, să zicem că 200 de Jetoane FXRP sunt emise împotriva celor 5000 de Jetoane Spark ale lui Bob, iar prețul XRP/Spark crește la 12. Bob trebuie acum să adauge 1000 Spark la sistem sau să cumpere și să răscumpere 33.34 FXRP pentru a reduce repartizarea lui de fxrp emis la 166.66.
dacă Bob nu are acces la jetoane Spark suplimentare, nu este oneros din punct de vedere financiar pentru el să reducă soldul FXRP susținut de adresa sa. Garanția lui Bob a permis sistemului FXRP să emită 200 de Jetoane FXRP, în procesul de a face acest lucru, Bob a primit 200 de jetoane XRP pe registrul XRP. Astfel, dacă Bob nu are capital suplimentar pentru a cumpăra jetoane Spark, el poate vinde suficient XRP pentru FXRP pe un schimb, astfel încât să poată răscumpăra cel puțin 33.34 FXRP sau să rămână într-un mediu pur descentralizat dacă există alți agenți în sistemul FXRP cu suficientă garanție în exces, el poate monta suficient FXRP și îl poate răscumpăra imediat. Al doilea scenariu mută în esență obligația către restul sistemului. Dacă Bob nu face nimic și rămâne în mod implicit față de raportul de garanție, garanția lui Bob va fi licitată automat pentru suma de FXRP emisă împotriva sa, care în acest caz este de 200. Bob păstrează orice garanție rămasă după această operațiune.
să spunem că Bob a optat pentru a adăuga scânteie suplimentare ca garanție. Acum, ceva timp mai târziu, Alice, care deține toate cele 200 de fxrp emise, dorește să răscumpere întreaga sumă înapoi în registrul XRP. Alice face pur și simplu o tranzacție cu sistemul FXRP trimițând FXRP către sistem și spunându-i ce adresă dorește creditată. Sistemul emite apoi un set de instrucțiuni pentru Bob spunându-i cât de mult XRP pentru a trimite și în cazul în care, împreună cu două termene XRP număr de registru prin care tranzacția trebuie să fie finalizată. Dacă Bob finalizează tranzacția până la primul termen, garanția lui este deblocată în întregime. Dacă Bob eșuează până la primul termen, dar reușește până la al doilea, i se percepe o mică taxă de penalizare, iar restul garanției sale este deblocat. Taxa de penalizare este arsă.
dacă Bob nu reușește să finalizeze tranzacția până la al doilea termen, se numește eșec de răscumpărare. Alice este apoi compensată cu jetoane Spark la valoarea XRP-ului răscumpărat plus o creștere de 1% pentru a acoperi costurile tranzacției de cumpărare a XRP-ului, aceasta fiind extrasă din garanția lui Bob. Din garanția rămasă a lui Bob, 50% este arsă ca pedeapsă, iar ceilalți 50% i-au revenit. Alice poate cumpăra apoi înlocuirea XRP pe un schimb. Alternativ, presupunând că există alți agenți pe Flare cu fxrp emis și oameni care doresc să-l vândă, Alice poate cumpăra mai mult FXRP pe Flare și să-l răscumpere împotriva acestor agenți.
Aplicații Spark și dependente
FXRP este primul exemplu de ceva ce numim o aplicație dependentă de scânteie (SDA). Un SDA este definit ca o aplicație care utilizează în construcția sa o combinație de: Spark pentru garanție, seria de timp Flare Oracle și deținătorii de Jetoane Spark pentru Guvernare. Fiecare dintre aceste elemente este în întregime opțională și o aplicație poate funcționa pe Flare interacționează numai cu Spark pentru plata costurilor de tranzacție. De exemplu, fxrp folosește Spark ca garanție, seria de timp Flare Oracle pentru prețul XRP/Spark și proprietatea Spark token setată pentru guvernanță asupra anumitor parametri, cum ar fi taxa de creare FXRP și raportul de garanție. Modelul SDA este destinat să ofere un șablon pentru extinderea fiecăreia dintre cele trei componente la un număr arbitrar de aplicații. Utilizarea Spark ca garanție în toate aplicațiile este simplă, cel mai important element a fost să luăm în considerare modul în care ar putea fi creată o metodologie oracle sigură pe mai multe serii de timp.
Flare Time Series Oracle
proprietatea asupra jetonului Spark permite contribuția la seria de timp Flare Oracle (FTSO). Scopul FTSO este de a forma estimări exacte ale datelor privind Flare din afara lanțului, păstrând în același timp descentralizarea. FTSO este structurat pentru a oferi multe estimări ale seriilor de timp individuale. Prețul XRP / Spark este un exemplu de o singură serie de timp.
fiecare serie de timp de ieșire de FTSO va avea, în general, două grupuri de participanți: primul fiind deținătorii de Jetoane Spark și al doilea fiind deținătorii jetonului de aplicație dependent, care este denumit F-activ. În aplicația FXRP, activul F este jetonul fxrp în sine. Pentru o aplicație mai complexă, cum ar fi o aplicație derivată în care aplicația necesită mai multe serii de timp, activul F poate fi ceva mai asemănător cu un jeton de guvernare emis.
pentru fiecare serie de timp, FTSO solicită fiecărui set relevant de participanți să furnizeze o estimare. Deținătorii Spark vor furniza estimări pentru toate seriile de timp, iar deținătorii de active F vor furniza estimări numai pentru seriile de timp legate de activele lor F. Aceste estimări sunt apoi prelucrate astfel cum sunt definite în secțiunea 4 din Cartea albă Flare și de ieșire de către sistem.
stimulentul pentru deținătorii de active F de a furniza date sistemului este siguranța aplicării lor. Deținătorii de Jetoane Spark sunt stimulați de potențialul de a câștiga ceva numit recompensa oracle. Aceasta este o cantitate de Jetoane Spark care sunt bătute de sistem. Recompensa oracle este o rată anuală împărțită uniform pe fiecare perioadă de estimare a FTSO. De exemplu, dacă rata este de 10%, există 365 de estimări într-un an și un număr inițial de Jetoane Spark de 100, atunci 10 Spark va fi creat în 1 an și ~0,03 Spark bătute și recompensate pe zi. Contribuitorii Spark token pot câștiga această recompensă contribuind cu date care sunt considerate a fi „corecte”. Mecanica precisă este prezentată în Cartea albă. Este important ca toți deținătorii de Jetoane Spark să fie pariați implicit în sistem ca și cum nu ar câștiga recompensa fie prin neparticipare, fie prin furnizarea de estimări „incorecte” pe care le pierd valoare deținătorilor de jetoane care sunt recompensați. Aceasta este versiunea Flare de recompense bloc.
FTSO va fi inițiat pentru a furniza următoarele prețuri pentru: XRP/Spark, USD/Spark, BTC/Spark și XLM / Spark. Numai XRP / Spark va avea un activ F corespunzător la început. Seriile de timp suplimentare și activele F aferente acestora pot fi propuse și acceptate prin procesul de guvernanță.
Delegația
FTSO va furniza în realitate estimări la fiecare două secunde. Nu orice suport Spark va dori sau va putea rula hardware pentru a contribui la FTSO și, separat, s-ar putea să nu fie interesat să voteze pentru Guvernanța rețelei. Prin urmare, voturile pentru ambele responsabilități pot fi detașate de tokenul însuși și delegate separat altor părți. Delegarea poate fi anulată în orice moment, iar atunci când un token este transferat de la o adresă la alta, delegarea este anulată automat, astfel încât drepturile de vot să meargă cu tokenul. Mecanismul permite, de asemenea, SDA-urilor, cum ar fi FXRP, să delege voturile Spark înapoi proprietarului final, care poate apoi să delege aceste voturi în continuare entităților pe care dorește să le voteze în numele său. Deci, dacă Bob are 5000 de Jetoane Spark în aplicația FXRP, va delega voturile de la acele jetoane la o adresă specificată de Bob. Dacă Bob dorește ca un furnizor de date dedicat să contribuie la FTSO în numele său, Bob își poate delega voturile pentru FTSO furnizorului de date. Foarte important, acest lucru înseamnă că Bob nu trebuie să aleagă între câștigarea Spark prin furnizarea de garanții pentru aplicația FXRP și câștigarea potențială a recompensei de la FTSO, el poate face ambele. Orice SDA care face ca jetoanele Spark să fie indisponibile proprietarilor lor subiacenți, cu condiția să existe o definiție în aplicație cu privire la cine este proprietarul subiacent, poate implementa procedura de delegare.
guvernanță& Fundația
Flare este guvernată în întregime de deținătorii de Jetoane Spark prin vot. SDA-urile pot solicita opțional să fie guvernate de deținătorii de Jetoane Spark.
anumite decizii pot fi luate în mod automat în lanț, cum ar fi modificarea costului tranzacției, rata de recompensă oracle sau, privind FXRP ca SDA, modificarea raportului de garanție și a comisionului de creare. Alte decizii, cum ar fi adăugarea unei noi serii de timp la FTSO și conectarea activului F propus, modificarea parametrilor consensului rețelei sau actualizări mai complexe pe termen lung necesită o modificare a codului. Cartea albă Flare stabilește un regim de propunere, dezvoltare și testare pentru modificările manuale care pot fi inițiate și votate de deținătorii de Jetoane Spark. Pentru a ajuta la implementarea acestui proces și la executarea modificărilor convenite, va exista o fundație Flare. Fundația va fi o organizație non-profit, care va fi încorporată în lunile următoare. Acesta va fi responsabil pentru 5 domenii cheie: granturi, investiții, cercetare și dezvoltare, Educație, publicitate și parteneriate.
este funcția de cercetare și dezvoltare care permite fundației să fie o parte integrantă a procesului de actualizare a rețelei, chiar mergând atât de departe încât să analizeze, să raporteze și apoi să construiască, să testeze și să implementeze modificările propuse ale codului de rețea.
fundația trebuie să fie foarte transparentă și să nu irosească bani. Două rapoarte pe an privind activitățile și cheltuielile sale vor fi respectate și publicate. Fundația este destinată doar să ia direcția de la deținătorii de Jetoane Spark și să nu stabilească ordinea de zi. Ca atare, nu poate: să contribuie în niciun fel la FTSO, să desfășoare oricare dintre participațiile sale Spark ca garanție pentru orice aplicație din rețea și nu poate utiliza participațiile sale Spark pentru a vota în niciun vot de guvernanță. Nu poate atribui jetoanele Spark altora pentru a face acest lucru. Mai mult, scris în Constituția fundației va fi obligația ca, dacă un vot de guvernare este de acord că fundația nu mai servește unui scop benefic, atunci fundația trebuie să-și încheie activitățile și să-și ardă toate deținerile de jetoane rămase cât mai curând posibil.
emiterea de scântei
cea mai bună comunitate care deține activul care permite utilizarea XRP cu contracte inteligente Turing complete este comunitatea care îl va folosi și va beneficia de acesta: deținătorii XRP. Flare nu face un ITO. În schimb, face ceea ce numim o furculiță de utilitate. Credem că este primul de acest gen.
o furculiță a căutat în mod tradițional să ia baza de utilizatori a unei rețele existente și să se îndepărteze în întregime de acea rețea, de obicei pentru a avea o relație antagonică cu lanțul original. În schimb, o furcă utilitară este destinată să readucă valoarea lanțului original în loc să se îndepărteze de acesta. Flare permite XRPL face ceea ce face cel mai bine, decontare rapid, în timp ce aduce la xrpl, contracte inteligente și fezabilitatea de a crea o conductă de încredere la alte blockchains. Credem că aceasta este o combinație cu adevărat puternică și un exemplu perfect de utilitate.
100 miliarde de Jetoane Spark vor fi create pentru a reflecta cantitatea de XRP care există. Există aproximativ 45 de Jetoane Bn XRP care nu aparțin Ripple labs. Obiectivul distribuției este ca deținătorii XRP, alții decât Ripple, să poată solicita aproximativ o cantitate de scânteie 1:1 la exploatația lor XRP. 45 BN Spark va fi revendicat de către deținătorii XRP (eliminarea adreselor cunoscute Ripple labs). 25 BN Spark va merge la Flare Networks Limited, care este organizația cu scop lucrativ a Flare. 30 BN Spark va merge la Fundația Flare.
deoarece mulți proprietari XRP folosesc de fapt schimburi pentru a-și păstra jetoanele XRP, există posibilitatea ca un titular de XRP care dorește să revendice jetoanele Spark să nu poată, deoarece fie schimbul revendică scânteia și le păstrează, mai degrabă decât să le transmită, sau alternativ nu le revendică deloc. Pentru a permite proprietarilor XRP să participe la distribuție fie prin presarea schimbului lor pentru a distribui jetoanele Spark, fie pentru a muta schimbul la unul care face, instantaneul registrului XRP va fi luat la o dată mai apropiată de lansare. O listă a schimburilor participante va fi postată pe site-ul Flare și actualizată periodic. Numărul registrului instantaneu va fi postat pe site-ul web atunci când instantaneul a fost realizat.
TL;DR
Flare Este prima rețea completă a Acordului Bizantin federalizat Turing (FBA) din lume. Acesta integrează mașina virtuală Ethereum (EVM) și nu obține siguranță dintr-un jeton. În plus, este construit un protocol pentru a permite în siguranță emiterea, utilizarea și răscumpărarea fără încredere a XRP pe Flare. Acest protocol se numește FXRP. Metodologia generală a protocolului și a sistemului care conectează Flare la alte rețele este extensibilă la orice token complet non-Turing. Interoperabilitatea fără încredere cu alte rețele este fezabilă, atât prin protocoale de interoperabilitate, cum ar fi Cosmos și Polkadot, fie cu Ethereum prin protocoale de punte bine definite.
jetonul lui Flare, Spark este creat prin ceea ce poate fi prima furculiță de utilitate prin care rețeaua de origine, în acest caz Registrul XRP, beneficiază prin utilitate sporită. 100 miliarde de Jetoane Spark vor fi create la începutul rețelei Flare, din care 45 miliarde vor fi revendicate de deținătorii XRP existenți, cu excepția Ripple Labs. Aceasta reflectă cantitatea existentă de XRP distribuită, astfel încât deținătorii XRP actuali vor putea revendica aproximativ 1 jeton Spark pentru fiecare jeton XRP deținut. 25 miliarde de jetoane vor merge la dezvoltatori, Flare, iar 30 miliarde de jetoane vor merge la o fundație non-profit numită Fundația Flare. Deținătorii de Jetoane Spark pot câștiga o rentabilitate a jetoanelor Spark atât prin comiterea jetoanelor Spark ca garanție pentru a asigura emiterea și răscumpărarea fără încredere a FXRP, cât și prin contribuția datelor la seria de timp Flare oracle. Aceste funcții nu concurează între ele.
jetonul Spark este utilizat pentru Guvernanța rețelei prin vot. Cu excepția granturilor și a investițiilor pentru a ajuta la dezvoltarea Flare, Fundația ia direcția tehnică de la proprietarii de Jetoane Spark. Un rol cheie al fundației este de a ajuta la executarea actualizărilor și modificărilor rețelei, convenite prin vot de guvernare, care nu pot fi implementate fără o modificare a codului. Important, scris în Constituția fundației, va fi un statut că fundația trebuie să fie lichidată și toate jetoanele Spark deținute de fundație arse, dacă deținătorii de Jetoane Spark sunt de acord că existența sa nu mai este benefică pentru rețea.
Flare reunește valoarea token-urilor complete non-Turing cu puterea transformatoare a contractelor inteligente într-o rețea care poate scala pentru valoare, precum și pentru transferul tranzacțiilor.
răspunsuri la două întrebări:
este Spark crearea dovada miza de backdoor?
numai jetoanele emise care necesită garanții, cum ar fi FXRP, sunt securizate cu Spark. Rețeaua nu folosește Spark pentru siguranță în a ajunge la consens.
am avut (ceea ce credem că sunt) concepte foarte puternice pentru o monedă stabilă denominată în USD, dar a necesitat o re-inginerie extinsă a mașinii virtuale Ethereum, care ar fi întârziat lansarea și ar fi avut efecte imprevizibile asupra compatibilității viitoare cu EVM. Spark așa cum este structurat, oferă o utilitate și beneficii mult mai mari atât comunității XRP, cât și registrului XRP.