L’Architettura di Oasis Network: Progettata per la Scalabilità

Disclaimer: questo post è una traduzione da parte di un membro della community di Oasis Network. Vengono effettuati controlli rigorosi per fornire traduzioni accurate, ma possono essere soggetti a errori e omissioni. Oasis Network non è responsabile per l’accuratezza e l’affidabilità delle informazioni tradotte.

Potete leggere l’articolo originale in inglese qui: https://medium.com/oasis-protocol-project/oasis-network-architecture-designed-for-scaling-2799994a4a21#fafe

L’unica blockchain con supporto nativo per i rollup al livello di consenso

Le soluzioni di scaling di livello 2 si sono evolute da “sidechains” a “commitchains”, “rollup” e ponti di validazione. “Rollup” si riferisce all’esecuzione di una macchina virtuale (VM) per contratti intelligenti in cui lo stato della VM viene periodicamente verificato e trasmesso a una blockchain sottostante per fornire funzionalità di contratti intelligenti a un costo inferiore e a un throughput più elevato, rispetto all’esecuzione di contratti intelligenti direttamente sulla blockchain sottostante. La verifica sulla blockchain sottostante assicura le transizioni di stato, e i calcoli fuori dalla blockchain permettono di scalare l’esecuzione del contratto intelligente.

Non li abbiamo chiamati rollup, ma è così che funziona il ParaTimes o livello di calcolo di Oasis Network.

Sin dalla sua nascita, l’Oasis Network separa i calcoli dal consenso come principio di progettazione modulare. Questa separazione significa che le entità di livello Paratime gestiscono solo l’esecuzione di contratti intelligenti, e le entità di livello di consenso gestiscono solo il consenso, ed entrambe sono notevolmente semplificate. Questo ha molti vantaggi, tra cui la facilità di controllo, l’isolamento dei guasti e la riduzione della replica dei calcoli senza sacrificare la sicurezza. La separazione, avendo il calcolo fatto in una macchina virtuale (rollup) e i risultati verificati e registrati in una blockchain, è esattamente ciò che sono i rollup.

La rete Oasis non è solo una rete che supporta nativamente i rollup, ma un’architettura ottimizzata solo per rollup. Si evita di mettere calcoli generali sul livello di consenso, e permette solo ai contratti integrati di funzionare lì. Questi contratti integrati sono accordi ponte di convalida, a cui si fa riferimento nei termini di rollup. L’obiettivo di progettazione dell’architettura Oasis era una catena modulare di blocchi Layer 1 che supporta contratti intelligenti, ma come risultato della modularità, tutti i ParatTimes sono macchine virtuali rollup Layer 2, alcuni possono affermare che lo strato di accordo Oasis è una catena di blocchi che supporta solo rollup.

In particolare, il ponte di convalida Oasis a livello di consenso utilizza una tecnica di rilevamento delle frodi nota come “discrepancy detection” per convalidare i risultati dal livello di calcolo. Questa tecnica, risultante dal rilevamento delle frodi e dalla co-progettazione dell’architettura del sistema, usa “bare metal proofs” che sono semplici e quindi più affidabili poiché ci sono meno cose che possono andare storte. Come vedremo, la semplicità dei “bare metal proofs” dà più spazio ai progettisti di Paratime: l’implementazione di un ambiente di esecuzione di contratti intelligenti in cui i contratti intelligenti sono codice nativo sandboxed diventa fattibile, dando quindi al sistema spazio per migliorare le prestazioni oltre l’esecuzione simultanea di Paratime.

Si può anche dire che Oasis è la prima rete nativa per supportare rollup. E che la nomenclatura “Layer 1”/”Layer 2" non è sufficientemente descrittiva/precisa.

Chiamatelo design convergente. Spacchettiamo cosa significa ed approfondiamo alcuni dettagli.

Caratteristiche dei rollups

