Potresti aver notato che quasi tutti gli sviluppatori partecipano e ritwittano la Cerimonia KZG, quindi cos'è la Cerimonia KZG?

In termini semplici, KZG Ceremony è la configurazione fiduciaria dell'impegno EIP-4844 KZG e EIP-4844 è la prerelease dello sharding completo di Ethereum.

1. Sharding: una soluzione a lungo termine per il ridimensionamento di Ethereum

  • Mentre i rollup ridimensionano Ethereum dal livello di esecuzione, lo sharding migliora la scalabilità e la capacità di Ethereum dal punto di vista della disponibilità dei dati.

  • Il grafico delle tendenze qui sotto mostra che la dimensione media dei blocchi oscilla intorno ai 90kb nonostante la rapida iterazione di Ethereum in questi anni. Sebbene i rollup riducano notevolmente la congestione della rete, le prestazioni complessive sono ancora limitate dalla capacità di archiviazione dei dati di Livello 1.

  • In considerazione della sicurezza e della complessità dell'implementazione, lo sharding è diviso in più fasi, che includono proto-danksharding e danksharding. L'intero processo potrebbe richiedere diversi anni.

  • Dato l'attuale schema di archiviazione, solo pochi hardware ad alte prestazioni sono in grado di partecipare come nodi. Dopo l'implementazione dello sharding, i nodi non sono tenuti a memorizzare l'intero contenuto dei dati storici, il che sfrutta la sicurezza di Ethereum abbassando la soglia per diventare un nodo (un costo di archiviazione dei dati inferiore e un grado di decentralizzazione più elevato).

2. EIP-4844: notevole ritorno a breve termine, una pre-release dello sharding completo di Ethereum

EIP-4844 = Proto-Danksharding;

Poiché l'implementazione completa dello sharding è ancora troppo complessa e potrebbe richiedere anni, il proto-danksharding è il miglior piano intermedio per ridurre la congestione di Ethereum nel breve termine.

2.1 Riepilogo del proto-danksharding

Proto-Danksharding introduce un nuovo tipo di transazione chiamato transazione blob-carrying. Grazie a questo aggiornamento, i rollup possono usare "blob" per trasferire dati a L1 e archiviarli provvisoriamente a un costo relativamente inferiore. La dimensione di un blob è molto più grande dell'attuale calldata.

Informazioni su blob:

  • Ogni transazione può trasportare al massimo 2 blob

  • Ogni blocco contiene normalmente 8 blob, che hanno una capacità di 1 MB.

Un blocco può contenere 16 blob, il che equivale a una dimensione del blocco di 2 MB.

  • Un blob non viene memorizzato in modo permanente nel registro cronologico come calldata.

  • Nella progettazione del proto-danksharding, i nodi devono comunque scaricare l'intero contenuto dei dati e verificarne la disponibilità.

2.2 Transazione che trasporta blob in profondità

Funzionalità

La funzionalità di un blob di dati è simile a quella di calldata, che consente al rollup di trasferire dati di transazione e prove a L1.

Costo

L'intenzione originale del blob è supportare TPS elevati nei rollup. Rispetto a calldata, che utilizza storage on-chain, quei blob di dati vengono scaricati e archiviati solo per un periodo di tempo. Pertanto, la spesa di gas per i rollup per garantire la disponibilità dei dati sarà prevedibilmente inferiore.

Capacità

La dimensione di ogni blob è 125 kB.

2.3 Il valore e la sfida delle transazioni che trasportano blob

Valore

È certo che l'emergere dei blob fa sì che i dati delle transazioni diventino una sorta di cache, il che riduce ulteriormente i requisiti hardware di archiviazione per i nodi e riduce la commissione del gas fornendo a Ethereum ulteriore spazio di archiviazione dati.

Sfida: calcoliamo i requisiti hardware

Il fatto è che la dimensione attuale del blocco è di circa 90 kB, ma la dimensione di un blob può raggiungere i 125 kB

In base alla progettazione di EIP-4844, la dimensione di ogni slot è normalmente di 1 MB, il che significa che la dimensione totale dei dati può essere calcolata come segue:

1 MB/blocco * 5 blocchi/min * 43200 min/mese * 12 mesi/anno = 2,47 TB all'anno

È ovvio che l'incremento annuale dei dati è di gran lunga superiore al totale dei dati di Ethereum, il che fa supporre che questo ingenuo piano di archiviazione dei dati non sia efficiente.

Cosa può essere ottimizzato?

