Vitalik: Masa Depan Potensial Ethereum, The Purge

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

Data historis: Setiap transaksi dan pembuatan akun yang dilakukan pada setiap waktu dalam sejarah perlu disimpan secara permanen oleh semua klien, dan diunduh oleh klien baru mana pun, sehingga sepenuhnya disinkronkan dengan jaringan. Ini akan menyebabkan beban klien dan waktu sinkronisasi terus 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 berjalannya waktu.

Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap dua tren ini, mengurangi kompleksitas dan ekspansi seiring berjalannya waktu. Tetapi 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 dalam rantai, masuk ke dalam gua selama sepuluh tahun, dan saat keluar, Anda akan menemukan bahwa itu masih ada di sana menunggu Anda untuk membaca dan berinteraksi. Agar DApp dapat sepenuhnya terdesentralisasi dengan tenang dan menghapus kunci peningkatan, 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 dua kebutuhan ini, dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan kemunduran sambil menjaga kontinuitas, itu sangat mungkin dilakukan. Organisme dapat melakukan ini: meskipun sebagian besar organisme menua seiring berjalannya waktu, beberapa yang beruntung tidak melakukannya. Bahkan sistem sosial pun bisa memiliki umur yang sangat panjang. Dalam beberapa kasus, Ethereum telah mencapai keberhasilan: bukti kerja telah hilang, opcode SELFDESTRUCT sebagian besar telah menghilang, dan node rantai beacon telah menyimpan data lama selama maksimal 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, dan bahkan keamanan.

The Purge: Tujuan utama.

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

Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak diperlukan.

Daftar isi:

History expiry（历史记录到期）

Status kedaluwarsa

Pembersihan fitur

Kadaluwarsa sejarah

masalah apa yang diselesaikan?

Hingga saat penulisan artikel ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1,1 TB ruang disk untuk menjalankan klien, ditambah lagi beberapa ratus GB ruang disk untuk klien konsensus. Sebagian besar adalah sejarah: data tentang blok sejarah, transaksi, dan kuitansi, sebagian besar sudah berusia beberapa tahun. Ini berarti bahwa bahkan jika batas Gas tidak meningkat sama sekali, ukuran node akan terus meningkat beberapa ratus 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), cukup untuk mencapai konsensus saat ini untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok, transaksi, atau status sejarah (saldo akun, nomor acak, kode, penyimpanan) mana pun dapat disediakan oleh peserta individu 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 riwayat. 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 keseluruhan 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% riwayat secara acak, maka setiap data akan disalin 10.000 kali - sama dengan faktor penggandaan dari jaringan 10.000 node, di mana setiap node menyimpan semua konten.

Saat ini, Ethereum telah mulai menghindari model di mana semua node menyimpan semua sejarah secara permanen. 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 tanda terima sejarah. Tujuan jangka panjang adalah untuk membangun satu periode yang seragam (mungkin sekitar 18 hari), selama periode ini setiap node bertanggung jawab untuk menyimpan semua konten, kemudian membangun jaringan peer-to-peer yang terdiri dari node Ethereum untuk 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 pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan besar adalah menggunakan kembali kode penghapusan ini, dan juga menempatkan eksekusi dan data blok konsensus ke dalam blob.

memiliki hubungan apa dengan penelitian yang ada?

EIP-4444；

Torrents dan EIP-4444；

Portal Jaringan;

Jaringan portal dan EIP-4444;

Penyimpanan dan pengambilan terdistribusi objek SSZ dalam 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 spesifik untuk menyimpan riwayat------setidaknya riwayat eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi termudah adalah (i) cukup dengan memperkenalkan pustaka torrent yang 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 memerlukan versi protokol jaringan baru. Oleh karena itu, mengaktifkannya untuk semua klien secara bersamaan adalah berharga, jika tidak ada risiko klien mengalami kegagalan karena terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak mendapatkannya.

Timbal balik utama melibatkan bagaimana kita 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 status Ethereum sebagai tempat catatan permanen. Cara yang lebih sulit tetapi lebih aman adalah dengan terlebih dahulu membangun dan mengintegrasikan jaringan torrent untuk menyimpan catatan secara terdistribusi. Di sini, "berapa 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 sangat obsesif untuk (1) akan melibatkan bukti kepemilikan: pada dasarnya mengharuskan setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa dengan cara yang 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 mendalam akan melibatkan menghubungkannya dengan 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 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, dan sekitar 800 GB telah menjadi sejarah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya memerlukan beberapa menit untuk mengatur dapat terwujud.

Pembatasan penyimpanan sejarah juga membuat node Ethereum yang lebih baru 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 2016 telah dihapus sepenuhnya. Karena peralihan ke bukti kepemilikan telah menjadi sejarah, klien dapat dengan aman menghapus semua kode terkait bukti kerja.

Masa kedaluwarsa negara

masalah apa 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 angka acak, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum sekarang dan di masa depan selamanya.

Status lebih sulit "kadaluarsa" dibandingkan dengan sejarah, karena EVM pada dasarnya dirancang dengan asumsi seperti ini: setelah objek status dibuat, ia 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 benar-benar menyimpan status, sementara semua node lainnya (bahkan yang termasuk dalam daftar generasi!) dapat berjalan tanpa status. Namun, ada pandangan 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 dengan kode, (iii) mengatur slot penyimpanan yang sebelumnya tidak terjamah), objek status tersebut akan selamanya berada dalam keadaan itu. Sebaliknya, yang kita inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring waktu. Tantangan kunci adalah melakukan ini dengan cara yang memenuhi tiga tujuan:

Efisiensi: Tidak memerlukan banyak perhitungan tambahan untuk menjalankan proses jatuh tempo.

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 asing. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui harus tetap berjalan dengan normal.

Tidak memenuhi sasaran 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 secara otomatis terjadi kapan saja saat dibaca atau ditulis), dan memiliki proses yang mengulangi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (bahkan kebutuhan penyimpanan), dan pasti tidak dapat memenuhi persyaratan ramah pengguna. Pengembang juga sulit untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang diatur ulang menjadi nol. Jika Anda mengatur penghitung kedaluwarsa dalam lingkup kontrak, ini secara teknis akan membuat hidup pengembang menjadi 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 diupayakan oleh komunitas pengembang inti Ethereum selama bertahun-tahun, termasuk proposal seperti "sewa blockchain" dan "reproduksi". Akhirnya, kami menggabungkan bagian terbaik dari proposal dan fokus pada dua kategori "solusi yang diketahui paling tidak buruk":

• Solusi status yang sebagian kadaluarsa
• Saran kedaluwarsa status berdasarkan periode 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,