Penulis: Vitalik Buterin

Kompilasi: Daily Planet Daily Planet Bagaimana suami

Sejak 14 Oktober, pendiri Ethereum Vitalik Buterin telah secara bertahap merilis diskusi tentang kemungkinan masa depan Ethereum, mulai dari "The Merge", "The Surge", "The Scourge", "The Verge" hingga yang terbaru, "The Purge", yang menunjukkan khayalan Vitalik tentang perkembangan masa depan Mainnet Ethereum dan solusi untuk mengatasi masalah saat ini.

《The Merge》: Membahas perluasan Ethereum ke PoS untuk meningkatkan kepastian akhir slot tunggal dan ambang batas stake, untuk meningkatkan partisipasi dan kecepatan konfirmasi transaksi.

《The Surge》: membahas berbagai strategi perluasan ETH, terutama roadmap yang berpusat pada Rollup, serta tantangan dan solusi dalam hal skalabilitas, Desentralisasi, dan keamanan.

"The Scourge": Membahas risiko sentralisasi dan ekstraksi nilai yang dihadapi oleh Ethereum dalam transformasi ke PoS, dan mengembangkan berbagai mekanisme untuk meningkatkan desentralisasi dan keadilan, serta melakukan reformasi ekonomi staking untuk melindungi kepentingan pengguna.

《The Verge》: Membahas tantangan dan solusi verifikasi tanpa keadaan dari ETH, dengan fokus pada bagaimana teknologi seperti pohon Verkle dan STARK meningkatkan Desentralisasi dan efisiensi blockchain.

Pada 26 Oktober, Vitalik Buterin menerbitkan artikel tentang "The Purge", di mana ia membahas tantangan yang dihadapi oleh Ethereum dalam menjaga kompleksitas dan kebutuhan penyimpanan yang rendah dalam jangka panjang, sambil tetap mempertahankan desentralisasi dan ketahanan jaringan. Langkah-langkah kunci termasuk mengurangi beban penyimpanan klien melalui "kedaluwarsa sejarah" dan "kedaluwarsa status", serta menyederhanakan protokol melalui "pembersihan fitur" untuk memastikan keberlanjutan dan skalabilitas jaringan.

Berikut adalah isi asli, yang diterjemahkan oleh Odaily Planet Daily.

Terima kasih khusus kepada Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden, dan Tomasz Stanczak atas umpan balik dan tinjauan mereka.

Salah satu tantangan yang dihadapi oleh Ethereum adalah bahwa secara default, kompleksitas dan ekspansi protokol Blokchain akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua tempat:

Data historis: Setiap transaksi yang terjadi dan akun yang dibuat pada setiap saat dalam sejarah harus disimpan secara permanen oleh semua klien dan diunduh oleh setiap klien baru untuk sinkronisasi penuh dengan jaringan. Hal ini menyebabkan beban dan waktu sinkronisasi klien terus meningkat seiring berjalannya waktu, meskipun kapasitas rantai tetap sama.

Fitur protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, yang mengakibatkan peningkatan kompleksitas kode seiring berjalannya waktu.

Untuk menjaga Ethereum agar tetap berkelanjutan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini seiring berjalannya waktu Drop kompleksitas dan inflasi. Namun pada saat yang sama, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda dapat menempatkan satu token Non-fungible, percakapan cinta dalam data transaksi, atau Smart Contract senilai 100 juta dolar ke on-chain, masuk ke dalam gua selama sepuluh tahun, dan menemukannya masih menunggu untuk dibaca dan diinteraksikan. Agar DApp dapat sepenuhnya Desentralisasi dengan aman dan menghapus Kunci Rahasia upgrade, mereka perlu yakin bahwa dependensi mereka tidak akan diupgrade dengan cara yang merusak - terutama L1 itu sendiri.

Jika kita berkomitmen untuk mencapai keseimbangan antara dua kebutuhan ini dan sekaligus mengurangi atau membalikkan kelebihan, kompleksitas, dan penurunan dengan tetap menjaga kontinuitas, itu adalah hal yang mungkin. Organisme dapat melakukannya: meskipun sebagian besar organisme mengalami penuaan seiring berjalannya waktu, beberapa di antaranya tidak. Sistem sosial pun dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah mencapai keberhasilan: bukti kerja telah hilang, sebagian besar opcode SELFDESTRUCT telah hilang, dan beacon chainNode telah menyimpan data lama selama enam bulan. Menemukan jalan ini secara lebih umum untuk Ethereum dan menuju hasil akhir yang stabil jangka panjang adalah tantangan utama bagi skalabilitas, keberlanjutan teknologi, dan bahkan keamanan Ethereum dalam jangka panjang.

The Purge: tujuan utama.

Dengan mengurangi atau menghilangkan kebutuhan setiap Node untuk menyimpan secara permanen semua catatan sejarah atau bahkan status akhir, Drop kebutuhan penyimpanan klien.

Mengurangi kompleksitas dengan menghapus fitur yang tidak diperlukan.

Daftar Isi Artikel:

Kadaluarsa riwayat

Kadaluwarsa status

Pembersihan Fitur

Kadaluarsa riwayat

Apa masalah yang dipecahkan?

Saat ini, Node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, serta ratusan GB ruang disk tambahan untuk klien Konsensus. Sebagian besar dari ruang tersebut adalah data historis: data tentang Blok, transaksi, dan tanda terima, sebagian besar sudah berusia beberapa tahun. Ini berarti bahwa bahkan jika batasan Gas tidak meningkat sama sekali, ukuran Node akan terus bertambah ratusan GB setiap tahunnya.

