Artikel panjang terbaru Buterin: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Penulis: Vitalik Buterin Penyusun: Odaily Planet Daily Nian Yinsitang

*Terima kasih khusus kepada Justin Drake, Tina Zhen, dan Yoav Weiss atas tanggapan dan ulasan mereka. *

Sejak awal proyek Ethereum, terdapat filosofi yang kuat untuk mencoba membuat inti Ethereum sesederhana mungkin, dan mencapainya semaksimal mungkin dengan membangun protokol di atasnya. Di dunia blockchain, perdebatan “membangun di atas L1” vs. “fokus pada L2” sering kali dianggap terutama tentang penskalaan, namun pada kenyataannya, ada masalah serupa dalam memenuhi kebutuhan banyak pengguna Ethereum: Pertukaran aset digital, privasi , nama pengguna, enkripsi tingkat lanjut, keamanan akun, ketahanan sensor, perlindungan terdepan, dan banyak lagi. Namun, ada beberapa upaya hati-hati baru-baru ini untuk memasukkan lebih banyak fitur ini ke dalam protokol inti Ethereum.

Artikel ini akan mempelajari beberapa alasan filosofis di balik filosofi asli enkapsulasi minimal, serta beberapa cara berpikir terkini tentang ide-ide ini. Sasarannya adalah mulai membangun kerangka kerja untuk mengidentifikasi kemungkinan sasaran dengan lebih baik sehingga merangkum fungsi tertentu mungkin layak untuk dipertimbangkan.

Filosofi awal tentang minimalisme protokol

Dalam sejarah awal dari apa yang kemudian dikenal sebagai “Ethereum 2.0,” terdapat keinginan kuat untuk menciptakan protokol yang bersih, sederhana, dan indah yang berusaha sesedikit mungkin untuk membangun dirinya sendiri dan menyerahkan hampir semua pekerjaan tersebut kepada pengguna. Idealnya, protokol hanyalah mesin virtual, dan memvalidasi blok hanyalah panggilan mesin virtual.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Ini adalah perkiraan rekonstruksi diagram papan tulis yang saya dan Gavin Wood gambar pada awal tahun 2015 ketika saya berbicara tentang seperti apa tampilan Ethereum 2.0.

"Fungsi transisi status" (fungsi yang menangani blok) hanya berupa satu panggilan VM, dan semua logika lainnya akan terjadi melalui kontrak: beberapa kontrak tingkat sistem, namun sebagian besar kontrak yang disediakan pengguna. Fitur yang sangat bagus dari model ini adalah bahwa bahkan seluruh hard fork dapat digambarkan sebagai satu transaksi ke kontrak pemroses blok, yang akan disetujui oleh tata kelola off-chain atau on-chain dan kemudian ditingkatkan izin untuk menjalankannya.

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

Kami mengeksplorasi ide ini secara singkat namun segera meninggalkannya karena kami terlalu fokus untuk membuktikan bahwa segala jenis penskalaan blockchain dapat dilakukan. Meskipun seperti yang akan kita lihat nanti, kombinasi pengambilan sampel ketersediaan data dan ZK-EVM berarti bahwa kemungkinan masa depan penskalaan Ethereum sebenarnya terlihat sangat dekat dengan visi ini! Sebaliknya, dengan abstraksi akun, kami mengetahui sejak awal bahwa semacam implementasi mungkin dilakukan, sehingga penelitian segera mulai mencoba membuat sesuatu sedekat mungkin dengan titik awal murni "transaksi hanyalah sebuah panggilan".

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

*Ada banyak kode boilerplate antara memproses transaksi dan membuat panggilan EVM sebenarnya dari alamat pengirim, dengan lebih banyak kode boilerplate yang menyusul. Bagaimana cara kita mengurangi kode ini sedekat mungkin dengan nol? *

Salah satu kode utama di sini adalah validasi_transaksi(negara bagian, tx), yang bertanggung jawab untuk memeriksa apakah nonce dan tanda tangan transaksi sudah benar. Tujuan sebenarnya dari abstraksi akun sejak awal adalah untuk memungkinkan pengguna mengganti verifikasi dasar non-inkremental dan verifikasi ECDSA dengan logika verifikasi mereka sendiri, sehingga pengguna dapat lebih mudah menggunakan fitur seperti pemulihan sosial dan dompet multi-tanda tangan. Jadi menemukan cara untuk merestrukturisasi apply_transaction menjadi panggilan EVM sederhana bukan hanya tugas "membuat kode bersih demi membuat kode bersih"; melainkan, ini tentang memindahkan logika ke kode akun pengguna, memberikan fleksibilitas kepada pengguna. membutuhkan.

