Dalam sejarah awal dari apa yang kemudian dikenal sebagai "Ethereum 2.0," ada keinginan kuat untuk membuat protokol yang bersih, sederhana, dan estetis yang mencoba membangun sendiri dengan sesedikit mungkin dan meninggalkan hampir semua pekerjaan semacam itu kepada pengguna. Idealnya, protokol hanyalah mesin virtual, dan memvalidasi potongan hanyalah panggilan mesin virtual.
"Fungsi transisi status" (fungsi yang memproses potongan) hanya akan menjadi panggilan VM tunggal, dan semua logika lainnya akan terjadi melalui kontrak: beberapa kontrak tingkat sistem, tetapi sebagian besar kontrak disediakan oleh pengguna. Fitur yang sangat bagus dari model ini adalah bahwa bahkan seluruh hard fork dapat digambarkan sebagai transaksi tunggal untuk kontrak prosesor blok yang akan disetujui oleh tata kelola off-chain atau on-chain dan kemudian dijalankan dengan hak istimewa yang lebih tinggi.
Diskusi pada tahun 2015 ini berlaku khususnya untuk dua bidang yang kami pertimbangkan: abstraksi akun dan penskalaan. Dalam kasus penskalaan, idenya adalah mencoba membuat bentuk abstraksi maksimum penskalaan yang terasa seperti perpanjangan alami dari bagan di atas. Kontrak dapat memanggil data yang tidak disimpan oleh sebagian besar node Ethereum, dan protokol akan mendeteksi ini dan menyelesaikan panggilan dengan semacam fungsi komputasi tambahan yang sangat umum. Dari perspektif mesin virtual, panggilan masuk ke beberapa subsistem terpisah dan secara ajaib mengembalikan jawaban yang benar setelah beberapa saat.
Kami menjelajahi garis pemikiran ini secara singkat, tetapi dengan cepat menyerah karena kami terlalu fokus untuk memverifikasi bahwa semua jenis penskalaan blockchain dimungkinkan. Meskipun kita akan lihat nanti, kombinasi pengambilan sampel ketersediaan data dan ZK-EVM berarti bahwa kemungkinan masa depan untuk penskalaan Ethereum sebenarnya terlihat sangat dekat dengan visi ini! Di sisi lain, untuk abstraksi akun, kami tahu sejak awal bahwa beberapa jenis implementasi dimungkinkan, jadi penelitian segera mulai mencoba membawa sesuatu sedekat mungkin ke titik awal murni "perdagangan hanyalah panggilan" menjadi kenyataan.
Antara memproses transaksi dan membuat panggilan EVM yang mendasari sebenarnya dari alamat pengirim, ada banyak kode boilerplate, dan lebih banyak kode boilerplate setelah itu. Bagaimana kita mengurangi kode ini sedekat mungkin dengan nol?
Salah satu kode utama di sini adalah validate_transaction(state, tx), yang bertanggung jawab untuk memeriksa bahwa transaksi memiliki nonce dan tanda tangan yang benar. Sejak awal, tujuan praktis abstraksi akun adalah untuk memungkinkan pengguna mengganti verifikasi dasar non-inkremental dan 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 merancang ulang apply_transaction sebagai panggilan EVM sederhana bukan hanya tugas "kode bersih demi membuat kode bersih"; Sebaliknya, ini tentang memindahkan logika ke kode akun pengguna, memberi pengguna fleksibilitas yang mereka butuhkan.
Namun, bersikeras bahwa menerapkan \ _transaction mengandung logika tetap sesedikit mungkin akhirnya menciptakan banyak tantangan. Kita dapat melihat salah satu proposal abstraksi akun paling awal, EIP-86 .
Jika EIP-86 disertakan apa adanya, itu akan mengurangi kompleksitas EVM dengan biaya meningkatkan kompleksitas bagian lain dari tumpukan Ethereum secara besar-besaran, membutuhkan kode yang pada dasarnya identik untuk ditulis di tempat lain, kecuali untuk memperkenalkan kategori aneh yang sama sekali baru, seperti transaksi yang sama dengan nomor hash yang sama dapat muncul beberapa kali dalam rantai, belum lagi masalah beberapa pembatalan.
Beberapa masalah pembatalan dalam abstraksi akun. Satu transaksi yang disertakan secara on-chain dapat membatalkan ribuan transaksi lain di mempool, membuat mempool mudah membanjiri dengan harga murah.
Sejak itu, abstraksi akun telah berkembang secara bertahap. EIP-86 kemudian menjadi EIP-208 dan akhirnya EIP-2938 praktis.
Namun, EIP-2938 sama sekali tidak minimalis. Isinya meliputi:
· Jenis transaksi baru
· Variabel global untuk tiga cakupan perdagangan baru
· Dua opcode baru, termasuk opcode PAYgas yang sangat kikuk untuk menangani harga gas dan pemeriksaan batas gas, melakukan breakpoint sebagai EVM, dan menyimpan sementara ETH dengan biaya satu kali
· Serangkaian strategi penambangan dan penyiaran ulang yang kompleks, termasuk daftar opcode terlarang selama fase verifikasi transaksi
Untuk menerapkan abstraksi akun tanpa melibatkan pengembang inti Ethereum (yang fokus pada pengoptimalan klien Ethereum dan menerapkan penggabungan), EIP-2938 akhirnya dirancang ulang ke ERC-4337 sepenuhnya di luar protokol.
Karena ini adalah ERC, itu tidak memerlukan hard fork dan secara teknis ada "di luar protokol Ethereum". Jadi...... Apakah masalahnya terpecahkan? Ternyata bukan itu masalahnya. Peta jalan jangka menengah ERC-4337 saat ini sebenarnya melibatkan akhirnya mengubah sebagian besar ERC-4337 menjadi satu set fitur protokol, yang merupakan contoh panduan yang berguna mengapa jalur ini harus dipertimbangkan.
Paket ERC-4337
Ada beberapa alasan utama yang dibahas untuk akhirnya membawa ERC-4337 kembali ke protokol:
Efisiensi gas: Setiap operasi yang dilakukan di dalam EVM menghasilkan beberapa tingkat overhead mesin virtual, termasuk inefisiensi saat menggunakan fitur mahal gas seperti slot penyimpanan. Saat ini, inefisiensi tambahan ini menambahkan hingga setidaknya 20.000 gas, atau lebih. Menempatkan 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 menakutkan, semua dompet yang kompatibel dengan ERC-4337 mungkin melihat semua dana mereka mengering. Mengganti kontrak dengan fungsionalitas dalam protokol menciptakan kewajiban implisit untuk memperbaiki kesalahan kode melalui hard fork, sehingga menghilangkan risiko dana pengguna mengering.
Dukungan untuk opcode EVM seperti txt.origin. ERC-4337 sendiri menyebabkan txt.origin mengembalikan alamat "bundler" yang mengemas serangkaian tindakan pengguna ke dalam transaksi. Abstraksi akun asli memecahkan masalah ini dengan membuat txt.origin menunjuk ke akun aktual yang mengirim transaksi, membuatnya bekerja dengan cara yang sama seperti EOA.
Tahan sensor: Salah satu tantangan pemisahan pengusul/pembangun adalah menjadi lebih mudah untuk meninjau transaksi individual. Masalah ini dapat sangat diatasi di dunia di mana protokol Ethereum dapat mengenali satu transaksi, memungkinkan pengusul untuk 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 buram terhadap protokol Ethereum; Oleh karena itu, daftar inklusi yang disediakan oleh protokol Ethereum tidak akan dapat memberikan ketahanan sensor terhadap operasi pengguna ERC-4337. Merangkum ERC-4337 dan menjadikan tindakan pengguna sebagai jenis transaksi yang "sesuai" akan menyelesaikan masalah ini.
Perlu disebutkan bahwa dalam bentuknya saat ini, ERC-4337 jauh lebih mahal daripada transaksi Ethereum "dasar": biaya transaksi adalah 21.000 gas, sedangkan ERC-4337 berharga sekitar 42.000 gas.
Secara teoritis, harus dimungkinkan untuk menyesuaikan sistem biaya gas EVM sampai biaya dalam perjanjian dan biaya akses di luar protokol ke penyimpanan cocok; Ketika jenis operasi pengeditan penyimpanan lainnya lebih murah, tidak ada alasan untuk mentransfer ETH pada 9000 gas. Faktanya, dua EIP yang terkait dengan konversi pohon Verkle yang akan datang sebenarnya mencoba melakukan hal itu. Tetapi bahkan jika kita melakukannya, ada alasan yang jelas mengapa fungsionalitas protokol yang dienkapsulasi pasti akan jauh lebih murah daripada kode EVM, tidak peduli seberapa efisien EVM menjadi: kode yang dienkapsulasi tidak perlu membayar gas untuk preloading.
Dompet ERC-4337 yang berfungsi penuh berukuran besar, dan implementasi yang mengkompilasi dan menempatkannya di rantai membutuhkan sekitar 12.800 byte. Tentu saja, Anda dapat menyebarkan kode ini sekali dan menggunakan DELEGATECALL untuk memungkinkan setiap dompet individu memanggilnya, tetapi Anda masih perlu mengakses kode di setiap blok yang menggunakannya. Di bawah EIP biaya gas pohon Verkle, 12.800 byte akan membentuk 413 potongan, dan mengakses potongan ini akan membutuhkan membayar 2x cabang saksi _cost (total 3.800 gas) dan 413x potongan saksi \ _cost (total 82.600 gas). Dan itu bahkan belum mulai 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 sesuai dengan aturan EIP pohon Verkle).
Ini mengarah pada masalah: biaya gas untuk benar-benar mengakses kode-kode ini entah bagaimana harus diamortisasi di seluruh transaksi. Pendekatan saat ini yang digunakan oleh ERC-4337 tidak terlalu baik: transaksi pertama dalam bundel mengkonsumsi biaya penyimpanan / kode baca satu kali, membuatnya jauh lebih mahal daripada transaksi lainnya. Enkapsulasi dalam protokol akan memungkinkan perpustakaan bersama publik ini menjadi bagian dari protokol dan dapat diakses secara bebas oleh semua orang.
Apa yang bisa kita pelajari dari contoh ini, dan kapan pengemasan akan lebih umum? **
Dalam contoh ini, kita melihat beberapa alasan berbeda untuk merangkum aspek abstraksi akun dalam protokol.
Pendekatan berbasis pasar yang "mendorong kompleksitas ke tepi" kemungkinan besar akan gagal ketika biaya tetap tinggi. Bahkan, peta jalan abstraksi akun jangka panjang sepertinya setiap blok memiliki banyak biaya tetap. 244, 100 gas untuk memuat kode dompet standar adalah satu hal; Tetapi agregasi dapat menambahkan ratusan ribu gas ke validasi ZK-SNARK, serta biaya on-chain untuk validasi proof-of-chain. Tidak ada cara untuk membebankan biaya ini kepada pengguna tanpa memperkenalkan banyak inefisiensi pasar, dan menerjemahkan beberapa fitur ini ke dalam fitur protokol yang dapat diakses semua orang secara gratis menyelesaikan masalah ini dengan baik.
Respons seluruh komunitas terhadap bug kode. Jika beberapa cuplikan kode digunakan oleh semua pengguna atau rentang pengguna yang sangat luas, biasanya lebih masuk akal bagi komunitas blockchain untuk bertanggung jawab atas hard fork untuk memperbaiki bug yang muncul. ERC-4337 memperkenalkan sejumlah besar kode yang dibagikan secara global, dan memperbaiki bug dalam kode melalui hard fork tidak diragukan lagi lebih masuk akal dalam jangka panjang daripada menyebabkan pengguna kehilangan banyak ETH.
Terkadang, bentuk yang lebih kuat dapat dicapai dengan memanfaatkan fungsionalitas protokol secara langsung. Contoh utama di sini adalah fitur anti-sensor dalam protokol, seperti daftar inklusi: daftar inklusi dalam protokol dapat menjamin ketahanan sensor lebih baik daripada metode di luar protokol, dan agar operasi tingkat pengguna benar-benar mendapat manfaat dari daftar inklusi dalam protokol, satu operasi tingkat pengguna harus "dapat dibaca" ke protokol. Contoh lain yang kurang dikenal adalah desain proof-of-stake Ethereum era 2017 yang mengabstraksi akun kunci saham, yang ditinggalkan demi merangkum BLS, karena BLS mendukung mekanisme "agregasi" yang harus diimplementasikan pada tingkat protokol dan jaringan, yang dapat membuat penanganan sejumlah besar tanda tangan lebih efisien.
Tetapi penting untuk diingat bahwa bahkan merangkum abstraksi akun dalam protokol masih merupakan "de-enkapsulasi" yang sangat besar dibandingkan dengan situasi saat ini. Saat ini, transaksi Ethereum tingkat atas hanya dapat dimulai dari akun milik eksternal (EOA) yang diverifikasi dengan tanda tangan kurva eliptik secp 256k1 tunggal. Abstraksi akun menghilangkan ini dan menyerahkan kriteria validasi kepada pengguna untuk ditentukan. Jadi, dalam cerita tentang abstraksi akun ini, kami juga melihat argumen terbesar terhadap enkapsulasi: fleksibilitas untuk memenuhi kebutuhan pengguna yang berbeda.
Mari kita sempurnakan cerita ini lebih lanjut dengan melihat beberapa contoh fitur lain yang baru-baru ini dianggap dienkapsulasi. Kami akan memberikan perhatian khusus pada: ZK-EVM, pemisahan pengusul-pembangun, mempool pribadi, staking likuiditas, dan prakompilasi baru.
Paket ZK-EVM
Mari kita mengalihkan perhatian kita ke target enkapsulasi potensial lain dari 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-SNARK. Ada ekosistem implementasi independen yang cukup beragam: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth dan banyak lagi.
Kontroversi baru-baru ini di ruang EVM ZK-rollup berkaitan dengan cara menangani kemungkinan bug dalam kode ZK. Saat ini, semua sistem yang berjalan ini memiliki beberapa bentuk mekanisme "Dewan Keamanan" yang mengontrol sistem pengesahan jika terjadi bug. Tahun lalu, saya mencoba membuat kerangka kerja standar untuk mendorong proyek mengklarifikasi tingkat kepercayaan mereka pada sistem sertifikasi, serta di Dewan Keamanan, dan secara bertahap mengurangi otoritas mereka atas organisasi dari waktu ke waktu.
Dalam jangka menengah, rollup dapat bergantung pada beberapa sistem pengesahan, dan Dewan Keamanan akan memiliki kekuatan hanya dalam kasus-kasus ekstrim di mana dua sistem pengesahan yang berbeda berbeda.
Namun, ada perasaan bahwa beberapa pekerjaan terasa berlebihan. Kami sudah memiliki lapisan dasar Ethereum, ia memiliki EVM, dan kami sudah memiliki mekanisme kerja untuk menangani bug dalam implementasi: jika ada bug, klien akan memperbarui untuk memperbaikinya, dan kemudian rantai akan terus berfungsi. Dari perspektif klien buggy, tampaknya blok yang telah diselesaikan tidak akan lagi dikonfirmasi, tetapi setidaknya kita tidak akan melihat pengguna kehilangan uang. Demikian pula, jika rollup hanya ingin mempertahankan peran mereka setara dengan EVM, maka mereka perlu menerapkan tata kelola mereka sendiri untuk terus-menerus mengubah aturan ZK-EVM internal mereka agar sesuai dengan peningkatan ke lapisan dasar Ethereum, yang terasa salah karena pada akhirnya mereka dibangun di atas lapisan dasar Ethereum itu sendiri, yang tahu kapan harus meningkatkan dan sesuai dengan aturan baru apa.
Karena L2 ZK-EVM ini pada dasarnya menggunakan EVM yang persis sama dengan Ethereum, dapatkah kita entah bagaimana memasukkan "memverifikasi eksekusi EVM di ZK" ke dalam fungsi protokol dan menangani pengecualian seperti bug dan peningkatan dengan menerapkan konsensus sosial Ethereum, seperti yang sudah kita lakukan dengan implementasi EVM lapisan dasar itu sendiri?
Ini adalah topik yang penting dan menantang.
Salah satu topik perdebatan yang mungkin tentang ketersediaan data di ZK-EVM asli adalah kenegaraan. Jika ZK-EVM tidak perlu membawa data "saksi", efisiensi data mereka akan jauh lebih tinggi. Artinya, jika sepotong data tertentu telah dibaca atau ditulis di beberapa blok sebelumnya, kita dapat dengan mudah mengasumsikan bahwa prover memiliki akses ke sana dan tidak harus membuatnya tersedia lagi. Ini bukan hanya tentang tidak memuat ulang penyimpanan dan kode; Ternyata kompresi stateful dapat menghemat hingga 3x data dibandingkan dengan kompresi stateless jika satu rollup memampatkan data dengan benar.
Ini berarti bahwa untuk prakompilasi ZK-EVM, kami memiliki dua opsi:
Prakompilasi mengharuskan semua data tersedia dalam potongan yang sama. Ini berarti bahwa prover dapat stateless, tetapi itu juga berarti bahwa menggunakan ZK-rollup yang telah dikompilasi ini jauh lebih mahal daripada menggunakan rollup dengan kode khusus.
Prakompilasi memungkinkan pointer menunjuk ke data yang sebelumnya dieksekusi, digunakan, atau dihasilkan. Ini membuat ZK-rollup hampir optimal, tetapi lebih kompleks dan memperkenalkan keadaan baru yang harus disimpan oleh prover.
Apa yang bisa kita pelajari dari ini? Ada alasan bagus untuk entah bagaimana merangkum verifikasi ZK-EVM: rollup sudah membangun versi kustomnya sendiri, dan Ethereum bersedia mempertimbangkan beberapa implementasi dan konsensus sosial off-chain pada L1 untuk mengeksekusi EVM, yang terasa salah, tetapi L2 melakukan pekerjaan yang persis sama harus menerapkan gadget kompleks yang melibatkan Dewan Keamanan. Tetapi di sisi lain, ada masalah besar dalam detailnya: ada berbagai versi ZK-EVM, yang berbeda dalam biaya dan manfaat. Perbedaan antara stateful dan stateless hanya menggores permukaan; Mencoba mendukung "hampir-EVM", kode khusus yang telah dibuktikan oleh sistem lain, dapat mengekspos lebih banyak ruang desain. Oleh karena itu, merangkum ZK-EVM menghadirkan janji dan tantangan.
** Pembungkus dan Builder Pemisahan (ePBS) **
Munculnya MEV telah membuat produksi blok menjadi kegiatan ekonomi berskala besar, dengan peserta yang kompleks mampu menghasilkan blok yang menghasilkan lebih banyak pendapatan daripada algoritma default, yang hanya mengamati mempool transaksi dan memuatnya. 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 melakukan outsourcing konstruksi blok ke peserta khusus ("pembangun").
Namun, MEV-Boost membuat asumsi kepercayaan di kelas peserta baru yang disebut relay. Dalam dua tahun terakhir, ada banyak proposal untuk membuat "PBS yang dienkapsulasi". Apa manfaatnya? Dalam hal ini, jawabannya sederhana: PBS yang dibangun langsung dengan fitur protokol lebih kuat (dalam arti memiliki asumsi kepercayaan yang lebih lemah) daripada PBS yang dibangun tanpa mereka. Ini mirip dengan kasus dengan oracle harga dalam protokol enkapsulasi – meskipun dalam kasus ini, ada juga oposisi yang kuat.
** Enkapsulasi Kolam Memori Pribadi **
Ketika pengguna mengirim transaksi, itu segera publik dan terlihat oleh semua orang, bahkan sebelum itu termasuk dalam rantai. Ini membuat pengguna banyak aplikasi rentan terhadap serangan ekonomi, seperti transaksi preemptive.
Baru-baru ini, ada sejumlah proyek yang didedikasikan untuk menciptakan "mempool pribadi" (atau "mempool terenkripsi") yang mengenkripsi transaksi pengguna sampai mereka diterima secara ireversibel ke dalam blok.
Masalahnya, bagaimanapun, adalah bahwa skema tersebut memerlukan jenis enkripsi khusus: untuk mencegah pengguna membanjiri sistem dan mendekripsinya terlebih dahulu, enkripsi harus secara otomatis didekripsi setelah transaksi memang diterima secara ireversibel.
Untuk mencapai bentuk enkripsi ini, ada berbagai teknik trade-off. Jon Charbonneau pernah mengatakannya dengan baik:
Enkripsi operator terpusat, seperti Flashbots Protect.
enkripsi timelock, yang dapat didekripsi oleh siapa saja setelah langkah perhitungan berurutan tertentu dan tidak dapat diparalelkan;
Enkripsi ambang batas, mempercayai komite mayoritas yang jujur untuk mendekripsi data. Untuk rekomendasi spesifik, lihat Konsep Rantai Suar Tertutup.
Perangkat keras tepercaya, seperti SGX.
Sayangnya, setiap enkripsi memiliki kelemahan yang berbeda. Sementara untuk setiap solusi, ada subset pengguna yang mau mempercayainya, tidak ada solusi yang cukup dipercaya untuk benar-benar diterima oleh Layer 1. Jadi, setidaknya sampai enkripsi latensi disempurnakan atau terobosan teknologi lainnya, merangkum fungsionalitas perdagangan anti-lanjutan di Layer 1 tampak seperti proposisi yang sulit, bahkan jika itu adalah fitur yang cukup berharga sehingga banyak solusi aplikasi telah muncul.
Staking likuiditas yang dienkapsulasi
Kebutuhan umum bagi pengguna Ethereum DeFi adalah kemampuan untuk menggunakan ETH mereka secara bersamaan untuk staking dan sebagai jaminan di aplikasi lain. Kebutuhan umum lainnya hanyalah untuk kenyamanan: pengguna ingin dapat mempertaruhkan (dan melindungi kunci staking online) tanpa kerumitan menjalankan node dan menjaganya selalu online.
Sejauh ini, "antarmuka" staking paling sederhana yang memenuhi kedua kebutuhan ini hanyalah token ERC 20: ubah ETH Anda menjadi "stake ETH", tahan, dan ubah kembali. Faktanya, penyedia staking likuiditas seperti Lido dan Rocket Pool sudah mulai melakukannya. Namun, staking likuiditas memiliki beberapa mekanisme sentralisasi alami di tempat kerja: orang secara alami masuk ke versi terbesar dari staking ETH karena ini adalah yang paling akrab dan likuid.
Setiap versi staking ETH memerlukan beberapa mekanisme untuk menentukan siapa yang dapat menjadi operator node yang mendasarinya. Itu tidak bisa tidak terbatas, karena penyerang akan bergabung dan memperkuat serangan dengan dana pengguna. Saat ini, dua teratas adalah Lido, yang memiliki operator node daftar putih DAO, dan Rocket Pool, yang memungkinkan siapa saja untuk menjalankan node dengan 8 ETH yang disimpan. Kedua metode memiliki risiko yang berbeda: pendekatan Rocket Pool memungkinkan penyerang untuk melakukan serangan 51% pada jaringan dan memaksa pengguna untuk membayar sebagian besar biaya; Adapun pendekatan DAO, jika token staking tertentu mendominasi, itu menghasilkan gadget tata kelola tunggal yang berpotensi diserang yang mengendalikan sebagian besar dari semua validator Ethereum. Yang pasti, protokol seperti Lido sudah memiliki tindakan pencegahan, tetapi lapisan pertahanan mungkin tidak cukup.
Dalam jangka pendek, salah satu pilihannya adalah mendorong peserta ekosistem untuk menggunakan beragam penyedia staking likuiditas untuk mengurangi kemungkinan risiko sistemik dari satu perusahaan. Namun, dalam jangka panjang, ini adalah keseimbangan yang genting, dan berbahaya untuk terlalu mengandalkan tekanan moral untuk menyelesaikan masalah. Sebuah pertanyaan alami muncul: apakah masuk akal untuk merangkum beberapa jenis fungsi dalam protokol untuk membuat staking likuiditas kurang terpusat?
Pertanyaan kuncinya di sini adalah: fungsi dalam protokol seperti apa? Masalah dengan hanya membuat token "staking ETH" yang dapat dipertukarkan dalam protokol adalah bahwa ia harus memiliki tata kelola Ethereum yang dienkapsulasi untuk memilih siapa yang menjalankan node, atau terbuka, tetapi ini mengubahnya menjadi alat untuk penyerang.
Ide yang menarik adalah artikel Dankrad Feist tentang maksimalisasi staking likuiditas. Pertama, mari kita gigit jari dan jika Ethereum diserang oleh 51%, hanya 5% dari serangan ETH yang dapat disita. Ini adalah trade-off yang masuk akal; Dengan lebih dari 26 juta ETH saat ini sedang dipertaruhkan, sepertiga dari itu (sekitar 8 juta ETH) dari biaya serangan berlebihan, terutama mengingat berapa banyak serangan "di luar model" yang dapat dilakukan dengan biaya lebih rendah. Bahkan, trade-off serupa telah dieksplorasi dalam proposal Komisi Super untuk menerapkan finalitas slot tunggal.
Jika kami menerima bahwa hanya 5% dari ETH serangan yang disita, maka lebih dari 90% ETH yang dipertaruhkan tidak akan terpengaruh oleh penyitaan, sehingga mereka dapat digunakan sebagai token staking likuiditas yang sepadan dalam protokol dan kemudian digunakan oleh aplikasi lain.
Jalannya menarik. Tapi itu masih menyisakan pertanyaan: apa sebenarnya yang dienkapsulasi? Rocket Pool bekerja sangat mirip: setiap operator node menyediakan sejumlah dana, dan staker likuiditas menyediakan sisanya. Kami cukup menyesuaikan beberapa konstanta untuk membatasi penalti maksimum hingga 2 ETH dan rETH yang ada dari Rocket Pool akan menjadi bebas risiko.
Dengan penyesuaian protokol sederhana, kita juga bisa melakukan hal-hal pintar lainnya. Sebagai contoh, katakanlah kita menginginkan sistem dengan dua "lapisan" staking: operator node (persyaratan jaminan tinggi) dan deposan (tidak ada persyaratan jaminan minimum dan dapat bergabung dan pergi kapan saja), tetapi kita masih ingin mencegah sentralisasi operator node dengan memberdayakan komite deposan sampel acak, seperti menyarankan daftar transaksi yang harus disertakan (untuk alasan tahan sensor), mengontrol pemilihan garpu selama kebocoran tidak aktif, atau memerlukan penandatanganan blok. Ini dapat dicapai dengan cara yang pada dasarnya terlepas dari protokol dengan mengutak-atik protokol untuk mengharuskan setiap validator menyediakan (i) kunci staking biasa, dan (ii) alamat ETH yang dapat dipanggil di setiap slot untuk menghasilkan kunci staking sekunder. Protokol akan memberikan kekuatan pada kedua kunci, tetapi mekanisme untuk memilih kunci kedua di setiap slot dapat diserahkan kepada protokol staking pool. Mungkin masih lebih baik untuk merangkum beberapa fitur secara langsung, tetapi perlu dicatat bahwa ruang desain "sertakan beberapa hal dan serahkan yang lainnya kepada pengguna" ini ada.
** Enkapsulasi lebih banyak prakompilasi **
Precompiled (atau "kontrak precomilasi") adalah kontrak Ethereum yang mengimplementasikan operasi kriptografi kompleks, logika yang diimplementasikan secara native dalam kode klien, daripada kode kontrak pintar EVM. Precoding adalah kompromi yang diadopsi pada awal pengembangan Ethereum: karena overhead mesin virtual terlalu besar untuk beberapa kode yang sangat kompleks dan sangat terspesialisasi, kami dapat menerapkan beberapa operasi utama dalam kode lokal yang berharga bagi aplikasi penting untuk membuatnya lebih cepat. Saat ini, ini pada dasarnya mencakup beberapa fungsi hash spesifik dan operasi kurva elips.
Saat ini ada dorongan untuk menambahkan prakompilasi untuk secp 256 R1, kurva elips yang sedikit berbeda dari secp 256 K1 untuk akun Ethereum dasar, karena didukung dengan baik oleh modul perangkat keras tepercaya, sehingga penggunaannya secara luas dapat meningkatkan keamanan dompet. Dalam beberapa tahun terakhir, komunitas juga telah mendorong penambahan prakompilasi untuk BLS-12-377, BW 6-761, pasangan umum, dan fitur lainnya.
Argumen tandingan untuk permintaan ini untuk lebih banyak file yang telah dikompilasi sebelumnya adalah bahwa banyak prakompilasi yang ditambahkan sebelumnya (misalnya RIPEMD dan BLAKE) akhirnya menggunakan jauh lebih sedikit dari yang diharapkan, dan kita harus belajar dari mereka. Alih-alih menambahkan lebih banyak prakompilasi untuk operasi tertentu, mungkin kita harus fokus pada pendekatan yang lebih lembut berdasarkan ide-ide seperti EVM-MAX dan proposal SIMD yang tidak aktif tetapi selalu dapat dipulihkan, yang akan memungkinkan implementasi EVM untuk mengeksekusi berbagai kelas kode dengan biaya lebih rendah. Mungkin bahkan prakompilasi yang jarang digunakan dapat dihapus dan diganti dengan implementasi kode EVM (yang pasti kurang efisien) dengan fungsi yang sama. Yang mengatakan, masih mungkin bahwa ada operasi kriptografi tertentu yang cukup berharga untuk mempercepat, jadi masuk akal untuk menambahkannya sebagai prakompilasi.
Apa yang telah kita pelajari dari semua ini?
Keinginan untuk merangkum sesedikit mungkin dapat dimengerti dan baik; Ini berasal dari tradisi filosofis Unix menciptakan perangkat lunak minimalis yang dapat dengan mudah disesuaikan dengan kebutuhan pengguna yang berbeda dan menghindari kutukan perangkat lunak yang membengkak. Namun, blockchain bukanlah sistem operasi komputasi pribadi, tetapi sistem sosial. Ini berarti masuk akal untuk merangkum fungsionalitas tertentu dalam protokol.
Dalam banyak kasus, contoh-contoh lain ini mirip dengan apa yang kita lihat dalam abstraksi akun. Tetapi kami juga belajar beberapa pelajaran baru:
Enkapsulasi dapat membantu menghindari risiko sentralisasi di tempat lain dalam tumpukan:
Seringkali, menjaga protokol dasar minimal dan sederhana mendorong kompleksitas di luar beberapa protokol ekosistem. Dari sudut pandang filosofis Unix, ini bagus. Namun, terkadang ada risiko bahwa ekosistem di luar protokol akan terpusat, biasanya (tetapi tidak hanya) karena biaya tetap yang tinggi. Enkapsulasi terkadang dapat mengurangi sentralisasi de facto.
Merangkum terlalu banyak konten dapat memperluas beban kepercayaan dan tata kelola pada protokol:
Ini adalah topik artikel sebelumnya tentang "Jangan membebani konsensus Ethereum": jika merangkum fungsi tertentu melemahkan model kepercayaan dan membuat Ethereum secara keseluruhan lebih "subyektif", itu melemahkan netralitas tepercaya Ethereum. Dalam kasus ini, lebih baik menyajikan fitur tertentu sebagai mekanisme di atas Ethereum daripada mencoba memperkenalkannya ke Ethereum itu sendiri. Di sini, kumpulan memori terenkripsi adalah contoh terbaik, dan mungkin agak sulit untuk dienkapsulasi, setidaknya sampai enkripsi latensi meningkat.
Merangkum terlalu banyak dapat memperumit protokol:
Kompleksitas protokol adalah risiko sistemik yang dapat ditingkatkan dengan menambahkan terlalu banyak fitur ke protokol. Prakompilasi adalah contoh terbaik.
Dalam jangka panjang, fungsi enkapsulasi dapat menjadi bumerang karena kebutuhan pengguna tidak dapat diprediksi:
Fitur yang dianggap penting oleh banyak orang dan akan digunakan oleh banyak pengguna kemungkinan tidak digunakan secara teratur dalam praktiknya.
Selain itu, staking likuiditas, ZK-EVM, dan kasus-kasus yang telah dikompilasi sebelumnya menunjukkan kemungkinan jalan tengah: pengabadian minimal yang layak. Protokol tidak perlu merangkum seluruh fungsi, tetapi dapat berisi bagian-bagian tertentu yang mengatasi tantangan utama, membuat fungsi mudah diimplementasikan tanpa terlalu paranoid atau terlalu sempit. Contohnya termasuk:
Daripada merangkum sistem penjaminan likuiditas lengkap, lebih baik mengubah aturan penalti staking untuk membuat janji likuiditas tanpa kepercayaan lebih layak;
Alih-alih merangkum lebih banyak precompiler, enkapsulasi EVM-MAX dan / atau SIMD untuk membuatnya lebih mudah untuk mengimplementasikan secara efisien untuk berbagai kategori operasi yang lebih luas;
Verifikasi EVM dapat dengan mudah dienkapsulasi alih-alih merangkum seluruh konsep rollup.
Kita dapat memperluas grafik sebelumnya sebagai berikut:
Terkadang masuk akal untuk membungkus sesuatu, dan menghapus prakompilasi yang jarang digunakan adalah contohnya. Abstraksi akun secara keseluruhan, seperti yang disebutkan sebelumnya, juga merupakan bentuk penting dari de-enkapsulasi. Jika kita ingin mendukung kompatibilitas mundur untuk pengguna yang ada, mekanismenya mungkin sebenarnya sangat mirip dengan yang mende-enkapsulasi yang telah dikompilasi sebelumnya: salah satu proposal adalah EIP-5003, yang akan memungkinkan EOA untuk mengubah akunnya menjadi kontrak dengan fungsi yang sama (atau lebih baik).
Fitur mana yang harus dimasukkan ke dalam protokol dan mana yang harus diserahkan ke lapisan ekosistem lainnya adalah trade-off yang kompleks. Trade-off ini diperkirakan akan terus meningkat dari waktu ke waktu karena pemahaman kami tentang kebutuhan pengguna dan ide-ide yang tersedia dan rangkaian teknologi terus meningkat.
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.
Vitalik Buterin: Haruskah Ethereum merangkum lebih banyak fitur?
** Filosofi awal minimalisme protokol **
Dalam sejarah awal dari apa yang kemudian dikenal sebagai "Ethereum 2.0," ada keinginan kuat untuk membuat protokol yang bersih, sederhana, dan estetis yang mencoba membangun sendiri dengan sesedikit mungkin dan meninggalkan hampir semua pekerjaan semacam itu kepada pengguna. Idealnya, protokol hanyalah mesin virtual, dan memvalidasi potongan hanyalah panggilan mesin virtual.
"Fungsi transisi status" (fungsi yang memproses potongan) hanya akan menjadi panggilan VM tunggal, dan semua logika lainnya akan terjadi melalui kontrak: beberapa kontrak tingkat sistem, tetapi sebagian besar kontrak disediakan oleh pengguna. Fitur yang sangat bagus dari model ini adalah bahwa bahkan seluruh hard fork dapat digambarkan sebagai transaksi tunggal untuk kontrak prosesor blok yang akan disetujui oleh tata kelola off-chain atau on-chain dan kemudian dijalankan dengan hak istimewa yang lebih tinggi.
Diskusi pada tahun 2015 ini berlaku khususnya untuk dua bidang yang kami pertimbangkan: abstraksi akun dan penskalaan. Dalam kasus penskalaan, idenya adalah mencoba membuat bentuk abstraksi maksimum penskalaan yang terasa seperti perpanjangan alami dari bagan di atas. Kontrak dapat memanggil data yang tidak disimpan oleh sebagian besar node Ethereum, dan protokol akan mendeteksi ini dan menyelesaikan panggilan dengan semacam fungsi komputasi tambahan yang sangat umum. Dari perspektif mesin virtual, panggilan masuk ke beberapa subsistem terpisah dan secara ajaib mengembalikan jawaban yang benar setelah beberapa saat.
Kami menjelajahi garis pemikiran ini secara singkat, tetapi dengan cepat menyerah karena kami terlalu fokus untuk memverifikasi bahwa semua jenis penskalaan blockchain dimungkinkan. Meskipun kita akan lihat nanti, kombinasi pengambilan sampel ketersediaan data dan ZK-EVM berarti bahwa kemungkinan masa depan untuk penskalaan Ethereum sebenarnya terlihat sangat dekat dengan visi ini! Di sisi lain, untuk abstraksi akun, kami tahu sejak awal bahwa beberapa jenis implementasi dimungkinkan, jadi penelitian segera mulai mencoba membawa sesuatu sedekat mungkin ke titik awal murni "perdagangan hanyalah panggilan" menjadi kenyataan.
Antara memproses transaksi dan membuat panggilan EVM yang mendasari sebenarnya dari alamat pengirim, ada banyak kode boilerplate, dan lebih banyak kode boilerplate setelah itu. Bagaimana kita mengurangi kode ini sedekat mungkin dengan nol?
Salah satu kode utama di sini adalah validate_transaction(state, tx), yang bertanggung jawab untuk memeriksa bahwa transaksi memiliki nonce dan tanda tangan yang benar. Sejak awal, tujuan praktis abstraksi akun adalah untuk memungkinkan pengguna mengganti verifikasi dasar non-inkremental dan 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 merancang ulang apply_transaction sebagai panggilan EVM sederhana bukan hanya tugas "kode bersih demi membuat kode bersih"; Sebaliknya, ini tentang memindahkan logika ke kode akun pengguna, memberi pengguna fleksibilitas yang mereka butuhkan.
Namun, bersikeras bahwa menerapkan \ _transaction mengandung logika tetap sesedikit mungkin akhirnya menciptakan banyak tantangan. Kita dapat melihat salah satu proposal abstraksi akun paling awal, EIP-86 .
Jika EIP-86 disertakan apa adanya, itu akan mengurangi kompleksitas EVM dengan biaya meningkatkan kompleksitas bagian lain dari tumpukan Ethereum secara besar-besaran, membutuhkan kode yang pada dasarnya identik untuk ditulis di tempat lain, kecuali untuk memperkenalkan kategori aneh yang sama sekali baru, seperti transaksi yang sama dengan nomor hash yang sama dapat muncul beberapa kali dalam rantai, belum lagi masalah beberapa pembatalan.
Beberapa masalah pembatalan dalam abstraksi akun. Satu transaksi yang disertakan secara on-chain dapat membatalkan ribuan transaksi lain di mempool, membuat mempool mudah membanjiri dengan harga murah.
Sejak itu, abstraksi akun telah berkembang secara bertahap. EIP-86 kemudian menjadi EIP-208 dan akhirnya EIP-2938 praktis.
Namun, EIP-2938 sama sekali tidak minimalis. Isinya meliputi:
· Jenis transaksi baru
· Variabel global untuk tiga cakupan perdagangan baru
· Dua opcode baru, termasuk opcode PAYgas yang sangat kikuk untuk menangani harga gas dan pemeriksaan batas gas, melakukan breakpoint sebagai EVM, dan menyimpan sementara ETH dengan biaya satu kali
· Serangkaian strategi penambangan dan penyiaran ulang yang kompleks, termasuk daftar opcode terlarang selama fase verifikasi transaksi
Untuk menerapkan abstraksi akun tanpa melibatkan pengembang inti Ethereum (yang fokus pada pengoptimalan klien Ethereum dan menerapkan penggabungan), EIP-2938 akhirnya dirancang ulang ke ERC-4337 sepenuhnya di luar protokol.
Karena ini adalah ERC, itu tidak memerlukan hard fork dan secara teknis ada "di luar protokol Ethereum". Jadi...... Apakah masalahnya terpecahkan? Ternyata bukan itu masalahnya. Peta jalan jangka menengah ERC-4337 saat ini sebenarnya melibatkan akhirnya mengubah sebagian besar ERC-4337 menjadi satu set fitur protokol, yang merupakan contoh panduan yang berguna mengapa jalur ini harus dipertimbangkan.
Paket ERC-4337
Ada beberapa alasan utama yang dibahas untuk akhirnya membawa ERC-4337 kembali ke protokol:
Efisiensi gas: Setiap operasi yang dilakukan di dalam EVM menghasilkan beberapa tingkat overhead mesin virtual, termasuk inefisiensi saat menggunakan fitur mahal gas seperti slot penyimpanan. Saat ini, inefisiensi tambahan ini menambahkan hingga setidaknya 20.000 gas, atau lebih. Menempatkan 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 menakutkan, semua dompet yang kompatibel dengan ERC-4337 mungkin melihat semua dana mereka mengering. Mengganti kontrak dengan fungsionalitas dalam protokol menciptakan kewajiban implisit untuk memperbaiki kesalahan kode melalui hard fork, sehingga menghilangkan risiko dana pengguna mengering.
Dukungan untuk opcode EVM seperti txt.origin. ERC-4337 sendiri menyebabkan txt.origin mengembalikan alamat "bundler" yang mengemas serangkaian tindakan pengguna ke dalam transaksi. Abstraksi akun asli memecahkan masalah ini dengan membuat txt.origin menunjuk ke akun aktual yang mengirim transaksi, membuatnya bekerja dengan cara yang sama seperti EOA.
Tahan sensor: Salah satu tantangan pemisahan pengusul/pembangun adalah menjadi lebih mudah untuk meninjau transaksi individual. Masalah ini dapat sangat diatasi di dunia di mana protokol Ethereum dapat mengenali satu transaksi, memungkinkan pengusul untuk 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 buram terhadap protokol Ethereum; Oleh karena itu, daftar inklusi yang disediakan oleh protokol Ethereum tidak akan dapat memberikan ketahanan sensor terhadap operasi pengguna ERC-4337. Merangkum ERC-4337 dan menjadikan tindakan pengguna sebagai jenis transaksi yang "sesuai" akan menyelesaikan masalah ini.
Perlu disebutkan bahwa dalam bentuknya saat ini, ERC-4337 jauh lebih mahal daripada transaksi Ethereum "dasar": biaya transaksi adalah 21.000 gas, sedangkan ERC-4337 berharga sekitar 42.000 gas.
Secara teoritis, harus dimungkinkan untuk menyesuaikan sistem biaya gas EVM sampai biaya dalam perjanjian dan biaya akses di luar protokol ke penyimpanan cocok; Ketika jenis operasi pengeditan penyimpanan lainnya lebih murah, tidak ada alasan untuk mentransfer ETH pada 9000 gas. Faktanya, dua EIP yang terkait dengan konversi pohon Verkle yang akan datang sebenarnya mencoba melakukan hal itu. Tetapi bahkan jika kita melakukannya, ada alasan yang jelas mengapa fungsionalitas protokol yang dienkapsulasi pasti akan jauh lebih murah daripada kode EVM, tidak peduli seberapa efisien EVM menjadi: kode yang dienkapsulasi tidak perlu membayar gas untuk preloading.
Dompet ERC-4337 yang berfungsi penuh berukuran besar, dan implementasi yang mengkompilasi dan menempatkannya di rantai membutuhkan sekitar 12.800 byte. Tentu saja, Anda dapat menyebarkan kode ini sekali dan menggunakan DELEGATECALL untuk memungkinkan setiap dompet individu memanggilnya, tetapi Anda masih perlu mengakses kode di setiap blok yang menggunakannya. Di bawah EIP biaya gas pohon Verkle, 12.800 byte akan membentuk 413 potongan, dan mengakses potongan ini akan membutuhkan membayar 2x cabang saksi _cost (total 3.800 gas) dan 413x potongan saksi \ _cost (total 82.600 gas). Dan itu bahkan belum mulai 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 sesuai dengan aturan EIP pohon Verkle).
Ini mengarah pada masalah: biaya gas untuk benar-benar mengakses kode-kode ini entah bagaimana harus diamortisasi di seluruh transaksi. Pendekatan saat ini yang digunakan oleh ERC-4337 tidak terlalu baik: transaksi pertama dalam bundel mengkonsumsi biaya penyimpanan / kode baca satu kali, membuatnya jauh lebih mahal daripada transaksi lainnya. Enkapsulasi dalam protokol akan memungkinkan perpustakaan bersama publik ini menjadi bagian dari protokol dan dapat diakses secara bebas oleh semua orang.
Apa yang bisa kita pelajari dari contoh ini, dan kapan pengemasan akan lebih umum? **
Dalam contoh ini, kita melihat beberapa alasan berbeda untuk merangkum aspek abstraksi akun dalam protokol.
Pendekatan berbasis pasar yang "mendorong kompleksitas ke tepi" kemungkinan besar akan gagal ketika biaya tetap tinggi. Bahkan, peta jalan abstraksi akun jangka panjang sepertinya setiap blok memiliki banyak biaya tetap. 244, 100 gas untuk memuat kode dompet standar adalah satu hal; Tetapi agregasi dapat menambahkan ratusan ribu gas ke validasi ZK-SNARK, serta biaya on-chain untuk validasi proof-of-chain. Tidak ada cara untuk membebankan biaya ini kepada pengguna tanpa memperkenalkan banyak inefisiensi pasar, dan menerjemahkan beberapa fitur ini ke dalam fitur protokol yang dapat diakses semua orang secara gratis menyelesaikan masalah ini dengan baik.
Respons seluruh komunitas terhadap bug kode. Jika beberapa cuplikan kode digunakan oleh semua pengguna atau rentang pengguna yang sangat luas, biasanya lebih masuk akal bagi komunitas blockchain untuk bertanggung jawab atas hard fork untuk memperbaiki bug yang muncul. ERC-4337 memperkenalkan sejumlah besar kode yang dibagikan secara global, dan memperbaiki bug dalam kode melalui hard fork tidak diragukan lagi lebih masuk akal dalam jangka panjang daripada menyebabkan pengguna kehilangan banyak ETH.
Terkadang, bentuk yang lebih kuat dapat dicapai dengan memanfaatkan fungsionalitas protokol secara langsung. Contoh utama di sini adalah fitur anti-sensor dalam protokol, seperti daftar inklusi: daftar inklusi dalam protokol dapat menjamin ketahanan sensor lebih baik daripada metode di luar protokol, dan agar operasi tingkat pengguna benar-benar mendapat manfaat dari daftar inklusi dalam protokol, satu operasi tingkat pengguna harus "dapat dibaca" ke protokol. Contoh lain yang kurang dikenal adalah desain proof-of-stake Ethereum era 2017 yang mengabstraksi akun kunci saham, yang ditinggalkan demi merangkum BLS, karena BLS mendukung mekanisme "agregasi" yang harus diimplementasikan pada tingkat protokol dan jaringan, yang dapat membuat penanganan sejumlah besar tanda tangan lebih efisien.
Tetapi penting untuk diingat bahwa bahkan merangkum abstraksi akun dalam protokol masih merupakan "de-enkapsulasi" yang sangat besar dibandingkan dengan situasi saat ini. Saat ini, transaksi Ethereum tingkat atas hanya dapat dimulai dari akun milik eksternal (EOA) yang diverifikasi dengan tanda tangan kurva eliptik secp 256k1 tunggal. Abstraksi akun menghilangkan ini dan menyerahkan kriteria validasi kepada pengguna untuk ditentukan. Jadi, dalam cerita tentang abstraksi akun ini, kami juga melihat argumen terbesar terhadap enkapsulasi: fleksibilitas untuk memenuhi kebutuhan pengguna yang berbeda.
Mari kita sempurnakan cerita ini lebih lanjut dengan melihat beberapa contoh fitur lain yang baru-baru ini dianggap dienkapsulasi. Kami akan memberikan perhatian khusus pada: ZK-EVM, pemisahan pengusul-pembangun, mempool pribadi, staking likuiditas, dan prakompilasi baru.
Paket ZK-EVM
Mari kita mengalihkan perhatian kita ke target enkapsulasi potensial lain dari 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-SNARK. Ada ekosistem implementasi independen yang cukup beragam: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth dan banyak lagi.
Kontroversi baru-baru ini di ruang EVM ZK-rollup berkaitan dengan cara menangani kemungkinan bug dalam kode ZK. Saat ini, semua sistem yang berjalan ini memiliki beberapa bentuk mekanisme "Dewan Keamanan" yang mengontrol sistem pengesahan jika terjadi bug. Tahun lalu, saya mencoba membuat kerangka kerja standar untuk mendorong proyek mengklarifikasi tingkat kepercayaan mereka pada sistem sertifikasi, serta di Dewan Keamanan, dan secara bertahap mengurangi otoritas mereka atas organisasi dari waktu ke waktu.
Dalam jangka menengah, rollup dapat bergantung pada beberapa sistem pengesahan, dan Dewan Keamanan akan memiliki kekuatan hanya dalam kasus-kasus ekstrim di mana dua sistem pengesahan yang berbeda berbeda.
Namun, ada perasaan bahwa beberapa pekerjaan terasa berlebihan. Kami sudah memiliki lapisan dasar Ethereum, ia memiliki EVM, dan kami sudah memiliki mekanisme kerja untuk menangani bug dalam implementasi: jika ada bug, klien akan memperbarui untuk memperbaikinya, dan kemudian rantai akan terus berfungsi. Dari perspektif klien buggy, tampaknya blok yang telah diselesaikan tidak akan lagi dikonfirmasi, tetapi setidaknya kita tidak akan melihat pengguna kehilangan uang. Demikian pula, jika rollup hanya ingin mempertahankan peran mereka setara dengan EVM, maka mereka perlu menerapkan tata kelola mereka sendiri untuk terus-menerus mengubah aturan ZK-EVM internal mereka agar sesuai dengan peningkatan ke lapisan dasar Ethereum, yang terasa salah karena pada akhirnya mereka dibangun di atas lapisan dasar Ethereum itu sendiri, yang tahu kapan harus meningkatkan dan sesuai dengan aturan baru apa.
Karena L2 ZK-EVM ini pada dasarnya menggunakan EVM yang persis sama dengan Ethereum, dapatkah kita entah bagaimana memasukkan "memverifikasi eksekusi EVM di ZK" ke dalam fungsi protokol dan menangani pengecualian seperti bug dan peningkatan dengan menerapkan konsensus sosial Ethereum, seperti yang sudah kita lakukan dengan implementasi EVM lapisan dasar itu sendiri?
Ini adalah topik yang penting dan menantang.
Salah satu topik perdebatan yang mungkin tentang ketersediaan data di ZK-EVM asli adalah kenegaraan. Jika ZK-EVM tidak perlu membawa data "saksi", efisiensi data mereka akan jauh lebih tinggi. Artinya, jika sepotong data tertentu telah dibaca atau ditulis di beberapa blok sebelumnya, kita dapat dengan mudah mengasumsikan bahwa prover memiliki akses ke sana dan tidak harus membuatnya tersedia lagi. Ini bukan hanya tentang tidak memuat ulang penyimpanan dan kode; Ternyata kompresi stateful dapat menghemat hingga 3x data dibandingkan dengan kompresi stateless jika satu rollup memampatkan data dengan benar.
Ini berarti bahwa untuk prakompilasi ZK-EVM, kami memiliki dua opsi:
Prakompilasi mengharuskan semua data tersedia dalam potongan yang sama. Ini berarti bahwa prover dapat stateless, tetapi itu juga berarti bahwa menggunakan ZK-rollup yang telah dikompilasi ini jauh lebih mahal daripada menggunakan rollup dengan kode khusus.
Prakompilasi memungkinkan pointer menunjuk ke data yang sebelumnya dieksekusi, digunakan, atau dihasilkan. Ini membuat ZK-rollup hampir optimal, tetapi lebih kompleks dan memperkenalkan keadaan baru yang harus disimpan oleh prover.
Apa yang bisa kita pelajari dari ini? Ada alasan bagus untuk entah bagaimana merangkum verifikasi ZK-EVM: rollup sudah membangun versi kustomnya sendiri, dan Ethereum bersedia mempertimbangkan beberapa implementasi dan konsensus sosial off-chain pada L1 untuk mengeksekusi EVM, yang terasa salah, tetapi L2 melakukan pekerjaan yang persis sama harus menerapkan gadget kompleks yang melibatkan Dewan Keamanan. Tetapi di sisi lain, ada masalah besar dalam detailnya: ada berbagai versi ZK-EVM, yang berbeda dalam biaya dan manfaat. Perbedaan antara stateful dan stateless hanya menggores permukaan; Mencoba mendukung "hampir-EVM", kode khusus yang telah dibuktikan oleh sistem lain, dapat mengekspos lebih banyak ruang desain. Oleh karena itu, merangkum ZK-EVM menghadirkan janji dan tantangan.
** Pembungkus dan Builder Pemisahan (ePBS) **
Munculnya MEV telah membuat produksi blok menjadi kegiatan ekonomi berskala besar, dengan peserta yang kompleks mampu menghasilkan blok yang menghasilkan lebih banyak pendapatan daripada algoritma default, yang hanya mengamati mempool transaksi dan memuatnya. 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 melakukan outsourcing konstruksi blok ke peserta khusus ("pembangun").
Namun, MEV-Boost membuat asumsi kepercayaan di kelas peserta baru yang disebut relay. Dalam dua tahun terakhir, ada banyak proposal untuk membuat "PBS yang dienkapsulasi". Apa manfaatnya? Dalam hal ini, jawabannya sederhana: PBS yang dibangun langsung dengan fitur protokol lebih kuat (dalam arti memiliki asumsi kepercayaan yang lebih lemah) daripada PBS yang dibangun tanpa mereka. Ini mirip dengan kasus dengan oracle harga dalam protokol enkapsulasi – meskipun dalam kasus ini, ada juga oposisi yang kuat.
** Enkapsulasi Kolam Memori Pribadi **
Ketika pengguna mengirim transaksi, itu segera publik dan terlihat oleh semua orang, bahkan sebelum itu termasuk dalam rantai. Ini membuat pengguna banyak aplikasi rentan terhadap serangan ekonomi, seperti transaksi preemptive.
Baru-baru ini, ada sejumlah proyek yang didedikasikan untuk menciptakan "mempool pribadi" (atau "mempool terenkripsi") yang mengenkripsi transaksi pengguna sampai mereka diterima secara ireversibel ke dalam blok.
Masalahnya, bagaimanapun, adalah bahwa skema tersebut memerlukan jenis enkripsi khusus: untuk mencegah pengguna membanjiri sistem dan mendekripsinya terlebih dahulu, enkripsi harus secara otomatis didekripsi setelah transaksi memang diterima secara ireversibel.
Untuk mencapai bentuk enkripsi ini, ada berbagai teknik trade-off. Jon Charbonneau pernah mengatakannya dengan baik:
Enkripsi operator terpusat, seperti Flashbots Protect.
enkripsi timelock, yang dapat didekripsi oleh siapa saja setelah langkah perhitungan berurutan tertentu dan tidak dapat diparalelkan;
Enkripsi ambang batas, mempercayai komite mayoritas yang jujur untuk mendekripsi data. Untuk rekomendasi spesifik, lihat Konsep Rantai Suar Tertutup.
Perangkat keras tepercaya, seperti SGX.
Sayangnya, setiap enkripsi memiliki kelemahan yang berbeda. Sementara untuk setiap solusi, ada subset pengguna yang mau mempercayainya, tidak ada solusi yang cukup dipercaya untuk benar-benar diterima oleh Layer 1. Jadi, setidaknya sampai enkripsi latensi disempurnakan atau terobosan teknologi lainnya, merangkum fungsionalitas perdagangan anti-lanjutan di Layer 1 tampak seperti proposisi yang sulit, bahkan jika itu adalah fitur yang cukup berharga sehingga banyak solusi aplikasi telah muncul.
Staking likuiditas yang dienkapsulasi
Kebutuhan umum bagi pengguna Ethereum DeFi adalah kemampuan untuk menggunakan ETH mereka secara bersamaan untuk staking dan sebagai jaminan di aplikasi lain. Kebutuhan umum lainnya hanyalah untuk kenyamanan: pengguna ingin dapat mempertaruhkan (dan melindungi kunci staking online) tanpa kerumitan menjalankan node dan menjaganya selalu online.
Sejauh ini, "antarmuka" staking paling sederhana yang memenuhi kedua kebutuhan ini hanyalah token ERC 20: ubah ETH Anda menjadi "stake ETH", tahan, dan ubah kembali. Faktanya, penyedia staking likuiditas seperti Lido dan Rocket Pool sudah mulai melakukannya. Namun, staking likuiditas memiliki beberapa mekanisme sentralisasi alami di tempat kerja: orang secara alami masuk ke versi terbesar dari staking ETH karena ini adalah yang paling akrab dan likuid.
Setiap versi staking ETH memerlukan beberapa mekanisme untuk menentukan siapa yang dapat menjadi operator node yang mendasarinya. Itu tidak bisa tidak terbatas, karena penyerang akan bergabung dan memperkuat serangan dengan dana pengguna. Saat ini, dua teratas adalah Lido, yang memiliki operator node daftar putih DAO, dan Rocket Pool, yang memungkinkan siapa saja untuk menjalankan node dengan 8 ETH yang disimpan. Kedua metode memiliki risiko yang berbeda: pendekatan Rocket Pool memungkinkan penyerang untuk melakukan serangan 51% pada jaringan dan memaksa pengguna untuk membayar sebagian besar biaya; Adapun pendekatan DAO, jika token staking tertentu mendominasi, itu menghasilkan gadget tata kelola tunggal yang berpotensi diserang yang mengendalikan sebagian besar dari semua validator Ethereum. Yang pasti, protokol seperti Lido sudah memiliki tindakan pencegahan, tetapi lapisan pertahanan mungkin tidak cukup.
Dalam jangka pendek, salah satu pilihannya adalah mendorong peserta ekosistem untuk menggunakan beragam penyedia staking likuiditas untuk mengurangi kemungkinan risiko sistemik dari satu perusahaan. Namun, dalam jangka panjang, ini adalah keseimbangan yang genting, dan berbahaya untuk terlalu mengandalkan tekanan moral untuk menyelesaikan masalah. Sebuah pertanyaan alami muncul: apakah masuk akal untuk merangkum beberapa jenis fungsi dalam protokol untuk membuat staking likuiditas kurang terpusat?
Pertanyaan kuncinya di sini adalah: fungsi dalam protokol seperti apa? Masalah dengan hanya membuat token "staking ETH" yang dapat dipertukarkan dalam protokol adalah bahwa ia harus memiliki tata kelola Ethereum yang dienkapsulasi untuk memilih siapa yang menjalankan node, atau terbuka, tetapi ini mengubahnya menjadi alat untuk penyerang.
Ide yang menarik adalah artikel Dankrad Feist tentang maksimalisasi staking likuiditas. Pertama, mari kita gigit jari dan jika Ethereum diserang oleh 51%, hanya 5% dari serangan ETH yang dapat disita. Ini adalah trade-off yang masuk akal; Dengan lebih dari 26 juta ETH saat ini sedang dipertaruhkan, sepertiga dari itu (sekitar 8 juta ETH) dari biaya serangan berlebihan, terutama mengingat berapa banyak serangan "di luar model" yang dapat dilakukan dengan biaya lebih rendah. Bahkan, trade-off serupa telah dieksplorasi dalam proposal Komisi Super untuk menerapkan finalitas slot tunggal.
Jika kami menerima bahwa hanya 5% dari ETH serangan yang disita, maka lebih dari 90% ETH yang dipertaruhkan tidak akan terpengaruh oleh penyitaan, sehingga mereka dapat digunakan sebagai token staking likuiditas yang sepadan dalam protokol dan kemudian digunakan oleh aplikasi lain.
Jalannya menarik. Tapi itu masih menyisakan pertanyaan: apa sebenarnya yang dienkapsulasi? Rocket Pool bekerja sangat mirip: setiap operator node menyediakan sejumlah dana, dan staker likuiditas menyediakan sisanya. Kami cukup menyesuaikan beberapa konstanta untuk membatasi penalti maksimum hingga 2 ETH dan rETH yang ada dari Rocket Pool akan menjadi bebas risiko.
Dengan penyesuaian protokol sederhana, kita juga bisa melakukan hal-hal pintar lainnya. Sebagai contoh, katakanlah kita menginginkan sistem dengan dua "lapisan" staking: operator node (persyaratan jaminan tinggi) dan deposan (tidak ada persyaratan jaminan minimum dan dapat bergabung dan pergi kapan saja), tetapi kita masih ingin mencegah sentralisasi operator node dengan memberdayakan komite deposan sampel acak, seperti menyarankan daftar transaksi yang harus disertakan (untuk alasan tahan sensor), mengontrol pemilihan garpu selama kebocoran tidak aktif, atau memerlukan penandatanganan blok. Ini dapat dicapai dengan cara yang pada dasarnya terlepas dari protokol dengan mengutak-atik protokol untuk mengharuskan setiap validator menyediakan (i) kunci staking biasa, dan (ii) alamat ETH yang dapat dipanggil di setiap slot untuk menghasilkan kunci staking sekunder. Protokol akan memberikan kekuatan pada kedua kunci, tetapi mekanisme untuk memilih kunci kedua di setiap slot dapat diserahkan kepada protokol staking pool. Mungkin masih lebih baik untuk merangkum beberapa fitur secara langsung, tetapi perlu dicatat bahwa ruang desain "sertakan beberapa hal dan serahkan yang lainnya kepada pengguna" ini ada.
** Enkapsulasi lebih banyak prakompilasi **
Precompiled (atau "kontrak precomilasi") adalah kontrak Ethereum yang mengimplementasikan operasi kriptografi kompleks, logika yang diimplementasikan secara native dalam kode klien, daripada kode kontrak pintar EVM. Precoding adalah kompromi yang diadopsi pada awal pengembangan Ethereum: karena overhead mesin virtual terlalu besar untuk beberapa kode yang sangat kompleks dan sangat terspesialisasi, kami dapat menerapkan beberapa operasi utama dalam kode lokal yang berharga bagi aplikasi penting untuk membuatnya lebih cepat. Saat ini, ini pada dasarnya mencakup beberapa fungsi hash spesifik dan operasi kurva elips.
Saat ini ada dorongan untuk menambahkan prakompilasi untuk secp 256 R1, kurva elips yang sedikit berbeda dari secp 256 K1 untuk akun Ethereum dasar, karena didukung dengan baik oleh modul perangkat keras tepercaya, sehingga penggunaannya secara luas dapat meningkatkan keamanan dompet. Dalam beberapa tahun terakhir, komunitas juga telah mendorong penambahan prakompilasi untuk BLS-12-377, BW 6-761, pasangan umum, dan fitur lainnya.
Argumen tandingan untuk permintaan ini untuk lebih banyak file yang telah dikompilasi sebelumnya adalah bahwa banyak prakompilasi yang ditambahkan sebelumnya (misalnya RIPEMD dan BLAKE) akhirnya menggunakan jauh lebih sedikit dari yang diharapkan, dan kita harus belajar dari mereka. Alih-alih menambahkan lebih banyak prakompilasi untuk operasi tertentu, mungkin kita harus fokus pada pendekatan yang lebih lembut berdasarkan ide-ide seperti EVM-MAX dan proposal SIMD yang tidak aktif tetapi selalu dapat dipulihkan, yang akan memungkinkan implementasi EVM untuk mengeksekusi berbagai kelas kode dengan biaya lebih rendah. Mungkin bahkan prakompilasi yang jarang digunakan dapat dihapus dan diganti dengan implementasi kode EVM (yang pasti kurang efisien) dengan fungsi yang sama. Yang mengatakan, masih mungkin bahwa ada operasi kriptografi tertentu yang cukup berharga untuk mempercepat, jadi masuk akal untuk menambahkannya sebagai prakompilasi.
Apa yang telah kita pelajari dari semua ini?
Keinginan untuk merangkum sesedikit mungkin dapat dimengerti dan baik; Ini berasal dari tradisi filosofis Unix menciptakan perangkat lunak minimalis yang dapat dengan mudah disesuaikan dengan kebutuhan pengguna yang berbeda dan menghindari kutukan perangkat lunak yang membengkak. Namun, blockchain bukanlah sistem operasi komputasi pribadi, tetapi sistem sosial. Ini berarti masuk akal untuk merangkum fungsionalitas tertentu dalam protokol.
Dalam banyak kasus, contoh-contoh lain ini mirip dengan apa yang kita lihat dalam abstraksi akun. Tetapi kami juga belajar beberapa pelajaran baru:
Enkapsulasi dapat membantu menghindari risiko sentralisasi di tempat lain dalam tumpukan:
Seringkali, menjaga protokol dasar minimal dan sederhana mendorong kompleksitas di luar beberapa protokol ekosistem. Dari sudut pandang filosofis Unix, ini bagus. Namun, terkadang ada risiko bahwa ekosistem di luar protokol akan terpusat, biasanya (tetapi tidak hanya) karena biaya tetap yang tinggi. Enkapsulasi terkadang dapat mengurangi sentralisasi de facto.
Merangkum terlalu banyak konten dapat memperluas beban kepercayaan dan tata kelola pada protokol:
Ini adalah topik artikel sebelumnya tentang "Jangan membebani konsensus Ethereum": jika merangkum fungsi tertentu melemahkan model kepercayaan dan membuat Ethereum secara keseluruhan lebih "subyektif", itu melemahkan netralitas tepercaya Ethereum. Dalam kasus ini, lebih baik menyajikan fitur tertentu sebagai mekanisme di atas Ethereum daripada mencoba memperkenalkannya ke Ethereum itu sendiri. Di sini, kumpulan memori terenkripsi adalah contoh terbaik, dan mungkin agak sulit untuk dienkapsulasi, setidaknya sampai enkripsi latensi meningkat.
Merangkum terlalu banyak dapat memperumit protokol:
Kompleksitas protokol adalah risiko sistemik yang dapat ditingkatkan dengan menambahkan terlalu banyak fitur ke protokol. Prakompilasi adalah contoh terbaik.
Dalam jangka panjang, fungsi enkapsulasi dapat menjadi bumerang karena kebutuhan pengguna tidak dapat diprediksi:
Fitur yang dianggap penting oleh banyak orang dan akan digunakan oleh banyak pengguna kemungkinan tidak digunakan secara teratur dalam praktiknya.
Selain itu, staking likuiditas, ZK-EVM, dan kasus-kasus yang telah dikompilasi sebelumnya menunjukkan kemungkinan jalan tengah: pengabadian minimal yang layak. Protokol tidak perlu merangkum seluruh fungsi, tetapi dapat berisi bagian-bagian tertentu yang mengatasi tantangan utama, membuat fungsi mudah diimplementasikan tanpa terlalu paranoid atau terlalu sempit. Contohnya termasuk:
Daripada merangkum sistem penjaminan likuiditas lengkap, lebih baik mengubah aturan penalti staking untuk membuat janji likuiditas tanpa kepercayaan lebih layak;
Alih-alih merangkum lebih banyak precompiler, enkapsulasi EVM-MAX dan / atau SIMD untuk membuatnya lebih mudah untuk mengimplementasikan secara efisien untuk berbagai kategori operasi yang lebih luas;
Verifikasi EVM dapat dengan mudah dienkapsulasi alih-alih merangkum seluruh konsep rollup.
Kita dapat memperluas grafik sebelumnya sebagai berikut:
Terkadang masuk akal untuk membungkus sesuatu, dan menghapus prakompilasi yang jarang digunakan adalah contohnya. Abstraksi akun secara keseluruhan, seperti yang disebutkan sebelumnya, juga merupakan bentuk penting dari de-enkapsulasi. Jika kita ingin mendukung kompatibilitas mundur untuk pengguna yang ada, mekanismenya mungkin sebenarnya sangat mirip dengan yang mende-enkapsulasi yang telah dikompilasi sebelumnya: salah satu proposal adalah EIP-5003, yang akan memungkinkan EOA untuk mengubah akunnya menjadi kontrak dengan fungsi yang sama (atau lebih baik).
Fitur mana yang harus dimasukkan ke dalam protokol dan mana yang harus diserahkan ke lapisan ekosistem lainnya adalah trade-off yang kompleks. Trade-off ini diperkirakan akan terus meningkat dari waktu ke waktu karena pemahaman kami tentang kebutuhan pengguna dan ide-ide yang tersedia dan rangkaian teknologi terus meningkat.