Apa itu, bagaimana cara kerjanya?

Salah satu fitur kunci penyederhanaan masalah penyimpanan historis adalah, karena setiap blok menunjuk ke blok sebelumnya melalui tautan hash (dan struktur lainnya), maka mencapai Konsensus saat ini sudah cukup untuk mencapai Konsensus historis. Selama jaringan mencapai Konsensus Blok terbaru, setiap Blok historis atau transaksi atau status (saldo akun, nomor acak, kode, penyimpanan) dapat disediakan oleh setiap peserta tunggal serta bukti Merkle, dan bukti tersebut memungkinkan siapa pun memverifikasinya. Konsensus adalah model kepercayaan N/2-of-N, sementara historis adalah model kepercayaan N-of-N.

Ini memberikan banyak pilihan bagi kami dalam menyimpan catatan sejarah. Salah satu pilihan alami adalah setiap Node hanya menyimpan sebagian kecil data dari jaringan. Ini adalah cara kerja jaringan benih selama puluhan tahun: meskipun jaringan secara keseluruhan menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin tidak sesuai dengan intuisi, metode ini bahkan mungkin tidak akan menurunkan kestabilan data. Jika dengan membuat Node berjalan lebih efisien secara ekonomi, kita dapat membangun jaringan dengan 100.000 Node, di mana setiap Node menyimpan 10% catatan sejarah secara acak, maka setiap data akan direplikasi 10.000 kali - sama persis dengan faktor replikasi 10.000 Node - Node jaringan, di mana setiap Node menyimpan semua konten.

Saat ini, Ethereum telah mulai keluar dari model Node yang menyimpan semua sejarah secara permanen. Konsensus Blok (bagian yang terkait dengan Proof of Stake Konsensus) hanya menyimpan sekitar 6 bulan. Blok hanya disimpan selama sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk Blok dan tanda terima sejarah. Tujuan jangka panjangnya adalah membangun periode yang seragam (mungkin sekitar 18 hari) di mana setiap Node bertanggung jawab untuk menyimpan semua konten, kemudian membangun jaringan peer-to-peer yang terdiri dari Node Ethereum untuk menyimpan data lama dalam cara yang terdistribusi.

Erasure codes dapat digunakan untuk meningkatkan kehandalan, sambil mempertahankan faktor replikasi yang sama. Faktanya, Blob telah menggunakan kode penghapusan untuk mendukung pengambilan sampel ketersediaan data. Solusi paling sederhana mungkin adalah menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok pelaksanaan dan Konsensus ke dalam blob.

Apa hubungannya dengan penelitian yang ada?

EIP-4444;

Torrent dan EIP-4444;

Portal jaringan;

Portal network dan EIP-4444;

Penyimpanan dan pengambilan terdistribusi objek SSZ di Portal;

Bagaimana meningkatkan batas gas (Paradigm)

Apa lagi yang perlu dilakukan, dan apa yang perlu dipertimbangkan?

Tugas utama yang tersisa termasuk membangun dan mengintegrasikan solusi terdistribusi konkret untuk menyimpan catatan sejarah - setidaknya untuk mengeksekusi catatan sejarah, tetapi akhirnya juga termasuk Konsensus dan blob. Solusi paling sederhana adalah (i) dengan memperkenalkan pustaka torrent yang ada, dan (ii) solusi asli ETH blok yang disebut Jaringan Portal. Begitu salah satunya diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 sendiri tidak memerlukan hardfork, tetapi memang memerlukan versi protokol jaringan baru. Oleh karena itu, bernilai untuk mengaktifkannya untuk semua klien secara bersamaan, jika tidak, ada risiko kegagalan klien yang terhubung ke Node lain dengan harapan mengunduh catatan sejarah lengkap namun sebenarnya tidak mendapatkannya.

Pertimbangan utama melibatkan bagaimana kita berupaya untuk menyediakan data sejarah "kuno". Solusi paling sederhana adalah menghentikan penyimpanan data sejarah kuno mulai besok, dan bergantung pada Node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah dilakukan, tetapi melemahkan posisi Ethereum sebagai tempat catatan permanen. Pendekatan yang lebih sulit namun lebih aman adalah dengan membangun dan mengintegrasikan jaringan torrent terlebih dahulu, untuk menyimpan catatan sejarah secara terdistribusi. Di sini, "seberapa keras kita berupaya" memiliki dua dimensi:

Bagaimana kita bekerja keras untuk memastikan bahwa kumpulan Node terbesar benar-benar menyimpan semua data?

Kami akan mengintegrasikan penyimpanan sejarah ke Kedalaman protokol seberapa dalam?

Metode paranoia ekstrim untuk (1) akan melibatkan bukti penitipan: meminta setiap validator Proof of Stake untuk menyimpan persentase tertentu dari riwayatnya, dan secara teratur memeriksa apakah mereka melakukannya dengan cara yang dienkripsi. Metode yang lebih moderat adalah dengan menetapkan standar sukarela untuk persentase riwayat yang disimpan oleh setiap klien.

Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah selesai hari ini: Portal telah menyimpan file ERA yang berisi sejarah lengkap Ethereum. Implementasi yang lebih menyeluruh akan melibatkan menghubungkannya ke proses sinkronisasi, sehingga jika seseorang ingin menyinkronkan Node penyimpanan atau Node arsip dengan sejarah lengkap, bahkan tanpa adanya Node arsip lain yang online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Jika kita ingin membuat menjalankan atau memulai Node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah dapat dikatakan lebih penting daripada keadaan tanpa status: dari 1.1 TB yang dibutuhkan oleh Node, sekitar 300 GB adalah status, sementara sekitar 800 GB telah menjadi sejarah. Hanya dengan menerapkan tanpa status dan EIP-4444, kita bisa mewujudkan visi menjalankan Node Ethereum pada smartwatch dan hanya memerlukan beberapa menit untuk pengaturannya.

