Penulis: Vitalik, pendiri Ethereum; Terjemahan: Golden Finance 0xjs

Sejak awal proyek Ethereum, terdapat filosofi yang kuat untuk mencoba menjaga inti Ethereum sesederhana mungkin dan menyelesaikan sebanyak mungkin dengan membangun protokol di atasnya. Di dunia blockchain, perdebatan “eksekusi pada L1” vs. “fokus pada L2” sering dianggap terutama melibatkan penskalaan, namun pada kenyataannya, masalah serupa terjadi dalam melayani berbagai jenis kebutuhan pengguna Ethereum: Pertukaran Aset Angka, privasi, nama pengguna, kriptografi tingkat lanjut, keamanan akun, ketahanan sensor, perlindungan terdepan, dan banyak lagi. Namun baru-baru ini, ada peningkatan minat dari beberapa orang untuk secara diam-diam menulis lebih banyak fitur ini ke dalam protokol inti Ethereum.

Artikel ini akan mengeksplorasi beberapa alasan filosofis di balik gagasan awal meminimalkan protokol Ethereum, serta beberapa pemikiran terbaru saya tentang gagasan ini. Tujuannya adalah untuk secara bertahap membangun kerangka kerja yang dapat mengidentifikasi tujuan dengan lebih baik yang mungkin layak dipertimbangkan untuk membentuk fitur-fitur tertentu dalam protokol.

Filosofi Minimisasi Perjanjian Awal

Di awal sejarah "Ethereum 2.0" (sebutan pada saat itu), terdapat keinginan kuat untuk menciptakan protokol yang bersih, sederhana, dan indah yang melakukan pekerjaan sendiri sesedikit mungkin dan menyerahkan hampir segalanya kepada pengguna untuk membangun di atasnya. Idealnya, protokol hanya berupa mesin virtual, dan memvalidasi sebuah blok hanya memerlukan satu panggilan ke mesin virtual.

Rekonstruksi diagram papan tulis yang sangat kasar yang saya dan Gavin Wood buat pada awal tahun 2015 ketika kami mendiskusikan seperti apa tampilan Ethereum 2.0.

"Fungsi transisi status" (fungsi yang menangani blok) hanya berupa panggilan mesin virtual, dan semua logika lainnya akan diimplementasikan melalui kontrak: beberapa kontrak tingkat sistem, tetapi sebagian besar kontrak yang disediakan pengguna. Fitur yang sangat bagus dari model ini adalah bahkan seluruh hard fork dapat digambarkan sebagai satu transaksi pada kontrak pemrosesan blok, yang akan disetujui melalui tata kelola off-chain atau on-chain dan kemudian dijalankan dengan izin yang ditingkatkan.

Diskusi tahun 2015 ini berlaku secara khusus pada dua bidang yang menjadi perhatian kami: abstraksi dan penskalaan akun. Dalam hal penskalaan, idenya adalah mencoba membuat bentuk penskalaan yang abstrak mungkin sehingga terasa seperti perpanjangan alami dari diagram di atas. Sebuah kontrak dapat memanggil data tertentu yang tidak disimpan oleh sebagian besar node Ethereum, dan protokol akan mendeteksi hal ini dan menyelesaikan panggilan tersebut melalui beberapa fungsi komputasi penskalaan yang sangat umum. Dari sudut pandang mesin virtual, panggilan tersebut akan masuk ke beberapa subsistem terpisah dan kemudian secara ajaib kembali beberapa waktu kemudian dengan jawaban yang benar.

Cara berpikir seperti ini sempat dieksplorasi secara singkat, namun dengan cepat ditinggalkan karena kami terlalu fokus untuk memverifikasi apakah segala bentuk penskalaan blockchain dapat dilakukan. Namun, seperti yang akan kita lihat nanti, kombinasi pengambilan sampel ketersediaan data dan ZK-EVM berarti bahwa kemungkinan masa depan penskalaan Ethereum mungkin terlihat sangat dekat dengan visi ini! Di sisi lain, untuk abstraksi akun, kami mengetahui sejak awal bahwa beberapa jenis implementasi mungkin dilakukan dan segera mulai berupaya membuat titik awal murni "transaksi hanya panggilan" sedekat mungkin dengan kenyataan.

Di sini, ada banyak kode yang terjadi antara dan setelah kode yang menangani transaksi dan membuat panggilan EVM yang mendasarinya ke alamat pengirim. Bagaimana cara kita mengurangi kode ini hingga mendekati nol?

Salah satu tugas utama dalam salah satu potongan kode adalah validasi_transaksi(status, tx), yang mencakup pemeriksaan apakah nonce dan tanda tangan transaksi sudah benar. Tujuan sebenarnya dari abstraksi akun sejak awal adalah untuk memungkinkan pengguna mengganti kenaikan nonce dasar dan verifikasi ECDSA dengan logika verifikasi mereka sendiri, sehingga memudahkan pengguna untuk menggunakan hal-hal seperti pemulihan sosial dan dompet multi-tanda tangan. Oleh karena itu, membentuk kembali apply_transaction menjadi panggilan EVM sederhana bukan hanya tentang tugas "membuat kode bersih", melainkan tentang memindahkan logika ke dalam kode akun pengguna untuk memberikan fleksibilitas yang dibutuhkan pengguna;

Namun, desakan bahwa apply_transaction mengandung logika formal sesedikit mungkin pada akhirnya menimbulkan sejumlah tantangan. Untuk memahami alasannya, mari kita gali salah satu proposal abstraksi akun awal, EIP 86:

spesifikasi

