Artikel baru Vitalik: Kemungkinan masa depan Ethereum (V) — The Purge

Judul asli: Kemungkinan masa depan protokol Ethereum, bagian 5: Pembersihan

Artikel asli oleh Vitalik Buterin

Terjemahan asli: Odaily Planet Daily Husband Bagaimana

Sejak 14 Oktober, pendiri Ethereum Vitalik Buterin telah berturut-turut menerbitkan diskusi tentang kemungkinan masa depan Ethereum. Dari Penggabungan , Gelombang , Bencana , The Verge ke rilis terbaru Pembersihan , semuanya menyoroti visi Vitaliks untuk pengembangan mainnet Ethereum di masa mendatang dan cara memecahkan masalah saat ini. Solusi.

Penggabungan: Membahas perlunya Ethereum untuk meningkatkan finalitas slot tunggal dan menurunkan ambang batas taruhan setelah berpindah ke PoS untuk meningkatkan partisipasi dan mempercepat konfirmasi transaksi.

The Surge: Menjelajahi berbagai strategi untuk meningkatkan skala Ethereum, khususnya peta jalan yang berpusat pada Rollup, serta tantangan dan solusinya dalam hal skalabilitas, desentralisasi, dan keamanan.

The Scourge: Menjelajahi risiko sentralisasi dan ekstraksi nilai yang dihadapi Ethereum dalam transisinya ke PoS, mengembangkan berbagai mekanisme untuk meningkatkan desentralisasi dan keadilan, serta mereformasi ekonomi staking untuk melindungi kepentingan pengguna.

The Verge: Menjelajahi tantangan dan solusi verifikasi stateless Ethereum, dengan fokus pada bagaimana teknologi seperti pohon Verkle dan STARK dapat meningkatkan desentralisasi dan efisiensi blockchain.

Pada tanggal 26 Oktober, Vitalik Buterin menerbitkan sebuah artikel tentang The Purge, yang membahas tantangan yang dihadapi Ethereum, yaitu bagaimana mengurangi kompleksitas dan persyaratan penyimpanan dalam jangka panjang sambil mempertahankan ketahanan dan desentralisasi rantai. Langkah-langkah utama meliputi pengurangan beban penyimpanan klien melalui kedaluwarsa riwayat dan kedaluwarsa status, dan penyederhanaan protokol melalui pembersihan fitur untuk memastikan keberlanjutan dan skalabilitas jaringan.

Berikut ini adalah konten asli yang diterjemahkan oleh Odaily Planet Daily.

Ucapan terima kasih khusus kepada Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden, dan Tomasz Stanczak atas masukan dan ulasan mereka.

Salah satu tantangan dengan Ethereum adalah, secara default, protokol blockchain apa pun akan bertambah besar dan kompleks seiring waktu. Hal ini terjadi di dua tempat:

• Data historis: Setiap transaksi yang dilakukan dan setiap akun yang dibuat pada titik mana pun dalam sejarah perlu disimpan secara permanen oleh semua klien dan diunduh oleh setiap klien baru agar dapat disinkronkan sepenuhnya ke jaringan. Hal ini menyebabkan beban klien dan waktu sinkronisasi meningkat seiring waktu, meskipun kapasitas rantai tetap konstan.

• Fitur protokol: Jauh lebih mudah untuk menambahkan fitur baru daripada menghapus yang lama, menyebabkan kompleksitas kode meningkat seiring waktu.

Agar Ethereum dapat berkelanjutan dalam jangka panjang, kita perlu memberikan tekanan balik yang kuat terhadap kedua tren ini, mengurangi kompleksitas dan pembengkakan seiring berjalannya waktu. Namun pada saat yang sama, kita perlu mempertahankan salah satu properti utama yang membuat blockchain hebat: daya tahan. Anda dapat meletakkan NFT, surat cinta dalam data panggilan transaksi, atau kontrak pintar dengan $1 juta pada rantai, masuk ke gua selama sepuluh tahun, dan keluar untuk menemukannya masih di sana menunggu Anda untuk membaca dan berinteraksi dengannya. Agar DApps merasa nyaman sepenuhnya mendesentralisasi dan menghapus kunci pemutakhiran, mereka perlu yakin bahwa dependensi mereka tidak akan dimutakhirkan dengan cara yang merusaknya – terutama L1 itu sendiri.

Sangat mungkin untuk mencapai keseimbangan antara kedua kebutuhan ini dan meminimalkan atau membalikkan pembengkakan, kompleksitas, dan pembusukan sambil mempertahankan kesinambungan jika kita bertekad untuk melakukannya. Organisme dapat melakukan ini: sementara sebagian besar organisme menua seiring waktu, hanya sedikit yang beruntung Bahkan sistem sosial pun bisa memiliki rentang hidup yang sangat panjang . Ethereum telah berhasil dalam beberapa kasus: bukti kerja telah hilang, opcode SELFDESTRUCT sebagian besar telah hilang, dan node rantai suar telah menyimpan data yang berusia hingga enam bulan. Mencari tahu jalur ini untuk Ethereum dengan cara yang lebih umum, dan menuju hasil akhir yang stabil dalam jangka panjang, adalah tantangan utama bagi skalabilitas jangka panjang Ethereum, keberlanjutan teknis, dan bahkan keamanan.

Pembersihan: Tujuan utama.

• Persyaratan penyimpanan klien yang lebih rendah dengan mengurangi atau menghilangkan kebutuhan setiap node untuk menyimpan semua riwayat atau bahkan status akhir secara permanen.

• Kurangi kompleksitas protokol dengan menghilangkan fungsionalitas yang tidak diperlukan.

Direktori Artikel:

• Riwayat kedaluwarsa

• Kedaluwarsa negara

• Pembersihan fitur

Riwayat kedaluwarsa

