Oggi siamo lieti di rendere pubblici i nostri piani dettagliati per la distribuzione della Flare Network. Questi piani possono essere completamente esplorati immergendosi nelle nostre bozze di white paper che coprono la rete e il suo token nativo, Spark (qui) e l’integrazione senza fiducia di XRP con Flare (qui). I documenti sono in bozza e ci saranno cambiamenti di ottimizzazione tra oggi e il giorno in cui il Flare entrerà nel vivo. Non dovrebbero esserci cambiamenti che si discostano materialmente dalla panoramica fornita di seguito. In questo post ci proponiamo di evidenziare quelli che consideriamo gli aspetti più importanti del Flare. Una panoramica minimamente tecnica di ogni componente importante sarà pubblicata nelle settimane successive, a partire da questa settimana con una procedura dettagliata dell’integrazione trustless di Flare di XRP, FXRP. Allacciate le cinture!

(A TL;DR è alla fine di questo post.)

Cos’è il Flare e perché lo stiamo costruendo?

Flare esiste per risolvere due problemi chiave:

In primo luogo, e di immediata importanza per la costruzione del nostro settore è che il 75% del valore esistente nella blockchain pubblica non può attualmente essere utilizzato in modo affidabile con contratti intelligenti.

In secondo luogo, e di conseguenza sia a breve che a lungo termine, ci sono potenziali problemi con il modo in cui il ridimensionamento viene implementato per le reti di contratti intelligenti oggi. La maggior parte delle nuove reti utilizza Proof of Stake o le sue varianti. Questi protocolli derivano la sicurezza della rete dal loro token nativo.

Il problema immediato inerente a Proof of Stake è che il design del consenso non consente ancora in modo sicuro usi alternativi del token nativo. Se un detentore di token può ottenere un rendimento più elevato (e senza possibilità di taglio) fornendo garanzie per creare uno stablecoin di quanto possano ottenere dal picchettamento, allora come razionalisti economici, probabilmente lo faranno. Questo devia i token dal picchettamento e cannibalizza la sicurezza della rete. (Un documento altamente perspicace su questo argomento è qui.) Sospettiamo che questo sia forse il motivo principale per cui, nonostante i costi di transazione relativamente più elevati e il throughput delle transazioni molto più basso, Ethereum è ancora all’avanguardia in DeFi.

Un problema a lungo termine è che quando una rete Proof of Stake guadagna utilizzo e il valore costruito su di esso aumenta, il valore del token di puntata deve aumentare o la rete diventerà non sicura. Questo è ottimo per gli investitori nel token, ma è negativo per le persone che vogliono vedere il decentramento diventare parte del modo tradizionale di fare affari. Perché? Perché affinché il valore del token che protegge la rete aumenti, il capitale deve essere deviato da qualche altro uso per acquistare il token. Portato all’endpoint logico, se le reti di contratti intelligenti che utilizzano proof of stake dovessero diventare il metodo onnipresente di fare affari, la scala di diversione del capitale richiesto da altri sforzi, solo per garantire il valore costruito su queste reti, renderebbe il costo del commercio insostenibilmente alto. Per questo motivo è estremamente improbabile che accada. Proof of Stake e varianti possono scalare il throughput delle transazioni, ma le implementazioni esistenti non possono scalare per valore. A nostro avviso Proof of Stake è più un ostacolo che una soluzione.

In che modo Flare risolve questi problemi?

Flare è al suo centro un nuovo modo di scalare le piattaforme smart contract che non collega la sicurezza con il valore del suo token. Flare richiede ancora un token per il funzionamento della rete, principalmente per scoraggiare le transazioni di spam. Il token di Flare si chiama Spark. Poiché Spark non ha implicazioni sulla sicurezza della rete, è adatto per consentire l’utilizzo senza fiducia di token completi non Turing con contratti intelligenti.

Flare è il primo Turing completa Federated Byzantine Agreement (FBA) rete al mondo. I nodi eseguono il protocollo di consenso Avalanche con un adattamento chiave alla topologia di consenso FBA. FBA è unico come topologia di consenso in quanto raggiunge la sicurezza senza fare affidamento su incentivi economici che possono interferire con casi d’uso ad alto valore e ad alto rischio. Una critica di FBA puro è che porta a strutture fragili di nodi costituenti, consentendo scenari topologici in cui un singolo errore di nodo può causare un errore a livello di rete. Per questo motivo, una specifica impostazione di FBA chiamata topologia Unique Node List (UNL) ha la priorità che enfatizza la chiarezza e la facilità d’uso mantenendo la proprietà open-membership di FBA. La sovrapposizione percentuale dell’UNL è un parametro definito dalla governance, con una sovrapposizione inferiore che migliora la proprietà open-membership della rete. La rete Flare sfrutta la macchina virtuale Ethereum (EVM), consentendo alla rete di eseguire contratti intelligenti completi di Turing.

