Il Copyright è di proprietà di block.one e lo scopo della traduzione è puramente educativo.
Abstract: Il software EOS.IO introduce una nuova architettura blockchain progettata per abilitare il ridimensionamento verticale e orizzontale delle applicazioni decentralizzate. Ciò si ottiene creando un costrutto simile a un sistema operativo su cui possono essere costruite le applicazioni. Il software fornisce account, autenticazione, database, comunicazione asincrona e pianificazione di applicazioni su più CPU cores o clusters. La tecnologia risultante è un'architettura blockchain che può alla fine scalare milioni di transazioni al secondo, eliminare le fee dell'utente e consentire l'implementazione e il mantenimento rapido e semplice delle applicazioni decentralizzate, nel contesto di una blockchain governata. NOTA BENE: I TOKENS CRITTOGRAFICI IN QUESTO WHITE PAPER FANNO RIFERIMENTO AI TOKENS CRITTOGRAFICI SU UNA BLOCKCHAIN IN RPODUZIONE CHE ADOTTA IL SOFTWARE EOS.IO. NON FANNO RIFERIMENTO AI TOKENS ERC-20 COMPATIBILI DISTRIBUITI SULLA BLOCKCHAIN ETHEREUM IN CONNESSIONE CON LA DISTRIBUZIONE DEI TOKEN EOS. Copyright © 2018 block.one Senza autorizzazione, chiunque può utilizzare, riprodurre o distribuire qualsiasi materiale in questo white paper per uso non commerciale ed educativo (ad esempio, a pagamento o per scopi commerciali) a condizione che venga citata la fonte originale e l'avviso di copyright applicabile.
ESCLUSIONE DI RESPONSABILITÀ: Questo white paper tecnico EOS.IO v2 è solo a scopo informativo. block.one non garantisce l'esattezza o le conclusioni raggiunte in questo white paper e questo white paper è fornito "così com'è". block.one non produce e nega espressamente tutte le dichiarazioni e garanzie, espresse, implicite, statutarie o di altro tipo, incluse, a titolo esemplificativo ma non esaustivo: (i) garanzie di commerciabilità, idoneità per uno scopo particolare, idoneità, utilizzo, titolo o non violazione; (ii) che il contenuto di questo white paper sia esente da errori; e (iii) che tali contenuti non violano i diritti di terzi. block.one e i suoi affiliati non avranno alcuna responsabilità per danni di qualsiasi tipo derivanti dall'uso, riferimento o affidamento su questo white paper o su qualsiasi contenuto qui contenuto, anche se avvisati della possibilità di tali danni. In nessun caso block.one o i suoi affiliati saranno ritenuti responsabili verso qualsiasi persona o entità per eventuali danni, perdite, responsabilità, costi o spese di qualsiasi tipo, diretti o indiretti, consequenziali, compensativi, incidentali, effettivi, esemplari, punitivi o speciali per l'uso, il riferimento o affidamento su questo white paper o qualsiasi contenuto nel presente documento, inclusi, a titolo esemplificativo, eventuali perdite di affari, ricavi, profitti, dati, utilizzo, avviamento o altre perdite immateriali.
Background: La tecnologia Blockchain è stata introdotta nel 2008 con il lancio della valuta Bitcoin e da allora imprenditori e sviluppatori hanno tentato di generalizzare la tecnologia per supportare una più ampia gamma di applicazioni su una singola piattaforma blockchain. Mentre un certo numero di piattaforme blockchain ha faticato a supportare applicazioni funzionali decentralizzate, blockchain specifiche per applicazioni come BitShares decentralized exchange (2014) e la piattaforma social media di Steem (2016) sono diventate blockchain fortemente utilizzate con decine di migliaia di utenti attivi quotidianamente. Hanno ottenuto questo risultato aumentando le prestazioni a migliaia di transazioni al secondo, riducendo il tempo di risposta a 1,5 secondi, eliminando le commissioni per transazione e fornendo un'esperienza all’utenza simile a quelle attualmente fornite dai servizi centralizzati esistenti. Le piattaforme di blockchain esistenti sono gravate da tariffe elevate e una capacità computazionale limitata che impedisce l'adozione diffusa di blockchain.
Requisiti per le applicazioni Blockchain Per ottenere un uso diffuso, le applicazioni sulla blockchain richiedono una piattaforma sufficientemente flessibile per soddisfare i seguenti requisiti:
Supportare milioni di utenti Competere con aziende come eBay, Uber, AirBnB e Facebook, richiede una tecnologia blockchain in grado di gestire decine di milioni di utenti giornalieri attivi. In alcuni casi, un'applicazione potrebbe non funzionare se non viene raggiunta una massa critica di utenti e quindi una piattaforma in grado di gestire un numero molto elevato di utenti è fondamentale.
Utilizzo gratuito Gli sviluppatori di applicazioni hanno bisogno della flessibilità per offrire agli utenti servizi gratuiti; gli utenti non dovrebbero pagare per utilizzare la piattaforma o beneficiare dei suoi servizi. È probabile che una piattaforma blockchain gratuita per gli utenti ottenga un'adozione più diffusa. Gli sviluppatori e le aziende possono quindi creare strategie di monetizzazione efficaci.
Aggiornamenti facili e recupero dei bug Le aziende che creano applicazioni basate su blockchain necessitano della flessibilità per migliorare le loro applicazioni con nuove funzionalità. La piattaforma deve supportare software e aggiornamenti dello smart contract. Tutti il software importante è soggetto a bug, anche con la più rigorosa verifica formale. La piattaforma deve essere abbastanza robusta da correggere bug quando inevitabilmente si verificano.
Rapidi tempi di risposta Una buona esperienza dell’utenza richiede feedback affidabili con un ritardo di non più di pochi secondi. Ritardi più lunghi deludono gli utenti e rendono le applicazioni basate su una blockchain meno competitiva con le esistenti alternative non blockchain. La piattaforma dovrebbe supportare rapidi tempi di risposta delle transazioni.
Prestazioni sequenziali Ci sono alcune applicazioni che non possono essere implementate con algoritmi paralleli a causa di passaggi sequenzialmente dipendenti. Applicazioni come gli scambi richiedono prestazioni sequenziali sufficienti per gestire volumi elevati. Pertanto, la piattaforma deve supportare prestazioni sequenziali rapide.
Prestazioni parallele Le applicazioni su larga scala devono dividere il carico di lavoro su più CPU e computers.
Algoritmo di consenso (BFT-DPOS) Il software EOS.IO utilizza l'unico algoritmo di consenso decentralizzato noto, in grado di soddisfare i requisiti prestazionali delle applicazioni sulla blockchain, Delegated Proof of Stake (DPOS). In base a questo algoritmo, coloro che detengono i tokens su una blockchain che adotta il software EOS.IO possono selezionare i produttori di blocchi tramite un sistema di voto di approvazione continuo. Chiunque può scegliere di partecipare alla produzione di blocchi e verrà data l'opportunità di produrre blocchi, a condizione che possano persuadere i titolari di token a votare per loro. Il software EOS.IO consente di produrre blocchi esattamente ogni 0,5 secondi e un produttore è autorizzato a produrre un blocco in qualsiasi momento rispettando questo tempo. Se il blocco non viene prodotto nel tempo pianificato, viene saltato il blocco. Quando uno o più blocchi vengono saltati, c'è una pausa di 0,5 o più secondi nella blockchain. Utilizzando il software EOS.IO, i blocchi vengono prodotti in round di 126 (6 blocchi ciascuno, per 21 produttori). All'inizio di ogni turno 21 produttori unici di blocchi vengono scelti in base alla preferenza dei voti espressi dai titolari di token. I produttori selezionati sono programmati secondo un ordine concordato tra 15 o più produttori. Se un produttore salta un blocco e non ha prodotto alcun blocco nelle ultime 24 ore, viene rimosso dalla valutazione fino a quando non notifica alla blockchain la propria intenzione di iniziare a produrre blocchi nuovamente. Ciò garantisce che la rete funzioni senza intoppi riducendo al minimo il numero di blocchi persi non eliminando i produttori che si dimostrano inaffidabili. In condizioni normali una blockchain DPOS non presenta fork perché, piuttosto che competere, i produttori di blocchi cooperano per produrre blocchi. Nel caso in cui vi sia un fork, il consenso passerà automaticamente alla catena più lunga. Questo metodo funziona perché la velocità con cui i blocchi vengono aggiunti a un blockchain fork è direttamente correlata alla percentuale di produttori di blocchi che condividono lo stesso consenso. In altre parole, un blockchain fork con più produttori su di essa crescerà di lunghezza più velocemente di una con meno produttori, perché il fork con più produttori presenterà meno blocchi mancanti. Inoltre, nessun produttore di blocchi dovrebbe produrre blocchi su due fork allo stesso tempo. Un produttore di blocco sorpreso a farlo verrà probabilmente eliminato. È inoltre possibile utilizzare prove crittografiche di tale doppia produzione per rimuovere automaticamente gli autori di abusi. Byzantine Fault Tolerance viene aggiunta al DPOS tradizionale consentendo a tutti i produttori di firmare tutti i blocchi a condizione che nessun produttore segni due blocchi con lo stesso timestamp o la stessa dimensione del blocco. Una volta che 15 produttori hanno firmato un blocco, il blocco è ritenuto irreversibile. Qualsiasi produttore byzantine dovrebbe generare prove crittografiche della sua slealtà firmando due blocchi con lo stesso timestamp o dimensione del blocco. Secondo questo modello, un consenso permanente dovrebbe essere raggiungibile entro 1 secondo.
Conferma della transazione Tipiche DPOS blockchain hanno una partecipazione al 100% dei produttori di blocchi. Una transazione può essere considerata confermata con una certezza del 99,9% dopo una media di 0,25 secondi dal momento della trasmissione. Oltre a DPOS, EOS.IO aggiunge il Byzantine Fault Tolerance asincrono (aBFT) per il raggiungimento più rapido dell'irreversibilità. L'algoritmo aBFT fornisce una conferma del 100% di irreversibilità entro 1 secondo.
Transaction come Proof of Stake (TaPoS) Il software EOS.IO richiede che ogni transazione includa parte dell'hash di un'intestazione di blocco recente. Questo hash ha due scopi: 1. impedisce la riproduzione di una transazione su fork che non includono il blocco di riferimento; 2. segnala alla rete che un particolare utente e il suo stake si trovano su una fork specifica. Nel tempo tutti gli utenti finiscono per confermare direttamente la blockchain che rende difficile falsificare le catene contraffatte poiché la contraffazione non sarebbe in grado di migrare le transazioni dalla catena legittima.
Accounts Il software EOS.IO consente a tutti gli account di essere referenziati da un nome umano leggibile unico di massimo 12 caratteri. Il nome è scelto dal creatore dell'account. Il creatore dell'account deve prenotare la RAM necessaria per memorizzare il nuovo account fino a quando il nuovo account detiene i token per prenotare la propria RAM. In un contesto decentralizzato, gli sviluppatori di applicazioni pagheranno il costo nominale della creazione dell'account per iscrivere un nuovo utente. Le imprese tradizionali già spendono ingenti somme di denaro per i clienti che acquistano sotto forma di pubblicità, servizi gratuiti, ecc. Il costo del finanziamento di un nuovo account sulla blockchain dovrebbe essere insignificante al confronto. Fortunatamente, non è necessario creare account per gli utenti già registrati da un'altra applicazione.
Azioni e Gestori Ogni account può inviare Azioni strutturate ad altri account e può definire script per gestire Azioni quando vengono ricevuti. Il software EOS.IO assegna ad ogni account il proprio database privato a cui possono accedere solo i propri gestori di azioni. Gli script di gestione delle azioni possono anche inviare Azioni ad altri account. La combinazione di azioni e gestori automatici di azioni è il modo in cui EOS.IO definisce gli smart contracts.
Per supportare l'esecuzione parallela, ogni account può anche definire qualsiasi numero di scopi all'interno del proprio database. I produttori di blocchi pianificheranno la transazione in modo tale che non ci siano conflitti sull'accesso alla memoria per gli scopi e quindi possano essere eseguiti in parallelo.
Gestione dei permessi basata sui ruoli La gestione delle autorizzazioni comporta la determinazione dell'appropriazione o meno di un'azione correttamente autorizzata. La forma più semplice di gestione dei permessi è controllare che una transazione abbia le firme richieste, ma questo implica che le firme richieste siano già note. Generalmente, l'autorità è legata a individui o gruppi di individui ed è spesso compartimentata. Il software EOS.IO fornisce un sistema di gestione dei permessi dichiarativo che fornisce agli account un controllo a grana fine e ad alto livello su chi può fare cosa e quando. È fondamentale che l'autenticazione e la gestione dei permessi siano standardizzati e separati dalla logica aziendale dell'applicazione. Ciò consente di sviluppare strumenti per gestire le autorizzazioni in modo generico e offre anche opportunità significative per l'ottimizzazione delle prestazioni. Ogni account può essere controllato da una combinazione ponderata di altri account e chiavi private. Ciò crea una struttura gerarchica di autorità che riflette il modo in cui le autorizzazioni sono organizzate nella realtà e rende più facile che mai il controllo multiutente sugli account. Il controllo multiutente è l’unico grande aiuto alla sicurezza e, se usato correttamente, può ridurre notevolmente il rischio di furti dovuti all'hacking. Il software EOS.IO consente agli account di definire quale combinazione di chiavi e / o account può inviare un particolare tipo di azione a un altro account. Ad esempio, è possibile avere una chiave per l'account di social media di un utente e un'altra per l'accesso allo scambio. È anche possibile concedere ad altri account il permesso di agire per conto dell'account di un utente senza assegnargli le chiavi.
Livelli di autorizzazione denominati Utilizzando il software EOS.IO, gli account possono definire livelli di autorizzazione specifici ciascuno dei quali può essere derivato da autorizzazioni specificate a livello superiore. Ogni livello di autorizzazione nominato definisce un'autorità; un'autorità è un controllo a più firme di soglia costituito da chiavi e / o livelli di autorizzazione denominati di altri account. Ad esempio, il livello di autorizzazione "Amico" di un account può essere impostato affinché un'azione sull'account sia controllata in modo uguale da uno qualsiasi degli amici dell'account. Un altro esempio è la blockchain di Steem che ha tre livelli di autorizzazione con nome codificato: owner, active e posting. L'autorizzazione alla pubblicazione può solo eseguire azioni sociali come il voto e la pubblicazione, mentre l'autorizzazione attiva può fare tutto tranne il cambio del proprietario. L'autorizzazione del proprietario è pensata per il cold storage ed è in grado di fare tutto. Il software EOS.IO generalizza questo concetto consentendo a ciascun titolare di account di definire la propria gerarchia e il raggruppamento di azioni.
Mappatura delle autorizzazioni Il software EOS.IO consente a ciascun account di definire una mappatura tra un contratto / azione o un contratto di qualsiasi altro account e il proprio Livello di autorizzazione specificato. Ad esempio, un titolare del conto può mappare l'applicazione social media del titolare del conto al gruppo di autorizzazioni "Amico" del titolare del conto. Con questa mappatura, qualsiasi amico può postare come titolare dell'account sui social media del titolare dell'account. Anche se pubblicassero come il titolare del conto, utilizzerebbero comunque le proprie chiavi per firmare l'azione. Ciò significa che è sempre possibile identificare quali amici hanno utilizzato l'account e in che modo.
Valutazione delle autorizzazioni Quando si consegna un'azione di tipo "Azione", da @alice a @bob, il software EOS.IO controlla innanzitutto se @alice ha definito una mappatura delle autorizzazioni per @ bob.groupa.subgroup.Action. Se non viene trovato nulla, allora verrà controllata una mappatura per @ bob.groupa.subgroup quindi @ bob.groupa, e infine @bob. Se non viene trovata alcuna ulteriore corrispondenza, la mappatura presunta sarà inviata al gruppo di autorizzazioni denominato @ alice.active. Una volta identificata una mappatura, l'autorizzazione di firma viene convalidata utilizzando il processo di firma multipla a soglia e l'autorizzazione associata all'autorizzazione denominata. Se fallisce, passa all’autorizzazione genitore e infine all'autorizzazione proprietario, @ alice.owner.
Gruppi di autorizzazioni predefiniti La tecnologia EOS.IO consente inoltre a tutti gli account di avere un gruppo "proprietario" che può fare tutto e un gruppo "attivo" che può fare tutto tranne cambiare il gruppo proprietario. Tutti gli altri gruppi di autorizzazioni sono derivati da "attivi".
Valutazione parallela delle autorizzazioni Il processo di valutazione dell'autorizzazione è "di sola lettura" e le modifiche alle autorizzazioni effettuate dalle transazioni non hanno effetto fino alla fine di un blocco. Ciò significa che tutte le chiavi e la valutazione delle autorizzazioni per tutte le transazioni possono essere eseguite in parallelo. Inoltre, ciò significa che è possibile una rapida convalida del permesso senza l'avvio di costose logiche applicative che dovrebbero essere ripristinate. Infine, significa che le autorizzazioni di transazione possono essere valutate come transazioni in sospeso e non devono essere rivalutate man mano che vengono applicate. Tutto sommato, la verifica dell'autorizzazione rappresenta una percentuale significativa del calcolo richiesto per convalidare le transazioni. Rendendo questo un processo di sola lettura e banalmente parallelizzabile consente un notevole aumento delle prestazioni. Quando si riproduce la blockchain per rigenerare lo stato deterministico dal registro delle azioni, non è necessario valutare nuovamente le autorizzazioni. Il fatto che una transazione sia inclusa in un blocco valido noto è sufficiente per saltare questo passaggio. Questo riduce drasticamente il carico computazionale associato alla riproduzione di una blockchain in continua crescita.
Azioni con ritardo obbligatorio Il tempo è un componente fondamentale della sicurezza. Nella maggior parte dei casi, non è possibile sapere se una chiave privata è stata rubata fino a quando non è stata utilizzata. La sicurezza basata sul tempo è ancora più importante quando le persone hanno applicazioni che richiedono che le chiavi vengano conservate su computer connessi a Internet per l'uso quotidiano. Il software EOS.IO consente agli sviluppatori di applicazioni di indicare che determinate azioni devono attendere un periodo di tempo minimo dopo essere state incluse in un blocco prima che possano essere applicate. Durante questo periodo, possono essere cancellati. Gli utenti possono quindi ricevere notifiche via email o messaggi di testo quando viene trasmessa una di queste azioni. Se non l'hanno autorizzato, possono utilizzare la procedura di recupero dell'account per recuperare il proprio account e ritirare l'azione. Il ritardo richiesto dipende dalla sensibilità di un'operazione. Pagare un caffè potrebbe non avere alcun ritardo ed essere irreversibile in pochi secondi, mentre l'acquisto di una casa potrebbe richiedere un periodo di compensazione di 72 ore. Il trasferimento di un intero account a un nuovo controllo può richiedere fino a 30 giorni. I ritardi esatti vengono scelti dagli sviluppatori e dagli utenti dell'applicazione.
Recupero da chiavi rubate Il software EOS.IO offre agli utenti un modo per ripristinare il controllo del proprio account quando vengono rubate le chiavi. Il proprietario di un account può utilizzare qualsiasi chiave del proprietario attiva negli ultimi 30 giorni e approvata dal partner di recupero dell'account designato per reimpostare la chiave del proprietario sul proprio account. Il partner per il recupero dell'account non può reimpostare il controllo dell'account senza l'aiuto del proprietario. Non c'è nulla che l'hacker possa guadagnare tentando di passare attraverso il processo di recupero perché già "controlla" l'account. Inoltre, se avessero attraversato il processo, il partner per il recupero avrebbe probabilmente richiesto l'identificazione e l'autenticazione a più fattori (telefono ed e-mail). Ciò probabilmente comprometterebbe l'hacker o non farebbe guadagnare nulla agli hacker nel processo. Questo processo è anche molto diverso da una semplice disposizione multi-firma. Con una transazione con più firme, un'altra entità diventa parte per ogni transazione eseguita. Al contrario, con il processo di ripristino il partner di ripristino è solo una parte del processo di ripristino e non ha alcun potere sulle transazioni giornaliere. Questo riduce drasticamente costi e responsabilità legali per tutti i soggetti coinvolti.
Esecuzione parallela deterministica delle applicazioni Il consenso blockchain dipende dal comportamento deterministico (riproducibile). Ciò significa che tutte le esecuzioni parallele devono essere libere dall'uso di mutex o altre primitive di blocco. Senza blocchi ci deve essere un modo per garantire che le transazioni che possono essere eseguite in parallelo non creino risultati non deterministici. La versione di giugno 2018 del software EOS.IO verrà eseguita con thread singolo, ma contiene le strutture di dati necessarie per la futura esecuzione parallela multithread. In una blockchain basata su software EOS.IO, una volta abilitata l'operazione parallela, sarà compito del produttore di blocchi organizzare il delivery di Action in frammenti indipendenti in modo che possano essere valutati in parallelo. Il programma è la produzione di un produttore di blocchi e verrà eseguito in modo deterministico, ma il processo per generare il programma non deve essere deterministico. Ciò significa che i produttori di blocchi possono utilizzare algoritmi paralleli per pianificare le transazioni. Parte dell'esecuzione parallela significa che quando uno script genera una nuova azione non viene consegnato immediatamente, ma è pianificato per essere consegnato nel ciclo successivo. Il motivo per cui non può essere consegnato immediatamente è perché il ricevitore potrebbe modificare attivamente il proprio stato in un altro frammento.
Riduzione al minimo della latenza delle comunicazioni La latenza è il tempo impiegato da un account per inviare un'azione a un altro account e quindi ricevere una risposta. L'obiettivo è di consentire a due account di scambiare azioni avanti e indietro all'interno di un singolo blocco senza dover attendere 0,5 secondi tra ciascuna azione. Per abilitare questo, il software EOS.IO divide ciascun blocco in cicli. Ogni ciclo è diviso in frammenti e ogni frammento contiene un elenco di transazioni. Ogni transazione contiene un insieme di azioni da consegnare. Questa struttura può essere visualizzata come un albero in cui gli strati alternati vengono elaborati in sequenza e in parallelo. Block Region Cycles (sequential) Shards (parallel) Transactions (sequential) Actions (sequential) Receiver and Notified Accounts (parallel) Le transazioni generate in un ciclo possono essere consegnate in qualsiasi ciclo o blocco successivo. I produttori di blocchi continueranno ad aggiungere cicli ad un blocco fino a quando non sarà trascorso il tempo massimo di clock o non ci saranno nuove transazioni generate da consegnare. È possibile utilizzare l'analisi statica di un blocco per verificare che all'interno di un dato ciclo non ci siano due frammenti contenenti transazioni che modificano lo stesso account. Finché tale invariante viene mantenuto, è possibile elaborare un blocco eseguendo tutti i frammenti in parallelo.
Operatori di azioni di sola lettura Alcuni account potrebbero essere in grado di elaborare un'azione su base pass/fail senza modificare il loro stato interno. Se questo è il caso, allora questi gestori possono essere eseguiti in parallelo fintantoché solo gestori di azioni di sola lettura per un particolare account sono inclusi in uno o più frammenti all'interno di un particolare ciclo.
Transazioni atomiche con più account A volte è auspicabile garantire che le Azioni vengano consegnate e accettate da più account atomicamente. In questo caso, entrambe le Azioni vengono inserite in una transazione e ad entrambi gli account verrà assegnato lo stesso frammento e le Azioni applicate in sequenza.
Valutazione parziale dello stato Blockchain La scalabilità della tecnologia blockchain richiede che i componenti siano modulari. Tutti non dovrebbero dover eseguire tutto, soprattutto se hanno solo bisogno di utilizzare un piccolo sottoinsieme delle applicazioni. Uno sviluppatore di applicazioni di scambio gestisce i nodi completi allo scopo di visualizzare lo stato di scambio ai propri utenti. Questa applicazione di scambio non ha bisogno dello stato associato alle applicazioni dei social media. Il software EOS.IO consente a qualsiasi nodo completo di selezionare qualsiasi sottoinsieme di applicazioni da eseguire. Le azioni consegnate ad altre applicazioni vengono ignorate in modo sicuro se la tua applicazione non dipende dallo stato di un altro contratto.
Programmazione soggettiva Best Effort Il software EOS.IO non può obbligare i produttori di blocchi a consegnare qualsiasi Azione a qualsiasi altro account. Ogni produttore di blocchi rende la propria misurazione soggettiva della complessità computazionale e del tempo richiesto per elaborare una transazione. Ciò si applica sia che una transazione sia generata da un utente sia automaticamente da uno smart contract. Su una blockchain in produzione che adotta il software EOS.IO, a livello di rete tutte le transazioni vengono fatturate a un costo di larghezza di banda computazionale basato sul numero di istruzioni WASM eseguite. Tuttavia, ogni singolo produttore di blocchi che utilizza il software può calcolare l'utilizzo delle risorse utilizzando il proprio algoritmo e le proprie misure. Quando un produttore di blocchi conclude che una transazione o un conto ha consumato una quantità sproporzionata della capacità computazionale, rifiutano semplicemente la transazione quando producono il proprio blocco; tuttavia, elaboreranno ancora la transazione se altri produttori di blocco lo ritengono valido. In generale, purché anche un produttore di blocchi consideri una transazione valida e ai limiti dell'utilizzo delle risorse, tutti gli altri produttori di blocchi lo accetteranno, ma potrebbe essere necessario fino a 1 minuto per la transazione per trovare quel produttore. In alcuni casi, un produttore può creare un blocco che include transazioni di un ordine di grandezza al di fuori degli intervalli accettabili. In questo caso il produttore del blocco successivo può scegliere di rifiutare il blocco e il legame verrà interrotto dal terzo produttore. Questo non è diverso da quello che succederebbe se un grosso blocco causasse ritardi nella propagazione della rete. La comunità avrebbe notato un modello di abuso e alla fine avrebbe rimosso i voti dal produttore impostore. Questa valutazione soggettiva del costo computazionale libera la blockchain dal dover misurare in modo preciso e deterministico quanto tempo ci vuole per la esecuzione. Con questo design non è necessario contare con precisione le istruzioni che aumentano notevolmente le opportunità di ottimizzazione senza rompere il consenso.
Transazioni differite Il software EOS.IO supporta le transazioni posticipate che sono pianificate per l'esecuzione in futuro. Ciò consente al calcolo di passare a diversi frammenti e / o alla creazione di processi di lunga durata che pianificano continuamente una transazione di continuità.
Azioni libere dal contesto Un'Azione Context Free comporta calcoli che dipendono solo dai dati della transazione, ma non dallo stato della blockchain. La verifica della firma, ad esempio, è un calcolo che richiede solo i dati della transazione e una firma per determinare la chiave pubblica che ha firmato la transazione. Questo è uno dei più costosi calcoli individuali che una blockchain deve eseguire, ma poiché questo calcolo è privo di contesto, può essere eseguito in parallelo. Le azioni contestuali sono come le altre azioni dell'utente, tranne per il fatto che non hanno accesso allo stato blockchain per eseguire la convalida. Ciò non solo consente a EOS.IO di elaborare tutte le azioni contestuali come la verifica della firma in parallelo, ma, cosa più importante, consente la verifica della firma generalizzata. Con il supporto di Context Free Actions, le tecniche di scalabilità come Sharding, Raiden, Plasma, Canali di stato e altri diventano molto più parallelizzabili e pratiche. Questo sviluppo consente comunicazioni inter-blockchain efficienti e scalabilità potenzialmente illimitata.
Token Model ed utilizzo delle risorse NOTA BENE: I TOKENS CRITTOGRAFICI DI CUI IN QUESTO WHITE PAPER FANNO RIFERIMENTO AI TOKENS CRITTOGRAFICI SU UN BLOCKCHAIN IN PRODUZIONE CHE ADOTTA IL SOFTWARE EOS.IO. NON FANNO RIFERIMENTO AI TOKENS ERC-20 COMPATIBILI DISTRIBUITI SULLA BLOCKCHAIN ETHEREUM IN CONNESSIONE CON LA DISTRIBUZIONE DEI TOKEN EOS. Tutte le blockchain sono limitate in termini di risorse e richiedono un sistema per prevenire gli abusi. Con una blockchain che utilizza il software EOS.IO, ci sono tre ampie classi di risorse che vengono utilizzate dalle applicazioni: 1. Larghezza di banda e archiviazione dei registri (disco); 2. Computation and Computational Backlog (CPU); e 3. State Storage (RAM). La larghezza di banda e il calcolo hanno due componenti, l'uso istantaneo e l'uso a lungo termine. Una blockchain mantiene un registro di tutte le azioni e questo registro viene infine memorizzato e scaricato da tutti i nodi completi. Con il log delle azioni, è possibile ricostruire lo stato di tutte le applicazioni. Il debito computazionale è un calcolo che deve essere eseguito per rigenerare lo stato dal registro di azione. Se il debito computazionale diventa troppo grande, diventa necessario scattare istantanee dello stato della blockchain e scartare la storia della blockchain. Se il debito computazionale cresce troppo rapidamente, potrebbero essere necessari 6 mesi per ripetere il valore di 1 anno di transazioni. È quindi fondamentale che il debito computazionale sia gestito con cura. Lo storage di stato blockchain è un'informazione accessibile dalla logica dell'applicazione. Include informazioni quali ordini e saldi contabili. Se lo stato non viene mai letto dall'applicazione, non dovrebbe essere memorizzato. Ad esempio, i contenuti dei post di blog e i commenti non vengono letti dalla logica dell'applicazione, quindi non dovrebbero essere archiviati nello stato della blockchain. Nel frattempo l'esistenza di un post / commento, il numero di voti e altre proprietà vengono memorizzate come parte dello stato della blockchain. I produttori di blocchi pubblicano la loro capacità disponibile per larghezza di banda, calcolo e stato. Il software EOS.IO consente a ciascun account di utilizzare una percentuale della capacità disponibile proporzionale alla quantità di token detenuti in un contratto 3-day staking . Ad esempio, se viene lanciata una blockchain basata sul software EOS.IO e se un account detiene l'1% del totale dei token distribuibili in base a tale blockchain, allora tale account ha il potenziale di utilizzare l'1% della capacità di archiviazione di stato. L'adozione del software EOS.IO su una blockchain avviata significa che la larghezza di banda e la capacità computazionale sono allocate su una base di riserva frazionaria perché sono transitori (la capacità non utilizzata non può essere salvata per un uso futuro). L'algoritmo utilizzato dal software EOS.IO è simile all'algoritmo utilizzato da Steem per l'utilizzo della larghezza di banda del limite di frequenza.
Misure oggettive e soggettive Come discusso in precedenza, la strumentazione dell'uso computazionale ha un impatto significativo sulle prestazioni e sull'ottimizzazione; pertanto, tutti i vincoli di utilizzo delle risorse sono in definitiva soggettivi e l'applicazione viene eseguita dai produttori di blocchi in base ai loro singoli algoritmi e stime. Questi sarebbero tipicamente implementati da un produttore di blocchi tramite la scrittura di un plugin personalizzato. Detto questo, ci sono alcune cose che sono banali da misurare obiettivamente. Il numero di azioni consegnate e la dimensione dei dati archiviati nel database interno sono economici per essere misurati oggettivamente. Il software EOS.IO consente ai produttori di blocchi di applicare lo stesso algoritmo su queste misure oggettive, ma può scegliere di applicare algoritmi soggettivi più rigidi rispetto alle misurazioni soggettive.
Il destinatario paga Tradizionalmente, è l'azienda che paga per lo spazio ufficio, la potenza di calcolo e altri costi necessari per gestire l'attività. Il cliente acquista prodotti specifici dall'azienda e le entrate derivanti da tali vendite di prodotti vengono utilizzate per coprire i costi operativi dell'attività. Allo stesso modo, nessun sito Web obbliga i suoi visitatori a effettuare micropagamenti per visitare il suo sito Web per coprire i costi di hosting. Pertanto, le applicazioni decentralizzate non dovrebbero costringere i propri clienti a pagare direttamente la blockchain per l'uso della blockchain. Una blockchain in produzione che utilizza il software EOS.IO non richiede che i suoi utenti paghino la blockchain direttamente per il suo utilizzo e pertanto non limita o impedisce a un'azienda di determinare la propria strategia di monetizzazione per i propri prodotti. Mentre è vero che il ricevitore può pagare, EOS.IO consente al mittente di pagare la larghezza di banda, il calcolo e l'archiviazione. Ciò consente agli sviluppatori di applicazioni di scegliere il metodo migliore per la loro applicazione. In molti casi, il mittente-pagante riduce in modo significativo la complessità per gli sviluppatori di applicazioni che non vogliono implementare il proprio sistema di razionamento. Gli sviluppatori di applicazioni possono delegare larghezza di banda e calcolo ai propri utenti e quindi lasciare che il modello "mittente pagante" imponga l'utilizzo. Dal punto di vista dell'utente finale è gratuito, ma dal punto di vista della blockchain è mittente pagante.
Capacità di delega Un detentore di token su una blockchain in produzione che adotta il software EOS.IO che potrebbe non avere la necessità immediata di consumare tutta o parte della larghezza di banda disponibile, può delegare o noleggiare tale larghezza di banda non consumata ad altri; i produttori di blocchi che eseguono il software EOS.IO su tale blockchain riconosceranno questa delega di capacità e assegneranno di conseguenza la larghezza di banda.
Separazione dei costi di transazione dal valore del token Uno dei principali vantaggi del software EOS.IO è che la quantità di larghezza di banda disponibile per un'applicazione è completamente indipendente da qualsiasi prezzo di token. Se il proprietario di un'applicazione detiene un numero rilevante di token su una blockchain che adotta il software EOS.IO, l'applicazione può essere eseguita a tempo indeterminato all'interno di uno stato fisso e dell'utilizzo della larghezza di banda. In tal caso, gli sviluppatori e gli utenti non sono interessati da alcuna volatilità dei prezzi nel mercato dei token e quindi non dipendono da un alimentatore di prezzo. In altre parole, una blockchain che adotta il software EOS.IO consente ai produttori di blocchi di aumentare naturalmente la larghezza di banda, il calcolo e lo storage disponibili per token indipendentemente dal valore del token. Una blockchain che utilizza il software EOS.IO assegna anche i token ai produttori di blocchi ogni volta che producono un blocco. Il valore dei token influirà sulla quantità di larghezza di banda, spazio di archiviazione e calcolo che un produttore può permettersi di acquistare; questo modello sfrutta naturalmente i valori dei token in aumento per aumentare le prestazioni della rete.
Costi di archiviazione dello stato Mentre la larghezza di banda e il calcolo possono essere delegati, l'archiviazione dello stato dell'applicazione richiede allo sviluppatore di applicazioni di conservare i token fino a quando tale stato non viene eliminato. Se lo stato non viene mai cancellato, i token vengono effettivamente rimossi dalla circolazione.
Ricompense dei blocchi Una blockchain che adotta il software EOS.IO assegnerà nuovi token a un produttore di blocchi ogni volta che viene prodotto un blocco. In queste circostanze, il numero di token creati è determinato dalla media della retribuzione desiderata pubblicata da tutti i produttori di blocchi. Il software EOS.IO può essere configurato per imporre un limite ai premi del produttore in modo tale che l'aumento annuo totale della fornitura di token non superi il 5%.
Governance La governance è il processo attraverso il quale le persone in una comunità: 1. Raggiungono il consenso su questioni soggettive di azione collettiva che non possono essere acquisite interamente dagli algoritmi software; 2. Eseguono le decisioni che raggiungono; e 3. Modificano le stesse regole di governance tramite emendamenti costituzionali. Una blockchain basata su software EOS.IO implementa un processo di governance che dirige in modo efficiente l'influenza esistente dei produttori di blocchi. In assenza di un processo di governance definito, le precedenti blockchain si basavano su processi di governance ad hoc, informali e spesso controversi che si traducono in esiti imprevedibili. Una blockchain basata sul software EOS.IO riconosce che il potere ha origine con i titolari di token che delegano tale potere ai produttori di blocchi. Ai produttori di blocchi viene concessa un'autorizzazione limitata e controllata per bloccare gli account, aggiornare le applicazioni difettose e proporre modifiche difficilmente modificabili del protocollo sottostante. Incorporato nel software EOS.IO è l'elezione dei produttori di blocchi. Prima che qualsiasi cambiamento possa essere apportato alla blockchain questi produttori di blocchi devono approvarlo. Se i produttori di blocchi rifiutano di apportare modifiche desiderate dai titolari di token, possono essere ritirati. Se i produttori di blocchi apportano modifiche senza il permesso dei titolari di token, tutti gli altri validatori di full-node non di produzione (scambi, ecc.) rifiuteranno la modifica.
Congelamento degli acconts A volte uno smart contract si comporta in modo anormale o imprevedibile e non riesce a eseguire come previsto; altre volte un'applicazione o un account possono scoprire un exploit che gli consente di consumare una quantità irragionevole di risorse. Quando si verificano inevitabilmente tali problemi, i produttori di blocchi hanno il potere di correggere tali situazioni. I produttori di blocchi di tutte le blockchain hanno il potere di selezionare quali transazioni sono incluse in blocchi che danno loro la possibilità di bloccare gli accounts. Una blockchain che utilizza il software EOS.IO formalizza questa autorità sottoponendo il processo di congelamento di un account a un voto 15/21 di produttori attivi. Se i produttori abusano del potere, possono essere ritirati e un account verrà sbloccato.
Modifica del codice dell’account Quando tutto il resto fallisce e una "applicazione inarrestabile" agisce in modo imprevedibile, una blockchain che utilizza il software EOS.IO consente ai produttori di blocchi di sostituire il codice dell'account senza forzare l'intera blockchain. Simile al processo di congelamento di un account, questa sostituzione del codice richiede un voto 15/21 di produttori di blocchi eletti.
Costituzione Il software EOS.IO consente alle blockchain di stabilire un contratto di servizio pari a pari o un contratto vincolante tra gli utenti che lo firmano, definito "costituzione". Il contenuto di questa costituzione definisce gli obblighi tra gli utenti che non possono essere interamente applicati mediante codice e facilita la risoluzione delle controversie stabilendo la giurisdizione e la scelta della legge insieme ad altre regole reciprocamente accettate. Ogni transazione trasmessa sulla rete deve incorporare l'hash della costituzione come parte della firma e quindi vincola esplicitamente il firmatario al contratto. La costituzione definisce anche l'intento leggibile da essere umano del protocollo del codice sorgente. Questo intento viene utilizzato per identificare la differenza tra un bug e una funzionalità quando si verificano errori e guida la comunità su quali correzioni sono corrette o improprie.
Aggiornamento del Protocollo e Costituzione Il software EOS.IO definisce il seguente processo mediante il quale il protocollo, come definito dal codice sorgente canonico e dalla sua costituzione, può essere aggiornato: 1. I produttori di blocchi propongono una modifica della costituzione e ottengono l'approvazione 15/21. 2. I produttori di blocchi mantengono l'approvazione 15/21 della nuova costituzione per 30 giorni consecutivi. 3. Tutti gli utenti sono tenuti a indicare l'accettazione della nuova costituzione come condizione per le transazioni future in corso di elaborazione. 4. I produttori di blocchi adottano modifiche al codice sorgente per riflettere il cambiamento nella costituzione e proporlo alla blockchain usando l'hash della nuova costituzione. 5. I produttori di blocchi mantengono l'approvazione 15/21 del nuovo codice per 30 giorni consecutivi. 6. Le modifiche al codice diventano effettive 7 giorni dopo, dando a tutti i nodi completi non di produzione 1 settimana di aggiornamento dopo la ratifica del codice sorgente. 7. Tutti i nodi che non si aggiornano al nuovo codice si spengono automaticamente. Per impostazione predefinita, configurazione del software EOS.IO, il processo di aggiornamento della blockchain per aggiungere nuove funzionalità richiede da 2 a 3 mesi, mentre gli aggiornamenti per correggere bug non critici che non richiedono modifiche alla costituzione possono richiedere da 1 a 2 mesi.
Modifiche di emergenza I produttori di blocchi possono accelerare il processo se è necessaria una modifica del software per correggere un bug dannoso o un exploit di sicurezza che sta danneggiando attivamente gli utenti. In generale, potrebbero essere contro la costituzione gli aggiornamenti accelerati per introdurre nuove funzionalità o correggere bug innocui.
Script e macchine virtuali Il software EOS.IO sarà prima di tutto una piattaforma per coordinare la consegna di messaggi autenticati (chiamati Azioni) agli account. I dettagli del linguaggio di scripting e della macchina virtuale sono dettagli specifici dell'implementazione che sono per lo più indipendenti dal design della tecnologia EOS.IO. Qualsiasi linguaggio o macchina virtuale che sia deterministica e adeguatamente sandboxed con prestazioni sufficienti può essere integrata con l'API del software EOS.IO.
Azioni definite dallo schema Tutte le azioni inviate tra account sono definite da uno schema che fa parte dello stato di consenso blockchain. Questo schema consente la conversione senza soluzione di continuità tra la rappresentazione binaria e JSON delle azioni.
Database definito dallo schema Lo stato del database viene anche definito utilizzando uno schema simile. Ciò garantisce che tutti i dati memorizzati da tutte le applicazioni siano in un formato che possa essere interpretato come JSON leggibile dall'uomo, ma memorizzato e manipolato con l'efficienza del binario.
Generic multi-index database API Lo sviluppo di smart contract richiede uno schema di database definito per tracciare, archiviare e trovare i dati. Gli sviluppatori hanno generalmente bisogno degli stessi dati ordinati o indicizzati da più campi e per mantenere la coerenza tra tutti gli indici.
Separazione dell'autenticazione dall'applicazione Per massimizzare le opportunità di parallelizzazione e ridurre al minimo il debito computazionale associato alla rigenerazione dello stato dell'applicazione dal log delle transazioni, il software EOS.IO separa la logica di convalida in tre sezioni: 1. Convalidare che un'azione è internamente coerente; 2. Convalidare che tutte le condizioni preliminari sono valide; e 3. Modificare lo stato dell'applicazione. La convalida della compattezza interna di un'azione è di sola lettura e non richiede l'accesso allo stato blockchain. Ciò significa che può essere eseguito con il massimo parallelismo. La convalida delle precondizioni, come il saldo richiesto, è di sola lettura e pertanto può anche beneficiare del parallelismo. Solo la modifica dello stato dell'applicazione richiede l'accesso in scrittura e deve essere elaborata in modo sequenziale per ciascuna applicazione. L'autenticazione è il processo di sola lettura per verificare che un'Azione possa essere applicata. L'applicazione sta effettivamente facendo il lavoro. In tempo reale è necessario eseguire entrambi i calcoli, tuttavia una volta inclusa una transazione nella blockchain non è più necessario eseguire le operazioni di autenticazione.
Comunicazione Inter Blockchain Communication Il software EOS.IO è progettato per facilitare la comunicazione inter-blockchain. Ciò si ottiene rendendo semplice la dimostrazione dell'esistenza dell'azione e la sequenza di prove di azione. Queste dimostrazioni combinate con un'architettura applicativa progettata attorno al passaggio di Action consentono di nascondere i dettagli della comunicazione inter-blockchain e la convalida delle prove agli sviluppatori di applicazioni, consentendo di presentare agli sviluppatori le astrazioni di alto livello.
Merkle Proofs per Light Client Validation (LCV) L'integrazione con altre blockchain è molto più semplice se i client non devono elaborare tutte le transazioni. Dopotutto, uno scambio riguarda solo i trasferimenti dentro e fuori dall’exchange e nulla più. Sarebbe anche ideale se la catena di scambio potesse utilizzare prove di deposito merkle leggere piuttosto che dover fidarsi interamente dei propri produttori di blocchi. Per lo meno i produttori di un blocco di catena vorrebbero mantenere il più piccolo possibile overhead durante la sincronizzazione con un'altra blockchain. L'obiettivo di LCV è di abilitare la generazione di prove di esistenza relativamente leggere che possano essere convalidate da chiunque tenga traccia di un set di dati relativamente leggero. In questo caso l'obiettivo è dimostrare che una particolare transazione è stata inclusa in un particolare blocco e che il blocco è incluso nella cronologia verificata di una determinata blockchain. Bitcoin supporta la convalida delle transazioni presupponendo che tutti i nodi abbiano accesso alla cronologia completa delle intestazioni dei blocchi che ammonta a 4MB di block headers all'anno. A 10 transazioni al secondo, una prova valida richiede circa 512 byte. Questo funziona bene per una blockchain con un intervallo di 10 minuti, ma non è più "leggero" per blockchain con un intervallo di blocco di 0,5 secondi. Il software EOS.IO consente prove leggere per chiunque abbia un'intestazione di blocco irreversibile dopo il punto in cui è stata inclusa la transazione. Utilizzando la struttura hash-linked mostrata è possibile provare l'esistenza di qualsiasi transazione con una prova inferiore a 1024 byte di dimensione. Dato un id di blocco per un blocco nella blockchain, e le intestazioni di un blocco irreversibile affidabile. È possibile dimostrare che il blocco è incluso nella blockchain. Questa dimostrazione prende i ceil(log2(N)) digests per il suo percorso, dove N è il numero di blocchi nella catena. Dato un metodo digest di SHA256, puoi provare l'esistenza di qualsiasi blocco in una catena che contiene 100 milioni di blocchi in 864 byte. C'è un piccolo overhead incrementale associato alla produzione di blocchi con l'hash-linking appropriato per abilitare queste prove, il che significa che non c'è motivo per non generare blocchi in questo modo. Quando arriva il momento di convalidare le prove su altre catene ci sono una grande varietà di ottimizzazioni tempo / spazio / larghezza di banda che possono essere fatte. Tracciare tutte le intestazioni dei blocchi (420 MB / anno) manterrà piccole dimensioni delle prove. Tracciare solo le intestazioni recenti può offrire un compromesso tra archiviazione a lungo termine e dimensioni di prova. In alternativa, una blockchain può usare un approccio di valutazione pigro in cui ricorda gli hash intermedi delle prove passate. Le nuove prove devono includere solo i collegamenti all'albero conosciuto e rado. L'approccio esatto utilizzato dipenderà necessariamente dalla percentuale di blocchi stranieri che includono le transazioni a cui fa riferimento la prova di merkle. Dopo una certa densità di interconnessione, diventa più efficiente avere semplicemente una catena che contiene l'intera cronologia dei blocchi di un'altra catena ed eliminare la necessità di prove tutte insieme. Per motivi di prestazioni, è ideale per ridurre al minimo la frequenza delle prove inter-chain.
Latenza della comunicazione interchain Quando comunicano con un'altra blockchain esterna, i produttori di blocchi devono attendere fino a quando non vi è la certezza del 100% che una transazione sia stata confermata in modo irreversibile dall'altra blockchain prima di accettarla come input valido. Utilizzando una blockchain basata su software EOS.IO e DPOS con blocchi di 0,5 secondi e l'aggiunta dell'irreversibilità di Byzantine Fault Tolerant, questo richiede circa 0,5 secondi. Se i produttori di bolcchi di catene non aspettano l'irreversibilità, sarebbe come uno scambio che accredita un deposito che è stato successivamente annullato e potrebbe influire sulla validità del consenso della blockchain. Il software EOS.IO utilizza sia DPOS che aBFT per fornire una rapida irreversibilità.
Prova di completezza Quando si usano le prove di merkle da blockchain esterne, c'è una differenza significativa tra sapere che tutte le transazioni processate sono valide e sapere che nessuna transazione è stata saltata o omessa. Sebbene sia impossibile dimostrare che tutte le transazioni più recenti siano conosciute, è possibile dimostrare che non ci sono stati vuoti nella cronologia delle transazioni. Il software EOS.IO facilita questo assegnando un numero di sequenza a ogni Azione consegnata a ogni account. Un utente può utilizzare questi numeri di sequenza per dimostrare che tutte le azioni previste per un determinato account sono state elaborate e che sono state elaborate in ordine.
Segregated Witness Il concetto di Segregated Witness (SegWit) è che le firme delle transazioni non sono rilevanti dopo che una transazione è immutabilmente inclusa nella blockchain. Una volta che è immutabile, i dati della firma possono essere eliminati e tutti gli altri possono ancora derivare lo stato corrente. Poiché le firme rappresentano una grande percentuale della maggior parte delle transazioni, SegWit rappresenta un notevole risparmio nell'utilizzo del disco e nel tempo di sincronizzazione. Questo stesso concetto può essere applicato alle prove di merkle utilizzate per la comunicazione inter-blockchain. Una volta accettata la prova e inserita irreversibilmente nella blockchain, i 2KB di hash sha256 usati dalla dimostrazione non sono più necessari per derivare lo stato corretto della blockchain. Nel caso della comunicazione inter-blockchain, questo risparmio è 32 volte maggiore rispetto ai risparmi sulle normali firme. Un altro esempio di SegWit sarebbe per i post del blog di Steem. Sotto questo modello un post conterrebbe solo lo sha256 (contenuto del blog) e il contenuto del blog sarebbe nei dati dei testimoni separati. Il produttore di blocchi verificherà che il contenuto esista e abbia l'hash specificato, ma il contenuto del blog non dovrebbe essere archiviato per ripristinare lo stato corrente dal log della blockchain. Ciò consente di provare che il contenuto era noto una volta senza dover memorizzare per sempre il contenuto.
Conclusione
Il software EOS.IO è progettato in base all'esperienza con concetti collaudati e pratiche migliori e rappresenta un progresso fondamentale nella tecnologia blockchain. Il software fa parte di un progetto olistico per una società blockchain scalabile a livello globale in cui le applicazioni decentralizzate possono essere facilmente implementate e governate.
Supportate il progetto con upvote e resteem. Grazie a tutti!
Sito web: http://eositalia.io