Namun, bersikeras bahwa apply_transaction mengandung logika tetap sesedikit mungkin pada akhirnya menciptakan banyak tantangan. Kita dapat melihat salah satu proposal abstraksi akun paling awal, EIP-86.

Jika EIP-86 dimasukkan apa adanya, hal ini akan mengurangi kompleksitas EVM dengan mengorbankan peningkatan kompleksitas bagian lain dari tumpukan Ethereum secara besar-besaran, yang pada dasarnya memerlukan kode yang sama untuk ditulis di tempat lain, selain memperkenalkan keseluruhan kelas keanehan baru. Misalnya, transaksi yang sama dengan nilai hash yang sama mungkin muncul beberapa kali dalam rantai, belum lagi masalah pembatalan ganda.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

*Beberapa masalah pembatalan validasi dalam abstraksi akun. Satu transaksi yang disertakan secara on-chain dapat membatalkan ribuan transaksi lain di mempool, sehingga memudahkan mempool untuk diisi dengan murah. *

Sejak itu, abstraksi akun telah berkembang secara bertahap. EIP-86 kemudian menjadi EIP-208, dan akhirnya muncullah EIP-2938 praktis.

Namun, EIP-2938 sama sekali tidak minimalis. Isinya antara lain:

  • Jenis transaksi baru
  • Tiga variabel global cakupan transaksi baru
  • Dua opcode baru, termasuk opcode PAYgas yang sangat kikuk untuk menangani pemeriksaan harga gas dan batas gas, sebagai breakpoint eksekusi EVM, dan untuk menyimpan sementara ETH untuk pembayaran satu kali
  • Serangkaian strategi penambangan dan transmisi ulang yang kompleks, termasuk daftar opcode yang dilarang selama fase verifikasi transaksi

Untuk mencapai abstraksi akun tanpa melibatkan pengembang inti Ethereum (berfokus pada pengoptimalan klien Ethereum dan penerapan penggabungan), EIP-2938 akhirnya dirancang ulang menjadi ERC-4337, yang sepenuhnya di luar protokol.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

ERC-4337. Itu sepenuhnya bergantung pada panggilan EVM!

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

Paket ERC-4337

Ada beberapa alasan utama yang dibahas untuk penggabungan kembali 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 yang mahal bahan bakar seperti slot penyimpanan. Saat ini, inefisiensi tambahan ini berjumlah setidaknya 20.000 gas, atau lebih. Memasukkan komponen-komponen ini ke dalam protokol adalah cara termudah untuk menghilangkan masalah ini.
  • Risiko Bug Kode: Jika "kontrak titik masuk" ERC-4337 memiliki bug yang cukup parah, semua dompet yang kompatibel dengan ERC-4337 dapat melihat semua dananya mengering. Mengganti kontrak dengan fungsionalitas dalam protokol menciptakan kewajiban implisit untuk memperbaiki bug kode melalui hard fork, sehingga menghilangkan risiko pengguna kehabisan dana.
  • Mendukung opcode EVM, seperti txt.origin. ERC-4337 sendiri menyebabkan txt.origin mengembalikan alamat "bundler" yang mengemas serangkaian tindakan pengguna ke dalam sebuah transaksi. Abstraksi akun asli memecahkan masalah ini dengan membuat txt.origin menunjuk ke akun sebenarnya yang mengirimkan transaksi, sehingga berperilaku sama seperti EOA.
  • Resistensi Sensor: Salah satu tantangan pemisahan pengusul/pembuat adalah semakin mudahnya meninjau transaksi individual. Di dunia di mana protokol Ethereum dapat mengidentifikasi transaksi tunggal, masalah ini dapat diatasi dengan daftar penyertaan, yang memungkinkan pengusul menentukan daftar transaksi yang harus dimasukkan dalam dua slot berikutnya di hampir semua kasus. Namun, ERC-4337 di luar protokol merangkum "operasi pengguna" dalam satu transaksi, membuat operasi pengguna tidak tembus pandang terhadap protokol Ethereum; oleh karena itu, daftar penyertaan yang disediakan oleh protokol Ethereum tidak akan mampu memberikan ketahanan sensor terhadap pengguna ERC-4337 operasi. Membungkus ERC-4337 dan menjadikan tindakan pengguna sebagai jenis transaksi yang "tepat" akan menyelesaikan masalah ini.

Perlu disebutkan bahwa dalam bentuknya saat ini, ERC-4337 jauh lebih mahal daripada transaksi Ethereum “dasar”: satu transaksi memerlukan biaya 21,000 gas, sedangkan ERC-4337 berharga sekitar 42,000 gas.