Al lancio della rete, costruito su Flare è quindi un protocollo per abilitare in modo sicuro l’emissione, l’utilizzo e la redenzione senza fiducia di XRP su Flare. Questo protocollo è chiamato FXRP. XRP diventa in modo sicuro e affidabile FXRP, su Flare, protetto dal token nativo di Flare, Spark. XRP ora esiste effettivamente su una rete completa di Turing e una volta lì, l’interoperabilità trustless con altre reti è fattibile, sia attraverso protocolli di interoperabilità come Cosmos e Polkadot o con Ethereum tramite protocolli bridge ben definiti. Insomma: Flare può essere utilizzato come piattaforma smart contract per XRP o come pipeline trustless per XRP ad altre reti.

Inoltre, la metodologia generale di FXRP è estendibile a qualsiasi token completo non Turing e la capacità di decidere quali altri token supportare e quindi estendere i mezzi per farlo è integrata nei sistemi e nella governance della rete.

Flare riunisce il valore dei token completi non di Turing con il potere trasformativo dei contratti intelligenti su una rete in grado di scalare per valore e throughput delle transazioni.

Panoramica FXRP

La complessità di ottenere XRP su Flare è che non c’è modo per un contratto intelligente su una blockchain pubblica di controllare un indirizzo sul libro mastro XRP. La ragione di ciò è che i contratti intelligenti attualmente non hanno un modo adeguato di memorizzare una chiave segreta in un modo che è veramente segreto. Per ottenere XRP su Flare usando solo il codice richiederebbe che un gruppo di partecipanti si riunisse con un indirizzo multi firma che controllano collettivamente, per cui se k di n parti firmano una transazione la transazione è autorizzata. Qualsiasi utente di una risorsa emessa da questo indirizzo multisig dovrebbe quindi fidarsi di quella raccolta di utenti e quindi la risorsa non sarebbe né trustless né decentralizzata.

FXRP consente in modo sicuro a un titolare XRP (un originatore) di inviare il proprio XRP a un insieme di indirizzi (chiamati agenti) sul libro mastro XRP. I contratti intelligenti FXRP su Flare emettono quindi l’originatore FXRP su Flare che è convertibile 1: 1 con XRP e protetto con Spark. Quando un detentore di FXRP desidera riscattarlo per XRP (un redentore) lo rispedisce agli smart contracts FXRP su Flare. Gli agenti quindi inviano l’XRP all’indirizzo dei redentori sul libro mastro XRP. Se gli agenti non completano questo rimborso abbastanza rapidamente il redentore è compensato il valore del loro XRP più un importo per compensare i costi di transazione per rebuy l’XRP.

Con FXRP, non è necessario alcun intermediario centralizzato.

FXRP funziona come segue:

I proprietari del token nativo di Flare, Spark, possono inviare i loro token a una raccolta di contratti intelligenti su Flare che sono indicati come sistema FXRP. Gli utenti che fanno questo stanno fornendo garanzie al sistema FXRP. Sono chiamati agenti. Chiamiamo uno degli agenti Bob. Ci saranno molti agenti nel sistema FXRP.

Diciamo che Bob ha inserito 5000 token Spark nel sistema FXRP. In questo esempio 10 token Spark possono attualmente essere acquistati per 1 token XRP. Il sistema FXRP richiede un rapporto collaterale di 2.5, il che significa che in ogni momento un agente deve aver fornito al sistema 2.5 volte il valore del FXRP che il sistema ha assegnato a loro in token Spark. FXRP è valutato qui come 1: 1 con XRP. Quindi i token Spark 5000 di Bob consentono al sistema di emettere 200 FXRP.