Pembatasan penyimpanan sejarah juga membuat Node Ethereum yang lebih baru menjadi lebih layak, hanya mendukung versi terbaru protokol, yang membuatnya menjadi lebih sederhana. Misalnya, sekarang banyak baris kode dapat dihapus dengan aman karena semua slot penyimpanan kosong yang dibuat selama serangan DoS tahun 2016 telah dihapus. Mengingat beralih ke Proof of Stake telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan Proof of Work.

Kedaluwarsa negara

Apa masalah yang dipecahkan?

Meskipun kita menghilangkan kebutuhan untuk menyimpan riwayat historis di sisi klien, kebutuhan penyimpanan klien akan terus naik, sekitar 50 GB per tahun, karena status terus naik: saldo akun dan nomor acak, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali bayar, sehingga memberikan beban kepada klien ETH sekarang dan di masa depan.

Status lebih sulit 'kadaluarsa' daripada sejarah, karena EVM pada dasarnya dirancang dengan asumsi ini: begitu objek status dibuat, itu akan tetap ada dan dapat dibaca kapan saja oleh transaksi apa pun. Jika kita memperkenalkan ketiadaan status, ada yang berpendapat bahwa ini mungkin tidak begitu buruk: hanya kelas pembangun Blok khusus yang perlu menyimpan status secara aktual, sementara semua Node lainnya (bahkan yang termasuk dalam pembangkitan daftar!) dapat berjalan tanpa status. Namun, ada pandangan yang berpendapat bahwa kita tidak ingin terlalu bergantung pada ketiadaan status, dan pada akhirnya kita mungkin ingin membuat status kadaluarsa untuk menjaga Desentralisasi Ethereum.

Apa itu, bagaimana cara kerjanya

Hari ini, ketika Anda membuat objek status baru (bisa terjadi melalui salah satu dari tiga cara berikut: (i) mengirim ETH ke akun baru, (ii) membuat akun baru menggunakan kode, (iii) mengatur slot penyimpanan yang sebelumnya belum tersentuh), objek status ini akan tetap berada dalam status tersebut selamanya. Sebaliknya, yang kita inginkan adalah objek tersebut otomatis kadaluarsa seiring berjalannya waktu. Tantangan utamanya adalah mencapai tiga tujuan ini dengan cara yang diinginkan:

Efisiensi: Tidak memerlukan perhitungan tambahan yang besar untuk menjalankan proses kadaluwarsa.

Kesesuaian Pengguna: Jika seseorang telah masuk ke dalam gua selama lima tahun dan kembali, mereka tidak boleh kehilangan akses ke posisi ETH, ERC20, Token Non-fungible, CDP...

Kemanusiaan Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sama sekali tidak dikenal. Selain itu, aplikasi yang saat ini sudah kaku dan tidak diperbarui seharusnya tetap dapat berjalan dengan normal.

Jika Anda tidak memenuhi tujuan ini, mudah untuk menyelesaikan masalah. Misalnya, Anda dapat meminta setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (tanggal kedaluwarsa dapat diperpanjang dengan membakar ETH, yang dapat terjadi secara otomatis kapan saja membaca atau menulis), dan memiliki proses yang berulang melalui status untuk menghapus tanggal kedaluwarsa objek status. Namun, ini memperkenalkan komputasi tambahan (dan bahkan persyaratan penyimpanan), dan tentu saja tidak memenuhi persyaratan untuk keramahan pengguna. Juga sulit bagi pengembang untuk bernalar tentang kasus tepi yang melibatkan nilai penyimpanan yang terkadang diatur ulang ke nol. Jika Anda mengatur timer kedaluwarsa dalam ruang lingkup kontrak, ini secara teknis akan membuat hidup pengembang lebih mudah, tetapi itu akan membuat ekonomi lebih sulit: pengembang harus memikirkan cara "meneruskan" biaya penyimpanan yang sedang berlangsung kepada pengguna.

Ini adalah masalah yang telah lama diupayakan oleh komunitas pengembangan inti Ethereum, termasuk proposal seperti 'Blok Sewa' dan 'Regenerasi'. Akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan fokus pada dua jenis 'solusi terbaik yang diketahui':

• Sebagian solusi kadaluarsa status
• Saran kadaluarsa status berdasarkan siklus Alamat.

Kadaluarsa status parsial

Beberapa proposal kedaluwarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang menyimpan 'pemetaan top-level' secara permanen, di mana blok dapat kosong atau tidak kosong. Data dalam setiap blok hanya disimpan ketika data tersebut diakses baru-baru ini. Ada mekanisme 'kebangkitan' jika data itu tidak lagi disimpan