Jika block.number >= METROPOLIS_FORK_BLKNUM, maka: 1. Jika tanda tangan transaksi adalah (0, 0, 0) (yaitu v = r = s = 0), maka dianggap sah dan alamat pengirim disetel ke 2 **160 - 1. 2. Tetapkan alamat kontrak apa pun yang dibuat dengan membuat transaksi ke sha3 (0 + kode inisialisasi) % 2 ** 160, dimana + melambangkan koneksi, ganti rumus alamat sebelumnya sha3(rlp.encode([sender, nonce])) 3. Buat opcode baru, 0xfb, CREATE_P2SH, opcode ini akan menyetel alamat pembuatan menjadi sha3(sender + init code )%2**160. Jika kontrak sudah ada di alamat itu, maka gagal dan mengembalikan 0, seolah-olah kode inisialisasi kehabisan Gas.

Pada dasarnya, jika Anda menyetel tanda tangan ke (0, 0, 0), maka transaksi secara efektif menjadi "hanya panggilan". Akun itu sendiri akan bertanggung jawab untuk memiliki kode untuk mengurai transaksi, mengekstrak dan memverifikasi tanda tangan dan nonce, serta membayar biaya. Klik di sini untuk melihat versi sebelumnya dari kode ini. Klik di sini untuk melihat kode validasi_transaksi yang akan digantikan oleh kode akun ini. Pada satu titik, apply_transaction direduksi menjadi Ini hanyalah sebuah proses yang dipanggil oleh EVM. Dengan kata lain, protokol Ethereum melakukan verifikasi transaksi, menyerahkan logika transaksi spesifik ke kode akun pengguna untuk memberikan fleksibilitas.

Namun, mencoba membuat apply_transaction berisi logika formal sesedikit mungkin akhirnya menimbulkan sejumlah tantangan. Untuk memahami alasannya, mari kita lihat secara detail salah satu proposal abstraksi akun awal, EIP 86.

Perhatikan bahwa penambang perlu mengembangkan strategi untuk menerima transaksi ini. Strategi ini harus sangat diskriminatif, jika tidak mereka mungkin menerima transaksi yang tidak membayar apa pun (untuk kode validasi_transaksi yang akan diganti dengan kode pra-akun), atau bahkan transaksi yang tidak berpengaruh (misalnya karena transaksi sudah termasuk , Jadi nonce tidak berlaku lagi). Cara sederhana untuk melakukan ini adalah dengan memasukkan codehash kode akun yang menerima transaksi untuk dikirim ke daftar putih; kode yang disetujui akan mencakup logika untuk membayar biaya transaksi penambang. Namun, hal ini mungkin terlalu membatasi; strategi yang lebih santai namun tetap efektif adalah dengan menerima kode apa pun yang sesuai dengan format umum yang sama seperti yang dijelaskan di atas, hanya menggunakan bahan bakar dalam jumlah terbatas untuk melakukan pemeriksaan nonce dan tanda tangan, dan menjamin bahwa biaya transaksi akan dikenakan. dibayarkan kepada penambang. Strategi lainnya adalah, selain metode lain, mencoba menangani setiap transaksi yang meminta kurang dari 250.000 gas dan hanya memasukkannya jika saldo penambang meningkat secara wajar setelah melakukan transaksi.

Jika EIP-86 digabungkan apa adanya, hal ini akan mengurangi kompleksitas EVM namun dengan biaya yang besar akan meningkatkan kompleksitas bagian lain dari tumpukan Ethereum, yang pada dasarnya memerlukan kode yang sama persis untuk ditulis di tempat lain sambil memperkenalkan kemungkinan-kemungkinan aneh yang benar-benar baru. seperti transaksi yang sama dengan hash yang sama dapat muncul beberapa kali dalam rantai, belum lagi masalah pembatalan ganda.

Beberapa masalah kedaluwarsa dalam abstraksi akun. Satu transaksi yang termasuk dalam rantai dapat membatalkan ribuan transaksi lain di mempool, sehingga mempool rentan terhadap banjir yang murah.

Abstraksi akun secara bertahap berkembang dari sana. EIP-86 menjadi EIP-208, yang kemudian menjadi postingan ini di ethresear.ch tentang "Pengorbanan dalam Proposal Abstraksi Akun", dan setengah tahun kemudian postingan ini di ethresear.ch. Pada akhirnya, semua ini menghasilkan EIP-2938, yang sebenarnya cukup layak dilakukan.

Namun, EIP-2938 tidaklah minimal. EIP meliputi:

  • jenis transaksi baru

  • Tiga variabel global cakupan transaksi baru

  • Dua opcode baru, termasuk opcode PAYGAS yang sangat kikuk, menangani pemeriksaan harga gas dan batas gas, bertindak sebagai breakpoint eksekusi EVM, dan juga menyimpan sementara ETH untuk pembayaran biaya.

  • Serangkaian strategi penambangan dan pemutaran ulang yang kompleks, termasuk serangkaian opcode terlarang selama fase verifikasi transaksi

Untuk mendorong abstraksi akun tanpa melibatkan pengembang inti Ethereum yang sibuk mengoptimalkan klien Ethereum dan menerapkan penggabungan, EIP-2938 akhirnya didesain ulang menjadi ERC-4337 yang sepenuhnya di luar protokol.

ERC-4337. Itu sepenuhnya bergantung pada panggilan EVM untuk melakukan semuanya!

Karena ini adalah ERC, maka tidak memerlukan hard fork dan secara teknis "di luar protokol Ethereum". Jadi...masalah terpecahkan? Ternyata, hal itu belum sepenuhnya terselesaikan. Peta jalan jangka menengah saat ini untuk ERC-4337 sebenarnya melibatkan transisi sebagian besar ERC-4337 ke dalam serangkaian fitur protokol, yang merupakan contoh berguna mengapa jalur ini dipertimbangkan.

Solidifikasi lapisan protokol ERC-4337

