Ergo Whitepaper Ver.1

Tempo di lettura stimato: 47 minuti

Versione in italiano

Ergo: una piattaforma resiliente per gli sviluppatori di denaro contrattuale

Ergo, https://ergoplatform.org 14 maggio 2019

v1.0

Astratto

Vi presentiamo Ergo, un nuovo protocollo blockchain flessibile. Ergo è progettato per lo sviluppo di applicazioni decentralizzate con l’obiettivo principale di fornire un modo efficiente, sicuro e semplice per implementare i contratti finanziari. Per raggiungere questo obiettivo, Ergo include vari miglioramenti tecnici ed economici alle soluzioni blockchain esistenti. Ogni moneta in Ergo è protetta da un programma in ErgoScript, che è un linguaggio di scripting potente e compatibile con i protocolli basato sui protocolli Σ. Utilizzando ErgoScript, possiamo codificare le condizioni in cui le monete possono essere utilizzate: chi può spenderle, quando, in quali condizioni esterne, a chi e così via.

Il supporto esteso per i nodi leggeri rende Ergo amichevole per gli utenti finali perché consente di eseguire contratti su hardware di base non affidabile. Per essere utilizzabile a lungo termine, Ergo segue un approccio di sopravvivenza: utilizza soluzioni ampiamente studiate che non comportano problemi di sicurezza in futuro, prevenendo anche il degrado delle prestazioni nel tempo con un nuovo modello economico. Infine, Ergo ha un protocollo automodificabile che gli consente di assorbire nuove idee e migliorarsi in futuro.

Introduzione

A partire da più di dieci anni fa con Bitcoin [1], la tecnologia blockchain si è finora dimostrata un modo sicuro per mantenere un registro delle transazioni pubbliche e disintermediare in una certa misura terze parti fidate come le istituzioni finanziarie tradizionali. Anche dopo aver raggiunto una capitalizzazione di mercato di oltre $ 300 miliardi nel 2017 [2], non sono stati effettuati gravi attacchi alla rete Bitcoin nonostante l’alto rendimento potenziale.

Questa resilienza delle criptovalute e l’emancipazione finanziaria e l’auto-sovranità che promettono di portare è raggiunta da una combinazione di moderni algoritmi crittografici e architettura decentralizzata. Tuttavia, questa resilienza ha un costo e non è stata ancora dimostrata per i sistemi esistenti a lungo termine su scala economica. Per utilizzare una blockchain senza alcuna fiducia, i suoi partecipanti dovrebbero controllarsi a vicenda scaricando ed elaborando tutte le transazioni nella rete, utilizzando le risorse di rete. Oltre all’utilizzo della rete, l’elaborazione delle transazioni utilizza anche risorse di calcolo, soprattutto se il linguaggio transazionale è sufficientemente flessibile. Infine, i partecipanti alla blockchain devono mantenere una quantità significativa di dati nei loro archivi locali e i requisiti di archiviazione stanno crescendo rapidamente.

Di questi, alcuni dati devono essere mantenuti in memoria. Pertanto, l’elaborazione delle transazioni utilizza varie risorse di centinaia di migliaia di computer in tutto il mondo e il consumo di queste risorse è pagato dagli utenti regolari sotto forma di commissioni di transazione [3]. Nonostante il generoso sussidio di ricompensa in blocco in alcuni sistemi esistenti, le loro commissioni possono essere ancora molto alte a volte [4].

Per questo motivo, anche dopo essere in circolazione da più di dieci anni, la tecnologia blockchain è ancora utilizzata principalmente nelle applicazioni finanziarie, dove il vantaggio dell’elevata sicurezza supera lo svantaggio degli elevati costi di transazione. Oltre all’esempio della valuta vanilla, l’altro uso delle blockchain è quello di creare applicazioni decentralizzate. Tali applicazioni utilizzano la capacità della piattaforma sottostante di scrivere contratti intelligenti [5] implementando la loro logica per mezzo di un linguaggio di programmazione specifico per blockchain. Un modo per classificare le blockchain in base alla loro capacità di scrivere contratti intelligenti si basa sul fatto che siano basate su UTXO (ad es. Bitcoin) o basate su account (ad es. Ethereum) [6]. Le criptovalute basate su account, come Ethereum, introducono conti speciali controllati dal codice, che possono essere invocati dalle transazioni in entrata. Sebbene questo approccio consenta di eseguire calcoli arbitrari, l’implementazione di condizioni di spesa complesse può portare a bug come quello in un “semplice” contratto multi-firma di Ethereum che ha causato una perdita di $ 150 milioni nel 2017 [7].

Nelle criptovalute basate su UTXO, ogni moneta ha uno script associato e per spendere quella moneta, è necessario soddisfare le condizioni indicate nello script. L’implementazione di tali condizioni di protezione è molto più semplice con il modello UTXO, ma eseguire calcoli arbitrari completi di Turing è piuttosto complesso [8]. Tuttavia, la maggior parte dei contratti finanziari non richiede la completezza di Turing [9]. Ergo si basa sul modello UTXO e fornisce un modo conveniente per implementare applicazioni finanziarie che coprono la stragrande maggioranza dei casi d’uso della blockchain pubblica. Sebbene la componente contrattuale sia importante per la creazione di applicazioni decentralizzate, è anche essenziale che la blockchain sopravviva a lungo termine.

Le piattaforme blockchain orientate alle applicazioni esistono solo da pochi anni e l’intera area è piuttosto giovane. Poiché tali piattaforme hanno già riscontrato problemi con il degrado delle prestazioni nel tempo [10, 11], la loro sopravvivenza a lungo termine è discutibile. Anche i vecchi blockchain orientati al denaro basati su UTXO non hanno dimostrato di essere completamente resilienti nel lungo periodo in condizioni mutevoli perché fino a questo punto abbiamo solo circa 10 anni di storia della blockchain.

Le soluzioni per la sopravvivenza a lungo termine includono concetti come nodi leggeri con requisiti di archiviazione minimi [12], componente del canone di affitto dello spazio di archiviazione per prevenire il rigonfiamento dei nodi completi [3] e protocolli automodificabili che possono adattarsi all’ambiente mutevole e migliorare gli stessi senza parti fidate [13]. Ciò che serve è una combinazione di varie idee scientifiche insieme per risolvere questi problemi, fornendo allo stesso tempo un modo per ulteriori miglioramenti senza modifiche sostanziali e questo è esattamente ciò che Ergo cerca di ottenere.

Ergo Vision