Perbedaan utama antara proposal-proposal ini adalah: (i) bagaimana kita mendefinisikan "baru-baru ini", dan (ii) bagaimana kita mendefinisikan "blok"? Salah satu proposal khususnya adalah EIP-7736, yang dibangun di atas desain "batang daun" yang diperkenalkan untuk pohon Verkle (meskipun kompatibel dengan bentuk status tanpa keadaan apa pun, misalnya pohon biner). Dalam desain ini, header, kode, dan slot penyimpanan yang saling berdekatan disimpan di bawah satu "batang" yang sama. Data yang disimpan di bawah batang dapat berjumlah maksimal 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun serta banyak slot penyimpanan kunci akan disimpan di bawah satu batang yang sama. Jika data di bawah batang tertentu tidak dibaca atau ditulis dalam waktu 6 bulan, data tersebut tidak akan disimpan lagi, namun hanya menyimpan 32 byte janji ('akar'). Transaksi yang mengakses data di masa depan akan memerlukan "penghidupan kembali" data, dan memberikan bukti pemeriksaan berdasarkan akar.

Masih ada metode lain untuk mewujudkan gagasan serupa. Misalnya, jika tingkat akun tidak cukup halus, kita bisa menyusun skema di mana setiap bagian 1/232 dari pohon dikontrol oleh mekanisme batang dan daun yang serupa.

Karena faktor insentif, ini menjadi lebih rumit: penyerang dapat memaksa klien untuk menyimpan status dalam jumlah besar secara permanen dengan memasukkan sejumlah besar data ke dalam satu subtree dan mengirimkan satu transaksi setiap tahun untuk 'memperbarui pohon'. Jika Anda membuat biaya perpanjangan sebanding dengan ukuran pohon (atau durasi perpanjangan sebaliknya), seseorang mungkin melukai pengguna lain dengan memasukkan sejumlah besar data ke dalam subtree yang sama dengan mereka. Orang-orang dapat mencoba membatasi kedua masalah ini dengan membuat granularitas dinamis berdasarkan ukuran subtree: misalnya, setiap 216 = 65536 objek status berturut-turut dapat dianggap sebagai 'kelompok'. Namun, gagasan-gagasan ini lebih kompleks; metode berbasis tangkai sangat sederhana dan insentif dapat disesuaikan, karena biasanya semua data di bawah tangkai terkait dengan aplikasi atau pengguna yang sama.

Saran Kedaluwarsa Status Berdasarkan Alamat

Jika kita ingin sepenuhnya menghindari keadaan permanen naik, bahkan 32-byte stub, apa yang harus dilakukan? Ini adalah masalah yang sulit karena konflik kebangkitan: jika sebuah objek status dihapus, eksekusi EVM kemudian akan menempatkan objek status lain pada posisi yang sama persis, tetapi bagaimana jika orang yang peduli dengan objek status asli kembali dan mencoba mengembalikannya? Ketika sebagian status kedaluwarsa, 'stub' akan mencegah pembuatan data baru. Saat status sepenuhnya kedaluwarsa, kita bahkan tidak dapat menyimpan stub.

Desain berbasis siklus Alamat adalah ide yang paling terkenal untuk mengatasi masalah ini. Kami tidak menyimpan seluruh status dalam satu pohon status, tetapi memiliki daftar pohon status yang naik terus-menerus, dan status apa pun yang dibaca atau ditulis akan disimpan dalam pohon status terbaru. Setiap siklus (misalnya: 1 tahun) menambahkan pohon status kosong baru. Pohon tua dibekukan dengan ketat. Node lengkap hanya menyimpan dua pohon terbaru. Jika objek status tidak disentuh dalam dua siklus, sehingga jatuh ke dalam pohon kedaluwarsa, itu masih dapat dibaca atau ditulis, tetapi transaksi harus membuktikan bukti Merkle - begitu terbukti, salinan akan disimpan kembali dalam pohon terbaru.

Salah satu konsep kunci yang ramah bagi pengguna dan pengembang adalah konsep siklus Alamat. Siklus Alamat adalah angka yang termasuk bagian dari Alamat. Aturan pentingnya adalah bahwa Alamat dengan siklus Alamat N hanya dapat dibaca atau ditulis selama atau setelah periode N (yaitu, ketika daftar pohon status mencapai panjang N). Jika Anda ingin menyimpan objek status baru (misalnya, kontrak baru atau saldo ERC20 baru), Anda dapat menyimpannya secara langsung tanpa bukti asalkan Anda memastikan bahwa objek status tersebut ada di kontrak dengan siklus Alamat N atau N-1. Di sisi lain, setiap penambahan atau pengeditan yang dilakukan selama siklus Alamat lama memerlukan bukti.

Desain ini mempertahankan sebagian besar atribut saat ini dari Ethereum tanpa perlu perhitungan tambahan, memungkinkan pengembangan aplikasi yang hampir sama seperti sekarang (ERC20 perlu ditulis ulang untuk memastikan saldo Alamat dengan siklus N disimpan dalam subkontrak yang memiliki siklus N Alamat itu sendiri), dan mengatasi masalah 'pengguna masuk ke gua selama lima tahun'. Namun, ada masalah besar: Alamat perlu diperluas menjadi lebih dari 20 byte agar dapat mengakomodasi siklus Alamat.

Alamat空间扩展

Salah satu saran adalah memperkenalkan format Alamat baru 32 byte, yang mencakup nomor versi, nomor siklus Alamat, dan hash ekstensi.

0x01 (merah) 0000 (oranye) 000001 (hijau) 57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (biru).

Versi warna merah. Empat nol berwarna oranye di sini adalah ruang kosong yang akan digunakan untuk nomor Sharding di masa depan. Warna hijau adalah nomor siklus Alamat. Warna biru adalah nilai hash 26 byte.