I rollups sono stati sviluppati principalmente per accelerare l’elaborazione di Ethereum-Smart Contracts. Più precisamente, sono stati progettati per eseguire contratti Ethereum Smart-Contracts, ma in una macchina virtuale separata e indipendente, creata dall’Ethereum Virtual Machine (EVM) sull’Ethereum Layer 1 “Base Chain” per ridurre il carico di lavoro al livello 1. L’intera esecuzione effettiva del contratto avviene nella macchina virtuale di tipo layer 2 Rollup. L’unico lavoro svolto dalla centrale mobile sottostante consiste nel validare l’esecuzione della macchina di rollup virtuale utilizzando uno smart contracts “Validating Bridge”. Di norma, la macchina virtuale del rollup è anche un organo del CSE e, in alcuni progetti, ad esempio Arbitrum, la macchina virtuale del rollup è ottimizzata per facilitare la convalida nella catena di base. Se la validazione del primo strato è meno costosa della realizzazione del Rollup Smart Contracts direttamente nel primo strato, abbiamo un vantaggio in termini di efficienza, perché il modello del secondo strato dovrebbe essere più economico. Questo è il cuore di come i rollups raggiungono lo scaling del throughput delle transazioni.

Nota che sul Layer 1 della blockchain si possono trovare molti motori virtuali dello strato 2. Non ci sono limiti architettonici oltre alla portata di convalida di livello 1. Quanto più efficiente è il contratto di bridge validante e quanto minore è l’onere di esecuzione del contratto non-bridge smart per la blockchain Layer-1, tanto maggiore è il numero di rollups supportati. Certo, un contratto di bridge valido potrebbe essere in corso all’interno del rullo, ma ci sono dei limiti a questa proiezione che non stiamo affrontando.

Nella maggior parte dei progetti di rollup, i dati delle transazioni vengono prima inviati alla catena di base, e successivamente impegnano lo stato risultante della macchina virtuale del rollup in una transazione successiva. Questo aiuta a risolvere i problemi di disponibilità dei dati in un certo senso perché l’ordine della transazione è determinato e lo stato della macchina virtuale rollup può essere ricostruito dai dati transazionali al costo di rieseguire tutte le transazioni da quando la macchina virtuale rollup è stata creata. Ad esempio, i dati transazionali sono crittografati allo stesso modo dello stato di una macchina virtuale, riducendo il costo di archiviazione Layer 1 e separando la disponibilità fornita dalla memorizzazione off-chain dall’autenticità dei dati. Poiché l’accesso ai dati di input necessari per la convalida richiede tempo, la convalida può essere ritardata se vi è un problema di throughput con la disponibilità dei dati temporaneamente.

Ci sono due forme di verifica della macchina virtuale con rollup:

• Rollup ottimista: dove i risultati della presunta esecuzione sono pubblicati e possono essere contestati.
• Zk rollup utilizza SNARK per costruire una prova di correttezza.

La differenza fondamentale è che i roll-up ottimisti utilizzano ‘fraud proofs’, in cui le parti in causa raccolgono prove per dimostrare che la prestazione dichiarata è errata o fraudolenta, e i zk rollups usano la ‘prova di validità’, che gli esecutori pubblicano con lo stato della VM del rollup, e lo Smart contract del bridge validante, che verifica la validità della prova. In entrambi i casi, il tempo è necessario per permettere che altri partecipanti vedano il nuovo stato e/o scoprano che lo stato non è corretto e costruiscano prove di frode; o di eseguire un algoritmo di verifica della prova per respingere la prova presunta quando non è corretto, nel caso di un rullo zk. Anche se questa può sembrare una piccola differenza, in entrambi i casi, è necessario fare un lavoro per costruire la prova di frode o per verificare che la prova di equità è corretta. La differenza è che di solito la prova di frode richiede una transazione da eseguire nuovamente, mentre la prova di validità deve essere meno costoso, utilizzando tecniche crittografiche (puntelli; Snarks). In pratica, le tecniche crittografiche comportano costi generali significativi e non generano (ancora) l’esecuzione arbitraria di contratti intelligenti.

Si noti che in generale, la macchina virtuale rollup non deve essere compatibile con Ethereum, né il meccanismo di validazione deve funzionare sopra Ethereum. Tutto ciò che serve è un substrato di calcolo decentralizzato che estende la sua sicurezza alla sicurezza di una macchina virtuale rollup. Naturalmente, il fatto che una VM sia compatibile con Ethereum rende facile spostare un EVM esistente.

Gusti delle prove di frode

Per comprendere perché lo sviluppo congiunto dell’identificazione delle frodi e dell’architettura del sistema della rete Oasis ha portato a un sistema più efficace e generale, dobbiamo innanzi tutto discutere i diversi tipi di prove di frode.

Prove di simulazione

