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

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

· Data sejarah: Setiap transaksi yang pernah dilakukan dan setiap akun yang dibuat pada setiap saat dalam sejarah harus disimpan secara permanen oleh semua klien dan diunduh oleh klien baru untuk sepenuhnya disinkronkan 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, menyebabkan kompleksitas kode meningkat seiring berjalannya waktu.

Untuk menjaga agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, seiring berjalannya waktu Drop kompleksitas dan inflasi. Tetapi seiring dengan itu, kita perlu mempertahankan salah satu sifat kunci yang membuat blockchain begitu hebat: ketahanan. Anda dapat menempatkan sebuah token Non-fungible, percakapan penuh cinta dalam data transaksi, atau Smart Contract senilai 100 juta dolar ke on-chain, masuk ke dalam gua selama sepuluh tahun, dan menemukan bahwa itu masih ada di sana menunggu Anda untuk membacanya dan berinteraksi. Agar DApp dapat dengan yakin sepenuhnya Desentralisasi dan menghapus Kunci Rahasia upgrade, mereka perlu yakin dependensi mereka tidak akan naik tingkat dengan cara yang merusak - terutama L1 itu sendiri.

Jika kita bertekad untuk menemukan keseimbangan antara dua kebutuhan ini dan mengurangi atau membalikkan kelebihan, kompleksitas, dan penurunan dengan mempertahankan kontinuitas, itu benar-benar mungkin. Organisme hidup dapat melakukannya: meskipun sebagian besar organisme hidup mengalami penuaan seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial juga dapat memiliki umur panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja telah hilang, sebagian besar opcode SELFDESTRUCT telah hilang, dan Beacon Chain Node telah menyimpan data lama selama enam bulan. Menemukan jalan ini secara lebih umum untuk Ethereum dan menuju hasil akhir yang stabil secara jangka panjang adalah tantangan utama untuk skalabilitas jangka panjang, keberlanjutan teknis, dan bahkan keamanan Ethereum.

The Purge: target utama.

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

· Dengan menghilangkan kompleksitas yang tidak diperlukan, Drop protokol.

Daftar Isi Artikel:

· Kadaluarsa riwayat

· Kadaluwarsa status

· Pembersihan Fitur

Kadaluarsa sejarah

Apa masalah yang ingin diselesaikan?

Pada saat artikel ini ditulis, Node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, serta beberapa ratus GB ruang disk tambahan untuk klien Konsensus. Sebagian besar adalah data historis: data Blok, transaksi, dan tanda terima historis, sebagian besar telah berusia bertahun-tahun. Hal ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran Node akan terus bertambah beberapa ratus GB setiap tahun.

Apa itu dan bagaimana cara kerjanya?

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

Ini memberi kami banyak pilihan untuk menyimpan catatan sejarah. Pilihan alami adalah setiap Node hanya menyimpan sebagian kecil data dari jaringan. Cara kerja jaringan benih ini selama puluhan tahun: meskipun jaringan secara keseluruhan menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file. Mungkin secara mengejutkan, metode ini bahkan tidak akan menurunkan kekokohan data. Jika dengan menjalankan Node lebih hemat biaya, kita dapat membangun jaringan dengan 100.000 Node, di mana setiap Node menyimpan 10% catatan sejarah secara acak, maka setiap data akan disalin 10.000 kali - sama dengan faktor duplikasi 10.000 Node - jaringan Node, di mana setiap Node menyimpan semua konten.

Saat ini, Ethereum telah mulai keluar dari model di mana setiap Node menyimpan sejarah secara permanen. Bagian Konsensus Blok (yang terkait dengan Proof of Stake) hanya menyimpan sekitar 6 bulan. Blok hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan selama satu tahun untuk Blok dan tanda terima sejarah. Tujuan jangka panjang 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 secara terdistribusi.

Erasure code dapat digunakan untuk meningkatkan kekokohan, sambil mempertahankan faktor replikasi yang sama. Faktanya, Blob sudah menggunakan kode erasure untuk mendukung pengambilan sampel ketersediaan data. Solusi yang paling sederhana kemungkinan besar adalah menggunakan kembali kode Erasure ini, dan juga memasukkan data blok eksekusi dan Konsensus ke dalam blob.

Apa hubungannya dengan penelitian yang ada?

· EIP-4444 ；

· Torrents dan EIP-4444 ；

· Jaringan Portal;

· Jaringan portal dan EIP-4444;

