Vitalik: Masa Depan Potensial Ethereum, The Purge

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

Data sejarah: Setiap transaksi dan akun yang dibuat pada setiap momen 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 tidak berubah.

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

Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu menerapkan tekanan balik yang kuat terhadap kedua 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: ketahanan. Anda dapat menempatkan NFT, surat cinta dalam data panggilan transaksi, atau kontrak pintar senilai 1 juta dolar di blockchain, masuk ke dalam gua selama sepuluh tahun, dan saat keluar, menemukannya masih ada menunggu Anda untuk dibaca dan diinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan aman dan menghapus kunci upgrade, 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 pasti 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 mencapai keberhasilan: 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 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:

History expiry（历史记录到期）

Kedaluwarsa status（状态到期）

Pembersihan fitur

Kadaluarsa sejarah

Menyelesaikan masalah apa?

Hingga saat penulisan 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 dari itu adalah sejarah: data tentang blok sejarah, transaksi, dan bukti, 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 fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui tautan hash (dan struktur lainnya), cukup untuk mencapai konsensus saat ini untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, 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, 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 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 kita dapat membangun jaringan dengan 100.000 node yang menyimpan 10% catatan sejarah secara acak dengan membuat node beroperasi lebih ekonomis, maka setiap data akan disalin 10.000 kali - sama dengan faktor salinan dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.

Saat ini, Ethereum telah mulai melepaskan model penyimpanan permanen semua sejarah oleh semua node. Blok konsensus (yaitu bagian yang terkait dengan 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 dan kuitansi sejarah. Tujuan jangka panjang adalah untuk membangun periode yang seragam (mungkin sekitar 18 hari), di mana setiap node bertanggung jawab untuk menyimpan semua konten, lalu 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 replikasi yang sama. Sebenarnya, Blob sudah menggunakan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan 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；

Portal Jaringan;

Jaringan portal 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 meliputi membangun dan mengintegrasikan solusi terdistribusi spesifik untuk menyimpan catatan sejarah ------ setidaknya catatan eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi termudah adalah (i) dengan sederhana memperkenalkan perpustakaan torrent yang sudah 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 memerlukan 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 diperoleh.

Pertimbangan utama melibatkan bagaimana kami berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah menghentikan penyimpanan sejarah kuno besok dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk 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 sejarah secara terdistribusi. Di sini, "seberapa keras kami berusaha" memiliki dua dimensi:

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

Seberapa dalam integrasi penyimpanan historis ke dalam protokol?

Salah satu metode ekstrem untuk (1) akan melibatkan bukti kustodian: pada kenyataannya, mengharuskan setiap validator proof-of-stake untuk menyimpan proporsi tertentu dari riwayat dan secara berkala memeriksa secara kriptografis apakah mereka melakukannya. Metode yang lebih ringan adalah menetapkan standar sukarela untuk persentase riwayat yang disimpan oleh setiap klien.

Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang telah diselesaikan hari ini: Portal telah menyimpan file ERA yang berisi 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 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, dan sekitar 800 GB yang tersisa 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 mengaturnya dapat terwujud.

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

Kedaluwarsa status

Apa masalah yang diselesaikan?

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

Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa setelah objek status dibuat, itu 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 begitu buruk: hanya kelas pembangun blok khusus yang perlu menyimpan status secara nyata, sementara semua node lainnya (bahkan yang mencakup pembuatan daftar!) 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, dan bagaimana cara kerjanya

Hari ini, ketika Anda membuat objek status baru (yang dapat terjadi dengan 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 diakses sebelumnya), objek status tersebut akan selamanya berada dalam status tersebut. Sebaliknya, yang kami inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring waktu. Tantangan kunci adalah melakukan hal itu dengan cara yang mencapai tiga tujuan:

Efisiensi: Tidak perlu perhitungan tambahan yang besar untuk menjalankan proses kedaluwarsa.

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

Keterpaduan untuk Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak dikenal. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui seharusnya tetap dapat berjalan dengan normal.

Tidak memenuhi tujuan-tujuan ini membuatnya mudah untuk menyelesaikan masalah. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (yang dapat diperpanjang dengan membakar Ether, yang mungkin terjadi secara otomatis saat membaca atau menulis kapan saja), dan memiliki proses yang berulang kali menjelajahi status untuk menghapus objek status dengan tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan pasti tidak akan memenuhi persyaratan ramah pengguna. Pengembang juga sulit untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam ruang lingkup kontrak, ini secara teknis akan memudahkan hidup pengembang, 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 usulan seperti "sewa blockchain" dan "regenerasi". Akhirnya, kami menggabungkan bagian terbaik dari usulan tersebut dan fokus pada dua kategori "solusi yang diketahui paling tidak buruk":

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

Kadaluarsa sebagian status

Beberapa proposal status yang kedaluwarsa mengikuti prinsip yang sama. Kami membagi status menjadi blok. Setiap orang menyimpan "peta teratas" secara permanen,