Masalah apa yang dipecahkannya?

Pada saat tulisan ini dibuat, node Ethereum yang tersinkronisasi sepenuhnya memerlukan sekitar 1,1TB ruang disk untuk klien eksekusi , dan ratusan GB lagi untuk klien konsensus. Sebagian besarnya adalah sejarah: data tentang blok, transaksi, dan penerimaan historis, yang sebagian besarnya sudah berumur bertahun-tahun. Ini berarti bahwa meskipun batas gas tidak bertambah sama sekali, ukuran node akan terus bertambah hingga ratusan GB per tahun.

Apa itu dan bagaimana cara kerjanya?

Fitur penyederhanaan utama dari masalah penyimpanan sejarah adalah karena setiap blok menunjuk ke blok sebelumnya melalui tautan hash (dan lainnya struktur ), konsensus mengenai masa kini sudah cukup untuk mencapai konsensus mengenai sejarah. Selama jaringan menyetujui blok terbaru, setiap blok atau transaksi atau status historis (saldo akun, nomor acak, kode, penyimpanan) dapat diberikan oleh setiap peserta tunggal bersama dengan bukti Merkle, dan bukti tersebut memungkinkan siapa pun untuk memverifikasi kebenarannya. Konsensus adalah model kepercayaan N/2-dari-N, sedangkan sejarah adalah model kepercayaan N-of-N .

Hal ini memberi kita banyak pilihan tentang cara kita menyimpan riwayat. Salah satu pilihan yang wajar adalah jaringan tempat setiap simpul hanya menyimpan sebagian kecil data. Beginilah cara jaringan Seed beroperasi selama beberapa dekade: sementara jaringan menyimpan dan mendistribusikan jutaan file secara total, setiap peserta hanya menyimpan dan mendistribusikan beberapa di antaranya. Mungkin berlawanan dengan intuisi, pendekatan ini bahkan tidak serta merta mengurangi ketahanan data. Jika, dengan membuatnya lebih terjangkau untuk menjalankan simpul, kita dapat membangun jaringan dengan 100.000 simpul, tempat setiap simpul menyimpan 10% acak dari riwayat, maka setiap bagian data akan direplikasi 10.000 kali – faktor replikasi yang sama persis dengan jaringan 10.000 simpul, tempat setiap simpul menyimpan semuanya.

Saat ini, Ethereum mulai menjauh dari model di mana semua node menyimpan semua riwayat secara permanen. Blok konsensus (yaitu bagian yang terkait dengan konsensus proof-of-stake) hanya disimpan selama sekitar 6 bulan. Blob hanya disimpan selama sekitar 18 hari. EIP-4444 bertujuan untuk memperkenalkan periode penyimpanan satu tahun untuk blok dan tanda terima historis. Sasaran jangka panjangnya adalah untuk menetapkan periode yang seragam (mungkin sekitar 18 hari) di mana setiap node bertanggung jawab untuk menyimpan semuanya, dan kemudian membangun jaringan peer-to-peer node Ethereum yang menyimpan data lama dalam jaringan terdistribusi.

Kode penghapusan dapat digunakan untuk meningkatkan ketahanan sekaligus menjaga faktor replikasi tetap sama. Faktanya, blob sudah dikodekan untuk mendukung pengambilan sampel ketersediaan data. Solusi paling sederhana mungkin adalah menggunakan kembali kode penghapusan tersebut dan memasukkan data blok eksekusi dan konsensus ke dalam blob juga.

Apa hubungannya dengan penelitian yang ada?

• EIP-4444 ;

• Torrent dan EIP-4444 ;

• Jaringan portal ;

• Jaringan Portal dan EIP-4444 ;

• Penyimpanan dan pengambilan objek SSZ terdistribusi di Portal ;

• Cara meningkatkan batas gas (Paradigma) .

Apa lagi yang perlu dilakukan dan apa saja pengorbanan yang perlu dilakukan?

Pekerjaan utama yang tersisa melibatkan pembangunan dan pengintegrasian solusi terdistribusi konkret untuk menyimpan riwayat – setidaknya riwayat eksekusi, tetapi pada akhirnya konsensus dan blob juga. Solusi paling sederhana adalah (i) cukup dengan membawa pustaka torrent yang ada, dan (ii) solusi asli Ethereum yang disebut Jaringan portal . Setelah salah satu dari keduanya diperkenalkan, kita dapat mengaktifkan EIP-4444. EIP-4444 sendiri tidak memerlukan hard fork, tetapi memerlukan versi protokol jaringan yang baru. Oleh karena itu, penting untuk mengaktifkannya untuk semua klien secara bersamaan, jika tidak, ada risiko klien gagal karena mereka terhubung ke node lain dengan harapan mengunduh riwayat lengkap tetapi sebenarnya tidak mendapatkannya.

Kompromi utamanya melibatkan seberapa keras kita bekerja untuk menyediakan data sejarah "kuno". Solusi paling sederhana adalah berhenti menyimpan sejarah kuno besok dan mengandalkan node arsip yang ada dan berbagai penyedia terpusat untuk replikasi. Ini mudah, tetapi melemahkan Ethereum sebagai tempat penyimpanan permanen. Jalan yang lebih sulit tetapi lebih aman adalah membangun dan mengintegrasikan jaringan torrent terlebih dahulu untuk menyimpan sejarah secara terdistribusi. Di sini, "seberapa keras kita bekerja" memiliki dua dimensi:

1. Bagaimana kita memastikan bahwa kumpulan node terbesar benar-benar menyimpan semua data?

2. Seberapa dalam kita mengintegrasikan penyimpanan riwayat ke dalam protokol?