Quando qualcuno, ad esempio Alice, vuole creare FXRP invia una transazione al sistema FXRP con una commissione fissa dello 0,1% del valore di XRP che vuole coniare in FXRP. Alice è definito un originatore. La transazione dice anche al sistema FXRP a quale indirizzo inviare l’FXRP sul Flare, una volta coniato, e da quale indirizzo l’XRP avrà origine sul libro mastro XRP. Se c’è capacità disponibile nel sistema FXRP, la garanzia per garantire la quantità di FXRP in fase di creazione è bloccata per un certo periodo contro l’imminente transazione di Alice. In questo modo Alice non deve fidarsi di Bob. In cambio, viene generata una serie di istruzioni per Alice che le dice quale indirizzo (l’indirizzo di Bob) inviare l’XRP sul libro mastro XRP e quale ultimo indice di ledger usare. Se non c’è capacità nel sistema di emettere la quantità desiderata di FXRP, Alice viene rimborsata la commissione.

Alice invia quindi l’importo corretto di XRP più una commissione di creazione in XRP all’indirizzo di Bob sul libro mastro XRP. La commissione di creazione è la maggior parte del denaro che Bob guadagnerà per bloccare la sua garanzia Spark, nota che i suoi guadagni sono prevalentemente in XRP. Flare osserva questa transazione utilizzando un sistema chiamato Connettore di stato, definito nella Sezione 2 del white paper Flare (e oggetto di un futuro post sul blog). Il FXRP viene quindi coniato dal sistema e consegnato all’indirizzo nominato da Alice su Flare.

Il rapporto di garanzia di 2,5 x deve essere mantenuto in ogni momento. Se il prezzo di XRP aumenta contro Spark, in modo tale che il valore della garanzia di Bob scende sotto 2.5 volte l’FXRP emesso contro di esso, quindi Bob ha un tempo limitato per aggiungere più token Spark come garanzia o acquistare e riscattare token FXRP per riportare il suo rapporto collaterale in linea. Ad esempio, diciamo che i token 200 FXRP vengono emessi contro i token 5000 Spark di Bob e il prezzo di XRP/Spark aumenta a 12. Bob ora deve aggiungere 1000 Spark al sistema o acquistare e riscattare 33.34 FXRP per ridurre la sua ripartizione di FXRP emesso a 166.66.

Se Bob non ha accesso a token Spark aggiuntivi, non è finanziariamente oneroso per lui ridurre il saldo di FXRP supportato dal suo indirizzo. Il collaterale di Bob ha permesso al sistema FXRP di emettere 200 token FXRP, nel processo di farlo Bob ha ricevuto 200 token XRP sul libro mastro XRP. Pertanto, se Bob non ha capitale aggiuntivo per acquistare token Spark, può vendere XRP sufficiente per FXRP su uno scambio tale da poter riscattare almeno 33.34 FXRP o rimanere in un ambiente puramente decentralizzato se ci sono altri agenti nel sistema FXRP con sufficienti garanzie in eccesso, può coniare FXRP sufficiente e riscattarlo immediatamente. Il secondo scenario sposta essenzialmente l’obbligo al resto del sistema. Se Bob non fa nulla e rimane in default contro il rapporto di garanzia, la garanzia di Bob sarà automaticamente messa all’asta per l’importo di FXRP emesso contro di essa, che in questo caso è 200. Bob conserva tutte le garanzie rimanenti dopo questa operazione.

Diciamo che Bob ha scelto di aggiungere Scintilla aggiuntiva come garanzia. Ora qualche tempo dopo Alice che possiede tutti i 200 FXRP emessi vuole riscattare l’intero importo sul libro mastro XRP. Alice fa semplicemente una transazione con il sistema FXRP inviando l’FXRP al sistema e dicendogli quale indirizzo vuole accreditato. Il sistema emette quindi una serie di istruzioni a Bob dicendogli quanto XRP inviare e dove insieme a due scadenze XRP ledger number con cui la transazione deve essere completata. Se Bob completa la transazione entro la prima scadenza, la sua garanzia è completamente sbloccata. Se Bob fallisce entro la prima scadenza ma riesce entro la seconda gli viene addebitata una piccola penale e il resto della sua garanzia è sbloccato. La tassa di penalità è bruciata.

Se Bob non riesce a completare la transazione entro la seconda scadenza, viene definito un errore di riscatto. Alice viene quindi compensata con token Spark al valore del suo XRP riscattato più un aumento dell ‘ 1% per coprire i costi di transazione di riacquisto dell’XRP, questo è tratto dalla garanzia di Bob. Del restante collaterale di Bob il 50% viene bruciato come penalità e l’altro 50% gli viene restituito. Alice può quindi acquistare XRP sostitutivo su uno scambio. In alternativa, supponendo che ci siano altri agenti su Flare con FXRP emesso e persone che desiderano venderlo, Alice può acquistare più FXRP su Flare e riscattarlo contro quegli agenti.