Secara teori, sistem biaya gas EVM harus dapat disesuaikan hingga biaya dalam protokol dan biaya akses penyimpanan di luar protokol cocok; tidak ada alasan untuk mengeluarkan 9000 gas untuk mentransfer ETH ketika jenis penyimpanan lainnya diedit. operasinya lebih murah. Faktanya, dua EIP yang terkait dengan transformasi pohon Verkle yang akan datang sebenarnya berupaya melakukan hal tersebut. Tetapi bahkan jika kita melakukan ini, ada alasan yang jelas mengapa betapapun efisiennya EVM, fungsi protokol yang dienkapsulasi pasti akan jauh lebih murah daripada kode EVM: kode yang dienkapsulasi tidak perlu membayar bahan bakar untuk pramuat.

Dompet ERC-4337 yang berfungsi penuh berukuran besar, dan implementasi yang dikompilasi dan dimasukkan ke dalam rantai membutuhkan sekitar 12,800 byte. Tentu saja, Anda dapat menerapkan kode ini satu kali dan menggunakan DELEGATECALL agar setiap dompet dapat memanggilnya, namun Anda masih perlu mengakses kode tersebut di setiap blok yang menggunakannya. Di bawah biaya gas pohon Verkle EIP, 12.800 byte akan membentuk 413 bongkahan. Mengakses bongkahan ini memerlukan pembayaran 2 kali biaya cabang saksi_biaya (total 3.800 gas) dan 413 kali biaya saksi potongan_biaya (total 82.600 gas). Itu bahkan belum menyebutkan titik masuk ERC-4337 itu sendiri, yang dalam versi 0.6.0 memiliki 23.689 byte pada rantai (sekitar 158.700 gas untuk dimuat menurut aturan EIP pohon Verkle).

Hal ini menimbulkan masalah: biaya bahan bakar untuk mengakses kode-kode ini harus diamortisasi di seluruh transaksi dengan cara tertentu. Pendekatan yang saat ini digunakan oleh ERC-4337 tidak terlalu baik: transaksi pertama dalam bundel memerlukan biaya penyimpanan/pembacaan kode satu kali, sehingga jauh lebih mahal dibandingkan transaksi lainnya. Enkapsulasi intra-protokol akan memungkinkan perpustakaan umum bersama ini menjadi bagian dari protokol dan dapat diakses secara bebas oleh semua orang.

Apa yang dapat kita pelajari dari contoh ini, dan kapan sebaiknya enkapsulasi dipraktikkan secara lebih umum?

Dalam contoh ini kita melihat beberapa alasan berbeda untuk merangkum abstraksi akun dalam protokol.

  • **Pendekatan berbasis pasar yang “mendorong kompleksitas hingga batas maksimal” kemungkinan besar akan gagal ketika biaya tetap tinggi. **Faktanya, peta jalan abstraksi akun jangka panjang tampaknya memiliki banyak biaya tetap per blok. 244.100 gas untuk memuat kode dompet standar adalah satu hal; tetapi agregasi dapat menambahkan ratusan ribu gas untuk verifikasi ZK-SNARK, serta biaya verifikasi bukti on-chain. Tidak ada cara untuk membebankan biaya ini kepada pengguna tanpa menimbulkan inefisiensi pasar yang besar, dan mengubah beberapa fitur ini menjadi fitur protokol yang dapat diakses secara bebas oleh semua orang akan menyelesaikan masalah ini dengan sangat baik.
  • **Respon komunitas terhadap bug kode. **Jika sebagian kode digunakan oleh semua pengguna atau sejumlah besar pengguna, seringkali lebih masuk akal bagi komunitas blockchain untuk mengambil tanggung jawab keras untuk memperbaiki bug yang muncul. ERC-4337 memperkenalkan sejumlah besar kode yang dibagikan secara global. Dalam jangka panjang, tidak diragukan lagi lebih masuk akal untuk memperbaiki kesalahan dalam kode melalui hard fork daripada menyebabkan pengguna kehilangan ETH dalam jumlah besar.
  • **Terkadang, bentuk protokol yang lebih kuat dapat diimplementasikan dengan memanfaatkan fungsinya secara langsung. **Contoh utama di sini adalah fitur-fitur yang tahan sensor dalam protokol, seperti daftar penyertaan: Daftar penyertaan dalam protokol dapat menjamin ketahanan sensor lebih baik dibandingkan metode di luar protokol. Agar operasi tingkat pengguna benar-benar mendapat manfaat dari dalam protokol sertakan daftar, Operasi tingkat pengguna individual harus "dapat dibaca" oleh protokol. Contoh lain yang kurang dikenal adalah bahwa desain bukti kepemilikan Ethereum era 2017 memiliki abstraksi akun kunci pasak, yang ditinggalkan demi BLS yang dienkapsulasi karena BLS mendukung mekanisme "agregasi" yang harus diimplementasikan pada protokol dan tingkat jaringan, hal ini dapat membuat pemrosesan tanda tangan dalam jumlah besar menjadi lebih efisien.

