Schema di messaggistica di Polkadot

Autori: Fatemeh Shirazi, Logan Saether, Alistair Stewart, Rob Habermeier, Gavin Wood

Il team di ricerca di Web3 Foundation ha lavorato negli ultimi mesi su un testo che delinea la funzionalità di Cross-Chain Message Passing (XCMP). È un componente chiave di Polkadot, il protocollo di punta della Web3 Foundation. Siamo entusiasti di condividere il nostro lavoro con te!

Lo schema Cross-Chain Message Passing (XCMP) è un sottoinsieme del protocollo Polkadot. Definisce come i messaggi possono essere passati tra parachain senza ulteriori presupposti di fiducia oltre alla sicurezza economica della Relay chain. Questo articolo affronta il protocollo di messaggistica delle parachain e si basa fortemente sull'architettura e sul design unici della Polkadot Relay chain.

Il protocollo copre:

• In termini di consenso: meccanismi di accodamento e ordinamento dei messaggi.
• In collaborazione con il resto della Relay chain e in particolare la finalizzazione del GRANDPA: disponibilità dei dati.
• In combinazione con la funzione di convalida parachain: input e output del messaggio.

Inoltre, questo articolo esamina anche la consegna, il modo in cui viene raggiunta la cronologia coerente e le idee per prevenire gli attacchi DoS. Infine, esaminiamo XCMP insieme a SPREE e concludiamo riassumendo le proprietà ottenute da XCMP.

La semantica del messaggio e i dettagli di rete come il peer discovery non sono trattati in questo articolo.

Introduzione

Una delle caratteristiche chiave di Polkadot "versione 1.0" è consentire alle sue parachain altrimenti isolate di inviare messaggi tra loro con garanzie e in modo sicuro e trustless.

Ai fini del presente, definiamo il termine messaggio più o meno allo stesso modo di transazione. Entrambi si riferiscono a dati provenienti dall'esterno della chain ricevente, ed entrambi implicano e richiedono che la chain agisca sui dati seguendo la logica interna della chain. Tenendo conto di un certo livello di ritardo tipico per i sistemi del mondo reale, la chain non può rifiutare o confondere le implicazioni dei dati. Ad esempio, nel contesto di Bitcoin, questa proprietà significa che un miner di Bitcoin difettoso o dannoso non può reindirizzare i fondi ed è quindi il fondamento di buoni sistemi di consenso crypto-economico.