Beberapa alasan utama telah dibahas untuk pengenalan ERC-4337 ke dalam protokol:

  • Efisiensi Gas: Setiap operasi yang dilakukan di dalam EVM menimbulkan overhead mesin virtual pada tingkat tertentu, termasuk inefisiensi saat menggunakan fitur gas yang mahal seperti slot penyimpanan. Saat ini, inefisiensi tambahan ini menghasilkan setidaknya ~20.000 gas, dan seringkali lebih. Mendorong komponen-komponen ini ke dalam protokol adalah cara termudah untuk menghilangkan masalah ini.

  • Risiko kesalahan kode: Jika ada bug yang cukup parah dalam “kontrak titik masuk” ERC-4337, semua dompet yang kompatibel dengan ERC-4337 mungkin akan mengalami penghapusan semua dananya. Dengan mengganti kontrak dengan fungsi protokol, Anda menciptakan tanggung jawab implisit untuk memperbaiki bug kode dan menghilangkan risiko terhadap dana pengguna.

  • Mendukung opcode EVM seperti tx.origin. ERC-4337 sendiri menyebabkan tx.origin mengembalikan alamat yang dikirim oleh "bundler" yang mengemas serangkaian tindakan pengguna ke dalam sebuah transaksi. Abstraksi akun asli dapat mengatasi masalah ini dengan membuat tx.origin menunjuk ke akun yang benar-benar mengirimkan transaksi, membuatnya bekerja dengan cara yang sama seperti EOA.

  • Resistensi Sensor: Dalam kasus PBS, salah satu tantangannya adalah mempermudah sensor transaksi individual. Di dunia di mana setiap transaksi dapat dilihat oleh protokol Ethereum, masalah ini dapat diatasi dengan daftar penyertaan, yang memungkinkan pengusul untuk menentukan di hampir semua kasus apa yang harus dimasukkan dalam dua slot berikutnya. Namun, ERC-4337 di luar protokol membungkus "operasi pengguna" dalam satu transaksi, membuat operasi pengguna tidak terlihat oleh protokol Ethereum; oleh karena itu, daftar penyertaan yang disediakan oleh protokol Ethereum tidak akan memberikan ketahanan sensor untuk operasi pengguna ERC-4337. Memformalkan ERC-4337 dan menjadikan operasi pengguna sebagai jenis transaksi "resmi" akan menyelesaikan masalah ini.

Masalah efisiensi gas perlu dikaji lebih lanjut. Dalam bentuknya saat ini, ERC-4337 jauh lebih mahal daripada transaksi Ethereum "dasar": satu transaksi membutuhkan biaya 21.000 gas, sedangkan ERC-4337 berharga sekitar 42.000 gas. Dokumentasi mencantumkan beberapa alasan berikut:

  • Ada sejumlah biaya baca/tulis penyimpanan terpisah yang harus dibayar, yang untuk EOA digabungkan menjadi satu pembayaran sebesar 21.000 gas:

  • Edit slot penyimpanan yang berisi pubkey+nonce (~5000)

  • Biaya data panggilan UserOperation (~4500, dikurangi menjadi ~2500 dengan kompresi)

  • PEMULIHAN EKRUT (3000)

  • Panaskan dompet itu sendiri (~2600)

  • Pemanasan akun penerima (~2600)

  • Transfer ETH ke akun penerima (~9000)

  • Edit penyimpanan untuk menutupi biaya (~5000)

  • Akses slot penyimpanan yang berisi agen (~2100), lalu agen itu sendiri (~2600)

  • Selain biaya baca/tulis penyimpanan yang disebutkan di atas, kontrak perlu menjalankan "logika bisnis" (membongkar UserOperation, melakukan hash, mengacak variabel, dll.), sedangkan transaksi EOA ditangani "gratis" oleh protokol Ethereum.

  • Gas diperlukan untuk membayar kayu gelondongan (EOA tidak menerbitkan kayu gelondongan)

  • Biaya pembuatan kontrak satu kali (biaya dasar ~32.000, kode di proxy menambahkan 200 gas per byte, ditambah 20.000 gas untuk menyetel alamat proxy)

Secara teori, sistem biaya gas EVM seharusnya dapat dimanipulasi sehingga biaya dalam protokol dan biaya ekstra-protokol untuk akses penyimpanan cocok; tidak ada alasan mengapa mentransfer ETH akan menelan biaya 9000 gas ketika operasi pengeditan penyimpanan lainnya jauh lebih murah . Faktanya, dua EIP yang terkait dengan transisi pohon Verkle yang akan datang sebenarnya berupaya melakukan hal tersebut. Namun bahkan jika kita melakukan itu, ada alasan besar mengapa fitur protokol formal pasti akan jauh lebih murah daripada kode EVM, tidak peduli seberapa efisiennya EVM: kode formal tidak perlu membayar bahan bakar untuk pramuat.

Dompet ERC-4337 yang berfungsi penuh sangatlah besar. Implementasi ini, dikompilasi dan ditempatkan secara on-chain, memakan waktu sekitar 12800 byte. Tentu saja, Anda dapat menerapkan kode besar itu satu kali dan menggunakan DELEGATECALL agar setiap dompet dapat memanggilnya, namun kode tersebut tetap harus dapat diakses di setiap blok yang menggunakannya. Menurut EIP biaya gas pohon Verkle yang akan datang, 12.800 byte akan menempati 413 bongkahan, dan untuk mengakses bongkahan ini perlu membayar 2x WITNESS_BRANCH_COST (total 3.800 gas) dan 413x WITNESS_CHUNK_COST (total 82.600 gas). Itu bahkan belum lagi titik masuk ERC-4337 itu sendiri, yang memiliki 23689 byte on-chain di versi 0.6.0 (pemuatan memerlukan ~158700 gas per aturan EIP pohon Verkle).

Hal ini menimbulkan masalah: biaya bahan bakar untuk mengakses kode ini harus didistribusikan antar transaksi dengan cara tertentu. Pendekatan yang saat ini digunakan oleh ERC-4337 tidak terlalu baik: transaksi pertama dalam bundel menyerap biaya penyimpanan/pembacaan kode satu kali, sehingga jauh lebih mahal dibandingkan transaksi lainnya. Menjadikan perpustakaan bersama yang umum digunakan ini sebagai bagian dari protokol, dapat diakses oleh semua orang tanpa membayar biaya, adalah solusi untuk masalah ini.