Spark e applicazioni dipendenti

FXRP è il primo esempio di qualcosa che definiamo un’applicazione dipendente da Spark (SDA). Un SDA è definito come un’applicazione che utilizza nella sua costruzione una combinazione di: Spark per le garanzie, le serie temporali Flare Oracle e i titolari di token Spark per la governance. Ognuno di questi elementi è del tutto opzionale e un’applicazione può operare su Flare solo interagendo con Spark per il pagamento dei costi di transazione. Ad esempio, FXRP utilizza Spark come garanzia, l’Oracle della serie temporale Flare per il prezzo XRP/Spark e il set di proprietà dei token Spark per la governance su determinati parametri come la commissione di creazione di FXRP e il rapporto di garanzia. Il modello SDA ha lo scopo di fornire un modello per estendere ciascuno dei tre componenti a un numero arbitrario di applicazioni. L’utilizzo di Spark come garanzia in tutte le applicazioni è semplice, l’elemento più importante era considerare come una metodologia Oracle sicura potesse essere creata su più serie temporali.

Serie temporale Flare Oracle

La proprietà del token Spark consente il contributo alla serie temporale Flare Oracle (FTSO). Lo scopo del FTSO è quello di formare stime accurate dei dati sul Flare da off-chain, pur mantenendo il decentramento. L’FTSO è strutturato per fornire molte stime delle singole serie temporali. Il prezzo XRP / Spark è un esempio di una singola serie temporale.

Ogni serie temporale prodotta dall’FTSO avrà generalmente due gruppi di partecipanti: il primo è titolari di token Spark e il secondo sono i titolari del token dell’applicazione dipendente, che è definito un F-asset. Nell’applicazione FXRP l’F-asset è il token FXRP stesso. Per un’applicazione più complessa come un’applicazione di derivati in cui l’applicazione richiede più serie temporali, F-asset potrebbe essere qualcosa di più simile a un token di governance emesso.

Per ogni serie temporale, l’FTSO chiede a ciascun gruppo pertinente di partecipanti di fornire una stima. I titolari di spark forniranno stime per tutte le serie temporali e i titolari di F-Asset forniranno stime solo sulle serie temporali relative al loro F-Asset. Tali stime vengono quindi elaborate come definito nella sezione 4 del white paper Flare e prodotte dal sistema.

L’incentivo per i titolari di F-asset a fornire dati al sistema è la sicurezza della loro applicazione. I titolari di token Spark sono incentivati dal potenziale per guadagnare qualcosa chiamato ricompensa oracle. Questa è una quantità di token Spark che vengono coniati dal sistema. La ricompensa oracle è un tasso annuale diviso uniformemente in ogni periodo di stima FTSO. Ad esempio, se il tasso è 10%, ci sono stime 365 in un anno e un numero iniziale di token Spark di 100, quindi 10 Spark verranno creati in 1 anno e ~0.03 Spark coniate e ricompensate al giorno. I contributori di token Spark possono guadagnare questa ricompensa contribuendo con dati ritenuti “corretti”. La meccanica precisa è esposta nel libro bianco. È importante sottolineare che tutti i titolari di token Spark sono implicitamente picchettati nel sistema come se non guadagnassero la ricompensa attraverso il non contributo o fornendo stime “errate” che perdono valore ai titolari di token che vengono premiati. Questa è la versione di Flare di block rewards.

L’FTSO verrà avviato per fornire i seguenti prezzi per: XRP/Spark, USD/Spark, BTC/Spark e XLM/Spark. Solo XRP / Spark avrà un corrispondente F-asset all’inizio. Ulteriori serie temporali e le relative F-asset possono essere proposte e accettate attraverso il processo di Governance.

Delega

