Masa Depan Potensial Ethereum: The Purge

Penulis: Vitalik Buterin

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 mana pun dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh klien baru mana pun, sehingga sepenuhnya disinkronkan ke jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi meningkat seiring berjalannya waktu, bahkan jika kapasitas rantai tetap sama.

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

Untuk memastikan bahwa Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan pembengkakan seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu menjaga salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda dapat menempatkan NFT, sebuah surat cinta dalam data panggilan transaksi, atau kontrak pintar yang berisi 1 juta dolar di blockchain, masuk ke sebuah gua selama sepuluh tahun, dan saat keluar, menemukan bahwa itu masih ada menunggu Anda untuk dibaca dan diinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan nyaman dan menghapus kunci pembaruan, 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, itu sangat mungkin. Organisme dapat melakukan hal ini: meskipun sebagian besar organisme menua seiring berjalannya waktu, beberapa yang beruntung tidak. Bahkan sistem sosial dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah mencapai keberhasilan: bukti kerja telah menghilang, opcode SELFDESTRUCT sebagian besar telah menghilang, dan node rantai beacon telah menyimpan data lama selama maksimum enam bulan. Menemukan jalan ini untuk Ethereum dengan cara yang lebih umum dan menuju hasil akhir yang stabil dalam jangka panjang adalah tantangan utama untuk skalabilitas jangka panjang Ethereum, keberlanjutan teknologi, bahkan keamanan.

The Purge: Tujuan utama.

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

Mengurangi kompleksitas protokol dengan menghapus fungsi yang tidak diperlukan.

Daftar Isi:

History expiry（历史记录到期）

Kedaluwarsa status

Pembersihan fitur

Riwayat 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, ditambah lagi ratusan GB ruang disk untuk klien konsensus. Sebagian besar adalah sejarah: data tentang blok, transaksi, dan bukti sejarah, yang sebagian besar sudah berumur beberapa tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat ratusan GB setiap tahun.

Apa itu, dan bagaimana cara kerjanya?

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

Ini memberikan banyak pilihan tentang bagaimana kita 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 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 beroperasi lebih ekonomis, kita dapat membangun jaringan dengan 100.000 node, di mana setiap node menyimpan 10% riwayat secara acak, maka setiap data akan disalin 10.000 kali - sama dengan faktor duplikasi dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.

Saat ini, Ethereum telah mulai melepaskan model di mana semua node menyimpan semua riwayat secara permanen. Blok konsensus (yaitu bagian yang 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 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 yang menyimpan data lama dengan cara terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Faktanya, Blob telah menggunakan kode penghapusan untuk mendukung pengambilan ketersediaan data. Solusi yang paling sederhana kemungkinan adalah dengan 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；

Portal jaringan;

Portal jaringan dan EIP-4444;

Penyimpanan dan pengambilan terdistribusi objek SSZ di Portal;

Bagaimana cara meningkatkan batas gas (Paradigm).

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 sudah 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 membutuhkan versi protokol jaringan baru. Oleh karena itu, mengaktifkannya untuk semua klien secara bersamaan adalah penting, 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 yang paling sederhana adalah menghentikan penyimpanan 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. Jalur yang lebih sulit tetapi lebih aman adalah pertama-tama membangun dan mengintegrasikan jaringan torrent untuk menyimpan sejarah 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?

Salah satu metode ekstrem untuk (1) akan melibatkan bukti kepemilikan: secara praktis meminta setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa dengan cara yang terenkripsi apakah mereka melakukan hal tersebut. Metode yang lebih ringan adalah menetapkan standar sukarela untuk persentase sejarah yang disimpan oleh setiap klien.

Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan 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 simpul penyimpanan sejarah lengkap atau simpul arsip, bahkan jika tidak ada simpul arsip lain yang online, mereka 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 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 mewujudkan tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya membutuhkan beberapa menit untuk diatur dapat dicapai.

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 tahun 2016 telah dihapus semuanya. Sekarang, dengan peralihan ke bukti kepemilikan menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan bukti kerja.

Masa berlaku negara

Masalah apa yang diselesaikan?

Meskipun kita telah menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus meningkat, sekitar 50 GB setiap tahun, karena status terus tumbuh: saldo akun dan nomor acak, kode kontrak dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum sekarang dan di masa depan selamanya.

Status lebih sulit "kadaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang berdasarkan asumsi bahwa begitu objek status dibuat, objek tersebut akan selalu ada dan dapat dibaca oleh transaksi kapan saja. Jika kita memperkenalkan tanpa status, ada yang berpendapat bahwa masalah ini mungkin tidak seburuk itu: hanya kelas pembangun blok khusus yang perlu menyimpan status secara nyata, sementara semua node lainnya (bahkan yang mencakup pembuatan daftar!) dapat beroperasi tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, dan pada akhirnya kita mungkin ingin membuat status kadaluwarsa untuk menjaga desentralisasi Ethereum.

Apa itu, dan bagaimana cara kerjanya

Hari ini, ketika Anda membuat objek status baru (yang 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 tersentuh), objek status tersebut akan selamanya berada dalam status itu. Sebaliknya, yang kita inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan utama adalah melakukan ini dengan cara yang memenuhi tiga tujuan:

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 untuk 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 berjalan dengan normal.

Tidak memenuhi tujuan ini membuatnya 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 yang melakukan iterasi melalui status untuk menghapus objek status dengan tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan pasti tidak dapat memenuhi persyaratan kemudahan penggunaan. Pengembang juga kesulitan untuk menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam ruang lingkup kontrak, secara teknis ini akan membuat hidup pengembang menjadi lebih mudah, tetapi akan membuat ekonomi menjadi lebih rumit: 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 tersebut dan fokus pada dua kategori "solusi yang paling tidak buruk yang diketahui":

• Solusi untuk status yang kadaluarsa
• Saran kedaluwarsa status berdasarkan siklus alamat.

Kedaluwarsa status sebagian

Beberapa proposal status yang kedaluwarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang menyimpan "peta 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 "resurrect" yang akan aktif jika tidak lagi disimpan.

Perbedaan utama antara proposal-proposal ini adalah: (i) kami seperti