“Secara keseluruhan, pandangan saya adalah bahwa dalam jangka pendek, Optimistic rollup lebih unggul dalam hal kompatibilitas EVM, sementara ZKrollup diharapkan lebih baik dalam lapisan pembayaran sederhana, transaksi, dan kasus penggunaan khusus lainnya.
Namun, dalam jangka menengah dan panjang, rollup ZK akan menang di semua kasus penggunaan dengan peningkatan teknologi ZK-SNARK. "
Ini adalah kata-kata asli God V di blognya "An Incomplete Guide to Rollups".
ZK adalah cita-cita ETH. Penerapan Zero-Knowledge Proofs (selanjutnya disebut sebagai ZK) dalam ekosistem Ethereum mengungkapkan kemampuannya untuk memecahkan masalah segitiga mustahil dari blockchain (yaitu, keamanan, skalabilitas, dan desentralisasi) tanpa sentralisasi. harus mengakses detail transaksi lengkap, meningkatkan skalabilitas sistem tanpa mengorbankan keamanan.
Pengenalan ZK semakin memperkuat desentralisasi sistem ETH (menurunkan ambang node) dan memastikan kemampuan desentralisasi dan anti-sensor jaringan, membuat ETH memasuki lautan seperti naga dan sulit untuk dihapus.
Dengan ZK yang begitu penting, mengapa setiap orang memiliki pengalaman buruk dalam menggunakannya, dan penerapan skala besar tidak dapat menimbulkan gelombang apa pun?
1. Masalah rollup tanpa bukti pengetahuan saat ini
Saya mengaitkan alasan mengapa bukti tanpa pengetahuan saat ini masih berada dalam periode hambatan karena tiga aspek: masalah kompatibilitas, masalah efisiensi, dan masalah struktur data.
1.1 Masalah utama dan paling mendesak: Masalah kompatibilitas
Karena EVM (Ethereum Virtual Machine) telah naik ke status seperti Java di ruang blockchain, EVM telah menjadi lingua franca dari internet of value yang baru. Dengan banyaknya alat, layanan, perpustakaan, dan infrastruktur, meluasnya penggunaan EVM hampir menjadi tren yang tak terhindarkan dalam lingkungan teknologi saat ini.
Ada pepatah yang beredar di Internet: "Apa pun yang dapat diimplementasikan di Java pada akhirnya akan diimplementasikan di Java".
Konsep penting namun membingungkan lainnya adalah "kompatibilitas EVM" dan "setara EVM".
Pahami kesenjangan antara keduanya dari "kedekatan" dan "metode implementasi"——
"Kompatibel": Sistem dapat mengeksekusi dan memahami bytecode EVM dengan cara yang mendukung kontrak pintar yang ditulis dalam Solidity atau bahasa EVM lainnya.
"Setara": Kesetaraan EVM memiliki standar yang lebih tinggi. Sistem yang setara dengan EVM tidak hanya mampu mengeksekusi bytecode EVM, tetapi juga sama persis dengan perilaku dan jalur EVM. Semua alat dan perpustakaan yang menargetkan Ethereum juga harus bekerja pada sistem setara EVM tanpa modifikasi apa pun.
Keuntungan dan Kerugian "EVM Setara":
Keuntungan:
Dukungan toolchain dan infrastruktur penuh: Ethereum memiliki ekosistem toolchain dan infrastruktur yang besar, termasuk berbagai alat pengembangan, kerangka pengujian, pustaka kode, dan layanan. Jika solusi L2 setara dengan EVM, maka semua alat dan layanan ini dapat berintegrasi mulus dengannya, karena dari sudut pandang mereka, solusi L2 ini seperti jaringan Ethereum lainnya.
Lebih mudah untuk menarik dan memigrasikan pengembang: Pengembang di Ethereum telah terbiasa dengan perilaku dan karakteristik EVM. Jika solusi L2 setara dengan EVM, maka pengembang dapat langsung menggunakan bahasa (seperti Solidity) dan alat yang sudah mereka kenal untuk mengembangkan solusi L2 ini tanpa mempelajari model atau bahasa pemrograman baru.
Kompatibilitas kontrak yang lebih baik: Banyak kontrak Ethereum yang ada bergantung pada perilaku spesifik EVM. Jika solusi L2 setara dengan EVM, maka kontrak ini dapat dijalankan pada solusi L2 ini tanpa atau dengan sedikit modifikasi.
Peningkatan dan fitur EVM di masa mendatang: EVM masih terus berkembang dan ditingkatkan, dan EIP (Ethereum Improvement Proposals) baru mungkin memperkenalkan fitur atau pengoptimalan baru. Peningkatan dan fitur ini dapat dengan mudah diimplementasikan pada solusi L2 jika setara dengan EVM.
Kekurangan:
Lebih rumit secara teknis: EVM adalah mesin virtual kompleks yang perilaku dan fiturnya memerlukan pemahaman mendalam dan implementasi akurat. Mencapai kesetaraan EVM dalam solusi L2 mungkin memerlukan penyelesaian beberapa kesulitan teknis, seperti cara mensimulasikan perilaku EVM dalam lingkungan konsensus atau model jaringan yang berbeda.
Kinerja dan efisiensi: EVM dirancang untuk Ethereum, dan desainnya mungkin tidak sepenuhnya sesuai dengan karakteristik dan kebutuhan solusi L2. Misalnya, EVM menggunakan bilangan bulat 256-bit untuk komputasi, sementara banyak sistem tahan-zk bekerja lebih alami pada bidang bilangan prima. Menerapkan EVM secara langsung mungkin memerlukan operasi tambahan seperti pemeriksaan jangkauan, yang dapat mengurangi kinerja dan efisiensi.
Keterbatasan fleksibilitas dan inovasi: Bersikeras pada kesetaraan EVM dapat membatasi fleksibilitas dan kemampuan inovasi solusi L2 dalam beberapa hal. Misalnya, jika solusi L2 ingin memperkenalkan fitur atau pengoptimalan baru, solusi tersebut harus memastikan bahwa perubahan ini tidak merusak kesetaraan EVM-nya.
OP menulis artikel untuk mengeksplorasi kompatibilitas EVM dan kesetaraan EVM, pada awalnya OVM yang digunakan oleh OP kemudian diubah menjadi kesetaraan EVM. Ini juga merupakan alasan penting mengapa menurut saya OP tidak melakukan ARB pada periode pertumbuhan barbar awal. Ada kesenjangan antara kompatibilitas EVM dan ARB, tetapi sekarang telah diubah, dan bahkan melampaui kompatibilitas ARB. berarti .
Dari perspektif ini, kita juga dapat memahami pentingnya kompatibilitas EVM, dan bahkan kesetaraan diperlukan untuk menarik pengembang, sehingga menciptakan pengguna, dan dengan demikian menciptakan ekologi.
1.2 Lingkungan teknis rollup ZK sebenarnya belum matang
Dari perspektif verifikasi data, verifikasi data adalah fitur utama dalam sistem blockchain, yang menjamin transparansi dan kemampuan audit sistem.
Struktur pembuktian ZK Rollup relatif kompleks, mengharuskan semua data tersedia di rantai. Ini memastikan keamanan dan integritas yang kuat, tetapi juga meningkatkan kompleksitas dan biaya penyimpanan data, yang sangat berbeda dari OP.
Rollup Optimis: OP Rollup menggunakan strategi optimis di mana transaksi diasumsikan sah kecuali ada sengketa. Pendekatan ini tidak mengharuskan semua data disimpan secara on-chain, hanya informasi yang cukup untuk memungkinkan siapa pun mempertanyakan validitas transaksi. Oleh karena itu, OP Rollup memiliki persyaratan yang relatif rendah dalam hal verifikasi data.
ZK Rollup: ZK Rollup menggunakan bukti tanpa pengetahuan (ZK-SNARKs) untuk mengompresi transaksi dan membuktikan validitasnya. Semua data transaksi harus tersedia secara on-chain sehingga siapa pun dapat menghasilkan bukti validitas. Jika skala data terlalu besar dan semuanya disimpan di rantai utama, mungkin akan terjadi hambatan kapasitas.
Seiring bertambahnya ukuran data zkSync, menyimpan semua data di rantai utama mungkin menjadi tidak layak. Hal ini mungkin memerlukan pengenalan verifikasi data eksternal, sehingga mengubah metode verifikasi sekunder yang ada dan mengurangi ketergantungan pada data jaringan utama.
Perubahan tersebut telah menimbulkan tantangan baru: bagaimana memastikan keamanan sistem sekaligus mengurangi ketergantungan pada data rantai utama?
Oleh karena itu, transformasi zkSync ke STARK juga sebagian dipicu oleh hal ini, karena STARK lebih cocok untuk menggunakan data eksternal yang dapat diverifikasi daripada SNARK.
Berdasarkan uraian di atas, implementasi ZK rollup masih perlu mengandalkan ETH untuk peningkatan yang lebih ZK-friendly, seperti peningkatan lapisan DA dan EVM.
1.3 Selain ZK rollup, ada beberapa masalah lain, seperti masalah efisiensi:
Di bidang blockchain, kecepatan Sequencer (biasanya diukur dengan jumlah transaksi per detik, TPS) merupakan indikator kunci untuk mengevaluasi kinerja sistem ZK. Sequencer bertanggung jawab atas penyortiran dan pemrosesan transaksi, dan kapasitas pemrosesannya secara langsung menentukan throughput seluruh rantai.
Namun, dalam implementasi saat ini (Zksync), kekuatan pemrosesan dari satu sequencer hanya sekitar beberapa ratus transaksi per detik, sebuah batasan yang memperlihatkan hambatan kinerja yang signifikan.
Untuk memperluas TPS, ada dua cara utama yang perlu dipertimbangkan: pertama adalah dengan terus meningkatkan kemampuan Sequencer tunggal, namun hal ini dapat meningkatkan risiko sentralisasi sistem; yang kedua adalah dengan memperkenalkan lebih banyak Sequencer untuk mendistribusikan pemrosesan. beban, meskipun melakukannya Meningkatkan desentralisasi, tetapi mengoordinasikan beberapa Sequencer dapat meningkatkan latensi dan mengurangi TPS secara keseluruhan. Masalah ini menyoroti tantangan yang ditimbang dengan hati-hati untuk menemukan keseimbangan yang tepat antara meningkatkan kinerja dan mempertahankan desentralisasi.
Arah pengembangan teknologi ZK, seperti yang ditunjukkan oleh zkSync, cenderung mendorong proses sequencer terdesentralisasi. Pilihan seperti itu akan membuat kinerja terus menjadi hambatan penting dalam pengembangan teknologi ZK. Meskipun penggunaan beberapa sequencer dan desain modular memberikan solusi tertentu, dalam praktiknya, masalah koordinasi dan sinkronisasi yang kompleks mungkin terlibat. Hal ini tidak hanya dapat memengaruhi waktu respons dan keluaran sistem, tetapi juga dapat menimbulkan tantangan keamanan dan keandalan baru.
Masalah kinerja tetap menjadi tantangan utama yang harus diselesaikan. Penelitian dan pengembangan di masa depan mungkin perlu fokus pada bagaimana meningkatkan kinerja dan skalabilitas sistem ZK dengan mengoptimalkan algoritma, strategi koordinasi, dan dukungan perangkat keras tanpa mengorbankan prinsip desentralisasi.
2. Bukti tanpa pengetahuan adalah cita-cita utama ETH
Kami telah berbicara tentang masalah ZK saat ini dan kesulitan yang dihadapinya, jadi apa alasan kematian ZK?
2.1
"Protokol Ethereum awalnya disusun sebagai versi upgrade dari cryptocurrency, menyediakan fungsionalitas canggih melalui bahasa pemrograman yang sangat umum... Protokol Ethereum jauh melampaui mata uang."
Masa depan ETH tidak terbatas pada menjadi platform transfer nilai, cita-cita utamanya adalah menciptakan dunia digital baru yang kredibel, terukur, dan terjamin privasinya.
Bukti tanpa pengetahuan adalah langkah kunci untuk membantu ETH bergerak menuju tujuan yang lebih tinggi. Bukti tanpa pengetahuan bukan hanya kemajuan teknologi ETH, tetapi juga perwujudan budaya dan filosofinya. Ini mewakili pemahaman baru dan upaya terhadap privasi, keamanan, dan skalabilitas.
2.2
Struktur sosial tradisional bergantung pada institusi terpusat untuk membangun kepercayaan. Bukti tanpa pengetahuan memungkinkan kepercayaan dibangun tanpa pengetahuan bersama. Model kepercayaan yang terdesentralisasi ini berpotensi mengubah struktur sosial, keuangan, dan pemerintahan yang ada, sehingga memicu revolusi sosial.
Struktur Ethereum saat ini mengorbankan privasi demi keamanan dan kenyamanan. ETH mengubah konsep privasi melalui pengenalan bukti tanpa pengetahuan. Orang tidak lagi harus memilih antara privasi dan keamanan, tetapi dapat menikmati kedua hak tersebut secara bersamaan.
Penerapan ZK akan memungkinkan proses verifikasi ringan untuk node ETH untuk memverifikasi validitas transaksi bahkan tanpa mengetahui data lengkapnya. Hal ini dapat mengurangi kebutuhan komputasi dan penyimpanan untuk pengoperasian node, sehingga menurunkan ambang batas untuk berpartisipasi dalam jaringan. Menurut kata-kata asli V God, "Ponsel dapat berpartisipasi dalam menjalankan node ETH".
Dengan mengurangi persyaratan perangkat keras dan pemeliharaan untuk menjalankan node, ZKP membantu memungkinkan lebih banyak peserta untuk bergabung dengan jaringan. Ini meningkatkan sifat jaringan yang terdesentralisasi, sehingga meningkatkan desentralisasi.
2.3
Penerapan ZK dapat mencegah otoritas pusat melacak dan mengganggu transaksi tertentu dengan melindungi privasi transaksi. Selain itu, desentralisasi semakin memastikan bahwa tidak ada satu titik kegagalan pun, sehingga membuat jaringan lebih sulit untuk diserang atau dimatikan.
Perlindungan privasi mendorong lebih banyak orang untuk berpartisipasi, baik individu maupun organisasi, sehingga ekosistem terbuka ini dapat tumbuh dengan bebas tanpa kendala dari otoritas pusat.
Pada akhirnya, ZK menjadikan ETH jaringan yang benar-benar global melalui integrasi privasi dan desentralisasi, dengan potensi dan elastisitas tak terbatas, tak terhapuskan seperti naga yang memasuki laut.
3. Pengetahuan nol membuktikan jalur yang masuk akal untuk penerapan di masa mendatang
Kebutuhan adalah tujuannya, masalahnya adalah status quo, lalu bagaimana jalannya?
**Mari kita bicara tentang kesimpulan terlebih dahulu: ini adalah melakukan rollup EVM ZK yang setara, dan menunggu Ethereum saat ini untuk memutakhirkan EVM yang ramah ZK, dan berjalan beriringan untuk membantu integrasi sempurna antara teknologi ZK dan ETH. **
3.1 Empat jenis ZKrollup di mulut Tuhan V
Tipe 1 (setara penuh dengan Ethereum)
ZK-EVM Tipe 1 bertujuan untuk sepenuhnya setara dengan Ethereum tanpa kompromi. Itu tidak mengubah apa pun, meskipun membuat pembuktian menjadi sulit.
Keuntungan: kompatibilitas sempurna.
Kerugian: Waktu pembuktian yang lama.
Siapa yang mengembangkannya? : Edisi Komunitas ZK-EVM.
Tipe 2 (setara EVM penuh)
ZK-EVM Tipe 2 berupaya untuk sepenuhnya setara dengan EVM, tetapi dengan perubahan pada struktur data eksternal.
Keuntungan: Persis setara di tingkat mesin virtual.
Kerugian: Peningkatan tetapi waktu pembuktian masih lambat.
Siapa yang mengembangkannya? : Gulir dan Poligon Hermez.
Tipe 3 (hampir setara dengan EVM)
Tipe 3 ZK-EVM hampir setara dengan EVM, namun beberapa kompromi dilakukan untuk lebih meningkatkan waktu pembuktian dan kemudahan pengembangan.
Keuntungan: Lebih mudah dibuat, waktu pembuktian lebih cepat.
Kerugian: lebih banyak ketidakcocokan.
Siapa yang mengembangkannya? : Gulir dan Poligon.
Tipe 4 (setara dengan bahasa tingkat tinggi)
Sistem tipe 4 bekerja dengan mengkompilasi langsung dari bahasa tingkat tinggi, tanpa eksekusi melalui EVM.
Keuntungan: Waktu pembuktian yang sangat cepat.
Kerugian: lebih banyak ketidakcocokan.
Siapa yang mengembangkannya? : ZKSync dan proyek Warp Nethermind. (catatan, StarkNet bahkan tidak kompatibel dengan EVM dan tidak termasuk dalam diskusi)
Berbagai jenis ZK-EVM menghadirkan serangkaian kompromi yang kompleks antara kompatibilitas dan efisiensi.
Tipe 1 bertujuan untuk kompatibilitas penuh, tetapi tunduk pada waktu pembuktian yang lama, yang memperlihatkan tantangan nyata bahwa Ethereum belum mempertimbangkan desain yang ramah ZK.
Tipe 2 dan Tipe 3 mencari keseimbangan antara kompatibilitas penuh dan efisiensi bukti, menunjukkan eksplorasi dan kompromi solusi praktis di bawah kondisi teknis yang ada.
Tipe 4 menjadikan efisiensi sebagai tujuan utama, namun mengorbankan kompatibilitas, sehingga membuat pembangunan ekologi menjadi sedikit sulit.
3.2 Peningkatan bersama EVM dan ZK: bekerja sama untuk bertemu di akhir
Jalur terbaik bagi ETH untuk mengimplementasikan ZK tidak hanya melibatkan implementasi ZK EVM yang setara dengan bukti tanpa pengetahuan, tetapi yang lebih penting, pemutakhiran dan transformasi EVM itu sendiri.
** Transformasi EVM ramah ZK **
Transformasi EVM yang ramah ZK adalah proses yang kompleks namun perlu. EVM tidak hanya harus setara dengan ZK-EVM, tetapi juga harus mempertimbangkan kemungkinan pengembangan ASIC ZK-SNARK di masa depan.
Kolaborasi dua arah antara ZK-EVM dan EVM
Kolaborasi antara ZK-EVM dan EVM tidak hanya terletak pada kompatibilitas dan efisiensi di tingkat teknis, tetapi juga pada integrasi alat pengembang dan dukungan pra-kompilasi.
Langkah demi langkah menuju masa depan Tipe 1
Ini adalah visi banyak orang untuk secara bertahap mewujudkan Tipe 1 melalui peningkatan berkelanjutan dari ZK-EVM dan Ethereum itu sendiri. Prosesnya mungkin lambat, namun menunjukkan jalan yang jelas menuju masa depan.
3.3 Upaya bersama dan kolaborasi dalam ekologi adalah cahayanya
Tantangan penerapan zero-knowledge proof (ZK) pada Ethereum bukan hanya masalah teknis, namun eksplorasi untuk menemukan jalur terbaik antara ideal dan kenyataan. Proses ini mengungkapkan bagaimana secara bertahap memperkenalkan solusi yang lebih cepat dan efisien dengan tetap menjaga kompatibilitas dengan infrastruktur yang ada.
Dalam proses eksplorasi ini, solusi ideal adalah membangun solusi ZK yang benar-benar setara dengan EVM yang ada, dan kemudian menunggu peningkatan EVM itu sendiri yang ramah ZK. Inti dari proses ini adalah kedua belah pihak bekerja sama dan bergerak maju bersama untuk bertemu pada titik perantara tertentu.
Gagasan upaya bersama ini tidak hanya tercermin dalam implementasi teknis, tetapi juga bagaimana membimbing seluruh komunitas untuk berkembang ke arah yang lebih aman dan terukur dengan tetap mempertahankan nilai unik Ethereum dan ekologi yang ada. Proses ini memerlukan wawasan teknis, perencanaan strategis, dan pemahaman mendalam tentang dinamika ekosistem secara keseluruhan.
Oleh karena itu, kita dapat melihat bahwa pendaratan teknologi ZK di Ethereum bukan hanya sebuah inovasi teknologi, tetapi sebuah perjalanan perubahan yang diikuti oleh seluruh ekosistem. Perjalanan ini akan membentuk masa depan Ethereum, mencari lingkungan blockchain yang menyeimbangkan inovasi dan stabilitas, kecepatan, dan kompatibilitas.
4. Ringkasan
Pembukaan era ZK tidak hanya menandai babak baru dalam ekologi Ethereum, tetapi juga lompatan bersejarah. Dalam gelombang tren ini, Ethereum tidak hanya diharapkan melampaui sistem Internet yang ada dalam beberapa aspek, tetapi juga menandai lahirnya metode koneksi yang baru dan lebih maju.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Perdagangan PSE: Dimana jalan keluar untuk bukti tanpa pengetahuan?
Posting asli oleh @Calvin, Analis Perdagangan PSE
“Secara keseluruhan, pandangan saya adalah bahwa dalam jangka pendek, Optimistic rollup lebih unggul dalam hal kompatibilitas EVM, sementara ZKrollup diharapkan lebih baik dalam lapisan pembayaran sederhana, transaksi, dan kasus penggunaan khusus lainnya.
Namun, dalam jangka menengah dan panjang, rollup ZK akan menang di semua kasus penggunaan dengan peningkatan teknologi ZK-SNARK. "
Ini adalah kata-kata asli God V di blognya "An Incomplete Guide to Rollups".
ZK adalah cita-cita ETH. Penerapan Zero-Knowledge Proofs (selanjutnya disebut sebagai ZK) dalam ekosistem Ethereum mengungkapkan kemampuannya untuk memecahkan masalah segitiga mustahil dari blockchain (yaitu, keamanan, skalabilitas, dan desentralisasi) tanpa sentralisasi. harus mengakses detail transaksi lengkap, meningkatkan skalabilitas sistem tanpa mengorbankan keamanan.
Pengenalan ZK semakin memperkuat desentralisasi sistem ETH (menurunkan ambang node) dan memastikan kemampuan desentralisasi dan anti-sensor jaringan, membuat ETH memasuki lautan seperti naga dan sulit untuk dihapus.
Dengan ZK yang begitu penting, mengapa setiap orang memiliki pengalaman buruk dalam menggunakannya, dan penerapan skala besar tidak dapat menimbulkan gelombang apa pun?
1. Masalah rollup tanpa bukti pengetahuan saat ini
Saya mengaitkan alasan mengapa bukti tanpa pengetahuan saat ini masih berada dalam periode hambatan karena tiga aspek: masalah kompatibilitas, masalah efisiensi, dan masalah struktur data.
1.1 Masalah utama dan paling mendesak: Masalah kompatibilitas
Karena EVM (Ethereum Virtual Machine) telah naik ke status seperti Java di ruang blockchain, EVM telah menjadi lingua franca dari internet of value yang baru. Dengan banyaknya alat, layanan, perpustakaan, dan infrastruktur, meluasnya penggunaan EVM hampir menjadi tren yang tak terhindarkan dalam lingkungan teknologi saat ini.
Ada pepatah yang beredar di Internet: "Apa pun yang dapat diimplementasikan di Java pada akhirnya akan diimplementasikan di Java".
Konsep penting namun membingungkan lainnya adalah "kompatibilitas EVM" dan "setara EVM".
Pahami kesenjangan antara keduanya dari "kedekatan" dan "metode implementasi"——
"Kompatibel": Sistem dapat mengeksekusi dan memahami bytecode EVM dengan cara yang mendukung kontrak pintar yang ditulis dalam Solidity atau bahasa EVM lainnya.
"Setara": Kesetaraan EVM memiliki standar yang lebih tinggi. Sistem yang setara dengan EVM tidak hanya mampu mengeksekusi bytecode EVM, tetapi juga sama persis dengan perilaku dan jalur EVM. Semua alat dan perpustakaan yang menargetkan Ethereum juga harus bekerja pada sistem setara EVM tanpa modifikasi apa pun.
Keuntungan dan Kerugian "EVM Setara":
Keuntungan:
Dukungan toolchain dan infrastruktur penuh: Ethereum memiliki ekosistem toolchain dan infrastruktur yang besar, termasuk berbagai alat pengembangan, kerangka pengujian, pustaka kode, dan layanan. Jika solusi L2 setara dengan EVM, maka semua alat dan layanan ini dapat berintegrasi mulus dengannya, karena dari sudut pandang mereka, solusi L2 ini seperti jaringan Ethereum lainnya.
Kekurangan:
OP menulis artikel untuk mengeksplorasi kompatibilitas EVM dan kesetaraan EVM, pada awalnya OVM yang digunakan oleh OP kemudian diubah menjadi kesetaraan EVM. Ini juga merupakan alasan penting mengapa menurut saya OP tidak melakukan ARB pada periode pertumbuhan barbar awal. Ada kesenjangan antara kompatibilitas EVM dan ARB, tetapi sekarang telah diubah, dan bahkan melampaui kompatibilitas ARB. berarti .
Dari perspektif ini, kita juga dapat memahami pentingnya kompatibilitas EVM, dan bahkan kesetaraan diperlukan untuk menarik pengembang, sehingga menciptakan pengguna, dan dengan demikian menciptakan ekologi.
1.2 Lingkungan teknis rollup ZK sebenarnya belum matang
Dari perspektif verifikasi data, verifikasi data adalah fitur utama dalam sistem blockchain, yang menjamin transparansi dan kemampuan audit sistem.
Struktur pembuktian ZK Rollup relatif kompleks, mengharuskan semua data tersedia di rantai. Ini memastikan keamanan dan integritas yang kuat, tetapi juga meningkatkan kompleksitas dan biaya penyimpanan data, yang sangat berbeda dari OP.
Seiring bertambahnya ukuran data zkSync, menyimpan semua data di rantai utama mungkin menjadi tidak layak. Hal ini mungkin memerlukan pengenalan verifikasi data eksternal, sehingga mengubah metode verifikasi sekunder yang ada dan mengurangi ketergantungan pada data jaringan utama.
Perubahan tersebut telah menimbulkan tantangan baru: bagaimana memastikan keamanan sistem sekaligus mengurangi ketergantungan pada data rantai utama?
Oleh karena itu, transformasi zkSync ke STARK juga sebagian dipicu oleh hal ini, karena STARK lebih cocok untuk menggunakan data eksternal yang dapat diverifikasi daripada SNARK.
Berdasarkan uraian di atas, implementasi ZK rollup masih perlu mengandalkan ETH untuk peningkatan yang lebih ZK-friendly, seperti peningkatan lapisan DA dan EVM.
1.3 Selain ZK rollup, ada beberapa masalah lain, seperti masalah efisiensi:
Di bidang blockchain, kecepatan Sequencer (biasanya diukur dengan jumlah transaksi per detik, TPS) merupakan indikator kunci untuk mengevaluasi kinerja sistem ZK. Sequencer bertanggung jawab atas penyortiran dan pemrosesan transaksi, dan kapasitas pemrosesannya secara langsung menentukan throughput seluruh rantai.
Namun, dalam implementasi saat ini (Zksync), kekuatan pemrosesan dari satu sequencer hanya sekitar beberapa ratus transaksi per detik, sebuah batasan yang memperlihatkan hambatan kinerja yang signifikan.
Untuk memperluas TPS, ada dua cara utama yang perlu dipertimbangkan: pertama adalah dengan terus meningkatkan kemampuan Sequencer tunggal, namun hal ini dapat meningkatkan risiko sentralisasi sistem; yang kedua adalah dengan memperkenalkan lebih banyak Sequencer untuk mendistribusikan pemrosesan. beban, meskipun melakukannya Meningkatkan desentralisasi, tetapi mengoordinasikan beberapa Sequencer dapat meningkatkan latensi dan mengurangi TPS secara keseluruhan. Masalah ini menyoroti tantangan yang ditimbang dengan hati-hati untuk menemukan keseimbangan yang tepat antara meningkatkan kinerja dan mempertahankan desentralisasi.
Arah pengembangan teknologi ZK, seperti yang ditunjukkan oleh zkSync, cenderung mendorong proses sequencer terdesentralisasi. Pilihan seperti itu akan membuat kinerja terus menjadi hambatan penting dalam pengembangan teknologi ZK. Meskipun penggunaan beberapa sequencer dan desain modular memberikan solusi tertentu, dalam praktiknya, masalah koordinasi dan sinkronisasi yang kompleks mungkin terlibat. Hal ini tidak hanya dapat memengaruhi waktu respons dan keluaran sistem, tetapi juga dapat menimbulkan tantangan keamanan dan keandalan baru.
Masalah kinerja tetap menjadi tantangan utama yang harus diselesaikan. Penelitian dan pengembangan di masa depan mungkin perlu fokus pada bagaimana meningkatkan kinerja dan skalabilitas sistem ZK dengan mengoptimalkan algoritma, strategi koordinasi, dan dukungan perangkat keras tanpa mengorbankan prinsip desentralisasi.
2. Bukti tanpa pengetahuan adalah cita-cita utama ETH
Kami telah berbicara tentang masalah ZK saat ini dan kesulitan yang dihadapinya, jadi apa alasan kematian ZK?
2.1
"Protokol Ethereum awalnya disusun sebagai versi upgrade dari cryptocurrency, menyediakan fungsionalitas canggih melalui bahasa pemrograman yang sangat umum... Protokol Ethereum jauh melampaui mata uang."
Masa depan ETH tidak terbatas pada menjadi platform transfer nilai, cita-cita utamanya adalah menciptakan dunia digital baru yang kredibel, terukur, dan terjamin privasinya.
Bukti tanpa pengetahuan adalah langkah kunci untuk membantu ETH bergerak menuju tujuan yang lebih tinggi. Bukti tanpa pengetahuan bukan hanya kemajuan teknologi ETH, tetapi juga perwujudan budaya dan filosofinya. Ini mewakili pemahaman baru dan upaya terhadap privasi, keamanan, dan skalabilitas.
2.2
Struktur sosial tradisional bergantung pada institusi terpusat untuk membangun kepercayaan. Bukti tanpa pengetahuan memungkinkan kepercayaan dibangun tanpa pengetahuan bersama. Model kepercayaan yang terdesentralisasi ini berpotensi mengubah struktur sosial, keuangan, dan pemerintahan yang ada, sehingga memicu revolusi sosial.
Struktur Ethereum saat ini mengorbankan privasi demi keamanan dan kenyamanan. ETH mengubah konsep privasi melalui pengenalan bukti tanpa pengetahuan. Orang tidak lagi harus memilih antara privasi dan keamanan, tetapi dapat menikmati kedua hak tersebut secara bersamaan.
Penerapan ZK akan memungkinkan proses verifikasi ringan untuk node ETH untuk memverifikasi validitas transaksi bahkan tanpa mengetahui data lengkapnya. Hal ini dapat mengurangi kebutuhan komputasi dan penyimpanan untuk pengoperasian node, sehingga menurunkan ambang batas untuk berpartisipasi dalam jaringan. Menurut kata-kata asli V God, "Ponsel dapat berpartisipasi dalam menjalankan node ETH".
Dengan mengurangi persyaratan perangkat keras dan pemeliharaan untuk menjalankan node, ZKP membantu memungkinkan lebih banyak peserta untuk bergabung dengan jaringan. Ini meningkatkan sifat jaringan yang terdesentralisasi, sehingga meningkatkan desentralisasi.
2.3
Penerapan ZK dapat mencegah otoritas pusat melacak dan mengganggu transaksi tertentu dengan melindungi privasi transaksi. Selain itu, desentralisasi semakin memastikan bahwa tidak ada satu titik kegagalan pun, sehingga membuat jaringan lebih sulit untuk diserang atau dimatikan.
Perlindungan privasi mendorong lebih banyak orang untuk berpartisipasi, baik individu maupun organisasi, sehingga ekosistem terbuka ini dapat tumbuh dengan bebas tanpa kendala dari otoritas pusat.
Pada akhirnya, ZK menjadikan ETH jaringan yang benar-benar global melalui integrasi privasi dan desentralisasi, dengan potensi dan elastisitas tak terbatas, tak terhapuskan seperti naga yang memasuki laut.
3. Pengetahuan nol membuktikan jalur yang masuk akal untuk penerapan di masa mendatang
Kebutuhan adalah tujuannya, masalahnya adalah status quo, lalu bagaimana jalannya?
**Mari kita bicara tentang kesimpulan terlebih dahulu: ini adalah melakukan rollup EVM ZK yang setara, dan menunggu Ethereum saat ini untuk memutakhirkan EVM yang ramah ZK, dan berjalan beriringan untuk membantu integrasi sempurna antara teknologi ZK dan ETH. **
3.1 Empat jenis ZKrollup di mulut Tuhan V
ZK-EVM Tipe 1 bertujuan untuk sepenuhnya setara dengan Ethereum tanpa kompromi. Itu tidak mengubah apa pun, meskipun membuat pembuktian menjadi sulit.
Keuntungan: kompatibilitas sempurna.
Kerugian: Waktu pembuktian yang lama.
Siapa yang mengembangkannya? : Edisi Komunitas ZK-EVM.
ZK-EVM Tipe 2 berupaya untuk sepenuhnya setara dengan EVM, tetapi dengan perubahan pada struktur data eksternal.
Keuntungan: Persis setara di tingkat mesin virtual.
Kerugian: Peningkatan tetapi waktu pembuktian masih lambat.
Siapa yang mengembangkannya? : Gulir dan Poligon Hermez.
Tipe 3 ZK-EVM hampir setara dengan EVM, namun beberapa kompromi dilakukan untuk lebih meningkatkan waktu pembuktian dan kemudahan pengembangan.
Keuntungan: Lebih mudah dibuat, waktu pembuktian lebih cepat.
Kerugian: lebih banyak ketidakcocokan.
Siapa yang mengembangkannya? : Gulir dan Poligon.
Sistem tipe 4 bekerja dengan mengkompilasi langsung dari bahasa tingkat tinggi, tanpa eksekusi melalui EVM.
Keuntungan: Waktu pembuktian yang sangat cepat.
Kerugian: lebih banyak ketidakcocokan.
Siapa yang mengembangkannya? : ZKSync dan proyek Warp Nethermind. (catatan, StarkNet bahkan tidak kompatibel dengan EVM dan tidak termasuk dalam diskusi)
Berbagai jenis ZK-EVM menghadirkan serangkaian kompromi yang kompleks antara kompatibilitas dan efisiensi.
Tipe 1 bertujuan untuk kompatibilitas penuh, tetapi tunduk pada waktu pembuktian yang lama, yang memperlihatkan tantangan nyata bahwa Ethereum belum mempertimbangkan desain yang ramah ZK.
Tipe 2 dan Tipe 3 mencari keseimbangan antara kompatibilitas penuh dan efisiensi bukti, menunjukkan eksplorasi dan kompromi solusi praktis di bawah kondisi teknis yang ada.
Tipe 4 menjadikan efisiensi sebagai tujuan utama, namun mengorbankan kompatibilitas, sehingga membuat pembangunan ekologi menjadi sedikit sulit.
3.2 Peningkatan bersama EVM dan ZK: bekerja sama untuk bertemu di akhir
Jalur terbaik bagi ETH untuk mengimplementasikan ZK tidak hanya melibatkan implementasi ZK EVM yang setara dengan bukti tanpa pengetahuan, tetapi yang lebih penting, pemutakhiran dan transformasi EVM itu sendiri.
Transformasi EVM yang ramah ZK adalah proses yang kompleks namun perlu. EVM tidak hanya harus setara dengan ZK-EVM, tetapi juga harus mempertimbangkan kemungkinan pengembangan ASIC ZK-SNARK di masa depan.
Kolaborasi antara ZK-EVM dan EVM tidak hanya terletak pada kompatibilitas dan efisiensi di tingkat teknis, tetapi juga pada integrasi alat pengembang dan dukungan pra-kompilasi.
Ini adalah visi banyak orang untuk secara bertahap mewujudkan Tipe 1 melalui peningkatan berkelanjutan dari ZK-EVM dan Ethereum itu sendiri. Prosesnya mungkin lambat, namun menunjukkan jalan yang jelas menuju masa depan.
3.3 Upaya bersama dan kolaborasi dalam ekologi adalah cahayanya
Tantangan penerapan zero-knowledge proof (ZK) pada Ethereum bukan hanya masalah teknis, namun eksplorasi untuk menemukan jalur terbaik antara ideal dan kenyataan. Proses ini mengungkapkan bagaimana secara bertahap memperkenalkan solusi yang lebih cepat dan efisien dengan tetap menjaga kompatibilitas dengan infrastruktur yang ada.
Dalam proses eksplorasi ini, solusi ideal adalah membangun solusi ZK yang benar-benar setara dengan EVM yang ada, dan kemudian menunggu peningkatan EVM itu sendiri yang ramah ZK. Inti dari proses ini adalah kedua belah pihak bekerja sama dan bergerak maju bersama untuk bertemu pada titik perantara tertentu.
Gagasan upaya bersama ini tidak hanya tercermin dalam implementasi teknis, tetapi juga bagaimana membimbing seluruh komunitas untuk berkembang ke arah yang lebih aman dan terukur dengan tetap mempertahankan nilai unik Ethereum dan ekologi yang ada. Proses ini memerlukan wawasan teknis, perencanaan strategis, dan pemahaman mendalam tentang dinamika ekosistem secara keseluruhan.
Oleh karena itu, kita dapat melihat bahwa pendaratan teknologi ZK di Ethereum bukan hanya sebuah inovasi teknologi, tetapi sebuah perjalanan perubahan yang diikuti oleh seluruh ekosistem. Perjalanan ini akan membentuk masa depan Ethereum, mencari lingkungan blockchain yang menyeimbangkan inovasi dan stabilitas, kecepatan, dan kompatibilitas.
4. Ringkasan
Pembukaan era ZK tidak hanya menandai babak baru dalam ekologi Ethereum, tetapi juga lompatan bersejarah. Dalam gelombang tren ini, Ethereum tidak hanya diharapkan melampaui sistem Internet yang ada dalam beberapa aspek, tetapi juga menandai lahirnya metode koneksi yang baru dan lebih maju.