OP a breve termine, ZK a lungo termine?
Questa frase è stata detta da Vitalik, quindi molti la considerano una 'legge aurea', ma la situazione reale è molto più complessa
Il tipo di confronto comune è già stato detto online - cioè OP basato sul gioco < ZK basato sulla matematica; periodo di prelievo di OP1 di due settimane < periodo di prelievo ZK che richiede solo pochi minuti a poche ore; la compatibilità EVM di OP è migliore > la compatibilità ZK ha ancora molta strada da fare... Non parlerò più, il commento di Vitalik sul breve e lungo termine è sostanzialmente basato sui tre fondamentali sopra menzionati
Tuttavia, il gioco VS matematica - gli utenti non percepiscono alcuna differenza e non si preoccupano affatto; periodo di prelievo di due settimane VS pochi minuti o poche ore - queste differenze sono tutte appianate dai ponti; compatibilità EVM - ora OP è effettivamente migliore, ma con lo sviluppo lento di ZK, anche questo sarà infine appianato
Quindi parliamo di qualcosa di diverso
1. Innanzitutto è la performance
Una affermazione comune è che il TPS del sistema ZK supera quello del sistema OP, e questo è principalmente dovuto al fatto che il rapporto di compressione di ZK è relativamente più alto rispetto a OP. In altre parole, quando si inviano dati di transazione compressi su L1, ZK può inviare più transazioni rispetto a OP grazie a un rapporto di compressione più elevato, quindi il TPS risulta naturalmente più alto.
Tuttavia, questa affermazione ignora i costi e il tempo enormi necessari per generare le prove di ZK.
Quindi il confronto delle performance tra OP e ZK è probabile che sia uno stile alternato, alla fine con risultati simili - ciò che segue è puramente una riflessione, non necessariamente accurata.
1. ZK appena lanciato - TPS OP alto, perché il costo e il tempo delle prove ZK superano di gran lunga i vantaggi forniti dal rapporto di compressione.
2. L'architettura del Prover ZK è relativamente matura - TPS ZK alto, da questo lato ad esempio sono emerse macchine FPGA o ASIC, i costi e i tempi delle prove ZK sono notevolmente diminuiti, e i vantaggi del rapporto di compressione iniziano a manifestarsi.
3. Pro-Danksharding lanciato - TPS OP e ZK sono di nuovo simili, perché dal lato L1 non si utilizza il Call Data, ma uno Blob molto più grande e a basso costo come DA, quindi il vantaggio del rapporto di compressione non è così evidente come ai tempi dell'era del Call Data, il piccolo vantaggio del rapporto di compressione viene sostanzialmente annullato dal piccolo svantaggio delle prove ZK, i limiti teorici del TPS di OP e ZK sono sostanzialmente limitati dalla capacità di elaborazione hardware del Sequencer.
2. In secondo luogo, i vantaggi reali di ZK nel mercato
La crittografia > gioco, è molto inferiore ai periodi di prelievo di OP, è un vantaggio tecnico di ZK, ma non necessariamente un vantaggio nel mercato. Il mondo della blockchain non è mai stato solo "tecnologia". Proprio come ora ETH è passato da POW a POS, ci sono ancora molte persone anziane e esperti di tecnologia che scrivono incessantemente articoli che dimostrano che POW è superiore a POS, e bisogna ammettere che molti dei loro argomenti sono davvero sensati.
Tuttavia, non importa, il mercato ritiene che POS sia il futuro delle nuove blockchain (escludendo BTC), cosa puoi farci?
Quindi, quali sono i vantaggi reali di ZK nel mercato? Ne ho pensati due.
1. ZK, come attualmente il "focus" nella tecnologia blockchain, potrebbe accendere un'intera catena industriale, proprio come POW ha acceso il mining (da CPU a GPU a FPGA a ASIC), pool di mining, fattorie di mining, prodotti derivati dalla potenza di calcolo e così via, ZK potrebbe anche accendere una catena industriale simile a POW, basata su hardware abbinato, dalla prova alla verifica.
2. ZK può fare molte più cose - ad esempio, implementare funzionalità di privacy (Aztec), come quello che V ha recentemente pubblicato (Che tipo di layer3 ha senso?) - che menziona uno scenario in cui un token nativo Arb viene "cross-chain" su Optimism (in modo Wrap), poiché dipende simultaneamente da ETH L1, quindi il contratto Wrap di Optimism può completamente aggirare i vari ponti "non sicuri" attuali leggendo la prova Merkle della ricevuta del contratto di deposito caricata su L1 da Arb. Tuttavia, teoricamente i depositi delle L2 di tipo OP dovrebbero attendere il passaggio di un periodo di finestra di frode (7 giorni) per essere considerati sicuri, quindi è difficile farlo in questo modo; con ZK, questo scenario non è un problema.
3. Infine, parliamo del destino finale di ZK e OP.
Hai la sensazione che ZK-sync, Scroll e simili siano già entrati nella fase di test Alpha e pensi che ZK sia quasi pronto per essere utilizzato?
Sei troppo ingenuo, la strada che ZK deve percorrere è ancora molto lunga, come il codice del circuito ufficiale di ZKEVM della Ethereum Foundation, oltre 30.000 righe, secondo le parole di V - richiede "uno sviluppo molto lungo e test continui", "nei prossimi anni non si può fare completamente affidamento sulla sicurezza fornita dal sistema ZK".
Certo, OP è in vantaggio, ma il percorso non è ancora completo, ad esempio Optimism a causa della modifica dell'architettura OVM, fino ad ora la funzione centrale della prova di frode di OP non è ancora stata lanciata, molte persone non lo sanno.
Quale potrebbe essere quindi il destino finale? V ha anche fornito una discussione, personalmente penso che sia piuttosto plausibile, magari tra qualche anno sarà proprio così.
Com'è? È tutto in questo thread di discussione.
In dettaglio è
prima della maturazione di zkEVM, OP sarà principale, ZK sarà secondario
1. Pubblicare il blocco
2. Attendere 24 ore
3. Se durante il periodo non ci sono sfide di frode, pubblicare ZKP, Finalizza il blocco.
Else（有挑战）, introdurre Governance, decidere il risultato finale tramite il modello 2of3
Dopo la maturazione di zkEVM, ZK sarà principale, OP sarà secondario
1. Pubblicare il blocco
2. Pubblicare regolarmente ZKP
3. SE ZKP viene pubblicato normalmente durante il periodo designato, allora Finalizza
Else（ZKP non pubblicato normalmente durante il periodo, sia che il Prover sia andato giù o ci sia stato un bug), il sistema passa a un meccanismo Ottimista, fino a quando il meccanismo ZK non viene ripristinato