Salah satu tantangan penting yang dihadapi Ethereum adalah bagaimana mengurangi kompleksitas dan kebutuhan penyimpanan dalam jangka panjang, sambil menjaga keberlanjutan dan desentralisasi jaringan. Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan yang kuat terhadap kompleksitas dan pembengkakan, dengan mengurangi kompleksitas dan pembengkakan seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu mempertahankan keberlanjutan blockchain sebagai atribut kunci.
Tujuan utama dari pemurnian termasuk:
Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan bagi setiap node untuk secara permanen menyimpan semua catatan sejarah atau bahkan status akhir.
Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak perlu.
Catatan Riwayat Kedaluwarsa
Apa masalah yang diselesaikan?
Hingga saat ini, node Ethereum yang sepenuhnya disinkronkan membutuhkan sekitar 1,1 TB ruang disk untuk menjalankan klien, dan juga memerlukan ratusan GB untuk klien konsensus. Sebagian besar dari data ini adalah data historis, bahkan jika ukuran blok tidak berubah, ukuran node akan terus meningkat ratusan GB setiap tahunnya.
Apa itu, bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui hash, cukup untuk mencapai konsensus saat ini untuk mencapai konsensus sejarah. 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 data.
Saat ini, Ethereum telah mulai melepaskan model di mana semua node menyimpan semua riwayat secara permanen. Blok konsensus hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan kwitansi sejarah. Tujuan jangka panjang adalah untuk membangun periode seragam ( yang 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.
Apa yang perlu dilakukan lagi, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa meliputi pembangunan dan integrasi solusi terdistribusi yang spesifik untuk menyimpan catatan sejarah. Solusi yang paling sederhana adalah memperkenalkan perpustakaan torrent yang ada atau solusi asli Ethereum yang disebut jaringan Portal. Pertimbangan utama melibatkan bagaimana kami berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah berhenti menyimpan sejarah kuno besok, dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk replikasi. Jalur yang lebih sulit tetapi lebih aman adalah terlebih dahulu membangun dan mengintegrasikan jaringan torrent, untuk menyimpan catatan sejarah secara terdistribusi.
bagaimana 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 statelessness. Hanya dengan mewujudkan statelessness dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya memerlukan beberapa menit untuk mengaturnya dapat dicapai.
Status Kedaluwarsa
Apa masalah 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. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum saat ini dan yang akan datang selamanya.
Apa itu, bagaimana cara kerjanya?
Hari ini, ketika membuat objek status baru, objek status tersebut selalu berada dalam status itu. Sebaliknya, yang kita inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan kuncinya adalah melakukan ini dengan cara yang mencapai efisiensi, ramah pengguna, dan ramah pengembang.
Saat ini ada dua jenis "solusi yang diketahui paling tidak buruk":
Solusi kedaluwarsa status sebagian
Saran status jatuh tempo berdasarkan siklus alamat
Beberapa proposal status kadaluarsa membagi status menjadi blok. Setiap orang menyimpan "peta teratas" secara permanen, di mana blok kosong atau tidak kosong. Data di setiap blok hanya akan disimpan jika data tersebut telah diakses baru-baru ini. Ada mekanisme "kebangkitan" jika data tidak lagi disimpan.
Desain berbasis siklus alamat menggunakan daftar pohon status yang terus berkembang, dan setiap status yang dibaca atau ditulis akan disimpan di pohon status terbaru. Setiap periode ( misalnya: 1 tahun ) menambahkan satu pohon status kosong baru. Pohon lama dibekukan. Node lengkap hanya menyimpan dua pohon terbaru.
Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Saya pikir ada empat jalan yang mungkin di masa depan:
Kami melakukan tanpa status, dan tidak pernah memperkenalkan status yang kadaluarsa.
Kami melakukan sebagian status yang kadaluarsa, dan menerima tingkat pertumbuhan ukuran status permanen yang jauh lebih rendah tetapi tetap non-nol.
Kami melakukan kadaluarsa status melalui perluasan ruang alamat.
Kami melakukan kadaluarsa status melalui pengurangan ruang alamat.
Poin penting adalah, terlepas dari apakah rencana kedaluwarsa yang bergantung pada perubahan format alamat akan diterapkan atau tidak, akhirnya harus ada solusi untuk masalah terkait perluasan dan penyusutan ruang alamat.
Pembersihan Fitur
Apa masalah yang diselesaikan?
Salah satu prasyarat kunci untuk keamanan, keterjangkauan, dan netralitas yang dapat dipercaya adalah kesederhanaan. Jika protokol menarik dan sederhana, kemungkinan terjadinya kesalahan akan berkurang. Ini meningkatkan kesempatan bagi pengembang baru untuk terlibat dalam bagian mana pun. Ini lebih mungkin adil, dan juga lebih mudah untuk menahan kepentingan khusus. Sayangnya, protokol, seperti sistem sosial lainnya, secara default akan menjadi lebih kompleks seiring berjalannya waktu.
Apa itu, bagaimana cara kerjanya?
Tidak ada perbaikan tunggal yang signifikan yang dapat mengurangi kompleksitas protokol; sifat masalah ini adalah ada banyak solusi kecil. Beberapa contoh kunci termasuk:
Konversi RLP → SSZ
Hapus jenis transaksi lama
LOG reformasi
Menghapus mekanisme komite sinkronisasi rantai beacon secara permanen
Format data seragam
Hapus Komite Rantai Beacon
Menghapus urutan byte campuran
Penyederhanaan mekanisme Gas
Hapus prekompilasi
Menghapus observabilitas gas
Peningkatan analisis statis
apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Trade-off utama untuk menyederhanakan fungsi ini adalah tingkat dan kecepatan penyederhanaan kami dibandingkan dengan kompatibilitas mundur. Masalah sosial yang lebih luas adalah menciptakan saluran yang distandarisasi untuk melakukan perubahan yang merusak kompatibilitas mundur yang tidak mendesak.
Format objek EVM ( EOF ) adalah serangkaian perubahan utama yang diusulkan untuk EVM. Kelebihannya adalah menciptakan jalur alami untuk menambahkan fitur EVM baru dan mendorong migrasi ke EVM yang lebih ketat dengan jaminan yang lebih kuat. Kekurangannya adalah secara signifikan meningkatkan kompleksitas protokol, kecuali kami dapat menemukan cara untuk akhirnya mendepresiasi dan menghapus EVM lama.
Sebuah strategi penyederhanaan Ethereum yang lebih radikal adalah mempertahankan protokol tetap sama, tetapi memindahkan sebagian besar fungsinya dari protokol ke kode kontrak. Versi yang paling ekstrem adalah membuat L1 Ethereum "secara teknis" hanya menjadi rantai suar, dan memperkenalkan mesin virtual minimal yang memungkinkan orang lain untuk membuat agregat mereka sendiri. Kemudian, EVM akan menjadi yang pertama di antara agregat ini.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Jalan Pemurnian Ethereum: Tantangan Jangka Panjang untuk Menurunkan Kompleksitas dan Kebutuhan Penyimpanan
Masa Depan Ethereum yang Mungkin: Pemurnian
Salah satu tantangan penting yang dihadapi Ethereum adalah bagaimana mengurangi kompleksitas dan kebutuhan penyimpanan dalam jangka panjang, sambil menjaga keberlanjutan dan desentralisasi jaringan. Agar Ethereum dapat bertahan dalam jangka panjang, kita perlu memberikan tekanan yang kuat terhadap kompleksitas dan pembengkakan, dengan mengurangi kompleksitas dan pembengkakan seiring berjalannya waktu. Namun, pada saat yang sama, kita perlu mempertahankan keberlanjutan blockchain sebagai atribut kunci.
Tujuan utama dari pemurnian termasuk:
Mengurangi persyaratan penyimpanan klien dengan mengurangi atau menghilangkan kebutuhan bagi setiap node untuk secara permanen menyimpan semua catatan sejarah atau bahkan status akhir.
Mengurangi kompleksitas protokol dengan menghilangkan fungsi yang tidak perlu.
Catatan Riwayat Kedaluwarsa
Apa masalah yang diselesaikan?
Hingga saat ini, node Ethereum yang sepenuhnya disinkronkan membutuhkan sekitar 1,1 TB ruang disk untuk menjalankan klien, dan juga memerlukan ratusan GB untuk klien konsensus. Sebagian besar dari data ini adalah data historis, bahkan jika ukuran blok tidak berubah, ukuran node akan terus meningkat ratusan GB setiap tahunnya.
Apa itu, bagaimana cara kerjanya?
Salah satu fitur penyederhanaan kunci dari masalah penyimpanan sejarah adalah bahwa karena setiap blok terhubung ke blok sebelumnya melalui hash, cukup untuk mencapai konsensus saat ini untuk mencapai konsensus sejarah. 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 data.
Saat ini, Ethereum telah mulai melepaskan model di mana semua node menyimpan semua riwayat secara permanen. Blok konsensus hanya menyimpan sekitar 6 bulan. Blob hanya menyimpan sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan kwitansi sejarah. Tujuan jangka panjang adalah untuk membangun periode seragam ( yang 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.
Apa yang perlu dilakukan lagi, apa yang perlu dipertimbangkan?
Pekerjaan utama yang tersisa meliputi pembangunan dan integrasi solusi terdistribusi yang spesifik untuk menyimpan catatan sejarah. Solusi yang paling sederhana adalah memperkenalkan perpustakaan torrent yang ada atau solusi asli Ethereum yang disebut jaringan Portal. Pertimbangan utama melibatkan bagaimana kami berusaha untuk menyediakan data sejarah "kuno". Solusi yang paling sederhana adalah berhenti menyimpan sejarah kuno besok, dan mengandalkan node arsip yang ada serta berbagai penyedia terpusat untuk replikasi. Jalur yang lebih sulit tetapi lebih aman adalah terlebih dahulu membangun dan mengintegrasikan jaringan torrent, untuk menyimpan catatan sejarah secara terdistribusi.
bagaimana 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 statelessness. Hanya dengan mewujudkan statelessness dan EIP-4444, visi untuk menjalankan node Ethereum di jam tangan pintar dan hanya memerlukan beberapa menit untuk mengaturnya dapat dicapai.
Status Kedaluwarsa
Apa masalah 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. Pengguna dapat membayar biaya sekali, sehingga membebani klien Ethereum saat ini dan yang akan datang selamanya.
Apa itu, bagaimana cara kerjanya?
Hari ini, ketika membuat objek status baru, objek status tersebut selalu berada dalam status itu. Sebaliknya, yang kita inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan kuncinya adalah melakukan ini dengan cara yang mencapai efisiensi, ramah pengguna, dan ramah pengembang.
Saat ini ada dua jenis "solusi yang diketahui paling tidak buruk":
Beberapa proposal status kadaluarsa membagi status menjadi blok. Setiap orang menyimpan "peta teratas" secara permanen, di mana blok kosong atau tidak kosong. Data di setiap blok hanya akan disimpan jika data tersebut telah diakses baru-baru ini. Ada mekanisme "kebangkitan" jika data tidak lagi disimpan.
Desain berbasis siklus alamat menggunakan daftar pohon status yang terus berkembang, dan setiap status yang dibaca atau ditulis akan disimpan di pohon status terbaru. Setiap periode ( misalnya: 1 tahun ) menambahkan satu pohon status kosong baru. Pohon lama dibekukan. Node lengkap hanya menyimpan dua pohon terbaru.
Apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Saya pikir ada empat jalan yang mungkin di masa depan:
Poin penting adalah, terlepas dari apakah rencana kedaluwarsa yang bergantung pada perubahan format alamat akan diterapkan atau tidak, akhirnya harus ada solusi untuk masalah terkait perluasan dan penyusutan ruang alamat.
Pembersihan Fitur
Apa masalah yang diselesaikan?
Salah satu prasyarat kunci untuk keamanan, keterjangkauan, dan netralitas yang dapat dipercaya adalah kesederhanaan. Jika protokol menarik dan sederhana, kemungkinan terjadinya kesalahan akan berkurang. Ini meningkatkan kesempatan bagi pengembang baru untuk terlibat dalam bagian mana pun. Ini lebih mungkin adil, dan juga lebih mudah untuk menahan kepentingan khusus. Sayangnya, protokol, seperti sistem sosial lainnya, secara default akan menjadi lebih kompleks seiring berjalannya waktu.
Apa itu, bagaimana cara kerjanya?
Tidak ada perbaikan tunggal yang signifikan yang dapat mengurangi kompleksitas protokol; sifat masalah ini adalah ada banyak solusi kecil. Beberapa contoh kunci termasuk:
apa lagi yang perlu dilakukan, apa yang perlu dipertimbangkan?
Trade-off utama untuk menyederhanakan fungsi ini adalah tingkat dan kecepatan penyederhanaan kami dibandingkan dengan kompatibilitas mundur. Masalah sosial yang lebih luas adalah menciptakan saluran yang distandarisasi untuk melakukan perubahan yang merusak kompatibilitas mundur yang tidak mendesak.
Format objek EVM ( EOF ) adalah serangkaian perubahan utama yang diusulkan untuk EVM. Kelebihannya adalah menciptakan jalur alami untuk menambahkan fitur EVM baru dan mendorong migrasi ke EVM yang lebih ketat dengan jaminan yang lebih kuat. Kekurangannya adalah secara signifikan meningkatkan kompleksitas protokol, kecuali kami dapat menemukan cara untuk akhirnya mendepresiasi dan menghapus EVM lama.
Sebuah strategi penyederhanaan Ethereum yang lebih radikal adalah mempertahankan protokol tetap sama, tetapi memindahkan sebagian besar fungsinya dari protokol ke kode kontrak. Versi yang paling ekstrem adalah membuat L1 Ethereum "secara teknis" hanya menjadi rantai suar, dan memperkenalkan mesin virtual minimal yang memungkinkan orang lain untuk membuat agregat mereka sendiri. Kemudian, EVM akan menjadi yang pertama di antara agregat ini.