Nel breve termine, ogni nodo deve ancora memorizzare il contenuto completo dei dati storici, ma il livello di consenso è implementato con uno schema in base al quale i dati blob verranno eliminati in un determinato periodo di tempo (30 giorni o 1 anno, TBD)

Per un beneficio a lungo termine, è necessario implementare EIP-4444, il che indica che i nodi non sono più tenuti a memorizzare dati completi. Invece, viene adottato un nuovo meccanismo, che consente ai nodi di memorizzare solo parti di dati per un certo periodo di tempo, facendo riferimento a un cosiddetto schema di scadenza della cronologia.

2.4 Impegno KZG

KZG Commitment è uno schema di impegno polinomiale adottato dal proto-danksharding EIP-4844

La cerimonia KZG è il processo di costituzione dell'impegno fiduciario KZG, che richiama oltre 30.000 partecipanti.

2.4.1 Qual è l'impegno di KZG

KZG è l'abbreviazione di Aniket Kate, Gregory M. Zaverucha e Ian Goldberg, che hanno pubblicato il saggio sull'impegno polinomiale "Constant-Size Commitments to Polynomials and Their Applications" nel 2010. L'impegno KZG è ampiamente applicato nel protocollo zk-snark in stile plonk.

Facendo riferimento al diagramma della presentazione di Dankrad, la radice KZG è simile alla radice Merkle, tranne per il fatto che la radice KZG si impegna in un polinomio, dove ogni posizione si trova su questo polinomio. Sulla base dello scenario del proto-danksharding, la radice KZG impegna un set di dati, dove ogni singolo punto dati può essere verificato come parte dell'intero set.

Una rapida panoramica di come funziona internamente l'impegno di KZG

  • Prover: Responsabile del calcolo dell'impegno. Per motivi di sicurezza, un prover non può modificare il polinomio dato e l'impegno è valido solo per il polinomio corrente;

  • Verificatore: responsabile della verifica dell'impegno inviato dal verificatore.

2.4.2 Cerimonia KZG (configurazione attendibile)

Il processo della cerimonia KZG

Tutti possono unirsi come partecipanti alla cerimonia KZG e contribuire con il segreto. Il segreto appena aggiunto verrà mescolato con l'output precedente per formare un nuovo risultato e, infine, generare un SRS per la configurazione del trust di impegno KZG. (Controllare il diagramma fornito da Vitalik per una migliore comprensione)

Impostazione della fiducia

  • La cerimonia KZG è un sistema di trust multi-partecipante ampiamente utilizzato, denominato "potere del tau";

  • Questa configurazione segue il modello di fiducia 1-of-N, il che significa che, indipendentemente dal numero di partecipanti che contribuiscono al processo di generazione della configurazione finale, finché una persona mantiene il proprio segreto, la validità della configurazione può essere garantita.

Significato della cerimonia KZG

  • Il valore della configurazione di trust dell'impegno KZG può essere interpretato come segue: per generare un parametro necessario per ogni singola esecuzione del protocollo crittografico

  • Quando il dimostratore calcola l'impegno, impegno KZG C = f(s)g1, dove f è la funzione di valutazione e s è il risultato finale della configurazione di trust KZG. Pertanto, il segreto finale generato dall'attuale cerimonia KZG è cruciale per la seguente implementazione dello sharding.

2.4.3 Vantaggio dell'impegno KZG

  • Costo

  • L'impegno KZG ha una complessità inferiore e può essere verificato in modo efficiente.

  • Non sono necessarie prove aggiuntive, il che comporta costi inferiori e risolve il problema della larghezza di banda.

  • Costi ancora più bassi sfruttando la valutazione dei punti precompilati.

  • Sicurezza

  • Se si verifica l'errore, viene infettato solo il blob corrispondente all'impegno corrente e non si verificano ulteriori effetti a catena.

  • Compatibilità

  • L'impegno di KZG è più favorevole a DAS, il che evita ridondanza nello sviluppo.

2.5 Il vantaggio di EIP-4844

Arrotolare

Come mostrato nell'immagine sottostante, rollup deve inviare il delta di stato e l'hash con versione dell'impegno KZG tramite calldata (zk-rollup deve ancora caricare lo zkp).

Dopo l'implementazione di EIP-4844, il costoso calldata trasporta solo alcuni dati di piccole dimensioni, come il delta di stato e gli impegni, mentre i dati di grandi dimensioni, come il batch di transazioni, vengono inseriti nel blob.

  • ridurre i costi;

  • ridurre l'utilizzo dello spazio di archiviazione a blocchi.

