Salah satu tantangan Ethereum adalah bahwa secara default, pembengkakan dan kompleksitas protokol blockchain apa pun bertambah seiring waktu. Ini terjadi di dua tempat:

• Data historis: setiap transaksi yang dilakukan dan setiap akun yang dibuat kapan pun dalam sejarah harus disimpan oleh semua klien selamanya, dan diunduh oleh klien baru yang melakukan sinkronisasi penuh ke jaringan. Hal ini menyebabkan beban klien dan waktu sinkronisasi terus meningkat seiring waktu, bahkan ketika kapasitas rantai tetap sama.
• Fitur protokol: jauh lebih mudah untuk menambahkan fitur baru daripada menghapus yang lama, menyebabkan kompleksitas kode meningkat dari waktu ke waktu.

Untuk Ethereum bertahan dalam jangka panjang, kita memerlukan tekanan lawan yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan pembengkakan dari waktu ke waktu. Tetapi pada saat yang sama, kita perlu mempertahankan salah satu properti kunci yang membuat blockchain hebat: keabadian mereka. Anda dapat menempatkan NFT, catatan cinta dalam calldata transaksi, atau kontrak pintar yang berisi sejuta dolar onchain, pergi ke dalam gua selama sepuluh tahun, keluar dan menemukannya masih ada menunggu Anda untuk membaca dan berinteraksi dengannya. Agar dapps merasa nyaman untuk sepenuhnya terdesentralisasi dan menghapus kunci upgrade mereka, mereka perlu yakin bahwa dependensi mereka tidak akan melakukan upgrade dengan cara yang merusak mereka - terutama L1 itu sendiri.

Pembersihan Besar-besaran, peta jalan 2023.

Menyeimbangkan antara dua kebutuhan ini, dan meminimalkan atau membalik bengkak, kompleksitas, dan kerusakan sambil mempertahankan kontinuitas, adalah hal yang sangat mungkin jika kita memusatkan pikiran kita padanya. Organisme hidup bisa melakukannya: sementara sebagian besar menua seiring waktu,beberapa orang beruntung tidak. Bahkan sistem sosial pun dapat memiliki umur panjang yang luar biasaPada beberapa kesempatan, Ethereum telah menunjukkan kesuksesan: bukti kerja sudah hilang, opcode SELFDESTRUCT sebagian besar sudah hilang, dan node rantai pelita sudah menyimpan data lama hanya sampai enam bulan. Menemukan jalur ini untuk Ethereum dengan cara yang lebih umum, dan bergerak menuju hasil akhir yang stabil untuk jangka panjang, adalah tantangan utama keberlanjutan teknis, skalabilitas jangka panjang, dan bahkan keamanan Ethereum.

Pembersihan: tujuan kunci

• Mengurangi kebutuhan penyimpanan klien dengan mengurangi atau menghapus kebutuhan setiap node untuk menyimpan secara permanen seluruh riwayat, dan mungkin akhirnya bahkan keadaan
• Mengurangi kompleksitas protokol dengan menghilangkan fitur yang tidak diperlukan

Di bab ini

• Kedaluwarsa sejarah
• Kadaluarsa negara
• Pembersihan fitur

Kedaluwarsa sejarah

Masalah apa yang dipecahkannya?

Pada saat penulisan ini, sebuah node Ethereum yang telah disinkronisasi penuh membutuhkan sekitar 1,1 terabyteof ruang disk untuk klien eksekusi, ditambah beberapa ratus gigabyte lagi untuk klien konsensus. Sebagian besar dari ini adalah sejarah: data tentang blok historis, transaksi, dan tanda terima, yang sebagian besar di antaranya sudah berusia bertahun-tahun. Ini berarti ukuran sebuah node terus bertambah ratusan gigabyte setiap tahun, bahkan jika batas gas tidak bertambah sama sekali.

Apa itu, dan bagaimana cara kerjanya?

Fitur kunci yang menyederhanakan masalah penyimpanan sejarah adalah bahwa setiap blok menunjuk ke blok sebelumnya melalui tautan hash (dan lainnya struktur), memiliki konsensus tentang masa kini sudah cukup untuk memiliki konsensus tentang sejarah. Selama jaringan memiliki konsensus tentang blok terbaru, setiap blok historis atau transaksi atau status (saldo akun, nonce, kode, penyimpanan) dapat disediakan oleh aktor tunggal mana pun bersama dengan bukti Merkle, dan bukti tersebut memungkinkan orang lain untuk memverifikasi kebenarannya. Sementara konsensus adalah model kepercayaan N / 2-of-N, sejarah adalah model kepercayaan 1-dari-N.

Ini membuka banyak pilihan untuk bagaimana kita dapat menyimpan sejarah. Salah satu opsi alami adalah jaringan di mana setiap node hanya menyimpan persentase kecil dari data. Inilah bagaimana jaringan torrent telah bekerja selama puluhan tahun: sementara jaringan secara keseluruhan menyimpan dan mendistribusikan jutaan file, setiap peserta hanya menyimpan dan mendistribusikan beberapa di antaranya. Mungkin secara kontra-intuitif, pendekatan ini bahkan tidak selalu mengurangi kekokohan data. Jika, dengan membuat node yang lebih terjangkau, kita dapat mencapai jaringan dengan 100.000 node, di mana setiap node menyimpan 10% sejarah secara acak, maka setiap data akan direplikasi 10.000 kali - persis sama dengan faktor replikasi 10.000-node network di mana setiap node menyimpan semuanya.

