Judul Asli: "Masa Depan yang Mungkin dari Protokol Ethereum, Bagian 4: The Verge"

Penulis asli: Vitalik Buterin

Terjemahan asli: Mensh, ChainCatcher

Terima kasih khusus kepada Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams dan Uma Roy atas umpan balik dan peninjauan mereka.

Salah satu fitur terkuat dari Blok adalah bahwa siapa saja dapat menjalankan Node di komputernya dan memverifikasi kebenaran Blok. Bahkan jika 9596 Node yang menjalankan Konsensus (PoW, PoS) setuju untuk mengubah aturan dengan satu suara dan mulai memproduksi Blok sesuai aturan baru, setiap orang yang menjalankan Node yang telah diverifikasi secara penuh akan menolak untuk menerima rantai tersebut. Penambang yang tidak terlibat dalam konspirasi semacam itu akan secara otomatis berkumpul ke dalam rantai on-chain yang masih mengikuti aturan lama dan melanjutkan membangun rantai tersebut, sedangkan pengguna yang sepenuhnya diverifikasi akan mengikuti rantai tersebut.

Ini adalah perbedaan kunci antara blockchain dan sistem terpusat. Namun, untuk menjadikan fitur ini menjadi kenyataan, menjalankan Node verifikasi penuh memerlukan menjadi memungkinkan bagi cukup banyak orang. Hal ini berlaku baik untuk pembuat kebijakan (karena jika mereka tidak memverifikasi rantai, mereka tidak memberikan kontribusi untuk menerapkan aturan protokol), maupun untuk pengguna biasa. Saat ini, menjalankan Node pada laptop konsumen (termasuk laptop yang digunakan saat menulis artikel ini) memungkinkan, namun sulit untuk melakukannya. The Verge bertujuan mengubah situasi ini, dengan mengurangi biaya komputasi Node verifikasi penuh, sehingga setiap dompet ponsel, dompet browser, bahkan smartwatch akan secara default melakukan verifikasi.

Peta Jalan The Verge 2023

Awalnya, "Verge" mengacu pada transfer status penyimpanan ETH ke pohon Verkle - struktur pohon yang memungkinkan bukti yang lebih padat dan validasi tanpa status blok ETH. Node dapat memvalidasi blok ETH tanpa perlu menyimpan status ETH (saldo akun, kode kontrak, ruang penyimpanan...) di disknya, dengan biaya data bukti sekitar beberapa ratus KB dan waktu ekstra beberapa ratus milidetik untuk memvalidasi satu bukti. Saat ini, Verge mewakili visi yang lebih besar, fokus pada implementasi validasi sumber daya maksimum rantai ETH, yang mencakup tidak hanya teknologi validasi tanpa status, tetapi juga validasi SNARK untuk semua eksekusi ETH.

Selain ikuti jangka panjang validasi SNARK dari seluruh rantai, pertanyaan baru lainnya berkaitan dengan apakah pohon Verkle adalah teknik terbaik. Pohon Verkle rentan terhadap Komputer Kuantum, jadi jika kita mengambil pohon Verkle di pohon KECCAK Merkle Patricia saat ini, kita harus mengganti pohon itu lagi di masa depan. Alternatif mandiri untuk pohon Merkle adalah dengan melewatkan STARK yang menggunakan cabang Merkle dan memasukkannya ke dalam pohon biner. Secara historis, pendekatan ini dianggap tidak layak karena overhead dan kompleksitas teknis. Baru-baru ini, meskipun, kita telah melihat Starkware membuktikan 1,7 juta Poseidon hash per detik menggunakan ckcle STARKs pada satu laptop, dan waktu bukti untuk nilai hash yang lebih "tradisional" menurun dengan cepat berkat teknologi seperti GKB. Jadi, selama setahun terakhir, "Verge" menjadi lebih terbuka, ia memiliki beberapa kemungkinan.

The Verge: Tujuan Utama

• Mesin pelanggan tanpa status: ruang penyimpanan yang diperlukan untuk mesin pelanggan yang diverifikasi sepenuhnya dan penanda Node tidak boleh melebihi beberapa GB.
• (Jangka Panjang) Validasi lengkap rantai pada jam tangan pintar (Konsensus dan eksekusi). Unduh beberapa data, verifikasi SNARK, selesai.

Dalam bab ini

• Klien tanpa status: Verkle masih STARKs
• Bukti validitas yang dilaksanakan oleh EVM
• Konsensus bukti validitas

Verifikasi Non-Status: Verkle atau STARKs

Apa masalah yang ingin kita selesaikan?

Saat ini, klien ETH perlu menyimpan ratusan ribu megabita data status untuk memverifikasi Blok, dan jumlah ini terus meningkat setiap tahunnya. Data status asli meningkat sekitar 30 GB setiap tahun, dan klien tunggal harus menyimpan beberapa data tambahan di atasnya untuk efektif memperbarui triplenya.

Ini mengurangi jumlah pengguna yang dapat menjalankan Node Ethereum validasi lengkap: meskipun hard disk besar yang dapat menyimpan semua status Ethereum bahkan sejarah bertahun-tahun tersedia di mana-mana, komputer yang dibeli orang secara default sering hanya memiliki beberapa ratus gigabyte ruang penyimpanan. Ukuran status juga membawa friksi besar dalam proses pembuatan Node pertama kalinya: Node perlu mengunduh seluruh status, yang mungkin memerlukan waktu berjam-jam atau bahkan berhari-hari. Ini menghasilkan berbagai reaksi berantai. Misalnya, ini sangat meningkatkan kesulitan pembuat Node untuk memperbarui pengaturan Node mereka. Secara teknis, Anda dapat melakukan upgrade tanpa mematikan mesin - memulai klien baru, menunggu sinkronisasi, kemudian menutup klien lama dan mentransfer Kunci Rahasia - tetapi dalam praktiknya, ini sangat rumit secara teknis.