Miglioramento della sicurezza

  • Disponibilità dei dati: Blob è archiviato nella beacon chain, che condivide lo stesso livello di sicurezza di Ethereum L1.

  • Dati storici: i nodi memorizzano i blob solo per un determinato periodo di tempo e il rollup di livello 2 è responsabile dell'archiviazione permanente dei dati, il che indica che la sicurezza dei dati storici si basa sul rollup.

Costo

La caratteristica di basso costo della transazione che trasporta blob può ottimizzare il costo complessivo da x10 a x50.

Nel frattempo, EIP-4844 introduce una tariffa blob

  • Il gas e il blob avranno prezzi e limiti del gas regolabili separatamente;

  • L'unità di prezzo di un blob è il gas; la quantità di gas varierà in base al traffico di rete, che mira a mantenere il numero trasportato da ogni blocco (8 in media).

Implementazione della precompilazione

L'esecuzione EVM può solo visualizzare il commit di un blob generato dal prover e non può accedere direttamente ai dati del blob. Pertanto, il rollup deve utilizzare lo schema di precompilazione per verificare la validità del commit.

Ci sono due algoritmi di precompilazione menzionati in EIP-4844

  • Valutazione dei punti precompilazione

  • Dimostrare che sono stati assunti più impegni sullo stesso set di dati.

  • La valutazione dei punti precompilati è adottata principalmente da zk-rollup, il rollup deve fornire due impegni, l'impegno KZG e l'impegno zk-rollup

  • Per quanto riguarda il rollup ottimistico, la maggior parte di essi ha adottato la tecnica multi-round fraud-proof, e la tecnica finale fraud-proof contiene una dimensione di dati inferiore, il che significa che possono anche utilizzare la valutazione dei punti pre-compilata a un costo inferiore.

  • Verifica blob precompilazione

  • Dimostrare che l'hash con versione è valido per il blob corrispondente

  • Il rollup ottimistico necessita dell'accesso ai dati completi quando invia dati a prova di frode, quindi è logico verificare la validità dell'hash con versione e quindi la verifica a prova di frode.

3. Danksharding: un passo cruciale verso lo sharding completo

Scalabilità

Grazie al nuovo design del tipo di transazione del proto-danksharding, che introduce un blob di dati, ogni blocco ha ora una cache extra da 1 MB. Questo numero crescerà da 16 a 32 volte dopo l'implementazione del danksharding.

Disponibilità dei dati: archiviazione e verifica dei dati ad alte prestazioni

Rispetto al proto-danksharding, in cui i nodi sono tenuti a memorizzare l'intero contenuto dei dati storici, il danksharding consente ai nodi di memorizzare i dati solo dopo il campionamento.

IL

Sfruttando la tecnologia di codifica della cancellazione, la proposta di danksharding semplifica (ogni nodo deve scaricare solo parti di dati) l'individuazione della perdita di dati da parte dei nodi.

Sicurezza: quasi la stessa

Poiché i nodi non sono più tenuti a memorizzare l'intero contenuto dei dati storici, la sicurezza non è supportata da un singolo nodo, ma dipende da più nodi che memorizzano parti di dati e possono essere ulteriormente composti e recuperare i dati completi.

Sebbene uno schema di dipendenza a punto singolo sia più sicuro di uno schema di dipendenza a più punti, il numero di nodi nella rete Ethereum è di gran lunga più che sufficiente, il che è idoneo a raggiungere l'obiettivo di garantire la disponibilità dei dati.

Nuova sfida: requisiti più elevati per i costruttori di blocchi

Mentre i validatori scaricano e memorizzano solo parti dei dati completi, il costruttore di blocchi deve comunque caricare il contenuto completo dei dati, ovvero il blob che contiene tutti i dati delle transazioni.

Secondo il diagramma delle diapositive di Dankrad, possiamo vedere come PBS (separazione proponente/costruttore), originariamente progettato per anti-MEV, aiuta a ridurre i requisiti di larghezza di banda durante la creazione di blocchi.

4. Un altro schema di sharding: sharding dinamico dello stato da Shardeum

Shardeum è una blockchain L1 compatibile con EVM, che utilizza lo sharding dinamico dello stato per migliorare la scalabilità e la sicurezza. Nel frattempo, la rete Shardeum è in grado di garantire un livello di decentralizzazione più elevato.

Sharding dinamico dello stato

Vantaggi

I vantaggi più intuitivi dello sharding dinamico dello stato sono il ridimensionamento lineare. Ogni nodo contiene un diverso intervallo di indirizzi e c'è una sovrapposizione significativa tra gli indirizzi coperti dai nodi. L'algoritmo di sharding raggruppa i nodi in modo dinamico, il che significa che i nodi appena aggiunti nella rete Shardeum lavorano immediatamente per aumentare il TPS