Namun penting untuk diingat bahwa bahkan abstraksi akun dalam protokol enkapsulasi masih merupakan “de-enkapsulasi” yang sangat besar dibandingkan dengan status quo. Saat ini, transaksi Ethereum tingkat atas hanya dapat dimulai dari akun milik eksternal (EOA), yang diverifikasi menggunakan satu tanda tangan kurva elips 256k 1 detik. Abstraksi akun menghilangkan hal ini dan menyerahkan kondisi validasi kepada pengguna untuk ditentukan. Oleh karena itu, dalam cerita tentang abstraksi akun ini, kami juga melihat alasan terbesar menentang enkapsulasi: Fleksibilitas untuk memenuhi kebutuhan pengguna yang berbeda.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Mari kita selesaikan ceritanya lebih jauh dengan melihat beberapa contoh fitur lain yang baru-baru ini dipertimbangkan untuk enkapsulasi. Secara khusus kita akan melihat: ZK-EVM, pemisahan pengusul-pembuat, kumpulan memori pribadi, staking likuiditas, dan prakompilasi baru.

Paket ZK-EVM

Mari kita alihkan perhatian kita ke target enkapsulasi potensial lainnya untuk protokol Ethereum: ZK-EVM. Saat ini, kami memiliki sejumlah besar ZK-rollup yang semuanya harus menulis kode yang cukup mirip untuk memverifikasi eksekusi blok Ethereum serupa di ZK-SNARKs. Terdapat ekosistem implementasi independen yang cukup beragam: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth, dan banyak lagi.

Kontroversi baru-baru ini di bidang rollup EVM ZK berkaitan dengan cara menangani bug yang mungkin muncul dalam kode ZK. Saat ini, semua sistem yang beroperasi memiliki semacam mekanisme "dewan keamanan" yang mengontrol sistem pengesahan jika terjadi bug. Tahun lalu, saya mencoba membuat kerangka standar yang akan mendorong proyek-proyek untuk memperjelas seberapa besar mereka mempercayai sistem pengesahan, dan seberapa besar mereka mempercayai Dewan Keamanan, dan secara bertahap mengurangi wewenang mereka atas organisasi tersebut seiring berjalannya waktu.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

*Dalam jangka menengah, rollup kemungkinan akan bergantung pada beberapa sistem sertifikasi, dan Dewan Keamanan hanya mempunyai wewenang dalam kasus ekstrim ketika dua sistem sertifikasi berbeda berbeda. *

Namun, ada perasaan bahwa beberapa pekerjaan ini terasa mubazir. Kami sudah memiliki lapisan dasar Ethereum, memiliki EVM, dan kami sudah memiliki mekanisme kerja untuk menangani bug dalam implementasi: jika ada bug, klien akan diperbarui untuk memperbaikinya, dan rantai akan terus berfungsi . Dari sudut pandang klien yang bermasalah, tampaknya pemblokiran yang telah diselesaikan tidak lagi dikonfirmasi, namun setidaknya kami tidak akan melihat pengguna kehilangan dana. Demikian pula, jika rollup hanya ingin mempertahankan peran yang setara dengan EVM, maka mereka perlu menerapkan tata kelola mereka sendiri untuk terus-menerus mengubah aturan internal ZK-EVM agar sesuai dengan peningkatan ke lapisan dasar Ethereum, yang terasa salah karena pada akhirnya mereka Dibangun di atas dari lapisan dasar Ethereum itu sendiri, ia mengetahui kapan harus melakukan upgrade dan sesuai dengan aturan baru apa.

Karena L2 ZK-EVM ini pada dasarnya menggunakan EVM yang sama persis dengan Ethereum, dapatkah kita memasukkan "verifikasi eksekusi EVM di ZK" ke dalam fungsi protokol dan menangani pengecualian dengan menerapkan konsensus sosial Ethereum, seperti bug dan peningkatan, seperti yang sudah kita lakukan untuk eksekusi EVM lapisan dasar itu sendiri?

