idag är vi glada över att göra våra detaljerade planer för utbyggnaden av Flare Network allmänheten. Dessa planer kan utforskas fullständigt genom att dyka in i våra utkast till vitböcker som täcker nätverket och dess inbyggda token, Spark (här) och den tillförlitliga integrationen av XRP med Flare (här). Tidningarna är i utkast och det kommer att bli optimeringsändringar mellan nu och dagen Flare går live. Det bör inte ske förändringar som väsentligt avviker från översikten nedan. I det här inlägget strävar vi efter att lyfta fram vad vi anser vara de viktigaste aspekterna av Flare. En minimalt teknisk översikt över varje viktig komponent kommer att publiceras under de följande veckorna, börjar senare i veckan med en genomgång av flares trustless integration av XRP, FXRP. Spänn fast!

(en TL;DR är i slutet av detta inlägg.)

Vad är Flare och varför bygger vi det?

Flare finns för att lösa två viktiga problem:

först och av omedelbar betydelse för byggandet av vår bransch är att 75% av värdet som finns i offentlig blockchain för närvarande inte kan användas på ett tillförlitligt sätt med smarta kontrakt.

För det andra, och av både kortsiktig och långsiktig konsekvens, finns det potentiella problem med hur skalning implementeras för smarta kontraktsnätverk idag. Majoriteten av nya nätverk använder proof of Stake eller dess varianter. Dessa protokoll härleder nätverkssäkerhet från deras ursprungliga token.

den omedelbara frågan som är inneboende i proof of Stake är att konsensusdesignen ännu inte säkert tillåter alternativa användningar av den ursprungliga token. Om en tokenhållare kan få ett högre utbyte (och utan möjlighet att skära) genom att tillhandahålla säkerheter för att skapa en stablecoin än de kan från staking, då som ekonomiska rationalister, kommer de sannolikt att göra det. Detta avleder tokens bort från staking och kannibaliserar nätets säkerhet. (En mycket insiktsfull uppsats om detta ämne finns här.) Vi misstänker att detta kanske är den viktigaste anledningen till att Ethereum trots att det har relativt högre transaktionskostnader och mycket lägre transaktionsflöde fortfarande leder vägen i DeFi.

ett problem på längre sikt är att som ett bevis på att Insatsnätverket får användning och värdet som byggs ovanpå det ökar, måste värdet på insatstoken öka eller nätverket blir osäkert. Detta är bra för investerare i token men dåligt för människor som vill se decentralisering bli en del av det vanliga sättet att göra affärer. Varför? För att tokenvärdet som säkrar nätverket ska stiga måste kapitalet avledas från någon annan användning för att köpa token. Om smarta kontraktsnätverk som använder proof of stake skulle bli den allestädes närvarande metoden för att göra affärer, skulle omfattningen av avledning av kapital som krävs från andra ansträngningar, bara för att säkra värdet byggt på dessa nätverk, göra handelskostnaden omöjligt hög. Av denna anledning är det extremt osannolikt att det händer. Bevis på insats och varianter kan skala transaktionsgenomströmning men befintliga implementeringar kan inte skala för värde. Enligt vår åsikt är Proof of Stake mer en stoppgap än en lösning.

hur löser Flare dessa problem?

Flare är kärnan ett nytt sätt att skala smarta kontraktsplattformar som inte kopplar säkerhet till värdet av dess token. Flare kräver fortfarande ett token för driften av nätverket, främst för att avskräcka skräpposttransaktioner. Flares token heter Spark. Eftersom Spark inte har nätverkssäkerhetsimplikationer är det väl lämpat för att möjliggöra tillförlitlig användning av icke-Turing kompletta tokens med smarta kontrakt.

Flare är världens första Turing complete Federated Byzantine Agreement (FBA) – nätverk. Noder kör Avalanche consensus-protokollet med en nyckelanpassning till FBA-konsensustopologin. FBA är unik som konsensus topologi genom att den uppnår säkerhet utan att förlita sig på ekonomiska incitament som kan störa högvärdiga och högriskanvändningsfall. En kritik av ren FBA är att det leder till bräckliga strukturer av beståndsdelar, vilket möjliggör topologiscenarier där ett enda nodfel kan orsaka ett nätverksomfattande fel. Av denna anledning prioriteras en specifik inställning av FBA som kallas en unik nodlista (UNL) topologi som betonar tydlighet och användarvänlighet samtidigt som FBA: s öppna medlemskapsegenskap bibehålls. Den procentuella överlappningen av UNL är en styrdefinierad parameter,med en lägre överlappning som förbättrar nätverkets öppna medlemskap. Flare-nätverket utnyttjar Ethereum Virtual Machine (EVM), vilket gör det möjligt för nätverket att köra Turing kompletta smarta kontrakt.