L’FTSO in realtà fornirà stime ogni paio di secondi. Non tutti gli Spark holder vorranno o saranno in grado di eseguire hardware per contribuire all’FTSO e separatamente potrebbero non essere interessati a votare per la governance della rete. Pertanto i voti per entrambe le responsabilità possono essere staccati dal token stesso e delegati separatamente ad altre parti. La delega può essere annullata in qualsiasi momento e quando un token viene trasferito da un indirizzo all’altro la delega viene automaticamente annullata in modo tale che i diritti di voto vadano con il token. Il meccanismo consente inoltre a SDA come FXRP di delegare i voti Spark al proprietario finale che può quindi delegare nuovamente tali voti alle entità che desidera votare a suo nome. Quindi, se Bob ha 5000 token Spark nell’applicazione FXRP, delegherà i voti da quei token a un indirizzo specificato da Bob. Se Bob desidera che un fornitore di dati dedicato contribuisca all’FTSO per suo conto, Bob può delegare nuovamente i suoi voti per l’FTSO al fornitore di dati. È importante sottolineare che questo significa che Bob non deve scegliere tra guadagnare Spark fornendo garanzie all’applicazione FXRP e potenzialmente guadagnare la ricompensa dall’FTSO, può fare entrambe le cose. Qualsiasi SDA che rende i token Spark non disponibili ai proprietari sottostanti, a condizione che nell’applicazione sia presente una definizione su chi sia il proprietario sottostante, può implementare la procedura di delega.

Governance&Fondazione

Flare è governato interamente dai titolari di token Spark attraverso il voto. Gli SDA possono facoltativamente richiedere di essere governati dai titolari di token Spark.

Alcune decisioni possono essere prese in modo automatizzato on-chain, ad esempio modificando il costo della transazione, il tasso di ricompensa oracle o, considerando FXRP come un SDA, modificando il rapporto di garanzia e la commissione di creazione. Altre decisioni come l’aggiunta di una nuova serie temporale all’FTSO e il collegamento del suo asset F proposto, la modifica dei parametri di consenso della rete o aggiornamenti più complessi a lungo termine richiedono una modifica del codice. Il libro bianco Flare stabilisce una proposta, uno sviluppo e un regime di test per le modifiche manuali che possono essere avviate e votate dai titolari di token Spark. Per aiutare a implementare tale processo ed eseguire le modifiche concordate ci sarà una base Flare. La fondazione sarà una onlus, da costituire nei prossimi mesi. È responsabile di 5 settori chiave: sovvenzioni, investimenti, ricerca e sviluppo, istruzione, pubblicità e partenariati.

È la funzione di ricerca e sviluppo che consente alla fondazione di essere parte integrante del processo di aggiornamento della rete, arrivando anche ad analizzare, riferire e quindi creare, testare e distribuire le modifiche proposte al codice di rete.

La fondazione deve essere altamente trasparente e non sprecare denaro. Due relazioni all’anno sulle sue attività e spese saranno rispettate e pubblicate. La fondazione ha lo scopo solo di prendere la direzione dai titolari di token Spark e non di impostare l’ordine del giorno. Come tale, non può: contribuire al FTSO in alcun modo, distribuire qualsiasi delle sue partecipazioni Spark come garanzia per qualsiasi applicazione sulla rete e non può utilizzare le sue partecipazioni Spark per votare in qualsiasi voto di governance. Non può assegnare i suoi token Spark ad altri per farlo. Inoltre, scritto nella costituzione della fondazione sarà l’obbligo che se un voto di governance concorda sul fatto che la fondazione non ha più uno scopo benefico, la fondazione deve interrompere le sue attività e bruciare tutte le sue rimanenti partecipazioni di token al più presto.

Spark Issuance

La migliore community per possedere l’asset che consente l’uso di XRP con Turing complete smart contracts è la community che lo utilizzerà e ne trarrà beneficio: i possessori di XRP. Flare non sta facendo un IT. Invece, sta facendo quello che definiamo un fork di utilità. Crediamo che sia il primo del suo genere.

Un fork ha tradizionalmente cercato di prendere la base di utenti di una rete esistente e partire interamente da quella rete, di solito per avere una relazione antagonista con la catena originale. Al contrario, un fork di utilità ha lo scopo di riportare valore alla catena originale invece di allontanarsi da esso. Flare consente a XRPL di fare ciò che sa fare meglio, liquidazione rapida, portando a XRPL, contratti intelligenti e la fattibilità di creare una pipeline trustless per altre blockchain. Pensiamo che questa sia una combinazione veramente potente e un perfetto esempio di utilità.