Sistemi di rollup ottimistici come Trumarbi e Optimism funzionano in modo tale che gli sfidanti che sostengono che il calcolo sia sbagliato devono dare l’esempio della frode. L’evidenza di frode è intesa a dimostrare che il calcolo che ha dato luogo a risultati sbagliati si discosta da un’esecuzione corretta della macchina virtuale in un’unica istruzione IM, utilizzando un simulatore di rollup di macchine virtuali in funzione sulla catena di base; “facile da controllare”.

Non è facile, è incredibilmente complesso. La frase di comando per la macchina virtuale è pertanto strettamente collegata all’implementazione del contratto ponte da convalidare. La chiave per verificarne l’esecuzione consiste nel non simulare l’intera progettazione del rullaggio virtuale, poiché ciò comporterebbe un costo enorme per il gas. Invece, si suppone che lo sfidante fornisca una prova incontrovertibile che l’asserzione dell’esecutore dello stato della macchina virtuale rollup in uscita, indicando l’esatta istruzione della macchina virtuale che non è stata eseguita correttamente, utilizzando la bisezione che confronta gli stati di esecuzione e le prove di Merkle. La compilazione della certificazione può essere effettuata offline e la convalida deve essere effettuata solo online dal contratto ponte di validazione — controllando che l’effettiva esecuzione dell’istruzione VM indicata non sia conforme alla semantica VM.

A tal fine, il contratto ponte di validazione deve essere in grado di simulare ogni istruzione di rollup della VM. È tecnicamente difficile garantire che il simulatore sia corretto e semanticamente equivalente alla VM effettiva. La complessità del simulatore dipende dalla complessità del set di istruzioni della VM, ma la costruzione di un simulatore accurato e robusto come Arbitrum e Optimism richiederà probabilmente anni di lavoro.

I candidati che sostengono la frode sono tenuti a fornire prove di frode insieme a nuove affermazioni circa il corretto stato dei risultati. Se una falsa traccia di corsa F devia dalla traccia di corsa corretta ad un certo tempo t ᶠ, uno sfidante può costruire una traccia di esecuzione C che devia dalla traccia corretta in un secondo momento passo t ᶜ > t ᶠ, effettivamente discernerla in F, ma di per sé, fornire falsi risultati. Pertanto, la prova di frode contro F non dimostra che C è corretto, e se la sfida riesce con un risultato diverso, il challenge clock deve essere resettato per consentire a C di sfidare. Una sfida riuscita non fornisce la prova definitiva che i risultati associati a C sono corretti a meno che non siano effettuati ulteriori controlli di convalida da parte di altri validatori.

Il vantaggio della certificazione di simulazione è che è accurata e, supponendo che tutto funzioni, si sa dove la semantica della VM è stata rotta, quindi si può essere sicuri se i risultati sono imprecisi. Si noti, tuttavia, che un ponte di verifica è un contratto intelligente che gira su una catena di blocchi, e la correttezza del risultato è solo stocastica, indipendentemente dal fatto che il consenso sulla sua esecuzione si verifichi sulle catene Pow o POS. (Nel primo caso, la probabilità di un attacco di successo è del 50% + ε, nel secondo caso, la probabilità che 2/3 dell’importo totale dell’investimento diventi sotto il controllo degli attori bizantini). In entrambi i casi, possono verificarsi guasti modalità comuni, come vulnerabilità zero-day nel codice della catena di blocchi sottostante o nel sistema operativo host, che consente guasti comuni. ) Poiché la ricerca di prove di frode è stocastica, il vantaggio di avere prove deterministiche è più teorico che realistico.

Bare Metal Proofs

Che cosa intendiamo con il termine “Bare Metal Proofs”? Diagramma di prova del metallo nudo:

• Deve essere molto resistente. Le prove possono essere probabilistiche (come ZKP), con la capacità di selezionare i parametri di sicurezza in modo che la probabilità di errore sia vicina a zero quanto necessario.
• Dovrebbe funzionare con qualsiasi macchina virtuale (deterministica) senza alcun adattamento specifico, comprese le macchine virtuali, che sono semplici estensioni di architetture di set di istruzioni comuni come x86–64. Il sistema dovrebbe essere in grado di eseguire binari di codice nativo in Sandbox (con limitazioni per evitare comportamenti non deterministici) a piena velocità, “nuda”, con estensioni di istruzioni di blocco come chiamate di funzione.