Il protocollo Ergo è molto flessibile e può essere modificato in futuro dalla comunità. In questa sezione, definiamo i principi fondamentali che dovrebbero essere seguiti in Ergo che potrebbero essere indicati come “Contratto sociale di Ergo“. In caso di violazione intenzionale di uno qualsiasi di questi principi, il protocollo risultante non dovrebbe essere chiamato Ergo.

  • Prima la decentralizzazione. Ergo dovrebbe essere il più decentralizzato possibile: dovrebbero essere evitate tutte le parti (leader sociali, sviluppatori di software, produttori di hardware, minatori, fondi e così via) la cui assenza o comportamento dannoso può influire sulla sicurezza della rete. Se qualcuno di questi partiti compare durante la vita di Ergo, la comunità dovrebbe considerare i modi per ridurne il livello di impatto.
  • Creato per le persone normali. Ergo è una piattaforma per la gente comune e i loro interessi non dovrebbero essere violati a favore dei grandi gruppi. In particolare, ciò significa che la centralizzazione del mining dovrebbe essere impedita e le persone normali dovrebbero essere in grado di partecipare al protocollo eseguendo un nodo completo e blocchi di mining (anche se con una piccola probabilità).
  • Piattaforma per denaro contrattuale. Ergo è lo strato di base per le applicazioni che verranno costruite su di esso. È adatto a diverse applicazioni, ma il suo obiettivo principale è fornire un modo efficiente, sicuro e semplice per implementare i contratti finanziari.
  • Focus a lungo termine. Tutti gli aspetti dello sviluppo di Ergo dovrebbero essere focalizzati su una prospettiva a lungo termine. In qualsiasi momento, Ergo dovrebbe essere in grado di sopravvivere per secoli senza prevedere hard fork, miglioramenti software o hardware o altri cambiamenti imprevedibili. Poiché Ergo è progettato come piattaforma, anche le applicazioni basate su Ergo dovrebbero essere in grado di sopravvivere a lungo termine. Questa resilienza e sopravvivenza a lungo termine possono anche consentire a Ergo di essere una buona riserva di valore.
  • Senza autorizzazione e aperto. Il protocollo Ergo non limita nessuno né limita alcuna categoria di utilizzo. Dovrebbe consentire a chiunque di unirsi alla rete e partecipare al protocollo senza alcuna azione preliminare. A differenza del sistema finanziario tradizionale, non dovrebbero essere possibili salvataggi, liste nere o altre forme di discriminazione a livello centrale del protocollo Ergo. D’altra parte gli sviluppatori di applicazioni sono liberi di implementare qualsiasi logica vogliano, assumendosi la responsabilità dell’etica e della legalità della loro applicazione.

Protocollo di consenso Autolykos

Il componente principale di qualsiasi sistema blockchain è il suo protocollo di consenso ed Ergo utilizza un protocollo di consenso Proof of Work (PoW) unico auto-sviluppato chiamato Autolykos, descritto di seguito. Nonostante le ricerche approfondite sulle possibili 3 alternative, il protocollo PoW originale con la regola della catena più lunga è ancora richiesto grazie alla sua semplicità, alle garanzie di alta sicurezza e alla facilità con i clienti leggeri. Tuttavia, un decennio di test approfonditi ha rivelato diversi problemi con l’idea originale di una CPU e un voto. Il primo problema noto di un sistema PoW è lo sviluppo di hardware specializzato (ASIC), che consente a un piccolo gruppo di minatori dotati di ASIC di risolvere enigmi PoW di ordini di grandezza più velocemente ed efficientemente di chiunque altro. Questo problema può essere risolto con l’aiuto di schemi PoW con memoria rigida che riducono la disparità tra ASIC e hardware di base.

L’approccio più promettente qui è utilizzare schemi PoW asimmetrici con memoria rigida che richiedono una quantità di memoria significativamente inferiore per verificare una soluzione che per trovarla [14, 15]. La seconda minaccia nota a un decentramento della rete PoW è che anche i grandi miner tendono a unirsi in mining pool, portando a una situazione in cui solo pochi operatori di pool (5 in Bitcoin, 2 in Ethereum al momento della scrittura) controllano più del 51% di potenza computazionale. Sebbene il problema sia già stato discusso nella comunità, prima di Ergo non sono state implementate soluzioni pratiche.

Il protocollo PoW di Ergo, Autolykos [16], è il primo protocollo di consenso che è sia resistente alla memoria che al pool. Autolykos si basa sul problema k-sum di una lista: un minatore deve trovare k = 32 elementi da una lista predefinita R di dimensione N = 226 (che ha una dimensione di 2 Gb), tale che j∈J rj − sk = d è nell’intervallo {−b,…,0,…,b mod q}. Gli elementi della lista R sono ottenuti come risultato di un calcolo unidirezionale dall’indice i, due chiavi pubbliche miner pk,w e hash dell’intestazione del blocco m come ri = (i||M||pk||m||w) , dove H è una funzione hash che restituisce i valori in Z/qZ e M è un grande messaggio statico utilizzato per rallentare il calcolo dell’hash. Inoltre, un insieme di indici di elementi J deve essere ottenuto dalla funzione pseudo-casuale unidirezionale genIndexes, che impedisce possibili ottimizzazioni di ricerca di soluzioni. Pertanto, assumiamo che l’unica opzione per un minatore sia quella di utilizzare il semplice metodo di forza bruta fornito nell’algoritmo 1 per creare un blocco valido.

Nota che sebbene il processo di mining utilizzi chiavi private, la soluzione stessa contiene solo chiavi pubbliche. La verifica della soluzione viene eseguita dall’algoritmo 2.

Questo approccio impedisce la formazione di pool di mining perché la chiave segreta sk è necessaria per il mining: una volta che qualsiasi pool miner trova una soluzione corretta, può utilizzare questo segreto per rubare la ricompensa del blocco. D’altra parte, è sicuro rivelare un’unica soluzione, poiché contiene solo chiavi pubbliche e rivela un’unica relazione lineare tra i 2 segreti sk,w. La durezza della memoria deriva dal fatto che l’algoritmo 1 richiede di mantenere l’intera lista R per l’esecuzione del ciclo principale. Ogni elemento dell’elenco occupa 32 byte, quindi l’intero elenco di N elementi occupa N · 32 = 2Gb di memoria per N = 226.

Un minatore può provare a ridurre i requisiti di memoria calcolando questi elementi “al volo” senza tenerli in memoria, tuttavia, dovrà calcolare più volte lo stesso hash H (circa 104 volte per le moderne GPU), riducendo così efficienza e profitto. Anche il calcolo dell’elenco R è un compito computazionale piuttosto pesante: la nostra implementazione iniziale [17] consuma 25 secondi su Nvidia GTX 1070 per riempire tutti i 226 elementi dell’elenco. Questa parte, tuttavia, può essere ottimizzata se un miner memorizza anche un elenco di hash non finalizzati ui∈[0,N) = H(i||M||pk) in memoria, consumandone altri 5 Gigabyte. In tal caso, il lavoro per calcolare gli hash non finalizzati dovrebbe essere eseguito solo una volta durante l’inizializzazione del mining, mentre la finalizzazione degli stessi e il riempimento dell’elenco R per la nuova intestazione richiede solo pochi millisecondi (circa 50 ms su Nvidia GTX 1070).

Il parametro target b è integrato nel puzzle stesso e viene adattato all’hash rate della rete corrente tramite un algoritmo di regolazione della difficoltà [18] per mantenere l’intervallo di tempo tra i blocchi vicino a 2 minuti. Questo algoritmo tenta di prevedere l’hashrate di un’imminente epoca lunga 1024 blocchi in base ai dati delle 8 epoche precedenti tramite il noto metodo dei minimi quadrati lineari. Ciò rende le previsioni migliori di quelle del solito algoritmo di regolazione della difficoltà e rende anche meno redditizi gli attacchi “coin-hopping”.

Ergo State

