Vitalik: Masa Depan Potensial Ethereum, The Purge

Salah satu tantangan yang dihadapi Ethereum adalah bahwa, secara default, pembengkakan dan kompleksitas 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 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.

Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan kuat terhadap kedua tren ini, menurunkan kompleksitas dan ekspansi seiring berjalannya waktu. Namun demikian, kita perlu mempertahankan salah satu atribut kunci yang membuat blockchain menjadi hebat: ketahanan. Anda bisa menaruh NFT, sebuah surat cinta dalam data panggilan transaksi, atau sebuah kontrak pintar yang berisi 1 juta dolar di dalam 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 mencapai keseimbangan antara kedua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan kemunduran sambil mempertahankan kontinuitas, hal ini sangat mungkin dilakukan. Organisme dapat melakukan hal ini: meskipun sebagian besar organisme akan menua seiring waktu, beberapa yang beruntung tidak akan. Bahkan sistem sosial 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 teknologi, 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 keadaan akhir.

Mengurangi kompleksitas protokol dengan menghapus fungsi yang tidak diperlukan.

Daftar Isi:

History expiry（历史记录到期）

Kedaluwarsa status（状态到期）

Pembersihan fitur

Kedaluwarsa sejarah

Apa masalah yang diselesaikan?

Pada saat penulisan artikel ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, dan juga memerlukan ratusan GB ruang disk untuk klien konsensus. Sebagian besar data ini adalah data historis: tentang blok sejarah, transaksi, dan bukti, 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, karena setiap blok terhubung ke blok sebelumnya melalui tautan hash (dan struktur lainnya), maka konsensus saat ini sudah cukup 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 individu 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 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 berlawanan dengan intuisi, pendekatan ini bahkan tidak harus mengurangi ketahanan data. Jika kita dapat membangun jaringan dengan 100.000 node yang masing-masing menyimpan 10% catatan sejarah secara acak, maka setiap data akan disalin 10.000 kali - sama persis dengan faktor duplikasi dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.

Saat ini, Ethereum telah mulai melepaskan model penyimpanan permanen semua sejarah di semua node. 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 menjaga faktor duplikasi tetap sama. Faktanya, Blob telah menerapkan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan besar adalah menggunakan kembali kode penghapusan ini dan juga menempatkan data eksekusi dan konsensus blok ke dalam blob.

dan penelitian yang ada memiliki hubungan apa?

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 riwayat------setidaknya riwayat eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi yang paling sederhana adalah (i) dengan sederhana memperkenalkan pustaka torrent yang ada, serta (ii) yang disebut solusi asli Ethereum yang dikenal sebagai jaringan Portal. 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 yang baru. Oleh karena itu, mengaktifkannya secara bersamaan untuk semua klien adalah berharga, 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 berhenti menyimpan sejarah kuno besok dan bergantung pada node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi ini melemahkan posisi Ethereum sebagai tempat catatan permanen. Jalur yang lebih sulit tetapi lebih aman adalah dengan 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 historis ke dalam protokol?

Salah satu metode ekstrem yang 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 secara kriptografi apakah mereka melakukan hal tersebut. Metode yang lebih moderat 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 mencakup seluruh sejarah Ethereum. Implementasi yang lebih mendalam 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 cara interaksinya dengan bagian lain dari peta jalan?

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

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

Kedaluwarsa negara

Apa masalah yang diselesaikan?

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

Status lebih sulit "kedaluwarsa" dibandingkan dengan sejarah, karena EVM pada dasarnya dirancang dengan asumsi ini: 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 seburuk itu: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, 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, pada akhirnya kita mungkin ingin membuat status kedaluwarsa untuk mempertahankan 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 dengan 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 kunci adalah melakukan ini dengan cara yang mencapai tiga tujuan:

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

Keterpakaian bagi 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 bagi Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sepenuhnya tidak familiar. Selain itu, aplikasi yang sudah kaku dan tidak diperbarui seharusnya dapat terus berfungsi dengan normal.

Tidak memenuhi target ini akan membuat masalah mudah terpecahkan. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (yang dapat diperpanjang dengan membakar ETH, yang mungkin terjadi secara otomatis saat dibaca atau ditulis kapan saja), dan memiliki proses yang mengiterasi 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 sulit untuk menyimpulkan kasus tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset ke nol. Jika Anda mengatur penghitung waktu kedaluwarsa dalam ruang 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.

Semua ini adalah masalah yang telah diperjuangkan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "regenerasi". Akhirnya, kami menggabungkan bagian terbaik dari proposal dan berfokus pada dua jenis "solusi yang paling tidak buruk yang diketahui":

Solusi untuk status yang kadaluwarsa Saran kedaluwarsa status berdasarkan periode alamat.

Masa kedaluwarsa status sebagian

Beberapa proposal status yang kadaluarsa 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 di dalam setiap blok hanya akan disimpan jika data tersebut baru saja diakses. Ada mekanisme "kebangkitan", jika tidak lagi disimpan

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