vid nätverksstart, byggd ovanpå Flare, är då ett protokoll för att säkert möjliggöra trustless emission, användning och inlösen av XRP on Flare. Detta protokoll kallas FXRP. XRP blir säkert och pålitligt FXRP, på Flare, säkrad av flares infödda token, Spark. XRP finns nu effektivt på ett Turing-komplett nätverk och en gång där är tillförlitlig interoperabilitet med andra nätverk möjlig, både genom interoperabilitetsprotokoll som Cosmos och Polkadot eller med Ethereum via väldefinierade broprotokoll. Kortfattat: Flare kan användas som en smart kontraktsplattform för XRP eller som en trustless pipeline för XRP till andra nätverk.

Dessutom kan den allmänna metoden för FXRP utökas till alla icke-Turing kompletta token och möjligheten att bestämma vilka andra tokens som ska stödja och sedan utöka medlen för att göra det är inbyggt i systemen och styrningen av nätverket.

Flare sammanför värdet av de icke-Turing kompletta tokens med transformativa kraften i smarta kontrakt på ett nätverk som kan skala för värde samt transaktionsgenomströmning.

Fxrp översikt

komplexiteten att få XRP på Flare är att det inte finns något sätt för ett smart kontrakt på en offentlig blockchain att styra en adress på XRP ledger. Anledningen till detta är att smarta kontrakt för närvarande inte har något adekvat sätt att lagra en hemlig nyckel på ett sätt som verkligen är hemligt. För att få XRP på Flare med endast kod skulle kräva att någon grupp deltagare kommer tillsammans med en multi signaturadress som de kollektivt kontrollerar, varigenom om k av n parter undertecknar en transaktion är transaktionen auktoriserad. Varje användare av en tillgång som utfärdats av denna multisig-adress måste då lita på den insamlingen av användare och därmed skulle tillgången varken vara tillförlitlig eller decentraliserad.

FXRP tillåter säkert en XRP-hållare (en upphovsman) att skicka sin XRP till en uppsättning adresser (kallade agenter) på XRP-huvudboken. FXRP smarta kontrakt på Flare utfärdar sedan upphovsmannen FXRP på Flare som är 1: 1 konvertibel med XRP och säkrad med Spark. När en innehavare av FXRP vill lösa in den för XRP (en Återlösare) skickar de tillbaka den till fxrp smart contracts på Flare. Agenterna skickar sedan XRP till redeemers-adressen på XRP-huvudboken. Om agenterna inte slutför denna inlösen tillräckligt snabbt kompenseras inlösaren värdet på deras XRP plus ett belopp för att kompensera för transaktionskostnader för att återköpa XRP.

med FXRP behövs ingen centraliserad mellanhand.

fxrp fungerar enligt följande:

ägare av flares inbyggda token, Spark, kan skicka sina tokens till en samling smarta kontrakt på Flare som kallas FXRP-systemet. Användare som gör detta ger säkerhet till FXRP-systemet. De kallas agenter. Låt oss ringa en av agenterna Bob. Det kommer att finnas många agenter i FXRP-systemet.

låt oss säga att Bob har satt in 5000 Spark-tokens i FXRP-systemet. I det här exemplet kan 10 Spark tokens för närvarande köpas för 1 XRP token. FXRP-systemet kräver ett säkerhetsförhållande på 2,5, vilket innebär att en agent alltid måste ha tillhandahållit systemet 2,5 gånger värdet på FXRP som systemet har fördelat på dem i Spark-tokens. FXRP värderas här som 1: 1 med XRP. Därför tillåter Bobs 5000 Spark tokens systemet att utfärda 200 FXRP.