Per controllare una nuova transazione, un client di criptovaluta non utilizza il libro mastro con tutte le transazioni avvenute prima di questa. Al contrario, utilizza un’istantanea dello stato del libro mastro dalla sua cronologia. Nell’implementazione di riferimento di Bitcoin Core, questa istantanea è costituita dalle monete una tantum attive (ad esempio, UTXO) e una transazione distrugge alcune monete e ne crea anche di nuove. In Ethereum, questa istantanea è di account di lunga durata e una transazione modifica il saldo monetario e la memoria interna 5 di alcuni account. Inoltre, in Ethereum (a differenza di Bitcoin), la rappresentazione dello snapshot è fissata all’interno del protocollo perché un digest di autenticazione dello snapshot è scritto nell’intestazione del blocco. Ergo segue il design UTXO di Bitcoin e rappresenta le istantanee utilizzando monete una tantum.

La differenza rispetto a Bitcoin è che oltre al valore monetario e allo script di protezione, una moneta Ergo monouso, chiamata box, contiene anche dati definiti dall’utente. Simile a Ethereum, un blocco Ergo memorizza anche un digest di autenticazione, chiamato stateRoot, dello stato globale dopo l’applicazione del blocco. Una scatola Ergo è fatta di registri (e nient’altro che registri). Tale casella può avere 10 registri etichettati R0,R1,…,R9, di cui i primi quattro sono riempiti con valori obbligatori e il resto può contenere dati arbitrari o essere vuoto.

  • R0 (valore monetario). Quantità di Erg bloccata in questa casella.
  • R1 (script di guardia). Script serializzato che protegge questa casella.
  • R2 (gettoni). Una scatola può contenere più gettoni. Questo registro contiene un array di (identificatore token → importo) coppie bloccate in questa casella.
  • R3 (informazioni sulla transazione). Contiene (1) l’altezza di creazione dichiarata (non dovrebbe essere maggiore dell’altezza effettiva di un blocco che contiene la transazione), (2) un identificatore univoco della transazione che ha creato questa casella e (3) l’indice di questa casella nella transazione caselle di uscita.
  • R4−R9 (dati aggiuntivi). Contiene dati arbitrari definiti dall’utente. Gli oggetti immutabili una tantum (come nel modello UTXO di Bitcoin) presentano alcuni vantaggi rispetto agli account mutevoli di lunga durata di Ethereum. In primo luogo, offre una protezione più semplice e sicura dalla riproduzione o dal riordino degli attacchi. In secondo luogo, è più facile elaborare le transazioni in parallelo perché non modificano lo stato degli oggetti a cui accedono. Inoltre, una transazione modifica lo stato del sistema esattamente come previsto o non lo cambia affatto (senza possibili effetti collaterali derivanti da eccezioni “out-of-gas”, problemi di rientro e così via). Infine, sembra più facile creare clienti completamente apolidi utilizzando monete una tantum [19] (sebbene la ricerca in questo settore sia ancora nella fase iniziale).

Una delle principali critiche alle monete una tantum è che questo modello non sembra adatto per applicazioni decentralizzate non banali. Tuttavia, Ergo ha superato i problemi e ha dimostrato che questa affermazione è falsa dimostrando molte applicazioni prototipo non banali costruite su di essa (vedi Sezione 7). Il protocollo Ergo corregge la rappresentazione dell’istantanea del libro mastro sotto forma di scatole non distrutte da transazioni precedenti.

In dettaglio, un minatore dovrebbe mantenere una struttura di dati autenticata simile a un albero Merkle costruita sopra il set UTXO e deve includere un breve digest (solo 33 byte) di questa struttura in ogni intestazione di blocco. Questo digest deve essere calcolato dopo aver applicato il blocco. Questa struttura di dati autenticata è costruita su un albero AVL+ [12], che come un normale albero di hash, permette di generare prove dell’esistenza o meno di particolari elementi nell’albero. Pertanto, gli utenti che mantengono l’intero albero sono in grado di generare prove che le loro scatole non sono state spese e un piccolo digest di 33 byte è sufficiente per verificare 6 di queste prove.

Tuttavia, a differenza degli alberi hash regolari, un albero AVL+ consente anche la generazione di prove di modifica dell’albero che consentono ai verificatori di calcolare il nuovo tree digest. I minatori Ergo sono tenuti a generare prove delle modifiche ai blocchi e un hash di questa prova è incluso nell’intestazione del blocco insieme al digest dello stato risultante.

Quindi, i nodi leggeri che mantengono solo un piccolo digest dello stato corrente sono in grado di verificare un blocco completo: possono controllare che tutte le caselle esaurite siano state rimosse dallo stato, tutte le caselle create sono state aggiunte e non sono state apportate più modifiche. Gli alberi AVL+ consentono di creare dizionari autenticati efficienti che riducono la dimensione della prova e accelerano la verifica di 1,4-2,5 volte rispetto alle soluzioni precedenti, rendendoli più adatti alle applicazioni di criptovaluta. Ad esempio, le nostre prove sono circa 3 volte più piccole delle prove di un trie Merkle Patricia utilizzato in Ethereum per lo stesso scopo (vedi Figura 1).

Figura1: Confronto della dimensione della prova con un Merkle patricia trie Infine, le prove per più transazioni in un unico blocco vengono compresse insieme, riducendo la loro lunghezza totale di circa un fattore aggiuntivo di 2: 7

Figura 2: A sinistra: dimensione della prova per modifica per 2000 transazioni come una funzione della dimensione dell’albero iniziale n. A destra: dimensione della prova per modifica per un albero con n = 1000000 chiavi in ​​funzione della dimensione del lotto B. In entrambi i casi, la metà di m le modificazioni erano inserimenti di nuove coppie (chiave, valore) e l’altra metà erano modifiche di valori per chiavi esistenti. Pertanto, lo stato Ergo fornisce un modo efficiente e sicuro per dimostrare l’esistenza o la non esistenza di determinati elementi in esso, nonché prove delle modifiche dell’albero. Queste operazioni ad albero sono supportate dal linguaggio smart contract Ergo, fornendo così la possibilità di implementare contratti sofisticati come quelli discussi nella Sezione 7.

Resilienza e sopravvivenza

Essendo una piattaforma per denaro contrattuale, Ergo dovrebbe anche supportare a lungo termine contratti per un periodo pari almeno alla vita di una persona media. Tuttavia, anche le giovani piattaforme di smart contract esistenti stanno riscontrando problemi con le prestazioni riguardo il degrado e l’adattabilità alle condizioni esterne. Questo porta ad una situazione in cui la criptovaluta dipende da un piccolo gruppo di sviluppatori fornire un hard-fork di riparazione, o la criptovaluta non sopravviverà. Per esempio, la rete Ethereum è stata avviata con un algoritmo di consenso Proof-of-Work con un piano per passare alla Proof-of-Stake nel prossimo futuro.

Tuttavia, ritardi lo sviluppo della Proof-of-Stake ha portato a diversi hard-fork di fissaggio [20] e la comunità è ancora costretta a fare affidamento su sviluppatori principali che promettono di implementare il prossimo hard-fork. Il primo problema comune di sopravvivenza è che alla ricerca della popolarità, gli sviluppatori tendono ad implementare soluzioni ad hoc senza un’adeguata ricerca preliminare e test. Tali soluzioni portano inevitabilmente a bug, che poi portano a bug frettolosi correzioni, quindi correzioni di tali correzioni di bug e così via, rendendo la rete inaffidabile e ancora meno sicuro. Un esempio notevole è la criptovaluta IOTA, che è stata implementata varie soluzioni di ridimensionamento, inclusa la propria funzione hash e DAG struttura, che gli ha permesso di raggiungere un’elevata popolarità e capitalizzazione di mercato. 

