Masa Depan Ethereum yang Mungkin: The Purge

Penulis: Vitalik Buterin

Kompilasi: Suatu bagaimana

Terima kasih khusus kepada Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden, dan Tomasz Stanczak atas umpan balik dan tinjauan mereka.

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

Data sejarah: Semua transaksi yang dilakukan dan semua akun yang dibuat pada setiap saat dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh klien baru, sehingga sepenuhnya disinkronkan dengan jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi terus meningkat seiring 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.

Untuk menjaga Ethereum tetap bertahan dalam jangka panjang, kita perlu memberikan 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 hebat: ketahanan. Anda bisa menempatkan sebuah NFT, sebuah surat cinta dalam data panggilan transaksi, atau sebuah kontrak pintar yang berisi 1 juta dolar di atas rantai, masuk ke sebuah gua selama sepuluh tahun, dan saat keluar, Anda akan 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 - khususnya L1 itu sendiri.

Jika kita bertekad untuk menemukan keseimbangan antara kedua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan kemunduran sambil menjaga kesinambungan, itu sangat mungkin. Organisme dapat melakukan ini: meskipun sebagian besar organisme menua seiring waktu, beberapa yang beruntung tidak. Bahkan sistem sosial pun dapat memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah sukses: bukti kerja telah hilang, 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 teknis, dan bahkan keamanannya.

The Purge: Tujuan Utama.

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

Mengurangi kompleksitas protokol dengan menghapus fungsi yang tidak diperlukan.

Daftar Isi:

Kedaluwarsa riwayat（历史记录到期）

Kedaluwarsa status

Pembersihan fitur

Riwayat kedaluwarsa

Masalah apa yang diselesaikan?

Hingga penulisan artikel ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, dan juga membutuhkan ratusan GB ruang disk untuk klien konsensus. Sebagian besar adalah sejarah: data tentang blok sejarah, transaksi, dan bukti, yang sebagian besar sudah berusia 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, 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, setiap blok atau transaksi atau status sejarah (saldo akun, angka 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 memberikan banyak pilihan tentang bagaimana kita menyimpan riwayat. Salah satu pilihan yang alami adalah jaringan di mana setiap node hanya menyimpan sebagian kecil data. Inilah cara kerja jaringan seed selama beberapa dekade: meskipun jaringan secara keseluruhan menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa file di antaranya. Mungkin bertentangan dengan intuisi, metode 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% 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 semuanya.

Saat ini, Ethereum telah mulai melepaskan 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 tanda terima. Tujuan jangka panjang adalah untuk membangun periode yang seragam (mungkin sekitar 18 hari), di mana setiap node bertanggung jawab untuk menyimpan segala sesuatu, 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 menerapkan kode penghapusan untuk mendukung sampling ketersediaan data. Solusi yang paling sederhana kemungkinan adalah menggunakan kembali kode penghapusan ini, dan juga menempatkan data eksekusi dan konsensus blok 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 lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?

Pekerjaan utama yang tersisa termasuk membangun dan mengintegrasikan solusi terdistribusi konkret untuk menyimpan catatan sejarah------setidaknya catatan eksekusi, tetapi pada akhirnya juga konsensus dan blob. Solusi termudah adalah (i) cukup dengan memperkenalkan perpustakaan torrent yang sudah ada, serta (ii) yang disebut 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 secara bersamaan untuk semua klien, 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 kita berusaha menyediakan data sejarah "kuno". Solusi yang paling sederhana 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 catatan 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?

Sebuah metode ekstrem yang memperlihatkan paranoid untuk (1) akan melibatkan bukti kustodian: pada dasarnya meminta 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 simpul penyimpanan sejarah lengkap atau simpul arsip, bahkan jika tidak ada simpul arsip lain yang online, mereka dapat mencapainya 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 dibutuhkan node, sekitar 300 GB adalah status, sementara sekitar 800 GB sudah 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 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 pada tahun 2016 telah dihapus sepenuhnya. Sekarang, dengan transisi ke proof of stake yang telah menjadi sejarah, klien dapat dengan aman menghapus semua kode yang terkait dengan proof of work.

Status kedaluwarsa

Masalah apa yang diselesaikan?

Meskipun kita menghilangkan kebutuhan untuk menyimpan riwayat di klien, kebutuhan penyimpanan klien akan terus tumbuh, sekitar 50 GB per tahun, karena status yang terus berkembang: saldo akun dan angka 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 "kadaluarsa" dibandingkan sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa: setelah objek status dibuat, ia akan selalu ada dan dapat dibaca kapan saja oleh transaksi mana pun. Jika kita memperkenalkan tanpa status, ada yang berpendapat bahwa masalah ini mungkin tidak begitu buruk: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, sementara semua node lainnya (bahkan yang menghasilkan daftar!) dapat berjalan tanpa status. Namun, ada pandangan yang mengatakan bahwa kita tidak ingin terlalu bergantung pada tanpa status, dan pada akhirnya kita mungkin ingin membuat status kadaluarsa 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 sebelumnya tidak terjangkau), objek status tersebut akan tetap dalam status itu selamanya. Sebaliknya, yang kami inginkan adalah objek secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan kunci 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 gua selama lima tahun dan kembali, mereka tidak seharusnya 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 berfungsi dengan baik.

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

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

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

Masa kadaluarsa status parsial

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