Tantangan utama di sini adalah kompatibilitas mundur. Kontrak yang ada didasarkan pada Alamat 20 byte, dan biasanya menggunakan teknik pengemasan byte yang ketat, dengan asumsi eksplisit bahwa Alamat tepat 20 byte. Salah satu ide untuk mengatasi masalah ini melibatkan konversi pemetaan, di mana kontrak lama yang berinteraksi dengan Alamat baru akan melihat nilai hash 20 byte dari Alamat baru. Namun, memastikan keamanannya memiliki kompleksitas yang besar.

Alamat空间收缩

Metode lain adalah dengan mengambil arah yang berlawanan: kami segera melarang beberapa Alamat dalam rentang sub 2128 (misalnya, semua Alamat yang dimulai dengan 0xffffffff), kemudian menggunakan rentang tersebut untuk memperkenalkan Alamat dengan siklus Alamat dan nilai hash 14 byte.

0xffffffff000169125d5dFcb7B8C2659029395bdF

Pengorbanan utama yang dilakukan oleh pendekatan ini adalah pengenalan risiko keamanan kontrafaktual Alamat: Alamat yang memegang aset atau izin, tetapi kodenya belum dipublikasikan secara on-chain. Risiko melibatkan seseorang yang membuat Alamat yang mengklaim memiliki sepotong kode (belum dipublikasikan), tetapi juga memiliki potongan kode lain yang valid yang di-hash ke dalam Alamat yang sama. Dibutuhkan 280 hash untuk menghitung tabrakan seperti itu hari ini; Penyusutan ruang alamat akan mengurangi angka ini menjadi nilai hash yang mudah diakses sebesar 256.

Di area risiko kunci, yaitu Alamat Dompet non-pemilik tunggal yang kontrafaktual, saat ini relatif jarang terjadi, tetapi dengan masuknya dunia L2 multi, mungkin akan menjadi lebih umum. Satu-satunya solusi adalah dengan sederhana menerima risiko ini, namun untuk mengidentifikasi semua kasus penggunaan umum yang mungkin bermasalah dan menawarkan solusi yang efektif.

Apa hubungannya dengan penelitian yang ada?

Proposal awal

• Blok链清洁；
• Regenerasi;
• Teori Manajemen Ukuran Status Ethereum;
• Beberapa kemungkinan jalur tanpa status dan status kadaluarsa;

Usulan Kadaluwarsa Sebagian Status

• EIP-7736;

Alamat空间扩展文档

• Proposal asli;
• Ulasan Ipsilon;
• Komentar artikel blog;
• Jika kita kehilangan daya tahan tabrakan, apa yang akan rusak.

Apa lagi yang perlu dilakukan, dan apa yang perlu dipertimbangkan?

Saya percaya bahwa ada empat jalan yang layak di masa depan:

• Kami mencapai keadaan tanpa status dan tidak pernah memperkenalkan kadaluarsa status. Status terus naik (meskipun lambat: kita mungkin tidak dapat melihatnya melebihi 8 TB dalam beberapa dekade), tetapi hanya diperlukan oleh pengguna kategori relatif khusus: bahkan validator PoS tidak perlu status. Salah satu fitur yang membutuhkan akses ke sebagian status adalah pembuatan daftar yang dimasukkan, tetapi kita dapat menyelesaikan operasi ini secara terdesentralisasi: setiap pengguna bertanggung jawab untuk memelihara bagian dari pohon status yang berisi akun mereka sendiri. Ketika mereka menyiarkan transaksi, mereka akan menyiarkan transaksi dan menyertakan bukti objek status yang diakses selama langkah verifikasi (ini berlaku untuk akun EOA dan ERC-4337). Kemudian, validator tanpa status dapat menggabungkan bukti-bukti ini menjadi satu bukti yang mencakup seluruh daftar.
• Kami melakukan pembaharuan status parsial dan menerima tingkat pertumbuhan ukuran status permanen yang jauh lebih rendah namun tetap non-nol. Hasil ini dapat dikatakan mirip dengan bagaimana proposal berakhir yang melibatkan jaringan setara menerima tingkat pertumbuhan penyimpanan sejarah permanen yang jauh lebih rendah namun tetap non-nol di mana setiap klien harus menyimpan persentase data sejarah yang lebih rendah namun tetap tetap tetap pada tingkat pertumbuhan penyimpanan sejarah.
• Kami akan memperluas ruang Alamat untuk melakukan penghapusan status. Proses ini akan memakan waktu bertahun-tahun untuk memastikan metode konversi format Alamat efektif dan aman, termasuk aplikasi yang sudah ada.
• Kami menggunakan penyusutan ruang Alamat untuk mengatasi masa kadaluwarsa status. Ini akan melibatkan proses yang berlangsung bertahun-tahun untuk memastikan semua risiko keamanan yang terkait dengan konflik Alamat (termasuk kasus Cross-Chain Interaksi) ditangani dengan baik.