när någon, säger Alice, vill skapa FXRP skickar de en transaktion till FXRP-systemet med en fast avgift på 0,1% av värdet på XRP som de vill mynta i FXRP. Alice kallas upphovsman. Transaktionen berättar också för FXRP-systemet vilken adress som ska skickas FXRP till på Flare, när den är präglad och vilken adress XRP kommer att härröra från på XRP-huvudboken. Om det finns tillgänglig kapacitet i fxrp-systemet låses säkerheter för att säkra mängden FXRP som skapas under en viss period mot Alices kommande transaktion. På så sätt behöver Alice inte lita på Bob. I gengäld genereras en uppsättning instruktioner för Alice som berättar för henne vilken adress (Bobs adress) att skicka XRP till på XRP ledger och vilket sista ledgerindex som ska användas. Om det inte finns kapacitet i systemet för att utfärda önskad mängd FXRP återbetalas Alice avgiften.

Alice skickar sedan rätt mängd XRP plus en skapningsavgift i XRP till Bobs adress på XRP-huvudboken. Skapningsavgiften är den stora delen av pengarna som Bob kommer att tjäna för att låsa upp sin Spark-säkerhet, notera att hans intäkter huvudsakligen är i XRP. Flare observerar denna transaktion med hjälp av ett system som kallas State Connector, definierat i Avsnitt 2 i Flare white paper (och ämnet för ett framtida blogginlägg). FXRP präglas sedan av systemet och levereras till Alices nominerade adress på Flare.

säkerhetsförhållandet på 2,5 x måste bibehållas hela tiden. Om priset på XRP ökar mot Spark, så att värdet på Bobs säkerheter faller under 2.5 gånger fxrp utfärdat mot det, då har Bob en begränsad tid att antingen lägga till fler Spark-tokens som säkerhet eller köpa och lösa in FXRP-tokens för att få tillbaka sitt säkerhetsförhållande i linje. Till exempel, säg 200 FXRP-tokens utfärdas mot Bobs 5000 Spark-tokens och priset på XRP/Spark ökar till 12. Bob behöver nu antingen lägga till 1000 Spark till systemet eller köpa och lösa in 33.34 FXRP för att minska sin fördelning av utfärdad FXRP till 166.66.

om Bob inte har tillgång till ytterligare Spark-tokens är det inte ekonomiskt betungande för honom att minska balansen i FXRP som stöds av hans adress. Bobs säkerhet gjorde det möjligt för FXRP-systemet att utfärda 200 fxrp-tokens, i processen att göra det har Bob fått 200 XRP-tokens på XRP-huvudboken. Således om Bob inte har ytterligare kapital för att köpa Spark tokens kan han antingen sälja tillräckligt med XRP för FXRP på ett utbyte så att han kan lösa in minst 33.34 FXRP eller stanna kvar i en rent decentraliserad miljö om det finns andra agenter i FXRP-systemet med tillräcklig överskottssäkerhet i han kan mynta tillräcklig FXRP och omedelbart lösa in den. Det andra scenariot skiftar i huvudsak skyldigheten till resten av systemet. Om Bob inte gör någonting och förblir i standard mot säkerhetsförhållandet, kommer Bobs säkerheter automatiskt att auktioneras ut för det belopp FXRP som utfärdats mot det, vilket i detta fall är 200. Bob behåller alla återstående säkerheter efter denna operation.

låt oss säga att Bob valde att lägga till ytterligare gnista som säkerhet. Nu någon gång senare Alice som äger alla 200 utfärdade FXRP vill lösa in hela beloppet tillbaka till XRP ledger. Alice gör helt enkelt en transaktion med FXRP-systemet som skickar FXRP till systemet och berättar vilken adress hon vill ha krediterad. Systemet utfärdar sedan en uppsättning instruktioner till Bob berätta för honom hur mycket XRP att skicka och där tillsammans med två XRP ledger nummer tidsfrister som transaktionen måste slutföras. Om Bob slutför transaktionen inom den första tidsfristen är hans säkerhet helt upplåst. Om Bob misslyckas med den första tidsfristen men lyckas med den andra debiteras han en liten straffavgift och resten av hans säkerhet är upplåst. Straffavgiften bränns.

om Bob inte slutför transaktionen inom den andra tidsfristen kallas det ett inlösenfel. Alice kompenseras sedan med Spark tokens till värdet av hennes inlösta XRP plus en ökning med 1% för att täcka transaktionskostnaderna för att köpa tillbaka XRP, detta dras från Bobs säkerhet. Av Bobs återstående säkerhet bränns 50% som straff och de andra 50% återvände till honom. Alice kan sedan köpa ersättare XRP på ett utbyte. Alternativt, förutsatt att det finns andra agenter på Flare med utfärdat FXRP och personer som vill sälja det, kan Alice köpa mer FXRP på Flare och lösa in det mot dessa agenter.