Bagaimana cara kerjanya?

Verifikasi tanpa status adalah teknologi yang memungkinkan Node untuk memverifikasi Blok tanpa memiliki seluruh status. Sebagai gantinya, setiap Blok dilengkapi dengan saksi yang mencakup: (i) nilai, kode, saldo, dan penyimpanan pada posisi tertentu dalam status yang akan diakses oleh Blok tersebut; (ii) bukti enkripsi yang memastikan nilai-nilai tersebut benar.

Sebenarnya, untuk mencapai verifikasi tanpa status, perlu mengubah struktur pohon status Ethereum. Hal ini karena pohon Merkle Patricia saat ini sangat tidak ramah terhadap implementasi skema enkripsi apa pun, terutama dalam kasus terburuk. Baik itu cabang Merkle asli, atau kemungkinan 'dibungkus' menjadi STARK, semuanya begitu. Kesulitan utama berasal dari beberapa kelemahan MPT:

1. Ini adalah pohon berarah enam (yaitu setiap Node memiliki 16 anak Node). Ini berarti dalam pohon berukuran N, sebuah bukti rata-rata membutuhkan 32 * (16-1) * log 16(N) = 120 * log 2(N) byte, atau sekitar 3840 byte dalam pohon dengan 2 ^ 32 item. Untuk pohon biner, hanya membutuhkan 32 * (2-1) * log 2(N) = 32 * log 2(N) byte, atau sekitar 1024 byte.

2. Kode tidak dimerkle. Ini berarti untuk membuktikan akses akun kode, semua kode harus disediakan, maksimal 24000 byte.

Kita dapat menghitung situasi terburuk sebagai berikut:

30000000 gas / 2400 (biaya baca akun dingin) * (5 * 488 + 24000) = 330000000 byte

Biaya cabang sedikit menurun (diganti dengan 5 * 480 daripada 8 * 480), karena bagian atasnya akan muncul berulang ketika ada banyak cabang. Namun demikian, jumlah data yang harus diunduh dalam satu slot sangat tidak realistis. Jika kita mencoba mengemasnya dengan STARK, kita akan menghadapi dua masalah: (i) KECCAK tidak ramah terhadap STARK; (ii) 330 MB data berarti kita harus membuktikan 5 juta panggilan fungsi putaran KECCAK, yang mungkin tidak bisa dibuktikan oleh semua perangkat keras kecuali perangkat keras konsumen paling canggih, meskipun kita dapat meningkatkan efisiensi pembuktian KECCAK dengan STARK.

Jika kita mengganti pohon heksadesimal dengan pohon biner secara langsung dan melakukan pemrosesan Merkle tambahan pada kode, maka dalam kasus terburuknya akan menjadi sekitar 30000000/2400* 32*( 32-14+ 8) = 10400000 byte (14 adalah pengurangan redundansi bit bercabang 2 ^ 14, sementara 8 adalah panjang bukti masuk ke blok kode). Perlu diingat bahwa ini akan mengubah biaya gas, dengan membebankan setiap akses blok kode secara terpisah; EIP-4762 melakukan hal ini. Kapasitas 10,4 MB tentu lebih baik, tetapi masih terlalu banyak data untuk diunduh dalam satu slot waktu bagi banyak Node. Oleh karena itu, kita perlu memperkenalkan teknologi yang lebih kuat. Di sini, ada dua solusi terdepan: pohon Verkle dan pohon hash biner STARKed.

Pohon Verkle

Verkle tree menggunakan komitmen vektor berbasis kurva elips untuk membuktikan yang lebih singkat. Kunci dari hal ini, tidak peduli seberapa lebar pohonnya, setiap bagian bukti untuk setiap hubungan parent-child hanya 32 byte. Satu-satunya batasan lebar pohon bukti adalah, jika pohon bukti terlalu lebar, efisiensi perhitungan bukti akan menurun. Solusi yang diusulkan untuk implementasi Ethereum memiliki lebar 256.

Oleh karena itu, bukti ukuran tunggal dalam cabang menjadi 32 - 1 OG 256(N) = 4* log 2(N) byte. Oleh karena itu, ukuran bukti maksimum secara teoritis kurang lebih 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 byte (karena distribusi blok status tidak merata, hasil perhitungan sebenarnya sedikit berbeda, tetapi sebagai nilai perkiraan pertama itu bisa diterima).

Selain itu, perlu diperhatikan bahwa dalam semua contoh di atas, "kasus terburuk" ini bukanlah kasus terburuk sebenarnya: skenario yang lebih buruk adalah ketika penyerang dengan sengaja "menggali" dua Alamat yang memiliki awalan umum yang panjang dalam pohon, dan membaca data dari salah satu Alamat tersebut, yang dapat memperpanjang panjang cabang dalam kasus terburuk sebesar 2 kali lipat. Namun, bahkan dalam kasus seperti itu, panjang bukti terburuk dari pohon Verkle adalah 2,6 MB, yang hampir sama dengan data verifikasi terburuk saat ini.