Satu hal yang penting adalah, apakah skema jangka waktu status yang bergantung pada perubahan format Alamat akan diimplementasikan atau tidak, pada akhirnya harus memecahkan masalah perluasan dan penyusutan ruang Alamat. Saat ini, sekitar 280 nilai hash diperlukan untuk menghasilkan konflik Alamat, dan untuk peserta yang memiliki sumber daya yang sangat melimpah, beban komputasi ini sudah dapat diterima: GPU dapat melakukan sekitar 227 nilai hash, sehingga dengan menjalankannya selama setahun, dapat menghitung 252, dan dengan demikian semua GPU di dunia sekitar 230 dapat menghitung tabrakan sekali dalam sekitar 1/4 tahun, sedangkan FPGA dan ASIC dapat mempercepat proses ini lebih lanjut. Di masa depan, jenis serangan seperti ini akan tersedia untuk semakin banyak orang. Oleh karena itu, biaya implementasi status ke masa depan sepenuhnya mungkin tidak sebesar yang terlihat, karena kita harus memecahkan masalah Alamat yang sangat menantang ini bagaimanapun juga.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Masa kedaluwarsa status dapat membuat konversi dari satu format pohon status ke format pohon status lainnya menjadi lebih mudah, karena tidak perlu proses konversi: Anda dapat dengan mudah mulai membuat pohon baru dengan format baru, lalu melakukan hard fork untuk mengonversi pohon lama. Oleh karena itu, meskipun status kedaluwarsa sangat kompleks, itu memang bermanfaat untuk menyederhanakan aspek lain dari peta jalan.

Pembersihan Fitur

Apa masalah yang dipecahkan oleh ini?

Salah satu prasyarat kunci untuk keamanan, aksesibilitas, dan netralitas yang dapat dipercaya adalah kesederhanaan. Jika protokolnya rapi dan sederhana, maka kemungkinan kesalahan akan berkurang. Ini meningkatkan peluang bagi pengembang baru untuk terlibat dalam bagian apapun. Ini lebih mungkin adil, dan juga lebih mudah untuk menahan kepentingan khusus. Sayangnya, seperti sistem sosial apa pun, protokol cenderung menjadi lebih kompleks seiring waktu. Jika kita tidak ingin Ethereum terjebak dalam lubang hitam yang semakin kompleks, kita perlu melakukan salah satu dari dua hal ini: (i) berhenti melakukan perubahan dan membuat protokol menjadi kaku, (ii) dapat benar-benar menghapus fitur dan menurunkan kompleksitas. Jalan tengah juga mungkin, yaitu melakukan sedikit perubahan pada protokol, dan seiring waktu setidaknya mengurangi sedikit kompleksitas. Bagian ini akan membahas bagaimana mengurangi atau menghilangkan kompleksitas.

Apa itu, bagaimana cara kerjanya?

Tidak ada satu perbaikan besar tunggal pun yang dapat menurunkan kompleksitas protokol; inti masalahnya adalah ada banyak solusi kecil.

Sebuah contoh yang sebagian besar selesai adalah menghapus kode operasi SELFDESTRUCT, dan dapat berfungsi sebagai blueprint tentang bagaimana cara menangani contoh lainnya. Kode operasi SELFDESTRUCT adalah satu-satunya yang dapat memodifikasi sejumlah tak terbatas slot penyimpanan dalam satu blok, yang memerlukan implementasi klien yang jauh lebih kompleks secara signifikan untuk menghindari serangan DOS. Tujuan awal dari kode operasi ini adalah untuk mencapai likuidasi status sukarela, yang memungkinkan ukuran status untuk berkurang seiring waktu. Namun, pada kenyataannya, hampir tidak ada orang yang akhirnya menggunakannya. Kode operasi ini dilemahkan, hanya memungkinkan akun yang dihancurkan dalam transaksi yang sama dengan hard fork Dencun. Hal ini mengatasi masalah DOS dan dapat secara signifikan menyederhanakan kode klien. Di masa depan, menghapus kode operasi sepenuhnya mungkin menjadi tindakan yang masuk akal.

Beberapa contoh kunci dari peluang protokol yang telah ditentukan sejauh ini termasuk yang berikut. Pertama, beberapa contoh di luar EVM; ini relatif non-intrusif, sehingga lebih mudah mencapai Konsensus dan mengimplementasikannya dalam waktu yang lebih singkat.

Konversi RLP → SSZ: Awalnya, objek Ethereum diserialisasi menggunakan format encoding yang disebut RLP. RLP adalah tipe data yang tidak berjenis dan tidak perlu rumit. Saat ini, beacon chain menggunakan SSZ yang jauh lebih baik dalam banyak hal termasuk mendukung serialisasi dan hash. Pada akhirnya, kami berharap dapat sepenuhnya menghilangkan RLP dan memindahkan semua jenis data ke dalam struktur SSZ, yang akan membuat upgrade lebih mudah. EIP saat ini termasuk[1][2]。

Menghapus jenis perdagangan lama: Terlalu banyak jenis perdagangan saat ini, banyak di antaranya mungkin akan dihapus. Alternatif yang lebih ringan untuk penghapusan total adalah fitur abstraksi akun, di mana akun pintar dapat memasukkan kode untuk memproses dan memvalidasi perdagangan lama (jika mereka mau).

Reformasi LOG: Membuat filter bloom untuk pencatatan log dan logika lainnya, meningkatkan kompleksitas protokol, tetapi sebenarnya tidak digunakan oleh klien karena terlalu lambat. Kita dapat menghapus fitur-fitur ini dan beralih ke solusi alternatif seperti menggunakan alat pembacaan log protokol desentralisasi yang menggunakan teknologi modern seperti SNARK.

