- Topik
76851 Popularitas
32650 Popularitas
9771 Popularitas
3765 Popularitas
3833 Popularitas
28466 Popularitas
15295 Popularitas
21666 Popularitas
12566 Popularitas
2197 Popularitas
- Sematkan
76851 Popularitas
32650 Popularitas
9771 Popularitas
3765 Popularitas
3833 Popularitas
28466 Popularitas
15295 Popularitas
21666 Popularitas
12566 Popularitas
2197 Popularitas
Perkembangan Masa Depan Ethereum: The Purge bertujuan untuk menyederhanakan protokol dan menurunkan kebutuhan penyimpanan.
Masa Depan Ethereum yang Mungkin: The Purge
Sejak 14 Oktober, pendiri Ethereum Vitalik Buterin secara bertahap menerbitkan serangkaian artikel diskusi tentang perkembangan masa depan Ethereum, dari "The Merge" hingga yang terbaru "The Purge", menunjukkan visinya tentang perkembangan masa depan jaringan utama Ethereum dan solusi untuk masalah saat ini.
Artikel "The Purge" membahas bagaimana Ethereum dapat mengurangi kompleksitas dan kebutuhan penyimpanan dalam jangka panjang, sambil mempertahankan keawetan dan desentralisasi rantai. Langkah-langkah utama termasuk mengurangi beban penyimpanan klien melalui "kedaluwarsa sejarah" dan "kedaluwarsa status", serta menyederhanakan protokol melalui "pembersihan fitur" untuk memastikan keberlanjutan dan skalabilitas jaringan.
History expiry Riwayat kedaluwarsa
Apa masalah yang diselesaikan?
Saat ini, node Ethereum yang sepenuhnya disinkronkan memerlukan sekitar 1.1TB ruang disk untuk menjalankan klien, ditambah beberapa ratus GB untuk klien konsensus. Sebagian besar adalah data historis, bahkan jika batas Gas tidak berubah, ukuran node akan meningkat beberapa ratus GB setiap tahun.
Apa itu, bagaimana cara kerjanya?
Salah satu fitur kunci dari penyimpanan sejarah adalah, konsensus saat ini cukup untuk mencapai konsensus tentang sejarah. Ini menyediakan berbagai pilihan untuk menyimpan catatan sejarah, seperti jaringan di mana setiap node hanya menyimpan sebagian data.
Ethereum telah mulai melepaskan model penyimpanan permanen semua sejarah di semua node. Blok konsensus 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 menetapkan periode penyimpanan bersatu sekitar 18 hari, kemudian membangun jaringan P2P yang terdiri dari node Ethereum untuk menyimpan data lama secara terdistribusi.
Kode penghapusan dapat digunakan untuk meningkatkan ketahanan, sambil mempertahankan faktor duplikasi yang sama. Solusi yang paling sederhana mungkin adalah menggunakan kembali kode penghapusan Blob yang ada, dan memasukkan eksekusi dan data blok konsensus juga ke dalam blob.
Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pekerjaan utama termasuk membangun dan mengintegrasikan solusi terdistribusi yang spesifik untuk menyimpan riwayat. Solusi paling sederhana adalah memperkenalkan pustaka torrent yang ada atau solusi asli Ethereum yang disebut jaringan Portal.
Pertimbangan utama melibatkan bagaimana berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah segera menghentikan penyimpanan sejarah kuno, bergantung pada node arsip yang ada. Solusi yang lebih aman tetapi lebih sulit adalah terlebih dahulu membangun dan mengintegrasikan jaringan torrent.
dan interaksi dengan bagian lain dari peta jalan
Mengurangi kebutuhan penyimpanan sejarah sangat penting untuk membuat operasi node menjadi sangat mudah. Hanya dengan mencapai tanpa status dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dapat terwujud.
Pembatasan penyimpanan sejarah juga membuat node Ethereum baru yang hanya mendukung versi protokol terbaru menjadi lebih praktis, sehingga menyederhanakan klien.
Status kedaluwarsa
Apa masalah yang diselesaikan?
Meskipun menghapus permintaan penyimpanan riwayat, permintaan penyimpanan klien akan terus meningkat sekitar 50GB per tahun, karena status ( saldo akun, kode kontrak, dan lain-lain ) akan terus tumbuh. Pengguna dapat membayar sekali, yang akan membawa beban permanen kepada pelanggan saat ini dan masa depan.
Apa itu, dan bagaimana cara kerjanya?
Status lebih sulit "kedaluwarsa" dibandingkan sejarah, karena EVM mengasumsikan bahwa objek status akan ada selamanya setelah dibuat. Tujuannya adalah untuk membuat objek secara otomatis kedaluwarsa seiring waktu, sambil tetap menjaga efisiensi, ramah pengguna, dan ramah pengembang.
Ada dua jenis solusi utama:
Status sebagian kedaluwarsa: Memecah status menjadi bagian, hanya menyimpan data yang baru-baru ini diakses. EIP-7736 mengusulkan solusi berbasis pohon Verkle, data yang tidak diakses selama 6 bulan hanya menyimpan 32 byte akar.
Status kadaluarsa berdasarkan siklus alamat: menggunakan daftar pohon status yang terus berkembang, menambahkan pohon kosong baru setiap tahun. Node lengkap hanya menyimpan dua pohon terbaru. Data yang kadaluarsa perlu menyediakan bukti untuk dibaca dan ditulis.
Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Jalur potensial di masa depan termasuk:
Mewujudkan tanpa status, tidak memperkenalkan status yang kedaluwarsa. Status terus meningkat tetapi hanya perlu disimpan oleh pengguna khusus.
Mewujudkan sebagian status yang kedaluwarsa, menerima tingkat pertumbuhan status permanen yang lebih rendah tetapi tidak nol.
Memperluas ruang alamat untuk mencapai kedaluwarsa status. Proses yang diperlukan bertahun-tahun untuk memastikan konversi format alamat aman dan efektif.
Mewujudkan kedaluwarsa status melalui penyusutan ruang alamat. Diperlukan proses bertahun-tahun untuk memastikan semua risiko keamanan teratasi.
Apa pun solusi yang diadopsi, tantangan perluasan dan pengecilan ruang alamat harus diselesaikan, karena serangan konflik alamat di masa depan akan menjadi lebih mudah.
Pembersihan Fitur
masalah apa yang diselesaikan?
Kesederhanaan protokol adalah kunci untuk keamanan, aksesibilitas, dan netralitas yang dapat dipercaya. Namun, protokol cenderung menjadi lebih kompleks seiring waktu. Kita perlu dapat menghapus fitur dan mengurangi kompleksitas.
Apa itu, bagaimana cara kerjanya?
Tidak ada perbaikan besar tunggal yang dapat mengurangi kompleksitas protokol, tetapi diperlukan banyak solusi kecil. Beberapa contoh kunci termasuk:
Beberapa contoh dalam EVM:
Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Pertimbangan utama adalah tingkat penyederhanaan dan kecepatan dibandingkan dengan kompatibilitas ke belakang. Diperlukan untuk membuat proses standar untuk melakukan perubahan yang merusak kompatibilitas ke belakang yang tidak mendesak, termasuk analisis dampak, penghapusan EIP secara resmi, dan langkah-langkah penghapusan akhir.
Format objek EVM ( EOF ) mengusulkan serangkaian perubahan EVM, dengan tujuan untuk memungkinkan lebih banyak pembaruan. Diperlukan pertimbangan antara kompleksitas yang meningkat dan tujuan untuk menyederhanakan seluruh EVM.
Metode yang lebih radikal adalah mengubah sebagian besar konten protokol menjadi kode kontrak, seperti mengubah EVM menjadi ringkasan atau mengganti EVM dengan VM baru. Ini dapat sangat menyederhanakan protokol, tetapi perlu mempertimbangkan kompatibilitas.