Salah satu cara yang kurang dibahas, namun sangat penting, di mana Ethereum mempertahankan keamanan dan desentralisasinya adalah filosofi multi-kliennya. Ethereum secara sengaja tidak memiliki "klien referensi" yang dijalankan semua orang secara default: sebagai gantinya, ada spesifikasi yang dikelola secara kolaboratif (saat ini ditulis dalam bahasa Python yang sangat mudah dibaca tetapi sangat lambat) dan ada beberapa tim yang membuat implementasi spesifikasi (juga disebut "klien"), yang merupakan apa yang sebenarnya dijalankan oleh para pengguna.

Setiap node Ethereum menjalankan klien konsensus dan klien eksekusi. Hingga hari ini, tidak ada klien konsensus atau eksekusi yang mencapai lebih dari 2/3 jaringan. Jika klien dengan kurang dari 1/3 bagian dalam kategorinya memiliki bug, jaringan akan terus berjalan seperti biasa. Jika klien dengan antara 1/3 dan 2/3 bagian dalam kategorinya (jadi, Prysm, Lighthouse atau Geth) memiliki bug, chain akan terus menambahkan blok, tetapi akan berhenti menyelesaikan blok, memberikan waktu bagi pengembang untuk melakukan intervensi.

Salah satu transisi besar yang belum banyak dibahas, namun sangat penting, yang akan datang dalam cara rantai Ethereum divalidasi adalah munculnya ZK-EVM. SNARK yang membuktikan eksekusi EVM telah dikembangkan selama bertahun-tahun, dan teknologi ini secara aktif digunakan oleh protokol lapisan 2 yang disebut rollup ZK. Beberapa dari rollup ZK ini sudah aktif di mainnet saat ini, dan akan segera menyusul. Namun dalam jangka panjang, ZK-EVM tidak hanya akan digunakan untuk rollup; kami ingin menggunakannya untuk memverifikasi eksekusi pada layer 1 juga (lihat juga: the Verge).

Setelah itu terjadi, ZK-EVM secara de-facto menjadi jenis klien Ethereum ketiga, sama pentingnya dengan keamanan jaringan seperti halnya klien eksekusi dan klien konsensus saat ini. Dan hal ini tentu saja menimbulkan pertanyaan: bagaimana ZK-EVM berinteraksi dengan filosofi multi-klien? Salah satu bagian yang sulit telah selesai: kami telah memiliki beberapa implementasi ZK-EVM yang sedang dikembangkan secara aktif. Namun, masih ada bagian sulit lainnya: bagaimana kita membuat ekosistem "multi-klien" untuk ZK yang membuktikan kebenaran blok Ethereum? Pertanyaan ini membuka beberapa tantangan teknis yang menarik - dan tentu saja pertanyaan yang membayangi, apakah pengorbanannya sepadan atau tidak.

Apa motivasi awal dari filosofi multi-klien Ethereum?

Filosofi multi-klien Ethereum adalah sebuah jenis desentralisasi, dan seperti <a href="https://medium.com/@VitalikButerin/arti-desentralisasi-a0c92b76a274"> desentralisasi secara umum, seseorang dapat berfokus pada manfaat teknis dari desentralisasi arsitektural atau manfaat sosial dari desentralisasi politik. Pada akhirnya, filosofi multi-klien dimotivasi oleh keduanya dan melayani keduanya.

Argumen untuk desentralisasi teknis

Manfaat utama dari desentralisasi teknis adalah sederhana: mengurangi risiko bahwa satu bug pada satu perangkat lunak akan menyebabkan kerusakan besar pada seluruh jaringan. Situasi historis yang mencontohkan risiko ini adalah bug overflow Bitcoin pada tahun 2010. Pada saat itu, kode klien Bitcoin tidak memeriksa bahwa jumlah output dari sebuah transaksi tidak meluap (membungkus ke nol dengan menjumlahkan ke atas bilangan bulat maksimum^264-1), sehingga seseorang melakukan transaksi yang melakukan hal tersebut, dan memberikan miliaran bitcoin kepada dirinya sendiri. Bug ditemukan dalam beberapa jam, dan perbaikan segera dilakukan dan dengan cepat disebarkan ke seluruh jaringan, tetapi seandainya ada ekosistem yang matang pada saat itu, koin-koin tersebut akan diterima oleh bursa, jembatan, dan bangunan lainnya, dan para penyerang dapat lolos dengan banyak uang. Jika ada lima klien Bitcoin yang berbeda, sangat tidak mungkin jika semuanya memiliki bug yang sama, sehingga akan terjadi pemisahan langsung, dan sisi yang mengalami bug kemungkinan besar akan kalah.