Pendekatan yang sangat paranoid terhadap (1) akan melibatkan bukti hak asuh : secara efektif mengharuskan setiap validator proof-of-stake untuk menyimpan persentase tertentu dari sejarah, dan secara berkala kriptomemeriksa secara grafis bahwa mereka melakukannya. Pendekatan yang lebih moderat adalah menetapkan standar sukarela untuk persentase riwayat yang disimpan setiap klien.

Untuk (2), implementasi dasar hanya melibatkan pekerjaan yang sudah dilakukan saat ini: Portal sudah menyimpan berkas ERA yang berisi seluruh riwayat Ethereum. Implementasi yang lebih menyeluruh akan melibatkan penyambungan berkas tersebut ke proses sinkronisasi, sehingga jika seseorang ingin menyinkronkan simpul penyimpanan riwayat lengkap atau simpul arsip, mereka dapat melakukannya dengan menyinkronkan langsung dari jaringan Portal, meskipun tidak ada simpul arsip lain yang tersedia secara daring.

Bagaimana interaksinya dengan peta jalan lainnya?

Jika kita ingin membuatnya sangat mudah untuk menjalankan atau menjalankan node, maka mengurangi persyaratan penyimpanan riwayat bisa dibilang lebih penting daripada statelessness: dari 1,1 TB yang dibutuhkan node, ~300 GB adalah status, dan ~800 GB sisanya adalah riwayat. Hanya dengan statelessness dan EIP-4444 kita dapat mencapai visi menjalankan node Ethereum pada jam tangan pintar dan menyiapkannya hanya dalam hitungan menit.
Pembatasan penyimpanan historis juga membuat implementasi node Ethereum yang lebih baru lebih memungkinkan untuk hanya mendukung versi protokol terbaru, yang membuatnya jauh lebih sederhana. Misalnya, banyak baris kode sekarang dapat dihapus dengan aman karena slot penyimpanan kosong yang dibuat selama serangan DoS 2016 semuanya telah dihapus. dihapus Sekarang setelah peralihan ke proof-of-stake sudah menjadi masa lalu, klien dapat dengan aman menghapus semua kode yang terkait dengan proof-of-work.

Kedaluwarsa negara

Masalah apa yang dipecahkannya?

Bahkan jika kami menghilangkan kebutuhan klien untuk menyimpan riwayat, kebutuhan penyimpanan klien akan terus bertambah, sekitar 50 GB per tahun, seiring terus berkembangnya status: saldo akun dan nonce, kode kontrak, dan penyimpanan kontrak. Pengguna dapat membayar biaya satu kali, sehingga membebani klien Ethereum saat ini dan masa mendatang selamanya.

Status lebih sulit untuk kedaluwarsa daripada riwayat, karena EVM pada dasarnya dirancang berdasarkan asumsi bahwa setelah objek status dibuat, objek tersebut akan selalu ada dan dapat dibaca oleh transaksi apa pun kapan saja. Jika kita memperkenalkan statelessness, beberapa orang berpikir bahwa masalah ini mungkin tidak terlalu buruk: hanya kelas pembangun blok khusus yang perlu benar-benar menyimpan status, dan semua node lainnya (bahkan pembuatan daftar!) dapat berjalan tanpa status. Namun, ada argumen bahwa kita tidak ingin terlalu bergantung pada statelessness, dan pada akhirnya kita mungkin ingin mengakhiri status untuk menjaga Ethereum tetap terdesentralisasi.

Apa itu dan bagaimana cara kerjanya?

Saat ini, saat Anda membuat objek status baru (yang dapat terjadi dalam salah satu dari tiga cara: (i) mengirim ETH ke akun baru, (ii) membuat akun baru menggunakan kode, (iii) menyiapkan slot penyimpanan yang sebelumnya tidak tersentuh), objek status tersebut akan tetap berada dalam status tersebut selamanya. Sebaliknya, yang kami inginkan adalah objek tersebut secara otomatis kedaluwarsa seiring berjalannya waktu. Tantangan utamanya adalah melakukan ini dengan cara yang mencapai tiga tujuan:

1. Efisiensi: Tidak diperlukan perhitungan tambahan dalam jumlah besar untuk menjalankan proses kedaluwarsa.

2. Keramahan pengguna: Jika seseorang masuk ke gua selama lima tahun dan kembali lagi, mereka tidak akan kehilangan akses ke posisi ETH, ERC 20, NFT, CDP mereka…

3. Keramahan bagi pengembang: Pengembang tidak perlu beralih ke model mental yang sama sekali tidak dikenal. Selain itu, aplikasi yang saat ini kaku dan tidak diperbarui akan tetap berfungsi dengan baik.

Mudah untuk memecahkan masalah yang tidak memenuhi tujuan ini. Misalnya, Anda dapat membuat setiap objek status juga menyimpan penghitung tanggal kedaluwarsa (tanggal kedaluwarsa dapat diperpanjang dengan membakar ETH, yang dapat terjadi secara otomatis setiap kali dibaca atau ditulis), dan memiliki proses yang mengulang status untuk menghapus objek status yang kedaluwarsa. Namun, ini memperkenalkan komputasi tambahan (dan bahkan persyaratan penyimpanan), dan itu tentu saja tidak memenuhi persyaratan keramahan pengguna. Sulit juga bagi pengembang untuk bernalar tentang kasus tepi yang melibatkan nilai tersimpan yang terkadang disetel ulang ke nol. Jika Anda mengatur pengatur waktu kedaluwarsa dalam lingkup kontrak, ini membuat kehidupan pengembang lebih mudah secara teknis, tetapi membuat ekonomi lebih sulit: pengembang harus berpikir tentang cara meneruskan biaya penyimpanan yang sedang berlangsung kepada pengguna.

Ini adalah masalah yang telah dikerjakan oleh komunitas pengembangan inti Ethereum selama bertahun-tahun, termasuk proposal seperti “ sewa blockchain " Dan " regenerasi “Akhirnya, kami menggabungkan bagian terbaik dari proposal tersebut dan berfokus pada dua kategori “solusi yang paling tidak buruk”:

• Solusi kedaluwarsa status parsial

• Rekomendasi kedaluwarsa negara bagian berdasarkan siklus alamat.

Kedaluwarsa status sebagian

Semua usulan kedaluwarsa status parsial mengikuti prinsip yang sama. Kami membagi status menjadi beberapa bagian. Setiap bagian secara permanen menyimpan peta tingkat atas yang bagiannya kosong atau tidak kosong. Data dalam setiap bagian hanya disimpan jika data tersebut baru saja diakses. Ada mekanisme kebangkitan yang menghidupkan kembali bagian tersebut jika tidak lagi disimpan.

Perbedaan utama antara proposal-proposal ini adalah: (i) bagaimana kita defi(ii) bagaimana kita mendefinisikan “blok”? Salah satu proposal spesifiknya adalah EIP-7736 , yang dibangun berdasarkan desain “batang dan daun” diperkenalkan untuk pohon Verkle (meskipun kompatibel dengan bentuk stateless apa pun, seperti pohon biner). Dalam desain ini, header, kode, dan slot penyimpanan yang berdekatan satu sama lain disimpan di bawah "trunk" yang sama. Data yang disimpan di bawah stem dapat mencapai 256 * 31 = 7.936 byte. Dalam banyak kasus, seluruh header dan kode akun, serta banyak slot penyimpanan kunci, akan disimpan di bawah trunk yang sama. Jika data di bawah trunk tertentu belum dibaca atau ditulis selama 6 bulan, data tersebut tidak lagi disimpan, dan hanya komitmen 32-byte ("stub") untuk data tersebut yang disimpan. Transaksi mendatang yang mengakses data tersebut perlu "menghidupkan kembali" data tersebut dan memberikan bukti bahwa data tersebut cocok dengan stub.

Ada cara lain untuk menerapkan ide serupa. Misalnya, jika tingkat ketelitian tingkat akun tidak cukup, kita dapat membuat skema di mana setiap 1/2 bagian dari pohon dikontrol oleh mekanisme batang dan daun yang serupa.

Hal ini menjadi lebih rumit karena adanya insentif: seorang penyerang dapat memaksa klien untuk menyimpan sejumlah besar status secara permanen dengan memasukkan sejumlah besar data ke dalam satu subpohon dan mengirimkan satu transaksi setiap tahun untuk memperbarui pohon tersebut. Jika Anda membuat biaya pembaruan proporsional dengan ukuran pohon (atau berbanding terbalik dengan durasi pembaruan), maka seseorang berpotensi membahayakan pengguna lain dengan memasukkan sejumlah besar data ke dalam subpohon yang sama dengan mereka. Seseorang dapat mencoba untuk membatasi kedua masalah ini dengan membuat granularitas dinamis sehubungan dengan ukuran subpohon: misalnya, setiap 216 = 65536 objek status yang berurutan dapat dianggap sebagai suatu kelompok. Namun, ide-ide ini lebih kompleks; pendekatan berbasis stem sederhana, dan insentif dapat diselaraskan karena biasanya semua data di bawah stem terkait dengan aplikasi atau pengguna yang sama.

Rekomendasi kedaluwarsa status berdasarkan siklus alamat

Bagaimana jika kita ingin menghindari pertumbuhan status permanen sama sekali, bahkan rintisan 32-byte? Ini adalah masalah yang sulit karena konflik kebangkitan : bagaimana jika objek status dihapus, dan kemudian eksekusi EVM menempatkan objek status lain di tempat yang sama persis, tetapi kemudian seseorang yang peduli dengan objek status asli kembali dan mencoba memulihkannya? Ketika bagian dari status kedaluwarsa, stub mencegah data baru dibuat. Dengan status yang sepenuhnya kedaluwarsa, kita bahkan tidak dapat menyimpan stub.

Desain berbasis siklus alamat merupakan ide yang paling terkenal untuk memecahkan masalah ini. Alih-alih memiliki satu pohon status yang menyimpan seluruh status, kita memiliki daftar pohon status yang terus bertambah, dan status apa pun yang dibaca atau ditulis disimpan di pohon status terbaru. Pohon status kosong baru ditambahkan sekali setiap epoch (misalnya: 1 tahun). Pohon lama dibekukan. Node penuh hanya menyimpan dua pohon terbaru. Jika objek status belum disentuh dalam dua epoch dan dengan demikian jatuh ke pohon kedaluwarsa, objek tersebut masih dapat dibaca atau ditulis, tetapi transaksi perlu membuktikan bukti Merkle-nya – setelah terbukti, salinannya disimpan lagi di pohon terbaru.

Gagasan utama yang membuat ini ramah bagi pengguna dan pengembang adalah konsep periode alamat. Periode alamat adalah angka yang merupakan bagian dari suatu alamat. Aturan utamanya adalah bahwa suatu alamat dengan periode alamat N hanya dapat dibaca dari atau ditulis selama atau setelah periode N (yaitu, ketika daftar pohon status mencapai panjang N). Jika Anda menyimpan objek status baru (misalnya, kontrak baru, atau saldo ERC 20 baru), jika Anda memastikan Anda memasukkan objek status ke dalam kontrak dengan periode alamat N atau N-1, maka Anda dapat menyimpannya segera, tanpa harus memberikan bukti bahwa tidak ada yang terjadi sebelumnya. Di sisi lain, setiap penambahan atau penyuntingan yang dilakukan selama periode alamat lama akan memerlukan bukti.

