Ergo – Una Piattaforma Resiliente per il Contratto

Aggiornato il 8 Giugno 2022

Tempo di lettura stimato: 42 minuti

I soldi

Sviluppatori 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 le 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,
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 lo sianoBasato su UTXO(ad esempio,
Bitcoin) obasato sul conto(ad esempio, 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]. 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 a lungo termine 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 auto-modificabili che possono
adattarsi all’ambiente in evoluzione e migliorarsi senza parti fidate [13].

Ciò che serve è una combinazione di varie idee scientifiche insieme per risolvere questi problemi, fornendo anche un modo per ulteriori miglioramenti senza modifiche di rilievo e questo è
esattamente ciò che Ergo cerca di ottenere.

Visione Ergo #

Il protocollo Ergo è molto flessibile e potrebbe 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.
• Decentramento in primo luogo.Ergo dovrebbe essere il più decentralizzato possibile:
dovrebbero essere evitate tutte le parti (leader sociali, sviluppatori 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 delle grandi feste. 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.
• Concentrazione 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 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 di Autolykos #

Il componente principale di qualsiasi sistema blockchain è il suo protocollo di consenso ed
Ergo utilizza un protocollo di consenso unico auto-sviluppato Proof of Work (PoW) chiamato
Autolico, che è descritto di seguito. Nonostante un’ampia ricerca su possibile

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 suluna listaK-problema della
somma: un minatore deve trovareK=32 elementi da∑un elenco predefinitoRdi taglia N
=226(che ha una dimensione di 2 Gb), tale che j∈Jrj−sk=dè nel
intervallo{-b, . . . ,0, . . . , bmodq}. Elementi di listaRsono ottenuti come risultato del calcolo
unidirezionale dall’indiceio, due chiavi pubbliche minerpk, we hash dell’intestazione del
bloccomcomerio=H(i||M||pk||m||w), doveHè una funzione hash che restituisce i valori inZ
/qZeMè un grande messaggio statico che viene utilizzato per rallentare il calcolo dell’hash.
Inoltre, un insieme di indici di elementiJdeve essere ottenuto mediante una funzione
pseudo-casuale unidirezionalegenIndici, 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.

Si noti 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 a causa della chiave segretaskè
necessario 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
segretisk, w.
La durezza della memoria deriva dal fatto che l’algoritmo 1 richiede il
mantenimento dell’intero elencoRper l’esecuzione del ciclo principale. Ogni elemento
dell’elenco occupa 32 byte, quindi l’intero elenco diNelementi prendonoN·32 = 2GBdi
memoria perN=226. Un minatore può provare a ridurre i requisiti di memoria
calcolando questi elementi “al volo” senza tenerli in memoria, tuttavia, dovrà calcolare
lo stesso hashHpiù volte (circa 104tempi per le moderne GPU), riducendo così
l’efficienza e il profitto.
Calcolo della listaRè anche un compito computazionale piuttosto pesante: la nostra
implementazione iniziale [17] consuma 25 secondi su Nvidia GTX 1070 per riempire tutti e 2
26elementi della lista. Questa parte, tuttavia, può essere ottimizzata se un miner memorizza
anche un elenco di hash non finalizzatituio∈[0,N)=H(i||M||pz) 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 durante la finalizzazione e la
compilazione dell’elencoRper la nuova intestazione consuma solo pochi millisecondi (circa
50 ms su Nvidia GTX 1070).
Il parametro di destinazionebè 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 cerca di prevedere
l’hash rate di un’imminente epoca lunga 1024 blocchi sulla base dei dati delle 8 epoche
precedenti tramite il notometodo 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”.

Stato Ergo #

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 conti di
lunga durata e una transazione modifica il saldo monetario e la memoria interna

di alcuni conti. 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 da Bitcoin è che oltre al valore monetario e allo script protettivo,
una moneta una tantum Ergo, chiamata ascatola, 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 scatola può
avere 10 registri etichettatiR0, R1, . . . , R9, di cui i primi quattro sono riempiti con
valori obbligatori e il resto può contenere dati arbitrari o essere vuoti.
• R0(valore monetario).Quantità di Erg bloccata in questa casella.
• R1(copione di guardia).Script serializzato che protegge questa casella.
• R2(gettoni).Una scatola può contenere più gettoni. Questo registro contiene un array di (
identificatore del token→Quantità) 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 di “mancanza di 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 calcolatodopoapplicando 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

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 una piccola sintesi dello stato corrente sono in grado di
verificare un blocco completo: possono verificare che tutte le caselle esaurite siano state rimosse
dallo stato, tutte le caselle create sono state aggiunte e non sono state apportate altre 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).