Spark och beroende applikationer

FXRP är det första exemplet på något vi kallar en Gnistberoende applikation (SDA). En SDA definieras som en applikation som i sin konstruktion använder en kombination av: Spark for collateral, Flare Time Series Oracle och Spark token holders for governance. Var och en av dessa element är helt frivilligt och ett program kan fungera på Flare endast interagera med Spark för betalning av transaktionskostnader. Till exempel använder FXRP Spark som säkerhet, Flare-tidsserien Oracle för XRP/Spark-priset och Spark token-ägandet för styrning över vissa parametrar som fxrp-skapningsavgiften och säkerhetsförhållandet. SDA-modellen är avsedd att tillhandahålla en mall för att utvidga var och en av de tre komponenterna till ett godtyckligt antal applikationer. Att använda Spark som säkerhet i alla applikationer är enkelt, det viktigaste var att överväga hur en säker oracle-metod kunde skapas över flera tidsserier.

Flare tidsserie Oracle

ägande av Spark token möjliggör bidrag till Flare tidsserie Oracle (FTSO). Syftet med FTSO är att bilda exakta uppskattningar av data om Flare från off-chain samtidigt som decentralisering bibehålls. FTSO är strukturerad för att ge många uppskattningar av enskilda tidsserier. XRP / Spark-priset är ett exempel på en enda tidsserie.

varje tidsserieutgång från FTSO kommer i allmänhet att ha två grupper av deltagare: den första är Spark token-innehavare och den andra är innehavarna av den beroende applikationstoken, som kallas en F-tillgång. I fxrp-applikationen är F-tillgången själva fxrp-token. För en mer komplex applikation som en derivatapplikation där applikationen kräver flera tidsserier kan F-tillgången vara något mer besläktad med en utfärdad styrningstoken.

för varje tidsserie ber FTSO varje relevant uppsättning deltagare att ge en uppskattning. Spark innehavare kommer att ge uppskattningar för alla tidsserier och f-Asset innehavare kommer att ge uppskattningar över endast tidsserier relaterade till deras F-tillgång. Dessa uppskattningar behandlas sedan enligt definitionen i Avsnitt 4 i Flare whitepaper och utdata från systemet.

incitamentet för F-tillgångsinnehavare att tillhandahålla data till systemet är säkerheten för deras tillämpning. Spark token innehavare stimuleras av potentialen att tjäna något som kallas oracle reward. Detta är en mängd Spark tokens som präglas av systemet. Oracle-belöningen är en årlig räntedelning jämnt över varje ftso-uppskattningsperiod. Till exempel, om kursen är 10%, finns det 365 uppskattningar på ett år och ett startnummer av Spark tokens på 100, då kommer 10 Spark att skapas om 1 år och ~0.03 Spark minted och belönas per dag. Spark token-bidragsgivare kan tjäna denna belöning genom att bidra med data som anses vara ”korrekta”. Den exakta mekaniken anges i vitboken. Det är viktigt att alla Spark token-innehavare implicit satsas i systemet som om de inte tjänar belöningen antingen genom icke-bidrag eller ger ”felaktiga” uppskattningar som de förlorar värde för tokeninnehavare som belönas. Detta är Flares version av blockbelöningar.

FTSO kommer att initieras för att ge följande priser för: XRP/Spark, USD/Spark, BTC/Spark och XLM/Spark. Endast XRP / Spark kommer att ha en motsvarande F-tillgång i början. Ytterligare tidsserier och tillhörande F-tillgångar kan föreslås och accepteras genom Styrningsprocessen.

Delegation