Kami juga melakukan sesuatu dengan perhatian ini: kami membuat biaya akses ke ruang penyimpanan 'tetangga' menjadi sangat murah: baik itu banyak blok kode kontrak yang sama atau slot penyimpanan yang berdekatan. EIP-4762 menyediakan definisi tetangga, dan biaya akses tetangga hanya dikenakan biaya 200 gas. Dalam kasus akses tetangga, ukuran bukti dalam kasus terburuk menjadi 30000000 / 200 * 32 - 4800800 byte, yang masih berada dalam kisaran toleransi. Jika untuk alasan keamanan, kami ingin mengurangi nilai ini, biaya akses tetangga dapat sedikit dinaikkan.

Pohon Hash Binari STARKed

Prinsip teknologi ini jelas: Anda hanya perlu membuat pohon biner, dapatkan bukti maksimum 10,4 MB, buktikan nilai dalam blok, kemudian gantikan bukti dengan STARK. Dengan demikian, bukti itu sendiri hanya berisi data yang dibuktikan, ditambah biaya tetap 100-300 kB dari STARK aktual.

Tantangan utama di sini adalah memverifikasi waktu. Kita dapat melakukan perhitungan yang hampir sama dengan di atas, hanya saja yang kita hitung bukanlah jumlah byte, melainkan nilai hash. Blok dengan ukuran 10,4 MB berarti 330.000 nilai hash. Jika kita juga mempertimbangkan kemungkinan bahwa penyerang 'mengeruk' Alamat pohon dengan awalan umum yang panjang, maka nilai hash dalam kasus terburuk akan mencapai sekitar 660.000 nilai hash. Oleh karena itu, jika kita dapat membuktikan bahwa nilai hash per detik adalah 200.000, maka itu tidak masalah.

Pada laptop konsumen yang menggunakan fungsi hash Poseidon, angka-angka ini telah mencapai, sementara fungsi hash Poseidon dirancang khusus untuk ke-Stark-an. Namun, sistem Poseidon masih tergolong belum matang, sehingga banyak orang masih meragukan keamanannya. Oleh karena itu, ada dua jalur kemajuan nyata:

1. Melakukan analisis keamanan besar-besaran terhadap Poseidon dengan cepat, dan cukup mengenalnya untuk dideploy di L1
2. Menggunakan fungsi hash yang lebih "konservatif ", seperti SHA 256 atau BLAKE

Untuk membuktikan fungsi hash yang konservatif, sirkuit STARK dari Starkware hanya dapat membuktikan 10-30k nilai hash per detik pada laptop konsumen saat artikel ini ditulis. Namun, teknologi STARK sedang mengalami peningkatan yang cepat. Bahkan pada saat ini, teknologi berbasis GKR juga menunjukkan kemampuan untuk meningkatkan kecepatan ini menjadi rentang 100-200k.

Kecuali kasus penggunaan saksi di luar blok verifikasi

Selain memverifikasi Blok, ada tiga kasus penggunaan kunci lain yang membutuhkan verifikasi tanpa status yang lebih efisien:

• Memori Pool: Ketika transaksi disiarkan, Node dalam jaringan P2P perlu memvalidasi apakah transaksi tersebut valid sebelum disiarkan ulang. Validasi saat ini meliputi verifikasi tanda tangan, serta memeriksa apakah saldo mencukupi dan apakah awalan benar. Di masa depan (misalnya, dengan menggunakan abstraksi akun asli, seperti EIP-7701), ini mungkin melibatkan menjalankan beberapa kode EVM yang melakukan akses ke status. Jika Node bersifat stateless, transaksi perlu dilengkapi dengan bukti tentang objek status.
• Termasuk daftar: Ini adalah fitur yang diusulkan yang memungkinkan validator Proof of Stake (mungkin dalam skala kecil dan tidak terlalu rumit) untuk memaksa Blok berikutnya mengandung transaksi, tanpa memperhatikan keinginan pembangun Blok (mungkin dalam skala besar dan rumit). Ini akan melemahkan kemampuan pemegang kekuasaan untuk memanipulasi rantai Blok melalui latensi transaksi. Namun, ini memerlukan validator memiliki cara untuk memverifikasi validitas transaksi dalam daftar yang disertakan.
• klien ringan: Jika kita ingin pengguna mengakses rantai melalui dompet (seperti Metamask, Rainbow, Rabby, dll.), untuk mencapai ini, mereka perlu menjalankan klien ringan (seperti Helios). Modul inti Helios menyediakan root status yang diverifikasi untuk pengguna. Namun, untuk mendapatkan pengalaman yang sepenuhnya tanpa kepercayaan, pengguna perlu memberikan bukti untuk setiap panggilan RPC yang mereka lakukan (misalnya, untuk permintaan panggilan jaringan ETH (pengguna perlu membuktikan semua status yang diakses selama panggilan tersebut).

Semua kasus penggunaan ini memiliki satu kesamaan, yaitu mereka memerlukan banyak bukti, tetapi setiap bukti sangat kecil. Oleh karena itu, bukti STARK tidak memiliki makna yang praktis bagi mereka; sebaliknya, pendekatan yang paling realistis adalah dengan langsung menggunakan cabang Merkle. Keuntungan lain dari cabang Merkle adalah dapat diperbarui: dengan memberikan bukti objek status X dengan akar Blok B, jika menerima sebuah subBlok B 2 beserta buktinya, maka bukti dapat diperbarui sehingga akar menjadi Blok B 2. Bukti Verkle juga merupakan bukti yang dapat diperbarui secara alami.

Apa hubungannya dengan penelitian yang ada:

• Pohon Verkle
• John Kuszmaul 关于 Verkle tree 的原始论文
• Starkware
• Poseidon 2 kertas
• Ajtai (fungsi hash alternatif cepat berbasis kekerasan kisi kristal)
• Verkle.info

Masih bisa melakukan apa lagi?

Tugas utama yang tersisa adalah

1. Analisis Lebih Lanjut tentang Konsekuensi EIP-4762 (Perubahan Biaya Gas yang Tidak Berkeadaan)

2. Melakukan lebih banyak pekerjaan pada program transisi dan pengujian, ini adalah bagian utama dari kompleksitas implementasi solusi tanpa negara

3. Analisis keamanan lebih lanjut terhadap fungsi hash Poseidon, Ajtai, dan lainnya yang "ramah STARK"

4. Untuk mengembangkan fungsi protokol STARK yang sangat efisien untuk "konservatif" (atau "tradisional") hash lebih lanjut, misalnya berdasarkan pandangan Binius atau GKR.

Selain itu, kami akan segera memutuskan untuk memilih salah satu dari tiga pilihan berikut: (i) Pohon Verkle, (ii) Fungsi hash Ramah STARK, dan (iii) Fungsi hash konservatif. Karakteristik mereka dapat disimpulkan secara kasar dalam tabel di bawah ini:

Selain "nomor judul" ini, ada beberapa faktor penting lainnya yang perlu dipertimbangkan:

• Saat ini, kode pohon Verkle sudah cukup matang. Selain Verkle, penggunaan kode lain akan menunda implementasi, dan kemungkinan besar akan menunda fork keras. Ini tidak masalah, terutama jika kita memerlukan waktu tambahan untuk analisis fungsi hash atau implementasi validator, atau jika kita memiliki fitur penting lain yang ingin kita masukkan lebih awal ke dalam Ethereum.
• Menggunakan nilai hash untuk memperbarui akar status lebih cepat daripada menggunakan pohon Verkle. Ini berarti metode berbasis nilai hash dapat mengurangi waktu sinkronisasi Node penuh.
• Pohon Verkle memiliki sifat saksi yang menarik untuk diperbarui - saksi Pohon Verkle dapat diperbarui. Properti ini berguna untuk mempool, daftar yang berisi, dan penggunaan lainnya, dan juga dapat membantu meningkatkan efisiensi implementasi: jika objek status diperbarui, saksi lapisan kedua dapat diperbarui tanpa perlu membaca konten lapisan terakhir.
• Pohon Verkle lebih sulit untuk melakukan bukti SNARK. Jika kita ingin mengurangi ukuran bukti menjadi beberapa ribu byte, maka bukti Verkle akan menghadapi beberapa kesulitan. Hal ini karena verifikasi bukti Verkle memperkenalkan banyak operasi 256 bit, yang membutuhkan biaya besar pada sistem bukti atau struktur internal yang khusus dengan bagian bukti Verkle 256 bit. Ini tidak menjadi masalah untuk status yang tidak ada tetapi akan menimbulkan lebih banyak kesulitan.

Jika kita ingin mendapatkan sifat verifikasi yang dapat diperbarui dari Verkle dengan cara yang aman secara kuantum dan efisien, pendekatan lain yang mungkin adalah menggunakan pohon Merkle berbasis lattice.

Jika dalam kasus terburuk, membuktikan bahwa efisiensi sistem tidak cukup tinggi, maka kita masih dapat menggunakan alat yang tidak terduga ini, gas multi-dimensi, untuk mengatasi kekurangan ini: menyediakan (i) calldata; (ii) perhitungan; (iii) akses status dan kemungkinan sumber berbeda lainnya dengan pengaturan gas yang terpisah. Gas multi-dimensi menambah kompleksitas, tetapi sebagai pertukaran, itu lebih ketat membatasi rasio antara kasus rata-rata dan kasus terburuk. Dengan gas multi-dimensi, jumlah cabang maksimum yang perlu dibuktikan secara teoritis dapat berkurang dari 12500 menjadi 3000, misalnya. Ini akan membuat BLAKE 3 cukup (dalam arti longgar) bahkan hari ini.

Gas multi-dimensi memungkinkan pembatasan sumber daya Blok lebih mendekati pembatasan sumber daya perangkat keras dasar

Alat lain yang tak terduga adalah menghitung latensi root state ke Blok setelah slot. Dengan demikian, kita memiliki waktu 12 detik penuh untuk menghitung akar status, yang berarti bahkan dalam situasi paling ekstrim, waktu bukti 60000 hash per detik sudah cukup, ini sekali lagi membuat kita berpikir bahwa BLAKE 3 hanya cukup memenuhi persyaratan.

Kekurangan metode ini adalah dapat meningkatkan latensi light clientlatensi dengan satu slot, namun ada teknik yang lebih canggih yang dapat mengurangi latensi ini menjadi hanya latensi pembuatan bukti. Misalnya, bukti dapat segera disiarkan ke jaringan setelah dihasilkan oleh Node mana pun, bukan menunggu Blok berikutnya.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Mengatasi masalah tanpa status secara signifikan meningkatkan kesulitan poin tunggal. Jika ada teknologi yang dapat menurunkan keseimbangan terendah titik tunggal, seperti Orbit SSF atau strategi Layer Aplikasi, seperti tim titik tunggal, ini akan menjadi lebih mungkin dilakukan.

Jika EOF diperkenalkan bersamaan, analisis gas multidimensi akan menjadi lebih mudah. Hal ini karena kompleksitas eksekusi gas multidimensi terutama berasal dari penanganan panggilan anak yang tidak meneruskan seluruh gas panggilan induk, sedangkan EOF hanya perlu mengatur panggilan anak semacam ini menjadi ilegal, masalah ini menjadi sepele (dan abstraksi akun lokal akan memberikan solusi pengganti untuk penggunaan gas utama saat ini dalam protokol).

Antara verifikasi tanpa status dan kedaluwarsa sejarah, ada kerja sama penting lainnya. Saat ini, klien harus menyimpan hampir 1 TB data sejarah; data ini adalah beberapa kali lipat data status. Bahkan jika klien tidak memiliki status, impian hampir tanpa penyimpanan klien tidak akan terwujud kecuali kita bisa melepaskan tanggung jawab klien untuk menyimpan data sejarah. Langkah pertama dalam hal ini adalah EIP-4444, yang juga berarti penyimpanan data sejarah di torrents atau Portal Network situs web portal.

bukti validitas yang dilakukan oleh EVM

Apa masalah yang ingin kita selesaikan?

Tujuan jangka panjang verifikasi Blok Ether sangat jelas - harus dapat diverifikasi dengan cara berikut: (i) mengunduh Blok, atau bahkan hanya mengunduh sebagian kecil dari sampel ketersediaan data Blok; (ii) memverifikasi bukti kecil yang sah dari Blok. Ini akan menjadi operasi dengan penggunaan sumber daya yang sangat rendah, dapat diselesaikan di klien seluler, dompet browser, bahkan dapat diselesaikan di rantai lain (tanpa bagian ketersediaan data).

Untuk mencapai hal ini, perlu dilakukan bukti SNARK atau STARK terhadap (i) lapisan konsensus (yaitu Proof of Stake) dan (ii) lapisan eksekusi (yaitu EVM). Yang pertama merupakan tantangan tersendiri, harus dipecahkan dalam proses terus-menerus perbaikan lapisan konsensus (misalnya, terkait finalitas tunggal). Yang kedua memerlukan bukti eksekusi EVM.

Apa itu, bagaimana cara kerjanya?

Dari segi bentuk, dalam spesifikasi blok ETH, EVM didefinisikan sebagai fungsi peralihan status: Anda memiliki beberapa status sebelum S, sebuah Blok B, Anda sedang menghitung status setelah S' = STF(S, B). Jika pengguna menggunakan light client, mereka tidak sepenuhnya memiliki S dan S', bahkan E; sebaliknya, mereka memiliki akar status sebelum R, akar status setelah R', dan nilai hash Blok H.

• Input Publik: Rantai keadaan sebelumnya R, rantai keadaan berikutnya R', hash blok H
• Input pribadi: objek dalam status yang diakses oleh entitas B blok program, entitas Q blok program, objek yang sama setelah menjalankan blok program Q', dan bukti status (seperti cabang Merkle) P
• Klaim 1: P adalah bukti yang valid yang menunjukkan bahwa Q mengandung bagian-bagian dari status yang diwakili oleh R
• Pendapat 2: Jika STF dijalankan di Q, (i) proses eksekusi hanya mengakses objek internal Q, (ii) blok data valid, (iii) hasilnya adalah Q'
• Klaim 3: Jika menggunakan informasi Q' dan P untuk menghitung akar status baru, akan didapatkan R'

Jika situasi ini terjadi, maka akan dimungkinkan untuk memiliki klien ringan yang melakukan verifikasi penuh dari eksekusi EVM ETH. Ini membuat sumber daya klien menjadi cukup rendah. Untuk mencapai klien ETH yang melakukan verifikasi penuh yang sebenarnya, perlu dilakukan kerja yang sama dalam hal Konsensus.

Implementasi bukti validitas untuk perhitungan EVM sudah ada dan banyak digunakan oleh L2. Namun, masih ada banyak pekerjaan yang perlu dilakukan agar bukti validitas EVM dapat berfungsi di L1.

Apa hubungannya dengan penelitian yang ada?

• EFPSE ZK-EVM (dihentikan karena ada pilihan yang lebih baik)
• Zeth, prinsip kerjanya adalah mengompilasi EVM ke dalam RISC-0 ZK-VM
• Proyek Verifikasi Formal ZK-EVM

Masih bisa melakukan apa lagi?

Saat ini, sistem pencatatan elektronik memiliki kekurangan dalam dua hal: keamanan dan waktu verifikasi.

Sebuah bukti validitas yang aman memerlukan memastikan SNARK benar-benar memverifikasi perhitungan EVM dan tidak ada kerentanan. Dua teknologi utama untuk meningkatkan keamanan adalah validator ganda dan verifikasi formal. Validator ganda mengacu pada implementasi bukti validitas yang ditulis secara independen, seperti memiliki beberapa klien, jika subset yang cukup besar dari implementasi ini membuktikan Blok, klien akan menerima Blok tersebut. Verifikasi formal melibatkan penggunaan alat yang biasanya digunakan untuk membuktikan teorema matematika, seperti Lean 4, untuk membuktikan bahwa bukti validitas hanya menerima spesifikasi EVM yang dieksekusi dengan benar (misalnya semantik K EVM atau spesifikasi lapisan eksekusi Ethereum yang ditulis dengan python (EELS)).

Waktu verifikasi yang cukup cepat berarti setiap blok di rantai blok ETH dapat diverifikasi dalam waktu kurang dari 4 detik. Saat ini, kita masih jauh dari tujuan ini, meskipun kita sudah jauh lebih dekat daripada yang kita bayangkan dua tahun lalu. Untuk mencapai tujuan ini, kita perlu membuat kemajuan dalam tiga arah:

• Paralelisme - Verifikator EVM tercepat saat ini dapat membuktikan blok Etherium dalam rata-rata 15 detik. Ini dicapai dengan memparallelkan ratusan GPU dan kemudian menggabungkan pekerjaan mereka pada akhirnya. Secara teori, kita sepenuhnya tahu bagaimana memproduksi verifikator EVM yang dapat membuktikan komputasi dalam waktu O(log(N)): Biarkan satu GPU menyelesaikan setiap langkah dan membuat "pohon agregat" setelahnya.

Mengimplementasikan ini memiliki tantangan. Bahkan dalam kasus terburuk, di mana transaksi yang sangat besar mengambil seluruh Blok, pembagian komputasi tidak dapat dilakukan secara berurutan, tetapi harus dilakukan berdasarkan opcode (opcode Virtual Machine dasar seperti EVM atau RISC-V). Menjaga 'memori' Virtual Machine konsisten di antara bagian-bagian berbeda dari bukti adalah tantangan kunci dalam implementasi. Namun, jika kita dapat mencapai bukti rekursif ini, maka kita tahu bahwa setidaknya masalah latensi pihak yang membuktikan telah teratasi, meskipun tidak ada perbaikan lainnya.

• Sistem bukti yang dioptimalkan - Sistem bukti baru, seperti Orion, Binius, GRK, dan informasi lainnya, kemungkinan besar akan menyebabkan penyingkatan besar dalam waktu verifikasi komputasi umum.
• Perubahan biaya gas EVM lainnya - Banyak hal dalam EVM dapat dioptimalkan untuk lebih menguntungkan validator, terutama dalam kasus terburuk. Jika penyerang dapat membuat Blok yang menghalangi validator selama sepuluh menit, maka perlu waktu kurang dari 4 detik untuk membuktikan sebuah Blok ETH biasa. Perubahan EVM yang diperlukan dapat dibagi menjadi beberapa jenis:

Perubahan biaya gas - Jika suatu operasi memerlukan waktu yang lama untuk terverifikasi, maka biaya gasnya harus tinggi meskipun kecepatan komputasinya relatif cepat. EIP-7667 adalah sebuah EIP yang diajukan untuk menangani masalah yang paling serius dalam hal ini: itu secara signifikan meningkatkan biaya gas dari fungsi hash (tradisional) karena opcode dan pra-kompilasi dari fungsi-fungsi ini relatif murah. Untuk mengimbangi peningkatan biaya gas ini, kita dapat menurunkan biaya gas dari opcode EVM yang membuktikan relatif rendah, sehingga menjaga throughput rata-rata tetap tidak berubah.

• Penggantian struktur data - Selain mengganti pohon status dengan metode yang lebih ramah STARK, kami juga perlu mengganti daftar transaksi, pohon tanda terima, dan struktur lain yang mahal biayanya untuk dibuktikan. Langkah Etan Kissling untuk memindahkan struktur transaksi dan tanda terima ke SSZ adalah langkah ke arah ini.

Selain itu, dua alat yang disebutkan dalam bagian sebelumnya (gas multidimensi dan latensi root state) juga dapat membantu dalam hal ini. Namun, perlu diperhatikan bahwa berbeda dengan verifikasi tanpa status, menggunakan kedua alat ini berarti kita sudah memiliki cukup teknologi untuk menyelesaikan pekerjaan yang saat ini kita butuhkan, dan meskipun menggunakan teknologi ini, verifikasi ZK-EVM lengkap juga membutuhkan lebih banyak pekerjaan - hanya perlu lebih sedikit pekerjaan.

Satu hal yang tidak disebutkan sebelumnya adalah hardware pembuat bukti: GPU, FPGA, dan ASIC digunakan untuk menghasilkan bukti lebih cepat. Fabric Cryptography, Cysic, dan Accseal adalah tiga perusahaan yang telah membuat kemajuan dalam hal ini. Ini sangat berharga untuk L2, tetapi tidak mungkin menjadi faktor penentu untuk L1 karena orang sangat ingin L1 tetap Desentralisasi, yang berarti pembuatan bukti harus dalam jangkauan wajar pengguna ETH, dan tidak boleh dibatasi oleh bottleneck hardware perusahaan tunggal. L2 dapat membuat pertimbangan yang lebih positif.

Di bidang-bidang ini, masih ada lebih banyak pekerjaan yang perlu dilakukan:

• Bukti paralelisasi mengharuskan sistem bukti untuk dapat 'mengakses memori bersama' (seperti tabel pencarian). Kita tahu teknologi untuk melakukan hal ini, tetapi perlu diimplementasikan.
• Kami perlu melakukan analisis lebih lanjut untuk menemukan kumpulan perubahan biaya gas yang ideal, sehingga dapat meminimalkan waktu verifikasi dalam skenario terburuk.
• Kami perlu melakukan lebih banyak pekerjaan dalam hal sistem bukti

Kemungkinan biayanya adalah:

• Keamanan dan Waktu Verifikator: Jika memilih fungsi hash yang lebih agresif, sistem bukti yang lebih kompleks, asumsi keamanan yang lebih agresif, atau skema desain lainnya, maka waktu verifikator dapat dipersingkat.
• Desentralisasi dan Waktu Pengepala: Komunitas perlu mencapai kesepakatan tentang 'spesifikasi' perangkat keras pengepala yang mereka tuju. Apakah pengepala harus menjadi entitas besar dalam skala besar? Apakah kita mengharapkan laptop konsumen kelas atas untuk membuktikan blok rantai ETH dalam waktu 4 detik? Atau di antara keduanya?
• Tingkat pelanggaran kompatibilitas mundur: Kekurangan lain dapat diatasi dengan perubahan biaya gas yang lebih proaktif, tetapi ini lebih mungkin secara tidak proporsional meningkatkan biaya beberapa aplikasi, memaksa pengembang untuk menulis ulang dan mendeploy ulang kode untuk menjaga kelayakan ekonomi. Demikian pula, kedua alat ini juga memiliki kompleksitas dan kerugian mereka sendiri.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Teknologi inti yang diperlukan untuk mencapai bukti validitas L1 EVM secara besar-besaran berbagi banyak kesamaan dengan dua bidang lainnya:

• Bukti validitas L2 (dikenal sebagai "ZK rollup")
• Stateless "STARK biner hash bukti" metode

Dengan berhasil menerapkan bukti validitas di L1, akhirnya dapat dengan mudah melakukan stake tunggal: bahkan perangkat komputer yang paling lemah sekalipun (termasuk ponsel atau jam tangan pintar) dapat melakukan stake. Hal ini lebih lanjut meningkatkan nilai dari memecahkan batasan lain dalam stake tunggal (seperti batas minimum 32 ETH).

Selain itu, bukti validitas EVM L1 dapat secara signifikan meningkatkan batas gas L1.

Bukti validitas Konsensus

Apa masalah yang ingin kita selesaikan?

Jika kita ingin sepenuhnya memverifikasi sebuah blok ETH di rantai menggunakan SNARK, maka pelaksanaan EVM bukanlah satu-satunya bagian yang perlu kita buktikan. Kita juga perlu membuktikan Konsensus, yaitu bagian sistem yang menangani deposit, penarikan, penandatanganan, pembaruan saldo validator, dan elemen lain dari bagian Proof of Stake blok ETH.

Konsensus jauh lebih sederhana dibandingkan EVM, tetapi tantangannya adalah kita tidak memiliki konvolusi L2 EVM, sehingga sebagian besar pekerjaan harus diselesaikan apa adanya. Oleh karena itu, implementasi Konsensus Ethereum yang membuktikan ETH perlu 'mulai dari awal', meskipun sistem bukti itu sendiri dapat dibangun di atas pekerjaan bersama itu.

Apa itu dan bagaimana cara kerjanya?

beacon chain didefinisikan sebagai fungsi perubahan status, seperti EVM. Fungsi perubahan status terdiri dari tiga bagian utama:

• ECADD（digunakan untuk memverifikasi tanda tangan BLS）
• Pasangan (digunakan untuk memverifikasi tanda tangan BLS)
• Nilai hash SHA 256 (digunakan untuk membaca dan memperbarui status)

Dalam setiap Blok, kita perlu membuktikan 1-16 ECADD BLS 12-381 untuk setiap validator (mungkin lebih dari satu karena tanda tangan dapat termasuk dalam beberapa koleksi). Ini dapat dikompensasi dengan teknik subset prekomputasi, sehingga kita dapat mengatakan bahwa setiap validator hanya perlu membuktikan satu ECADD BLS 12-381. Saat ini, setiap slot memiliki 30000 tanda tangan validator. Di masa depan, dengan pencapaian finalitas satu slot, situasi ini dapat berubah dalam dua arah: Jika kita mengambil rute 'kekerasan', jumlah validator per slot dapat meningkat menjadi 1 juta. Sementara itu, jika menggunakan Orbit SSF, jumlah validator akan tetap 32768, atau bahkan berkurang menjadi 8192.

Bagaimana BLS Agregat Berfungsi: Verifikasi tanda tangan keseluruhan hanya memerlukan satu ECADD dari setiap peserta, bukan satu ECMUL. Namun 30000 ECADD masih merupakan jumlah bukti yang besar.

Untuk pasangan, saat ini setiap slot memiliki maksimum 128 bukti, yang berarti perlu diverifikasi 128 pasangan. Melalui ElP-7549 dan modifikasi lebih lanjut, setiap slot dapat berkurang menjadi 16. Jumlah pasangan sedikit, tetapi biayanya sangat tinggi: waktu operasi (atau bukti) setiap pasangan lebih dari k kali lebih lama dari ECADD.

Salah satu tantangan utama dalam membuktikan operasi BLS 12-381 adalah bahwa tidak ada kurva yang nyaman dengan order kurva sama dengan ukuran bidang BLS 12-381, yang menambahkan biaya yang cukup besar untuk sistem bukti apa pun. Di sisi lain, Verkle Tree yang diajukan untuk ETH dikonstruksi dengan kurva Bandersnatch, sehingga BLS 12-381 itu sendiri menjadi subkurva yang digunakan dalam sistem SNARK untuk membuktikan cabang Verkle. Sebuah implementasi yang relatif sederhana dapat membuktikan penjumlahan 100 G1 per detik; untuk membuat kecepatan bukti cukup cepat, hampir pasti diperlukan teknologi yang cerdik seperti GKR.

Untuk nilai hash SHA 256, situasi terburuk saat ini adalah blok konversi zaman, seluruh pohon keseimbangan pendek validator dan banyak keseimbangan validator akan diperbarui. Setiap pohon keseimbangan pendek validator hanya memiliki satu byte, sehingga 1 MB data akan di-hash ulang. Ini setara dengan 32768 panggilan SHA 256. Jika ada seribu validator yang saldo-nya lebih tinggi atau lebih rendah dari ambang batas, perlu memperbarui saldo efektif dalam catatan validator, ini setara dengan seribu cabang Merkle, sehingga mungkin perlu 10.000 nilai hash. Mekanisme pengocokan memerlukan 90 Bit per validator (sehingga memerlukan 11 MB data), tetapi ini dapat dihitung kapan saja dalam satu era. Dalam kasus terminasi satu slot, angka-angka ini mungkin bertambah atau berkurang tergantung pada situasi tertentu. Pengocokan menjadi tidak perlu, meskipun Orbit mungkin akan mengembalikan kebutuhan ini hingga batas tertentu.

Tantangan lain adalah perlu untuk mendapatkan kembali status validator, termasuk Kunci Publik, sebelum Blok dapat diverifikasi. Untuk 1 juta validator, hanya membaca Kunci Publik memerlukan 48 juta byte, ditambah dengan cabang Merkle. Ini memerlukan jutaan nilai hash di setiap epoch. Jika kita harus membuktikan kevalidan PoS, satu metode yang realistis adalah dengan bentuk perhitungan verifikasi bertambah: penyimpanan struktur data terpisah di dalam sistem pembuktian yang dioptimalkan untuk pencarian efisien dan pembuktian pembaruan terhadap struktur itu sendiri.

Secara keseluruhan, tantangannya sangat banyak. Untuk menghadapi tantangan-tantangan tersebut secara efektif, mungkin perlu melakukan redesain yang mendalam terhadap beacon chain, dan hal ini mungkin dilakukan secara bersamaan dengan beralih ke akhir slot tunggal. Redesain ini mungkin mencakup fitur-fitur seperti:

• Perubahan fungsi hash: Sekarang menggunakan fungsi hash SHA 256 "lengkap", sehingga setiap panggilan harus sesuai dengan dua panggilan fungsi kompresi bawahnya karena alasan padding. Jika menggunakan fungsi kompresi SHA 256, kita setidaknya dapat mendapatkan keuntungan dua kali lipat. Jika menggunakan Poseidon, kita mungkin akan mendapatkan keuntungan 100 kali lipat, sehingga secara keseluruhan dapat mengatasi semua masalah kita (setidaknya dalam hal nilai hash): membaca rekaman verifikasi satu juta bahkan dapat "dibaca" dalam beberapa detik dengan 1,7 juta nilai hash per detik (54 MB).
• Jika itu Orbit, catat validator yang diacak secara langsung: Jika sejumlah validator tertentu (misalnya 8192 atau 32768) dipilih sebagai komite untuk slot yang diberikan, maka mereka akan langsung dimasukkan ke dalam status yang bersebelahan satu sama lain, sehingga hanya perlu hash minimum untuk membaca Kunci Publik dari semua validator ke dalam bukti. Ini juga memungkinkan pembaruan saldo yang efisien.
• Agregasi Tanda Tangan: Setiap skema agregasi tanda tangan yang berkinerja tinggi akan melibatkan bukti rekursif tertentu di mana Node yang berbeda dalam jaringan akan melakukan bukti perantara terhadap subset tanda tangan. Dengan demikian, pekerjaan bukti secara alami dibagi di antara beberapa Node dalam jaringan, yang secara signifikan mengurangi beban kerja 'pemohon bukti akhir'.
• Skema tanda tangan lainnya: Untuk tanda tangan Lamport+ Merkle, kami memerlukan 256 + 32 nilai hash untuk memverifikasi tanda tangan; dikalikan dengan 32768 penandatangan, maka akan mendapatkan 9437184 nilai hash. Setelah mengoptimalkan skema tanda tangan, hasil ini dapat ditingkatkan lebih lanjut melalui faktor konstan yang sangat kecil. Jika kami menggunakan Poseidon, ini dapat dibuktikan dalam satu slot tunggal. Namun sebenarnya, menggunakan skema agregasi rekursif akan lebih cepat.

Apa hubungannya dengan penelitian yang ada?

• Bukti Konsensus Ether yang ringkas (hanya untuk komite sinkronisasi)
• Helios di dalam SP 1 yang Sederhana
• Pra-penyusunan Kompilasi BLS 12-381 yang Ringkas
• Verifikasi Tanda Tangan Kumpulan BLS berdasarkan Halo 2

Masih ada pekerjaan apa yang perlu dilakukan, bagaimana memilih:

Sebenarnya, kami membutuhkan beberapa tahun untuk mendapatkan bukti validitas Konsensus ETH. Ini sekitar waktu yang sama yang diperlukan untuk mencapai finalitas slot tunggal, Orbit, memodifikasi Algoritme Tanda Tangan, dan melakukan analisis keamanan yang memerlukan kepercayaan yang cukup untuk menggunakan fungsi hash yang "agresif" seperti Poseidon. Oleh karena itu, pendekatan terbaik adalah menyelesaikan masalah lain ini dan pada saat yang sama mempertimbangkan kebaikan STARK.

Kompromi utama mungkin berada pada urutan operasi, antara pendekatan yang lebih progresif dalam memperbarui lapisan konsensus Ethereum dan pendekatan yang lebih agresif dengan 'banyak perubahan sekaligus'. Untuk EVM, pendekatan progresif masuk akal karena dapat mengurangi gangguan terhadap kompatibilitas mundur sebanyak mungkin. Bagi lapisan konsensus, dampak terhadap kompatibilitas mundur relatif kecil, dan memikir ulang berbagai detail dalam pembangunan beacon chain dengan lebih 'komprehensif', serta mengoptimalkan ke-SNARK-an dengan cara terbaik juga memiliki manfaat.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Ketika merancang ulang PoS Ethereum jangka panjang, keahlian STARK harus menjadi faktor pertimbangan utama, terutama dalam hal finalitas slot tunggal, Orbit, perubahan skema penandatanganan, dan agregasi penandatanganan.