Tuttavia, un’analisi dettagliata di queste soluzioni ha rivelato molteplici gravi problemi, compresi gli attacchi pratici che hanno consentito il furto di token [21, 22]. Un successivo hard-fork [23] ha quindi risolto questi problemi passando al noto SHA3 funzione hash, confermando così l’inutilità di questo tipo di innovazioni. L’approccio di Ergo qui è quello di utilizzare soluzioni stabili e ben testate, anche se portano a innovazioni più lente a breve termine. La maggior parte delle soluzioni utilizzate in Ergo sono formalizzate in documenti presentati a conferenze peer-reviewed [12, 18, 3, 8, 24, 25] e sono state ampiamente discusse nella comunità. Un secondo problema che deve affrontare il decentramento (e quindi la sopravvivenza) è la mancanza di client leggeri affidabili e sicuri. Ergo cerca di risolvere questo problema di blockchain tecnologia senza crearne di nuove.

Poiché Ergo è una blockchain PoW, esso consente facilmente l’estrazione di una piccola intestazione dal contenuto del blocco. Questa intestazione da sola consente la convalida del lavoro svolto nel blocco e una catena di sole intestazioni è sufficiente per la migliore selezione della catena e la sincronizzazione con la rete. Una catena di sole intestazioni, sebbene molto più piccola della blockchain completa, continua a crescere linearmente con il tempo.

Una recente ricerca sui light client fornisce una via per light client per sincronizzarsi con la rete, scaricando una quantità ancora più piccola di dati, sbloccando così la possibilità di accedere alla rete utilizzando la fascia bassa non affidabile hardware come i telefoni cellulari [26, 27]. Ergo utilizza uno stato autenticato e per le transazioni incluse in un blocco, un cliente può scaricare una prova della loro correttezza. Pertanto, indipendentemente dalle dimensioni della blockchain, un utente normale con un cellulare può entrare in rete e iniziare a usare Ergo con la stessa sicurezza garanzie come nodo completo.

I lettori potrebbero notare un terzo potenziale problema in quanto nonostante il supporto per i light client risolve il problema per gli utenti Ergo, non risolve il problema per i minatori Ergo, che hanno ancora bisogno di mantenere l’intero stato per transazioni efficienti e la convalida. Nei sistemi blockchain esistenti, gli utenti possono inserire dati arbitrari. Questi dati, che durano per sempre, creano molta polvere e le sue dimensioni aumentano infinitamente nel tempo [28]. Una grande dimensione dello stato porta a seri problemi di sicurezza perché quando lo stato non si adatta alla memoria ad accesso casuale, un avversario può generare transazioni la cui convalida diventa molto lenta a causa dell’accesso casuale richiesto al deposito del minatore. Questo può portare ad attacchi DoS come quello su Ethereum nel 2016 [29].

Inoltre, la paura della comunità di tali attacchi insieme al problema di “state bloat” senza alcun tipo di compenso a minatori o utenti per il mantenimento dello stato potrebbe aver impedito il ridimensionamento di soluzioni che altrimenti avrebbero potuto essere implementate (come blocchi di dimensioni maggiori, ad esempio). Impedire questo, Ergo ha una componente di affitto di memoria: se un’uscita rimane nello stato per 4 anni senza essere consumato, un miner può addebitare una piccola commissione per ogni byte mantenuto nel sistema.

Questa idea, che è simile ai normali servizi di cloud storage, è stata solo proposta abbastanza recentemente per le criptovalute [30] e ha diverse importanti conseguenze. In primo luogo, garantisce che l’Ergo mining sia sempre stabile, a differenza di Bitcoin e altre valute PoW, in cui il mining potrebbe diventare instabile dopo che l’emissione è avvenuta per intero [31].

In secondo luogo, la crescita delle dimensioni dello stato diventa controllabile e prevedibile, aiutando così i minatori Ergo a gestire i loro requisiti hardware. In terzo luogo, riscuotendo i costi di stoccaggio da scatole obsolete, i minatori possono rimettere in circolazione le monete, impedendo così la costante diminuzione della circolazione della fornitura per smarrimento chiavi [32]. Tutti questi effetti dovrebbero supportare per il lungotermine Ergo, la sua sopravvivenza, sia tecnica che economica. Una quarta sfida vitale alla sopravvivenza è quella dei cambiamenti nell’ambiente esterno e le richieste del protocollo. Un protocollo dovrebbe adattarsi all’infrastruttura hardware in continua evoluzione, nuove idee per migliorare la sicurezza o la scalabilità che emerge nel tempo, l’evoluzione dei casi d’uso e così via.

Se tutte le regole sono fissate senza alcuna possibilità di modificarle in modo decentralizzato, anche un semplice cambiamento costante può portare ad accesi dibattiti e divisioni comunitarie. Ad esempio, la discussione sul limite della dimensione del blocco in Bitcoin ha portato alla sua suddivisione in diverse monete indipendenti.

Al contrario, il protocollo Ergo è automodificabile ed è in grado di adattarsi all’ambiente che cambia. In Ergo, i parametri come la dimensione del blocco possono essere modificati al volo tramite il voto dei minatori. All’inizio di ogni 1024-blocco epoca di votazione, un miner propone modifiche fino a 2 parametri (ad es un aumento della dimensione del blocco e una diminuzione del fattore di tariffa di stoccaggio). Durante il resto dell’epoca, i minatori votano per approvare o rifiutare le modifiche. Se la maggioranza di voti entro l’epoca supportano il cambiamento, i nuovi valori sono scritti nella sezione di estensione del primo blocco dell’epoca successiva e la rete si avvia utilizzando i valori aggiornati per il block mining e la convalida.

Per assorbire i cambiamenti più fondamentali, Ergo segue l’approccio della softforkability che consente di modificare in modo significativo il protocollo mantenendo i vecchi nodi operativi. All’inizio di un’epoca, anche un minatore può proporre di votare per una modifica fondamentale (ad esempio, l’aggiunta di una nuova istruzione a ErgoScript) descrivere le regole di convalida interessate.

Le votazioni per tali cambiamenti radicali continuano  per 32.768 blocchi e richiede l’accettazione di almeno il 90% dei voti “Sì”. Una volta accettato, un periodo di attivazione lungo 32.768 blocchi inizia a dare risultati obsoleti ai nodi e sarà il momento di aggiornare la versione del software. Se un software del nodo non è ancora aggiornato trascorso il periodo di attivazione, salta i controlli specificati ma continua per convalidare tutte le regole conosciute. Viene registrato l’elenco delle precedenti modifiche soft-fork sull’estensione per consentire ai nodi leggeri di qualsiasi versione software di unirsi alla rete e aggiorna le attuali regole di convalida. Una combinazione di soft-forkability con il protocollo di votazione permette di modificare quasi tutti i parametri della rete ad eccezione delle regole PoW che sono responsabili del voto stesso.

Gettone nativo di Ergo

La piattaforma Ergo ha il suo token nativo, che si chiama Erg ed è divisibile fino a 109 unità più piccole, nanoErg (un nanoErg è un miliardesimo di Erg). Gli erg sono importanti per la stabilità e la sicurezza della piattaforma Ergo per diversi motivi discussi qui di seguito. Durante la fase iniziale della vita di Ergo, i minatori riceveranno la ricompensa in Erg secondo un programma di emissione di token predefinito e codificato (vedi 6.1per ulteriori dettagli).

