Masa Depan Ethereum yang Mungkin: The Purge

Salah satu tantangan yang dihadapi Ethereum adalah, secara default, ekspansi dan kompleksitas dari setiap protokol blockchain akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek: data historis dan fungsi protokol. Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan ekspansi seiring waktu. Tetapi pada saat yang sama, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: keberlanjutan.

Tujuan utama The Purge adalah:

• Mengurangi atau menghilangkan kebutuhan untuk setiap node menyimpan secara permanen semua catatan sejarah bahkan status akhir untuk mengurangi persyaratan penyimpanan klien.
• Mengurangi kompleksitas protokol dengan menghilangkan fitur yang tidak diperlukan.

Ekspirasi sejarah

Apa masalah yang diselesaikan?

Hingga saat penulisan ini, node Ethereum yang sepenuhnya disinkronkan membutuhkan sekitar 1,1 TB ruang disk untuk menjalankan klien, dan masih membutuhkan ratusan GB ruang disk untuk klien konsensus. Sebagian besar dari ini adalah sejarah: data tentang blok, transaksi, dan bukti sejarah, sebagian besar sudah berusia bertahun-tahun. Ini berarti bahwa bahkan jika batas Gas tidak bertambah sama sekali, ukuran node akan terus meningkat ratusan GB setiap tahun.

Apa itu, dan bagaimana cara kerjanya?

Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung melalui hash ( dan struktur lainnya ) yang menunjuk ke blok sebelumnya, maka konsensus yang dicapai saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok sejarah, transaksi, atau status ( saldo akun, angka acak, kode, penyimpanan ) dapat disediakan oleh peserta tunggal mana pun bersama dengan bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-of-N, sedangkan sejarah adalah model kepercayaan N-of-N.

Ini memberikan kita banyak pilihan tentang bagaimana menyimpan catatan sejarah. Salah satu pilihan alami adalah jaringan di mana setiap node hanya menyimpan sebagian kecil data. Inilah cara kerja jaringan benih selama beberapa dekade: meskipun jaringan secara total menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, metode ini bahkan tidak harus mengurangi ketahanan data. Jika dengan membuat node berjalan lebih ekonomis, 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 dari jaringan 10.000 node, di mana setiap node menyimpan segala sesuatu.

Saat ini, Ethereum telah mulai menghindari model di mana semua node menyimpan semua sejarah secara permanen. Blok konsensus ( terkait dengan konsensus bukti kepemilikan hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok sejarah dan tanda terima. Tujuan jangka panjang adalah untuk membangun periode seragam ) yang 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 yang menyimpan data lama dengan cara terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil menjaga faktor replikasi tetap sama. Sebenarnya, Blob sudah menerapkan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan adalah menggunakan kembali kode penghapusan ini, dan menempatkan data eksekusi dan konsensus blok juga ke dalam blob.