Hari ini, Ethereum sudah mulai menjauh dari model semua node menyimpan semua riwayat selamanya. Blok konsensus (yaitu bagian yang terkait dengan konsensus bukti kepemilikan) hanya disimpan selama ~6 bulan. Blobs hanya disimpan selama ~18 hari.EIP-4444bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok historis dan tanda terima. Tujuan jangka panjang adalah memiliki periode yang diselaraskan (yang bisa ~18 hari) di mana setiap node bertanggung jawab untuk menyimpan segalanya, dan kemudian memiliki jaringan peer-to-peer yang terdiri dari node Ethereum yang menyimpan data lama secara terdistribusi.

Kode erasure dapat digunakan untuk meningkatkan ketahanan sambil menjaga faktor replikasi tetap sama. Faktanya, blob sudah datang dalam bentuk kode erasure untuk mendukung pengambilan sampel ketersediaan data. Solusi paling sederhana mungkin adalah untuk menggunakan ulang kode erasure ini, dan memasukkan data blok eksekusi dan konsensus ke dalam blob juga.

Apa beberapa tautan ke penelitian yang ada?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrent dan EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• jaringan portal: https://ethereum.org/id/developers/docs/networking-layer/portal-network/
• Jaringan portal dan EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Penyimpanan dan pengambilan objek SSZ yang didistribusikan di Portal: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Bagaimana cara meningkatkan batas gas (Paradigma):https://www.paradigm.xyz/2024/05/cara-menambahkan-batas-gas-2

Apa yang masih perlu dilakukan, dan apa saja pertimbangannya?

Pekerjaan utama yang tersisa melibatkan membangun dan mengintegrasikan solusi terdistribusi konkret untuk menyimpan sejarah - setidaknya sejarah pelaksanaan, tetapi pada akhirnya juga konsensus dan blob. Solusi yang paling mudah untuk ini adalah (i) dengan hanya memperkenalkan perpustakaan torrent yang ada, dan (ii) solusi Ethereum-native yang disebut protokol gate.jaringan Portal. Setelah salah satunya diperkenalkan, kita dapat mengaktifkan EIP-4444. EIP-4444 sendiri tidak memerlukan hard fork, meskipun membutuhkan versi protokol jaringan baru. Karena alasan ini, ada nilai dalam mengaktifkannya untuk semua klien pada saat yang sama, karena jika tidak ada risiko klien tidak berfungsi dengan baik saat terhubung ke node lain yang mengharapkan untuk mengunduh riwayat lengkap tetapi sebenarnya tidak mendapatkannya.

Kompromi utama melibatkan seberapa keras kita mencoba untuk membuat data sejarah 'kuno' tersedia. Solusi paling mudah adalah dengan berhenti menyimpan sejarah kuno besok, dan mengandalkan simpul arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi melemahkan posisi Ethereum sebagai tempat untuk membuat catatan permanen. Jalur yang lebih sulit, tetapi lebih aman, adalah dengan membangun dan mengintegrasikan jaringan torrent untuk menyimpan sejarah secara terdistribusi. Di sini, ada dua dimensi 'seberapa keras kita mencoba':

1. Seberapa keras kita mencoba untuk memastikan bahwa seperangkat node yang sangat besar benar-benar menyimpan semua data?
2. Seberapa dalam kita mengintegrasikan penyimpanan historis ke dalam protokol?

Sebuah pendekatan yang sangat paranoid untuk (1) akan melibatkanbukti penyimpanan: sebenarnya memerlukan setiap validator proof of stake untuk menyimpan sebagian persentase sejarah, dan secara teratur memeriksa secara kriptografis bahwa mereka melakukannya. Pendekatan yang lebih moderat adalah menetapkan standar sukarela untuk persentase sejarah yang disimpan setiap klien.

Untuk (2), implementasi dasar melibatkan hanya mengambil pekerjaan yang sudah dilakukan saat ini: Portal sudah menyimpan file ERA yang berisi sejarah Ethereum seluruhnya. Implementasi yang lebih menyeluruh akan melibatkan menghubungkan ini ke proses sinkronisasi, sehingga jika seseorang ingin melakukan sinkronisasi node penyimpanan sejarah lengkap atau node arsip, mereka dapat melakukannya bahkan jika tidak ada node arsip lain yang ada online, dengan melakukan sinkronisasi langsung dari jaringan Portal.

Bagaimana itu berinteraksi dengan bagian lain dari jalan peta?

Mengurangi persyaratan penyimpanan riwayat mungkin lebih penting daripada keadaan tanpa keadaan jika kita ingin membuatnya sangat mudah untuk menjalankan atau menjalankan node: dari 1,1 TB yang diperlukan oleh node, ~300 GB adalah keadaan, dan sisanya ~800 GB adalah sejarah. Visi dari node Ethereum yang berjalan di smart watch dan hanya memerlukan beberapa menit untuk diatur hanya dapat dicapai jika keduanya keadaan tanpa keadaan dan EIP-4444 diimplementasikan.

Membatasi penyimpanan riwayat juga membuatnya lebih layak bagi implementasi simpul Ethereum yang lebih baru untuk hanya mendukung versi terbaru dari protokol, yang memungkinkan mereka menjadi jauh lebih sederhana. Sebagai contoh, banyak baris kode dapat dengan aman dihapus sekarang bahwa slot penyimpanan kosong yang dibuat selama serangan DoS 2016 telah semua dihapus.dihapus. Sekarang bahwa peralihan ke bukti kepemilikan sudah menjadi sejarah kuno, klien dapat dengan aman menghapus semua kode terkait bukti kerja.

Kadaluarsa status

Masalah apa yang dipecahkannya?