Queste monete incentiveranno i minatori a partecipare alla rete di Ergo, proteggendola da attacchi basati su hashrate come il noto attacco del 51% [33]. L’emissione di erg sarà terminata in soli otto anni, e successivamente i minatori riceveranno solo Ergs dalle commissioni. Sebbene, regolabile nel tempo tramite il voto dei minatori on-chain, la dimensione del blocco Ergo e il costo massimo di calcolo del blocco, in un determinato momento sarà limitato e quindi i minatori sono obbligati a scegliere solo un sottoinsieme di transazioni da mempool durante i periodi di carico elevato. Le commissioni aiuteranno i minatori ad ordinare le transazioni, prevenendo gli attacchi di spam consentendo al tempo stesso di includere le transazioni di utenti onesti in blocchi. Oltre alle risorse di rete e di calcolo, una transazione utilizza l’archiviazione aumentando le dimensioni dello stato.

Nelle criptovalute esistenti, un elemento dello stato, come può essere un UTXO nelle blockchain basate su UTXO, chiamato box in Ergo, una volta creato vive forse per sempre senza alcun compenso per i minatori e alcuni utenti che devono mantenere questo stato in una memoria ad accesso casuale ad alto costo. Questo porta a un disallineamento di incentivi e di dimensioni statali in continuo aumento. Al contrario, Ergo ha un componente di affitto dello spazio di archiviazione che addebita periodicamente agli utenti Erg per ogni byte compreso nello stato.

Questo affitto di spazio di archiviazione sta rendendo il sistema più stabile limitando le dimensioni dello stato e assicurando un’adeguata compensazione per le dimensioni dello stato più grandi, il ritorno delle monete perse in circolazione e fornisce un ulteriore stabile e prevedibile ricompensa ai minatori. Pertanto, essendo una piattaforma per denaro contrattuale, Ergo è adatta a costruire applicazioni e sistemi monetari su di essa. Tuttavia, partecipare a tali sistemi richiede l’utilizzo del token nativo Ergo, Erg, anche per pagare l’affitto dello spazio di archiviazione e le commissioni di transazione che forniranno ai minatori una forte continuità di incentivi per proteggere la rete con un’adeguata potenza hash. Utenti, per loro parte, saranno altamente incentivati ​​ad acquistare, utilizzare e risparmiare Ergs se trovano applicazioni per Ergo di alto valore.

Emissione

Tutti i token Erg che circoleranno mai nel sistema sono presentati nell’iniziale stato, che si compone di 3 caselle:

  • Nessuna prova preliminare. Questa scatola contiene esattamente un Erg ed è protetta da uno script che impedisce che venga speso da chiunque. Quindi, è un longevo box che rimarrà nel sistema fino alla componente di affitto di deposito lo distrugge. Il suo scopo principale è dimostrare che l’estrazione di Ergo non è stata avviata privatamente da chiunque prima della data di lancio dichiarata. Per realizzare questo, registri aggiuntivi di questa casella contengono gli ultimi titoli dei media (The Guardian, Vedomosti, Xinhua), così come gli ultimi identificatori di blocco da Bitcoin ed Ethereum. Pertanto, l’estrazione di Ergo non avrebbe potuto iniziare prima di determinati eventi nel mondo reale e nello spazio delle criptovalute.
  • Tesoro. Questa scatola contiene 4.330.791,5 Erg che verranno utilizzati per finanziare Sviluppo dell’ergo. Il suo copione protettivo [34] si compone di due parti. Innanzitutto, garantisce che solo una parte predefinita del valore della casella sia sbloccata. Durante i blocchi 1-525.599 (2 anni) verranno rilasciati 7,5 Ergs per ogni blocco.Quindi durante i blocchi 525.600-590.399 (3 mesi) verranno rilasciati 4,5 Ergs ogni blocco. Infine, durante i blocchi 590.400-655.199 (3 mesi) 1,5 Ergs verrà rilasciato ogni blocco. Questa regola garantisce la presenza di fondi per Sviluppo ergonomico per 2,5 anni e, in qualsiasi momento, i premi non supereranno il 10% del numero totale di monete in circolazione. In secondo luogo, ha una protezione personalizzata da spese impreviste. Inizialmente, richiede che l’operazione di spesa sia firmata da almeno 2 su 3 chiavi che sono sotto il controllo dei membri del team iniziale. Quando spendono la casella, sono liberi di modificare questa parte dello script come desiderano, per esempio aggiungendo nuovi membri per proteggere i fondi della fondazione. Durante il primo anno, questi fondi saranno utilizzati per coprire il pre-emesso token EFYT. Successivamente, saranno distribuiti in modo decentralizzato attraverso un sistema di voto comunitario che è in fase di sviluppo.
  • Ricompensa per i minatori. Questa scatola contiene 93.409.132 Erg che verranno raccolti dai block miner come ricompensa per il loro lavoro. Il suo copione protettivo [35] richiede che la transazione di spesa abbia esattamente due output con le seguenti proprietà:

  1. Il primo output dovrebbe essere protetto dallo stesso script e dal file il numero di Erg in esso contenuto dovrebbe essere uguale alla ricompensa dei minatori rimanenti. Durante i blocchi 1 – 655.199, un minatore sarà in grado di raccogliere 67,5 Erg da questa scatola. Durante i blocchi 655.200 – 719.999 (3 mesi), un minatore sarà in grado di raccogliere 66 Ergs e, successivamente, la ricompensa del blocco lo farà essere ridotto di 3 Ergs ogni 64.800 blocchi (3 mesi) fino a raggiungere zero al blocco 2.080.800.
  2. Il secondo output dovrebbe contenere le monete rimanenti e dovrebbe esserlo protetto dalla seguente condizione: può essere speso da un minatore che risolto il puzzle PoW del blocco e non prima di 720 blocchi dopo il blocco attuale.

Tutte queste regole risultano nella seguente curva che denota il numero di monete in circolazione nel tempo:

 Denaro contrattuale

A nostro avviso, la stragrande maggioranza dei casi d’uso per le blockchain pubbliche (anche quelle che affermano di fornire un computer mondiale decentralizzato per uso generale) sono per applicazioni finanziarie, che non richiedono la completezza di Turing. Ad esempio, se un oracolo scrive dati non finanziari nella blockchain (come la temperatura), questi dati vengono solitamente utilizzati ulteriormente in un contratto finanziario. L’altra osservazione banale che facciamo è che molte applicazioni utilizzano token digitali con meccaniche diverse dal token nativo.

Per uno sviluppatore di applicazioni, la piattaforma Ergo offre token personalizzati (che sono cittadini di prima classe) e un linguaggio specifico del dominio per la protezione della casella di scrittura condizioni per implementare applicazioni finanziarie flessibili e sicure. Quindi le applicazioni sono definite in termini di protezione degli script integrati nelle caselle, che può contenere anche dati coinvolti nell’esecuzione. Usiamo il termine contrattuale money per definire Ergs (e token secondari) il cui utilizzo è limitato da a contrarre. Questo vale per tutti i token esistenti sulla piattaforma perché nessuno box con il suo contenuto (Ergs, token, dati) è vincolato da un contratto.

Tuttavia, possiamo distinguere tra due tipologie di Ergs contrattuali. Il i primi, chiamati Ergs gratuiti, sono quelli che potrebbero cambiare facilmente i loro contratti e non hanno restrizioni sugli output o sugli altri input di un’operazione di spesa. Il secondo tipo è l’Erg limitato, i cui contratti prevedono la spesa della transazione per avere caselle di input e output con proprietà specifiche.