In particolare, questi requisiti significano che un sistema basato su prove di Bare Metal sarà molto più semplice di un sistema basato su prove di simulazione. Un contratto ponte convalidato non ha bisogno di accedere allo stato macchina virtuale rollup perché la verifica dello stato richiede la conoscenza del tipo di strutture dati Merclized in uso e di come sono controllati, che è specifico per la macchina virtuale rollup: ciò introdurrebbe la necessità di interfacce/meccanismi per la blockchain sottostante al fine di avere accesso allo stato di rollup e rendere più complesse le interfacce dei moduli. Inoltre, non è necessaria una simulazione specifica della VM a livello di istruzione. Evitare la complessità (non necessaria) è un importante obiettivo di sicurezza perché la complessità crea errori.

È interessante notare che, richiedendo una prova del sistema di frode per essere più generale, si allenta anche i vincoli di progettazione della macchina virtuale rollup. Anche se possiamo continuare a scrivere contratti intelligenti in un linguaggio che compila per byte di codice e l’uso di interpreti di codice byte come una macchina virtuale (che rende più facile per eseguire singoli passaggi e raccogliere Merclized eseguire tracce), non siamo più limitati a questo approccio. Tecniche più avanzate ed efficienti possono essere applicate in modo che vi sia ampio spazio per migliorare le prestazioni dei contratti intelligenti. Ad esempio, le istruzioni/byte della macchina virtuale possono essere compilate sul codice macchina per essere eseguite in Software Fault Isolation (SFI) Sandbox, come Rlbox, ottenendo prestazioni di codice quasi native.

Oasis Paratimes

Nel caso di Oasis, separare l’esecuzione di Smart Contract e consenso significava finire con un design simile al rollup. C’è una Paratime compatibile con l’EVM che esegue Emerald Paratime e altri Smart Contracts a base di Rust, tutti che utilizzano un unico Smart Contract di validazione integrato e orientato agli oggetti. Nessun altro blocco limita la catena di base all’esecuzione di contratti di convalida di rollup.

1.1 Identificazione delle discrepanze Prove di frode

Abbiamo già detto che Oasis si limita ad attuare contratti di convalida di tipo integrato nella fascia di consenso. Al momento si tratta di un ponte di convalida “bare metal fraud-proof”, in cui usiamo una tecnica chiamata “discrey pancy detection” per rilevare le frodi e, se questa viene riconosciuta, “discrey resolution” per risolverle. L’idea di base alla base del “riconoscimento discreto” è che possiamo scoprire la frode in modo più efficace che correggere, proprio come nella teoria di codificazione si possono usare ulteriori bit ridondanti per rilevare più errori di quanti si possano correggere. Supponendo che un aggressore che compromette una nota di esecuzione non contribuisca a compromettere gli altri, ad esempio corrompendo il personale operativo, indovinando le password, ecc. Possiamo usare dei comitati di calcolo più piccoli, che devono tutti raggiungere lo stesso risultato nell’esecuzione dei contratti intelligenti.

Penso che la sicurezza pratica di questo progetto sia più facile da capire. Il progetto basato sul comitato fornisce la dimensione del comitato, un parametro di sicurezza pubblicamente noto, ed esegue i contratti in modo semi-sincrono, in modo che gli utenti conoscano sia il numero di controlli incrociati sia quando i controlli incrociati sono completi, i membri del comitato hanno SLA e possono essere troncati a causa della mancanza di disponibilità. Questo è in contrasto con un rollup ottimista in cui gli utenti attendono un numero sconosciuto di potenziali sfide per un certo periodo di tempo o convalidare i propri calcoli. Questo modello non elimina la presentazione di certificati fraudolenti da parte di non membri del comitato, e anche i certificati fraudolenti “tardivi” da parte di non membri del comitato possono essere trattati facendo riferimento alla sezione Checkpoint di questo articolo qui sotto, così la convalida non è chiusa.

Se si verifica una collisione, viene eseguita la fase di risoluzione/recupero della collisione. Per quanto riguarda i risultati dei comitati semisincroni, un comitato più ampio sarà immediatamente eseguito al fine di determinare quale sia il risultato corretto. Il comitato di risoluzione è molto più grande e, ad esempio, è possibile che l’intero comitato di accordo attui una soluzione, quindi questo risultato sarà affidabile. Questo è più costoso sia in termini di calcoli replicati e comunicazioni, ma va bene: Dovrebbe essere molto raro e il costo è ammortizzato nella maggior parte dei casi in cui non è richiesta alcuna risoluzione.

