Masa Depan Potensial Ethereum: The Purge

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

Data historis: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada waktu sejarah mana pun 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 terus meningkat seiring berjalannya waktu, bahkan jika kapasitas rantai tetap tidak berubah.

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

Untuk memastikan Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap dua tren ini, mengurangi kompleksitas dan ekspansi seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: keberlanjutan. Anda dapat menempatkan NFT, surat cinta dalam data panggilan transaksi, atau kontrak pintar yang berisi 1 juta dolar di rantai, masuk ke dalam gua selama sepuluh tahun, dan saat keluar, menemukan bahwa itu masih ada menunggu Anda untuk membaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan aman dan menghapus kunci peningkatan, mereka perlu yakin bahwa ketergantungan mereka tidak akan diperbarui 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 mempertahankan kontinuitas, hal ini sangat mungkin dilakukan. Organisme dapat melakukan ini: meskipun sebagian besar organisme akan menua seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial juga dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah berhasil: bukti kerja telah menghilang, opcode SELFDESTRUCT sebagian besar telah menghilang, dan node rantai beacon 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 keamanan.

The Purge: Tujuan Utama.

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

Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak diperlukan.

Daftar Isi:

Sejarah kadaluarsa(catatan sejarah kadaluarsa)

Status kadaluwarsa(状态到期)

Pembersihan fitur(特征清理)

Sejarah kedaluwarsa

Apa masalah yang dipecahkan?

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

Apa itu, bagaimana cara kerjanya?

Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung secara hash ( dan struktur lainnya ) menunjuk ke blok sebelumnya, maka konsensus saat ini cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, setiap blok sejarah atau transaksi atau status ( saldo akun, nomor acak, kode, penyimpanan ) dapat disediakan oleh peserta individu 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 memberi kita banyak pilihan tentang bagaimana menyimpan catatan sejarah. Salah satu pilihan yang alami adalah jaringan di mana setiap node hanya menyimpan sebagian kecil data. Inilah cara kerja jaringan benih selama beberapa dekade: meskipun jaringan menyimpan dan mendistribusikan jutaan file secara total, 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 dengan faktor penggandaan dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.

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

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

)# Apa 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 ### Paradigm (.

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

Pekerjaan utama yang tersisa termasuk membangun dan mengintegrasikan solusi terdistribusi spesifik untuk menyimpan catatan sejarah ------ setidaknya catatan eksekusi, tetapi akhirnya juga termasuk konsensus dan blob. Solusi yang paling sederhana adalah ###i( sederhana dengan memperkenalkan pustaka torrent yang sudah ada, serta )ii( yang disebut solusi asli Ethereum bernama Portal Network. Setelah memperkenalkan salah satu dari keduanya, kita bisa membuka EIP-4444. EIP-4444 itu sendiri tidak memerlukan hard fork, tetapi memang memerlukan versi protokol jaringan baru. Oleh karena itu, mengaktifkannya secara bersamaan untuk semua klien adalah penting, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh catatan sejarah lengkap tetapi sebenarnya tidak mendapatkan.

Pertimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah menghentikan penyimpanan sejarah kuno besok, dan mengandalkan node arsip yang ada dan 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 kami berusaha untuk memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?

Seberapa dalam integrasi penyimpanan sejarah ke dalam protokol?

Sebuah metode ekstrem yang paranoid untuk ) akan melibatkan bukti penahanan: secara praktis mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan historis, dan secara berkala memverifikasi secara kriptografis apakah mereka melakukannya. Metode yang lebih lunak 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 berisi seluruh sejarah Ethereum. Implementasi yang lebih menyeluruh akan melibatkan menghubungkannya secara nyata ke proses sinkronisasi, sehingga, jika ada yang ingin menyinkronkan node penyimpanan sejarah lengkap atau node arsip, bahkan jika tidak ada node arsip lain yang online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.

(# Bagaimana itu 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 dibutuhkan node, sekitar 300 GB adalah status, sisa sekitar 800 GB telah menjadi sejarah. Hanya dengan mewujudkan tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya membutuhkan beberapa menit untuk disiapkan dapat tercapai.

Pembatasan penyimpanan sejarah juga membuat implementasi 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 sepenuhnya. Mengingat transisi ke bukti kepemilikan telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan bukti kerja.

) Status kedaluwarsa

Apa masalah yang diselesaikan?

Bahkan jika kita menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus tumbuh, sekitar 50 GB setiap tahun, karena status terus meningkat: saldo akun dan nonce, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya satu kali, sehingga membebani klien Ethereum sekarang dan di masa depan selamanya.

Status lebih sulit "kadaluarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang berdasarkan asumsi ini: setelah 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 menyimpan status secara nyata, 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 kadaluarsa untuk mempertahankan 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 sebelumnya tidak terjamah (, objek status tersebut akan selalu dalam keadaan tersebut. Sebaliknya, yang kita inginkan adalah objek yang kedaluwarsa secara otomatis seiring berjalannya waktu. Tantangan utama adalah melakukan ini dengan cara yang mencapai tiga tujuan.

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

Kemudahan penggunaan: Jika seseorang masuk ke 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 kaku dan tidak diperbarui harus dapat terus berfungsi dengan normal.

Tidak memenuhi tujuan ini sangat mudah untuk 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 untuk mengiterasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan komputasi tambahan bahkan kebutuhan penyimpanan, dan itu pasti tidak dapat memenuhi persyaratan ramah pengguna. Para pengembang juga kesulitan untuk menyimpulkan kondisi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda menetapkan 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 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 dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":

• Solusi status yang sebagian kedaluwarsa
• Saran masa berlaku status berdasarkan siklus alamat.

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

(# Kadaluarsa status parsial

Beberapa proposal status yang berakhir mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang menyimpan "peta teratas" secara permanen, di mana blok bisa kosong atau tidak kosong. Hanya ketika paling