Penyimpanan dan pengambilan terdistribusi objek SSZ di Portal.

· Bagaimana meningkatkan batasan gas (Paradigma).

Apa 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 menjalankan catatan sejarah, tetapi akhirnya juga termasuk Konsensus dan blob. Solusi yang paling sederhana adalah (i) secara sederhana mengenalkan perpustakaan torrent yang sudah ada, dan (ii) solusi asli ETH yang disebut Portal Network. Begitu salah satunya diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 sendiri tidak memerlukan fork keras, tetapi memang membutuhkan versi protokol jaringan baru. Oleh karena itu, ada nilai dalam mengaktifkannya secara bersamaan untuk semua klien, jika tidak ada risiko kegagalan klien karena terhubung ke Node lain yang diharapkan mengunduh catatan sejarah lengkap tetapi sebenarnya tidak mendapatkannya.

Pertimbangan utama terkait dengan bagaimana kita berupaya untuk menyediakan data sejarah ‘kuno’. Solusi paling sederhana adalah menghentikan penyimpanan 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 tetapi lebih aman adalah dengan membangun dan mengintegrasikan jaringan torrent terlebih dahulu, untuk menyimpan catatan sejarah secara terdistribusi. Di sini, ‘seberapa keras kita berusaha’ memiliki dua dimensi:

1. Bagaimana kami berusaha memastikan bahwa kumpulan Node terbesar benar-benar menyimpan semua data?

2. Seberapa dalam kami mengintegrasikan penyimpanan sejarah ke Kedalaman dalam protokol?

Metode paranoia ekstrim untuk (1) akan melibatkan bukti penitipan: secara efektif meminta setiap validator Proof of Stake untuk menyimpan sejumlah persentase catatan sejarah dan secara berkala memeriksanya secara enkripsi apakah mereka melakukannya. Pendekatan yang lebih lunak adalah dengan menetapkan standar sukarela untuk persentase sejarah yang disimpan oleh setiap klien.

Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang sudah 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 sejarah lengkap, bahkan tanpa keberadaan Node arsip lainnya secara online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Jika kita ingin membuat operasi Node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan historis bisa dikatakan lebih penting daripada keadaan tanpa status: dari 1.1 TB yang dibutuhkan oleh Node, sekitar 300 GB adalah status, sementara sisanya sekitar 800 GB telah menjadi sejarah. Hanya dengan menerapkan tanpa status dan EIP-4444, kita dapat mencapai visi menjalankan Node Ethereum pada smartwatch dan bisa diatur dalam beberapa menit saja.

Pembatasan penyimpanan sejarah juga membuat implementasi Node Eth yang lebih baru menjadi lebih layak, hanya mendukung versi protokol terbaru, yang membuatnya lebih sederhana. Misalnya, sekarang banyak baris kode yang dapat dihapus dengan aman karena semua slot penyimpanan kosong yang dibuat selama serangan DoS tahun 2016 telah dihapus. Sekarang bahwa 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 ingin diselesaikan?

Meskipun kita menghilangkan kebutuhan untuk menyimpan riwayat klien, kebutuhan penyimpanan klien akan terus naik, sekitar 50 GB per tahun, karena status terus naik: saldo akun dan angka acak, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya satu kali sehingga memberikan beban yang abadi bagi klien ETH saat ini dan di masa depan.

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

Apa itu dan bagaimana itu bekerja

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 tersebut tetap berada dalam status tersebut selamanya. Sebaliknya, yang kita inginkan adalah objek tersebut secara otomatis kadaluarsa seiring berjalannya waktu. Tantangan utama adalah untuk mencapai tiga tujuan ini dalam sebuah implementasi:

1. Efisiensi: Tidak memerlukan perhitungan tambahan yang besar untuk menjalankan proses yang sudah jatuh tempo.

2. Kemudahan pengguna: Jika seseorang telah menghabiskan lima tahun di dalam gua dan kembali, mereka tidak harus kehilangan akses ke posisi ETH, ERC 20, non-fungible token, CDP…

3. Kepuasan Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak familiar. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui harus tetap dapat berjalan normal.