Ad esempio, se una casella A è protetta solo da una chiave pubblica (fornendo quindi una firma contro un’operazione di spesa è sufficiente per distruggere la scatola), il proprietario della chiave pubblica può spendere A e trasferire gli Ergs a qualsiasi casella di output arbitraria. Pertanto, gli Erg all’interno di A sono liberi. Immaginiamo invece una scatola B protetta da a combinazione di una chiave pubblica e di una condizione che richiede l’operazione di spesa per creare una casella di output con la stessa quantità di Ergs di B e di cui lo script di guardia ha l’hash rBMUEMuPQUx3GzgFZSsHmLMBouLabNZ4HcERm4N (in codifica Base58). In questo caso, gli Ergs in B sono Ergs limitati. Allo stesso modo, possiamo definire token liberi e limitati. Un contratto Ergo può avere diversi ibridi come Erg limitati e token gratuiti o entrambi limitati una chiave pubblica e libera sotto un’altra.

Preliminari per i contratti Ergo

Mentre in Bitcoin, l’output di una transazione è protetto da un programma in uno stack linguaggio chiamato Script, in Ergo un box è protetto da una formula logica che combina predicati su un contesto con affermazioni crittografiche dimostrabili tramite protocolli a conoscenza zero che utilizzano connettivi AND, OR e k-out-of-n. La formula è rappresentata come un grafico aciclico diretto digitato, la cui forma serializzata è scritto in una scatola. Per distruggere una scatola, una transazione di spesa deve fornire argomenti (che includono dimostrazioni a conoscenza zero) che soddisfano la formula. Tuttavia, nella maggior parte dei casi, è improbabile che uno sviluppatore sviluppi contratti in termini di grafici. Vorrebbe invece utilizzare un linguaggio di alto livello come ErgoScript, che forniamo con il cliente di riferimento.

Scrivere script in ErgoScript è facile. Ad esempio, per un uno su due signature, lo script di protezione sarebbe pk1∥pk2, che significa “dimostrare la conoscenza di una chiave segreta corrispondente alla chiave pubblica pk1 o conoscenza di un segreto chiave corrispondente alla chiave pubblica pk2”. Abbiamo due documenti separati per l’aiuto nello sviluppo di contratti con ErgoScript: l’“ErgoScript Tutorial” [36] e l’“Advanced ErgoScript Tutorial” [37]. Pertanto, non entriamo nei dettagli dello sviluppo contratti con ErgoScript. Piuttosto, forniamo un paio di motivanti esempi nelle sezioni seguenti. Altre due caratteristiche delle possibilità di appalto per modellare Ergo sono:

  • Input di dati: per essere utilizzato in una transazione, non è necessario distruggere una scatola ma può invece essere di sola lettura. In quest’ultimo caso, ci riferiamo alla scatola come facente parte dell’input dei dati della transazione. Quindi, una transazione ottiene due insiemi di scatole come argomenti, input e input di dati e produce un box set denominato uscite. Gli input di dati sono utili per le applicazioni Oracle e contratti interagenti.
  • Token personalizzati: una transazione può trasportare molti token fino a quanto stimato la complessità per elaborarli non supera un limite, un parametro che è impostato dal voto dei minatori. Una transazione può anche emettere un singolo token con un identificatore univoco che è uguale all’identificatore di un primo (spendibile) casella di inserimento della transazione. L’identificatore è univoco presupponendo la collisione resistenza di una funzione hash sottostante. L’importo dei token emesso potrebbe essere qualsiasi numero compreso nell’intervallo [1, 9223372036854775807]. Per i token viene seguita la regola di conservazione debole, che richiede che l’importo totale di qualsiasi token negli output di una transazione non dovrebbe essere più rispetto all’importo totale di quel token negli input della transazione (cioè, alcune quantità di token potrebbero essere bruciate). Al contrario, la regola della prenotazione forte è seguito per Ergs, che richiede che l’importo totale di Ergs negli ingressi e nelle uscite devono essere gli stessi.

Esempi di contratto

In questa sezione, forniamo alcuni esempi che dimostrano la superiorità di Contratti Ergo rispetto a Bitcoin. Gli esempi includono scommesse su Oracle, mix non interattivo, atomic swap, valuta complementare, e un’offerta iniziale di monete implementata sulla blockchain di Ergo.

Un esempio di Oracle

Dotato di token personalizzati e input di dati, possiamo sviluppare un semplice oracolo esempio che mostra anche alcuni modelli di design che abbiamo scoperto durante il gioco con contratti Ergo. Supponiamo che Alice e Bob vogliano scommettere sul tempo di domani mettendo i soldi in una scatola che diventa spendibile da Alice se domani la temperatura è superiore a 15 gradi, altrimenti spendibile da Bob. Per fornire la temperatura nella blockchain, è necessario un oracolo fidato. In contrasto con Ethereum con i suoi account longevi, dove quello di un oracolo fidato l’identificatore è generalmente noto in anticipo, mentre la consegna dei dati con caselle monouso è più complicato. Per cominciare, non ci si può fidare di una scatola protetta dalla chiave dell’oracolo, come chiunque può creare una scatola del genere.

È possibile includere i dati firmati in una casella e controlla la firma dell’oracolo nel contratto (abbiamo un esempio del genere), ma questo è abbastanza coinvolto. Invece, una soluzione con token personalizzati è molto semplice. In primo luogo, dovrebbe essere emesso un token che identifica l’oracolo. Nel caso più semplice, l’importo di questo token potrebbe essere uno. Chiamiamo tale token un token singleton. L’oracolo crea una scatola contenente questo token insieme ai suoi dati (cioè, la temperatura) nel registro R4 e l’epoca UNIX nel registro R5. In ordine per aggiornare la temperatura, l’oracolo distrugge questa scatola e ne crea una nuova con la temperatura aggiornata.

Supponiamo che Alice e Bob conoscano in anticipo l’identificatore del token dell’oracolo. Con questa conoscenza, possono creare insieme una scatola con un contratto che richiede primo input di dati (di sola lettura) per contenere il token dell’oracolo. Il contratto estrae la temperatura e il tempo dall’input dei dati e decide chi riceve il pagamento. Il codice è semplice come segue:

Questo contratto mostra come utilizzare un token singleton per l’autenticazione. Come possibile alternativa, l’oracolo può inserire il tempo e la temperatura una casella insieme a una firma su questi dati. Tuttavia, questo richiede la firma verifica, che è più complessa e costosa rispetto al singleton approccio simbolico. Inoltre, il contratto mostra come potrebbero essere gli input di dati di sola lettura utile per i contratti che necessitano di accedere ai dati archiviati in qualche altra casella del sistema. Senza input di dati, un oracolo deve emettere una scatola spendibile per ciascuno coppia di Alice e Bob. Con gli input di dati, l’oracolo emette solo una singola casella.

Un esempio di miscelazione

La privacy è importante per una valuta digitale, ma implementarla può essere costosa o richiede una configurazione affidabile. Pertanto, è desiderabile trovare un modo più economico per la miscelazione della moneta. Come primo passo verso questo, offriamo un protocollo di miscelazione non interattivo tra due utenti Alice e Bob che funziona come segue:

  1. Alice crea una scatola che richiede la transazione di spesa da soddisfare certe condizioni. Dopodiché, Alice ascolta solo la blockchain; no è necessaria l’interazione con Bob.
  2. Bob crea una transazione spendendo la scatola di Alice insieme a una sua per generare due output con script identici ma dati diversi.