Figura 1: confronto delle dimensioni della prova con un trie Merkle patricia

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:

Figura 2: A sinistra: dimensione della prova per modifica per 2000 transazioni in funzione della
dimensione iniziale dell’alberon. A destra: dimensione della prova per modifica per un albero con
n=1000000 chiavi in funzione della dimensione del lottoB. In entrambi i casi, metà delle
modifiche 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 il denaro contrattuale, Ergo dovrebbe anche supportare
contratti a lungo termine per un periodo almeno della vita di una persona media. Tuttavia,
anche le giovani piattaforme di smart contract esistenti stanno riscontrando problemi di
degrado delle prestazioni e adattabilità alle condizioni esterne. Ciò porta a una situazione in
cui la criptovaluta dipende da un piccolo gruppo di sviluppatori per fornire un hard-fork di
riparazione, altrimenti la criptovaluta non sopravviverà. Ad esempio, la rete Ethereum è
stata avviata con un algoritmo di consenso Proof-of-Work con un piano per passare a Proof-of-Stake nel prossimo futuro. Tuttavia, i ritardi nello sviluppo della Proof-of-Stake hanno
portato a diversi aggiustamenti di hard-fork [20] e la comunità è ancora costretta a fare
affidamento sugli sviluppatori principali che promettono di implementare il prossimo hard-fork.
Il primo problema comune di sopravvivenza è che, alla ricerca della popolarità, gli sviluppatori
tendono a implementare soluzioni ad hoc senza un’adeguata ricerca e test preliminari. Tali
soluzioni portano inevitabilmente a bug, che poi portano a correzioni di bug affrettate, quindi a
correzioni di tali correzioni di bug e così via, rendendo la rete inaffidabile e ancora meno sicura.


Un esempio degno di nota è la criptovaluta IOTA, che ha implementato varie soluzioni di
ridimensionamento, inclusa la propria funzione hash e la struttura DAG, che le hanno 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 poi risolto questi problemi passando alla ben nota funzione hash SHA3, confermando così l’inutilità di questo tipo di innovazioni. L’approccio di Ergo in questo caso consiste nell’utilizzare soluzioni stabili e ben collaudate, 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 sottoposte a revisione paritaria [12, 18, 3, 8, 24, 25] e sono
state ampiamente discusse nella comunità.
Un secondo problema che deve affrontare la decentralizzazione (e quindi la sopravvivenza) è
la mancanza di client leggeri sicuri e affidabili. Ergo cerca di risolvere questo problema della
tecnologia blockchain senza crearne di nuovi. Poiché Ergo è una blockchain PoW, consente
facilmente l’estrazione di una piccola intestazione dal contenuto del blocco. Questa sola
intestazione 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, cresce ancora linearmente
nel tempo. Una recente ricerca sui client leggeri fornisce un modo per i client leggeri di
sincronizzarsi con la rete scaricando una quantità ancora più piccola di dati, sbloccando così la
possibilità di unirsi alla rete utilizzando hardware di fascia bassa non affidabile come i telefoni
cellulari [26, 27].

Ergo utilizza uno stato autenticato 4 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 telefono cellulare può entrare in rete e
iniziare a utilizzare Ergo con le stesse garanzie di sicurezza di un nodo completo.
I lettori potrebbero notare un terzo potenziale problema in quanto, sebbene il supporto per i
client leggeri risolva il problema per gli utenti Ergo, non risolve il problema per i minatori Ergo,
che devono comunque mantenere l’intero stato per una convalida efficiente delle transazioni. Nei
sistemi blockchain esistenti, gli utenti possono inserire dati arbitrari in questo stato. Questi dati,
che durano per sempre, creano molta polvere e le sue dimensioni aumentano all’infinito 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 allo spazio di archiviazione
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 del “gonfiamento dello stato” senza
alcun tipo di compenso per i minatori o gli utenti che detengono lo stato potrebbero aver
impedito soluzioni di ridimensionamento che altrimenti avrebbero potuto essere implementate
(come blocchi di dimensioni maggiori, ad esempio). Per evitare ciò, Ergo ha una componente di
canone di archiviazione: se un’uscita rimane nello stato per 4 anni senza essere consumata, un
miner può addebitare una piccola commissione per ogni byte mantenuto nello stato.