Ini adalah topik yang penting dan menantang.

Salah satu topik perdebatan mengenai ketersediaan data di ZK-EVM asli adalah statefulness. ZK-EVM akan jauh lebih efisien dalam data jika tidak perlu membawa data "saksi". Artinya, jika bagian data tertentu telah dibaca atau ditulis di blok sebelumnya, kita dapat berasumsi bahwa pembukti memiliki akses ke data tersebut dan tidak perlu menyediakannya lagi. Ini bukan hanya tentang tidak memuat ulang penyimpanan dan kode; ternyata jika rollup mengompresi data dengan benar, kompresi stateful dapat menghemat hingga 3x data dibandingkan dengan kompresi stateless.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

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 ini jauh lebih mahal dibandingkan menggunakan rollup kode khusus.

**2.**Prakompilasi memungkinkan pointer menunjuk ke data yang digunakan atau dihasilkan oleh eksekusi sebelumnya. Hal ini membuat ZK-rollup mendekati optimal, namun lebih kompleks dan memperkenalkan keadaan baru yang harus disimpan oleh pembuktian.

Apa yang bisa kita pelajari dari ini? Ada alasan bagus untuk merangkum verifikasi ZK-EVM dalam beberapa cara: rollup sudah membangun versi kustomnya sendiri, dan Ethereum bersedia mengimplementasikan EVM di L1 dengan bobot implementasi ganda dan konsensus sosial off-chain. , ini terasa salah, tapi L2 yang melakukan pekerjaan yang sama harus menerapkan sistem rumit yang melibatkan Dewan Keamanan. Namun di sisi lain, ada masalah besar dalam detailnya: Ada versi ZK-EVM yang berbeda, serta biaya dan manfaatnya berbeda. Perbedaan antara stateful dan stateless hanya terlihat di permukaan saja; upaya untuk mendukung kode kustom "hampir-EVM" yang telah dibuktikan oleh sistem lain dapat mengekspos ruang desain yang lebih besar. Oleh karena itu, pengemasan ZK-EVM membawa harapan sekaligus tantangan.

Pengusul enkapsulasi dan pemisahan pembuat (ePBS)

Munculnya MEV menjadikan produksi blok sebagai aktivitas ekonomi dalam skala besar, dengan pelaku yang canggih mampu menghasilkan blok yang menghasilkan lebih banyak pendapatan dibandingkan algoritme default, yang hanya mengamati kumpulan transaksi dan menampungnya. Sejauh ini, komunitas Ethereum telah mencoba memecahkan masalah ini dengan menggunakan skema pemisahan pengusul-pembangun di luar protokol seperti MEV-Boost, yang memungkinkan validator reguler ("pengusul") untuk mendorong blok ke Bangunan dialihdayakan ke aktor khusus ("Pembangun ").

Namun, MEV-Boost membuat asumsi kepercayaan pada kelompok aktor baru yang disebut relay. Dalam dua tahun terakhir, banyak usulan untuk membuat "PBS yang dikemas". Apa manfaat melakukan hal ini? Dalam hal ini, jawabannya sangat sederhana: PBS yang dibangun dengan menggunakan fitur protokol secara langsung lebih kuat (dalam artian memiliki asumsi kepercayaan yang lebih lemah) dibandingkan PBS yang dibangun tanpa menggunakannya. Hal ini mirip dengan kasus merangkum ramalan harga dalam sebuah protokol – meskipun dalam kasus ini, terdapat keberatan yang kuat.

Enkapsulasi kumpulan memori pribadi

Saat pengguna mengirimkan suatu transaksi, transaksi tersebut langsung bersifat publik dan dapat dilihat oleh semua orang, bahkan sebelum transaksi tersebut disertakan secara on-chain. Hal ini membuat pengguna banyak aplikasi rentan terhadap serangan ekonomi, seperti front-running.

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

Masalahnya, skema seperti itu memerlukan jenis enkripsi khusus: Untuk mencegah pengguna membanjiri sistem dan mendekripsinya terlebih dahulu, enkripsi harus didekripsi secara otomatis setelah transaksi benar-benar diterima secara permanen.

Ada berbagai teknik dengan pengorbanan berbeda untuk menerapkan bentuk enkripsi ini. Jon Charbonneau pernah menggambarkannya dengan baik:

  • Enkripsi untuk operator terpusat seperti Flashbots Protect**. **
  • Enkripsi kunci waktu, formulir enkripsi ini dapat didekripsi oleh siapa pun setelah langkah penghitungan berurutan tertentu, dan tidak dapat diparalelkan;
  • Enkripsi Ambang, percayakan komite mayoritas yang jujur untuk mendekripsi data. Lihat konsep rantai suar tertutup untuk saran spesifik.
  • Perangkat Keras Tepercaya, seperti SGX.

