Masa Depan Ethereum yang Mungkin: The Purge

Salah satu tantangan yang dihadapi Ethereum adalah bahwa, secara default, ekspansi dan kompleksitas protokol blockchain mana pun akan meningkat seiring berjalannya waktu. Ini terjadi dalam dua aspek:

Data sejarah: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada waktu tertentu dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh klien baru, 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 fitur baru jauh lebih mudah daripada menghapus fitur lama, yang menyebabkan kompleksitas kode meningkat seiring berjalannya waktu.

Untuk memastikan bahwa Ethereum dapat bertahan dalam jangka panjang, kita perlu menerapkan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan ekspansi 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 mencakup 1 juta dolar di blockchain, masuk ke dalam gua selama sepuluh tahun, dan ketika keluar, menemukan bahwa itu masih ada di sana menunggu Anda untuk membaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan aman 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, hal itu sepenuhnya mungkin. Organisme dapat melakukan hal ini: meskipun sebagian besar organisme menua seiring berjalannya waktu, beberapa yang beruntung tidak. Bahkan sistem sosial pun dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah mencapai kesuksesan: bukti kerja telah hilang, opcode SELFDESTRUCT sebagian besar telah lenyap, dan node rantai beacon telah menyimpan data lama selama maksimal 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 teknologi, bahkan keamanan.

The Purge: Tujuan utama.

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

Mengurangi kompleksitas protokol dengan menghapus fitur yang tidak diperlukan.

Daftar Isi:

History expiry（历史记录到期）

Kedaluwarsa status（状态到期）

Pembersihan fitur

Riwayat kedaluwarsa

Masalah apa yang diselesaikan?

Hingga saat penulisan artikel ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1TB ruang disk untuk menjalankan klien, ditambah lagi ratusan GB ruang disk untuk klien konsensus. Sebagian besar dari ini adalah sejarah: data tentang blok, transaksi, dan tanda terima 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, dan bagaimana cara kerjanya?

Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui hash (dan struktur lainnya), 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 individu mana pun dan dibuktikan dengan 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 dari 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 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 persis dengan faktor salinan 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 (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 bukti. Tujuan jangka panjang adalah untuk membangun periode yang seragam (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, yang menyimpan data lama dengan cara terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Faktanya, Blob telah melakukan kode penghapusan untuk mendukung sampling 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 hubungannya dengan penelitian yang ada?

EIP-4444；

Torrents dan EIP-4444；

Portal Jaringan;

Jaringan portal dan EIP-4444;

Penyimpanan dan pengambilan objek SSZ yang terdistribusi di Portal;

Bagaimana cara meningkatkan batas gas (Paradigm).

Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?

Pekerjaan utama yang tersisa mencakup membangun dan mengintegrasikan solusi distribusi konkret untuk menyimpan riwayat------setidaknya riwayat eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi paling sederhana adalah (i) cukup memperkenalkan perpustakaan torrent yang ada, serta (ii) solusi asli Ethereum yang disebut 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, sangat berharga untuk mengaktifkannya untuk semua klien sekaligus, jika tidak, ada risiko klien gagal karena terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak diperoleh.

Pertimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah menghentikan penyimpanan sejarah kuno mulai besok dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk melakukan replikasi. Ini mudah, tetapi ini memperlemah posisi Ethereum sebagai tempat catatan permanen. Jalur yang lebih sulit tetapi lebih aman adalah terlebih dahulu membangun dan mengintegrasikan jaringan torrent untuk menyimpan catatan 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?

Sebuah metode ekstrem yang sangat paranoid untuk (1) akan melibatkan bukti penjagaan: pada kenyataannya, mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa dengan cara terenkripsi 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 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 node penyimpanan sejarah lengkap atau node arsip, bahkan jika tidak ada node arsip lain yang online, mereka dapat mencapainya dengan melakukan sinkronisasi langsung dari jaringan portal.

Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?

Jika kita ingin membuat pengoperasian atau peluncuran 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 sisanya telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya membutuhkan beberapa menit untuk mengaturnya dapat terwujud.

Pembatasan penyimpanan sejarah juga membuat implementasi 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. Sekarang bahwa peralihan ke proof of stake telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan proof of work.

Kedaluwarsa negara

Masalah apa yang diselesaikan?

Meskipun kami telah 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 bayar, sehingga membebani klien Ethereum saat ini dan di masa depan selamanya.

Status lebih sulit "kedaluwarsa" daripada sejarah, karena EVM pada dasarnya dirancang di sekitar asumsi bahwa: 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 begitu buruk: hanya kelas pembangun blok khusus yang perlu menyimpan status secara nyata, sementara semua node lainnya (termasuk yang menghasilkan 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 (ini 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 selalu berada dalam keadaan itu. Sebaliknya, yang kami inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan kunci adalah melakukan ini 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 ETH, ERC20, NFT, posisi CDP...

Keterpakaian bagi Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sama sekali tidak familiar. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui seharusnya dapat terus berfungsi dengan baik.

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 Ether, yang mungkin secara otomatis terjadi kapan saja saat dibaca atau ditulis), dan memiliki proses yang mengulangi status untuk menghapus objek status dengan tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan itu pasti tidak dapat memenuhi persyaratan kemudahan penggunaan. Para pengembang juga sulit untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset menjadi nol. Jika Anda mengatur penghitung waktu kedaluwarsa dalam ruang lingkup kontrak, secara teknis itu akan membuat hidup pengembang lebih mudah, tetapi itu akan membuat ekonomi menjadi lebih sulit: pengembang harus mempertimbangkan bagaimana "meneruskan" biaya penyimpanan yang terus-menerus kepada pengguna.

Semua ini 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 kategori "solusi yang paling tidak buruk yang diketahui":

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

Kadaluarsa status parsial

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

Perbedaan utama antara proposal ini adalah: (i) bagaimana kita mendefinisikan "baru-baru ini", dan (ii) bagaimana kita