Tidak memenuhi target-target ini akan sangat mudah untuk menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status menyimpan penghitung tanggal kedaluwarsa (dapat diperpanjang dengan membakar ETH, yang mungkin terjadi secara otomatis kapan saja dibaca atau ditulis), dan memiliki proses yang melintasi status untuk menghapus tanggal kedaluwarsa dari objek status. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan pasti tidak dapat memenuhi persyaratan kemanusiaan. Pengembang juga sulit untuk merasionalkan kasus tepi di mana nilai penyimpanan terlibat kadang-kadang diatur ulang menjadi nol. Jika Anda mengatur penghitung waktu kedaluwarsa dalam kontrak, ini secara teknis akan membuat hidup pengembang lebih mudah, tetapi akan membuat ekonomi menjadi lebih sulit: Pengembang harus memikirkan bagaimana cara ‘meneruskan’ biaya penyimpanan kepada pengguna.

Ini adalah masalah yang telah lama diupayakan untuk dipecahkan oleh komunitas pengembangan inti Ethereum, termasuk proposal seperti ‘Blok Rental’ dan ‘Regenerasi’. Pada akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan fokus pada dua jenis ‘solusi terbaik yang diketahui’.

· Sebagian solusi kadaluarsa status

· Saran berdasarkan siklus Alamat yang akan berakhir.

Kadaluarsa Status Parsial

Beberapa proposal kedaluwarsa status mengikuti prinsip yang sama. Kami membagi negara menjadi potongan-potongan. Semua orang secara permanen menyimpan “pemetaan tingkat atas”, di mana blok kosong atau tidak kosong. Data di setiap blok disimpan hanya jika data telah diakses baru-baru ini. Ada mekanik “kebangkitan” jika 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 konkret adalah EIP-7736, yang dibangun di atas desain “ranting daun” yang diperkenalkan untuk pohon Verkle (meskipun kompatibel dengan segala bentuk status tanpa keadaan, seperti pohon biner). Dalam desain ini, header, kode, dan slot penyimpanan yang berdekatan disimpan di bawah satu “batang” yang sama. Data yang disimpan di bawah ranting dapat mencapai maksimal 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun, serta banyak slot kunci penyimpanan, akan disimpan di bawah satu batang yang sama. Jika data dalam batang yang diberikan tidak dibaca atau ditulis dalam waktu 6 bulan, data tersebut tidak akan disimpan lagi, tetapi hanya menyimpan komitmen 32 byte dari data tersebut (“tumpuan”). Transaksi yang mengakses data di masa depan akan memerlukan “penghidupan” data dan memberikan bukti berdasarkan tumpuan.

Ada metode lain untuk mewujudkan gagasan serupa. Misalnya, jika granularitas tingkat akun tidak mencukupi, kita bisa merancang skema di mana setiap bagian 1/2 32 dari pohon dikendalikan oleh mekanisme batang daun yang serupa.

Karena faktor insentif, ini menjadi lebih rumit: penyerang dapat memaksa klien untuk menyimpan sejumlah besar status 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 berbanding terbalik dengan durasi perpanjangan), seseorang dapat 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 2^16 = 65536 objek status berurutan dapat dianggap sebagai ‘kelompok’. Namun, gagasan-gagasan ini lebih kompleks; metode berbasis batang sangat sederhana dan insentif dapat disesuaikan karena semua data di bawah batang umumnya terkait dengan aplikasi atau pengguna yang sama.

Saran Kedaluwarsa Status Berdasarkan Siklus Alamat

Jika kita ingin sepenuhnya menghindari naik keadaan permanen, bahkan 32-byte stub, apa yang harus dilakukan? Ini adalah dilema karena konflik kebangkitan: jika sebuah objek keadaan dihapus, kemudian EVM akan menempatkan objek keadaan lain di posisi yang sama, tetapi bagaimana jika seseorang yang peduli dengan objek keadaan asli kembali dan mencoba mengembalikannya? Ketika bagian dari keadaan kedaluwarsa, “stub” akan mencegah penciptaan data baru. Saat keadaan kedaluwarsa sepenuhnya, kita bahkan tidak dapat menyimpan stub.

Desain berbasis siklus Alamat adalah konsep yang paling terkenal untuk mengatasi masalah ini. Kami tidak menyimpan seluruh status dalam satu pohon status, tetapi daftar pohon status yang naik terus menerus, dan setiap status yang dibaca atau ditulis akan disimpan dalam pohon status terbaru. Setiap periode (misalnya: 1 tahun) menambahkan satu pohon status kosong baru. Pohon yang lebih lama akan membeku dengan sangat kuat. Node lengkap hanya menyimpan dua pohon terbaru. Jika objek status tidak tersentuh selama dua periode dan jatuh ke dalam pohon yang kedaluwarsa, itu masih dapat dibaca atau ditulis, tetapi transaksi perlu membuktikan bukti Merkle - setelah terbukti, salinan akan disimpan kembali dalam pohon terbaru.