Desain ini mempertahankan sebagian besar properti Ethereum saat ini, tidak memerlukan komputasi tambahan, memungkinkan aplikasi ditulis hampir seperti sekarang (ERC 20 perlu ditulis ulang untuk memastikan bahwa saldo alamat dengan siklus alamat N disimpan dalam subkontrak, yang memiliki siklus alamat N), dan memecahkan masalah pengguna dalam gua selama lima tahun. Namun, ada masalah besar: alamat perlu diperluas hingga lebih dari 20 byte untuk mengakomodasi siklus alamat.

Ekstensi ruang alamat

Salah satu usulannya adalah memperkenalkan format alamat 32-byte baru yang mencakup nomor versi, nomor siklus alamat, dan hash yang diperluas.

0x 01 (merah) 0000 (oranye) 000001 (hijau) 57 Bahasa Inggris: aE 408398 dF 7 Bahasa Inggris 5 F 4552091 A 69125 d5 FWf 7 B 8 C 2659029395 bdF (biru).

Yang merah adalah nomor versi. Empat angka nol oranye di sini dimaksudkan sebagai ruang kosong yang dapat menampung nomor shard di masa mendatang. Yang hijau adalah nomor siklus alamat. Yang biru adalah nilai hash 26-byte.

Tantangan utama di sini adalah kompatibilitas mundur. Kontrak yang ada dirancang berdasarkan alamat 20-byte, dan sering kali menggunakan teknik pengemasan byte yang ketat yang secara eksplisit mengasumsikan alamat memiliki panjang tepat 20 byte. Satu ide untuk mengatasi hal ini melibatkan pemetaan konversi, di mana kontrak lama yang berinteraksi dengan alamat gaya baru akan melihat hash 20-byte dari alamat gaya baru tersebut. Namun, ada kerumitan yang signifikan dalam memastikan keamanannya.

Penyusutan ruang alamat

Pendekatan lain berjalan ke arah yang berlawanan: kita segera melarang beberapa subrentang ukuran 2 128 (misalnya, semua alamat yang dimulai dengan 0x ffffffff ), dan kemudian menggunakan rentang tersebut untuk memperkenalkan alamat dengan siklus alamat dan nilai hash 14-byte.

0x ffffffff 000169125 d5 FWf 7 B 8 C2659029395bdF

Pengorbanan utama yang dilakukan oleh pendekatan ini adalah risiko keamanan dalam memperkenalkan alamat kontrafaktual : alamat yang menyimpan aset atau izin tetapi kodenya belum dipublikasikan ke rantai. Risikonya melibatkan seseorang yang membuat alamat yang mengklaim memiliki sepotong kode (yang belum dipublikasikan), tetapi juga memiliki sepotong kode valid lain yang di-hash ke alamat yang sama. Menghitung tabrakan seperti itu saat ini memerlukan 2 80 hash; penyusutan ruang alamat akan mengurangi angka ini menjadi 2 56 hash yang mudah diakses.

Area risiko utama, alamat kontrafaktual untuk dompet yang tidak dimiliki oleh satu pemilik, relatif jarang saat ini, tetapi kemungkinan akan menjadi lebih umum saat kita memasuki dunia multi-L2. Satu-satunya solusi adalah menerima risiko ini, tetapi mengidentifikasi semua kasus penggunaan umum yang dapat menimbulkan kesalahan, dan menemukan solusi efektif.

Apa hubungannya dengan penelitian yang ada?

Proposal Awal

• Pembersihan blockchain ;

• regenerasi ;

• Teori manajemen ukuran negara Ethereum ;

• Beberapa kemungkinan jalan menuju keadaan tanpa kewarganegaraan dan berakhirnya status kewarganegaraan ;

Usulan Kedaluwarsa Status Sebagian

• EIP-7736 ;

Dokumentasi Ekstensi Ruang Alamat

• Proposal asli ;

• Ulasan Ipsilon ;

• Komentar postingan blog ;

• Apa yang akan rusak jika kita kehilangan ketahanan terhadap tabrakan? .

Apa lagi yang perlu dilakukan dan apa saja pengorbanan yang perlu dilakukan?

Saya melihat empat kemungkinan jalan ke depan:

• Kami membuatnya tanpa status, dan tidak pernah memperkenalkan kedaluwarsa status. Status tersebut terus bertambah (meskipun lambat: kami mungkin tidak akan melihatnya melebihi 8 TB selama beberapa dekade), tetapi hanya oleh kelas pengguna yang relatif khusus: bahkan validator PoS tidak memerlukan status.
  Satu fitur yang memerlukan akses ke bagian status adalah pembuatan daftar penyertaan, tetapi kita dapat melakukannya dengan cara yang terdesentralisasi: Setiap pengguna bertanggung jawab untuk memelihara bagian status yang berisi akun mereka sendiri. Saat mereka menyiarkan transaksi, mereka menyiarkannya bersama dengan bukti objek status yang diakses selama langkah verifikasi (ini berfungsi untuk akun EOA dan ERC-4337). Validator tanpa status kemudian dapat menggabungkan bukti-bukti ini menjadi bukti seluruh daftar penyertaan.

• Kami melakukan kedaluwarsa status parsial dan menerima tingkat pertumbuhan ukuran status permanen yang jauh lebih rendah tetapi masih bukan nol. Hasil ini dapat dikatakan serupa dengan bagaimana proposal kedaluwarsa riwayat yang melibatkan jaringan peer-to-peer menerima tingkat pertumbuhan penyimpanan riwayat permanen yang jauh lebih rendah tetapi masih bukan nol, di mana setiap klien harus menyimpan persentase data riwayat yang lebih rendah tetapi tetap.

• Kami sedang melakukan kedaluwarsa status melalui perluasan ruang alamat. Ini akan melibatkan proses beberapa tahun untuk memastikan metode konversi format alamat efektif dan aman, termasuk untuk aplikasi yang sudah ada.