Akhirnya menghapus mekanisme komite sinkronisasi beacon chain: Mekanisme komite sinkronisasi pada awalnya diperkenalkan untuk mendukung verifikasi light client ETH namun justru secara signifikan meningkatkan kompleksitas protokol. Akhirnya, kita akan dapat secara langsung menggunakan verifikasi SNARK pada lapisan Konsensus ETH, yang akan menghilangkan kebutuhan akan protokol verifikasi light client khusus. Secara potensial, perubahan Konsensus dapat memungkinkan kita untuk lebih cepat menghapus komite sinkronisasi dengan menciptakan protokol verifikasi light client yang lebih "asli", yang melibatkan tanda tangan subset acak dari validator verifikasi Konsensus ETH.

Pemformatan data yang seragam: Saat ini, status pelaksanaan disimpan dalam pohon Merkle Patricia, status Konsensus disimpan dalam pohon SSZ, dan blob dikirimkan melalui komitmen KZG. Di masa depan, memiliki format seragam tunggal untuk data blok dan status akan bermakna. Format ini akan memenuhi semua kebutuhan penting: (i) bukti sederhana untuk klien tanpa status, (ii) serialisasi data dan pengkodean penghapusan, (iii) struktur data standar.

Menghapus komite beacon chain: Mekanisme ini awalnya diperkenalkan untuk mendukung pelaksanaan Sharding versi tertentu. Sebagai gantinya, kami akhirnya menggunakan L2 dan blob untuk Sharding. Oleh karena itu, komite ini tidak diperlukan, dan tindakan penghapusan komite sedang dilakukan.

Menghapus urutan byte campuran: EVM menggunakan urutan byte besar, lapisan konsensus menggunakan urutan byte kecil. Rekonsiliasi ulang dan membuat semua konten menjadi satu atau yang lain mungkin bermakna (mungkin menjadi urutan byte besar karena EVM lebih sulit untuk diubah)

Sekarang, beberapa contoh di EVM:

Sederhanaan Mekanisme gas: Aturan Gas saat ini belum dioptimalkan dengan baik, sehingga tidak dapat memberikan batasan yang jelas terhadap jumlah sumber daya yang diperlukan untuk memverifikasi Blok. Contoh utama yang relevan termasuk (i) biaya pembacaan/penulisan penyimpanan, yang bertujuan untuk membatasi jumlah pembacaan/penulisan dalam satu blok, tetapi saat ini masih cukup sewenang-wenang, dan (ii) aturan pengisian memori, yang saat ini sulit untuk memperkirakan konsumsi memori maksimum EVM. Upaya perbaikan yang diajukan termasuk perubahan biaya Gas non-status (menggabungkan semua biaya terkait penyimpanan menjadi rumus sederhana tunggal) dan proposal harga memori.

Menghapus pra-kompilasi: Banyak pra-kompilasi yang dimiliki oleh Ethereum tidak perlu rumit, kurang digunakan, dan merupakan bagian besar dari kegagalan Konsensus karena hampir tidak digunakan oleh aplikasi apa pun. Ada dua cara untuk menangani masalah ini: (i) hanya menghapus pra-kompilasi, dan (ii) menggantinya dengan kode EVM (yang lebih mahal) yang menerapkan logika yang sama. Rancangan EIP ini menyarankan untuk melakukan langkah pertama untuk menghapus pra-kompilasi identitas; kemudian, RIPEMD160, MODEXP, dan BLAKE mungkin menjadi kandidat penghapusan.

Menghapus gas observability: membuat EVM tidak lagi dapat melihat berapa banyak gas yang tersisa untuk dieksekusi. Ini akan merusak beberapa aplikasi (yang paling jelas adalah transaksi sponsor), tetapi akan lebih mudah untuk ditingkatkan di masa depan (misalnya, untuk versi gas multi-dimensi). EOF telah membuat Gas tidak dapat diobservasi, tetapi untuk menyederhanakan protokol, EOF perlu menjadi obligatif.

Peningkatan Analisis Statik: Saat ini, sangat sulit untuk melakukan analisis statik pada kode EVM, terutama karena lompatan dapat bersifat dinamis. Hal ini juga membuat penyempurnaan implementasi EVM (memprediksi kode EVM ke bahasa lain) semakin sulit. Kita dapat memecahkan masalah ini dengan menghapus lompatan dinamis (atau membuatnya lebih mahal, misalnya, biaya Gas untuk jumlah JUMPDEST di kontrak menjadi linear). EOF melakukan hal ini, meskipun untuk mendapatkan manfaat sederhana protokol, EOF harus diterapkan secara paksa.

Apa hubungannya dengan penelitian yang ada?

• Langkah-langkah lanjutan pembersihan;
• Merusak diri sendiri
• SSZ to EIPS:[1][2]；
• Biaya gas tanpa status berubah;
• Penentuan harga memori linear;
• Penghapusan pra-kompilasi;
• menghapus filter bloom;
• Metode untuk melakukan pengambilan log aman off-chain menggunakan perhitungan verifikasi bertambah (baca: rekursif STARK);

Apa lagi yang perlu dilakukan, dan apa yang perlu dipertimbangkan?

Salah satu pertimbangan utama dalam menyederhanakan fungsi ini adalah (i) sejauh mana dan seberapa cepat kami menyederhanakan dan (ii) kompatibilitas ke belakang. Nilai Ethereum sebagai jaringan datang dari fakta bahwa itu adalah platform di mana Anda dapat mendeploy aplikasi dan yakin bahwa itu akan tetap berfungsi dalam beberapa tahun ke depan. Namun, idealisme ini juga dapat berjalan terlalu jauh, seperti yang dikatakan oleh William Jennings Bryan, 'menyalib Ethereum pada tiang kompatibilitas ke belakang'. Jika hanya ada dua aplikasi dalam seluruh Ethereum yang menggunakan fitur yang diberikan, dan satu aplikasi tidak memiliki pengguna selama bertahun-tahun sementara aplikasi lain hampir tidak digunakan dan memiliki nilai total $57, maka kita harus menghapus fitur tersebut dan mengganti $57 untuk korban jika perlu.