Salah satu konsep kunci yang ramah pengguna dan pengembang adalah konsep siklus Alamat. Siklus Alamat adalah angka yang merupakan bagian dari Alamat. Aturan kunci adalah Alamat dengan siklus Alamat N hanya dapat dibaca atau ditulis selama atau setelah siklus N (yaitu, ketika daftar pohon status mencapai panjang N). Jika Anda ingin menyimpan objek status baru (misalnya, kontrak baru atau saldo ERC 20 baru), jika Anda memastikan objek status tersebut dimasukkan ke dalam kontrak dengan siklus Alamat N atau N-1, maka Anda dapat menyimpannya secara langsung tanpa perlu membuktikan bahwa sebelumnya tidak ada apa-apa. Di sisi lain, setiap tambahan atau pengeditan yang dilakukan selama siklus Alamat lama memerlukan bukti.

Desain ini mempertahankan sebagian besar properti saat ini dari Ethereum, tanpa perlu perhitungan tambahan, memungkinkan aplikasi untuk ditulis hampir seperti sekarang (ERC 20 perlu ditulis ulang untuk memastikan saldo Alamat dengan siklus N disimpan di dalam subkontrak, dengan siklus N Alamat itu sendiri), yang mengatasi masalah “pengguna masuk goa selama lima tahun”. Namun, ada satu masalah besar: Alamat perlu diperluas menjadi lebih dari 20 byte untuk cocok dengan siklus Alamat.

Alamat空间扩展地址空间扩展

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

0x01 (merah) 0000 (oranye) 000001 (hijau) 57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF (biru).

Merah adalah nomor versi. Empat angka nol oranye di sini dimaksudkan sebagai ruang kosong yang dapat menampung nomor Sharding di masa depan. Hijau adalah nomor siklus Alamat. Biru adalah nilai hash 26 byte.

Tantangan utama di sini adalah kompatibilitas mundur. Kontrak yang ada didesain berdasarkan Alamat 20 byte, dan sering kali menggunakan teknik pemaketan byte yang ketat, dengan asumsi yang jelas bahwa Alamat memiliki panjang 20 byte. Salah satu ide untuk mengatasi masalah ini melibatkan pemetaan konversi, di mana kontrak lama yang berinteraksi dengan Alamat baru akan melihat nilai hash 20 byte dari Alamat baru. Namun, memastikan keamanannya memiliki kompleksitas yang tinggi.

Ruang Alamat menyusut

Metode lain mengambil arah yang berlawanan: Kami segera melarang beberapa subrentang Alamat dengan ukuran 2 128 (misalnya, semua Alamat yang dimulai dengan 0x ffffffff), dan kemudian menggunakan rentang tersebut untuk memperkenalkan Alamat dengan siklus dan nilai hash 14 byte.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

Pengorbanan utama yang dibuat dengan metode ini adalah memperkenalkan risiko keamanan Alamat fiktif: Alamat yang memegang aset atau otoritas, tetapi kode mereka belum dipublikasikan di rantai. Risiko melibatkan seseorang menciptakan Alamat yang mengklaim memiliki sepotong kode (belum dipublikasikan), tetapi juga memiliki hash kode yang valid di Alamat yang sama. Hari ini, menghitung benturan seperti ini membutuhkan 2^80 hash; penyusutan ruang Alamat akan mengurangi angka ini menjadi 2^56 hash yang mudah diakses.

Di area risiko kunci, yaitu Alamat non-faktual Dompet yang dimiliki oleh pemilik tunggal, saat ini relatif jarang terjadi, tetapi dengan masuknya dunia L2 multipel, hal ini mungkin menjadi lebih umum. Satu-satunya solusi adalah dengan menerima risiko ini secara sederhana, namun menentukan semua kasus penggunaan umum yang mungkin bermasalah dan menawarkan solusi yang efektif.

Apa hubungannya dengan penelitian yang ada?

Proposal awal

Blok Blockchain bersih;

Regenerasi;

Teori Manajemen Ukuran Status Ethereum;

Beberapa kemungkinan jalur tanpa status dan status kedaluwarsa;

Proposal Status Expired

EIP-7736;

Alamat空间扩展文档

Usulan Asli;

