Masa Depan Ethereum yang Mungkin: The Purge

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

Data historis: Setiap transaksi yang dilakukan dan akun yang dibuat harus disimpan secara permanen oleh semua klien, dan diunduh oleh klien baru untuk sepenuhnya disinkronkan dengan jaringan. Ini menyebabkan beban klien dan waktu sinkronisasi terus meningkat, meskipun kapasitas rantai tetap sama.

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

Untuk memastikan Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan 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 luar biasa: ketahanan. Anda bisa menempatkan NFT, surat cinta, atau kontrak pintar senilai 1 juta dolar di dalam rantai, masuk ke gua selama sepuluh tahun, dan saat keluar, menemukannya masih di sana menunggu Anda untuk membaca dan berinteraksi. Agar DApp merasa tenang sepenuhnya terdesentralisasi 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 penurunan sambil mempertahankan kontinuitas, itu sangat mungkin dilakukan. Organisme dapat melakukan 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 hilang, 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 ultimat untuk skalabilitas jangka panjang Ethereum, keberlanjutan teknis, dan bahkan keamanan.

The Purge: Tujuan utama.

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

Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak diperlukan.

Daftar Isi:

Sejarah kedaluwarsa(catatan sejarah kedaluwarsa) Status kedaluwarsa(status kedaluwarsa) Pembersihan fitur(特征清理)

Riwayat kedaluwarsa

Apa masalah yang diselesaikan?

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

Salah satu fitur sederhana kunci dari masalah penyimpanan sejarah adalah, karena setiap blok terhubung melalui hash ( dan struktur lainnya ) yang menunjuk ke blok sebelumnya, maka konsensus saat ini cukup untuk mencapai konsensus sejarah. Selama jaringan mencapai konsensus pada blok terbaru, blok atau transaksi atau status sejarah ( 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, sedangkan 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 dari data. Inilah cara kerja jaringan benih selama beberapa dekade: meskipun jaringan menyimpan dan mendistribusikan jutaan file secara total, 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 beroperasi 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 dengan faktor penggandaan dari jaringan 10.000 node, di mana setiap node menyimpan semuanya.

Saat ini, Ethereum telah mulai melepaskan model penyimpanan permanen semua riwayat oleh semua node. Blok konsensus ( terkait dengan bagian 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 dan bukti sejarah. Tujuan jangka panjang adalah untuk membangun periode yang seragam ) yang 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 untuk menyimpan data lama dengan cara terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Faktanya, Blob telah menggunakan kode penghapusan untuk mendukung pengambilan data yang tersedia. Solusi yang paling sederhana kemungkinan adalah dengan menggunakan kembali kode penghapusan ini, dan juga memasukkan data blok eksekusi dan konsensus ke dalam blob.

)# Apa keterkaitan 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?

Sisa pekerjaan utama mencakup pembangunan dan integrasi solusi terdistribusi konkret untuk menyimpan catatan historis------setidaknya catatan eksekusi, tetapi pada akhirnya juga termasuk konsensus dan blob. Solusi paling sederhana adalah ###i( cukup dengan memperkenalkan pustaka torrent yang ada, serta )ii( solusi asli Ethereum yang disebut jaringan Portal. Setelah salah satu dari ini diperkenalkan, kita dapat membuka EIP-4444. EIP-4444 sendiri tidak memerlukan hard fork, tetapi memang memerlukan versi protokol jaringan yang 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 mengunduh catatan lengkap tetapi sebenarnya tidak mendapatkannya.

Perimbangan utama melibatkan bagaimana kita berusaha untuk menyediakan data sejarah "kuno". Solusi termudah adalah menghentikan penyimpanan sejarah kuno besok dan bergantung pada node arsip yang ada serta berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi ini melemahkan posisi Ethereum sebagai tempat catatan permanen. Jalur yang lebih sulit tetapi lebih aman adalah pertama-tama membangun dan mengintegrasikan jaringan torrent untuk menyimpan catatan 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 untuk ) akan melibatkan bukti penyimpanan: sebenarnya meminta setiap validator bukti kepemilikan untuk menyimpan proporsi tertentu dari catatan sejarah, dan secara berkala memeriksa dengan cara kriptografi apakah mereka melakukannya. 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 diselesaikan 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 simpul penyimpanan riwayat lengkap atau simpul arsip, bahkan jika tidak ada simpul arsip lain yang online, mereka dapat mencapainya melalui sinkronisasi langsung dari jaringan portal.