FTSO kommer i verkligheten att ge uppskattningar varje par sekunder. Inte alla Gnisthållare vill eller kan köra hårdvara för att bidra till FTSO och separat kanske de inte är intresserade av att rösta för nätverksstyrning. Därför kan rösterna för båda ansvarsområdena lossas från själva token och delegeras separat till andra parter. Delegationen kan avbrytas när som helst och när en token överförs från en adress till en annan avbryts delegationen automatiskt så att rösträtten går med token. Mekanismen gör det också möjligt för SDA: er som FXRP att delegera Spark-röster tillbaka till den ultimata ägaren som sedan kan delegera dessa röster vidare till enheter som han vill rösta för hans räkning. Så om Bob har 5000 Spark tokens i fxrp-applikationen, kommer den att delegera rösterna från dessa tokens till en adress som anges av Bob. Om Bob vill att en dedikerad dataleverantör ska bidra till FTSO för hans räkning, kan Bob sedan delegera sina röster för FTSO till dataleverantören. Viktigt betyder det att Bob inte behöver välja mellan att tjäna Spark genom att tillhandahålla säkerheter till FXRP-applikationen och potentiellt tjäna belöningen från FTSO, han kan göra båda. Alla SDA som gör Spark tokens otillgängliga för sina underliggande ägare, förutsatt att det finns en definition i ansökan om vem den underliggande ägaren är, kan genomföra delegeringsförfarandet.

Governance & Foundation

Flare styrs helt av Spark token innehavare genom omröstning. SDA: s kan eventuellt begära att styras av Spark token innehavare.

vissa beslut kan fattas på ett automatiserat sätt på kedjan, till exempel att ändra transaktionskostnaden, oracle-belöningsgraden eller, titta på FXRP som en SDA, ändra säkerhetsförhållandet och skapningsavgiften. Andra beslut som att lägga till en ny tidsserie till FTSO och länka den föreslagna F-tillgången, ändra nätverkskonsensusparametrar eller mer komplexa långsiktiga uppdateringar kräver en kodändring. Flare white paper innehåller ett förslag, utvecklings-och testsystem för manuella ändringar som kan initieras och röstas om av Spark token-innehavare. För att hjälpa till att genomföra den processen och genomföra de överenskomna ändringarna kommer det att finnas en Flare foundation. Stiftelsen kommer att vara en ideell, som ska införlivas under de kommande månaderna. Det ska ansvara för 5 nyckelområden: bidrag, investeringar, forskning och utveckling, utbildning, publicitet och partnerskap.

det är forsknings-och utvecklingsfunktionen som gör att grunden kan vara en integrerad del av nätverksuppdateringsprocessen, till och med gå så långt som att analysera, rapportera om och sedan bygga, testa och distribuera föreslagna nätverkskodsändringar.

stiftelsen måste vara mycket transparent och inte slösa bort pengar. Två rapporter per år om dess verksamhet och utgifter kommer att följas och offentliggöras. Stiftelsen är endast avsedd att ta riktning från Spark token-innehavarna och inte sätta dagordningen. Som sådan får den inte: bidra till FTSO på något sätt, distribuera något av sina Spark holdings som säkerhet för någon applikation i nätverket och den får inte använda sina Spark holdings för att rösta i någon styrelse. Det får inte tilldela sina Spark tokens till andra att göra det. Dessutom, skrivet i stiftelsens konstitution kommer att vara skyldigheten att om en styrelse omröstning håller med om att stiftelsen inte längre tjänar ett fördelaktigt syfte då stiftelsen måste avveckla sin verksamhet ner och bränna alla sina återstående token innehav så snart som möjligt.

Spark Issuation

det bästa samhället att äga tillgången som möjliggör användning av XRP med Turing complete smart contracts är det samhälle som kommer att använda det och dra nytta av det: XRP-innehavare. Flare gör inte en ito. Istället gör det vad vi kallar en verktygsgaffel. Vi tror att det är den första i sitt slag.

en gaffel har traditionellt försökt ta användarbasen för ett befintligt nätverk och avvika helt från det nätverket, vanligtvis för att ha ett antagonistiskt förhållande till den ursprungliga kedjan. Däremot är en verktygsgaffel avsedd att ge värde tillbaka till den ursprungliga kedjan istället för att flytta bort från den. Flare låter XRPL göra vad det gör bäst, snabb avveckling, samtidigt som XRPL, smarta kontrakt och möjligheten att skapa en tillförlitlig pipeline till andra blockkedjor. Vi tycker att detta är en verkligt kraftfull kombination och ett perfekt exempel på nytta.