Ulasan Ipsilon;

Komentar pada artikel blog;

Jika kita kehilangan hambatan tumbukan, apa yang akan rusak.

Apa yang perlu dilakukan dan apa yang perlu dipertimbangkan?

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

· Kami mencapai keadaan tanpa status, dan tidak pernah memperkenalkan status kedaluwarsa. Status terus naik (meskipun lambat: kita mungkin tidak melihatnya lebih dari 8 TB beberapa puluh tahun), tetapi hanya perlu oleh pengguna kategori yang relatif khusus: bahkan validator PoS pun tidak memerlukan status.

Sebuah fitur yang membutuhkan akses ke sebagian status adalah pembuatan daftar terpadu, tetapi kita dapat menyelesaikan ini secara terdesentralisasi: setiap pengguna bertanggung jawab untuk mempertahankan bagian dari pohon status yang mencakup akun mereka sendiri. Ketika mereka menyiarkan transaksi, mereka akan menyiarkan transaksi dan menyertakan bukti objek status yang diakses selama langkah validasi (ini berlaku untuk akun EOA dan ERC-4337). Kemudian, validator tanpa status dapat menggabungkan bukti-bukti ini menjadi bukti yang mencakup seluruh daftar.

· Kami melakukan keadaan yang sebagian berakhir dan menerima tingkat pertumbuhan ukuran keadaan permanen yang jauh lebih rendah tetapi tetap non-nol. Hasil ini dapat dikatakan serupa dengan bagaimana proposal kedaluwarsa sejarah yang melibatkan jaringan peer-to-peer menerima tingkat pertumbuhan penyimpanan sejarah permanen yang jauh lebih rendah tetapi tetap non-nol, di mana setiap klien harus menyimpan persentase yang lebih rendah tetapi tetap tetap dari data sejarah.

· Kami menggunakan ekstensi Alamat untuk mengatasi masa berlakunya status. Ini melibatkan proses yang berlangsung bertahun-tahun untuk memastikan metode konversi format Alamat yang efektif dan aman, termasuk aplikasi yang sudah ada.

· Kami melakukan pengetatan ruang Alamat untuk mengatasi keadaan kedaluwarsa. Ini melibatkan proses bertahun-tahun untuk memastikan semua risiko keamanan yang terkait dengan konflik Alamat (termasuk situasi Interaksi Cross-Chain) ditangani.

Hal pentingnya adalah, apakah pun rencana akhirnya yang mengimplementasikan perubahan format Alamat yang bergantung pada status kedaluwarsa, masalah perlu diperhatikan tentang perluasan dan penyusutan ruang Alamat. Saat ini, penghasilan konflik Alamat memerlukan sekitar 2 80 nilai hash, yang sudah bisa dihitung oleh peserta dengan sumber daya yang sangat kaya: GPU dapat melakukan sekitar 2 27 nilai hash, sehingga dalam setahun bisa menghitung 2 52, sehingga sekitar 230 GPU di seluruh dunia bisa menghitung tabrakan sekali dalam sekitar 1/4 tahun, sementara FPGA dan ASIC dapat lebih mempercepat proses ini. Di masa depan, jenis serangan ini akan terbuka bagi semakin banyak orang. Oleh karena itu, biaya implementasi status kedaluwarsa sepenuhnya mungkin tidak sebesar yang terlihat, karena kita harus menyelesaikan masalah Alamat yang sangat menantang ini dengan cara apa pun.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Kedaluwarsa status dapat membuat konversi dari satu format pohon status ke format pohon status lain menjadi lebih mudah, karena tidak perlu proses konversi: Anda dapat langsung mulai menggunakan format baru untuk membuat pohon baru, kemudian melakukan hard fork untuk mengonversi pohon lama. Jadi, meskipun kedaluwarsa status ini kompleks, tetapi itu benar-benar menguntungkan dalam menyederhanakan aspek lain dari rencana.

Pembersihan Fitur

Apa masalah yang dipecahkan oleh ini?