I guadagni di prestazioni sono causati dall’uso dell’ottimizzazione del percorso veloce/lento comunemente usata nella progettazione del sistema. Il caso probabile di non-fraud/non-discrepancy è trattato efficientemente e il caso improbabile dI dover determinare quale di due o più risultati discrepanti è corretto può essere più lento. Vedere qui per i dettagli sui parametri di sicurezza.

Il livello di consenso Oasis non supporta i contratti intelligenti generici. Invece, abbiamo supportato la funzionalità del ponte di convalida, che altrimenti viene eseguito come un contratto intelligente in un rullup basato su Ethereum. Utilizziamo Gap Detection per convalidare i risultati dei nodi nello strato Paratime perché è più efficiente e più generale.

Al fine di capire perché il gap detection è più efficiente, considereremo la quantità di tempo necessario prima della selezione casuale dei membri del comitato di calcolo, che può consentire all’adwersor di compromettere i calcoli. Se, su un totale di 100 candidati, un massimo di 33 sono bizantini e ne selezioniamo a caso 20 per servire da comitato di calcolo, anche se le nuove configurazioni del comitato sono state selezionate ad un tasso di 100.000 all’ora, L’avversario che controllava questi 33 nodi bizantini avrebbe dovuto aspettare 1.066 anni prima che fosse eletto un comitato completamente bizantino, che potrebbe essere usato per attaccare il sistema. Un tipico schema bizantino di tolleranza ai guasti può usare la replicazione a 100 lati per raggiungere il consenso; qui replichiamo i calcoli solo 20 volte.

I dettagli dell’analisi tecnica per i calcoli e il motivo per cui l’armatura discreta è più efficiente sono riportati nell’allegato alla nostra Whitepaper.

Dato che lil rilevamento della discrepanza confronta solo i risultati del calcolo, è più generale di qualsiasi altro schema che richieda la comparazione delle condizioni intermedie attraverso un’esecuzione graduale, come avviene per la maggior parte dei concetti di rollup ottimistici. Il lavoro necessario per convalidare il contratto ponte all’interno dello strato di consenso attraverso la stesura di carri armati discreti è limitato, per cui è facile scalare il sistema in modo arbitrario, utilizzando diverse paratimes contemporaneamente all’esecuzione parallela.

1.2 Estensibilità per altre procedure di certificazione della frode/validità

Si noti che lo strato di consenso della rete Oasis, sebbene comprenda una copertura funzionale discreta, è tuttavia ampliabile dal punto di vista architettonico e consente l’applicazione di altre procedure di convalida per l’esecuzione del rollup. Non vediamo la necessità di farlo.

Una verifica zk-rollup di un rapporto zk-rollup sarebbe un’ottima aggiunta, poiché i ponti di validazione incorporati sono stati implementati nel Go, dovrebbero essere molto più veloci di uno smart contracts di solidità.

Vi sono altre variazioni/dimensioni nel campo delle prove di frode che non sono state trattate in questa sede. Ulteriori informazioni sul design delle prove di frode sono disponibili qui.

Checkpointing

Individuando le discrepanze, è possibile impostare i parametri di dimensione del comitato in modo da poter essere sicuri che la possibilità di compromesso per l’intera commissione possa essere ignorata. Restano ancora due questioni.

1. Rilevazione di discrepanza — solo per il comitato di calcolo, non completamente aperto. Questo perché è necessario un limite di risorse simile a pile per i nodi di elaborazione candidati per prevenire gli attacchi Sybil.
2. I guasti Common-Mode Failures, come gli errori di programmazione nel codice di Oasis Network o nel kernel di Linux, potrebbero permettere ad un avversario di utilizzare un compromesso zero-day per prendere il controllo di tutti i nodi di calcolo — e di consenso! — della rete.

Si prega di notare che gli errori di programmazione, naturalmente, esistono su qualsiasi rete e non sono specifici di Oasis. Infatti, crediamo che la qualità del codice e il processo di revisione di Oasis siano i migliori della concorrenza.

Affrontare le vulnerabilità zero-day è difficile. Infatti, come per tutti i sistemi software, nessuna catena di blocchi ha una soluzione generale oltre alla possibilità di hard forking. Oasis distingue tra la determinazione dell’ordine delle transazioni e la determinazione del risultato delle transazioni, consentendo a chiunque di opporsi al risultato della transazione, consentendo così un fallimento catastrofico (come il compromesso di tutti i comitati, lo sfruttamento delle vulnerabilità zero-day, il fallimento del modo comune, ecc. Scenario estremamente improbabile).