• Kami melakukan kedaluwarsa status dengan mempersempit ruang alamat. Ini akan melibatkan proses selama beberapa tahun untuk memastikan bahwa semua risiko keamanan yang melibatkan konflik alamat (termasuk situasi lintas rantai) ditangani.

Hal yang penting adalah apakah skema kedaluwarsa status yang bergantung pada perubahan format alamat diterapkan atau tidak, masalah sulit perluasan dan penyusutan ruang alamat pada akhirnya harus dipecahkan. Saat ini, menghasilkan tabrakan alamat memerlukan sekitar 2 80 hash, dan beban komputasi ini sudah layak untuk aktor yang sangat banyak akal: GPU dapat melakukan sekitar 2 27 hash, sehingga dapat menghitung 2 52 dalam setahun, jadi semua sekitar 2 30 GPU di dunia dapat menghitung tabrakan dalam waktu sekitar 1/4 tahun, dan FPGA serta ASIC dapat mempercepat proses ini lebih jauh. Di masa mendatang, serangan semacam itu akan terbuka bagi semakin banyak orang. Oleh karena itu, biaya sebenarnya untuk menerapkan kedaluwarsa status penuh mungkin tidak setinggi yang terlihat, karena kita harus menyelesaikan masalah alamat yang sangat menantang ini.

Bagaimana interaksinya dengan peta jalan lainnya?

Melakukan kedaluwarsa status dapat mempermudah transisi dari satu format trie status ke format trie status lain, karena tidak diperlukan proses konversi: Anda cukup mulai membuat pohon baru dengan format baru, lalu melakukan hard fork untuk mengonversi pohon lama. Jadi, meskipun kedaluwarsa status itu rumit, ia memiliki manfaat menyederhanakan aspek lain dari peta jalan.

Pembersihan fitur

Masalah apa yang dipecahkannya?

Salah satu prasyarat utama untuk keamanan, aksesibilitas, dan netralitas tepercaya adalah kesederhanaan. Jika sebuah protokol indah dan sederhana, kecil kemungkinannya untuk memiliki bug. Ini meningkatkan kemungkinan bahwa pengembang baru akan dapat berpartisipasi dalam bagian mana pun darinya. Ini lebih mungkin menjadi adil dan lebih mudah untuk dipertahankan terhadap kepentingan khusus. Sayangnya, protokol, seperti sistem sosial lainnya, secara default akan menjadi lebih kompleks dari waktu ke waktu. Jika kita tidak ingin Ethereum jatuh ke dalam lubang hitam dengan kompleksitas yang meningkat, kita perlu melakukan salah satu dari dua hal: (i) berhenti membuat perubahan dan mengeraskan protokol, atau (ii) benar-benar dapat menghapus fitur dan mengurangi kompleksitas. Jalan tengah juga memungkinkan, membuat lebih sedikit perubahan pada protokol dan menghilangkan setidaknya sedikit kompleksitas dari waktu ke waktu. Bagian ini membahas cara mengurangi atau menghilangkan kompleksitas.

Apa itu dan bagaimana cara kerjanya?

Tidak ada perbaikan tunggal yang dapat mengurangi kompleksitas protokol; sifat masalahnya adalah terdapat banyak perbaikan kecil.

Salah satu contoh yang sudah hampir selesai, dan dapat dijadikan sebagai cetak biru untuk pendekatan terhadap contoh-contoh lainnya, adalah penghapusan opcode SELFDESTRUCT . Kode operasi SELFDESTRUCT adalah satu-satunya kode operasi yang dapat mengubah slot penyimpanan dalam jumlah tak terbatas dalam satu blok, yang mengharuskan klien untuk menerapkan kompleksitas yang jauh lebih tinggi guna menghindari serangan DoS. Tujuan awal kode operasi ini adalah untuk memungkinkan likuidasi status secara sukarela, yang memungkinkan ukuran status berkurang seiring waktu. Dalam praktiknya, hanya sedikit orang yang menggunakannya. Kode operasinya telah dikurangi untuk hanya mengizinkan akun yang dapat merusak diri sendiri yang dibuat dalam transaksi yang sama dengan hard fork Dencun. Ini memecahkan masalah DoS dan dapat menyederhanakan kode klien secara signifikan. Di masa mendatang, mungkin masuk akal untuk menghapus opcode sepenuhnya.

Beberapa contoh utama peluang penyederhanaan protokol yang telah diidentifikasi hingga saat ini meliputi hal-hal berikut. Pertama, beberapa contoh di luar EVM; hal ini relatif tidak invasif dan karenanya lebih mudah untuk mencapai konsensus dan menerapkannya dalam waktu yang lebih singkat.

• Konversi RLP → SSZ: Awalnya, objek Ethereum diserialisasi menggunakan pengkodean yang disebut Bahasa Inggris RLP . RLP tidak diketik dan terlalu rumit. Saat ini, rantai suar menggunakan SSZ , yang jauh lebih baik dalam banyak hal, termasuk mendukung tidak hanya serialisasi tetapi juga hashing. Akhirnya, kami berharap untuk menyingkirkan RLP sepenuhnya dan memindahkan semua tipe data ke struktur SSZ, yang pada gilirannya akan membuat peningkatan jauh lebih mudah. EIP saat ini mencakup [1] [2] [3] .

• Menghapus jenis transaksi lama: Saat ini ada terlalu banyak jenis transaksi, dan banyak di antaranya yang berpotensi dihapus. Alternatif yang lebih sederhana untuk penghapusan total adalah fitur abstraksi akun, di mana Akun Pintar dapat berisi kode untuk menangani dan memvalidasi transaksi lama jika diinginkan.

• Reformasi LOG: Filter bloom pembuatan log dan logika lainnya menambah kompleksitas pada protokol, tetapi sebenarnya tidak digunakan oleh klien karena terlalu lambat. Kita dapat hapus fitur ini dan mengerjakan alternatif, seperti alat pembacaan log terdesentralisasi di luar protokol yang menggunakan teknologi modern seperti SNARK.