Salah satu prasyarat kunci keamanan, aksesibilitas, dan netralitas terpercaya adalah kesederhanaan. Jika protokolnya cantik dan sederhana, maka kemungkinan terjadinya kesalahan akan berkurang. Ini meningkatkan peluang bagi pengembang baru untuk terlibat dalam bagian apapun. Lebih mungkin adil, dan lebih mudah untuk menolak kepentingan khusus. Sayangnya, protokol seperti sistem sosial lainnya, cenderung menjadi lebih kompleks seiring waktu. Jika kita tidak ingin Ethereum terperangkap dalam lubang hitam peningkatan kompleksitas, kita perlu melakukan salah satu dari dua hal berikut: (i) berhenti melakukan perubahan dan membuat protokol menjadi kaku, (ii) dapat secara faktual menghapus fitur dan Drop kompleksitas. Jalan tengah juga mungkin, yaitu melakukan sedikit perubahan pada protokol, dan setidaknya mengurangi sedikit kompleksitas seiring waktu. Bagian ini akan membahas bagaimana mengurangi atau menghilangkan kompleksitas.

Apa itu dan bagaimana cara kerjanya?

Tidak ada perbaikan tunggal yang signifikan yang dapat menurunkan kompleksitas protokol; inti dari masalah ini adalah ada banyak solusi kecil.

Sebuah contoh yang sebagian besar lengkap adalah menghapus kode operasi SELFDESTRUCT, dan dapat berfungsi sebagai blueprint tentang bagaimana cara menangani contoh lain. Kode operasi SELFDESTRUCT adalah satu-satunya yang dapat mengubah sejumlah tak terbatas slot penyimpanan dalam satu blok, yang memerlukan klien untuk mengimplementasikan kompleksitas yang jauh lebih tinggi untuk menghindari serangan DoS. Tujuan awal dari kode operasi ini adalah untuk melakukan penyelesaian status sukarela, yang memungkinkan ukuran status untuk berkurang seiring waktu. Namun, pada kenyataannya, sangat sedikit orang yang akhirnya menggunakannya. Kode operasi tersebut dilemahkan, hanya memungkinkan akun penghancuran yang dibuat dalam transaksi yang sama selama hardfork Dencun. Hal ini mengatasi masalah DoS dan dapat secara signifikan menyederhanakan kode klien. Di masa depan, penghapusan total kode operasi mungkin menjadi ide yang masuk akal.

Beberapa contoh kunci dari peluang yang disederhanakan protokol yang telah ditetapkan sejauh ini termasuk hal-hal berikut. Pertama, beberapa contoh di luar EVM; ini relatif non-invasif, sehingga lebih mudah untuk mencapai Konsensus dan menerapkannya dalam waktu yang lebih singkat.

· Konversi RLP → SSZ: Awalnya, objek Ethereum diserialisasi menggunakan format encoding yang disebut RLP. RLP tidak memiliki tipe dan secara tidak perlu rumit. Saat ini, beacon chain menggunakan SSZ, yang jauh lebih baik dalam banyak hal, termasuk mendukung serialisasi dan hash. Akhirnya, kita berharap dapat sepenuhnya meninggalkan RLP dan memindahkan semua tipe data ke dalam struktur SSZ, yang pada gilirannya akan membuat upgrade menjadi lebih mudah. EIP saat ini termasuk [ 1 ] [ 2 ] [ 3 ].

· Hapus jenis transaksi lama: Ada terlalu banyak jenis transaksi saat ini, banyak di antaranya mungkin akan dihapus. Salah satu alternatif yang lebih ringan untuk penghapusan lengkap adalah fitur abstraksi akun, di mana akun pintar dapat mengandung kode untuk memproses dan memverifikasi transaksi lama (jika mereka mau).

· Reformasi LOG: Pembuatan filter bloom dan logika lainnya dalam protokol telah meningkatkan kompleksitas, namun sebenarnya tidak digunakan oleh klien karena terlalu lambat. Kita dapat menghapus fitur-fitur ini dan beralih ke solusi pengganti, seperti menggunakan alat pembacaan log yang terdesentralisasi dari protokol menggunakan teknologi modern seperti SNARK.

· Akhirnya menghapus mekanisme komite sinkronisasi beacon chain: Mekanisme komite sinkronisasi awalnya diperkenalkan untuk mencapai verifikasi light client ETH, namun secara signifikan meningkatkan kompleksitas protokol. Akhirnya, kita akan dapat menggunakan verifikasi SNARK lapisan Konsensus ETH secara langsung, yang akan menghilangkan kebutuhan untuk protokol verifikasi light client khusus. Secara potensial, perubahan Konsensus dapat memungkinkan kita untuk lebih awal menghapus komite sinkronisasi dengan menciptakan protokol verifikasi subset acak dari validator verifikasi Konsensus ETH.