Apa yang dapat kita pelajari dari contoh ini tentang kapan harus memperkuat protokol secara lebih umum?

Dalam contoh ini, kita dapat mempelajari beberapa pelajaran tentang prinsip-prinsip yang lebih umum tentang kapan harus meringkas sesuatu.

  • Merupakan ide bagus untuk menghilangkan kompleksitas, terutama ketika biaya perawatannya tinggi. Hal ini menjadi jelas dalam peta jalan "Abstraksi Akun Terdesentralisasi", karena memuat kode dompet standar memerlukan 244.100 bahan bakar, sementara agregasi (lihat pembicaraan saya musim panas ini untuk lebih jelasnya) memerlukan ratusan ribu bahan bakar untuk Verifikasi ZK-SNARKs, ditambah biaya verifikasi bukti on-chain. Membebankan biaya-biaya ini pada pengguna hampir tidak mungkin karena hal ini akan menimbulkan banyak inefisiensi pasar, yang dapat diatasi dengan membuat fitur-fitur tertentu dapat diakses oleh semua pengguna tanpa biaya sebagai fitur protokol.

  • Respon kolektif komunitas terhadap kesalahan pengkodean. Jika sekumpulan cuplikan kode digunakan oleh semua pengguna atau kelas pengguna yang luas, seringkali lebih masuk akal bagi komunitas blockchain untuk mengambil tanggung jawab untuk memperbaiki kemungkinan bug melalui hard fork. ERC-4337 memperkenalkan sejumlah besar kode yang dibagikan secara global, dan dalam jangka panjang, perbaikan bug dalam kode ini paling baik dilakukan melalui hard fork daripada menyebabkan pengguna kehilangan ETH dalam jumlah besar.

  • Terkadang, bentuk fungsionalitas yang lebih canggih dapat dicapai dengan memanfaatkan kekuatan protokol secara langsung. Misalnya, penyensoran dalam protokol dapat menjamin resistensi sensor dengan lebih baik, namun agar operasi tingkat pengguna benar-benar mendapatkan manfaat dari protokol, setiap operasi tingkat pengguna harus "dapat dibaca" oleh protokol. Contoh lain yang kurang terkenal adalah desain bukti kepemilikan Ethereum tahun 2017 dengan abstraksi otoritatif, dan ini ditinggalkan demi ringkasan BLS, karena BLS mendukung mekanisme "agregasi" yang harus diterapkan pada tingkat protokol dan jaringan, yang mana dapat Membuat pemrosesan tanda tangan dalam jumlah besar menjadi lebih efisien.

Namun penting untuk diingat bahwa bahkan abstraksi akun yang ditetapkan dalam protokol masih merupakan “kontra-kemapanan” yang sangat besar dibandingkan dengan status quo. Saat ini, transaksi tingkat atas Ethereum hanya dapat dimulai oleh akun milik eksternal (EOA), yang diverifikasi menggunakan satu tanda tangan kurva elips secp256k1. Abstraksi akun mencerminkan hal ini dan memberikan keterbukaan bagi pengguna untuk menentukan kondisi validasi. Jadi dalam cerita tentang abstraksi akun ini, kita juga melihat argumen terbesar yang menentang mothballing: fleksibilitas untuk memenuhi kebutuhan pengguna yang berbeda.

Mari kita coba menyempurnakan cerita ini lebih lanjut dengan melihat beberapa fitur yang baru-baru ini dipertimbangkan untuk dikembangkan. Kami akan memberikan perhatian khusus pada: ZK-EVM, pemisahan pengusul-pembangun, mempool pribadi, taruhan likuiditas, dan prakompilasi baru.

Menyembuhkan ZK-EVM

Mari kita alihkan perhatian kita ke kemungkinan target lain yang ditetapkan dalam protokol Ethereum: ZK-EVMs. Saat ini, kami memiliki sejumlah besar ZK-rollup yang semuanya harus menulis kode yang cukup mirip untuk memverifikasi blok mirip Ethereum dalam eksekusi ZK-SNARK. Terdapat ekosistem implementasi independen yang cukup beragam: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth, dan banyak lagi.

Salah satu kontroversi baru-baru ini di bidang EVM ZK-rollup melibatkan cara menangani kemungkinan bug pada kode ZK. Saat ini, semua sistem yang berjalan memiliki mekanisme "dewan keamanan" yang mengesampingkan sistem pengesahan jika terjadi kesalahan. Dalam sebuah artikel tahun lalu, saya mencoba membuat kerangka standar yang akan mendorong proyek-proyek untuk memperjelas tingkat kepercayaan antara sistem pengesahan dan Dewan Keamanan, dan bergerak menuju pengurangan wewenang atas Dewan Keamanan seiring berjalannya waktu.

Dalam jangka menengah, rollup dapat bergantung pada beberapa sistem sertifikasi, dan Dewan Keamanan hanya akan mempunyai kekuasaan dalam kasus ekstrim ketika dua sistem sertifikasi berbeda tidak sepakat satu sama lain.

Namun, ada perasaan bahwa beberapa pekerjaan itu mubazir. Kami sudah memiliki lapisan dasar Ethereum, yang memiliki EVM, dan kami sudah memiliki mekanisme kerja untuk menangani kesalahan dalam implementasi: jika ada kesalahan, klien dengan kesalahan tersebut akan memperbarui untuk memperbaiki kesalahan tersebut, dan rantai akan berlanjut. . Dari perspektif klien yang memiliki bug, dari perspektif berbagai implementasi komunitas Ethereum dan konsensus sosial off-chain, pemblokiran tersebut tampaknya telah diselesaikan, tetapi setidaknya kita tidak akan melihat pengguna kehilangan dana. Demikian pula, jika rollup hanya ingin menjadi dan tetap setara dengan EVM, maka ketika aturan internal ZK-EVM harus sesuai dengan peningkatan lapisan dasar Ethereum, aturan tersebut tidak boleh menerapkan tata kelolanya sendiri, namun harus dibangun langsung di Ethereum lapisan dasar Selain itu, lapisan dasar ini mengetahui kapan harus melakukan peningkatan dan aturan baru apa yang harus ditingkatkan.