• Akhirnya menghapus mekanisme Komite Sinkronisasi Rantai Beacon: Mekanisme Komite Sinkronisasi awalnya diperkenalkan untuk memungkinkan verifikasi klien ringan untuk Ethereum. Namun, hal ini secara signifikan meningkatkan kompleksitas protokol. Pada akhirnya, kita akan dapat verifikasi lapisan konsensus Ethereum secara langsung menggunakan SNARK , yang akan menghilangkan kebutuhan akan protokol verifikasi klien ringan khusus. Secara potensial, perubahan konsensus dapat memungkinkan kita untuk menghapus Komite Sinkronisasi lebih awal dengan membuat protokol klien ringan yang lebih asli yang melibatkan verifikasi tanda tangan dari subset acak validator konsensus Ethereum.

• Penyatuan format data: Saat ini, status eksekusi disimpan di pohon Merkle Patricia, status konsensus disimpan di Pohon SSZ , dan gumpalan dilakukan melalui Komitmen KZG . Di masa mendatang, akan lebih masuk akal untuk memiliki satu format terpadu untuk data blok dan satu format terpadu untuk status. Format-format ini akan memenuhi semua persyaratan penting: (i) pembuktian sederhana untuk klien tanpa status, (ii) serialisasi dan pengodean penghapusan data, dan (iii) struktur data yang terstandarisasi.

• Menghapus Komite Rantai Beacon: Mekanisme ini awalnya diperkenalkan untuk mendukung versi spesifik dari sharding eksekusi Sebaliknya, kami akhirnya melakukan sharding melalui L2 dan gumpalan Oleh karena itu, komite tersebut tidak diperlukan, jadi langkah untuk menghilangkannya sedang dilakukan .

• Hapus mixed endianness: EVM adalah big endian, lapisan konsensus adalah little endian. Mungkin masuk akal untuk menyesuaikan dan menjadikan semuanya satu arah atau yang lain (mungkin big endian, karena EVM lebih sulit diubah)

Sekarang, beberapa contoh dalam EVM:

• Penyederhanaan mekanisme gas: Aturan gas saat ini tidak dioptimalkan dengan baik untuk memberikan batasan yang jelas pada jumlah sumber daya yang diperlukan untuk memvalidasi blok. Contoh utama dari hal ini meliputi (i) biaya baca/tulis penyimpanan, yang dimaksudkan untuk membatasi jumlah baca/tulis dalam blok tetapi saat ini cukup arbitrer, dan (ii) aturan penambahan memori, yang saat ini sulit untuk memperkirakan konsumsi memori maksimum EVM. Perbaikan yang diusulkan meliputi perubahan biaya gas tanpa kewarganegaraan (yang menyatukan semua biaya terkait penyimpanan menjadi formula sederhana) dan proposal harga memori .

• Menghapus prakompilasi: Banyak prakompilasi yang dimiliki Ethereum saat ini terlalu rumit dan relatif jarang digunakan, serta menjadi penyebab sebagian besar kegagalan konsensus saat jarang digunakan oleh aplikasi apa pun. Dua cara untuk mengatasinya adalah (i) cukup menghapus prakompilasi, dan (ii) menggantinya dengan kode EVM (yang pasti lebih mahal) yang menerapkan logika yang sama. Draf EIP ini mengusulkan untuk melakukan ini untuk prakompilasi identitas sebagai langkah pertama; kemudian, RIPEMD 160, MODEXP, dan BLAKE mungkin menjadi kandidat untuk dihapus.

• Hapus observabilitas gas: Jadikan eksekusi EVM tidak dapat lagi melihat berapa banyak gas yang tersisa. Ini akan merusak beberapa aplikasi (terutama transaksi yang disponsori), tetapi akan membuatnya lebih mudah untuk ditingkatkan di masa mendatang (misalnya ke versi yang lebih canggih dengan gas multidimensi ). Spesifikasi EOF sudah membuat gas tidak dapat diamati, tetapi untuk menyederhanakan protokol, EOF perlu menjadi wajib.

• Peningkatan pada analisis statis: Kode EVM sulit dianalisis secara statis saat ini, terutama karena lompatan dapat bersifat dinamis. Hal ini juga mempersulit pengoptimalan implementasi EVM (melakukan prakompilasi kode EVM ke dalam bahasa lain). Kita dapat memperbaikinya dengan menghapus lompatan dinamis (atau membuatnya lebih mahal, misalnya, biaya gas linear dari jumlah total JUMPDEST dalam suatu kontrak). EOF melakukan hal itu, meskipun penerapan EOF diperlukan untuk memperoleh manfaat penyederhanaan protokol darinya.

Apa hubungannya dengan penelitian yang ada?

• Langkah selanjutnya untuk penghapusan ;

• Menghancurkan diri sendiri

• EIPS berbasis SSZ: [1] [2] [3] ;

• Perubahan biaya gas tanpa kewarganegaraan ;

• Harga memori linier ;

• Penghapusan prakompilasi ;

• Filter Bloom dihapus ;

• Suatu metode untuk pengambilan log aman di luar rantai menggunakan komputasi yang dapat diverifikasi secara bertahap (baca: STARK rekursif);

Apa lagi yang perlu dilakukan dan apa saja pengorbanan yang perlu dilakukan?

