Analisi tecnica dell'architettura JAM e dell'esecuzione sharding in Polkadot

1. Contesto preliminare In questa sezione vengono presentati i seguenti concetti, la cui comprensione è presupposta. La blockchain come funzione di transizione di stato (State Transition Function) Comprensione dello "Stato" (State) Entrambi i concetti sono spiegati qui. Sicurezza economica (Economic Security) e Proof of Stake Contenuti spiegati nella conferenza PBA e nei video.

2. Introduzione: Polkadot 1.0 Innanzitutto, riassumiamo le caratteristiche più innovative di Polkadot 1.0: Aspetti sociali: Polkadot può essere visto come una grande DAO in tutti gli aspetti. La governance di rete, inclusi gli aggiornamenti runtime senza fork (fork-less), avviene interamente on-chain in modo auto-eseguito. La SEC (Securities and Exchange Commission) degli Stati Uniti considera DOT un software e non un titolo. La maggior parte dello sviluppo della rete è gestita dal Polkadot Fellowship, piuttosto che da una società contabile (es. Parity). Aspetti tecnici: Sicurezza condivisa ed esecuzione sharding (tecnica di divisione dei dati della rete blockchain in "shard" per l'elaborazione). Utilizzo di un meta-protocollo basato su WASM. Salvando il codice blockchain nello stato sotto forma di bytecode, la maggior parte degli aggiornamenti può procedere senza fork, rendendo possibile non solo lo sharding, ma anche lo sharding eterogeneo in Polkadot. Per maggiori dettagli, fare riferimento all'eterogeneità. Esamineremo ora in dettaglio l'esecuzione sharding.

3. Il cuore dello sharding: il Core In questo articolo ci occupiamo di reti L1 che ospitano diverse L2 o altre "blockchain", come Polkadot o Ethereum. Di conseguenza, considereremo L2 e Parachain come sinonimi. Il problema fondamentale della scalabilità delle blockchain può essere riassunto come segue. Esiste un gruppo di validatori, e il codice che eseguono è garantito sicuro dal concetto di crittografia economica noto come Proof of Stake. I validatori devono sostanzialmente rieseguire l'intero lavoro l'uno dell'altro. Cioè, fintanto che questo sistema costringe tutti i validatori a rieseguire sempre tutto, non può scalare. È necessario notare che, fintanto che il principio di riesecuzione menzionato nel paragrafo precedente rimane valido, in questo modello l'aumento del numero di validatori non comporta un aumento del throughput del sistema. La descrizione sopra riportata descrive le caratteristiche delle blockchain monolitiche, in contrapposizione allo sharding. Gli input (es. blocchi) vengono elaborati uno per uno da tutti i validatori della rete. Se in questo sistema l'L1 desidera ospitare più L2, tutti i validatori devono rieseguire il lavoro di tutte le L2. Naturalmente, in questo tipo di sistema non ci si può aspettare scalabilità. Esistono modi per aggirare questo problema, come gli Optimistic Rollup, che limitano la riesecuzione (o fraud proof) solo ai casi in cui qualcuno afferma che si è verificata una frode. I Rollup basati su SNARK si basano sul fatto che verificare una prova SNARK costa significativamente meno che generarla, permettendo a tutti i validatori di verificare le prove SNARK. Per maggiori dettagli, consultare la "Scalability Space Map" nell'appendice. La soluzione semplice dello sharding consiste nel dividere il gruppo di validatori in sottoinsiemi più piccoli, affinché questi piccoli sottoinsiemi rieseguano i blocchi L2. Qual è il problema di questo approccio? Siamo sharding l'esecuzione e la sicurezza economica della rete. La sicurezza della L2 è già più debole rispetto all'L1, e più frammentiamo il gruppo di validatori in più shard, più la sicurezza deve necessariamente diminuire. A differenza degli Optimistic Rollup, che non possono rieseguire ogni transazione, Polkadot è stato progettato per shardingare le transazioni. Questo permette ai sottoinsiemi di validatori di rieseguire i blocchi L2, fornendo a tutti i partecipanti alla rete una prova crittografica che la validità del blocco L2 è sicura quasi quanto se l'intero gruppo di validatori avesse rieseguito il blocco. Ciò è reso possibile dal meccanismo ELVES recentemente annunciato. ELVES può essere visto anche come un meccanismo "Cynical Rollup". I validatori confermano la validità dei blocchi L2 con altri validatori ripetendo il processo più volte, confermando che c'è un'alta probabilità che il blocco L2 sia effettivamente valido. In caso di controversia, l'intero gruppo di validatori viene chiamato a partecipare in breve tempo; questo contenuto è ben spiegato nell'articolo di Rob Habermeier, co-fondatore di Polkadot. È grazie al meccanismo ELVES che Polkadot può possedere entrambe le caratteristiche, solitamente trattate come mutuamente esclusive, di "esecuzione shardingata" e "sicurezza condivisa", e questo è il principale risultato tecnico lasciato da Polkadot 1.0 in termini di scalabilità. Passiamo ora alla metafora del "Core". Una blockchain con esecuzione shardingata può essere paragonata a una CPU. Proprio come una CPU possiede molteplici core che possono elaborare istruzioni in parallelo, anche Polkadot può elaborare blocchi L2 in parallelo. Per questo motivo in Polkadot la L2 è chiamata parachain [1], e l'ambiente in cui un sottoinsieme di validatori esegue un singolo blocco L2 è chiamato "Core". Ogni core può essere riassunto come "un gruppo collaborativo di validatori". Se una blockchain monolitica può elaborare un solo blocco in qualsiasi time slot, Polkadot può elaborare un blocco relay chain e un blocco parachain per core e per time slot.

3.1. Eterogeneità Finora abbiamo parlato solo di scalabilità ed esecuzione shardingata in Polkadot, ma un fatto importante è che ogni shard di Polkadot è un'applicazione completamente distinta [2]. Questo è stato implementato utilizzando un meta-protocollo memorizzato come bytecode; un meta-protocollo è un protocollo in cui la definizione della blockchain è memorizzata nello stato della blockchain sotto forma di bytecode. In Polkadot 1.0 è stato utilizzato WASM come bytecode, mentre in JAM è stato adottato PVM/RISC-V. In definitiva, questo è il motivo per cui Polkadot è chiamato blockchain con sharding eterogeneo. Ogni L2 può essere considerata un'applicazione completamente diversa e distinta.

4. Polkadot 2.0 Polkadot 2.0 pone l'accento sul rendere l'utilizzo dei core più flessibile. Nel modello Polkadot tradizionale, un core poteva essere affittato per una volta ogni 6 mesi fino a un massimo di 2 anni. Questo è un modello adatto per le aziende con molte risorse disponibili, ma non per i piccoli team. La funzione che rende l'utilizzo dei core di Polkadot più flessibile è chiamata "agile coretime". Nell'agile coretime, è possibile noleggiare un core di Polkadot alla volta da un singolo blocco fino a un massimo di un mese, e per i noleggi a lungo termine viene garantito anche un prezzo massimo (price cap). Polkadot 2.0 è attualmente in corso insieme ad altre funzionalità, quindi qui ometteremo ulteriori spiegazioni.

5. Dentro il Core vs. On-Chain Per comprendere JAM (Polkadot 3.0), è necessario capire cosa succede nel core di Polkadot quando entra un blocco L2. Quanto segue include contenuti molto semplificati. Il core è fondamentalmente composto da un gruppo di validatori. "Inviare dati al core" significa che i dati sono stati consegnati al gruppo di validatori.

6. Un blocco L2 e un sottoinsieme dello stato L2 corrispondente vengono trasmessi al core. Questi sono gli unici dati necessari per elaborare il blocco L2 [3].

7. Il sottoinsieme di validatori che compone il core riesegue il blocco L2 ed esegue le attività relative al consenso.

8. I validatori del core rendono i dati necessari per la riesecuzione disponibili ad altri validatori (fuori dal core). Secondo le regole ELVES, più validatori potrebbero voler rieseguire il blocco L2, e questi dati sono necessari a tal fine. È importante ricordare che tutte queste attività avvengono esternamente, separatamente dal blocco principale e dalla funzione di modifica dello stato di Polkadot. Tutti i processi descritti finora avvengono all'interno del core e del livello di disponibilità dei dati.

9. L'ultimo stato trasmesso dalla L2 viene salvato nello stato della relay chain di Polkadot. Questa operazione è molto meno costosa rispetto alla riesecuzione del blocco L2, influisce sullo stato Polkadot principale, viene registrato nel blocco Polkadot ed è elaborato da tutti i validatori Polkadot. Oltre a quanto spiegato in precedenza, approfondiamo ciò che fa Polkadot: Dal punto 1 abbiamo visto che in Polkadot esiste un metodo di elaborazione diverso dalla solita funzione di transizione di stato della blockchain. Generalmente, quando tutti i validatori della rete eseguono il lavoro, lo stato della blockchain principale viene aggiornato di conseguenza; questo viene chiamato operazione on-chain. Questa operazione corrisponde al punto 3. Tuttavia, ciò che accade all'interno del core (punto 1) è diverso. Questo nuovo metodo di calcolo blockchain viene chiamato elaborazione in-core (in-core execution). Dal punto 2 si può dedurre che Polkadot fornisce già un livello nativo di disponibilità dei dati (DA), e la L2 utilizza automaticamente la DA per un certo periodo di tempo come prova di elaborazione. Inoltre, la quantità di dati che può salire su questo livello DA [4] è fissata, e questi dati sono sempre la prova necessaria per rieseguire il blocco L2. Inoltre, il codice della parachain non può leggere i dati dal livello DA. Quanto sopra serve da base per comprendere le funzionalità di JAM. Riassumendo: Elaborazione in-core: avviene all'interno del core. Ha abbondanza di risorse e scalabilità, e basata sulla crittografia economica e su ELVES, ha la stessa sicurezza dell'"elaborazione on-chain". Elaborazione on-chain: è il lavoro dei validatori. La sicurezza è mantenuta da validatori con incentivi economici, ed è più costosa e limitata perché tutti elaborano tutto. Disponibilità dei dati: è quando i validatori Polkadot forniscono dati disponibili per un certo periodo ad altri validatori.

10. JAM (Polkadot 3.0) Se hai capito le spiegazioni precedenti, il concetto di JAM sarà ancora più chiaro. JAM è pesantemente influenzato da Polkadot, è completamente compatibile con esso, ed è un nuovo protocollo che mira a sostituire la relay chain di Polkadot e rendere l'uso dei core fondamentalmente non opinabile (un-opinionated [5]). JAM si basa su Polkadot 2.0. Mira ad aumentare l'usabilità dei core Polkadot in modo fondamentalmente più flessibile e non opinabile rispetto all'agile coretime. In Polkadot 2.0, l'allocazione dei core L2 è più fluida. Il punto chiave di JAM è che qualsiasi applicazione, non limitata al formato blockchain/L2, può essere distribuita su un core Polkadot. Questo è possibile principalmente perché fornisce agli sviluppatori i tre elementi descritti nella sezione precedente: elaborazione in-core e on-chain, e disponibilità dei dati. In altre parole, JAM fornisce agli sviluppatori le seguenti capacità: Possibilità di programmare le attività svolte in-core e on-chain. Possibilità di leggere e inserire dati arbitrayi nel livello DA Polkadot. Fin qui abbiamo esaminato i contenuti di base della direzione intrapresa da JAM. Naturalmente, molte parti sono state semplificate e il protocollo è in continua evoluzione. Basandoci sulle spiegazioni finora fornite, esamineremo il contenuto di JAM in modo più dettagliato.

6.1. Servizi e Work-Item Nel sistema JAM, ciò che veniva chiamato L2/Parachain diventa Servizio (Service), e i blocchi/transazioni diventano Work-Item o Work-Package. Va specificato che un work-item appartiene a un servizio, e un work-package si riferisce a un gruppo di work-item. Entrambi i termini sono stati scelti come termini generici per includere casi d'uso non limitati alla blockchain/L2. Un servizio può essere descritto da tre punti di ingresso, due dei quali sono fn refine() e fn accumulate() [6]. Il primo descrive ciò che fa il servizio in-core, il secondo descrive ciò che fa il servizio on-chain. Infine, i nomi di questi due punti di ingresso sono correlati al nome del protocollo, JAM (Join Accumulate Machine). Join si riferisce a fn refine(), dove tutti i core Polkadot eseguono molto lavoro in parallelo per vari servizi. In Join, i dati vengono raffinati in subset più piccoli e passati alla fase successiva. Accumulate si riferisce alla raccolta dei risultati del processo precedentemente menzionato nello stato JAM principale, che corrisponde alla parte di esecuzione on-chain. 💡 Un work-item può determinare specificamente quale codice eseguire in-core e on-chain, e può decidere come, cosa e se leggere e scrivere dati nel Distributed Data Lake.

6.2. Quasi-concordanza Secondo la documentazione esistente su XCM, il linguaggio di comunicazione tra le parachain Polkadot, tutta la comunicazione è asincrona.

In altre parole, i messaggi vengono inviati senza attendere una risposta. L'asincronia è una caratteristica dei sistemi incoerenti e rappresenta un problema tipico di sistemi con sharding permanente come Polkadot 1.0, Polkadot 2.0 e gli attuali L2 di Ethereum. Tuttavia, come spiegato nella sezione 2.4 del Gray Paper, un sistema sempre sincrono e pienamente coerente per tutti i membri fatica a crescere senza sacrificare generalità, accessibilità e resilienza. ℹ️Sincrono (Synchronous) ~ Coerente (Coherent) || Asincrono (Asynchronous) ~ Incoerente (Incoherent).

È qui che JAM mostra un altro punto di forza. JAM introduce varie proprietà per trovare un nuovo punto di equilibrio definito sistema semi-coerente. In sostanza, i sottosistemi che comunicano frequentemente hanno l'opportunità di creare un ambiente coerente, ma ciò non viene imposto all'intero sistema. Questo aspetto è approfondito in un'intervista al Dr. Gavin Wood, autore del Gray Paper.

Un'altra prospettiva è vedere Polkadot e JAM come sistemi di sharding in cui i confini tra shard sono fluidi e decisi momento per momento. Polkadot è sempre stata una blockchain con sharding permanente e completamente eterogenea. Ora diventerà una blockchain con sharding e eterogeneità, ma con confini di sharding determinati in modo fluido, come @gavofyork ha definito sistema semi-coerente su — Kian Paimani (@kianenigma) 15 Maggio 2024.

Le caratteristiche che rendono ciò possibile sono le seguenti: esecuzione parallela in-core senza stato (state-less) in cui solo i servizi sullo stesso core in un determinato blocco possono interagire in modo sincrono, e accesso all'esecuzione on-chain che consente a un servizio di accedere ai risultati di tutti i servizi presenti su tutto il core. JAM non impone una programmazione specifica dei servizi. I servizi che comunicano frequentemente possono offrire incentivi economici affinché i sequencer creino pacchetti di lavoro che includono elementi di lavoro di questi servizi. Possono comunicare come se fossero nello stesso core, in un ambiente sincrono.

I servizi JAM hanno accesso al layer DA, che possono utilizzare come livello di dati temporaneo ma estremamente economico. Una volta che i dati vengono trasmessi al DA, vengono immediatamente propagati a tutti i core e resi disponibili immediatamente sullo stesso core. Di conseguenza, i servizi JAM possono godere di un'elevata accessibilità ai dati tramite auto-scheduling sullo stesso core di blocchi sequenziali [7]. Va ricordato che quanto sopra è una funzionalità possibile in JAM, ma non imposta a livello di protocollo. Alcune interfacce sono teoricamente asincrone, ma in pratica potrebbero funzionare in modo sincrono grazie a sofisticate astrazioni e incentivi. Un esempio che lo dimostra è CorePlay, descritto nella sezione successiva.

6. 3. CorePlay

In questa sezione spieghiamo l'idea sperimentale di JAM chiamata CorePlay. CorePlay è un nuovo modello per la programmazione di smart contract; al momento della scrittura non è chiaramente definito [8] ed è ancora nella fase di idea. Per capire CorePlay, è prima necessario esaminare la macchina virtuale di JAM, la PVM.

6. 3. 1. PVM

La PVM è un elemento cruciale per JAM e CorePlay. Una spiegazione dettagliata e tecnica della PVM è ben fornita nel Gray Paper, scritto da esperti del settore; qui descriveremo solo alcune caratteristiche della PVM:

• Misurazione efficiente dell'uso delle risorse
• Funzionalità di interruzione e ripresa dell'esecuzione

Quest'ultima è in particolare una funzione importante per CorePlay. CorePlay è un caso di utilizzo dei primitivi fluidi di JAM per creare un ambiente di smart contract estensibile con interfacce di programmazione. CorePlay propone un metodo per abilitare interfacce di programmazione sincrone distribuendo direttamente smart contract basati su attori sui core JAM. Si programma con un normale fn main(), e si comunica usando let _result = other_coreplay_actor(data).await?. Se other_coreplay_actor si trova nello stesso core del blocco JAM, questa chiamata è sincrona; se si trova in un core diverso, l'attore si interrompe e riprende in un blocco JAM successivo. Ciò è possibile grazie ai servizi di JAM, allo scheduling flessibile e alle caratteristiche della PVM.

6. 4. Servizi CoreChain

Concludiamo ribadendo il motivo per cui abbiamo menzionato che JAM è completamente compatibile con Polkadot. Il prodotto principale di Polkadot, le parachain in stile Agile Coretime, viene mantenuto in JAM. I primi servizi distribuiti su JAM saranno quelli chiamati CoreChain o parachain. È un servizio che permette alle parachain in stile Polkadot 2.0 di essere eseguite su JAM. È possibile distribuire più servizi su JAM e i servizi CoreChain esistenti possono comunicare con essi, ma le funzionalità già fornite da Polkadot continueranno a essere considerate importanti, aprendo nuove opportunità anche per i team di parachain esistenti.

Appendice: Data Sharding

La maggior parte di questo articolo ha discusso la scalabilità dal punto di vista dell'esecuzione con sharding, ma è possibile discuterne anche dal punto di vista dei dati. Interessante, ci si troverà di fronte a una situazione simile a quella menzionata per la semi-coerenza. Un sistema completamente coerente può essere in principio migliore, ma è difficile da scalare. Un sistema completamente incoerente è scalabile ma non ideale. JAM, che si propone come semi-coerente, presenta nuove possibilità.

• Sistema completamente coerente: Si trova in piattaforme di smart contract completamente sincrone come Solana, o in piattaforme ardite che distribuiscono solo su Ethereum L1. Tutti i dati dell'applicazione sono memorizzati sulla catena e facilmente accessibili da tutte le altre applicazioni. È una caratteristica perfetta per la programmabilità, ma non ha scalabilità.
• Sistema incoerente: I dati dell'applicazione sono memorizzati su shard diversi, esterni alla L1. È estremamente scalabile, ma non è ottimale in termini di componibilità. Il modello di Polkadot e Ethereum rollup rientra in questa categoria.

JAM offre entrambi, permettendo ai programmatori di pubblicare dati arbitrari sul layer DA di JAM, che può essere visto come una terra di mezzo tra dati on-chain e off-chain. Ciò consente di costruire un tipo completamente nuovo di applicazione utilizzando il layer DA per la maggior parte dei dati dell'applicazione e includendo solo le informazioni critiche nello stato JAM.

Appendice: Scalability Space Map

In questa parte spieghiamo nuovamente la visione sulla scalabilità delle blockchain. È una versione più concisa di quanto spiegato nel Gray Paper. Nelle blockchain, la scalabilità segue per lo più gli approcci utilizzati nei sistemi distribuiti tradizionali, ovvero scale-up (verticale) e scale-out (orizzontale). Piattaforme come Solana rientrano nel scale-up: ottimizzano codice e hardware per raggiungere la massima throughput. Ethereum e Polkadot rientrano nel scale-out: si riduce la quantità di lavoro che tutti devono svolgere. Nei sistemi distribuiti tradizionali questo si ottiene aggiungendo più macchine repliche. Nelle blockchain, la "macchina di calcolo" è l'intero set di validatori. Dividendoli per partizionare il lavoro (approccio ELVES) o alleviando i loro obblighi (approccio Optimistic Rollup), si riduce il carico di lavoro dell'intero set di validatori, risultando in una scalabilità orizzontale del sistema.

💡Il scale-out nelle blockchain significa "ridurre il numero di macchine che devono elaborare tutto".

In sintesi:

• Scale-up: Approccio a blockchain monolitica che esegue ottimizzazioni basate su hardware potente.
• Scale-out:
• Optimistic Rollup
• Rollup basati su SNARK
• ELVES: il sarcastico rollup di Polkadot.

Appendice: Stesso hardware, aggiornamento del kernel

In questa parte, basandoci sulla presentazione di Rob Habermeier a Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube, spieghiamo come JAM come aggiornamento di Polkadot possa essere paragonato a un aggiornamento del kernel sullo stesso hardware. In un computer generico, l'intero stack del sistema può essere diviso in tre parti:

1. Hardware
2. Kernel
3. Spazio utente

Come spiegato in precedenza, in Polkadot i core svolgono il ruolo di hardware, fornendo calcolo e disponibilità dei dati. Il kernel di Polkadot è composto sostanzialmente [9] da due cose:

• Protocollo Parachain: un modo rigido e opinato per utilizzare i core.
• Un insieme di funzioni di basso livello come il token DOT, funzioni di trasferimento, staking, governance.

Questi due elementi esistono attualmente nella relay chain di Polkadot. Lo spazio utente le applicazioni sono le parachain, i loro token nativi e tutto ciò che è costruito sopra di esse. Questo può essere visualizzato come segue. Polkadot ha sempre cercato di spostare le funzioni principali verso le parachain, utenti di prima classe. Anche l'obiettivo del Minimal Relay RFC è questo. Significa che lo spazio del kernel della relay chain Polkadot si riduce in某种程度上 poiché si concentra solo sul fornire il protocollo alle parachain.

Una volta implementata questa architettura, è facile immaginare come sarà la migrazione a JAM. JAM ridurrà drasticamente lo spazio del kernel di Polkadot, rendendolo più ampiamente utilizzabile. Inoltre, il protocollo Parachain si sposta nello spazio utente, poiché è uno dei pochi modi per scrivere applicazioni sullo stesso core (hardware) e su JAM (kernel).

💡Questa spiegazione sottolinea ancora una volta che JAM sostituisce la relay chain di Polkadot, non le parachain. In altre parole, la migrazione a JAM può essere vista come un aggiornamento del kernel. L'hardware di base rimane lo stesso, mentre gran parte del kernel esistente si sposta nello spazio utente per la semplificazione.

Referenze

7. 9 Polkadot 2.0: CorePlay, CoreChains, Corejam, Safrole, PolkaVM - Polkadot by Gavin @PBA4 - YouTube Gavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers - YouTube Parallel Chain. ↩︎ Blockchain o funzione di transizione di stato. ↩︎ In Polkadot 1.0, la prova di stato dell'L2 era chiamata PoV (Proof of Validity), e la combinazione di prova di stato e blocco parachain era chiamata PVF (Parachain Validation Function). ↩︎ Nel Gray Paper, il layer DA è chiamato Distributed Data Lake (DDL). In questo articolo, per comodità, lo esprimeremo come DA o layer DA. ↩︎ È importante che JAM sostituisce solo la relay chain di Polkadot. Tutte le applicazioni che operano su Polkadot, inclusa la parachain, rimangono invariate grazie a CoreChain. ↩︎ Il terzo è on_message, chiamato quando arriva un messaggio da un altro servizio. ↩︎ Per dettagli sullo scheduling dei servizi, consultare la sezione "Authorization" del Gray Paper. ↩︎ La migliore risorsa su CorePlay è questa bozza di RFC. ↩︎ La parola "sostanzialmente" è importante. Anche nel video menzionato, Rob ha definito il protocollo Parachain come applicazione nello spazio utente di Polkadot. Tuttavia, si tratta solo di un'ipotesi teorica; il protocollo Parachain è integrato nel core protocol Polkadot, ovvero nel kernel stesso. ↩︎

ABOUT THE AUTHOR

Kian Paimani Engineering Lead / Rust Core Developer at Parity Technologies 1 post

Terri Technical Writer 1 post

ON THIS PAGE

Share on Twitter Share on Facebook Share on LinkedIn Email address

Notify me Welcome! You will soon receive an email. Please click the log in link to confirm your subscription. Sorry, something went wrong. Please try again.