I Dag er vi glade for å gjøre våre detaljerte planer for distribusjon av Flare Network offentlig. Disse planene kan utforskes fullt ut ved å dykke inn i utkastet til hvite papirer som dekker Nettverket og dets innfødte token, Spark (her) og trustless integrering AV XRP med Flare (her). Papirene er i utkast, og det vil bli optimaliseringsendringer mellom nå og dagen Flare går live. Det bør ikke være endringer som vesentlig avviker fra oversikten nedenfor. I dette innlegget tar vi sikte på å markere det vi anser for å være de viktigste aspektene Av Flare. En minimal teknisk oversikt over hver viktig komponent vil bli lagt ut i løpet av de følgende ukene, starter senere denne uken med en gjennomgang Av Flare trustless integrering AV XRP, FXRP. Spenn deg fast!

(EN TL;DR er på slutten av dette innlegget.)

Hva Er Flare og hvorfor bygger vi det?

Flare eksisterer for å løse to viktige problemer:for det første, og av umiddelbar betydning for å bygge ut av vår bransje, er at 75% av verdien som eksisterer i offentlig blockchain for tiden ikke kan brukes på en trustless måte med smarte kontrakter.For det Andre, og av både kortsiktige og langsiktige konsekvenser, er det potensielle problemer med hvordan skalering implementeres for smarte kontraktsnettverk i dag. De fleste nye nettverk bruker Proof of Stake eller dens varianter. Disse protokollene utlede nettverkssikkerhet fra deres opprinnelige token.det umiddelbare problemet som ligger i Proof of Stake er at konsensusdesignet ennå ikke trygt tillater alternativ bruk av det innfødte token. Hvis en tokenholder kan oppnå høyere avkastning (og uten mulighet for slashing) ved å gi sikkerhet for å skape en stablecoin enn de kan fra staking, da som økonomiske rasjonalister, vil de sannsynligvis gjøre det. Dette avleder tokens vekk fra staking og kannibaliserer sikkerheten til nettverket. (En svært innsiktsfull artikkel om dette emnet er her. Vi mistenker at Dette kanskje er den viktigste grunnen til At Til tross for å ha relativt høyere transaksjonskostnader og langt lavere transaksjonsgjennomstrømning, Er Ethereum fortsatt ledende i DeFi.et langsiktig problem er at Når Et Bevis på Bruk av Innsatsnettverket øker og verdien som er bygget på toppen av den øker, må verdien av staking-token øke eller nettverket blir usikkert. Dette er flott for investorer i token, men dårlig for folk som ønsker å se desentralisering bli en del av den vanlige måten å gjøre forretninger på. Hvorfor? Fordi for at tokenverdien som sikrer nettverket skal stige, må kapitalen omdirigeres fra annen bruk for å kjøpe token. Tatt til det logiske endepunktet, hvis smarte kontraktsnettverk ved hjelp av bevis på innsats skulle bli den allestedsnærværende metoden for å drive forretninger, ville omfanget av avledning av kapital som kreves fra andre bestrebelser, bare for å sikre verdien bygget på disse nettverkene, gjøre kostnadene for handel unfeasibly høy. Av denne grunn er det ekstremt usannsynlig å skje. Proof of Stake og varianter kan skalere transaksjonsgjennomstrømming, men eksisterende implementeringer kan ikke skalere for verdi. Etter vår mening Er Proof of Stake mer en stopp enn en løsning.

hvordan Løser Flare disse problemene?

Flare er i sin kjerne en ny måte å skalere smarte kontraktplattformer som ikke knytter sikkerhet til verdien av token. Flare krever fortsatt et token for driften av nettverket, hovedsakelig for å avskrekke spamtransaksjoner. Flare ‘ s token kalles Gnist. Fordi Spark ikke har nettverkssikkerhetsimplikasjoner, er Det godt egnet for å muliggjøre trustless bruk av ikke-Turing komplette tokens med smarte kontrakter.Flare Er verdens første Turing complete Federated Byzantine Agreement (Fba) nettverk. Noder kjøre Avalanche konsensus protokollen med en nøkkel tilpasning TIL FBA konsensus topologi. FBA er unik som en konsensustopologi ved at den oppnår sikkerhet uten å stole på økonomiske insentiver som kan forstyrre høyverdige og høyrisiko brukssaker. En kritikk av ren FBA er at den fører til skjøre strukturer av bestanddeler, noe som tillater topologiske scenarier der en enkelt knutefeil kan forårsake en nettverksfeilfeil. Av denne grunn prioriteres en bestemt innstilling AV FBA kalt En Unik Node List (UNL) topologi som legger vekt på klarhet og brukervennlighet samtidig som fbas åpne medlemskapsegenskap opprettholdes. Den prosentvise overlapping AV UNL er en styring definert parameter, med en lavere overlapping forbedre åpen-medlemskap eiendom av nettverket. Flare-Nettverket utnytter Ethereum Virtual Machine (EVM), slik at nettverket kan kjøre Turing komplette smarte kontrakter.

ved nettverksstart, bygget på Toppen Av Flare, er da en protokoll for å aktivere trustless utstedelse, bruk og innløsning AV XRP på Flare. Denne protokollen kalles FXRP. XRP trygt og tillitsløst blir FXRP, På Flare, sikret Med Flare native token, Spark. XRP eksisterer nå effektivt på Et Turing-komplett nettverk, og når det er der, er trustless interoperabilitet med andre nettverk mulig, både gjennom interoperabilitetsprotokoller som Cosmos og Polkadot eller Med Ethereum via veldefinerte broprotokoller. Kort: Flare kan brukes som en smart kontrakt plattform FOR XRP eller som en trustless rørledning FOR XRP til andre nettverk.Videre er den generelle metodikken TIL FXRP utvidbar til enhver ikke-Turing komplett token, og evnen til å bestemme hvilke andre tokens som skal støtte og deretter utvide midler for å gjøre det, er innebygd i systemene og styringen av nettverket.Flare samler verdien av de ikke-Turing komplette tokens med den transformative kraften til smarte kontrakter på et nettverk som kan skalere for verdi samt transaksjonsgjennomstrømning.

Fxrp Oversikt

kompleksiteten ved å få XRP på Flare er at det ikke er mulig for en smart kontrakt på en offentlig blockchain å kontrollere en adresse på XRP-hovedboken. Årsaken til dette er at smarte kontrakter for tiden ikke har tilstrekkelig måte å lagre en hemmelig nøkkel på en måte som er virkelig hemmelig. For Å få XRP på Flare bruker bare kode ville kreve noen gruppe deltakere til å komme sammen med en multi signatur adresse som de kollektivt kontroll, der hvis k av n parter signere en transaksjon transaksjonen er autorisert. Enhver bruker av en eiendel utstedt av denne multisig-adressen må da stole på at samlingen av brukere, og dermed vil eiendelen ikke være tillitsløs eller desentralisert.

FXRP tillater en xrp-holder (en opphavsmann) å sende SIN XRP til et sett med adresser (kalt agenter) på Xrp-Hovedboken. FXRP smarte kontrakter På Flare utsteder deretter opphavsmannen FXRP På Flare som er 1: 1 konvertibel MED XRP og sikret Med Gnist. Når en innehaver av FXRP ønsker å innløse DEN FOR XRP (en forløser), sender de den tilbake til FXRP smart contracts on Flare. Agentene sender DERETTER XRP til innløseradressen på xrp-hovedboken. Hvis agentene ikke fullfører denne innløsningen raskt nok, kompenseres forløseren VERDIEN av XRP pluss et beløp for å kompensere for transaksjonskostnader for å kjøpe XRP på nytt.

MED FXRP er det ikke nødvendig med sentralisert mellommann.

FXRP fungerer som følger:

Eiere Av Flare ‘ s native token, Spark, kan sende sine tokens til en samling smarte kontrakter på Flare som refereres TIL SOM FXRP-systemet. Brukere som gjør dette gir sikkerhet TIL FXRP-systemet. De kalles agenter. La Oss ringe En av agentene Bob. Det vil være mange agenter I FXRP-systemet.

La Oss si At Bob har satt inn 5000 Spark tokens I FXRP-systemet. I dette eksemplet kan 10 Spark-tokens for øyeblikket kjøpes for 1 XRP-token. FXRP-systemet krever et sikkerhetsforhold på 2,5, noe som betyr at en agent til enhver tid må ha gitt systemet 2,5 ganger verdien AV FXRP systemet har fordelt til Dem I Spark-tokens. FXRP er verdsatt her som 1: 1 MED XRP. Derfor Tillater Bobs 5000 Spark tokens systemet å utstede 200 FXRP.

Når Noen, Sier Alice, ønsker å lage FXRP, sender De en transaksjon TIL fxrp-systemet med et fast gebyr på 0.1% av verdien AV XRP som de vil mynte INN I FXRP. Alice kalles en opphavsmann. Transaksjonen forteller OGSÅ fxrp-systemet hvilken adresse du skal sende FXRP til På Flare, når DEN er myntet, og hvilken adresse XRP kommer fra PÅ Xrp-Hovedboken. Hvis DET er ledig kapasitet I fxrp-systemet, er sikkerhet for å sikre mengden FXRP som opprettes, låst i en viss periode mot Alices kommende transaksjon. På Denne Måten Trenger Alice ikke å stole På Bob. Til gjengjeld genereres Et sett med instruksjoner for Alice å fortelle henne hvilken adresse (Bobs adresse) for å sende XRP til PÅ XRP-hovedboken og hvilken siste hovedbokindeks som skal brukes. Hvis det ikke er kapasitet i systemet til å utstede ønsket MENGDE FXRP, blir Alice refundert gebyret.

Alice sender deretter riktig MENGDE XRP pluss et etableringsgebyr I XRP Til Bobs adresse PÅ xrp-hovedboken. Etableringsavgiften er den store delen av pengene Bob vil tjene for å låse Opp Gnistsikkerheten, merk at inntektene hans hovedsakelig er I XRP. Flare observerer denne transaksjonen ved hjelp Av et system kalt State Connector, definert i Seksjon 2 I Flare white paper (og gjenstand for et fremtidig blogginnlegg). FXRP blir deretter myntet av systemet og levert Til Alices nominerte adresse På Flare.

2,5 x sivile forhold må opprettholdes til enhver tid. HVIS prisen PÅ XRP øker mot Spark, slik at verdien Av Bobs sikkerhet faller under 2.5 ganger fxrp utstedt mot Det, Så Har Bob en begrenset tid til å enten legge til Flere Spark-tokens som sikkerhet eller kjøpe OG innløse FXRP-tokens for å bringe sikkerhetsforholdet tilbake i kø. For eksempel, si 200 FXRP tokens utstedes mot Bobs 5000 Spark tokens og prisen PÅ XRP / Spark øker til 12. Bob må nå enten legge til 1000 Spark til systemet eller kjøpe og innløse 33.34 FXRP for å redusere sin fordeling av utstedt FXRP til 166.66.

Hvis Bob ikke har tilgang til flere Spark-tokens, er det ikke økonomisk tungt for HAM å redusere balansen I FXRP støttet av adressen hans. Bobs sikkerhet gjorde DET MULIG FOR fxrp-systemet å utstede 200 fxrp-tokens, i Ferd Med Å Gjøre Det, Har Bob mottatt 200 XRP-tokens på xrp-hovedboken. Dermed Hvis Bob ikke har ekstra kapital til å kjøpe Spark tokens, kan Han enten selge tilstrekkelig XRP FOR FXRP på en børs slik at Han kan innløse minst 33.34 FXRP eller forbli i et rent desentralisert miljø hvis det er andre agenter I FXRP-systemet med tilstrekkelig overskytende sikkerhet i han kan mynte tilstrekkelig FXRP og umiddelbart innløse den. Det andre scenariet skifter i hovedsak forpliktelsen til resten av systemet. Hvis Bob ikke gjør noe og forblir i mislighold mot sikkerhetsforholdet, Blir Bobs sikkerhet automatisk auksjonert bort for MENGDEN FXRP utstedt mot den, som i dette tilfellet er 200. Bob beholder gjenværende sikkerhet etter denne operasjonen.

La Oss si At Bob valgte å legge til Ekstra Gnist som sikkerhet. Nå en tid Senere Alice som eier alle 200 utstedt FXRP ønsker å innløse hele beløpet tilbake TIL xrp hovedbok. Alice gjør bare en transaksjon MED FXRP-systemet som sender FXRP til systemet og forteller det hvilken adresse hun vil krediteres. Systemet utsteder deretter et sett med instruksjoner Til Bob som forteller ham hvor MYE XRP skal sende og hvor sammen med to xrp ledger nummer tidsfrister som transaksjonen må fullføres. Hvis Bob fullfører transaksjonen innen den første fristen, er hans sikkerhet helt låst opp. Hvis Bob mislykkes innen den første fristen, men lykkes med den andre, blir Han belastet et lite straffegebyr og resten av hans sikkerhet er låst opp. Straffegebyret er brent.

Hvis Bob ikke fullfører transaksjonen innen den andre fristen, kalles Det en innløsningsfeil. Alice kompenseres deretter Med Spark tokens til verdien av hennes innløste XRP pluss en 1% økning for å dekke transaksjonskostnader ved å kjøpe TILBAKE XRP, dette er hentet Fra Bobs sikkerhet. Av Bobs gjenværende sikkerhet blir 50% brent som en straff og de andre 50% returnerte til ham. Alice kan da kjøpe erstatning XRP på en børs. Alternativt, forutsatt at det er andre agenter På Flare med utstedt FXRP og folk som ønsker å selge Det, Kan Alice kjøpe MER FXRP på Flare og innløse det mot disse agentene.

Gnist Og Avhengige Applikasjoner

FXRP ER det første eksempelet på noe vi kaller En Gnistavhengig Applikasjon (Sda). EN SDA er definert som et program som bruker i sin konstruksjon en kombinasjon av: Spark for collateral, Flare Time Series Oracle og Spark token holders for governance. Hver av disse elementene er helt valgfritt, og et program kan operere På Flare bare samspill Med Spark for betaling av transaksjonskostnader. FXRP bruker For eksempel Spark som collateral, Flare Time Series Oracle for XRP / Spark-prisen og Spark token eierskap satt for styring over visse parametere som fxrp creation fee og collateral ratio. SDA-modellen er ment å gi en mal for å utvide hver av de tre komponentene til et vilkårlig antall applikasjoner. Å bruke Spark som sikkerhet på tvers av alle applikasjoner er grei, det viktigste elementet var å vurdere hvordan en sikker oracle-metodikk kunne opprettes over flere tidsserier.

Flare Time Series Oracle

Eierskap Av Spark token tillater bidrag til Flare Time Series Oracle (FTSO). FORMÅLET MED FTSO er å danne nøyaktige estimater av data på Flare fra off-chain samtidig beholde desentralisering. FTSO er strukturert for å gi mange estimater av individuelle tidsserier. XRP / Spark-prisen er et eksempel på en enkelt tidsserie.

hver tidsserieutgang av FTSO vil vanligvis ha to grupper av deltakere: den første Er Spark token holdere og den andre er innehavere av den avhengige applikasjonstoken, som kalles En F-eiendel. I fxrp-applikasjonen Er F-asset SELVE fxrp-token. For en mer kompleks applikasjon som en derivatapplikasjon der søknaden krever flere tidsserier, Kan F-aktiva være noe mer lik en utstedt styringstoken.

FOR hver tidsserie ber FTSO hvert relevant sett med deltakere om å gi et estimat. Spark holdere vil gi estimater for alle tidsserier Og f-Asset holdere vil gi estimater over bare tidsserier knyttet til Deres F-Aktiva. Disse estimatene blir deretter behandlet som definert i avsnitt 4 I Flare whitepaper og utgang av systemet.

incitamentet For f-asset-innehavere til å gi data til systemet er sikkerheten til deres søknad. Spark token holdere er incentivized av potensialet til å tjene noe som kalles oracle reward. Dette er en mengde Spark tokens som er myntet av systemet. Oracle belønning er en årlig rate delt jevnt over hver FTSO estimat periode. For eksempel, hvis prisen er 10%, er det 365 estimater om et år og et startnummer Av Spark-tokens på 100, så vil 10 Gnist bli opprettet om 1 år og ~0,03 Gnist myntet og belønnet per dag. Spark token-bidragsytere kan tjene denne belønningen ved å bidra med data som anses å være «riktige». Den nøyaktige mekanikken er angitt i hvitboken. Det er viktig at Alle Spark token-holdere er implisitt staket i systemet som om de ikke tjener belønningen enten gjennom ikke-bidrag eller gir «feil» estimater de mister verdi til token-holdere som belønnes. Dette Er Flare versjon av block rewards.FTSO vil bli initiert for Å gi følgende priser FOR: XRP/Spark, USD/Spark, BTC/Spark og XLM / Spark. Bare XRP / Spark vil ha en tilsvarende F-eiendel i begynnelsen. Ytterligere tidsserier og Tilhørende F-eiendeler kan foreslås og aksepteres gjennom Styringsprosessen.

Delegasjon

FTSO vil i virkeligheten gi estimater hvert par sekunder. Ikke Alle Spark-holdere vil ha eller kunne kjøre maskinvare for å bidra til FTSO, og separat er de kanskje ikke interessert i å stemme for nettverksstyring. Derfor kan stemmer for begge ansvarene løsnes fra selve token og delegeres separat til andre parter. Delegasjonen kan kanselleres når som helst, og når et token overføres fra en adresse til en annen, blir delegasjonen automatisk kansellert slik at stemmerettene går med token. Mekanismen tillater OGSÅ SDAS SOM FXRP å delegere Spark stemmer tilbake til den ultimate eieren som deretter kan delegere disse stemmer videre til enheter han ønsker å stemme på hans vegne. Så Hvis Bob har 5000 Spark tokens I FXRP-applikasjonen, vil den delegere stemmer fra disse tokens til en adresse spesifisert Av Bob. Hvis Bob ønsker at en dedikert dataleverandør skal bidra til FTSO på hans vegne, Kan Bob deretter delegere sine stemmer til FTSO til dataleverandøren. Det er viktig at Dette betyr At Bob ikke trenger å velge mellom å tjene Spark ved å gi sikkerhet TIL fxrp-applikasjonen og potensielt tjene belønningen FRA FTSO, han kan gjøre begge deler. ENHVER SDA som gjør Spark-tokens utilgjengelige for sine underliggende eiere, forutsatt at det er en definisjon i søknaden om hvem den underliggende eieren er, kan implementere delegeringsprosedyren.

Styring & Foundation

Flare styres helt Av Spark token holdere gjennom avstemning. SDAS kan eventuelt be om å bli styrt Av Spark token holdere.

Visse beslutninger kan gjøres på en automatisert måte i kjeden, for eksempel å endre transaksjonskostnaden, oracle-belønningssatsen eller, se PÅ FXRP som EN SDA, endre sikkerhetsforholdet og etableringsgebyret. Andre beslutninger som å legge til en ny tidsserie TIL FTSO og knytte den foreslåtte F-aktiva, endre nettverk konsensusparametere eller mer komplekse langsiktige oppdateringer krever en kodeendring. Flare white paper angir et forslag, utvikling og testing regime for manuelle endringer som kan initieres og stemt på Av Spark token holdere. For å bidra til å gjennomføre denne prosessen og gjennomføre de avtalte endringene vil det være En Flare foundation. Stiftelsen vil være en non-profit, som skal inkorporeres i de kommende månedene. Det skal være ansvarlig for 5 nøkkelområder: tilskudd, investeringer, forskning og utvikling, utdanning, publisitet og partnerskap.det er forsknings – og utviklingsfunksjonen som gjør at grunnlaget kan være en integrert del av nettverksoppdateringsprosessen, til og med gå så langt som å analysere, rapportere om og deretter bygge, teste og distribuere foreslåtte endringer i nettverkskoden.

stiftelsen må være svært gjennomsiktig og ikke kaste bort penger. To rapporter per år om sine aktiviteter og utgifter vil bli overholdt og publisert. Stiftelsen er kun ment å ta retning fra Spark token holdere og ikke å sette dagsordenen. Som sådan kan Det ikke: bidra til FTSO på noen måte, distribuere Noen Av Sine Spark holdings som sikkerhet for enhver applikasjon på nettverket, og Det kan ikke bruke Sine Spark holdings til å stemme i noen styringsstemme. Det kan ikke tildele Sine Spark tokens til andre for å gjøre det. Videre vil skrevet inn i stiftelsens grunnlov være forpliktelsen om at hvis en styringsstemme er enig i at stiftelsen ikke lenger tjener et gunstig formål, må stiftelsen slå sin virksomhet ned og brenne alle sine gjenværende tokenbeholdninger så snart som mulig.

Gnist Utstedelse

det beste samfunnet til å eie eiendelen som muliggjør bruk AV XRP Med Turing complete smart kontrakter er samfunnet som vil bruke det og dra nytte av det: XRP holdere. Flare gjør IKKE EN ITO. I stedet, det gjør det vi kaller et verktøy gaffel. Vi tror det er den første i sitt slag.en gaffel har tradisjonelt søkt å ta brukerbasen til et eksisterende nettverk og avvike helt fra det nettverket, vanligvis for å ha et antagonistisk forhold til den opprinnelige kjeden. Derimot er en verktøygaffel ment å bringe verdien tilbake til den opprinnelige kjeden i stedet for å bevege seg bort fra den. Flare lar XRPL gjøre det den gjør best, rask oppgjør, mens bringe TIL XRPL, smarte kontrakter og muligheten til å skape en trustless rørledning til andre blockchains. Vi tror dette er en virkelig kraftig kombinasjon og et perfekt eksempel på nytte.

100 Milliarder Spark tokens vil bli opprettet for å speile mengden XRP som eksisterer. Det er omtrent 45 Bn XRP tokens som ikke tilhører Ripple labs. Målet med distribusjonen er AT ANDRE xrp-holdere enn Ripple kan kreve omtrent en 1: 1 Mengde Gnist til DERES XRP-holding. 45 Bn Spark vil bli hevdet AV XRP holdere (stripping ut kjente Ripple labs adresser). 25 Bn Spark vil gå Til Flare Networks Limited som Er Flare ‘ s for-profit organisasjon. 30 Bn Gnist vil gå til Flare foundation.Siden MANGE XRP-eiere faktisk bruker utvekslinger for å holde SINE XRP-tokens, er det en mulighet for at en innehaver AV XRP som ønsker å kreve Spark-tokens, kanskje ikke kan, fordi enten utvekslingen hevder Gnisten og beholder dem i stedet for å overføre dem, eller alternativt ikke hevder dem i det hele tatt. FOR Å tillate xrp-eiere å delta i distribusjonen, enten ved å presse utvekslingen til å distribuere Spark-tokens eller å flytte utveksling til en som gjør det, vil øyeblikksbildet AV XRP-hovedboken bli tatt på en dato nærmere å starte. En liste over deltakende utvekslinger vil bli lagt ut på Flare hjemmeside og oppdateres med jevne mellomrom. Stillbilde ledger nummeret vil bli lagt ut på nettstedet når stillbildet er tatt.

TL;DR

Flare Er verdens første Turing complete Federated Byzantine Agreement (FBA) nettverk. Den integrerer Ethereum Virtual Machine (EVM) og henter ikke sikkerhet fra et token. På toppen av dette er bygget en protokoll for å aktivere trustless utstedelse, bruk og innløsning, AV XRP på Flare. Denne protokollen kalles FXRP. Den generelle metodikken til protokollen og systemet som kobler Flare til andre nettverk, kan utvides til enhver ikke-Turing komplett token. Trustless interoperabilitet med andre nettverk er mulig, både gjennom interoperabilitetsprotokoller som Cosmos Og Polkadot eller Med Ethereum via veldefinerte broprotokoller.

Flare ‘ s token, Spark er opprettet gjennom det som kan være den første verktøygaffelen, hvor origin-nettverket, i DETTE tilfellet XRP-Hovedboken, fordeler gjennom økt verktøy. 100 Milliarder Spark tokens vil bli opprettet i Begynnelsen Av Flare-nettverket, hvorav 45 Milliarder vil bli hevdet av eksisterende xrp-holdere unntatt Ripple Labs. Dette speiler eksisterende mengde distribuert XRP slik at nåværende xrp-holdere vil kunne kreve omtrent 1 Spark token for hver XRP-token holdt. 25 Milliarder tokens vil gå til utviklerne, Flare, og 30 Milliarder tokens vil gå til et non-profit fundament kalt Flare foundation. Spark token holdere kan tjene en avkastning på Sine Spark tokens både gjennom å begå Spark tokens som sikkerhet for å sikre trustless utstedelse OG innløsning AV FXRP og ved å bidra med data Til Flare time series oracle. Disse funksjonene konkurrerer ikke med hverandre.

Gnisttokenet brukes til styring av nettverket gjennom avstemning. Med unntak av tilskudd og investeringer for å bidra til å utvikle Flare, tar stiftelsen teknisk retning fra Spark token-eierne. En nøkkelrolle for stiftelsen er å bidra til å gjennomføre oppgraderinger og endringer i nettverket, avtalt av styrings stemme, som ikke kan gjennomføres uten en kodeendring. Viktig, skrevet inn i stiftelsens grunnlov, vil være en vedtekt at grunnlaget må vikles ned og alle Gnisttokener holdt av stiftelsen brent, hvis Gnisttokenholderne er enige om at eksistensen ikke lenger er gunstig for nettverket.Flare samler verdien av de ikke-Turing komplette tokens med den transformative kraften til smarte kontrakter på et nettverk som kan skalere for verdi samt transaksjonsgjennomstrømning.

Svar På To Spørsmål:

Skaper Gnist Bevis På Innsats ved bakdøren?

bare utstedte tokens som krever sikkerhet, for EKSEMPEL FXRP, er sikret Med Spark. Nettverket bruker Ikke Gnist for sikkerhet i å komme til enighet.Vi hadde (det vi tror er) veldig sterke konsepter for EN USD denominert stabil mynt, men det krevde omfattende re-engineering Av Ethereum Virtuell Maskin som ville ha forsinket lanseringen og hadde uforutsigbare effekter på fremtidig kompatibilitet med EVM. Spark som den er strukturert, gir mye større nytte og fordel for BÅDE XRP-fellesskapet og TIL XRP-hovedboken.