Meskipun kita menghilangkan kebutuhan bagi klien untuk menyimpan riwayat, kebutuhan penyimpanan klien akan terus bertambah sekitar 50 GB per tahun, karena pertumbuhan yang terus berlanjut ke dalam keadaan: saldo akun dan nonces, kode kontrak dan penyimpanan kontrak. Pengguna dapat membayar biaya satu kali untuk memberikan beban pada klien Ethereum saat ini dan masa depan selamanya.

Negara jauh lebih sulit untuk 'kedaluwarsa' daripada sejarah, karena EVM pada dasarnya dirancang dengan asumsi bahwa begitu objek negara dibuat, itu akan selalu ada dan dapat dibaca oleh transaksi apa pun kapan pun. Jika kita memperkenalkan tanpa negara, ada argumen bahwa mungkin masalah ini tidak terlalu buruk: hanya kelas khusus pembangun blok yang perlu benar-benar menyimpan negara, dan semua node lain (bahkan daftar inklusi(produksi!) dapat berjalan tanpa keadaan. Namun, ada argumen bahwa kita tidak ingin terlalu bergantung pada keadaan tanpa keadaan, dan pada akhirnya kita mungkin ingin menghapus keadaan untuk menjaga Ethereum terdesentralisasi.

Apa itu, dan bagaimana cara kerjanya?

Hari ini, ketika Anda membuat objek state baru (yang dapat terjadi dalam satu dari tiga cara: (i) mengirim ETH ke akun baru, (ii) membuat akun baru dengan kode, (iii) mengatur slot penyimpanan yang sebelumnya belum disentuh), objek state tersebut akan berada dalam keadaan selamanya. Yang kita inginkan sebaliknya, adalah agar objek-objek tersebut secara otomatis kedaluwarsa seiring waktu. Tantangan utamanya adalah melakukan ini dengan cara yang mencapai tiga tujuan:

1. Efisiensi: tidak memerlukan jumlah komputasi tambahan yang besar untuk menjalankan proses kedaluwarsa
2. Kemudahan penggunaan: jika seseorang masuk ke dalam gua selama lima tahun dan kembali, mereka tidak seharusnya kehilangan akses ke ETH, ERC20, NFT, posisi CDP mereka...
3. Kemudahan pengembang: pengembang tidak perlu beralih ke model mental yang benar-benar tidak dikenal. Selain itu, aplikasi yang kaku saat ini dan tidak melakukan pembaruan seharusnya tetap berfungsi dengan baik.

Sangat mudah untuk memecahkan masalah tanpa memenuhi tujuan-tujuan ini. Misalnya, Anda dapat meminta setiap objek status juga menyimpan penghitung untuk tanggal kedaluwarsanya (yang dapat diperpanjang dengan membakar ETH, yang dapat terjadi secara otomatis kapan saja dibaca atau ditulis), dan memiliki proses yang berulang melalui status untuk menghapus objek status kedaluwarsa. Namun, ini memperkenalkan perhitungan tambahan (dan bahkan persyaratan penyimpanan), dan jelas tidak memenuhi persyaratan keramahan pengguna. Pengembang juga akan kesulitan bernalar tentang kasus tepi yang melibatkan nilai penyimpanan yang terkadang disetel ulang ke nol. Jika Anda membuat kontrak penghitung waktu kedaluwarsa, ini membuat hidup secara teknis lebih mudah bagi pengembang, tetapi itu membuat ekonomi lebih sulit: pengembang harus memikirkan cara "melewati" biaya penyimpanan yang sedang berlangsung kepada pengguna mereka.

Ini adalah masalah-masalah yang dihadapi komunitas pengembangan inti Ethereum selama bertahun-tahun, termasuk proposal seperti “sewa blockchaindanregenesis“. Akhirnya, kami menggabungkan bagian terbaik dari proposal dan berkumpul pada dua kategori "solusi yang paling tidak buruk":

• Solusi kadaluarsa status parsial
• Proposal penghapusan status berdasarkan periode alamat.

Kadaluwarsa status parsial

Proposal penghapusan status parsial semuanya bekerja dengan prinsip yang sama. Kami membagi status menjadi bagian-bagian. Setiap orang menyimpan secara permanen "peta tingkat atas" tentang bagian mana yang kosong atau tidak kosong. Data dalam setiap bagian hanya disimpan jika data tersebut baru-baru ini diakses. Ada mekanisme "kebangkitan" di mana jika sebuah bagian tidak lagi disimpan, siapa pun dapat mengembalikan data tersebut dengan memberikan bukti tentang apa data tersebut.

Perbedaan utama antara proposal-proposal ini adalah: (i) bagaimana kita mendefinisikan "baru-baru ini", dan (ii) bagaimana kita mendefinisikan "chunk"? Salah satu proposal konkret adalah EIP-7736, yang dibangun berdasarkan desain “stem-and-leaf”diperkenalkan untuk pohon Verkle(meskipun kompatibel dengan bentuk ketiadaan negara apa pun, misalnya pohon biner). Dalam desain ini, header, kode, dan slot penyimpanan yang berdekatan disimpan di bawah 'batang' yang sama. Data yang disimpan di bawah 'batang' maksimal 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode, dan banyak slot penyimpanan kunci, dari sebuah akun akan disimpan di bawah 'batang' yang sama. Jika data di bawah 'batang' tertentu tidak dibaca atau ditulis selama 6 bulan, data tersebut tidak lagi disimpan, dan hanya komitmen 32 byte ('tunggulah') ke data yang disimpan. Transaksi masa depan yang mengakses data tersebut perlu 'menghidupkan kembali' data, dengan bukti yang akan diperiksa terhadap 'tunggulah'.

Ada cara lain untuk menerapkan ide serupa. Misalnya, jika granularitas tingkat akun tidak mencukupi, kita dapat membuat skema di mana setiap 1/232 bagian dari pohon diperintah oleh mekanisme batang-dan-daun yang serupa.

Ini lebih rumit karena insentif: penyerang dapat memaksa klien untuk secara permanen menyimpan sejumlah besar status dengan memasukkan sejumlah besar data ke dalam satu subpohon dan mengirim satu transaksi setiap tahun untuk "memperbarui pohon". Jika Anda membuat biaya perpanjangan proporsional (atau durasi perpanjangan berbanding terbalik) dengan ukuran pohon, maka seseorang dapat membuat pengguna lain sedih dengan memasukkan sejumlah besar data ke dalam subpohon yang sama dengan mereka. Seseorang dapat mencoba membatasi kedua masalah dengan membuat granularitas dinamis berdasarkan ukuran subtree: misalnya, setiap objek keadaan 216 = 65536 berturut-turut dapat diperlakukan sebagai "grup". Namun, ide-ide ini lebih kompleks; Pendekatan berbasis STEM sederhana, dan menyelaraskan insentif, karena biasanya semua data di bawah STEM terkait dengan aplikasi atau pengguna yang sama.

Proposal kedaluwarsa berbasis periode alamat negara

Bagaimana jika kita ingin menghindari pertumbuhan status permanen sama sekali, bahkan 32-byte stub? Ini adalah masalah yang sulit karena dari @vbuterin/state_size_management#Resurrection-conflicts">konflik kebangkitan: bagaimana jika objek negara dihapus, kemudian eksekusi EVM menempatkan objek negara lain di posisi yang sama persis, tetapi setelah itu seseorang yang peduli dengan objek negara asli kembali dan mencoba memulihkannya? Dengan kadaluwarsa negara parsial, "stub" mencegah data baru dibuat. Dengan kadaluwarsa negara penuh, kita tidak mampu menyimpan bahkan stub.

Desain berbasis periode alamat adalah ide terbaik yang dikenal untuk mengatasi hal ini. Alih-alih memiliki satu pohon status yang menyimpan seluruh status, kami memiliki daftar pohon status yang terus berkembang, dan setiap status yang dibaca atau ditulis disimpan dalam pohon status yang paling baru. Pohon status kosong baru ditambahkan satu kali per periode (bayangkan: 1 tahun). Pohon status yang lebih lama membeku. Node penuh hanya diharapkan menyimpan dua pohon terbaru. Jika objek status tidak disentuh selama dua periode dan dengan demikian jatuh ke dalam pohon kedaluwarsa, masih bisa dibaca atau ditulis, tetapi transaksi perlu membuktikan bukti Merkle untuknya - dan begitu dilakukan, salinan akan disimpan kembali di pohon terbaru.

Sebuah gagasan utama untuk membuat semua ini ramah pengguna dan pengembang adalah konsep periode alamat. Sebuah periode alamat adalah nomor yang merupakan bagian dari alamat. Aturan utama adalah bahwa alamat dengan periode alamat N hanya dapat dibaca atau ditulis selama atau setelah periode N (yaitu ketika daftar pohon keadaan mencapai panjang N). Jika Anda menyimpan objek keadaan baru (misalnya kontrak baru, atau saldo ERC20 baru), jika Anda memastikan untuk menempatkan objek keadaan ke dalam kontrak yang periode alamatnya adalah baik N atau N-1, maka Anda dapat menyimpannya secara langsung, tanpa perlu memberikan bukti bahwa tidak ada yang ada sebelumnya. Namun, setiap penambahan atau pengeditan keadaan dalam periode alamat yang lebih tua memerlukan bukti.

Desain ini mempertahankan sebagian besar properti Ethereum saat ini, sangat ringan dalam komputasi tambahan, memungkinkan aplikasi ditulis hampir seperti saat ini (ERC20 perlu menulis ulang, untuk memastikan saldo alamat dengan periode alamat N disimpan dalam kontrak anak yang memiliki periode alamat N itu sendiri), dan memecahkan masalah 'pengguna masuk ke dalam gua selama lima tahun'. Namun, ada satu masalah besar: alamat perlu diperluas lebih dari 20 byte untuk memuat periode alamat.

Perluasan ruang alamat

Salah satu usulan adalah memperkenalkan format alamat baru berukuran 32 byte, yang mencakup nomor versi, nomor periode alamat, dan hash yang diperluas.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

Merah adalah nomor versi. Keempat nol berwarna oranye di sini dimaksudkan sebagai ruang kosong, yang dapat menampung nomor shard di masa depan. Hijau adalah nomor periode alamat. Biru adalah hash 26 byte.

Tantangan utama di sini adalah kompatibilitas mundur. Kontrak yang ada dirancang berdasarkan alamat 20 byte, dan sering menggunakan teknik byte-packing yang ketat yang secara eksplisit mengasumsikan alamat memiliki panjang tepat 20 byte.@ipsilon/address-space-extension-exploration">Salah satu ide untuk memecahkan masalah ini melibatkan peta terjemahan, di mana kontrak gaya lama yang berinteraksi dengan alamat gaya baru akan melihat hash 20 byte dari alamat gaya baru. Namun, ada kompleksitas signifikan yang terlibat dalam membuat ini aman.

Kontraksi ruang alamat

Pendekatan lain melibatkan arah yang berlawanan: kita segera melarang sebagian sub-range alamat berukuran 2128 tertentu (misalnya semua alamat yang dimulai dengan 0xffffffff), dan kemudian menggunakan rentang tersebut untuk memperkenalkan alamat dengan periode alamat dan hash 14 byte.

0xfffffff000169125d5dFcb7B8C2659029395bdF

Korban kunci yang dibuat oleh pendekatan ini, adalah bahwa itu memperkenalkan risiko keamanan untuk alamat kontrafaktual: alamat yang menyimpan aset atau izin, tetapi kodenya belum dipublikasikan ke Chain. Risiko melibatkan seseorang yang membuat alamat yang mengklaim memiliki satu bagian kode (belum dipublikasikan), tetapi juga memiliki potongan kode lain yang valid yang hash ke alamat yang sama. Menghitung tabrakan seperti itu membutuhkan 2⁸⁰hashes hari ini; kontraksi ruang alamat akan mengurangi angka ini menjadi 2 yang sangat mudah diakses⁵⁶hashes.

Area risiko kunci, alamat kontrafaktual yang bukan dompet yang dimiliki oleh satu pemilik, merupakan kasus yang relatif jarang terjadi saat ini, tetapi kemungkinan akan menjadi lebih umum saat kita memasuki dunia multi-L2. Satu-satunya solusi hanyalah menerima risiko ini, tetapi mengidentifikasi semua kasus penggunaan umum di mana ini mungkin menjadi masalah, dan mencari solusi alternatif yang efektif.

Apa beberapa tautan ke penelitian yang ada?

• Proposal awal
  • Sewa blockchain: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Teori pengelolaan ukuran status Ethereum: @vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• Beberapa kemungkinan jalur menuju tanpa negara dan kedaluwarsa negara: @vbuterin/state_expiry_paths">https://hackmd.io/@vbuterin/state_expiry_paths
• Usulan Kadaluwarsa Status Parsial
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Dokumen perluasan ruang alamat
  • Usulan asli: https://ethereum-magicians.org/t/meningkatkan-ukuran-alamat-dari-20-hingga-32-byte/5485
  • ulasan Ipsilon: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Ulasan posting blog:@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• Apa yang akan rusak jika kita kehilangan resistensi tabrakan:https://ethresear.ch/t/apa-yang-akan-terjadi-jika-kita-kehilangan-resistensi-tabrakan-alamat/11356

Apa yang harus dilakukan, dan apa saja kompromi yang ada?

Saya melihat empat jalur yang layak untuk masa depan:

• Kami melakukan keadaan tanpa negara, dan tidak pernah memperkenalkan kadaluwarsa negara. Negara terus berkembang (meskipun lambat: mungkin tidak akan melebihi 8 TB selama beberapa dekade), tetapi hanya perlu dipegang oleh kelas pengguna yang relatif khusus: bahkan validator PoS tidak perlu keadaan.
  \
  Fungsi satu-satunya yang memerlukan akses ke bagian-bagian dari state adalah produksi daftar inklusi, tetapi kita dapat mencapai ini dengan cara terdesentralisasi: setiap pengguna bertanggung jawab untuk mempertahankan bagian dari tree state yang berisi akun mereka sendiri. Ketika mereka menyiaran transaksi, mereka menyiarannya dengan bukti objek state yang diakses selama langkah verifikasi (ini berfungsi baik untuk akun EOAs maupun ERC-4337). Validator tanpa state kemudian dapat menggabungkan bukti-bukti ini menjadi bukti untuk seluruh daftar inklusi.
• Kami melakukan kadaluwarsa status parsial, dan menerima pertumbuhan ukuran status permanen yang lebih rendah namun tetap bukan nol. Hasil ini mungkin mirip dengan proposal kadaluwarsa sejarah yang melibatkan jaringan peer-to-peer yang menerima pertumbuhan penyimpanan sejarah permanen yang lebih rendah tetapi tetap bukan nol dari setiap klien yang harus menyimpan persentase data historis yang rendah tetapi tetap tetap.
• Kami melakukan kadaluwarsa negara, dengan perluasan ruang alamat. Ini melibatkan proses multi-tahun untuk memastikan bahwa pendekatan konversi format alamat bekerja dan aman, termasuk untuk aplikasi yang sudah ada.
• Kami melakukan kedaluwarsa negara, dengan kontraksi ruang alamat. Hal ini akan melibatkan proses multi-tahun untuk memastikan bahwa semua risiko keamanan yang melibatkan tabrakan alamat, termasuk situasi lintas-rantai, ditangani.

Satu poin penting adalah bahwa masalah-masalah sulit seputar perluasan dan penyusutan ruang alamat pada akhirnya harus diatasi terlepas dari apakah skema kadaluwarsa status yang bergantung pada perubahan format alamat pernah diterapkan. Saat ini, membutuhkan sekitar 2⁸⁰ hash untuk menghasilkan tabrakan alamat, beban komputasi yang sudah layak untuk aktor dengan sumber daya yang sangat baik: GPU dapat melakukan sekitar 2²⁷hash, jadi jika dijalankan selama satu tahun, ia dapat menghitung 2⁵², jadi semua ~2^30 GPU di duniadapat menghitung tabrakan dalam waktu sekitar 1/4 tahun, dan FPGAs dan ASICs dapat mempercepat ini lebih lanjut. Di masa depan, serangan seperti ini akan terbuka bagi lebih banyak orang. Oleh karena itu, biaya aktual dari menerapkan kadaluwarsa status penuh mungkin tidak sebesar yang terlihat, karena kita harus menyelesaikan masalah alamat yang sangat menantang ini bagaimanapun juga.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Melakukan kadaluarsa status secara potensial membuat transisi dari satu format pohon status ke format lain menjadi lebih mudah, karena tidak akan ada kebutuhan untuk prosedur transisi: Anda bisa mulai membuat pohon baru menggunakan format baru, dan kemudian melakukan hard fork untuk mengonversi pohon-pohon lama. Oleh karena itu, meskipun kadaluwarsa status itu kompleks, ia memiliki manfaat dalam menyederhanakan aspek lain dari peta jalan.

Pembersihan fitur

Masalah apa yang dapat diselesaikan olehnya?

Salah satu prasyarat kunci dari keamanan, aksesibilitas dan netralitas yang kredibel adalah kesederhanaan. Jika sebuah protokol indah dan sederhana, itu mengurangi kemungkinan akan ada bug. Ini meningkatkan kemungkinan bahwa pengembang baru akan dapat masuk dan bekerja dengan bagian mana pun darinya. Ini lebih cenderung adil dan lebih mudah untuk membela terhadap kepentingan khusus. Sayangnya, protokol, seperti sistem sosial lainnya, secara default menjadi lebih kompleks dari waktu ke waktu. Jika kita tidak ingin Ethereum masuk ke lubang hitam dengan kompleksitas yang terus meningkat, kita perlu melakukan salah satu dari dua hal: (i) berhenti membuat perubahan dan mengeraskan protokol, (ii) dapat benar-benar menghapus fitur dan mengurangi kompleksitas. Rute perantara, membuat lebih sedikit perubahan pada protokol, dan juga menghapus setidaknya sedikit kerumitan dari waktu ke waktu, juga dimungkinkan. Bagian ini akan berbicara bagaimana kita dapat mengurangi atau menghilangkan kompleksitas.

Apa itu, dan bagaimana cara kerjanya?

Tidak ada perbaikan tunggal besar yang dapat mengurangi kompleksitas protokol; sifat inheren dari masalah ini adalah ada banyak perbaikan kecil.

Salah satu contoh yang sebagian besar sudah selesai, dan dapat berfungsi sebagai cetak biru untuk bagaimana menangani yang lain, adalah @vbuterin/selfdestruct">penghapusan opcode SELFDESTRUCT. Opcode SELFDESTRUCT adalah satu-satunya opcode yang dapat mengubah jumlah slot penyimpanan yang tidak terbatas dalam satu blok, memerlukan klien untuk menerapkan kompleksitas yang jauh lebih besar untuk menghindari serangan DoS. Tujuan asli dari opcode ini adalah untuk memungkinkan penghapusan status sukarela, memungkinkan ukuran status untuk berkurang dari waktu ke waktu. Dalam praktiknya, sangat sedikit yang akhirnya menggunakannya. opcode telah dibuat lebih lemahhanya memungkinkan akun yang hancur sendiri dibuat dalam transaksi yang sama dalam hardfork Dencun. Ini memecahkan masalah DoS dan memungkinkan penyederhanaan yang signifikan dalam kode klien. Di masa depan, mungkin masuk akal untuk akhirnya menghapus opcode sepenuhnya.

Beberapa contoh kunci peluang penyederhanaan protokol yang telah diidentifikasi sejauh ini mencakup hal-hal berikut. Pertama, beberapa contoh di luar EVM; ini relatif tidak berbahaya, dan dengan demikian lebih mudah untuk mencapai konsensus dan melaksanakannya dalam jangka waktu yang lebih singkat.

• Transisi RLP → SSZ: sebelumnya, objek Ethereum diserialisasi menggunakan encoding yang disebutRLP. RLP tidak berjenis, dan secara tidak perlu rumit. Saat ini, rantai beacon menggunakanSSZ, yang jauh lebih baik dalam banyak hal, termasuk mendukung tidak hanya serialisasi tetapi juga hashing. Pada akhirnya, kami ingin sepenuhnya menghilangkan RLP, dan memindahkan semua jenis data menjadi struktur SSZ, yang pada gilirannya akan memudahkan peningkatan. EIP saat ini untuk ini termasuk [1] [2] [3].
• Penghapusan jenis transaksi lama: saat ini terdapat terlalu banyak jenis transaksi, banyak di antaranya yang dapat dihapus. Alternatif yang lebih moderat daripada penghapusan total adalah fitur abstraksi akun dengan mana akun pintar dapat memasukkan kode untuk memproses dan memverifikasi transaksi gaya lama jika mereka ingin.
• Reformasi LOG: log menciptakan filter bloom dan logika lain yang menambah kompleksitas pada protokol, namun sebenarnya tidak digunakan oleh klien karena terlalu lambat. Kita bisa hapus fitur-fitur ini, dan sebaliknya berusaha untuk mengembangkan alternatif, seperti alat pembaca log terdesentralisasi di luar protokol yang menggunakan teknologi modern seperti SNARK.
• Penghapusan akhir mekanisme komite sinkronisasi beacon chain: mekanisme komite sinkronisasiawalnya diperkenalkan untuk memungkinkan verifikasi klien ringan dari Ethereum. Namun, itu menambah kompleksitas signifikan ke protokol. Pada akhirnya, kita akan bisamemverifikasi lapisan konsensus Ethereum secara langsung menggunakan SNARKsIni akan menghilangkan kebutuhan untuk protokol verifikasi klien ringan yang didedikasikan. Potensialnya, perubahan pada konsensus bisa memungkinkan kita untuk menghapus komite sinkronisasi bahkan lebih awal, dengan membuat protokol klien ringan yang lebih 'asli' yang melibatkan verifikasi tanda tangan dari subset acak validator konsensus Ethereum.
• Pengharmonisasian format data: hari ini, status eksekusi disimpan dalam pohon Merkle Patricia, status konsensus disimpan dalam sebuah pohon SSZ, dan blob disimpan dengan @vbuterin/proto_danksharding_faq#Format-data-dalam-blob-dan-bagaimana-ia-dikonfirmasi-ke">Komitmen KZG. Di masa depan, masuk akal untuk membuat format tunggal yang terpadu untuk data blok dan format tunggal yang terpadu untuk status. Format-format ini akan mencakup semua kebutuhan penting: (i) bukti mudah untuk klien tanpa status, (ii) serialisasi dan pengkodean erasure untuk data, (iii) struktur data standar.
• Penghapusan komite rantai beacon: mekanisme ini awalnya diperkenalkan untuk mendukung sebuahversi eksekusi sharding tertentu. Sebaliknya, kita akhirnya melakukan shardingmelalui L2 dan blob. Oleh karena itu, komite-komite tidak perlu, dan oleh karena itu ada menuju penghapusan mereka yang sedang berlangsung.
• Penghapusan mixed-endianness: EVM adalah big-endian dan lapisan konsensus adalah little-endian. Mungkin masuk akal untuk melakukan re-harmonisasi dan membuat semuanya menjadi salah satu dari keduanya (mungkin big-endian, karena EVM lebih sulit untuk diubah)

Sekarang, beberapa contoh yang ada di dalam EVM:

• Pemudahan mekanika gas: aturan gas saat ini belum sepenuhnya dioptimalkan untuk memberikan batasan yang jelas terhadap jumlah sumber daya yang diperlukan untuk memverifikasi blok. Contoh kunci dari hal ini termasuk (i) biaya baca/tulis penyimpanan, yang dimaksudkan untuk membatasi jumlah baca/tulis dalam satu blok tetapi saat ini cukup sembrono, dan (ii) aturan pengisian memori, di mana saat ini sulit untuk memperkirakan konsumsi memori maksimum dari EVM. Perbaikan yang diusulkan termasuk perubahan biaya gas tanpa keadaan, yang mengharmonisasikan semua biaya yang terkait dengan penyimpanan ke dalam rumus sederhana, dan proposal ini untuk penetapan harga memori.
• Penghapusan precompiles: banyak precompiles yang dimiliki Ethereum saat ini sangat rumit dan jarang digunakan, dan menyumbang persentase besar hampir kegagalan konsensus tanpa benar-benar digunakan oleh aplikasi apa pun. Dua cara untuk menangani ini adalah (i) hanya menghapus precompile, dan (ii) menggantinya dengan kode EVM yang (pasti lebih mahal) yang mengimplementasikan logika yang sama.Rancangan EIP ini mengusulkanuntuk melakukan ini untuk prekompilasi identitas sebagai langkah pertama; kemudian, RIPEMD160, MODEXP, dan BLAKE mungkin menjadi kandidat untuk dihapus.
• Penghapusan observabilitas gas: membuat eksekusi EVM tidak lagi dapat melihat berapa banyak gas yang tersisa. Ini akan merusak beberapa aplikasi (terutama transaksi yang disponsori), tetapi akan memungkinkan peningkatan yang jauh lebih mudah di masa depan (misalnya, untuk versi yang lebih canggih darigas multidimensional). The spesifikasi EOFsudah membuat gas tidak teramati, meskipun untuk menjadi berguna untuk penyederhanaan protokol, EOF harus menjadi wajib.
• Peningkatan analisis statis: saat ini kode EVM sulit untuk dianalisis secara statis, terutama karena lompatan bisa bersifat dinamis. Hal ini juga membuat implementasi EVM yang dioptimalkan menjadi lebih sulit untuk mengonversi kode EVM menjadi bahasa lain sebelum dikompilasi. Ini dapat diperbaiki denganmenghilangkan lonjakan dinamis(atau membuatnya jauh lebih mahal, misalnya biaya gas linear dalam jumlah total JUMPDESTs dalam kontrak). EOF melakukan ini, meskipun mendapatkan keuntungan penyederhanaan protokol dari ini akan memerlukan membuat EOF menjadi wajib.

Apa beberapa tautan ke penelitian yang ada?

• Langkah-langkah selanjutnya dalam Pembersihan:https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• SELFDESTRUCT:@vbuterin/merusak diri sendiri"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-ifikasi EIPS: [1] [2] [3]
• Perubahan biaya gas tanpa keadaan: https://eips.ethereum.org/EIPS/eip-4762
• Penentuan harga memori linear: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Penghapusan pra-kompilasi: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Penghapusan filter Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Sebuah cara untuk melakukan pengambilan log yang aman di luar rantai menggunakan komputasi yang dapat diverifikasi secara bertahap (baca: STARKs rekursif):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Apa yang tersisa untuk dilakukan, dan apa saja kompromi yang ada?

Kompromi utama dalam melakukan penyederhanaan fitur semacam ini adalah (i) seberapa banyak kita menyederhanakan dan seberapa cepat vs (ii) kompatibilitas mundur. Nilai Ethereum sebagai rantai berasal dari menjadi platform di mana Anda dapat mendeploy aplikasi dan yakin bahwa itu masih akan berfungsi bertahun-tahun ke depan. Pada saat yang sama, mungkin terlalu berlebihan untuk mengambil ideal itu terlalu jauh, dan,untuk menguraikan William Jennings Bryan, 'menghukum Ethereum pada salib kompatibilitas mundur'. Jika hanya ada dua aplikasi di seluruh Ethereum yang menggunakan fitur tertentu, dan satu telah tidak memiliki pengguna selama bertahun-tahun dan yang lainnya hampir tidak digunakan sama sekali dan mengamankan total nilai $57, maka kita harus menghapus fitur tersebut, dan jika perlu membayar korban $57 dari saku sendiri.

Masalah sosial yang lebih luas terletak pada menciptakan pipa standar untuk membuat perubahan yang melanggar kompatibilitas mundur non-darurat. Salah satu cara untuk mendekati ini adalah dengan memeriksa dan memperpanjang preseden yang ada, seperti proses SELFDESTRUCT. Pipa terlihat seperti berikut:

• Langkah 1: mulai berbicara tentang menghapus fitur X
• Langkah 2: melakukan analisis untuk mengidentifikasi seberapa banyak penghapusan X mengganggu aplikasi, tergantung pada hasilnya baik (i) mengabaikan ide tersebut, (ii) melanjutkan sesuai rencana, atau (iii) mengidentifikasi cara modifikasi “kurang mengganggu” untuk menghapus X dan melanjutkan dengan cara tersebut
• Langkah 3: buat EIP resmi untuk menghentikan penggunaan X. Pastikan infrastruktur tingkat tinggi yang populer (misalnya, bahasa pemrograman, dompet) menghormati hal ini dan berhenti menggunakan fitur tersebut.
• Langkah 4: akhirnya, benar-benar hapus X

Seharusnya ada pipa selama bertahun-tahun antara langkah 1 dan langkah 4, dengan informasi yang jelas tentang barang-barang apa yang berada di langkah mana. Pada saat itu, ada tradeoff antara seberapa giat dan cepat pipa penghilangan fitur ini, dibandingkan dengan lebih konservatif dan mengalokasikan lebih banyak sumber daya ke area pengembangan protokol lainnya, tetapi kita masih jauh dari garis Pareto.

EOF

Seperangkat perubahan besar yang telah diajukan untuk EVM adalah Format Objek EVM (EOF). EOF memperkenalkan sejumlah perubahan, seperti melarang observabilitas gas, observabilitas kode (yaitu tidak ada CODECOPY), memungkinkan hanya lompatan statis. Tujuannya adalah untuk memungkinkan EVM ditingkatkan lebih banyak, dengan cara yang memiliki properti yang lebih kuat, sambil mempertahankan kompatibilitas mundur (karena EVM sebelum EOF masih akan ada).

Ini memiliki keuntungan bahwa itu menciptakan jalur alami untuk menambahkan fitur EVM baru dan mendorong migrasi ke EVM yang lebih restriktif dengan jaminan yang lebih kuat. Ini memiliki kelemahan bahwa itu secara signifikan meningkatkan kompleksitas protokol, kecuali jika kita dapat menemukan cara untuk akhirnya menonaktifkan dan menghapus EVM lama. Pertanyaan utama adalah: peran apa yang dimainkan EOF dalam proposal penyederhanaan EVM, terutama jika tujuannya adalah untuk mengurangi kompleksitas EVM secara keseluruhan?

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Banyak dari proposal “perbaikan” dalam sisa peta jalan juga merupakan kesempatan untuk melakukan penyederhanaan fitur-fitur lama. Untuk mengulangi beberapa contoh dari atas:

• Beralih ke finalitas slot tunggal memberi kita kesempatan untuk menghapus komite, mengerjakan ulang ekonomi, dan melakukan penyederhanaan terkait bukti saham lainnya.
• Menerapkan abstraksi akun sepenuhnya memungkinkan kami menghapus banyak logika penanganan transaksi yang ada, dengan memindahkannya ke bagian "kode EVM akun default" yang dapat diganti oleh semua EOA.
• Jika kita memindahkan keadaan Ethereum ke dalam pohon hash biner, ini dapat disesuaikan dengan versi baru SSZ, sehingga semua struktur data Ethereum dapat di-hash dengan cara yang sama.

Sebuah pendekatan yang lebih radikal: ubah bagian-bagian besar dari protokol menjadi kode kontrak

Strategi penyederhanaan Ethereum yang lebih radikal adalah tetap menjaga protokol yang ada, tetapi memindahkan sebagian besar fitur protokol menjadi kode kontrak.

Versi paling ekstrim dari ini akan membuat Ethereum L1 "secara teknis" hanya menjadi rantai beacon, dan memperkenalkan VM minimal (misalnya. RISC-V, Kairo, atau sesuatu yang lebih minimal khusus untuk membuktikan sistem) yang memungkinkan siapa pun untuk membuat rollup mereka sendiri. EVM kemudian akan berubah menjadi yang pertama dari rollup-rollup ini. Ironisnya, ini sama persis dengan hasil yang sama seperti sebelumnya.usulan lingkungan pelaksanaan dari 2019-20, meskipun SNARK membuatnya jauh lebih layak untuk benar-benar diimplementasikan.

Pendekatan yang lebih moderat adalah menjaga hubungan antara rantai beacon dan lingkungan eksekusi Ethereum saat ini seperti adanya, tetapi melakukan penggantian EVM di tempat. Kita bisa memilih RISC-V, Cairo, atau VM lainnya untuk menjadi "VM Ethereum resmi" baru, dan kemudian memaksa mengonversi semua kontrak EVM menjadi kode new-VM yang menafsirkan logika kode asli (dengan mengompilasi atau menafsirkannya). Secara teori, bahkan ini dapat dilakukan dengan "VM target" menjadi versi EOF.

Disclaimer：

1. Artikel ini dicetak ulang dari [Vitalik Buterin], Semua hak cipta dimiliki oleh penulis asli [Vitalik Buterin]. Jika ada keberatan terhadap cetakan ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan pendapat yang terdapat dalam artikel ini sepenuhnya merupakan milik penulis dan tidak merupakan nasihat investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Belajar gate. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.