Karena L2 ZK-EVM ini pada dasarnya menggunakan EVM yang sama dengan Ethereum, tidak bisakah kita mengubah "verifikasi eksekusi EVM di ZK" menjadi fitur protokol? Jika terjadi bug dan peningkatan, dapatkah kita mengatasinya dengan menerapkan konsensus sosial Ethereum, sama seperti yang telah kita lakukan pada eksekusi EVM lapisan dasar itu sendiri?

Ini adalah topik yang penting dan menantang. Ada beberapa kehalusan:

1. Kami berharap untuk tetap kompatibel dengan filosofi multi-klien Ethereum. Ini berarti kami ingin mengizinkan klien yang berbeda untuk menggunakan sistem pembuktian yang berbeda. Hal ini berarti bahwa untuk setiap eksekusi EVM yang menggunakan satu sistem ZK-SNARK sebagai pembuktian, kami ingin memastikan bahwa data pokok tersedia sehingga pembuktian dapat dihasilkan untuk sistem ZK-SNARK lainnya.

2. Meskipun teknologinya belum matang, kami mungkin ingin melakukan audit. Dalam praktiknya, hal ini memiliki arti yang sama: jika ada eksekusi yang terbukti, kami ingin data dasar tersedia sehingga pengguna dan pengembang dapat memeriksanya jika terjadi kesalahan.

3. Kita membutuhkan waktu pembuktian yang lebih cepat sehingga jika satu jenis bukti dihasilkan, jenis bukti lainnya dapat dihasilkan dengan cepat sehingga klien lain dapat memverifikasinya. Masalah ini dapat diselesaikan dengan membuat prakompilasi yang memiliki respons asinkron setelah jangka waktu tertentu (misalnya 3 jam), namun hal ini menambah kerumitan.

4. Kami berharap dapat mendukung tidak hanya salinan EVM, tetapi juga "hampir-EVM". Berinovasi pada tingkat eksekusi dan memperluas EVM adalah bagian dari daya tarik L2. Jika VM untuk L2 tertentu hanya sedikit berbeda dari EVM, alangkah baiknya jika VM L2 menggunakan protokol asli ZK-EVM untuk bagian yang sama dengan EVM, dan hanya mengandalkan kodenya sendiri untuk menangani bagian berbeda dari EVM. . Hal ini dapat dicapai dengan merancang prakompilasi ZK-EVM sehingga memungkinkan pemanggil untuk menentukan sekumpulan opcode atau bidang bit atau daftar alamat yang ditangani oleh tabel yang disediakan secara eksternal, bukan oleh EVM itu sendiri. Kami juga dapat menyesuaikan biaya bahan bakar hingga batas tertentu.

Salah satu topik yang mungkin diperdebatkan dengan ketersediaan data saat menggunakan ZK-EVM asli adalah statefulness. ZK-EVM akan lebih hemat data jika tidak perlu membawa data "saksi". Artinya, jika data tertentu telah dibaca atau ditulis di blok sebelumnya, kita dapat berasumsi bahwa pembukti memiliki akses ke data tersebut dan kita tidak perlu memberikannya lagi. Hal ini lebih dari sekadar tidak memuat ulang penyimpanan dan kode; ternyata jika rollup mengompresi data dengan benar sehingga kompresinya bersifat stateful, hal ini akan menghemat hingga 3x data dibandingkan dengan kompresi stateless.

Artinya untuk prakompilasi ZK-EVM, kami memiliki dua opsi:

1. Prakompilasi mengharuskan semua data tersedia di blok yang sama. Ini berarti bahwa pembuktiannya bisa tanpa kewarganegaraan, namun ini juga berarti bahwa menggunakan ZK-rollup yang sudah dikompilasi lebih mahal dibandingkan menggunakan rollup kode kustom.

2. Prakompilasi memungkinkan penunjuk ke data yang digunakan atau dihasilkan dalam eksekusi sebelumnya. Hal ini memungkinkan ZK-rollup menjadi hampir optimal, namun lebih kompleks dan memperkenalkan jenis status baru yang harus disimpan oleh pembuktian.

Pelajaran apa yang dapat kita ambil dari hal ini? Ada argumen yang cukup bagus bahwa verifikasi ZK-EVM dapat dilakukan: rollup sudah membuat versi kustomnya sendiri, dan yang terasa salah adalah kesediaan Ethereum untuk memberikan bobot pada berbagai implementasi dan konsensus sosial off-chain pada After the EVM. L1 dijalankan, L2 yang melakukan pekerjaan yang sama harus mengimplementasikan gadget kompleks yang melibatkan dewan keamanan. Namun di sisi lain, ada perbedaan besar dalam detailnya: Ada berbagai versi ZK-EVM yang sudah ada, dengan biaya dan manfaat yang berbeda. Stateful vs. stateless hanyalah puncak gunung es; mencoba mendukung "hampir-EVM" dengan kode khusus yang dibuktikan oleh sistem lain dapat mengungkapkan ruang desain yang lebih besar. Oleh karena itu, membangun ZK-EVM memiliki janji dan tantangan.

Pemisahan Pengusul-Pembangun yang Diperkuat (ePBS)

Munculnya MEV telah menjadikan produksi blok sebagai latihan skala ekonomi, dengan pemain yang cerdas mampu menghasilkan blok yang menghasilkan lebih banyak pendapatan daripada algoritme default yang hanya memantau transaksi di mempool dan memasukkannya. Komunitas Ethereum sejauh ini telah berupaya mengatasi masalah ini dengan menggunakan skema pemisahan pengusul-pembangun di luar protokol seperti MEV-Boost, yang memungkinkan validator reguler ("pengusul") untuk melakukan outsourcing konstruksi blok ke aktor yang berdedikasi ("Pembangun").