verranno creati 100 miliardi di token Spark per rispecchiare la quantità di XRP esistente. Ci sono circa 45 Bn token XRP che non appartengono a Ripple labs. L’obiettivo della distribuzione è che i possessori di XRP diversi da Ripple possano rivendicare circa una quantità 1: 1 di Spark alla loro holding XRP. 45 Bn Spark sarà rivendicabile dai possessori di XRP (eliminando gli indirizzi noti di Ripple labs). 25 Bn Spark andrà a Flare Networks Limited che è l’organizzazione for-profit di Flare. 30 Miliardi di Scintilla andranno alla fondazione Flare.

Poiché molti proprietari di XRP utilizzano effettivamente gli scambi per tenere i loro token XRP, esiste la possibilità che un titolare di XRP che desidera rivendicare i token Spark possa non essere in grado di farlo perché lo scambio rivendica la Spark e li conserva piuttosto che passarli, o in alternativa non li rivendica affatto. Per consentire ai proprietari di XRP di prendere parte alla distribuzione facendo pressione sul loro scambio per distribuire i token Spark o per spostare lo scambio su uno che lo fa, l’istantanea del libro mastro XRP verrà presa in una data più vicina al lancio. Un elenco degli scambi partecipanti sarà pubblicato sul sito web di Flare e aggiornato periodicamente. Il numero di registro delle istantanee verrà pubblicato sul sito Web quando l’istantanea è stata scattata.

TL;DR

Flare è il primo Turing completa Federated Byzantine Agreement (FBA) rete al mondo. Integra la macchina virtuale Ethereum (EVM) e non deriva la sicurezza da un token. In cima a questo è costruito un protocollo per consentire in modo sicuro l’emissione trustless, l’utilizzo e la redenzione, di XRP su Flare. Questo protocollo è chiamato FXRP. La metodologia generale del protocollo e del sistema che collega Flare ad altre reti è estendibile a qualsiasi token completo non di Turing. L’interoperabilità trustless con altre reti è fattibile, sia attraverso protocolli di interoperabilità come Cosmos e Polkadot o con Ethereum tramite protocolli bridge ben definiti.

Il token di Flare, Spark viene creato attraverso quello che potrebbe essere il primo fork di utilità in assoluto per cui la rete di origine, in questo caso il libro mastro XRP, beneficia di una maggiore utilità. 100 Miliardi di token Spark saranno creati all’inizio della rete Flare, di cui 45 miliardi saranno rivendicabili dai possessori di XRP esistenti esclusi Ripple Labs. Ciò rispecchia la quantità esistente di XRP distribuito in modo tale che gli attuali possessori di XRP saranno in grado di richiedere circa 1 token Spark per ogni token XRP detenuto. 25 Miliardi di token andranno agli sviluppatori, Flare e 30 miliardi di token andranno a una fondazione senza scopo di lucro chiamata Flare foundation. I titolari di token Spark possono guadagnare un ritorno sui loro token Spark sia attraverso l’impegno di token Spark come garanzia per garantire l’emissione e il riscatto di FXRP senza fiducia e contribuendo ai dati dell’oracle Flare time series. Queste funzioni non sono in concorrenza tra loro.

Il token Spark viene utilizzato per la governance della rete attraverso il voto. Ad eccezione delle sovvenzioni e degli investimenti per aiutare a sviluppare Flare, la fondazione prende la direzione tecnica dai proprietari di token Spark. Un ruolo chiave della fondazione è quello di aiutare a eseguire aggiornamenti e modifiche alla rete, concordati dal voto di governance, che non possono essere implementati senza una modifica del codice. È importante sottolineare che, scritto nella costituzione della fondazione, sarà uno statuto che la fondazione deve essere liquidata e tutti i token Spark detenuti dalla fondazione bruciati, se i titolari di token Spark concordano sul fatto che la sua esistenza non è più vantaggiosa per la rete.

Flare riunisce il valore dei token completi non di Turing con il potere trasformativo dei contratti intelligenti su una rete in grado di scalare per valore e throughput delle transazioni.

Risposte a due domande:

Spark sta creando Proof of Stake dalla backdoor?

Solo i token emessi che richiedono garanzie, come FXRP, sono protetti con Spark. La rete non utilizza Spark per la sicurezza nel venire al consenso.

Avevamo (quello che pensiamo essere) concetti molto forti per una moneta stabile denominata in USD, ma richiedeva un’ampia reingegnerizzazione della macchina virtuale Ethereum che avrebbe ritardato il lancio e avuto effetti imprevedibili sulla futura compatibilità con l’EVM. Spark come è strutturato, offre un’utilità e un vantaggio molto maggiori sia per la comunità XRP che per il libro mastro XRP.