![Vitalik: Masa Depan Ethereum yang Mungkin, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(

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

Pekerjaan utama yang tersisa termasuk membangun dan mengintegrasikan solusi terdistribusi konkret untuk menyimpan riwayat------setidaknya riwayat eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi termudah adalah ###i( secara sederhana memperkenalkan pustaka torrent yang ada, serta )ii( yang disebut solusi asli Ethereum Portal Network. Setelah salah satu dari ini diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 itu sendiri tidak memerlukan hard fork, tetapi memang memerlukan versi protokol jaringan yang baru. Oleh karena itu, mengaktifkannya untuk semua klien secara bersamaan adalah berharga, jika tidak, ada risiko klien gagal karena terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak mendapatkannya.

Pertimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah berhenti menyimpan sejarah kuno besok, dan bergantung pada node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi ini melemahkan posisi Ethereum sebagai tempat catatan permanen. Jalur yang lebih sulit tetapi lebih aman adalah membangun dan mengintegrasikan jaringan torrent terlebih dahulu, untuk menyimpan sejarah secara terdistribusi. Di sini, "seberapa keras kita berusaha" memiliki dua dimensi:

• Bagaimana kami berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?
• Seberapa dalam integrasi penyimpanan sejarah ke dalam protokol?

Metode ekstrem obsesif untuk ) akan melibatkan bukti kustodian: pada dasarnya mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa secara kriptografis apakah mereka melakukannya. Metode yang lebih lembut adalah menetapkan standar sukarela untuk persentase sejarah yang disimpan oleh setiap klien.

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

( Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?

Jika kita ingin membuat menjalankan atau memulai node menjadi sangat mudah, maka mengurangi kebutuhan penyimpanan sejarah bisa dibilang lebih penting daripada tanpa status: dari 1,1 TB yang diperlukan node, sekitar 300 GB adalah status, dan sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya memerlukan beberapa menit untuk pengaturannya dapat terwujud.

Pembatasan penyimpanan sejarah juga membuat node Ethereum yang lebih baru menjadi lebih praktis, hanya mendukung versi terbaru dari protokol, yang membuatnya menjadi lebih sederhana. Misalnya, sekarang banyak baris kode dapat dihapus dengan aman, karena slot penyimpanan kosong yang dibuat selama serangan DoS pada tahun 2016 telah dihapus sepenuhnya. Mengingat bahwa peralihan ke bukti kepemilikan telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan bukti kerja.

![Vitalik: Masa Depan Potensial Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###

Masa kedaluwarsa negara

( Apa masalah yang diselesaikan?

Bahkan jika kami menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus meningkat, sekitar 50 GB per tahun, karena status terus tumbuh: saldo akun dan angka acak, kode kontrak dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum saat ini dan di masa depan selamanya.

Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang di sekitar asumsi ini: setelah objek status dibuat, itu akan selalu ada, dan dapat dibaca oleh transaksi kapan saja. Jika kita memperkenalkan tanpa status, beberapa orang berpendapat bahwa masalah ini mungkin tidak seburuk itu: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, sementara semua node lainnya ) bahkan termasuk daftar yang dihasilkan! ### dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, dan pada akhirnya kita mungkin ingin membuat status kedaluwarsa untuk menjaga desentralisasi Ethereum.

( Apa itu, bagaimana cara kerjanya

Hari ini, ketika Anda membuat objek status baru, ) dapat terjadi dengan salah satu dari tiga cara berikut: ###i ( mengirim ETH ke akun baru, (ii ) menggunakan kode untuk membuat akun baru, (iii ) mengatur slot penyimpanan yang belum pernah diakses sebelumnya (, objek status tersebut akan selalu dalam keadaan itu. Sebaliknya, yang kita inginkan adalah objek tersebut kedaluwarsa secara otomatis seiring berjalannya waktu. Tantangan kunci adalah melakukannya dengan cara yang mencapai tiga tujuan.

• Efisiensi: Tidak memerlukan banyak perhitungan tambahan untuk menjalankan proses kedaluwarsa.
• Kemudahan Pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka seharusnya tidak kehilangan akses ke posisi ETH, ERC20, NFT, CDP...
• Ramah bagi pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui seharusnya dapat terus beroperasi dengan normal.

Tidak memenuhi tujuan ini sangat mudah untuk menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa. ) dapat diperpanjang dengan membakar ETH, dan ini dapat terjadi secara otomatis kapan saja saat dibaca atau ditulis ), dan ada proses yang mengiterasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan komputasi tambahan ( bahkan kebutuhan penyimpanan ), dan itu pasti tidak dapat memenuhi persyaratan kemudahan penggunaan. Para pengembang juga kesulitan dalam menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam jangkauan kontrak, ini secara teknis akan memudahkan hidup pengembang, tetapi akan membuat ekonomi menjadi lebih sulit: pengembang harus mempertimbangkan bagaimana "meneruskan" biaya penyimpanan yang berkelanjutan kepada pengguna.

Semua ini adalah masalah yang telah diupayakan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "regenerasi". Pada akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":

• Solusi status kadaluarsa sebagian
• Saran kedaluwarsa status berdasarkan siklus alamat.

(# Kedaluwarsa sebagian status

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

Perbedaan utama antara proposal-proposal ini adalah: )i### bagaimana kita mendefinisikan "terbaru", dan (ii) bagaimana kita mendefinisikan "blok"? Salah satu proposal konkret adalah EIP-7736, yang dibangun di atas desain "cabang" yang diperkenalkan untuk pohon Verkle ( meskipun kompatibel dengan bentuk status tanpa negara apa pun, seperti pohon biner ). Dalam desain ini, header, kode, dan slot penyimpanan yang berdekatan satu sama lain disimpan di bawah "batang" yang sama. Data yang disimpan di bawah satu cabang dapat mencapai maksimum 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun serta banyak slot penyimpanan kunci akan disimpan di bawah batang yang sama. Jika data di bawah batang tertentu tidak dibaca atau ditulis dalam waktu 6 bulan, maka data tersebut tidak lagi disimpan, melainkan hanya komitmen 32 byte dari data tersebut ("stub"). Transaksi yang mengakses data tersebut di masa depan akan memerlukan "menghidupkan kembali" data, dan menyediakan bukti untuk memverifikasi berdasarkan stub.

Ada metode lain untuk mencapai ide serupa. Misalnya, jika granularitas tingkat akun tidak cukup, kita dapat merancang skema di mana setiap 1/232 bagian dari pohon dikendalikan oleh mekanisme batang dan daun yang serupa.

Karena faktor insentif, ini menjadi lebih rumit: penyerang dapat "memperbarui pohon" dengan memasukkan sejumlah besar data ke dalam satu subpohon dan mengirimkan satu transaksi setiap tahun, sehingga memaksa klien untuk menyimpan sejumlah besar status secara permanen. Jika Anda membuat biaya perpanjangan sebanding dengan ukuran pohon ( atau berbanding terbalik dengan durasi perpanjangan ), maka seseorang mungkin dapat merugikan pengguna lain dengan memasukkan sejumlah besar data ke dalam subpohon yang sama dengan mereka. Orang dapat mencoba membatasi kedua masalah ini dengan mendinamiskan granularitas berdasarkan ukuran subpohon: misalnya, setiap 216= 65536 objek status yang berurutan dapat dianggap sebagai satu "kelompok". Namun, ide-ide ini lebih kompleks; pendekatan berbasis batang cukup sederhana, dan insentif dapat disesuaikan, karena biasanya di bawah batang.