Sayangnya, setiap metode enkripsi memiliki kelemahan yang berbeda-beda. Meskipun untuk setiap solusi terdapat segmen pengguna yang bersedia memercayainya, tidak ada solusi yang cukup dipercaya untuk benar-benar diterima oleh Lapisan 1. **Jadi, setidaknya sampai enkripsi tertunda disempurnakan atau terobosan teknologi lainnya, merangkum fungsionalitas perdagangan anti-depan di Lapisan 1 tampaknya merupakan proposisi yang sulit, meskipun itu adalah fitur yang cukup berharga yang dapat dipecahkan oleh banyak aplikasi. rencana telah muncul.

Merangkum pertaruhan likuiditas

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

Sejauh ini, "antarmuka" staking paling sederhana yang memenuhi kedua kebutuhan ini hanyalah token ERC 20: ubah ETH Anda menjadi "staking ETH", tahan, lalu konversikan kembali. Faktanya, penyedia staking likuiditas seperti Lido dan Rocket Pool sudah melakukan hal ini. Namun, ada beberapa mekanisme sentralisasi alami yang berperan dalam staking likuiditas: orang secara alami akan beralih ke staking versi ETH terbesar karena ini adalah versi yang paling familiar dan likuid.

Setiap versi ETH yang dipertaruhkan perlu memiliki beberapa mekanisme untuk menentukan siapa yang dapat menjadi operator node yang mendasarinya. Ini tidak bisa tidak terbatas karena penyerang akan bergabung dan menggunakan dana pengguna untuk memperluas serangan mereka. Saat ini, dua yang teratas adalah Lido dan Rocket Pool, dengan yang pertama memiliki operator node yang masuk daftar putih DAO dan yang terakhir mengizinkan siapa pun untuk menjalankan node dengan deposit 8 ETH. Kedua metode tersebut memiliki risiko yang berbeda: metode Rocket Pool memungkinkan penyerang melakukan serangan sebesar 51% pada jaringan dan memaksa pengguna untuk membayar sebagian besar biaya; sedangkan untuk metode DAO, jika token tertentu yang dipertaruhkan mendominasi, hal itu akan menyebabkan satu sistem tata kelola yang berpotensi disusupi mengendalikan sebagian besar validator Ethereum. Untungnya, protokol seperti Lido telah menerapkan pengamanan, namun satu lapisan pertahanan saja mungkin tidak cukup.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Dalam jangka pendek, salah satu opsinya adalah mendorong peserta ekosistem untuk menggunakan beragam penyedia likuiditas untuk mengurangi kemungkinan pemain dominan menimbulkan risiko sistemik. Namun dalam jangka panjang, hal ini merupakan keseimbangan yang tidak stabil, dan ketergantungan yang berlebihan pada tekanan moral untuk menyelesaikan masalah adalah hal yang berbahaya. Sebuah pertanyaan wajar muncul: **Apakah masuk akal untuk merangkum beberapa fungsi dalam protokol untuk membuat staking likuiditas menjadi kurang terpusat? **

Pertanyaan kuncinya di sini adalah: fungsi dalam protokol seperti apa? Salah satu masalah dengan hanya membuat token "staking ETH" yang sepadan dalam protokol adalah bahwa token tersebut harus memiliki tata kelola Ethereum yang terenkapsulasi untuk memilih siapa yang dapat menjalankan node, atau bersifat terbuka, namun hal tersebut akan mengubahnya menjadi milik Penyerang. Peralatan.

Ide yang menarik adalah artikel Dankrad Feist tentang maksimalisasi pertaruhan likuiditas. Pertama, mari kita ambil keputusan. Jika Ethereum terkena serangan 51%, hanya 5% dari ETH yang diserang yang dapat dipotong. Ini adalah trade-off yang masuk akal; dengan lebih dari 26 juta ETH yang saat ini dipertaruhkan, biaya untuk menyerang sepertiga dari jumlah tersebut (~8 juta ETH) adalah berlebihan, terutama mengingat berapa banyak serangan "di luar model" yang dapat dilakukan dalam satu waktu. biaya rendah. Faktanya, trade-off serupa telah dieksplorasi dalam proposal Komite Super untuk menerapkan finalitas satu slot.

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Jika kami menerima bahwa hanya 5% dari serangan ETH yang dipangkas, maka lebih dari 90% ETH yang dipertaruhkan tidak akan terpengaruh oleh pemotongan tersebut, sehingga dapat digunakan sebagai token staking cair yang sepadan dalam protokol dan kemudian digunakan oleh aplikasi lain.