Questa idea, che è simile ai normali servizi di cloud storage, è stata proposta solo di
recente per le criptovalute [30] e ha diverse importanti conseguenze. In primo luogo,
garantisce che il mining di Ergo sia sempre stabile, a differenza di Bitcoin e altre valute
PoW, dove il mining potrebbe diventare instabile dopo che l’emissione è stata completata
[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 le spese di stoccaggio da scatole obsolete, i minatori possono rimettere in
circolazione le monete e, quindi, impedire la costante diminuzione della circolazione della fornitura per smarrimento chiavi [32]. Tutti questi effetti dovrebbero supportare la sopravvivenza a
lungo termine di Ergo, sia tecnicamente che economicamente.


Una quarta sfida vitale alla sopravvivenza è quella dei cambiamenti nell’ambiente esterno e
delle richieste poste al protocollo. Un protocollo dovrebbe adattarsi all’infrastruttura hardware in
continua evoluzione, nuove idee per migliorare la sicurezza o la scalabilità che emergono nel
tempo, l’evoluzione dei casi d’uso e così via. Se tutte le regole vengono 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 divisione in diverse monete indipendenti. Al
contrario, il protocollo Ergo è automodificabile ed è in grado di adattarsi all’ambiente in
evoluzione. In Ergo, parametri come la dimensione del blocco possono essere modificati al volo
tramite il voto dei minatori. All’inizio di ogni epoca di votazione del blocco 1024, un miner propone
modifiche fino a 2 parametri (come un aumento della dimensione del blocco e una diminuzione
del fattore di tariffa di archiviazione). Durante il resto dell’epoca, i minatori votano per approvare
o rifiutare le modifiche. Se la maggioranza dei voti all’interno dell’epoca supporta la modifica, i
nuovi valori vengono scritti nella sezione di estensione del primo blocco dell’epoca successiva e la
rete inizia a utilizzare i valori aggiornati per l’estrazione e la convalida dei blocchi.


Per assorbire i cambiamenti più fondamentali, Ergo segue l’approccio di
softforkableche consente di modificare in modo significativo il protocollo
mantenendo operativi i vecchi nodi. All’inizio di un’epoca, un minatore può
anche proporre di votare per un cambiamento più fondamentale (ad
esempio, l’aggiunta di una nuova istruzione a ErgoScript) che descrive le
regole di convalida interessate. Il voto per tali modifiche sostanziali continua
per 32.768 blocchi e richiede almeno il 90% dei voti “Sì” per essere accettato.
Una volta accettato, un lungo periodo di attivazione di 32.768 blocchi inizia a
dare ai nodi obsoleti il tempo di aggiornare la loro versione del software. Se
un software del nodo non viene ancora aggiornato dopo il periodo di
attivazione, salta i controlli specificati ma continua a convalidare tutte le
regole note. L’elenco delle precedenti modifiche al soft fork viene registrato
nell’estensione per consentire ai nodi leggeri di qualsiasi versione del
software di unirsi alla rete e rispettare le regole di convalida correnti.

Gettone nativo di Ergo #

La piattaforma Ergo ha il suo token nativo, che si chiama Erg ed è divisibile fino a 109unità
più piccole, nanoErg (un nanoErg è un miliardesimo di un Erg). Gli Ergs sono importanti per
la stabilità e la sicurezza della piattaforma Ergo per diversi motivi discussi di seguito.
Durante la fase iniziale della vita di Ergo, i minatori riceveranno la ricompensa in Ergs
secondo un programma di emissione di token predefinito e codificato (vedi 6.1 per
maggiori dettagli). Queste monete incentiveranno i minatori a partecipare alla rete Ergo,
proteggendola da attacchi basati sull’hashrate come il noto attacco del 51% [33].
L’emissione di Erg sarà terminata in soli otto anni, dopodiché i minatori
riceveranno solo Erg dalle tasse. Sebbene, regolabile nel tempo tramite minatore il voto on-chain, la dimensione del blocco Ergo e il costo massimo di calcolo del blocco in un dato
momento saranno limitati, 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
a ordinare le transazioni, prevenendo gli attacchi di spam e consentendo ai minatori 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, essendo un UTXO
nelle blockchain basate su UTXO, chiamato box in Ergo, una volta creato vite forse per sempre
senza alcun compenso per i minatori e alcuni utenti che devono mantenere questo stato in
accesso casuale ad alto costo memoria. Ciò porta a un disallineamento degli incentivi e a un
continuo aumento delle dimensioni dello stato. Al contrario, Ergo ha una componente di affitto
dello storage che addebita periodicamente agli utenti Erg per ogni byte incluso nello stato.
Questa rendita di stoccaggio sta rendendo il sistema più stabile limitando le dimensioni dello
stato o assicurando un’adeguata compensazione per le dimensioni dello stato più grandi,
rimettendo in circolazione le monete perse e fornendo un’ulteriore ricompensa stabile e
prevedibile ai minatori.
Pertanto, essendo una piattaforma per il denaro contrattuale, Ergo è adatto per
costruire applicazioni e sistemi monetari su di esso. Tuttavia, la partecipazione a tali sistemi
richiederebbe l’utilizzo del token nativo Ergo, Erg, anche per pagare l’affitto dello storage e
le commissioni di transazione che forniranno ai minatori forti incentivi continui per
proteggere la rete con un’adeguata potenza di hash. Gli utenti, da parte loro, saranno
fortemente incentivati ad acquistare, utilizzare e risparmiare Ergs se trovano che le
applicazioni per Ergo siano di alto valore.

Emissione #

Tutti i token Erg che circoleranno mai nel sistema sono presentati nello stato
iniziale, che consiste in 3 caselle:
• Nessuna prova preliminare.Questa scatola contiene esattamente un Erg ed è protetta da
uno script che impedisce che venga speso da chiunque. Pertanto, è una scatola di lunga
durata che rimarrà nel sistema fino a quando il componente di affitto di archiviazione non
la distruggerà. Il suo scopo principale è dimostrare che il mining di Ergo non è stato
avviato privatamente da nessuno prima della data di lancio dichiarata. Per raggiungere
questo obiettivo, i registri aggiuntivi di questa casella contengono gli ultimi titoli dei media
(The Guardian, Vedomosti, Xinhua), nonché gli ultimi identificatori di blocco di Bitcoin ed
Ethereum. Pertanto, l’Ergo mining 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 lo
sviluppo di 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
per ogni blocco. Infine, durante i blocchi 590.400-655.199 (3 mesi) verranno rilasciati
1,5 Ergs per ogni blocco. Questa regola garantisce la presenza di fondi per

Ergo sviluppo per 2,5 anni e, in qualsiasi momento, i premi non
superano il 10% del numero totale di monete in circolazione.
In secondo luogo, ha una protezione personalizzata da spese impreviste. Inizialmente,
richiede che la transazione di spesa sia firmata da almeno 2 delle 3 chiavi segrete che sono
sotto il controllo dei membri del team iniziale. Quando spendono la scatola, sono liberi di
modificare questa parte del copione come desiderano, ad esempio aggiungendo nuovi
membri per proteggere i fondi della fondazione.
Durante il primo anno, questi fondi verranno utilizzati per coprire il token EFYT
pre-emesso. Successivamente, saranno distribuiti in modo decentralizzato
tramite un sistema di voto comunitario in fase di sviluppo.
• Ricompensa dei minatori.Questa scatola contiene 93.409.132 Erg che verranno
raccolti dai minatori di blocchi come ricompensa per il loro lavoro. Il suo script di
protezione [35] richiede che la transazione di spesa abbia esattamente due output
con le seguenti proprietà:
– Il primo output dovrebbe essere protetto dallo stesso script e il numero di Ergs
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 miner sarà in grado di raccogliere 66 Erg, dopodiché la ricompensa
del blocco verrà ridotta di 3 Erg ogni 64.800 blocchi (3 mesi) fino a raggiungere
lo zero al blocco 2.080.800.
– Il secondo output dovrebbe contenere le monete rimanenti e dovrebbe
essere protetto dalla seguente condizione: può essere speso da un miner
che ha risolto il puzzle PoW del blocco e non prima di 720 blocchi dopo il
blocco corrente.
Tutte queste regole risultano nella seguente curva che denota il numero di monete in
circolazione nel tempo:

Figura 3: curva di emissione Ergo

Denaro contrattuale #

A nostro avviso, la stragrande maggioranza dei casi d’uso per blockchain pubbliche (anche
quelli che affermano di fornire un computer mondiale decentralizzato di 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. Un’altra banale
osservazione 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 scrittura di
condizioni di protezione delle scatole al fine di implementare applicazioni finanziarie
flessibili e sicure. Le applicazioni Ergo sono definite in termini di protezione degli script
incorporati in scatole, che possono contenere anche dati coinvolti nell’esecuzione. Usiamo il
terminedenaro contrattualeper definire Ergs (e token secondari) il cui utilizzo è vincolato da
un contratto. Questo vale per tutti i token esistenti sulla piattaforma perché qualsiasi box
con il suo contenuto (Erg, token, dati) è vincolato da un contratto.
Tuttavia, possiamo distinguere tra due tipologie di Ergs contrattuali. Il primo,
chiamatolibero Erg, 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 èlimitato Ergs, i cui contratti richiedono che la transazione di spesa
disponga di caselle di input e output con proprietà specifiche.
Ad esempio, se una scatolaUNè protetto solo da una chiave pubblica (quindi è
sufficiente fornire una firma contro una transazione di spesa per distruggere la scatola), il
proprietario della chiave pubblica può spendereUNe trasferire gli Ergs in qualsiasi casella di
output arbitraria. Così, l’Erg all’internoUNsono liberi.

Al contrario, immagina una scatolaB protetto da una combinazione di chiave pubblica e condizione che richieda all’operazione di spesa di creare un output box con la stessa quantità di Ergs diBe il cui script di guardia ha l’hashrBMUEMuPQUx3GzgFZSsHmLMMBouLabNZ4HcERm4N (nella codifica Base58). In
questo caso, l’Erg inBsono limitati Ergs.
Allo stesso modo, possiamo definire token liberi e limitati. Un contratto Ergo può
avere diversi ibridi come Ergs limitati e token gratuiti o entrambi limitati sotto una
chiave pubblica e gratuiti sotto un’altra.

Preliminari per i contratti Ergo #

Mentre in Bitcoin, l’output di una transazione è protetto da un programma in un linguaggio
basato su stack denominatocopione, in Ergo una scatola è protetta da una formula logica
che combina predicati su un contesto con affermazioni crittografiche dimostrabili tramite
protocolli a conoscenza zero utilizzando AND, OR eK-fuori da-nconnettivi. La formula è
rappresentata come un grafico aciclico diretto digitato, la cui forma serializzata è scritta in
una casella. Per distruggere una scatola, una transazione di spesa deve fornire argomenti
(che includono prove a conoscenza zero) che soddisfino 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 una firma uno su due, lo
script di protezione sarebbepk1∥pk2, che significa “dimostrare la conoscenza di una
chiave segreta corrispondente alla chiave pubblicapk1o conoscenza di una chiave
segreta corrispondente alla chiave pubblicapk2”. Abbiamo due documenti separati per
l’aiuto nello sviluppo di contratti con ErgoScript: “ErgoScript Tutorial” [36] e “Advanced
ErgoScript Tutorial” [37]. Pertanto, non entriamo nei dettagli dello sviluppo di contratti
con ErgoScript. Piuttosto, forniamo un paio di esempi motivanti nelle sezioni seguenti.
Altre due caratteristiche delle possibilità di appalto per modellare Ergo sono:


• Input di dati:Per essere utilizzata in una transazione, una casella non deve essere distrutta
ma può essere invece di sola lettura. In quest’ultimo caso, ci riferiamo alla scatola come
facente parte delinserimento datidella transazione. Pertanto, una transazione ottiene due
set di riquadri come argomenti, gli input e gli input di dati, e produce un set di riquadri
denominatouscite. Gli input di dati sono utili per applicazioni Oracle e contratti interagenti.
• Token personalizzati:Una transazione può trasportare molti token purché la
complessità stimata per elaborarli non superi 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 una prima casella di
input (spendibile) della transazione. L’identificatore è univoco presupponendo la resistenza
alle collisioni di una funzione hash sottostante. L’importo dei token emessi 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 sia superiore all’importo totale di quel
token negli input della transazione (ad esempio, una certa quantità di token potrebbe
essere bruciata). Al contrario, per Ergs viene seguita la forte regola di prenotazione, che
richiede che la quantità totale di Ergs negli ingressi e nelle uscite debba essere la stessa.

Esempi di contratto #

In questa sezione forniamo alcuni esempi che dimostrano la superiorità dei
contratti Ergo rispetto a quelli di Bitcoin. Gli esempi includono scommesse su dati
forniti da 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 esempio di
oracolo che mostra anche alcuni modelli di progettazione che abbiamo scoperto giocando
con i 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 la temperatura di
domani supera i 15 gradi, e spendibile da Bob in caso contrario. Per fornire la temperatura
nella blockchain, è necessario un oracolo fidato.
A differenza di Ethereum con i suoi account di lunga durata, in cui l’identificatore di un
oracolo fidato è solitamente noto in anticipo, fornire dati con caselle monouso è più complicato.
Per cominciare, non ci si può fidare di una scatola protetta dalla chiave dell’oracolo, poiché
chiunque può creare una scatola del genere. È possibile includere i dati firmati in una casella e
controllare la firma dell’oracolo nel contratto (abbiamo un esempio del genere), ma questo è
piuttosto complicato. 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 un tale tokenun token
singleton. L’oracolo crea una scatola contenente questo token insieme ai suoi dati (cioè la
temperatura) nel registroR4e l’ora dell’epoca UNIX nel registroR5. 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 il primo input di dati (di sola lettura) per contenere il token dell’oracolo. Il
contratto estrae la temperatura e il tempo dai dati inseriti 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 l’ora e la temperatura in una casella
insieme a una firma su questi dati. Tuttavia, ciò richiede la verifica della firma, che è
più complessa e costosa rispetto all’approccio del token singleton. Inoltre, il contratto
mostra come gli input di dati di sola lettura potrebbero essere utili per i contratti che
devono accedere ai dati archiviati in qualche altra casella nello stato. Senza input di
dati, un oracolo deve emettere una scatola spendibile per ogni 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 richiedere una
configurazione affidabile. Pertanto, è desiderabile trovare un modo più economico per la miscelazione
delle monete. Come primo passo verso questo, offriamo un protocollo di mixaggio non interattivo tra
due utenti Alice e Bob che funziona come segue:

  1. Alice crea una scatola che richiede la transazione di spesa per soddisfare
    determinate condizioni. Dopodiché, Alice ascolta solo la blockchain; non è
    necessaria alcuna interazione con Bob.
  2. Bob crea una transazione spendendo la casella di Alice insieme a una sua
    per generare due output con script identici ma dati diversi. Ciascuno di
    Alice e Bob può spendere solo uno dei due output, ma un osservatore
    decide quale output appartiene a chi perché sembrano indistinguibili.
    Per semplicità, nell’esempio non consideriamo la tariffa. L’idea del missaggio
    è simile allo scambio di chiavi Diffie-Hellman non interattivo. Innanzitutto, Alice
    genera un valore segretoX(un numero enorme) e pubblica il valore pubblico
    corrispondente gX=gX. Richiede a Bob di generare un numero segretoye per
    includere in ogni output due valoric1,c2, dove un valore è uguale agye l’altro è
    uguale agxy. Bob usa una moneta a caso per scegliere i significati{c1, c2}. Senza
    l’accesso ai segreti, un osservatore esterno non può indovinare con probabilità
    meglio di 1
    2sec1è uguale agyo agxy. Questo presuppone che il
    la primitiva crittografica che utilizziamo ha una certa proprietà, che il problema
    Decision Diffie-Hellman (DDH) è difficile. Per distruggere una casella di output,
    dovrebbe essere fornita anche una provayè noto tale chec2=gy, oXè noto tale che
    c2=cX 1. Il contratto della scatola di Alice lo controllac1ec2sono ben formati. Il
    vengono forniti frammenti di codice per la moneta di Alice e l’output della transazione di missaggio

rispettivamente negli algoritmi 4 e 5. Dal momento che ErgoScript attualmente non ha
supporto per dimostrare la conoscenza di alcuniXtale chec2=cX 1 per arbitrarioc1,
dimostreremo un’affermazione leggermente più lunga che è supportata, vale a dire la dimostrazione
conoscenza diXtale chegX=gXec2=cX 1.Questo è chiamato proveDHTuple.

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.

Altri esempi #

In questa sezione, faremo brevemente luce su alcuni altri esempi insieme ai collegamenti ai
documenti che forniscono i dettagli e il codice.
Scambio atomicoLo scambio atomico incrociato tra Ergo e qualsiasi blockchain che supporti
il pagamento a preimage hash SHA-256 o Blake2b-256 e time-lock può essere eseguito in
modo simile a quello proposto per Bitcoin [38]. Un’implementazione alternativa Ergo è
fornita in [36]. Poiché Ergo ha anche token personalizzati, è possibile anche lo scambio
atomico sulla singola blockchain Ergo (Erg-to-token o tokento-token). Un’implementazione
per questo può essere trovata anche in [36].


Raccolta di fondiConsideriamo lo scenario di crowdfunding più semplice. In questo
esempio, un progetto di crowdfunding con una chiave pubblica nota è considerato riuscito se può raccogliere le uscite non spese con un valore totale non inferiore a una certa
quantità prima di una certa altezza. Un finanziatore del progetto crea una casella di output
protetta dalla seguente dichiarazione: la casella può essere spesa se la transazione di spesa
ha la prima casella di output protetta dalla chiave del progetto e un importo non inferiore
all’importo target. Quindi il progetto può raccogliere (in un’unica transazione) le caselle di
output dei finanziatori più grandi con un valore totale non inferiore all’importo target (è
possibile raccogliere fino a 22.000 output, sufficienti anche per una grande campagna di
crowdfunding). Per i restanti output, è possibile costruire operazioni di follow-up. Il codice
può essere trovato in [36].


Il sistema di scambio di borsa localeQui dimostriamo brevemente un sistema di
scambio di borsa locale (LETS) in Ergo. In un tale sistema, un membro di una
comunità può emettere valuta comunitaria tramite debito personale. Ad esempio,
se Alice con saldo zero sta acquistando qualcosa per 5 gettoni comunità da Bob, il
cui saldo è pari a zero, il suo saldo dopo lo scambio sarebbe−5 gettoni e il saldo di
Bob sarebbe 5 gettoni. Quindi Bob può acquistare qualcosa usando i suoi 5
gettoni, ad esempio da Carol. Solitamente, in tali sistemi, c’è un limite ai saldi
negativi (per evitare il free-riding).


Poiché una comunità digitale è vulnerabile agli attacchi Sybil [39], è necessario un
meccanismo per prevenire tali attacchi in cui i nodi Sybil creano debiti. La soluzione
più semplice è utilizzare un comitato di manager fidati che approvi i nuovi membri
della comunità. Una soluzione trustless ma più complessa consiste nell’utilizzare
depositi cauzionali effettuati in Ergs. Per semplicità, consideriamo qui l’approccio con il
comitato.


Questo esempio contiene due contratti interagenti. UNcontratto di gestione mantiene
un elenco di membri della comunità ed è possibile aggiungere un nuovo membro se alcune
condizioni di gestione sono soddisfatte (ad esempio, viene fornita una firma di soglia). Un
nuovo membro è associato a una casella contenente un token che identifica il membro.
Questa scatola, che contiene ilcontratto di appartenenza, è protetto da uno speciale script
di scambio che richiede che la transazione di spesa esegua uno scambio equo. Saltiamo il
codice corrispondente, che può essere trovato in un articolo separato [40].
Ciò che questo contratto mostra, contrariamente all’esempio precedente, è che invece di
memorizzare l’elenco dei membri, nella casella può essere incluso solo un breve riassunto di un
albero AVL+ autenticato. 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+. Pertanto, il risparmio di spazio nella
memoria di stato porta a transazioni più grandi, ma questo problema di scalabilità è più facile da
risolvere.


Offerta iniziale di moneteDiscutiamo di un esempio di Initial Coin Offering (ICO) che
mostra come è possibile creare contratti a più stadi in Ergo. Come la maggior parte
delle ICO, il nostro esempio ha tre fasi. Nella prima fase, il progetto raccoglie fondi in
Ergs. Nella seconda fase, il progetto emette un nuovo token, il cui importo è pari al
numero di nanoErg raccolti 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 una
singola transazione è sufficiente per la seconda fase. Simile all’esempio precedente, il
contratto ICO utilizza un albero AVL+ per memorizzare l’elenco delle coppie (investitore,
importo). Il codice completo è disponibile su [41].


Altri esempiAbbiamo ancora più esempi di applicazioni Ergo in [36, 37].
Questi esempi includono emissioni a tempo controllato, contratti cold wallet,
giochi rockpaper-forbici e molti altri.

Cosa nè pensi?