Implementazione

La complessità dell'implementazione dello sharding dinamico dello stato è più difficile dello sharding statico. Il team tecnico di Shardeum ha studiato a fondo le tecnologie di sharding. Anche i precedenti risultati di R&S ottenuti dal team di Shardeum (in precedenza tecnologia Shardus) apportano contributi significativi, in grado di mostrare la scalabilità lineare dello sharding dinamico dello stato in una fase di sviluppo iniziale.

Prodotto

Facendo riferimento all'idea di dividi et impera, lo sharding dinamico dello stato di Shardeum divide il carico di lavoro di calcolo e archiviazione, il che consente un livello di parallelizzazione più elevato. Pertanto, la rete è in grado di ospitare più nodi, il che migliora ulteriormente la produttività e il livello di decentralizzazione.

Squadra

Il team di Shardeum ha una solida esperienza di marketing e capacità narrative. Hanno anche una profonda comprensione dei dettagli tecnici, in particolare dello sharding dinamico dello stato.

Tecnologia

Il team tecnico è in grado di progettare uno schema di sharding appropriato e un algoritmo di consenso efficiente (Proof of Stake + Proof of Quorum) in base alla propria comprensione dello scenario, che pone la scalabilità e la produttività come prima considerazione e garantisce la sicurezza e il livello di decentralizzazione il più possibile.

Progressi

Betanet è stato lanciato il 2023–02–02.

5. La prospettiva

  • Lo sharding è una soluzione di scalabilità a lungo termine per Ethereum, ha un valore enorme e un significato profondo per l'intera rete. È peggio prestare troppa attenzione, poiché l'implementazione dello sharding è un processo di iterazione. Tutte le proposte attuali, tra cui proto-danksharding e danksharding, possono essere aggiornate/modificate.

  • Sebbene sia importante comprendere il metodo generale di implementazione dello sharding, vale la pena prestare attenzione anche alle proposte tecniche, come PBS, DAS, mercato delle commissioni multidimensionali, ecc., che emergono durante il processo. Potrebbero esserci molti progetti in sospeso che accompagnano tali schemi.

  • È importante sapere che sharding è un termine generico che descrive un set di tecnologie di scaling e che ci sono diversi schemi applicativi a seconda di scenari specifici. Ad esempio, il design di danksharding potrebbe adattarsi solo a Ethereum e potrebbe probabilmente portare a un effetto negativo se applicato in altri L1, poiché la sicurezza deve essere garantita da un'enorme quantità di nodi nella rete.

  • Una combinazione razionale di sharding e altre soluzioni di scaling può ottenere un effetto moltiplicatore. L'attuale proposta di danksharding non funzionerà da sola. Invece, rollup e danksharding si integrano a vicenda per migliorare ulteriormente la scalabilità e la capacità di Ethereum.

Riferimento

https://notes.ethereum.org/@dankrad/kzg_commitments_in_proofs

https://notes.ethereum.org/@dankrad/new_sharding

https://vitalik.ca/general/2022/03/14/trustedsetup.html

https://notes.ethereum.org/@vbuterin/proto_danksharding_faq# Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly

https://ethresear.ch/t/easy-proof-of-equivalence-between-multiple-polynomial-commitment-schemes-to-the-same-data/8188

https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

https://eips.ethereum.org/EIPS/eip-4844

Italiano: https://www.eip4844.com/

https://biquanlibai.notion.site/Data-Availability-caa896aae59d489b98f2448f17b01640

https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434

Informazioni su Foresight Ventures

Foresight Ventures si dedica a sostenere l'innovazione dirompente della blockchain per i prossimi decenni. Gestiamo più fondi: un fondo VC, un fondo secondario gestito attivamente, un FOF multi-strategia e un fondo secondario del mercato privato, con AUM superiore a $ 400 milioni. Foresight Ventures aderisce alla convinzione di "Mentalità unica, indipendente, aggressiva e a lungo termine" e fornisce ampio supporto alle società di portafoglio all'interno di un ecosistema in crescita. Il nostro team è composto da veterani delle principali società finanziarie e tecnologiche come Sequoia Capital, CICC, Google, Bitmain e molte altre.

Sito web: https://www.foresightventures.com/

Twitter: https://twitter.com/ForesightVen

Medio: https://foresightventures.medium.com

Sottostack: https://foresightventures.substack.com

Discordia: https://discord.com/invite/maEG3hRdE3

Linktree: https://linktr.ee/foresightventures