100 miljarder Spark tokens kommer att skapas för att spegla den mängd XRP som finns. Det finns cirka 45 Bn XRP-tokens som inte tillhör Ripple labs. Syftet med distributionen är att andra XRP-innehavare än Ripple kan göra anspråk på ungefär en 1:1-mängd gnista till deras XRP-innehav. 45 Bn Spark kommer att krävas av XRP-innehavare (strippar ut kända Ripple labs-adresser). 25 Bn Spark kommer att gå till Flare Networks Limited som är Flares vinstdrivande organisation. 30 miljarder gnista kommer att gå till Flare foundation.

eftersom många XRP-ägare faktiskt använder utbyten för att hålla sina XRP-tokens, finns det en möjlighet att en innehavare av XRP som vill hävda Spark-tokens kanske inte kan, eftersom antingen utbytet hävdar gnistan och behåller dem snarare än att vidarebefordra dem, eller alternativt inte hävdar dem alls. För att tillåta XRP-ägare att delta i distributionen antingen genom att trycka på deras utbyte för att distribuera Spark-tokens eller för att flytta exchange till en som gör det, kommer ögonblicksbilden av XRP-huvudboken att tas vid ett datum närmare lanseringen. En lista över deltagande utbyten kommer att publiceras på Flares webbplats och uppdateras regelbundet. Snapshot ledger-numret kommer att publiceras på webbplatsen när ögonblicksbilden har tagits.

TL;DR

Flare är världens första Turing complete Federated Byzantine Agreement (FBA) nätverk. Den integrerar Ethereum Virtual Machine (EVM) och härleder inte säkerhet från ett token. Ovanpå detta byggs ett protokoll för att på ett säkert sätt möjliggöra trustless emission, användning och inlösen, av XRP på Flare. Detta protokoll kallas FXRP. Protokollets allmänna metodik och systemet som ansluter Flare till andra nätverk kan utökas till alla icke-Turing kompletta token. Trustless interoperabilitet med andra nätverk är möjlig, både genom interoperabilitetsprotokoll som Cosmos och Polkadot eller med Ethereum via väldefinierade broprotokoll.

Flare token, Spark skapas genom vad som kan vara den första någonsin verktyget gaffel där origin network, i detta fall XRP Ledger, fördelar genom ökad nytta. 100 miljarder Spark-tokens kommer att skapas i början av Flare-nätverket, varav 45 miljarder kommer att krävas av befintliga XRP-innehavare exklusive Ripple Labs. Detta speglar den befintliga mängden distribuerad XRP så att nuvarande XRP-innehavare kommer att kunna göra anspråk på cirka 1 Gnisttoken för varje XRP-token som hålls. 25 miljarder tokens kommer att gå till utvecklarna, Flare och 30 miljarder tokens kommer att gå till en ideell stiftelse som heter Flare foundation. Spark token innehavare kan tjäna en avkastning på sina Spark tokens både genom att begå Spark tokens som säkerhet för att säkra trustless emission och inlösen av FXRP och genom att bidra med data till Flare tidsserien oracle. Dessa funktioner konkurrerar inte med varandra.

Spark token används för styrning av nätverket genom omröstning. Med undantag för bidrag och investeringar för att hjälpa till att utveckla Flare tar stiftelsen teknisk riktning från Spark token-ägarna. En nyckelroll för stiftelsen är att hjälpa till att genomföra uppgraderingar och ändringar av nätverket, som överenskommits med styrelseomröstning, som inte kan genomföras utan kodändring. Viktigt, skrivet i stiftelsens konstitution, kommer att vara en stadgar att stiftelsen måste avvecklas och alla Spark tokens som innehas av stiftelsen bränns, om Spark token innehavare är överens om att dess existens inte längre är till nytta för nätverket.

Flare sammanför värdet av de icke-Turing kompletta tokens med transformativa kraften i smarta kontrakt på ett nätverk som kan skala för värde samt transaktionsgenomströmning.

svar på två frågor:

skapar Spark bevis på insats av bakdörren?

endast utfärdade tokens som kräver säkerhet, såsom FXRP, är säkrade med Spark. Nätverket använder inte gnista för säkerhet för att komma till konsensus.

Vi hade (vad vi tycker är) mycket starka koncept för ett stabilt mynt i USD, men det krävde omfattande omkonstruktion av den virtuella Ethereum-maskinen som skulle ha försenat lanseringen och hade oförutsägbara effekter på framtida kompatibilitet med EVM. Spark eftersom det är strukturerat, erbjuder mycket större nytta och nytta för både XRP samhället och XRP ledger.