Pertimbangan utama dalam melakukan penyederhanaan fitur semacam ini adalah (i) seberapa banyak dan seberapa cepat kita menyederhanakan vs. (ii) kompatibilitas mundur. Nilai Ethereum sebagai rantai berasal dari platform tempat Anda dapat menyebarkan aplikasi dan yakin bahwa aplikasi tersebut akan tetap berfungsi bertahun-tahun kemudian. Pada saat yang sama, cita-cita ini juga dapat diambil terlalu jauh dan, dalam kata-kata William Jennings Bryan , “paku Ethereum pada salib kompatibilitas mundur”. Jika hanya ada dua aplikasi di seluruh Ethereum yang menggunakan fitur tertentu, dan satu aplikasi tidak memiliki pengguna selama bertahun-tahun, sementara aplikasi lainnya hampir sepenuhnya tidak digunakan dan telah memperoleh total nilai $57, maka kita harus menghapus fitur tersebut dan membayar korban $57 dari kantongnya sendiri jika perlu.

Masalah masyarakat yang lebih luas adalah menciptakan alur kerja standar untuk membuat perubahan yang tidak mendesak dan merusak kompatibilitas ke belakang. Salah satu cara untuk mengatasinya adalah dengan memeriksa dan memperluas preseden yang ada, seperti proses penghancuran diri. Alur kerja tersebut akan terlihat seperti ini:

1. Mulai berbicara tentang penghapusan fitur X;

2. Melakukan analisis untuk menentukan dampak penghapusan X terhadap aplikasi, dan tergantung pada hasilnya: (i) meninggalkan ide tersebut, (ii) melanjutkan sesuai rencana, atau (iii) menentukan pendekatan “yang paling tidak mengganggu” yang direvisi untuk menghapus X dan melanjutkan;

3. Buat EIP formal untuk menghentikan X. Pastikan infrastruktur tingkat tinggi yang populer (misalnya bahasa pemrograman, dompet) menghormati hal ini dan berhenti menggunakan fitur tersebut. ;

4. Akhirnya, benar-benar menghapus X;

Harus ada alur kerja multi-tahun antara langkah 1 dan 4, dengan artikulasi yang jelas tentang proyek mana yang berada di langkah yang mana. Pada titik ini, ada pilihan antara semangat dan kecepatan proses penghilangan fitur versus bersikap lebih konservatif dan menginvestasikan lebih banyak sumber daya di area pengembangan protokol lainnya, tetapi kita masih jauh dari batas Pareto.

Akhir Pekan

Serangkaian perubahan utama yang diusulkan pada EVM adalah Format Objek EVM (EOF) EOF memperkenalkan banyak perubahan, seperti menonaktifkan observabilitas gas, observabilitas kode (yaitu tidak ada CODECOPY), dan hanya mengizinkan lompatan statis. Tujuannya adalah untuk memungkinkan EVM ditingkatkan lebih lanjut dengan cara yang memiliki properti yang lebih kuat sambil mempertahankan kompatibilitas mundur (karena EVM sebelum EOF masih ada).

Keuntungannya adalah ia menciptakan jalur alami untuk menambahkan fitur EVM baru dan mendorong migrasi ke EVM yang lebih ketat dengan jaminan yang lebih kuat. Kerugiannya adalah ia meningkatkan kompleksitas protokol secara signifikan kecuali kita dapat menemukan cara untuk akhirnya menghentikan dan menghapus EVM lama. Pertanyaan utamanya adalah: peran apa yang dimainkan EOF dalam proposal penyederhanaan EVM, terutama jika tujuannya adalah untuk mengurangi kompleksitas seluruh EVM?

Bagaimana interaksinya dengan peta jalan lainnya?

Banyak saran Peningkatan di sisa peta jalan juga merupakan peluang untuk menyederhanakan fitur lama. Untuk mengulang beberapa contoh di atas:

• Beralih ke finalitas slot tunggal memberi kita peluang untuk menghapus komite, mendesain ulang ekonomi, dan membuat penyederhanaan terkait bukti kepemilikan lainnya.

• Penerapan abstraksi akun secara penuh akan memungkinkan kami menghapus banyak logika pemrosesan transaksi yang ada dan memindahkannya ke “kode EVM akun default” yang dapat digantikan oleh semua EOA.

• Jika kita memindahkan status Ethereum ke pohon hash biner, ini dapat disesuaikan dengan versi baru SSZ sehingga semua struktur data Ethereum dapat di-hash dengan cara yang sama.

Pendekatan yang lebih radikal: mengubah bagian besar protokol menjadi kode kontrak

Strategi yang lebih radikal untuk menyederhanakan Ethereum adalah dengan tetap menjaga protokolnya tetap utuh tetapi memindahkan sebagian besarnya dari fungsionalitas protokol ke dalam kode kontrak.

Versi yang paling ekstrim adalah menjadikan Ethereum L1 “secara teknis” hanya rantai suar, dan memperkenalkan mesin virtual minimal (misalnya Bahasa Indonesia: RISC-V , Kairo , atau sesuatu yang lebih minimal khususnya untuk sistem pembuktian) yang memungkinkan orang lain membuat rollup mereka sendiri. EVM kemudian akan menjadi yang pertama dari rollup ini. Ironisnya, ini adalah hasil yang sama persis dengan proposal lingkungan pelaksanaan 2019-20 , meskipun SNARK membuatnya lebih layak untuk diimplementasikan secara nyata.

Pendekatan yang lebih sederhana adalah dengan mempertahankan hubungan antara rantai suar dan lingkungan eksekusi Ethereum saat ini tidak berubah, tetapi mengganti EVM di tempatnya. Kita dapat memilih RISC-V, Cairo, atau VM lain sebagai VM Ethereum resmi yang baru, lalu memaksa semua kontrak EVM untuk dikonversi ke kode VM baru yang menginterpretasikan logika kode asli (baik melalui kompilasi maupun interpretasi). Secara teori, ini bahkan dapat dilakukan dengan mesin virtual target yang merupakan versi EOF.

Artikel ini bersumber dari internet: Artikel baru Vitalik: Kemungkinan masa depan Ethereum (V) — The Purge