Jalur ini menarik. Namun masih menyisakan pertanyaan: Apa sebenarnya yang dienkapsulasi? **Rocket Pool cara kerjanya sangat mirip: setiap operator node menyediakan sejumlah dana, dan pemangku kepentingan likuiditas menyediakan sisanya. Kita cukup menyesuaikan beberapa konstanta untuk membatasi penalti pemotongan maksimum menjadi 2 ETH, dan rETH yang ada di Rocket Pool akan menjadi bebas risiko.

Dengan penyesuaian protokol sederhana, kita juga dapat melakukan hal cerdas lainnya. Misalnya, kita menginginkan sistem dengan dua "tingkatan" staking: operator node (persyaratan agunan yang tinggi) dan deposan (tidak ada persyaratan agunan minimum, dapat bergabung dan keluar kapan saja), namun kita masih ingin memberikan sampel secara acak wewenang komite penyimpan untuk mencegah sentralisasi operator node, seperti merekomendasikan daftar transaksi yang harus disertakan (untuk alasan penolakan sensor), mengontrol pemilihan fork selama kebocoran tidak aktif, atau memerlukan tanda tangan di blok. Hal ini dapat dicapai dengan cara yang pada dasarnya tidak sesuai dengan protokol dengan mengubah protokol agar setiap validator menyediakan (i) kunci staking reguler, dan (ii) alamat ETH yang dapat digunakan di setiap slot dipanggil untuk mengeluarkan output. kunci janji sekunder. Protokol akan memberdayakan kedua kunci, namun mekanisme untuk memilih kunci kedua di setiap slot dapat diserahkan kepada protokol staking pool. Mungkin masih lebih baik untuk merangkum beberapa fungsi secara langsung, tetapi perlu dicatat bahwa ruang desain "sertakan beberapa hal dan serahkan hal lain kepada pengguna" ada.

Rangkum lebih banyak prakompilasi

Kontrak yang telah dikompilasi sebelumnya (atau "kontrak yang telah dikompilasi") adalah kontrak Ethereum yang menerapkan operasi kriptografi yang kompleks, dengan logika yang diterapkan secara asli dalam kode klien, bukan kode kontrak pintar EVM. Precoding adalah kompromi yang diadopsi sejak awal pengembangan Ethereum: karena overhead mesin virtual terlalu besar untuk beberapa kode yang sangat kompleks dan sangat terspesialisasi, kami dapat mengimplementasikan beberapa aplikasi penting dalam kode asli. Menghargai operasi penting 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 untuk secp 256 r 1, kurva elips yang sedikit berbeda dari secp 256 k 1 yang digunakan untuk akun ethereum dasar, yang banyak digunakan karena didukung dengan baik oleh modul perangkat keras tepercaya. Gunakan untuk meningkatkan keamanan dompet. Dalam beberapa tahun terakhir, komunitas juga mendorong penambahan prakompilasi untuk BLS-12-377, BW 6-761, penyandingan umum, dan fitur lainnya.

Argumen tandingan terhadap seruan untuk lebih banyak precompiler adalah bahwa banyak dari precompiler yang ditambahkan sebelumnya (seperti RIPEMD dan BLAKE) akhirnya digunakan jauh lebih sedikit 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 Hibernate-But-Always-Resumable, yang akan memungkinkan implementasi EVM berjalan dengan biaya lebih rendah. berbagai kelas kode. Mungkin bahkan prakompilasi yang jarang digunakan dapat dihapus dan diganti dengan implementasi kode EVM (yang tentunya kurang efisien) dari fungsi yang sama. Meskipun demikian, masih ada kemungkinan bahwa ada operasi kriptografi tertentu yang cukup berharga untuk dipercepat, jadi masuk akal untuk menambahkannya sebagai operasi yang telah dikompilasi sebelumnya.

Apa yang telah kita pelajari dari semua ini?

Keinginan untuk merangkum sesedikit mungkin dapat dimengerti dan bagus; hal ini berasal dari tradisi filosofis Unix dalam menciptakan perangkat lunak minimalis yang dapat dengan mudah beradaptasi dengan berbagai kebutuhan pengguna dan menghindari kutukan pembengkakan perangkat lunak. Namun, blockchain bukanlah sistem operasi komputasi personal, melainkan sistem sosial. Ini berarti masuk akal untuk merangkum fungsionalitas tertentu dalam protokol.