Ada tradeoff dalam menggunakan pendekatan multi-klien untuk meminimalkan risiko bug yang sangat besar: sebagai gantinya, Anda akan mendapatkan bug kegagalan konsensus. Artinya, jika Anda memiliki dua klien, ada risiko bahwa klien memiliki interpretasi yang berbeda secara halus tentang beberapa aturan protokol, dan meskipun kedua interpretasi tersebut masuk akal dan tidak mengizinkan pencurian uang, ketidaksepakatan tersebut akan menyebabkan rantai terbelah menjadi dua. Perpecahan serius seperti itu pernah terjadi sekali dalam sejarah Ethereum (ada beberapa perpecahan lain yang jauh lebih kecil di mana sebagian kecil jaringan yang menjalankan versi kode lama bercabang). Para pembela pendekatan klien tunggal menunjukkan kegagalan konsensus sebagai alasan untuk tidak memiliki banyak implementasi: jika hanya ada satu klien, satu klien tersebut tidak akan berselisih dengan dirinya sendiri. Model mereka tentang bagaimana jumlah klien diterjemahkan ke dalam risiko mungkin terlihat seperti ini:

Saya, tentu saja, tidak setuju dengan analisis ini. Inti dari ketidaksepakatan saya adalah bahwa (i) bug bencana gaya 2010 juga penting, dan (ii) Anda tidak pernah hanya memiliki satu klien. Poin terakhir ini paling jelas terlihat pada fork Bitcoin tahun 2013: perpecahan rantai terjadi karena ketidaksepakatan antara dua versi klien Bitcoin yang berbeda, yang salah satunya ternyata memiliki batas yang tidak disengaja dan tidak terdokumentasi pada jumlah objek yang dapat dimodifikasi dalam satu blok. Oleh karena itu, satu klien dalam teori sering kali adalah dua klien dalam praktik, dan lima klien dalam teori mungkin menjadi enam atau tujuh klien dalam praktik - jadi kita harus mengambil risiko dan berada di sisi kanan kurva risiko, dan memiliki setidaknya beberapa klien yang berbeda.

Argumen untuk desentralisasi politik

Pengembang klien monopoli berada dalam posisi yang memiliki banyak kekuatan politik. Jika pengembang klien mengusulkan perubahan, dan pengguna tidak setuju, secara teoritis mereka dapat menolak untuk mengunduh versi yang diperbarui, atau membuat fork tanpa perubahan, tetapi dalam praktiknya sering kali sulit bagi pengguna untuk melakukannya. Bagaimana jika perubahan protokol yang tidak disetujui dibundel dengan pembaruan keamanan yang diperlukan? Bagaimana jika tim utama mengancam untuk berhenti jika mereka tidak mendapatkan apa yang mereka inginkan? Atau, yang lebih berbahaya, bagaimana jika tim klien monopoli akhirnya menjadi satu-satunya kelompok yang memiliki keahlian protokol terbesar, meninggalkan sisa ekosistem dalam posisi yang buruk untuk menilai argumen teknis yang diajukan oleh tim klien, sehingga tim klien memiliki banyak ruang untuk mendorong tujuan dan nilai mereka sendiri, yang mungkin tidak sesuai dengan komunitas yang lebih luas?