· Format data yang seragam: Saat ini, status eksekusi disimpan dalam pohon Merkle Patricia, status Konsensus disimpan dalam pohon SSZ, dan blob diserahkan melalui komitmen KZG. Di masa depan, memiliki format tunggal yang seragam untuk data blok dan status akan masuk akal. Format-format ini akan memenuhi semua kebutuhan penting: (i) bukti sederhana untuk klien tanpa status, (ii) serialisasi data dan encoding penghapusan, (iii) struktur data yang terstandar.

· Menghapus komite beacon chain: Mekanisme ini awalnya diperkenalkan untuk mendukung pelaksanaan Sharding versi tertentu. Sebaliknya, kami akhirnya melakukan Sharding melalui L2 dan blob. Oleh karena itu, komite ini tidak diperlukan, dan tindakan penghapusan komite sedang diambil.

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

Sekarang, beberapa contoh dalam EVM:

Sederhanaan dari mekanisme gas: Peraturan gas saat ini belum dioptimalkan dengan baik dan tidak dapat memberikan batasan yang jelas untuk jumlah sumber daya yang diperlukan untuk memvalidasi Blok. Contoh kunci dalam hal ini termasuk (i) biaya baca/tulis penyimpanan, yang dimaksudkan untuk membatasi jumlah baca/tulis dalam sebuah blok, namun saat ini cukup sewenang-wenang, dan (ii) aturan pengisian memori, yang saat ini sulit untuk memperkirakan konsumsi memori maksimum EVM. Langkah perbaikan yang diusulkan termasuk perubahan biaya gas tanpa status (menggabungkan semua biaya yang terkait dengan penyimpanan menjadi rumus sederhana tunggal) serta proposal penetapan harga memori.

· Menghapus pra-kompilasi: Saat ini Ethereum memiliki banyak pra-kompilasi yang tidak perlu rumit, jarang digunakan, dan merupakan bagian besar dari kegagalan Konsensus tanpa hampir tidak digunakan oleh aplikasi apa pun. Dua pendekatan untuk menangani masalah ini adalah (i) menghapus pra-kompilasi sepenuhnya, dan (ii) menggantinya dengan kode EVM yang menerapkan logika yang sama (yang pada akhirnya lebih mahal). Draf EIP ini menyarankan langkah pertama untuk menjalankan operasi ini pada pra-kompilasi identitas; nantinya, RIPEMD 160, MODEXP, dan BLAKE mungkin menjadi kandidat penghapusan.

· Menghapus keterlihatan gas: Membuat EVM tidak lagi dapat melihat berapa banyak gas yang tersisa. Ini akan merusak beberapa aplikasi (yang paling jelas adalah transaksi sponsor), tetapi akan lebih mudah ditingkatkan di masa depan (misalnya, untuk versi gas multidimensi yang lebih tinggi). Spesifikasi EOF telah membuat Gas tidak terlihat, tetapi untuk menyederhanakan protokol, EOF perlu menjadi wajib.

· Peningkatan analisis statis: Saat ini, sulit untuk melakukan analisis statis pada kode EVM, terutama karena lompatan dapat menjadi dinamis. Hal ini juga membuat implementasi EVM yang dioptimalkan (prekompilasi kode EVM ke bahasa lain) menjadi lebih sulit. Kita dapat memecahkan masalah ini dengan menghapus lompatan dinamis (atau membuatnya lebih mahal, misalnya biaya Gas untuk jumlah total JUMPDEST dalam kontrak bersifat linear). Ini dilakukan oleh EOF, meskipun penerapan protokol yang disederhanakan memerlukan penerapan EOF secara paksa.

Apa hubungannya dengan penelitian yang ada?

· Langkah-langkah lanjutan yang jelas;

· Merusak diri sendiri

· SSZ 化 EIPS： [ 1 ] [ 2 ] [ 3 ]；

· Perubahan biaya gas tanpa status;

Pricing memori linear;

· Penghapusan pra-kompilasi;

· filter bloom removed;

· Metode untuk melakukan pencarian log keamanan off-chain menggunakan komputasi verifikasi bertambah (dibaca: rekursif STARK);

Apa yang perlu dilakukan dan apa yang perlu dipertimbangkan?