Dalam banyak kasus, contoh-contoh lain serupa dengan apa yang kita lihat dalam abstraksi akun. Namun kami juga mendapat beberapa pelajaran baru:

  • Fungsi yang dienkapsulasi dapat membantu menghindari risiko sentralisasi di area lain dari tumpukan:

Seringkali, menjaga protokol dasar tetap minimal dan sederhana mendorong kompleksitas ke beberapa ekosistem di luar protokol. Dari perspektif filosofi Unix, ini bagus. Namun, terkadang terdapat risiko bahwa ekosistem di luar protokol akan menjadi terpusat, biasanya (tetapi tidak hanya) karena tingginya biaya tetap. Enkapsulasi terkadang dapat mengurangi sentralisasi de facto.

  • Merangkum terlalu banyak konten dapat membebani kepercayaan dan beban tata kelola protokol secara berlebihan:

Ini adalah subjek dari artikel sebelumnya tentang "Jangan Membebani Konsensus Ethereum secara Berlebihan": jika merangkum fitur tertentu melemahkan model kepercayaan dan menjadikan Ethereum secara keseluruhan lebih "subyektif", hal ini akan melemahkan Ethereum. Netralitas yang kredibel. Dalam kasus ini, lebih baik memiliki fungsi spesifik sebagai mekanisme di atas Ethereum daripada mencoba memasukkannya ke dalam Ethereum itu sendiri. Kumpulan memori terenkripsi adalah contoh terbaik di sini, yang mungkin agak sulit untuk dienkapsulasi, setidaknya sampai enkripsi latensi membaik.

  • Merangkum terlalu banyak konten dapat membuat protokol menjadi terlalu rumit:

Kompleksitas protokol adalah risiko sistemik yang meningkat dengan menambahkan terlalu banyak fitur pada suatu protokol. Prakompilasi adalah contoh terbaik.

  • Dalam jangka panjang, fungsi enkapsulasi mungkin kontraproduktif karena kebutuhan pengguna tidak dapat diprediksi:

Sebuah fitur yang dianggap penting oleh banyak orang dan akan digunakan oleh banyak pengguna mungkin tidak terlalu sering digunakan dalam praktiknya.

Selain itu, pertaruhan likuiditas, ZK-EVM, dan contoh yang telah dikompilasi sebelumnya menunjukkan kemungkinan jalan tengah: percandian minimal yang layak. Protokol tidak perlu merangkum seluruh fungsi, namun dapat berisi bagian-bagian spesifik yang mengatasi tantangan utama, membuat fungsi tersebut mudah diimplementasikan tanpa menjadi terlalu paranoid atau terlalu sempit. Contohnya meliputi:

  • Daripada merangkum sistem staking likuiditas yang lengkap, lebih baik mengubah aturan penalti staking untuk membuat staking likuiditas yang tidak dapat dipercaya menjadi lebih layak;
  • Daripada merangkum lebih banyak prakompiler, lebih baik merangkum EVM-MAX dan/atau SIMD untuk membuat kelas operasi yang lebih luas lebih mudah diterapkan secara efisien;
  • Dapat dengan mudah merangkum verifikasi EVM alih-alih merangkum keseluruhan konsep rollup.

Kita dapat memperluas diagram sebelumnya sebagai berikut:

Artikel panjang terbaru V God: Haruskah protokol Ethereum merangkum lebih banyak fungsi?

Terkadang masuk akal untuk merangkum sesuatu, dan menghapus prakompiler yang jarang digunakan adalah salah satu contohnya. Abstraksi akun secara keseluruhan, seperti disebutkan sebelumnya, juga merupakan bentuk de-enkapsulasi yang penting. Jika kita ingin mendukung kompatibilitas mundur untuk pengguna yang ada, mekanismenya mungkin sebenarnya sangat mirip dengan mekanisme yang menghapus prakompilasi: salah satu proposalnya adalah EIP-5003, yang memungkinkan EOA mengonversi akun mereka menjadi sama ( atau lebih baik) kontrak fungsional.

Fitur mana yang harus dimasukkan ke dalam protokol dan mana yang harus diserahkan kepada lapisan ekosistem lainnya merupakan sebuah trade-off yang kompleks. Pertukaran ini diperkirakan akan terus meningkat seiring berjalannya waktu seiring dengan meningkatnya pemahaman kita tentang kebutuhan pengguna serta rangkaian ide dan teknologi yang tersedia.

Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
  • Hadiah
  • Komentar
  • Bagikan
Komentar
0/400
Tidak ada komentar
  • Sematkan
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate
Komunitas
Bahasa Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)