Cartesi machine, cosa c’è in una macchiana?
Cartesi machine è composta da un processore e una scheda che separano le macchine cartesi.
Il processore esegue i calcoli, eseguendo il tradizionale ciclo fetch-execute mantenendo una varietà di registri.
Con un assortimento di unità flash e memorie RAM e ROM insieme a una serie di dispositivi la scheda definisce l’ambiente che la circonda.
Memorie e dispositivi sono mappati nello spazio degli indirizzi fisici a 64 bit della Cartesi Machine.
La quantità di RAM, nonché il numero, la lunghezza e la posizione delle unità flash nello spazio degli indirizzi possono essere scelti in base alle esigenze di ogni particolare applicazione.
In uno scenario tipico, una macchina Cartesi viene inizializzata e quindi avviata fino all’arresto.
Da file normali installati nel file di sistema il processo di inizializzazione, carica l’immagine ROM, un’immagine RAM e un file di sistema radice, tipo un’unità flash.
Dall’immagine ROM parte l’esecuzione contenente un programma per il kernel linux dove crea una descrizione dell’organizzazione della macchina.
L’immagine ROM rom.bin può essere creata nella rom/directory dell’Emulatore SDK.
Il kernel Linux stesso risiede nell’immagine RAM linux.bin, costruita nella kernel/directory nell’Emulatore SDK.
Dopo aver eseguito la propria inizializzazione, il kernel Linux cede il controllo al /sbin/initprogramma nel file system radice.
Il file system radicerootfs.ext2 contiene tutti i file di dati e i programmi che costituiscono una distribuzione Linux incorporata.
Può essere compilato nella fs/directory dell’Emulatore SDK.
Nel file system radice o nel proprio file system separato risiedono tutti i componenti dapp.
È possibile utilizzare unità flash aggiuntive come input e output DApp, contenenti file system o dati grezzi.
L’emulatore può essere incaricato di eseguire qualsiasi calcolo la DApp desideri eseguire all’interno della Macchina Cartesi.
Rollup di Cartesio
Smart contract scalabili creati con stack software tradizionali.
Con risoluzione interattiva delle controversie descartes rollups è una variante dei rollup ottimistici.
Invece di Solidity, usa innumerevoli componenti software tradizionali per codificare contratti intelligenti eseguiti su una macchina virtuale Linux.
Nel giugno 2020, Compound ha emesso il suo token COMP, accendendo una mania di yield farming.
Gli utenti DeFi hanno invaso Ethereum di transazioni e la rete ha raggiunto rapidamente la capacità, portando a commissioni alle stelle e, di conseguenza, a un processo di gentrificazione.
Per la maggior parte delle dapp la blockchain e stata inutilizzabile per molti giorni, rendendo chiaro che è urgente per la sostenibilità del sistema di ethereum correggere la scalabitiltà.
Nel frattempo, la Ethereum Foundation ha lavorato duramente per rendere disponibile lo sharding su Serenity (Eth 2.0) e, attraverso questo, aumentare il throughput delle transazioni a livelli più alti.
Il vero e proprio sharding con il supporto di smart contract non arriverà presto a causa di una sfida tecnologica pesante.
Poiché i miglioramenti della scalabilità sul livello 1 non possono eguagliare la base di utenti di Ethereum e la vigorosa crescita dell’ecosistema DApp, Vitalik ha voluto proporre rollup poiché gli sviluppatori di armi hanno bisogno di
sconfiggere le enormi tariffe del gas e ottenere prestazioni migliori.
I rollup sono usciti di recente come un approccio più promettente al ridimensionamento rispetto al plasma, un precedente famigerato approccio di livello 2 per ridimensionare Ethereum.
Il motivo è che i rollup risolvono un problema fondamentale della disponibilità dei dati inerente al plasma e ad altri progetti di livello 2.
Con i rollup, tutti i dati delle transazioni vengono raggruppati (arrotolati) e resi disponibili su Ethereum stesso in un modo più economico di quanto non sarebbero normalmente per una normale transazione sulla blockchain.
Inoltre, la maggior parte del carico computazionale va fuori catena, ottenendo grandi guadagni in termini di throughput ed efficienza dei costi di transazione.
Perché Cartesi Rollups è unico
La tecnologia di base di Cartesi si basa sulla sua macchina virtuale che emula un RISC-V ISA, chiamata Cartesi Machine.
È stato progettato per eseguire logica decentralizzata ad alta intensità di calcolo off-chain, in un ambiente Linux.
Le macchine Cartesi sono autonome e riproducibili. Sono anche trasparenti, il che significa che espongono il loro stato per un’ispezione esterna attraverso succinte prove di alberi Merkle.
Il cartesi team sta lavorando per poter supportare optimistic rollups , lavorando ad un aggiornamento del proprio sistema con risoluzione delle controversie.
L’implementazione aiuta a contribuire in maniera diretta al problema della scalabilità degli smart contract, eseguendo calcoli pesanti che sarebbero difficilmente possibili da eseguire on chain.
Ci si può aspettare un ridimensionamento computazionale di un milione di volte senza perdite per le forti garanzie di sicurezza di Ethereum.
Da solo, sarebbe abbastanza utile. Ma qualcos’altro rende notevole il sistema di Cartesi. Con Cartesi Rollups, gli smart contract vengono eseguiti off-chain su Cartesi Machines.
Poiché questi supportano Linux, gli sviluppatori hanno la possibilità di rinunciare a Solidity e alle limitazioni dell’EVM per creare contratti intelligenti con una miriade di stack software tradizionali, toolchain, librerie standard, file system e altre risorse del sistema operativo.
L’esecuzione di contratti intelligenti su un runtime Linux deterministico non è mai stato possibile prima d’ora.
Per la prima volta, gli sviluppatori avranno a disposizione un intero sistema operativo per gli smart contract.
Riteniamo che questo rappresenti più di un miglioramento incrementale per le applicazioni decentralizzate.
Consentire la programmabilità tradizionale significa che gli sviluppatori di DApp hanno un potere espressivo completamente nuovo per creare contratti intelligenti da semplici a piuttosto complessi.
Significa anche aprire le porte a un’ampia adozione da parte di sviluppatori regolari che non hanno mai programmato per blockchain, poiché creeranno applicazioni decentralizzate con un’esperienza di codifica simile al desktop o al web.
Una rapida introduzione ai rollup ottimisti.
Inizialmente per scalare ethereum, i rollup sono una classe di soluzioni layer 2.
Le transazioni vengono aggregate e inviate a basso costo in batch all’interno di un contratto intelligente mentre tutte le elaborazioni che comportano vanno fuori catena.
Grazie alle forti garanzie sulla sicurezza della blockchain i risultati delle transazioni vengono regolati sulla catena senza nessuna perdita.
Esistono due classi di rollup. Da un lato, abbiamo quelli basati su prove di validità (rollup ZK).
Dall’altro, quelli basati su prove di frode (rollup ottimistici). In questo articolo, descriviamo una variante dei rollup ottimistici con risoluzione interattiva delle controversie.
In particolare, ci addentriamo in Cartesi Rollups e nella sua capacità di supportare contratti intelligenti complessi in esecuzione direttamente su un ambiente runtime Linux.
Iniziamo con una panoramica del design ottimistico dei rollup.
In fase di esecuzione, gli utenti di un’applicazione rollup depositano inizialmente le proprie criptovalute su un particolare contratto intelligente sul livello 1 (d’ora in avanti chiamato portale), fornendo loro uno stato iniziale e fondi sul livello 2.
Fatto ciò, possono iniziare a inviare messaggi al contratto di livello 2, avanzando di conseguenza il suo stato.
Di tanto in tanto, lo stato del contratto di livello 2 deve essere riflesso e finalizzato sul livello 1, il che implica in genere una ridistribuzione dei token tra gli utenti coinvolti.
Per questo, uno dei nodi di convalida inserisce un’affermazione statale sulla catena, con tutte le parti coinvolte che rimangono ottimiste, sperando che l’affermazione sia vera.
Quando viene presentata la richiesta, inizia un periodo di contestazione, che concede tempo sufficiente a qualsiasi altro nodo validatore per verificarlo e inviare una prova di frode sul livello 1 in caso di disaccordo.
Se nessun altro validatore presenta alcuna sfida, la blockchain considera finalizzata la richiesta originale.
Tuttavia, se viene inviata una transazione contenente una prova di frode, la blockchain giudica la controversia e garantisce che il reclamo corretto sia finalizzato inequivocabilmente sulla catena.
Cartesi sta implementando una variante di rollup ottimistici con risoluzioni interattive delle controversie.
In questa situazione la blockchain ha un ruolo di verifica tra i nodi del richiedente e sfidante, fino a quando non viene scoperto uno dei due ingannevole.
I rollup ottimistici con controversie interattive consentono immensi guadagni di scalabilità, poiché un set di validatori specifico dell’applicazione può eseguire attività di calcolo pesanti.
Sulla blockchain, ogni nodo deve emulare le transizioni di stato di tutte le applicazioni esistenti.
In effetti, spostare i contratti intelligenti al livello 2 su rollup ottimistici è come avere uno shard di livello 2 specifico per l’applicazione.
Per motivi di sicurezza e per prestazioni, nel caso di cartesi, ogni smart contract in esecuzione sul layer 2 lo fa sul proprio shard.
Avremo un pezzo dedicato sulla sicurezza, che sarà pubblicato nel prossimo futuro.
C’è un avvertimento. Il guadagno di scalabilità dei rollup ottimistici, con o senza controversie interattive, viene a scapito di una finalità ritardata sul livello 1.
Tale ritardo alla finalizzazione comporta un problema di efficienza del capitale, poiché gli utenti devono affrontare lunghi tempi di regolamento sulla blockchain, che possono durare diverse settimane quando si verificano controversie.
Il motivo è che i nodi di validazione onesti possono continuare a far avanzare lo stato del contratto nonostante le latenze sul livello 1, sapendo che il sistema finalizzerà le transizioni di stato corrette sulla catena, dato abbastanza tempo.
In ogni caso, l’efficienza del capitale sul livello 1 rimane un problema importante che deve essere affrontato e, fortunatamente, alcune strategie mitigano il problema.
Una possibilità è quella di utilizzare fornitori di liquidità.
Un altro è attraverso uno specifico compromesso di configurazione del nodo che elimina virtualmente il problema, di cui parleremo più dettagliatamente di seguito.
Frammenti di applicazione
Su Ethereum, l’EVM ha lo scopo di elaborare tutte le transazioni che coinvolgono ogni smart contract distribuito sulla rete.
Questo è fondamentalmente diverso dai Cartesi Rollups, in cui le macchine Cartesi hanno lo scopo di specificare ed eseguire i singoli contratti di livello 2 in modo indipendente.
Significa che ogni macchina convalida un singolo contratto e ogni contratto ha il suo set esclusivo di validatori, creando di fatto uno shard di livello 2 a singola applicazione.
Questo design consente enormi guadagni di scalabilità degli smart contract.
Possiamo avere ordini di grandezza di throughput computazionale più elevato senza compromettere le forti garanzie di sicurezza di Ethereum, a condizione che almeno un validatore sia onesto e disponibile a impegnarsi in controversie di fronte a false affermazioni.
Le macchine Cartesi che eseguono contratti di livello 2 separati possono interagire tra loro solo attraverso input e output regolari, con queste interazioni mediate da un hub speciale di cui parleremo in dettaglio in una futura pubblicazione.
Esecuzione del contratto
Su Cartesi Rollups, i contratti vengono eseguiti in un ambiente che non ha opinioni come sembra.
La Cartesi Machine è una VM generica che emula un’architettura hardware standard aperta ed esegue il sistema operativo open source più pervasivo al mondo.
Non obbliga gli sviluppatori a utilizzare un linguaggio particolare, uno stack software o un’API specifica, se è per questo.
Invece, sono liberi di fare le loro scelte di design e componenti software quando codificano i loro contratti intelligenti di livello 2.
Questo ha profonde implicazioni. Cartesi rilascia gli smart contract di Ethereum dalle idiosincrasie di Solidity e dai limiti dell’EVM, garantendo la produttività mainstream agli sviluppatori di DApp.
A questo punto è utile riformulare il termine “contratto di livello 2”.
Mentre, nel contesto dell’EVM, i contratti intelligenti hanno un significato ben definito e ampiamente compreso, qui “contratto di livello 2″ indica qualsiasi programma che elabora input e crea output.
Questo programma può essere implementato anche come uno o più processi che coinvolgono più server e servizi in esecuzione sulla Macchina Cartesi.
Anche con l’uso di thread software e logiche molto complesse che coinvolgono in virgola mobile, la riproducibilità del programma è assicurata perché le Macchine Cartesi sono deterministiche.
Con questa distinzione chiara, torniamo a come funziona il protocollo.
Gli utenti iniziano inviando messaggi al contratto di livello 2, spingendoli direttamente sulla blockchain o utilizzando un servizio di aggregazione.
In ogni caso i messaggi arrivano ad un ordine preciso e restano disponibili on-chain.
Tramite una flash drive di imput di tanto in tanto i validatori recuperano un batch di messaggi e li inviano alla macchina cartesi.
Il contratto di livello 2 legge quindi il payload di input, analizzandolo ed elaborandolo in base alle scelte sintattiche e semantiche determinate dallo sviluppatore.
Spetta anche allo sviluppatore adottare i propri standard API preferiti.
Ad esempio, un gruppo di sviluppatori può scegliere di codificare i messaggi direttamente in richieste HTTP da elaborare da un server web in esecuzione nella Cartesi Machine.
Un altro gruppo potrebbe preferire codificare i messaggi come chiamate gRPC a un altro server.
Entrambi i gruppi di sviluppatori avrebbero accesso a tutto il software di supporto eseguito su Linux durante l’implementazione di questi meccanismi di trasporto.
L’elaborazione di ciascun messaggio fa avanzare lo stato del contratto di livello 2 e in ciascuna di queste transizioni di stato, il contratto di livello 2 può scrivere dati nell'”unità flash” di output della macchina.
L’hash radice viene inviato alla blockchain dopo che tutte le elaborazioni degli output corrispondenti vengono riepilogati in un albero Merkler.
La macchina esegue tutti i messaggi in un file batch.
Come spiegato in precedenza, in qualsiasi transizione di stato quando il contratto di livello 2 elabora un messaggio, può scrivere dati sull'”unità flash” di output della macchina.
I log corrispondono a tutti i dati rilevanti per le applicazioni client ma non hanno alcun effetto sulla catena.
Al contrario, i bytecode di livello 1 sono bytecode EVM che l’applicazione client o alcuni utenti devono eseguire sulla catena in futuro.
Nello scenario più semplice, il bytecode può eseguire semplici trasferimenti di risorse, ma può anche chiamare altri contratti intelligenti di livello 1 ed essere complesso quanto richiesto dall’applicazione.
È attraverso i bytecode di livello 1 che gli stati di livello 2 vengono riflessi e finalizzati sulla catena.
Ciò significa che i validatori stessi non rilasciano fondi sulla blockchain.
Invece, gli utenti inviano una richiesta al contratto di livello 2, il contratto di livello 2 decide se il ritiro è garantito e, in tal caso, emette il bytecode corrispondente.
Quindi gli utenti inviano loro stessi una transazione su Ethereum all’I /O Manager, che è il contratto di livello 1 di Cartesi Rollup responsabile dell’esecuzione di un bytecode.
Ad esempio, un utente che desidera prelevare token ERC20 dal proprio portafoglio invierà all’I /O Manager un bytecode che esegue il trasferimento del token.
Insieme al bytecode, invieranno anche la prova Merkle che tale bytecode fa parte dell’albero Merkle rappresentato dall’hash di output finalizzato sulla catena.
Si noti che la parte che tenta di eseguire il bytecode deve attendere che l’ hash di output sia considerato definitivo dalla blockchain, altrimenti l’ I/O Manager rifiuta il tentativo di eseguire il trasferimento.
Per comprendere meglio l’intero processo su una sequenza temporale, descriviamo come il sistema pianifica le diverse fasi dei rollup.
Cartesi suddivide la sequenza temporale di esecuzione dei contratti di livello 2 in epoche.
In una data epoca N, i nodi validatori coinvolti raggruppano tutti i messaggi di input che sono stati accodati sulla catena dall’inizio dello slot di elaborazione dell’epoca precedente fino all’inizio dello slot di elaborazione dell’epoca corrente.
I nodi elaborano quindi ogni messaggio del batch attraverso la Cartesi Machine, producendo un hash di output che riassume la transizione di stato dell’intera epoca.
Quindi, uno dei validatori, d’ora in poi chiamato claimer , inserisce nella catena l’hash che rappresenta lo stato del contratto di livello 2 alla fine dell’epoca N, S(N).
Al termine di un periodo di contestazione, se non c’è stata controversia, S(N) è considerato definitivo dal sistema.
In caso contrario, seguiranno controversie fino a quando non verrà applicata la rivendicazione dello stato corretto rappresentata dal relativo hash di output.
Il periodo di regolamento visualizzato nel diagramma soprastante rappresenta un periodo di contestazione, con o senza controversie.
Per garantire una durata minima per ogni epoca, il protocollo di rollup richiede anche uno slot di accumulo.
Per evitare che le richieste frequenti vengano inviate al livello 1 viene imposta una latenza minima alla finalizzazione on chain per motivi di efficienza dei costi di commissione sulla piattaforma ethereum.
A seconda di come vogliono bilanciare la latenza con la finalità e la sicurezza spetta allo sviluppatore del rollup impostare il periodo dello slot di accumulo.
Comitato di validatori
Nelle versioni successive, Cartesi Rollups consentirà un numero qualsiasi di nodi validatori e non autorizzati.
Nella sua prima versione, Cartesi Rollups consentirà agli sviluppatori di selezionare un comitato di nodi validatori.
Definiscono le organizzazioni che gestiscono i nodi che preferiscono e pagano una tariffa a ciascuna di esse per fornire il servizio.
Le organizzazioni selezionate quindi istanziano un nodo validatore e scaricano un modello Cartesi Machine che contiene tutto l’ambiente, la configurazione e il software che comprende il contratto di livello 2.
Con i validatori pronti con i loro contratti e online, lavoreranno in modo proattivo per garantire ai propri utenti le corrette transizioni di stato.
Il comitato dei validatori fornisce una garanzia di fiducia, il che significa che fintanto che almeno un validatore è onesto e vigile, le corrette transizioni di stato e i prelievi di attività sono finalizzati sulla catena.
In primo luogo, un contratto basato su un comitato può chiedere a tutti i suoi validatori di presentare le proprie richieste in modo proattivo il prima possibile.
Una volta che tutti i nodi fanno immediatamente la stessa richiesta, rendono superfluo il resto del periodo di sfida, eliminando le lunghe latenze alla finalità e il problema dell’efficienza del capitale.
Nello scenario peggiore, ci saranno fino a N-1 controversie per i validatori N in disaccordo tra loro, che potrebbero richiedere settimane per essere risolte.
Tuttavia, per scopi pratici, questa situazione dovrebbe verificarsi raramente (se mai) se i corridori del nodo selezionati si preoccupano dei loro soldi e della loro reputazione.
Pertanto, in circostanze estremamente rare, i contratti subiscono un ritardo nella finalizzazione.
Ciò potrebbe essere attribuito a difficoltà tecniche, ad esempio dovute a nodi offline che non possono confermare un reclamo in tempo.
O all’operazione dolosa, che finirebbe per essere sdoganata durante tutto il protocollo di risoluzione delle controversie, con l’identificazione e la penalizzazione del node runner disonesto.
Il sistema stesso identifica sempre i nodi dannosi.
La trasparenza fornita dal sistema rende i corridori del nodo responsabili di qualsiasi comportamento malvagio o scarso rendimento.
Pertanto, gli istituti di convalida degli incentivi devono agire in modo doloso o negligente tende ad essere basso a causa della reputazione o dei rischi legali.
Il secondo aspetto positivo riguarda la privacy.
Tutti i governi con cartesi rollups hanno il vantaggio di poter creare reti autorizzate, nascondendo i dati sensibili dal resto del mondo, poiché i contratti cartesi espongono solo al livello 1 le informazioni che desiderano.
Questo perché Cartesi Machines può utilizzare chiavi crittografiche che consentono loro di leggere i messaggi di input crittografati che vengono inviati alla blockchain.
Dall’esterno, nulla è trapelato a parte gli effetti collaterali nel livello 1.
Solo le parti autorizzate avrebbero accesso al contratto di livello 2 , dato che l’insieme dei nodi validatori è autorizzato.
Ora, vediamo più in dettaglio come il comportamento dei nodi validatori influisca sul periodo di regolamento.
La configurazione più efficiente elimina i lunghi ritardi di finalizzazione coinvolti nei progetti di rollup ottimistici.
Tutti i validatori pongono le loro richieste in modo proattivo e sono tutti d’accordo tra loro.
Ciò può accadere rapidamente, con tutte le rivendicazioni che possono entrare nello stesso blocco sul livello 1, senza aggiungere alcun ritardo alla finalità.
Tuttavia, uno o più validatori potrebbero non presentare tempestivamente la propria richiesta.
In tal caso, il portale deve attendere abbastanza a lungo per raccogliere le richieste mancanti o far scadere il periodo di contestazione.
Supponiamo che uno o più validatori non presentino le proprie affermazioni, ma almeno tutte le attestazioni inviate corrispondono.
Al termine del periodo di contestazione, il portale considera il reclamo come definitivo.
Tuttavia, un’altra possibilità è che il portale raccolga una o più affermazioni contrastanti durante il periodo di contestazione.
In tal caso, se abbiamo N reclami, nello scenario peggiore, avremmo N-1 controversie da eseguire in serie.
In tal caso, il richiedente onesto vincerebbe qualsiasi partita di verifica contro qualsiasi altro nodo e la sua richiesta verrà finalizzata sulla catena.
Sempre nell’ambito dei comitati validatori, Cartesi Rollups supporterà due classi di nodi: validatori e osservatori.
Al contrario, i nodi osservatore partecipano al consenso del livello 2 inviando o leggendo messaggi e facendo avanzare il loro stato contrattuale, ma non hanno il permesso di presentare reclami o avviare controversie.
I nodi Observer esistono per la comodità delle applicazioni client e dei loro utenti e possono essere eseguiti direttamente dagli utenti o da terze parti.
Collaterals e mercato dei nodi
Quando si considerano i comitati di validazione, i validatori istituzionali che non gestiscono correttamente i propri nodi possono essere penalizzati in diversi modi.
La loro reputazione verrebbe in appannaggio da una registrazione indelebile del loro comportamento scorretto.
Poiché queste informazioni sono pubblicamente disponibili in tutta la rete blockchain, in alcuni casi è possibile intraprendere un’azione legale, utilizzando la traccia storica della blockchain come prova in tribunale.