Namun, MEV-Boost menerapkan asumsi kepercayaan pada kelas peserta baru, yang disebut relay. Dalam dua tahun terakhir, banyak usulan untuk menciptakan "PBS yang dipadatkan". Apa manfaat melakukan hal ini? Dalam hal ini, jawabannya sangat sederhana: PBS yang dibangun dengan langsung menggunakan kekuatan protokol lebih kuat dalam hal asumsi kepercayaan (dalam arti asumsi kepercayaan lebih lemah) dibandingkan PBS yang dibangun tanpa asumsi kepercayaan. Hal ini mirip dengan kasus penetapan harga oracle dalam sebuah protokol, meskipun dalam kasus tersebut terdapat argumen tandingan yang kuat.

Buat kumpulan memori pribadi

Saat pengguna mengirimkan transaksi, transaksi tersebut segera menjadi publik dan dapat dilihat oleh semua orang, bahkan sebelum dimasukkan secara on-chain. Hal ini membuat pengguna banyak aplikasi rentan terhadap serangan ekonomi seperti front-running: jika pengguna melakukan transaksi besar di Uniswap, penyerang dapat melakukan transaksi sebelum mereka, menaikkan harga pembelian dan mengumpulkan keuntungan arbitrase.

Baru-baru ini, ada sejumlah proyek yang didedikasikan untuk membuat “mempool pribadi” (atau “mempool kripto”) yang memungkinkan transaksi pengguna tetap terenkripsi hingga diterima secara permanen ke dalam blok.

Namun, skema ini memerlukan jenis enkripsi tertentu: untuk mencegah pengguna membanjiri sistem dan menjalankan proses dekripsi itu sendiri sebelum transaksi benar-benar diterima secara permanen, enkripsi harus diaktifkan untuk mendekripsi secara otomatis ketika transaksi benar-benar diterima secara permanen. .

Untuk menerapkan bentuk enkripsi ini, terdapat berbagai teknik berbeda, dengan trade-off berbeda, dijelaskan dengan baik oleh Jon Charbonneau dalam sebuah artikel (dan dalam video serta tayangan slide ini):

  • Enkripsi ke operator terpusat seperti Flashbots Protect.

  • Enkripsi terkunci waktu, suatu bentuk enkripsi yang dapat didekripsi oleh siapa pun setelah sejumlah langkah komputasi berurutan tertentu, yang tidak dapat diparalelkan.

  • Enkripsi ambang batas, mempercayai komite mayoritas untuk mendekripsi data. Lihat konsep rantai suar tertutup untuk proposal konkret.

  • Perangkat keras tepercaya seperti SGX.

Sayangnya, semua itu mempunyai berbagai kelemahan. Karena alasan yang jelas, hal ini tidak dapat diterima oleh operator pusat untuk dimasukkan dalam perjanjian. Enkripsi timelock tradisional terlalu mahal untuk menjalankan ribuan transaksi di mempool publik. Enkripsi primitif yang lebih kuat yang disebut enkripsi tertunda memungkinkan dekripsi yang efisien pada sejumlah pesan tertentu, namun dalam praktiknya sulit untuk dibuat, dan serangan terhadap build yang sudah ada terkadang masih ditemukan. Seperti halnya fungsi hash, kita mungkin memerlukan penelitian dan analisis bertahun-tahun sebelum enkripsi tertunda cukup matang. Kriptografi ambang batas memerlukan kepercayaan pada komite mayoritas untuk tidak berkolusi, hal ini tidak dapat diterima dalam situasi di mana kolusi tidak dapat terdeteksi (tidak seperti serangan 51% yang langsung diketahui siapa yang berpartisipasi). SGX memperkenalkan ketergantungan pada satu produsen tepercaya.

Meskipun ada sebagian pengguna yang ingin memercayai setiap solusi, saat ini tidak ada solusi yang cukup dapat dipercaya untuk benar-benar diterima di Tingkat 1. Oleh karena itu, setidaknya sampai/kecuali enkripsi yang tertunda membaik atau ada terobosan teknologi lainnya, memasukkan front-running ke dalam Tier 1 tampak seperti sebuah proposisi yang sulit, bahkan jika itu adalah fitur yang sangat berharga sehingga banyak solusi aplikasi telah muncul.

Hipotek Cair Dipadatkan

Kebutuhan umum di antara pengguna Ethereum DeFi adalah untuk dapat menggunakan ETH mereka untuk staking dan sebagai jaminan dalam aplikasi lain. Permintaan umum lainnya hanya untuk kenyamanan: pengguna ingin dapat melakukan staking tanpa kerumitan dalam menjalankan node dan selalu online, (serta melindungi kunci staking mereka yang sekarang online).

Sejauh ini, "antarmuka" staking paling sederhana yang memenuhi kedua kebutuhan ini adalah token ERC20: ubah ETH Anda menjadi "staking ETH", tahan, lalu konversikan kembali. Faktanya, penyedia staking likuiditas seperti Lido dan Rocketpool telah melakukan hal tersebut. Namun, ada beberapa mekanisme sentralisasi alami yang berperan dalam staking likuiditas: orang-orang secara alami melakukan staking pada versi ETH terbesar karena versi tersebut paling familiar dan likuid (dan paling baik didukung oleh aplikasi, yang pada gilirannya lebih disukai karena lebih familiar, karena itu yang paling banyak didengar pengguna).