Cosa significa? Aggiungiamo una registrazione sicura delle password dei punti di controllo periodici e delle transazioni degli ordini. Questi dati facilitano il ripristino di una transazione da un noto, buon punto di controllo dopo un guasto catastrofico viene identificato attraverso una sfida e affrontarlo.

La registrazione deve essere monotona / definitiva perché includiamo attacchi a lungo raggio / perdita di controllo delle chiavi crittografiche come potenziali modalità di guasto. Questa proprietà può essere ottenuta scrivendo il registro su registri distribuiti di sola appendice, come altri blockchain, ad es. Ethernet; scrivendo su supporti fisicamente aggiunti, ad es. una stampante con alimentazione continua; scrivendo su supporti registrabili (CD-R/DVD-R); scrivendo su supporti, Che vengono periodicamente copiati su servizi di backup off-line, ecc. la scrittura su Ethereum utilizzerebbe la finalità di Ethereum per contrassegnare la data di generazione del registro, mentre la scrittura su altri meccanismi di sola appendice richiederà la verifica, ad es. confrontando copie indipendenti, che il supporto non sia una nuova copia alterata del registro legittimo. Si veda il documento Shadows of Finality (in arrivo) per una discussione più approfondita sulla finalità della sequenza di transazioni e sulla finalità dello stato.

Una volta completato questo processo, chiunque può contestare i risultati del livello di calcolo, anche dopo che il sistema di rilevamento delle discrepanze ha accettato i risultati. Questo significa che fallimenti catastrofici, come il comitato tutto bizantino o il gap zero-day, possono essere gestiti se rilevati in modo tempestivo. Finché vi è un importante punto di controllo in uno stato che precede un fallimento catastrofico, abbiamo una buona condizione nota da usare come base per il recupero.

La strategia proposta per affrontare errori catastrofici è quella di rispettare la sequenza delle operazioni. Ciò significa che se uno sfidante dimostra che c’è stato un cambiamento di stato errato, possiamo riprogrammare le transazioni registrate che sono state presentate dopo un buono stato noto per calcolare la corretta situazione attuale, dove la replicazione/verifica è impiegata per quanto necessario. Come per l’individuazione di discrepanze che permette un percorso veloce efficiente per il caso di assenza di discrepanza contro uno schema più costoso per il caso infrequente in cui vi sono discrepanze, il checkpoint e il replay possono essere costosi da ripristinare in caso di avarie catastrofiche, in quanto tali disastri sono considerati estremamente improbabili.

Sintesi

L’architettura della rete Oasis è il risultato di un co-design tra il rilevamento delle frodi e l’architettura del sistema. Esiste una separazione modulare dei compiti tra il calcolo e il consenso, tra cui un semplice ed efficiente metodo di rilevamento delle frodi Bare Metal.

I vantaggi dell’architettura di Oasis sono:

• Un’architettura pulita e modulare che rende il design più comprensibile e comprensibile rispetto al design monolitico. La modularità porta anche ad applicazioni più pulite, che facilitano la valutazione della sicurezza.
• Efficace individuazione delle frodi con parametri di sicurezza espliciti che consentano ai designer di Paratime di scegliere parametri adeguati per i casi di utilizzo previsti.
• L’evidenza di frodi bare-metal consente lo sviluppo futuro di ambienti di esecuzione di contratti intelligenti ad alte prestazioni, come il codice nativo Sandboxed, rendendo possibili in futuro contratti intelligenti con l’elaborazione o l’uso intensivo di dati.
• Gli utenti sanno che è stata fissata una soglia inferiore per la verifica indipendente, piuttosto che aspettare che i validatori siano disponibili/operativi durante il periodo di sfida, come nel caso di Rollup ottimisti.

Il risultato è che l’Oasis Network è una catena di bloccaggio in stile rollup, dove il livello di consenso funziona solo convalidando i contratti di bridge. Paratimes multipli — macchine virtuali indipendenti — sono stati distribuiti con successo in cima allo strato di consenso Oasis. Attualmente, Paratime Esmerald fornisce un’esecuzione intelligente del contratto compatibile con EVM, e ParaTime Cipher fornirà un ambiente di performance del contratto intelligente e confidenziale una volta rilasciato nel Q1 2022.