Fat Contract: Introdurre il Calcolo Computazionale Off-chain negli Smart Contract
Scritto da Shelven Zhou, Ricercatore Capo di Phala Network
Articolo Originale qui
Materiale dopo la conferenza WASM 2022
Cos’è il Calcolo Computazionale Off-Chain?
Prima di introdurre il calcolo computazionale off-chain, vediamo di conoscere il modello di computazione on-chain adottato da quasi tutti gli smart contract esistenti.
La Figura 1 mostra il modello di esecuzione on-chain. L’esecuzione on-chain è deterministica: la transazione viene eseguita da tutti i nodi, che devono concordare lo stato finale.
Tali requisiti di coerenza dello stato introducono inevitabilmente delle limitazioni: sono lenti e costosi. Inoltre, operazioni come le richieste di rete sono proibite perché possono portare a stati finali diversi su nodi diversi (le richieste di rete possono fallire su alcuni nodi e avere successo su altri).
L’esecuzione off-chain è stata proposta per la prima volta per soddisfare l’esigenza degli Oracoli, ovvero per introdurre un input off-chain come il prezzo di BTC in tempo reale da alcuni exchange durante l’esecuzione. A differenza dell’esecuzione on-chain, l’esecuzione off-chain è condotta da un numero limitato (a volte uno solo) di lavoratori off-chain, quindi migliora anche le prestazioni e i costi. Ora i nodi devono solo verificare che i risultati dell’esecuzione siano realmente prodotti da questi lavoratori (è un po’ come i rollup di una singola transazione).
Questo modello, purtroppo, presenta anche dei limiti. La fiducia dei lavoratori off-chain è implicita in questa soluzione, poiché i nodi on-chain possono solo sapere che questi lavoratori producono i risultati, ma non che utilizzano i “giusti” input off-chain ed eseguono l’esecuzione in modo fedele. Per questo motivo una soluzione di questo tipo è solitamente utilizzata solo dai team di sviluppo della chain che ospitano i propri lavoratori.
Un passo verso un’infrastruttura off-chain trustless
La chiave del problema di cui sopra è trovare i lavoratori “fidati” fuori dalla chain, e ci sono alcuni candidati come metodi di calcolo verificabili come zero-knowledge proof, o soluzioni basate su hardware come il secure enclave.
Phala è un cloud computing trustless i cui nodi miner sono tutti Secure Workers che utilizzano secure enclave. Il secure enclave è solitamente implementato come sottosistema sicuro dei moderni processori e fornisce due importanti garanzie di sicurezza: la riservatezza e l’integrità dell’esecuzione. Ciò significa che gli operatori malintenzionati, anche con accesso fisico alle macchine, non possono leggere lo stato in memoria (poiché è criptato da chip dedicati), né manipolare l’esecuzione del programma per fornire risultati falsi. In questo modo, anche i singoli sviluppatori possono affittare i propri lavoratori off-chain da Phala blockchain e goderne i benefici.
Questo ci spinge a progettare un nuovo modello di esecuzione del contratto, il Fat (PHAt) Contract, in grado di eseguire calcoli off chain. Vale la pena notare che abbiamo deliberatamente scelto di non migrare semplicemente l’EVM nel secure enclave, poiché è stato progettato per l’esecuzione on chain e quindi è difficile da estendere.
Caratteristiche e Scenari Applicativi
Il Fat Contract è pensato per essere scritto con ink! di Parity. Dal punto di vista degli sviluppatori, la differenza tra ink! e il Fat Contract è minima, fatta eccezione per le estensioni che forniamo al Fat Contract. La differenza fondamentale è dove vengono eseguiti: ink! viene eseguito dai nodi Substrate e Fat Contract in pRuntime (runtime personalizzato da Phala) nei nostri Secure Worker off-chain. Ovviamente, Fat Contract gode di tutti i vantaggi menzionati sopra.
Con Fat Contract è ora possibile implementare con un solo contratto le applicazioni che prima richiedevano la creazione di una nuova catena.
Il modello di Fat Contract
Il principio di progettazione di Fat Contract è semplice: pur supportando la logica di esecuzione legacy on-chain, cerca di fornire un ambiente di esecuzione off-chain pienamente funzionale con privacy, alte prestazioni e caratteristiche necessarie come l’accesso a Internet e l’archiviazione. Il nostro punto di vista è che solo una piccola parte dello stato (come il saldo dei token e la proprietà di NFT) nelle DApp ha davvero bisogno di essere conservato on chain, per questo incoraggiamo gli sviluppatori a implementare la maggior parte della loro logica off chain.
Le chiacchiere sono a buon mercato e lasciate che vi mostri un po’ di codice. Questo è il contratto Hello World di ink!. Come promesso, è possibile eseguirlo in Phala senza alcuna modifica. In questo contratto, lo stato del contratto (on-chain) è descritto dalla variabile value. In base al fatto che lo stato sarà cambiato, le funzioni seguenti sono divise in due classi, mutabili (funzione flip()) e immutabili (funzione get()). Di conseguenza, le richieste dell’utente a queste funzioni vengono suddivise in Comandi, che vengono inviati alle funzioni mutabili e modificano lo stato della chain, e Query, che vengono inviate alle funzioni immutabili e lasciano invariato lo stato della chain.
Tra queste, Command segue il tradizionale percorso di esecuzione off-chain, tranne per il fatto che è criptato e può essere decriptato solo in secure enclave. Ciò significa che Command, come le normali transazioni, deve essere pubblicato on-chain, impacchettato nel blocco e quindi sincronizzato con i lavoratori off-chain per l’esecuzione. Può essere un collo di bottiglia per le prestazioni, quindi deve essere usato con cautela.
La query, invece, è molto diversa. In primo luogo, viene inviata direttamente al Secure Worker, proprio come una comunicazione client/server, quindi è priva della latenza delle transazioni blockchain e della tassa di gas per l’esecuzione (si affitta il worker invece di pagare per ogni istruzione nell’elaborazione della Query). In secondo luogo, la Query è destinata a modificare lo stato locale ( off-chain). Inoltre, le conferiamo la capacità di leggere/scrivere la cache locale e di inviare richieste HTTP, il che significa che è possibile utilizzare direttamente tutti i servizi web esistenti, compresi i feed di dati, le API dei bot di Telegram/Discord, lo storage online come AWS e altro ancora.
In altre parole, quando si scrivono funzioni per Query, è come se si scrivesse un normale programma server invece di uno smart contract. Questa volta, però, il vostro “programma server” viene eseguito su un vero cloud decentralizzato e può utilizzare la blockchain come radice di fiducia: a ogni Fat Contract viene assegnata una coppia di chiavi con la chiave pubblica pubblicata on chain. Questa coppia di chiavi prova l’identità del programma e può essere utilizzata per firmare qualsiasi messaggio per dimostrare che è stato prodotto da un contratto certificato e che quindi ci si può fidare. Ciò consente di effettuare operazioni di attestazione, che sono alla base di Oracle, dell’identità decentralizzata e di altre interessanti applicazioni Web3.
Perché non sporcarsi le mani e provare personalmente Fat Contract?
Altre Letture
A proposito di Phala
Phala Network si prefigge di risolvere il problema della fiducia nel cloud computazionale.
Organizzando una rete mondiale decentralizzata di nodi per il calcolo, offre servizi performanti senza appoggiarsi su nessun grande cloud provider. I worker Phala fanno girare i programmi in Secure Enclaves, una tecnologia votata alla privacy presente in alcuni moderni processori, rendendo possibile l’esecuzione confidenziale e versatile di codice. Insieme, questo crea l’infrastruttura per un cloud computing potente, sicuro e scalabile, senza riporre la propria fiducia in soggetti terzi.
🍽 — Subscribe | Website | Twitter | Github
🥤 — Discord | Forum | Telegram |Italiano |Français | Persian | Korean