Alice e Bob possono spendere solo una delle due uscite ma l’explorer decide quale output appartiene a chi e perché sembrano indistinguibili. Per semplicità, nell’esempio non consideriamo la tariffa. L’idea di mescolare è simile allo scambio di chiavi Diffie-Hellman non interattivo. Innanzitutto, Alice genera un valore segreto x (un numero enorme) e pubblica il valore pubblico corrispondente gX = gx. Richiede a Bob di generare un numero segreto y e di includerlo in ciascuna uscita due valori c1, c2, dove un valore è uguale a gy e the altro è uguale a gxy.

Bob usa una moneta casuale per scegliere i significati di {c1, c2}. Senza l’accesso ai segreti, un osservatore esterno non può indovinare con probabilità meglio di 1 2 se c1 è uguale a gy o a gxy. Questo presuppone che il la primitiva crittografica che utilizziamo ha una certa proprietà, che la Decision Diffie- Il problema di Hellman (DDH) è difficile. Per distruggere una casella di output, una prova dovrebbe sia dato che o y è noto in modo tale che c2 = gy, oppure x è noto in modo tale che c2 = cx1 . Il contratto della scatola di Alice verifica che c1 e c2 siano ben formati.

Il vengono forniti frammenti di codice per la moneta di Alice e l’output della transazione di mixaggio rispettivamente negli algoritmi 4 e 5. Dal momento che ErgoScript attualmente non ha supporto per dimostrare la conoscenza di alcune x tali che c2 = c1 x per c1 arbitrario, dimostreremo un’affermazione leggermente più lunga che è supportata, vale a dire la dimostrazione conoscenza di x tale che gX = gx e c2 = c1 X. Questo è chiamato prove DHTuple.

Altri esempi

Rimandiamo il lettore a [37] per una prova dell’indistinguibilità degli output e dettagli sul motivo per cui Alice e Bob possono spendere solo le rispettive monete.

In questa sezione, faremo brevemente luce su alcuni altri esempi insieme ai collegamenti a i documenti che forniscono i dettagli e il codice. Atomic Swap Scambio atomico a catena incrociata tra Ergo e qualsiasi blockchain  che supporta il pagamento a preimage hash SHA-256 o Blake2b-256 e i blocchi temporali possono essere eseguiti in modo simile a quello proposto per Bitcoin [38]. Un Ergo implementazione alternativa è fornita in [36]. Come Ergo ha anche personalizzato token, scambio atomico sulla singola blockchain Ergo (Erg-to-token o token-to- token) è anche possibile.

Un’implementazione per questo può essere trovata anche in [36]. Crowdfunding Consideriamo lo scenario di crowdfunding più semplice. In questo esempio, un progetto di crowdfunding con una chiave pubblica nota è considerato di successo se può incassare le uscite non spese con un valore complessivo non inferiore a un determinato importo prima di una certa altezza.

Un sostenitore del progetto crea una casella di output protetta da seguente rendiconto: la casella può essere spesa se l’operazione di spesa ha la prima casella di output protetta dalla chiave del progetto e di importo non inferiore al target Quantità. Quindi il progetto può raccogliere (in un’unica transazione) il più grande caselle di output del sostenitore con un valore totale non inferiore all’importo target (it è possibile raccogliere fino a 22.000 uscite, sufficienti anche per un big campagna di crowdfunding).

Per le restanti uscite è possibile costruire operazioni di follow-up. Il codice può essere trovato in [36]. Il sistema di scambio di borsa locale Qui dimostriamo brevemente un locale Exchange Trading System (LETS) in Ergo. In un tale sistema, un membro di a la comunità può emettere valuta comunitaria tramite debito personale. Ad esempio, se Alice con saldo zero sta comprando qualcosa per 5 gettoni della comunità da Bob, il cui saldo è pari a zero, il suo saldo dopo lo scambio sarebbe di -5 gettoni, e il saldo di Bob sarebbe di 5 gettoni. Quindi Bob può comprare qualcosa usando il suo 5 gettoni, ad esempio, da Carol. Di solito, in tali sistemi, c’è un limite

saldi negativi (per evitare il free-riding). Dal momento che una comunità digitale è vulnerabile agli attacchi Sybil [39], alcuni meccanismi è necessario per prevenire tali attacchi in cui i nodi Sybil creano debiti. La soluzione più semplice è utilizzare un comitato di manager fidati che ne approvino il nuovo membri della comunità.

È da utilizzare una soluzione senza fiducia ma più complessa depositi cauzionali effettuati in Ergs. Per semplicità, consideriamo l’approccio con il comitato qui Questo esempio contiene due contratti interagenti. Un contratto di gestione mantiene un elenco di membri della comunità e un nuovo membro può essere aggiunto se alcune condizioni di gestione sono soddisfatte (ad esempio, una firma di soglia è fornito). Un nuovo membro è associato a una casella contenente un token che identifica il membro.

Questa casella, che contiene il contratto del membro, è protetta da uno speciale script di scambio che richiede che  la transazione di spesa sia corretta per lo scambio. Saltiamo il codice corrispondente, che può essere trovato in un separato articolo [40]. Ciò che mostra questo contratto, contrariamente all’esempio precedente, è invece quello di memorizzare l’elenco dei membri, solo un breve riassunto di un albero AVL+ autenticato può essere incluso nella confezione. Ciò consente una riduzione dei requisiti di archiviazione per lo stato. Una transazione che esegue la ricerca o la modifica dell’elenco dei membri dovrebbe fornire una prova per le operazioni di ricerca o modifica dell’albero AVL+. Così, il risparmio di spazio nella memoria di stato porta a transazioni più grandi, ma questa scalabilità non è un problema facile da risolvere.

Offerta iniziale di monete

Discutiamo un esempio di offerta iniziale di monete (ICO). che mostra come si possono creare contratti a più stadi in Ergo. Come la maggior parte degli ICO, il nostro esempio ha tre fasi. Nella prima fase, il progetto raccoglie fondi Erg. Nella seconda fase, il progetto emette un nuovo token, il cui importo è uguale il numero di nanoErg aumentati nella prima fase. Nella terza fase, gli investitori può ritirare i gettoni emessi. Nota che la prima e la terza fase hanno molte transazioni sulla blockchain, mentre per la seconda fase è sufficiente una singola transazione. Simile al precedente ad esempio, il contratto ICO utilizza un albero AVL+ per memorizzare l’elenco di (investitore, importo) coppie. Il codice completo è disponibile su [41]. Altri esempi Abbiamo ancora più esempi di applicazioni Ergo in [36, 37]. Questi esempi includono emissioni a tempo controllato, contratti cold wallet, rockpaper- gioco delle forbici e molti altri.

Note