(# Bagaimana cara 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 diperlukan node, sekitar 300 GB adalah status, dan sekitar 800 GB sisanya adalah sejarah. Hanya dengan mewujudkan tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di smartwatch dan hanya memerlukan beberapa menit untuk disiapkan dapat dicapai.

Pembatasan penyimpanan sejarah juga membuat implementasi 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 semua. Sekarang, dengan beralih ke bukti kepemilikan telah menjadi sejarah, klien dapat menghapus semua kode yang terkait dengan bukti kerja dengan aman.

) Masa kadaluarsa negara

Apa masalah yang diselesaikan?

Meskipun kami telah 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 nonce, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum sekarang dan di masa depan selamanya.

"Status lebih sulit untuk 'kadaluwarsa' dibandingkan dengan sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa setelah objek status dibuat, ia akan selalu ada dan dapat dibaca oleh transaksi kapan saja. 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 termasuk daftar yang dihasilkan! ### dapat berjalan tanpa status. Namun, ada pandangan bahwa kita tidak ingin terlalu bergantung pada tanpa status, pada akhirnya kita mungkin ingin membuat status kadaluwarsa untuk mempertahankan desentralisasi Ethereum."

(# Apa itu, bagaimana cara kerjanya

Hari ini, ketika Anda membuat objek status baru, ) dapat terjadi melalui salah satu dari tiga cara berikut: ###i ( mengirim ETH ke akun baru, (ii ) menggunakan kode untuk membuat akun baru, (iii ) mengatur slot penyimpanan yang sebelumnya tidak tersentuh (, objek status tersebut akan selamanya berada dalam keadaan itu. Sebaliknya, yang kita inginkan adalah objek yang secara otomatis kedaluwarsa seiring waktu. Tantangan kuncinya adalah melakukannya dengan cara yang memenuhi ketiga tujuan tersebut:

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

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

Keterpampuan untuk Pengembang: Pengembang tidak perlu beralih ke model pemikiran yang sama sekali tidak mereka kenal. Selain itu, aplikasi yang saat ini sudah kaku dan tidak diperbarui seharusnya tetap dapat berfungsi dengan normal.

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 ETH, yang mungkin secara otomatis terjadi setiap kali dibaca atau ditulis ), dan memiliki proses untuk melintasi status untuk menghapus objek status tanggal kedaluwarsa. Namun, ini memperkenalkan kebutuhan komputasi tambahan ( bahkan kebutuhan penyimpanan ), dan itu pasti tidak dapat memenuhi tuntutan ramah pengguna. Pengembang juga kesulitan untuk menyimpulkan situasi tepi yang melibatkan nilai penyimpanan yang kadang-kadang direset 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 "meneruskan" biaya penyimpanan yang berkelanjutan kepada pengguna.

Ini semua 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 diketahui paling tidak buruk":

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

(# Kadaluarsa status sebagian

Sebagian proposal status yang kedaluwarsa 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 dalam setiap blok hanya akan disimpan jika data tersebut baru-baru ini diakses. Ada mekanisme "kebangkitan" jika data tersebut tidak lagi disimpan.

Perbedaan utama antara proposal-proposal ini adalah:)i### bagaimana kita mendefinisikan "terbaru", dan(ii) bagaimana kita mendefinisikan "blok"? Salah satu proposal konkret adalah EIP-7736, yang dibangun di atas desain "daun" yang diperkenalkan untuk pohon Verkle(meskipun kompatibel dengan bentuk keadaan tanpa status apa pun, seperti pohon biner). Dalam desain ini, header, kode, dan slot penyimpanan yang berdekatan satu sama lain disimpan di bawah "batang" yang sama. Data yang disimpan di bawah satu batang dapat mencapai maksimal 256 * 31 = 7,936.