La differenza fondamentale tra una transazione e un messaggio è che una transazione contiene una firma per provare la provenienza dei dati (e quindi l'autorità delle istruzioni), mentre con un messaggio la provenienza è provata semplicemente in virtù della resistenza bizantina interna di Polkadot infrastruttura di convalida cripto economica, più o meno allo stesso modo del passaggio di messaggi inter contratti di Ethereum.

Esempio

Prima di entrare nei dettagli di ciascun componente di XCMP, prendiamo prima un esempio di come un messaggio in uscita su una parachain smart contract (denominata A nella Figura 1) sarà collegata in rete alla coda in entrata di una parachain Decentralized Finance “DeFi” (indicato come B nella Figura 1) per l'inclusione nel prossimo blocco candidato dal collator della parachain DeFi.

Al blocco 300 della Relay chain , lo smart contract della parachain avvia un messaggio che è mirato verso l'endpoint 32, che è l'ID della Parachain DeFi. Il messaggio verrà prima incluso nella coda in uscita, o in attesa, nella parachain dello smart contract.

Tutti inodi completi degli smart contract della parachain inizieranno a comunicare (vedere la sezione Consegna di seguito) il messaggio nella rete. Se alcuni nodi dello smart contract della chain sono anche nodi completi nella chain DeFi,questi nodi fungono da collante tra le due reti di comunicazione inoltrando il messaggio. Se non ci sono nodi condivisi delle reti che devono essere attraversati, viene invocato un meccanismo di fallback (vedere la sezione Fallback di seguito).

Una volta che il messaggio ha raggiunto il collator della parachain DeFi, prendono questo messaggio (e tutti gli altri messaggi che hanno ricevuto) e lo inseriscono nella coda in entrata o in ingresso per l'elaborazione nel suo prossimo blocco candidato.

Figura 1: mostra due parachain A e B, i relativi collator e inodi completi. Esistono due nodi che sono entrambi completi nella rete parachain A e nella rete parachain B.

Il collator sulla parachain DeFi produrrà un candidato di blocco per il blocco della relay chain 301. Questo candidato di blocco richiederà la prova che i messaggi su cui ha agito nel blocco A sono i messaggi corretti. Il blocco della relay chain 300 contiene un'intestazione parachain per il blocco A, una piccola quantità di dati che include un hash radice del messaggio che può essere utilizzato per autenticare i messaggi.

Questo candidato al blocco includerà una prova client light della relay chain che questa radice del messaggio era nella relay chain e la combinerà con una prova inviata con il messaggio dalla chain di invio.

Il validatore della parachain per la parachain DeFi sarà in grado di utilizzare queste prove per convalidare l'integrità del blocco candidato proposto dalla parachain DeFi. Il messaggio originaledello smart contractviene quindi incluso nella parachain DeFi senza ulteriori presupposti di fiducia e facendo affidamento sulla piena sicurezza di Polkadot.

Mettere in coda e ordini dei messaggi

Ogni blocco parachain in Polkadot produce un elenco possibilmente vuoto di messaggi da instradare a ogni altro blocco. Queste sono note come code di uscita. Una volta che un messaggio è stato introdotto, entra nella coda di ingresso di una parachain. Le parachain devono elaborare gli elenchi di ingressi in ordine.

Un selezionatore o validatore che cerca di raccogliere messaggi per le code di uscita di una determinata parachain invoca l'ingresso per quella parachain e cerca nella pool di propagazione i messaggi rilevanti, in attesa di quelli che non sono stati ancora comunicati.

Consegnare i messaggi

Assumiamo di avere una rete connessa di nodi completi per ogni parachain. Assumiamo che ogni nodo completo sia a conoscenza di un sottoinsieme di altri nodi completi nel sistema, a cui ci riferiamo come nodi vicini. Si noti che non facciamo alcuna ipotesi sulla topologia e sul diametro di queste reti.

Il modo più semplice per inviare messaggi è con un protocollo di gossip. Ricorda che i peer comunicano costantemente tra di loro sulla loro visione del corrente congedo. Per ottenere una consegna più efficiente, i messaggi non instradati vengono comunicati solo ai nodi vicini che hanno la stessa visualizzazione.

Se ci sono nodi in comune tra queste due reti, i messaggi verranno comunicati da una rete parachain a un'altra rete.

Figura 2: mostra la consegna del messaggio tramite gossiping. Partiamo dal presupposto che il messaggio sia stato inviato dal collator di invio rosa, che ha prodotto l'ultimo blocco parachain.

Fallback di consegna

Tuttavia, se i validatori della parachain ricevente si rendono conto che il messaggio non è stato comunicato, richiedono il messaggio ai validatori della parachain di invio. Una volta ricevuti, spettegolano (comunicano) quei messaggi sulla rete parachain ricevente.

Figura 3: mostra la consegna di fallback quando le parachain di invio e ricezione non condividono alcun nodo completo.

Il meccanismo di consegna di fallback è mostrato nella Figura 3, dove presumiamo che la parachain A voglia inviare un messaggio alla parachain C, con la quale non condivide alcun nodo completo comune. Una volta che i validatori della parachain C notano che il messaggio non è arrivato, inviano una richiesta ai validatori della parachain di invio, che sono responsabili della conservazione dei messaggi di uscita dalla loro parachain. Una volta che arriva la risposta alla loro richiesta, i validatori della parachain C comunicano il messaggio all'interno della parachain C.

Ottenere una cronologia coerente

Una proprietà chiave che vogliamo da XCMP è per i blocchi parachain canonici, i. e. cioè quelli che alla fine concordiamo siano accaduti. Ciò significa, che nel blocco parachain corrente, agiamo solo su quei messaggi che sono stati inviati da blocchi parachain che sono essi stessi sia canonici che precedenti al blocco corrente.

La relay chain definisce una cronologia per tutte le parachain. Ad esempio, un blocco della parachain B la cui intestazione era nel blocco della relay chain 301, può dire di aver agito su tutti i messaggi fino al blocco 300 e, in tal caso, dovrebbe agire sui messaggi inviati dal blocco parachain A solo se l'intestazione del blocco parachain A è apparso nel blocco della relay chain 300 o precedente.

Ciò significa che la relay chain deve svolgere un ruolo nell'autenticazione dei messaggi. Tuttavia, poiché non possiamo inserire molti dati in queste intestazioni parachain, la relay chain non dovrebbe avere il carico utile del messaggio stesso. Al contrario, riusciamo a mantenere una cronologia coerente in modo efficiente utilizzando alberi Merkle nidificati. L'intestazione di un blocco parachain che corrisponde ai messaggi inviati conterrà un singolo hash radice del messaggio, la radice di un albero Merkle. A loro volta, le foglie di questo albero Merkle sono il capo della chain di messaggi hash da questa parachain all'altra.

Ciò significa che esiste una sequenza di hash che contiene ogni hash del messaggio, consentendo la verifica di tutti i messaggi inviati da una parachain all'altra da questo hash. Ciò consente a un selezionatore di costruire una prova, composta da molti hash, che hanno agito sui messaggi e solo su quei messaggi su cui dovrebbero agire, mostrando prima che la radice del messaggio era nella relay chain e poi fornendo una prova che questi erano i messaggi dall'hash principale del messaggio.

Per ulteriori informazioni su questo argomento, vedere [qui].(https://research.web3.foundation/en/latest/polkadot/XCMP.html)

Convalida di input e output

Ricordiamo che Polkadot è composto da una singola relay chain e da un numero (provvisorio fino a 100) di parachain.

Le intestazioni sulla Parachain contengono una radice dei messaggi in uscita. Per produrre un blocco parachain su una parachain che si basa su un particolare blocco della relay chain, un collator dovrebbe guardare quali intestazioni sulla parachain sono state costruite tra quel blocco relay chain e la relay chain che includeva l'intestazione dell'ultimo blocco parachain di questa parachain . Per quei messaggi, la parachain deve agire sui dati del messaggio corrispondente.

Figura 4: mostra i blocchi parachain che sono stati costruiti per tre parachain A,B,C nei tre round 0, 1, 2 e i messaggi che sono stati inviati in ogni round tra queste parachain.

La funzione di verifica della transizione dello stato parachain (STVF) utilizza una funzione di convalida per verificare che i messaggi di input effettivamente agiscano. La funzione di convalida è un pezzo di WebAssembly che verifica che la transizione di stato della parachain sia effettivamente valida. Collega un nuovo stato della parachain e un insieme di messaggi di output a un riassunto dello stato precedente della parachain , ai dati del blocco parachain e a una serie di messaggi di input che sono stati instradati fedelmente da altre parachain o dalla relay chain.

La Figura 4 mostra un esempio in cui i blocchi parachain prodotti e i messaggi tra tre parachain A, B e C sono mostrati per i round 0, 1, 2. Supponiamo che la parachain B non produca alcun blocco parachain nel round 0 e che la parachain C non produca un blocco nel round 1. Il blocco parachain B1 prodotto nel round 1 deve aver preso il messaggio m1 come messaggio di input e risponde alla parachain E inviando il messaggio m3 al round 1. Il blocco parachain C1 prodotto nel round 2 deve ricevere messaggi m2 e m4 nella sua coda di ingresso non processata.

Disponibilità dei messaggi

Una volta che i messaggi sono stati inclusi nelle code di uscita, vengono conservati dai collator e dai nodi completi della parachain di invio. Quando le intestazioni dei blocchi parachain di invio sono state incluse nella relay chain, anche i validatori di parachain manterranno i messaggi. Anche i collators e i full node della parachain ricevente dovranno essere consapevoli del carico utile dei messaggi inviati tra le parachain. Tutte le altre entità che devono essere a conoscenza dell'esistenza dei messaggi possono archiviare solo hash, che possono essere utilizzati per autenticare i messaggi.

Per garantire la disponibilità, richiediamo che tutti i validatori contengano pezzi con codice di cancellazione in grado di recuperare qualsiasi messaggio parachain. Questi pezzi con codice di cancellazione sono prodotti e distribuiti dai validatori della parachain di invio. 1/3 di questi pezzi con codice di cancellazione sono sufficienti per recuperare tutti i messaggi. La finalità richiede che questi pezzi con codice di cancellazione siano stati ricevuti dagli elettori (validatori), altrimenti saranno puniti per il voto. Pertanto, 2/3 dei pezzi con codice di cancellazione devono essere disponibili una volta raggiunta la finalità; quindi, possiamo garantire che sia disponibile anche un messaggio finalizzato.

Prevenire gli attacchi DoS

Si noti che lo scopo di XCMP non è determinare alcun formato standard per i messaggi. Tuttavia, ogni parachain ha un limite alla dimensione totale dei messaggi che può inviare a un altra parachain. Inoltre, il protocollo di gossiping utilizza una consegna di delimitazione per evitare grandi spese generali.

Per le parathread che non ottengono blocchi nella relay chain frequentemente, la coda dei messaggi non elaborati potrebbe aumentare in modo sostanziale. Per limitare questo, la parachain di invio manterrà una coda di uscita per questa chain che ha un limite di dimensioni. Può rimuovere i vecchi messaggi solo quando sa che sono stati ricevuti. La chain ricevente pubblica una filigrana indicando quale numero di blocco - e all'interno di esso, quale parachain - ha elaborato i messaggi fino a. La chain di invio può utilizzare questa filigrana per eliminare la coda in uscita.

Inoltre, prevediamo di dare alla parachain ricevente la possibilità di impedire a un altra parachain di inviare messaggi (questa funzione non è ancora implementata). Le parathread possono anche disabilitare la funzione XCMP per evitare di dover elaborare grandi quantità di messaggi.

XCMP e SPREE

Gli Shared Protected Runtime Execution Enclaves (SPREE) sono frammenti di logica simili ai moduli di runtime ma che risiedono sulla relay chain e possono avere la loro funzionalità attivata da parachain.

Questi frammenti di logica sono blob di codice WebAssembly caricati su Polkadot tramite un meccanismo di governance o tramite parachain. Una volta che il blob è stato caricato su Polkadot, tutti le altre parachain possono decidere di aderire alla logica. Il modulo SPREE manterrebbe la propria memoria indipendente dalla parachain ma potrebbe essere richiamato tramite un'interfaccia con la parachain. La Parachain invierà messaggi al modulo SPREE in modo sincrono. Per ulteriori informazioni su SPREE, vedere il suo articolo wiki.

Sarà possibile indirizzare un messaggio XCMP a un modulo SPREE e garantire che quando si agisce su quel messaggio, utilizzerà lo stesso codice di quel modulo SPREE come qualsiasi altra parachain. I moduli SPREE sono importanti per l'architettura XCMP complessiva perché forniscono una garanzia che una certa interpretazione del codice verrà eseguita sulle parachain di destinazione. Sebbene XCMP garantisca la consegna di un messaggio, non garantisce quale codice verrà eseguito, ovvero come la parachain ricevente interpreterà il messaggio. Gli aggiornamenti al codice di un modulo SPREE saranno simultanei attraverso le parachain. Oltre ai vantaggi in termini di sicurezza, ciò significa che è possibile modificare i formati dei messaggi senza coordinare gli aggiornamenti su molte parachain.

In sintesi, mentre XCMP esegue il passaggio di messaggi trustless, SPREE è l'interpretazione trustless del messaggio e una parte fondamentale dell'utilità di XCMP. I messaggi XCMP indirizzati ai moduli SPREE forniscono agli sviluppatori e agli utenti dei messaggi di invio di chiarezza su come verrà elaborato il messaggio.

Riassumendo le proprietà di XCMP

Lo schema XCMP ottiene le seguenti proprietà:

Affidabilità Poiché lo stesso insieme di validatori protegge una parachain come un'altra mentre garantiscono anche il corretto passaggio dei messaggi, XCMP non richiede più fiducia di quanto farebbe una singola blockchain.

Coerenza fornisce assoluta garanzia che i messaggi ricevuti siano esattamente quelli inviati, nonostante eventuali riorganizzazioni delle chain.

Disponibilità Polkadot garantisce che i messaggi non vadano persi e siano tenuti a disposizione. Ciò si ottiene distribuendo pezzi con codice di cancellazione che possono essere utilizzati per ricostruire i messaggi.

Mantenere il corretto ordinamento dei messaggi emessi dai blocchi parachain è garantito dalla validazione Input/Output.

Efficienza Il protocollo evita un sovraccarico eccessivo della larghezza di banda e consente ai messaggi di arrivare il più rapidamente possibile.

Per ulteriori informazioni su Web3 Foundation, visitare web3.foundation. Per un'analisi più approfondita delle funzionalità e delle caratteristiche di Polkadot, controlla il nostro Wiki, che aggiorniamo ed elaboriamo costantemente.