Masa Depan Ethereum yang Mungkin: The Purge

Salah satu tantangan yang dihadapi Ethereum adalah, secara default, ekspansi dan kompleksitas dari protokol blockchain mana pun akan meningkat seiring waktu. Ini terjadi di dua tempat:

Data historis: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada waktu mana pun dalam sejarah perlu disimpan secara permanen oleh semua klien, dan diunduh oleh klien baru mana pun, sehingga sepenuhnya disinkronkan dengan jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi meningkat seiring waktu, bahkan jika kapasitas rantai tetap sama.

Fungsi protokol: Menambahkan fitur baru jauh lebih mudah daripada menghapus fitur lama, yang mengakibatkan kompleksitas kode meningkat seiring waktu.

Untuk memastikan Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap dua tren ini, mengurangi kompleksitas dan pembengkakan seiring waktu. Namun, pada saat yang sama, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda dapat menempatkan NFT, surat cinta dalam data panggilan transaksi, atau kontrak pintar yang berisi 1 juta dolar di dalam rantai, masuk ke sebuah gua selama sepuluh tahun, dan saat keluar menemukan bahwa itu masih ada menunggu Anda untuk dibaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan tenang dan menghapus kunci upgrade, mereka perlu yakin bahwa ketergantungan mereka tidak akan diupgrade dengan cara yang merusak mereka - terutama L1 itu sendiri.

Jika kita bertekad untuk mencapai keseimbangan antara kedua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan penurunan sambil menjaga kontinuitas, itu benar-benar mungkin. Organisme dapat melakukan ini: meskipun sebagian besar organisme menua seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja telah menghilang, opcode SELFDESTRUCT sebagian besar telah hilang, dan node beacon chain telah menyimpan data lama hingga enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum, dan bergerak menuju hasil akhir yang stabil dalam jangka panjang, adalah tantangan utama untuk skalabilitas jangka panjang Ethereum, keberlanjutan teknis, dan bahkan keamanannya.

The Purge: Tujuan utama.

Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan setiap node untuk secara permanen menyimpan semua riwayat bahkan status akhir.

Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak diperlukan.

Daftar isi:

Kedaluwarsa sejarah

Kedaluwarsa negara

Pembersihan fitur

Kedaluwarsa sejarah

Memecahkan masalah apa?

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

Apa itu, dan bagaimana cara kerjanya?

Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung dengan hash ( dan struktur lainnya ) menunjuk ke blok sebelumnya, maka konsensus saat ini sudah cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, setiap blok sejarah atau transaksi atau status ( saldo akun, angka acak, kode, penyimpanan ) dapat disediakan oleh peserta tunggal mana pun serta 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 banyak pilihan tentang bagaimana kita 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, pendekatan ini bahkan tidak selalu mengurangi ketahanan data. Jika dengan membuat node 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 persis dengan faktor penggandaan jaringan 10.000 node, di mana setiap node menyimpan semuanya.

Saat ini, Ethereum telah mulai menghindari model di mana semua node menyimpan semua riwayat secara permanen. Blok konsensus ( terkait dengan bagian konsensus proof-of-stake 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 terpadu ) yang mungkin sekitar 18 hari (, di mana setiap node bertanggung jawab untuk menyimpan semua konten, dan kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum untuk menyimpan data lama dengan cara terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor replikasi yang sama. Faktanya, Blob sudah menggunakan kode penghapusan untuk mendukung sampling ketersediaan data. Solusi yang paling sederhana kemungkinan besar adalah menggunakan kembali kode penghapusan ini, dan juga menempatkan data eksekusi dan konsensus blok ke dalam blob.

) memiliki hubungan 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 cara meningkatkan batas gas.

apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Pekerjaan utama yang tersisa mencakup membangun dan mengintegrasikan solusi terdistribusi konkret untuk menyimpan catatan sejarah------setidaknya catatan eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi paling sederhana adalah ###i( dengan sederhana memperkenalkan pustaka torrent yang ada, serta )ii( yang disebut solusi asli Ethereum yang bernama Portal Network. Setelah salah satu dari ini diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 itu sendiri tidak memerlukan hard fork, tetapi memang membutuhkan versi protokol jaringan 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 catatan sejarah lengkap tetapi sebenarnya tidak mendapatkannya.

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

Bagaimana kita berusaha memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?

Seberapa dalam integrasi penyimpanan sejarah ke dalam protokol?

Sebuah metode ekstrem yang sangat paranoid untuk ) akan melibatkan bukti kustodian: pada dasarnya meminta 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 sudah selesai hari ini: Portal sudah 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, meskipun tidak ada node arsip lain yang online, mereka masih dapat melakukannya 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 dapat dikatakan lebih penting daripada tanpa status: dari 1,1 TB yang dibutuhkan node, sekitar 300 GB adalah status, sisanya sekitar 800 GB menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya membutuhkan beberapa menit untuk diatur dapat terwujud.

Pembatasan penyimpanan sejarah juga membuat node Ethereum yang lebih baru menjadi lebih layak, 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 semua. Karena 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###

Kadaluarsa negara

( Memecahkan masalah apa?

Meskipun kita menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus tumbuh, sekitar 50 GB per tahun, karena status yang terus meningkat: saldo akun dan nomor acak, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali untuk membebankan ini kepada klien Ethereum sekarang dan di masa depan.

Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang berdasarkan asumsi bahwa: begitu objek status dibuat, ia akan selalu ada dan dapat dibaca kapan saja oleh transaksi mana pun. 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 pembuatan daftar! ### dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, 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 melalui salah satu dari tiga cara berikut: ###i ( mengirim ETH ke akun baru, (ii ) membuat akun baru menggunakan kode, (iii ) mengatur slot penyimpanan yang belum pernah disentuh sebelumnya (, objek status tersebut akan tetap dalam keadaan itu selamanya. Sebaliknya, yang kita inginkan adalah objek yang secara otomatis kadaluarsa seiring berjalannya waktu. Tantangan kunci adalah untuk melakukan ini dengan cara yang mencapai tiga tujuan tersebut:

Efisiensi: Tidak memerlukan banyak perhitungan tambahan untuk menjalankan proses kedaluwarsa.

Keterpakaian pengguna: Jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka seharusnya tidak kehilangan akses ke posisi ETH, ERC20, NFT, dan CDP...

Keterpahaman bagi pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak familiar. Selain itu, aplikasi yang saat ini sudah kaku dan tidak diperbarui seharusnya dapat terus berjalan dengan normal.

Tidak memenuhi tujuan-tujuan ini akan dengan mudah menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa ) yang dapat diperpanjang dengan membakar ETH, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis ), dan memiliki proses yang melintasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan perhitungan tambahan ( bahkan kebutuhan penyimpanan ), dan jelas tidak dapat memenuhi persyaratan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset ke nol. Jika Anda mengatur penghitung kedaluwarsa dalam lingkup kontrak, ini secara teknis akan membuat hidup pengembang lebih mudah, tetapi akan membuat ekonomi menjadi lebih sulit: pengembang harus mempertimbangkan bagaimana "mengalihkan" biaya penyimpanan yang berkelanjutan kepada pengguna.

Ini semua adalah masalah yang telah diupayakan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "regenerasi". Akhirnya, kami menggabungkan bagian terbaik dari proposal dan fokus pada dua jenis "solusi yang diketahui paling tidak buruk":

• Solusi untuk status yang sebagian kadaluwarsa
• 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 "peta teratas" secara permanen, di mana blok kosong atau tidak kosong. Data dalam setiap blok hanya akan disimpan jika data tersebut baru-baru ini diakses. Ada suatu "