Kompromi utama dalam melakukan penyederhanaan fungsi ini adalah (i) tingkat dan kecepatan penyederhanaan yang kami lakukan dan (ii) kompatibilitas ke belakang. Nilai Ethereum sebagai jaringan berasal dari fakta bahwa ini adalah platform di mana Anda dapat mendeploy aplikasi dan yakin bahwa itu masih akan berfungsi bertahun-tahun kemudian. Namun, idealisme ini juga bisa berjalan terlalu jauh, untuk mengutip William Jennings Bryan, ‘menyalibkan Ethereum pada salib kompatibilitas ke belakang’. Jika hanya ada dua aplikasi di seluruh Ethereum yang menggunakan fitur yang diberikan, dan satu aplikasi tidak memiliki pengguna selama bertahun-tahun sementara aplikasi lain hampir tidak digunakan dan hanya bernilai total 57 dolar, maka kita harus menghapus fitur itu dan mengganti 57 dolar kepada pihak yang terdampak jika perlu.

Masalah sosial yang lebih luas adalah menciptakan saluran standar untuk perubahan yang tidak mendesak yang merusak kompatibilitas ke belakang. Salah satu cara untuk mengatasi masalah ini adalah dengan memeriksa dan memperluas preseden yang ada, seperti proses pemusnahan diri. Saluran tersebut terlihat seperti berikut:

1. Mulai membicarakan fitur penghapusan X;

2. Melakukan analisis untuk menentukan dampak penghapusan X terhadap aplikasi, tergantung pada hasilnya: (i) membatalkan ide tersebut, (ii) melanjutkan sesuai rencana, atau (iii) menentukan metode penghapusan X yang telah dimodifikasi dengan ‘kerusakan minimal’ dan melanjutkan.

3. Menetapkan EIP resmi untuk menghentikan penggunaan X. Pastikan infrastruktur tingkat tinggi yang populer (seperti bahasa pemrograman, Dompet) menghormati hal ini dan berhenti menggunakan fitur tersebut.

4. Terakhir, hapus X secara aktual;

Antara Langkah 1 dan Langkah 4, harus ada pipa yang panjang selama bertahun-tahun dan menjelaskan dengan jelas proyek mana yang berada di langkah mana. Pada titik ini, perlu ada keseimbangan antara kecepatan dan kecepatan dalam proses penghapusan fitur dengan kehati-hatian dan penempatan lebih banyak sumber daya ke bidang pengembangan protokol lainnya, tetapi kita masih jauh dari batas Pareto.

EOF

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

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

Bagaimana interaksi dengan bagian lain dari peta jalan?

Banyak saran ‘perbaikan’ di bagian lain dari peta jalan juga merupakan kesempatan untuk menyederhanakan fungsi lama. Beberapa contoh yang sama seperti yang disebutkan di atas:

· Beralih ke finalitas slot tunggal memberi kita kesempatan untuk membatalkan komite, mendesain ulang ekonomi, dan melakukan penyederhanaan lain yang terkait dengan Proof of Stake.

· Implementasi lengkap abstraksi akun memungkinkan kami menghapus banyak logika pemrosesan transaksi yang ada dan memindahkannya ke ‘kode EVM default akun’ yang dapat digantikan oleh semua EOA.

· Jika kita memindahkan status Ethereum ke pohon hash biner, ini dapat konsisten dengan SSZ versi baru sehingga semua struktur data Ethereum dapat di-hash dengan cara yang sama.

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

Strategi sederhana yang lebih agresif untuk ETH adalah dengan mempertahankan protokol yang sama tetapi memindahkan sebagian besar fungsinya dari protokol ke kode kontrak.

Versi paling ekstrem adalah membuat ETH L1 hanya sebagai beacon chain secara ‘teknis’, dan memperkenalkan Virtual Machine minimal (misalnya RISC-V, Cairo, atau yang lebih kecil yang khusus untuk sistem bukti), memungkinkan orang lain membuat agregat mereka sendiri. Kemudian, EVM akan menjadi yang pertama dalam agregat tersebut. Ironisnya, ini sama persis dengan hasil dari proposal lingkungan pelaksanaan tahun 2019-20, meskipun SNARK membuatnya lebih layak diimplementasikan secara nyata.

Metode yang lebih lunak adalah untuk menjaga hubungan antara beacon chain dan lingkungan eksekusi ETH saat ini tetap tidak berubah, tetapi melakukan penggantian langsung terhadap EVM. Kita bisa memilih RISC-V, Cairo, atau VM lain sebagai “VM resmi ETH baru”, dan 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 diselesaikan melalui “Target Virtual Machine” sebagai versi EOF.

Tautan Asli