Masalah sosial yang lebih luas adalah menciptakan saluran standar untuk melakukan perubahan yang merusak kompatibilitas mundur yang tidak darurat. Salah satu cara untuk menyelesaikan masalah ini adalah dengan memeriksa dan memperluas contoh-contoh yang ada, seperti proses penghancuran diri. Saluran terlihat seperti berikut:

• Mulai membahas fitur penghapusan X;
• Melakukan analisis untuk menentukan dampak penghapusan X pada aplikasi, tergantung pada hasilnya: (i) membuang ide tersebut, (ii) melanjutkan sesuai rencana, atau (iii) menentukan metode penghapusan X yang meminimalkan kerusakan dan melanjutkan.
• Mengembangkan EIP resmi untuk menghentikan X. Pastikan infrastruktur tingkat atas yang populer (seperti bahasa pemrograman, Dompet) menghargai hal ini dan menghentikan penggunaan fitur tersebut.
• Terakhir, hapus X secara aktual;
• Harus ada pipa yang panjang antara Langkah 1 dan Langkah 4, serta secara jelas menentukan proyek mana yang berada di langkah mana. Pada titik ini, perlu melakukan keseimbangan antara kegairahan dan kecepatan dalam proses penghapusan fitur dengan pendekatan yang lebih konservatif dan penyaluran sumber daya yang lebih besar ke bidang pengembangan protokol lainnya, tetapi kita masih jauh dari batas Pareto.

EOF

Sebuah set utama perubahan yang diajukan untuk EVM adalah Format Objek EVM (EOF). EOF memperkenalkan banyak perubahan, seperti larangan observabilitas gas, observabilitas kode (yaitu tanpa CODECOPY), dan hanya mengizinkan lompatan statis. Tujuannya adalah memungkinkan EVM untuk melakukan lebih banyak peningkatan dengan properti yang lebih kuat, sambil tetap mempertahankan kompatibilitas mundur (karena EVM sebelum EOF masih ada).

Keuntungan dari ini adalah menciptakan jalur alami untuk menambahkan fitur-fitur EVM baru dan mendorong migrasi ke EVM yang lebih kuat dan lebih ketat dengan jaminan yang lebih baik. Kerugiannya adalah ini secara signifikan meningkatkan kompleksitas protokol, kecuali jika kita bisa menemukan cara untuk secara akhirnya menghentikan dan menghapus EVM lama. Salah satu masalah utama adalah: apa peran EOF dalam proposal penyederhanaan EVM, terutama jika tujuannya adalah menurunkan kompleksitas EVM keseluruhan?

Bagaimana interaksi dengan bagian lain dari peta jalan?

Banyak saran "perbaikan" dalam bagian sisa peta jalan juga merupakan kesempatan untuk menyederhanakan fitur lama. Beberapa contoh yang telah disebutkan di atas:

• Beralih ke finalitas tunggal memberi kita kesempatan untuk membatalkan komite, mendesain ulang ekonomi, dan melakukan penyederhanaan lain yang terkait dengan Proof of Stake.
• Implementasi abstraksi akun lengkap dapat memungkinkan kami menghapus sejumlah besar logika pemrosesan transaksi yang ada, dan memindahkannya ke dalam "kode EVM akun default" yang dapat digantikan oleh semua EOA.
• Jika kita memindahkan status Ethereum ke pohon hash biner, ini dapat konsisten dengan versi baru SSZ agar semua struktur data Ethereum dapat di-hash dengan cara yang sama.

Metode yang lebih agresif: mengonversi sebagian besar konten protokol menjadi kode kontrak

Sebuah strategi penyederhanaan ETH yang lebih agresif adalah tetap mempertahankan protokol yang ada, tetapi memindahkan sebagian besar fungsinya dari protokol ke kode kontrak.

Versi yang paling ekstrem adalah membuat ETH Workshop L1 "secara teknis" hanya rantai suar, dan memperkenalkan Mesin Virtual minimal (seperti RISC-V, Kairo, atau bahkan lebih kecil yang didedikasikan untuk sistem bukti) yang memungkinkan orang lain untuk membuat agregat mereka sendiri. EVM kemudian menjadi yang pertama dari rollup ini. Ironisnya, ini adalah hasil yang persis sama dengan implementasi proposal lingkungan pada 2019-20, meskipun SNARKs membuat implementasi praktis mereka jauh lebih layak.

Cara yang lebih moderat adalah menjaga hubungan antara beacon chain dan lingkungan eksekusi blok ETH saat ini tetap tidak berubah, tetapi melakukan penggantian langsung terhadap EVM. Kita dapat memilih RISC-V, Cairo, atau VM lain sebagai 'VM resmi ETH blok' baru, kemudian memaksa semua kontrak EVM untuk dikonversi ke kode VM baru yang menginterpretasikan logika kode asli (melalui kompilasi atau interpretasi). Secara teori, ini bahkan dapat dilakukan dengan 'Target Virtual Machine' sebagai salah satu versi EOF.