Kekhawatiran tentang politik protokol, terutama dalam konteks perang OP_RETURN Bitcoin 2013-14 di mana beberapa peserta secara terbuka mendukung diskriminasi terhadap penggunaan rantai tertentu, merupakan faktor penting yang berkontribusi pada adopsi awal Ethereum terhadap filosofi multi-klien, yang bertujuan untuk mempersulit sekelompok kecil orang untuk mengambil keputusan semacam itu. Kekhawatiran khusus terhadap ekosistem Ethereum - yaitu, menghindari konsentrasi kekuasaan di dalam Ethereum Foundation itu sendiri - memberikan dukungan lebih lanjut untuk arah ini. Pada tahun 2018, sebuah keputusan dibuat untuk secara sengaja membuat Yayasan tidak membuat implementasi protokol PoS Ethereum (yaitu. yang sekarang disebut "klien konsensus"), menyerahkan tugas itu sepenuhnya kepada tim luar.

Bagaimana ZK-EVM akan digunakan pada lapisan 1 di masa depan?

Saat ini, ZK-EVM digunakan dalam rollup. Hal ini meningkatkan penskalaan dengan memungkinkan eksekusi EVM yang mahal terjadi hanya beberapa kali secara off-chain, dan semua orang cukup memverifikasi SNARK yang diposting secara on-chain yang membuktikan bahwa eksekusi EVM telah dikomputasi dengan benar. Hal ini juga memungkinkan beberapa data (terutama tanda tangan) untuk tidak disertakan secara on-chain, sehingga menghemat biaya gas. Hal ini memberikan kami banyak manfaat skalabilitas, dan kombinasi komputasi yang dapat diskalakan dengan ZK-EVM dan data yang dapat diskalakan dengan <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> data-availability-sampling memungkinkan kami untuk melakukan skalabilitas yang sangat jauh.

Akan tetapi, jaringan Ethereum saat ini juga memiliki masalah yang berbeda, masalah yang tidak dapat diselesaikan oleh penskalaan lapisan 2 dengan sendirinya: lapisan 1 sulit untuk diverifikasi, sampai-sampai tidak banyak pengguna yang menjalankan node mereka sendiri. Sebaliknya, sebagian besar pengguna hanya mempercayai penyedia pihak ketiga. Klien ringan seperti Helios dan Succinct mengambil langkah untuk menyelesaikan masalah, tetapi klien ringan jauh dari simpul yang memverifikasi sepenuhnya: klien ringan hanya memverifikasi tanda tangan dari subset acak validator yang disebut komite sinkronisasi, dan tidak memverifikasi bahwa rantai tersebut benar-benar mengikuti aturan protokol. Untuk membawa kita ke dunia di mana pengguna benar-benar dapat memverifikasi bahwa rantai pasok mengikuti aturan, kita harus melakukan sesuatu yang berbeda.

Opsi 1: menyempitkan lapisan 1, memaksa hampir semua aktivitas untuk berpindah ke lapisan 2

Seiring waktu, kami dapat mengurangi target gas per blok layer 1 dari 15 juta menjadi 1 juta, cukup untuk satu blok yang berisi satu SNARK dan beberapa operasi setoran dan penarikan, tetapi tidak lebih dari itu, dan dengan demikian memaksa hampir semua aktivitas pengguna untuk pindah ke protokol layer 2. Desain seperti itu masih dapat mendukung banyak rollup yang dilakukan di setiap blok: kita dapat menggunakan protokol agregasi off-chain yang dijalankan oleh pembangun yang disesuaikan untuk mengumpulkan SNARK dari beberapa protokol layer 2 dan menggabungkannya menjadi satu SNARK. Dalam dunia seperti itu, satu-satunya fungsi lapisan 1 adalah menjadi lembaga kliring untuk protokol lapisan 2, memverifikasi bukti-bukti mereka dan kadang-kadang memfasilitasi transfer dana dalam jumlah besar di antara mereka.

Pendekatan ini bisa saja berhasil, tetapi memiliki beberapa kelemahan penting:

• Secara de-facto tidak kompatibel ke belakang, dalam arti bahwa banyak aplikasi berbasis L1 yang ada menjadi tidak dapat digunakan secara ekonomis. Dana pengguna hingga ratusan atau ribuan dolar dapat macet karena biaya menjadi sangat tinggi sehingga melebihi biaya untuk mengosongkan akun tersebut. Hal ini dapat diatasi dengan membiarkan pengguna menandatangani pesan untuk ikut serta dalam migrasi massal dalam protokol ke L2 pilihan mereka (lihat beberapa ide implementasi awal di sini), tetapi hal ini akan menambah kerumitan pada transisi, dan untuk membuatnya benar-benar cukup murah akan membutuhkan semacam SNARK di lapisan 1. Saya umumnya adalah penggemar dari melanggar kompatibilitas ke belakang dalam hal <a href="https://hackmd.io/@vbuterin/selfdestruct"> hal-hal seperti opcode SELFDESTRUCT, tetapi dalam hal ini pengorbanannya tampaknya jauh lebih tidak menguntungkan.
• Ini mungkin masih belum membuat verifikasi cukup murah. Idealnya, protokol Ethereum harus mudah diverifikasi tidak hanya di laptop tetapi juga di dalam ponsel, ekstensi peramban, dan bahkan di dalam chain lain. Menyinkronkan rantai untuk pertama kalinya, atau setelah lama offline, seharusnya juga mudah. Sebuah simpul laptop dapat memverifikasi 1 juta gas dalam ~ 20 ms, tetapi bahkan itu menyiratkan 54 detik untuk menyinkronkan setelah satu hari offline (dengan asumsi <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single finalitas slot meningkatkan waktu slot hingga 32 detik), dan untuk ponsel atau ekstensi peramban, dibutuhkan beberapa ratus milidetik per blok dan mungkin masih menguras baterai yang tidak dapat diabaikan. Angka-angka ini dapat dikelola, tetapi tidak ideal.
• Bahkan dalam ekosistem yang mengutamakan L2, ada manfaat dari L1 yang setidaknya agak terjangkau. Validium dapat memperoleh manfaat dari model keamanan yang lebih kuat jika pengguna dapat menarik dana mereka jika mereka menyadari bahwa data negara bagian yang baru tidak lagi tersedia. Arbitrase menjadi lebih efisien, terutama untuk token yang lebih kecil, jika ukuran minimum transfer langsung lintas-L2 yang layak secara ekonomi lebih kecil.

Oleh karena itu, tampaknya lebih masuk akal untuk mencoba menemukan cara menggunakan ZK-SNARK untuk memverifikasi lapisan 1 itu sendiri.

Opsi 2: SNARK-verifikasi lapisan 1

ZK-EVM tipe 1 (sepenuhnya setara dengan Ethereum) dapat digunakan untuk memverifikasi eksekusi EVM dari sebuah blok Ethereum (lapisan 1). Kita dapat menulis lebih banyak kode SNARK untuk memverifikasi sisi konsensus dari sebuah blok. Ini akan menjadi masalah teknik yang menantang: saat ini, ZK-EVM membutuhkan waktu beberapa menit hingga beberapa jam untuk memverifikasi blok Ethereum, dan menghasilkan bukti secara real time akan membutuhkan satu atau lebih dari (i) peningkatan pada Ethereum itu sendiri untuk menghapus komponen yang tidak ramah SNARK, (ii) peningkatan efisiensi yang besar dengan perangkat keras khusus, dan (iii) peningkatan arsitektur dengan paralelisasi yang lebih banyak. Namun, tidak ada alasan teknologi yang mendasar mengapa hal ini tidak dapat dilakukan - dan saya berharap bahwa, meskipun membutuhkan waktu bertahun-tahun, hal ini akan terlaksana.

Di sinilah kita melihat titik temu dengan paradigma multi-klien: jika kita menggunakan ZK-EVM untuk memverifikasi lapisan 1, ZK-EVM mana yang kita gunakan?

Saya melihat ada tiga pilihan:

1. ZK-EVM tunggal: tinggalkan paradigma multi-klien, dan pilihlah ZK-EVM tunggal yang kita gunakan untuk memverifikasi blok.
2. Multi ZK-EVM tertutup: menyepakati dan mengabadikan dalam konsensus satu set tertentu dari beberapa ZK-EVM, dan memiliki aturan protokol lapisan konsensus bahwa sebuah blok membutuhkan bukti dari lebih dari setengah ZK-EVM dalam set tersebut untuk dapat dianggap valid.
3. Multi ZK-EVM terbuka: klien yang berbeda memiliki implementasi ZK-EVM yang berbeda, dan setiap klien menunggu bukti yang kompatibel dengan implementasinya sendiri sebelum menerima blok sebagai valid.