Setiap versi ETH yang dipertaruhkan perlu memiliki mekanisme untuk menentukan siapa yang dapat menjadi operator node dasar. Hal ini tidak dapat dibatasi karena penyerang akan bergabung dan menggunakan dana pengguna untuk memperkuat serangan mereka. Saat ini, dua teratas adalah Lido, yang memiliki operator node DAO yang masuk daftar putih, dan Rocket Pool, yang memungkinkan siapa pun menjalankan node dengan menyetor 8 ETH (yaitu 1/4 modal) sebagai deposit. Kedua metode tersebut memiliki risiko yang berbeda: metode Rocket Pool memungkinkan penyerang melancarkan serangan 51% pada jaringan dan memaksa pengguna membayar sebagian besar biayanya. Dengan pendekatan DAO, jika satu token yang dipertaruhkan menjadi dominan, hal ini akan menghasilkan satu gadget tata kelola yang berpotensi diserang yang mengendalikan sebagian besar semua validator Ethereum. Untuk protokol seperti Lido, mereka telah menerapkan pengamanan, namun satu lapisan pertahanan mungkin tidak cukup.

Dalam jangka pendek, salah satu pilihannya adalah dengan mendorong secara sosial para peserta ekosistem untuk menggunakan beragam penyedia jaminan cair untuk mengurangi kemungkinan salah satu penyedia jaminan tersebut menjadi terlalu besar dan menjadi risiko sistemik. Namun dalam jangka panjang, hal ini merupakan keseimbangan yang berbahaya, dan ada bahayanya jika terlalu mengandalkan tekanan moral untuk memecahkan masalah. Sebuah pertanyaan wajar muncul: apakah masuk akal untuk memperkuat beberapa fungsi ke dalam protokol untuk mengurangi konsentrasi jaminan cair?

Di sini, pertanyaan kuncinya adalah: Fungsi protokol manakah yang harus diperkuat? Masalah dengan hanya membuat token "ETH yang dijaminkan" yang sepadan dalam suatu protokol adalah bahwa token tersebut harus memperkuat tata kelola global Ethereum untuk memilih siapa yang menjalankan node, atau bersikap terbuka terhadapnya, mengubahnya menjadi alat bagi penyerang.

Pemikiran yang menarik adalah artikel Dankrad Feist tentang Ekstremisme Jaminan Likuiditas. Pertama-tama, kita harus menerima kenyataan bahwa jika Ethereum diserang oleh 51%, hanya 5% dari ETH yang menyerang yang dapat dihukum. Ini adalah trade-off yang masuk akal; dengan lebih dari 26 juta ETH yang dipertaruhkan, 1/3 dari biaya serangan (~8 juta ETH) benar-benar berlebihan, terutama mengingat banyaknya serangan "di luar model" yang mungkin terjadi. dilaksanakan dengan biaya yang jauh lebih sedikit. Faktanya, trade-off serupa telah dieksplorasi dalam proposal “Komite Super” untuk menerapkan finalitas slot tunggal.

Jika kita menerima bahwa hanya 5% dari serangan ETH yang akan dipangkas, maka lebih dari 90% ETH yang dipertaruhkan akan dikecualikan dari pemotongan, sehingga 90% dari ETH yang dipertaruhkan dapat dimasukkan ke dalam token staking cair yang sepadan dalam protokol, yang kemudian dapat digunakan oleh aplikasi lain.

Jalur ini menarik. Namun masih menyisakan pertanyaan: Apa sebenarnya yang akan dipadatkan? Rocket Pool bekerja dengan cara yang sangat mirip: setiap operator node memberikan sejumlah modal, dan pemegang saham yang likuid memberikan sisanya. Kita cukup menyesuaikan beberapa konstanta untuk membatasi penalti maksimum menjadi 2 ETH, dan rETH yang ada di Rocket Pool akan menjadi bebas risiko.

Dengan penyesuaian protokol sederhana kita dapat melakukan beberapa hal cerdas. Misalnya, bayangkan kita menginginkan sistem yang memiliki dua "tingkatan" staking: operator node (persyaratan agunan yang tinggi) dan deposan (tidak ada persyaratan minimum, dapat bergabung dan keluar kapan saja), namun kita tetap ingin memberikan deposit sebesar A komite orang yang diambil sampelnya secara acak memberikan wewenang seperti merekomendasikan daftar transaksi yang harus disertakan (untuk alasan anti-sensor), mengontrol pemilihan fork selama kebocoran tidak aktif, atau mengharuskan blok ditandatangani. Hal ini dapat dicapai dengan mengadaptasi mekanisme dalam protokol dimana setiap validator harus menyediakan (i) kunci staking reguler dan (ii) alamat ETH yang dapat dipanggil oleh setiap slot untuk mengeluarkan kunci staking sekunder. Protokol akan memberikan kekuatan ke kedua kunci, namun mekanisme untuk memilih kunci kedua di setiap slot mungkin diserahkan kepada protokol staking pool. Mungkin masih lebih baik untuk memperkuat sesuatu secara langsung, tetapi perlu dicatat bahwa ruang desain "memperkuat beberapa hal dan menyerahkan hal-hal lain kepada pengguna" ada.

Perkuat lebih banyak prakompilasi

Kontrak yang telah dikompilasi sebelumnya (atau "kontrak yang telah dikompilasi") adalah kontrak Ethereum yang mengimplementasikan operasi kriptografi kompleks secara asli dalam kode klien, bukan dalam kode kontrak pintar EVM. Prakompilasi adalah kompromi yang diadopsi pada masa-masa awal Ethereum: karena overhead VM terlalu besar untuk jenis kode tertentu yang sangat kompleks dan sangat terspesialisasi, kami dapat mengimplementasikan beberapa fitur dalam kode asli yang berguna untuk jenis aplikasi penting operasi utama untuk membuatnya lebih cepat. Saat ini, ini pada dasarnya mencakup beberapa fungsi hash tertentu dan operasi kurva elips.

Saat ini ada dorongan untuk menambahkan prakompilasi secp256r1, kurva elips yang sedikit berbeda dari secp256k1 yang digunakan untuk akun Ethereum dasar, karena didukung secara luas oleh modul perangkat keras tepercaya, sehingga penggunaannya secara luas dapat meningkatkan keamanan dompet. Dalam beberapa tahun terakhir, ada upaya untuk mempromosikan prakompilasi fungsi seperti BLS-12-377, BW6-761, dan pemasangan umum.