[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[2] Bitcoin’s price surpasses $18,000 level, market cap now higher
than visa’s. [Online]. Available: https://cointelegraph.com/news/
bitcoins-price-surpasses-18000-level-market-cap-now-higher-than-visas
[3] A. Chepurnoy, V. Kharin, and D. Meshkov, “A systematic approach to
cryptocurrency fees,” IACR Cryptology ePrint Archive, vol. 2018, p. 78,
2018.
[4] Skyrocketing fees are fundamentally changing bitcoin. [Online]. Available:
https://arstechnica.com/tech-policy/2017/12/bitcoin-fees-rising-high/
[5] N. Szabo, “Smart contracts,” Unpublished manuscript, 1994.
[6] J. Zahnentferner, “Chimeric ledgers: Translating and unifying utxo-based
and account-based cryptocurrencies.” IACR Cryptology ePrint Archive,
vol. 2018, p. 262, 2018.
[7] I accidentally killed it: Parity wallet bug locks $150
million in ether. [Online]. Available: https://www.ccn.com/
i-accidentally-killed-it-parity-wallet-bug-locks-150-million-in-ether
[8] A. Chepurnoy, V. Kharin, and D. Meshkov, “Self-reproducing coins as universal turing machine,” in Data Privacy Management, Cryptocurrencies
and Blockchain Technology. Springer, 2018, pp. 57–64.
[9] M. Jansen, F. Hdhili, R. Gouiaa, and Z. Qasem, “Do smart
contract languages need to be turing complete?” 2019. [Online]. Available: https://www.researchgate.net/publication/332072371
Do Smart Contract Languages Need to be Turing Complete/download
[10] Very slow syncing on hard drive. [Online]. Available: https://github.com/
ethereum/go-ethereum/issues/14895
19
[11] Why is my node synchronization stuck/extremely slow at block 2,306,843?
[Online]. Available: https://ethereum.stackexchange.com/questions/9883/
why-is-my-node-synchronization-stuck-extremely-slow-at-block-2-306-843
[12] L. Reyzin, D. Meshkov, A. Chepurnoy, and S. Ivanov, “Improving authenticated dynamic dictionaries, with applications to cryptocurrencies,”
in International Conference on Financial Cryptography and Data Security.
Springer, 2017, pp. 376–392.
[13] L. Goodman, “Tezos — a self-amending crypto-ledger white paper,” URL:
https://www. tezos. com/static/papers/white paper. pdf, 2014.
[14] A. Biryukov and D. Khovratovich, “Equihash: Asymmetric proof-of-work
based on the generalized birthday problem,” Ledger, vol. 2, pp. 1–30, 2017.
[15] Ethash. [Online]. Available: https://github.com/ethereum/wiki/wiki/
Ethash/6e97c9cea49605264c6f4d1dc9e1939b1f89a5a3
[16] A. Chepurnoy, V. Kharin, and D. Meshkov, “Autolykos: The ergo platform
pow puzzle,” 2019. [Online]. Available: https://docs.ergoplatform.com/
ErgoPow.pdf
[17] Autolykos gpu miner. [Online]. Available: https://github.com/
ergoplatform/Autolykos-GPU-miner
[18] D. Meshkov, A. Chepurnoy, and M. Jansen, “Short paper: Revisiting difficulty control for blockchain systems,” in Data Privacy Management, Cryptocurrencies and Blockchain Technology. Springer, 2017, pp. 429–436.
[19] A. Chepurnoy, C. Papamanthou, and Y. Zhang, “Edrax: A cryptocurrency
with stateless transaction validation,” Cryptology ePrint Archive, Report
2018/968, Tech. Rep., 2018.
[20] Ethereum’s blockchain is once again feeling the ‘difficulty
bomb’ effect. [Online]. Available: https://www.coindesk.com/
ethereum-blockchain-feeling-the-difficulty-bomb-effect
[21] E. Heilman, N. Narula, G. Tanzer, J. Lovejoy, M. Colavita, M. Virza, and
T. Dryja, “Cryptanalysis of curl-p and other attacks on the iota cryptocurrency.”
[22] G. De Roode, I. Ullah, and P. J. Havinga, “How to break iota heart by
replaying?” in 2018 IEEE Globecom Workshops (GC Wkshps). IEEE,
2018, pp. 1–7.
[23] Iota vulnerability report: Cryptanalysis of the curl hash function enabling
practical signature forgery attacks on the iota cryptocurrency. [Online]. Available: https://github.com/mit-dci/tangled-curl/blob/master/
vuln-iota.md
20
[24] A. Chepurnoy and M. Rathee, “Checking laws of the blockchain with
property-based testing,” in Blockchain Oriented Software Engineering (IWBOSE), 2018 International Workshop on. IEEE, 2018, pp. 40–47.
[25] T. Duong, A. Chepurnoy, and H.-S. Zhou, “Multi-mode cryptocurrency
systems,” in Proceedings of the 2nd ACM Workshop on Blockchains, Cryptocurrencies, and Contracts. ACM, 2018, pp. 35–46.
[26] A. Kiayias, A. Miller, and D. Zindros, “Non-interactive proofs of proofof-work,” Cryptology ePrint Archive, Report 2017/963, 2017. Accessed:
2017-10-03, Tech. Rep., 2017.
[27] L. Luu, B. Buenz, and M. Zamani, “Flyclient super light client
for cryptocurrencies,” IACR Cryptology ePrint Archive, 2019. [Online].
Available: https://eprint.iacr.org/2019/226
[28] C. P´erez-Sol`a, S. Delgado-Segura, G. Navarro-Arribas, and J. HerreraJoancomart´ı, “Another coin bites the dust: an analysis of dust in utxobased cryptocurrencies,” Royal Society open science, vol. 6, no. 1, p. 180817,
2019.
[29] Ethereum network attacker’s ip address is traceable. [Online]. Available: https://www.bokconsulting.com.au/blog/
ethereum-network-attackers-ip-address-is-traceable/
[30] A. Chepurnoy and D. Meshkov, “On space-scarce economy in blockchain
systems.” IACR Cryptology ePrint Archive, vol. 2017, p. 644, 2017.
[31] M. Carlsten, H. Kalodner, S. M. Weinberg, and A. Narayanan, “On the
instability of bitcoin without the block reward,” in Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security.
ACM, 2016, pp. 154–167.
[32] E. Krause, “A fifth of all bitcoin is missing. these crypto hunters can help,”
2018.
[33] 51% attack. [Online]. Available: https://en.bitcoinwiki.org/wiki/51%
25 attack
[34] Script of the ergo treasury box. [Online]. Available:
https://github.com/ScorexFoundation/sigmastate-interpreter/blob/
1b7b5a69035fc384b47c18ccf42b87dd95bbcf12/src/main/scala/org/
ergoplatform/ErgoScriptPredef.scala#L118
[35] Script of the ergo emission box. [Online]. Available:
https://github.com/ScorexFoundation/sigmastate-interpreter/blob/
1b7b5a69035fc384b47c18ccf42b87dd95bbcf12/src/main/scala/org/
ergoplatform/ErgoScriptPredef.scala#L74
21
[36] Ergoscript, a cryptocurrency scripting language supporting noninteractive
zero-knowledge proofs. [Online]. Available: https://docs.ergoplatform.
com/ErgoScript.pdf
[37] Advanced ergoscript tutorial. [Online]. Available: https://docs.
ergoplatform.com/sigmastate protocols.pdf
[38] T. Nolan, “Alt chains and atomic transfers,” 2013. [Online].
Available: https://bitcointalk.org/index.php?topic=193281.msg2224949#
msg2224949
[39] Sybil attack. [Online]. Available: https://en.wikipedia.org/wiki/Sybil
attack
[40] A local exchange trading system on top of ergo. [Online]. Available:
https://ergoplatform.org/blog/2019 04 22-lets/
[41] An ico example on top of ergo. [Online]. Available: https://ergoplatform.
org/blog/2019 04 10-ico-example/

Articoli Correlati

Risposte