Bagi saya, (3) tampaknya ideal, setidaknya sampai dan kecuali teknologi kita meningkat ke titik di mana kita dapat secara resmi membuktikan bahwa semua implementasi ZK-EVM setara satu sama lain, di mana pada saat itu kita dapat memilih mana yang paling efisien. (1) akan mengorbankan manfaat dari paradigma multi-klien, dan (2) akan menutup kemungkinan untuk mengembangkan klien baru dan mengarah pada ekosistem yang lebih terpusat. (3) memiliki tantangan, tetapi tantangan tersebut tampaknya lebih kecil dibandingkan dengan tantangan dari dua opsi lainnya, setidaknya untuk saat ini.

Menerapkan (3) tidak akan terlalu sulit: seseorang dapat memiliki sub-jaringan p2p untuk setiap jenis bukti, dan klien yang menggunakan salah satu jenis bukti akan mendengarkan pada sub-jaringan yang sesuai dan menunggu sampai mereka menerima bukti yang dikenali oleh verifikator mereka sebagai bukti yang valid.

Dua tantangan utama dari (3) kemungkinan adalah sebagai berikut:

• Tantangan latensi: penyerang jahat dapat mempublikasikan blok terlambat, bersama dengan bukti yang valid untuk satu klien. Secara realistis akan membutuhkan waktu yang lama (bahkan jika misalnya 15 detik) untuk menghasilkan bukti yang valid untuk klien lain. Waktu ini akan cukup lama untuk berpotensi membuat fork sementara dan mengganggu rantai untuk beberapa slot.
• Inefisiensi data: salah satu manfaat dari ZK-SNARK adalah data yang hanya relevan untuk verifikasi (terkadang disebut "data saksi") dapat dihapus dari sebuah blok. Sebagai contoh, setelah Anda memverifikasi sebuah tanda tangan, Anda tidak perlu menyimpan tanda tangan tersebut dalam sebuah blok, Anda bisa menyimpan satu bit yang menyatakan bahwa tanda tangan tersebut valid, bersama dengan satu bukti dalam blok yang mengonfirmasi bahwa semua tanda tangan yang valid ada. Akan tetapi, jika kita ingin membuat bukti dari berbagai jenis untuk sebuah blok, tanda tangan asli harus benar-benar dipublikasikan.

Tantangan latensi dapat diatasi dengan berhati-hati saat merancang protokol finalitas slot tunggal. Protokol finalitas slot tunggal kemungkinan akan membutuhkan lebih dari dua putaran konsensus per slot, dan dengan demikian, seseorang dapat meminta putaran pertama untuk menyertakan blok, dan hanya membutuhkan node untuk memverifikasi bukti sebelum menandatangani di putaran ketiga (atau terakhir). Hal ini memastikan bahwa jendela waktu yang signifikan selalu tersedia antara tenggat waktu penerbitan blok dan waktu yang diharapkan untuk bukti-bukti yang tersedia.

Masalah efisiensi data harus diatasi dengan memiliki protokol terpisah untuk mengumpulkan data terkait verifikasi. Untuk tanda tangan, kita dapat menggunakan agregasi BLS, yang sudah didukung oleh ERC-4337. Kategori utama lain dari data terkait verifikasi adalah ZK-SNARK yang digunakan untuk privasi. Untungnya, ini sering kali cenderung memiliki protokol agregasi sendiri.

Perlu juga disebutkan bahwa verifikasi SNARK pada lapisan 1 memiliki manfaat penting: fakta bahwa eksekusi EVM on-chain tidak perlu lagi diverifikasi oleh setiap node sehingga memungkinkan untuk meningkatkan jumlah eksekusi EVM yang terjadi. Hal ini dapat terjadi, baik dengan meningkatkan batas gas lapisan 1 secara drastis, atau dengan memperkenalkan rollup yang diabadikan, atau keduanya.

Kesimpulan