Argumen tandingan terhadap permintaan untuk menambahkan lebih banyak prakompiler adalah bahwa banyak dari prakompiler yang ditambahkan sebelumnya (misalnya RIPEMD dan BLAKE) akhirnya digunakan kurang dari yang diharapkan, dan kita harus belajar dari hal ini. Daripada menambahkan lebih banyak prakompilasi untuk operasi tertentu, kita mungkin harus fokus pada pendekatan yang lebih lembut berdasarkan ide seperti EVM-MAX dan proposal SIMD tidur-tapi-selalu-bangun, yang akan memungkinkan implementasi EVM bekerja lebih luas dan lebih murah Kode Kategori. Bahkan dimungkinkan untuk menghapus dan mengganti prakompilasi yang sudah ada namun jarang digunakan dengan implementasi kode EVM dengan fungsi yang sama. Meskipun demikian, mungkin masih ada beberapa operasi kriptografi tertentu yang perlu dipercepat, sehingga dapat dibenarkan untuk menambahkannya sebagai operasi yang telah dikompilasi sebelumnya.

Apa yang bisa kita pelajari dari semua ini?

Keinginan untuk memiliki solidifikasi sesedikit mungkin dapat dimengerti dan merupakan hal yang baik; hal ini berasal dari tradisi filosofis Unix dalam menciptakan perangkat lunak minimal yang dapat dengan mudah disesuaikan dengan berbagai kebutuhan penggunanya, menghindari kutukan penggembungan perangkat lunak. Namun, blockchain bukanlah sistem operasi komputasi personal; melainkan sistem sosial. Ini berarti bahwa ada alasan untuk memasukkan fitur-fitur tertentu ke dalam protokol yang melampaui pertimbangan pribadi yang disebutkan di atas.

Dalam banyak kasus, contoh-contoh lain ini memperkenalkan kembali pelajaran serupa yang terlihat dalam abstraksi akun. Namun ada juga beberapa pembelajaran baru:

  • Membantu menghindari risiko sentralisasi di area lain dari tumpukan. Seringkali, menjaga protokol dasar tetap sederhana dan sederhana mendorong kompleksitas ke dalam ekosistem di luar protokol. Dari perspektif filosofi Unix, ini bagus. Namun terkadang, risiko ekosistem di luar protokol adalah menjadi tersentralisasi, seringkali (tetapi tidak hanya) karena tingginya biaya tetap. Solidifikasi terkadang dapat mengurangi sentralisasi yang sebenarnya.

  • Terlalu banyak solidifikasi akan meningkatkan kepercayaan dan beban tata kelola protokol secara berlebihan. Ini adalah tema artikel sebelumnya tentang "Jangan membebani konsensus Ethereum" (lihat artikel terjemahan Golden Finance sebelumnya): jika fitur tertentu diperkuat, ini akan melemahkan model kepercayaan dan menjadikan Ethereum secara keseluruhan lebih "subyektif" , sehingga ini melemahkan netralitas Ethereum yang dapat dipercaya. Dalam kasus ini, lebih baik mempertahankan fungsi spesifik tersebut sebagai mekanisme di atas Ethereum daripada mencoba menghadirkannya ke Ethereum itu sendiri. Di sini, kumpulan memori terenkripsi adalah contoh terbaik dari sesuatu yang mungkin terlalu sulit untuk diperkuat, setidaknya sampai/kecuali teknologi enkripsi membaik.

  • Terlalu banyak proses curing dapat memperumit protokol. Kompleksitas protokol adalah risiko sistemik, dan menambahkan terlalu banyak fitur ke protokol akan meningkatkan risiko tersebut. Prakompilasi adalah contoh terbaiknya.

  • Solidifikasi dapat menjadi kontraproduktif dalam jangka panjang karena kebutuhan pengguna tidak dapat diprediksi. Sebuah fitur yang dianggap penting oleh banyak orang dan akan digunakan oleh banyak pengguna, mungkin sebenarnya tidak banyak digunakan dalam praktiknya.

Selain itu, jaminan likuiditas, ZK-EVM, dan kasus yang telah dikompilasi menunjukkan kemungkinan jalan tengah: solidifikasi minimum yang layak. Daripada memperkuat keseluruhan fitur, perkuat bagian-bagian tertentu yang mengatasi tantangan utama dalam penerapan fitur tersebut tanpa terlalu subyektif atau berpikiran sempit. Ini termasuk:

  • Daripada memperkuat seluruh sistem pertaruhan likuiditas, aturan penalti harus diubah agar pertaruhan likuiditas yang tidak dapat dipercaya menjadi lebih layak dilakukan.

  • Daripada memperkeras prakompilasi lebih lanjut, perkuat EVM-MAX dan/atau SIMD untuk membuat kelas operasi yang lebih luas lebih mudah diterapkan secara efisien.

  • Daripada memperkuat keseluruhan konsep Rollup, kita cukup memperkuat verifikasi EVM.

Kita dapat memperluas diagram dari artikel sebelumnya sebagai berikut:

Kadang-kadang bahkan masuk akal untuk menghilangkan pemadatan sesuatu. Menghapus precompiler yang jarang digunakan adalah salah satu contohnya. Sebagai dukungan yang kompatibel ke depan untuk pengguna yang sudah ada, mekanisme ini mungkin sebenarnya sangat mirip dengan mekanisme yang menghilangkan prakompilasi: salah satunya adalah EIP-5003, yang akan memungkinkan EOA mengonversi akun mereka di tempat agar memiliki akun yang sama (atau lebih baik). ) ) kontrak fungsi.

Fitur mana yang harus dimasukkan ke dalam protokol dan fitur mana yang diserahkan ke lapisan ekosistem lainnya adalah sebuah trade-off yang kompleks, dan kita harus berharap untuk terus meningkatkannya seiring dengan pemahaman kita tentang kebutuhan pengguna dan rangkaian ide dan teknologi yang tersedia. berkembang seiring berjalannya waktu.