Membuat ekosistem ZK-EVM multi-klien terbuka bekerja dengan baik akan membutuhkan banyak pekerjaan. Tetapi kabar baiknya adalah bahwa sebagian besar dari pekerjaan ini sedang atau akan terjadi:

• Kami telah memiliki beberapa implementasi ZK-EVM yang kuat. Implementasi ini belum menjadi tipe 1 (sepenuhnya setara dengan Ethereum), tetapi banyak di antaranya yang secara aktif bergerak ke arah itu.
• Pekerjaan pada klien ringan seperti Helios dan Succinct pada akhirnya dapat berubah menjadi verifikasi SNARK yang lebih lengkap dari sisi konsensus PoS rantai Ethereum.
• Klien kemungkinan akan mulai bereksperimen dengan ZK-EVM untuk membuktikan eksekusi blok Ethereum sendiri, terutama setelah kami memiliki klien tanpa kewarganegaraan dan tidak ada kebutuhan teknis untuk secara langsung mengeksekusi ulang setiap blok untuk mempertahankan status. Kita mungkin akan mendapatkan transisi yang lambat dan bertahap dari klien yang memverifikasi blok Ethereum dengan mengeksekusinya kembali ke sebagian besar klien yang memverifikasi blok Ethereum dengan memeriksa bukti SNARK.
• Ekosistem ERC-4337 dan PBS kemungkinan besar akan mulai bekerja dengan teknologi agregasi seperti BLS dan agregasi bukti dalam waktu dekat, untuk menghemat biaya gas. Pada agregasi BLS, pekerjaan telah dimulai.

Dengan adanya teknologi ini, masa depan terlihat sangat cerah. Blok Ethereum akan lebih kecil daripada saat ini, siapa pun dapat menjalankan node yang sepenuhnya memverifikasi di laptop atau bahkan ponsel mereka atau di dalam ekstensi browser, dan ini semua akan terjadi sambil mempertahankan manfaat filosofi multi-klien Ethereum.

Dalam jangka waktu yang lebih panjang, tentu saja apa pun bisa terjadi. Mungkin AI akan meningkatkan verifikasi formal ke titik di mana ia dapat dengan mudah membuktikan implementasi ZK-EVM yang setara dan mengidentifikasi semua bug yang menyebabkan perbedaan di antara keduanya. Proyek semacam itu bahkan mungkin merupakan sesuatu yang praktis untuk mulai dikerjakan sekarang. Jika pendekatan berbasis verifikasi formal seperti itu berhasil, mekanisme yang berbeda perlu dilakukan untuk memastikan desentralisasi politik yang berkelanjutan dari protokol tersebut; mungkin pada saat itu, protokol tersebut akan dianggap "lengkap" dan norma-norma keabadian akan menjadi lebih kuat. Tetapi meskipun itu adalah masa depan jangka panjang, dunia ZK-EVM multi-klien yang terbuka tampaknya seperti batu loncatan alami yang kemungkinan besar akan terjadi.

Dalam waktu dekat, ini masih merupakan perjalanan yang panjang. ZK-EVM sudah ada di sini, tetapi ZK-EVM menjadi benar-benar layak di lapisan 1 akan mengharuskannya menjadi tipe 1, dan membuat pembuktian yang cukup cepat sehingga dapat terjadi secara real time. Dengan paralelisasi yang cukup, hal ini dapat dilakukan, tetapi masih banyak pekerjaan yang harus dilakukan untuk mencapainya. Perubahan konsensus seperti menaikkan biaya gas KECCAK, SHA256 dan precompile fungsi hash lainnya juga akan menjadi bagian penting dalam gambaran ini. Meskipun demikian, langkah pertama dari transisi ini dapat terjadi lebih cepat dari yang kita harapkan: setelah kita beralih ke pohon Verkle dan klien tanpa kewarganegaraan, klien dapat mulai secara bertahap menggunakan ZK-EVM, dan transisi ke dunia "multi-ZK-EVM terbuka" dapat mulai terjadi dengan sendirinya.

Penafian: Penafian

1. Artikel ini dicetak ulang dari[vitalik], Semua hak cipta adalah milik penulis asli[vitalik]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.