Terima kasih kepada Fede, Danno Ferrin, Justin Drake, Ladislaus, dan Tim Beiko atas umpan balik dan tinjauan mereka.

Tujuan Ethereum adalah menjadi buku besar global - sebuah platform yang membawa aset dan catatan manusia, dan merupakan lapisan dasar untuk aplikasi seperti keuangan, tata kelola, dan verifikasi data bernilai tinggi. Untuk mencapai tujuan ini, Ethereum harus memiliki skalabilitas dan ketahanan. Rencana hard fork Fusaka akan meningkatkan ruang ketersediaan data L2 sebesar 10 kali lipat, sementaraRencana jalan 2026 yang diusulkanJuga termasuk skala yang sama dari ekspansi data L1. Sementara itu, 'The Merge' telah meningkatkan Ethereum ke mekanisme konsensus proof of stake (PoS).Keragaman klien semakin meningkat dengan cepat, Verifikasi ZK (Bukti Tanpa Pengetahuan) dan ketahanan terhadap serangan kuantum juga terus berkembang, dan ekosistem aplikasi semakin meningkatDewasa dan tangguh.

Tujuan artikel ini adalah untuk menekankan suatu hal yang sama pentingnya namun sering diabaikanDaya tahan (dan pada akhirnya skalabilitas)Elemen:
Kesederhanaan protokol.

Salah satu aspek yang paling dipuji dari Bitcoin adalah desain protokolnya, yang sangat elegan dan sederhana:

Sistem ini adalah blockchain, terdiri dari serangkaian blok. Setiap blok terhubung ke blok sebelumnya melalui hash. Validitas setiap blok diverifikasi melalui Proof of Work (PoW), yang berarti... Anda hanya perlu memeriksa apakah digit terdepan hash-nya adalah nol. Setiap blok berisi transaksi, yang entah mengeluarkan koin yang diperoleh melalui penambangan, atau mengeluarkan koin dari transaksi sebelumnya. Itu pada dasarnya adalah itu.
Bahkan seorang siswa SMA yang cerdas memiliki kemampuan untuk sepenuhnya memahami prinsip operasi protokol Bitcoin. Dan seorang programmer bahkan dapat mengembangkan klien Bitcoin sebagai proyek hobi.

Menjaga protokol tetap sederhana membawa serangkaian keuntungan utama, yang berpotensi membuat Bitcoin dan EthereumNetralitas yang dipercayaiLapisan dasar kepercayaan global:

• Memudahkan logika protokol agar lebih mudah dipahami, memperluas kelompok yang dapat berpartisipasi dalam penelitian, pengembangan, dan tata kelola protokol, menurunkan hambatan teknis, dan menghindari dominasi 'kelas birokrat teknologi' dalam protokol.
• Secara signifikan mengurangi biaya pengembangan infrastruktur baru yang terintegrasi dengan protokol (seperti klien baru, verifikator baru, alat logging baru, dll).
• Mengurangi biaya pemeliharaan jangka panjang dari protokol.
• Mengurangi risiko kerentanan yang mengancam, baik dalam spesifikasi protokol maupun kode implementasi; ini juga memudahkan untuk memverifikasi bahwa protokol tidak mengandung kerentanan tersebut.
• Mengurangi permukaan serangan sosial: semakin sedikit komponen, semakin sedikit tempat yang dapat dieksploitasi dan dikendalikan oleh pemangku kepentingan tertentu.

Di masa lalu, Ethereum tidak berperforma baik dalam hal ini (terkadang bahkan karena keputusan pribadi saya), yang menyebabkan biaya pengembangan kami berlebihan,@vbuterin/selfdestruct”>Berbagai risiko keamanan dan sifat tertutup dari budaya R&D, dan upaya-upaya ini seringkali hanya membawa hasil yang ilusif.
Artikel ini akan menjelaskan bagaimana Ethereum bisa mencapai tingkat kesederhanaan yang mendekati Bitcoin dalam lima tahun.

Lapisan Konsensus Disederhanakan

3-slot finality（3槽终结性）模拟图 —3sf-mini

Desain lapis konsensus baru (sebelumnya dikenal sebagai ‘beam chain’) bertujuan untuk mengintegrasikan pengalaman yang telah kami kumpulkan dalam teori konsensus, pengembangan ZK-SNARK, ekonomi staking, dan area lain selama dekade terakhir, untuk menciptakan lapis konsensus Ethereum jangka panjang yang optimal. Lapis konsensus baru ini, dibandingkan dengan Beacon Chain yang ada, diharapkan dapat mencapai kesederhanaan yang lebih tinggi. Hal ini terutama terlihat dalam:

• restruktur finalitas 3 slot
  Desain ini menghilangkan perbedaan antara 'slot' dan 'epoch', perombakan komite, dan detail spesifikasi protokol lainnya terkait mekanisme ini (seperti komite sinkron). Versi dasar finalitas 3-slot,Hanya sekitar 200 baris kode yang diperlukanHal itu dapat dicapai. Dibandingkan dengan protokol Gasper saat ini, finalitas 3-slot juga memiliki keamanan yang mendekati optimal.
• Jumlah validator aktif telah berkurang
  Membuat lebih aman dan lebih memungkinkan untuk mengadopsi aturan pemilihan fork yang lebih sederhana.
• Protokol agregasi berbasis STARK
  Berarti bahwa siapa pun dapat menjadi pengumpul tanpa perlu khawatir tentang kepercayaan pengumpul, biaya berlebih untuk bidang bit yang diulang, dll. Meskipun enkripsi pengumpulan itu sendiri memiliki kompleksitas tertentu, iniKompleksitas yang sangat terenkapsulasiRisiko sistematis keseluruhan protokol ini jauh lebih rendah.
• Kedua poin di atas juga kemungkinan untuk mendukung arsitektur peer-to-peer (p2p) yang lebih sederhana dan kokoh.
• Kita memiliki kesempatan untuk memikir ulang mekanisme masuk validator, keluar, penarikan, pergantian kunci, hukuman inersia, dll., dan menyederhanakannya—bukan hanya mengurangi jumlah baris kode (LoC), tetapi juga memberikan jaminan mekanisme yang lebih jelas, seperti batas waktu 'subjektivitas lemah' yang lebih eksplisit.

Keuntungan dari lapisan konsensus adalah bahwa ia relatif terpisah dari eksekusi EVM, sehingga kami memiliki banyak ruang untuk terus mendorong peningkatan ini ke depan.
Lebih menantang adalah: bagaimana mencapai penyederhanaan yang sama di lapisan pelaksanaan.

Sederhanakan Lapisan Eksekusi

Kompleksitas Mesin Virtual Ethereum (EVM) terus meningkat, dan sebagian besar kompleksitas ini terbukti tidak perlu (seringkali juga terkait dengan keputusan pribadi saya): kami memiliki mesin virtual 256-bit yang terlalu dioptimalkan untuk bentuk kriptografi yang sangat spesifik, yang sekarang secara bertahap menjadi tidak terlalu penting; dan beberapa kontrak pra-dikompilasi terlalu fokus pada beberapa kasus penggunaan tunggal saja.

Mencoba secara bertahap memperbaiki masalah praktis ini tidak memungkinkan.Hapus @vbuterinInstruksi SELFDESTRUCT mengonsumsi sejumlah energi yang besar, namun hasilnya terbatas. Debat terbaru tentang EOF (Format Objek EVM) lebih lanjut menunjukkan kesulitan dalam melakukan perubahan serupa pada mesin virtual.

Oleh karena itu, sebagai alternatif, baru-baru ini saya mengusulkan ide yang lebih radikal: daripada melakukan perubahan inkremental (tetapi masih merusak) untuk peningkatan 1.5x, lebih baik langsung bermigrasi ke mesin virtual yang baru, jauh lebih unggul, dan lebih sederhana, dengan tujuan pengembalian 100x. Sama seperti 'The Merge,' kita mengurangi jumlah transformasi, tetapi setiap transformasi adalah signifikan. Secara khusus, saya menyarankan untuk mengganti EVM yang ada dengan RISC-V (atau mesin virtual lain yang akan digunakan oleh ZK prover Ethereum). Dengan cara ini, kita akan mencapai:

• Peningkatan efisiensi yang signifikan: karena kontrak pintar dapat berjalan langsung di prover tanpa biaya overhead dari interpreter. Data ringkas menunjukkan bahwa kinerja dapat ditingkatkan lebih dari 100 kali dalam banyak skenario.
• Kesederhanaan mutlak: dibandingkan dengan spesifikasi RISC-V, EVMSangat sederhana. Solusi alternatif lainnya (seperti Cairo) sama singkatnya.
• Mewarisi keuntungan yang diharapkan dari EOF: seperti segmentasi kode, analisis statis yang lebih ramah, batas kapasitas kode yang lebih besar, dll.
• Pengembang memiliki lebih banyak pilihan: Solidity dan Vyper dapat dikompilasi ke backend mesin virtual baru. Jika dipilih RISC-V, pengembang bahasa utama juga dapat dengan mudah memindahkan kode mereka.
• Secara signifikan mengurangi kebutuhan untuk pra-kompilasi: mungkin hanya menyisakan beberapa operasi kurva elips yang sangat dioptimalkan (meskipun ini tidak akan ada lagi ketika komputasi kuantum menjadi populer).

Kelemahan utama dari pendekatan ini adalah bahwa, berbeda dengan EOF (dapat segera diterapkan), mesin virtual baru memerlukan waktu lebih lama untuk memberikan manfaat kepada pengembang. Untuk mengurangi hal ini, kita dapat memperkenalkan beberapa perbaikan EVM yang kecil namun bernilai tinggi dalam jangka pendek.Meningkatkan batas ukuran kode kontrakTingkatkan instruksi DUP/SWAP17-32, dll.)

Pada akhirnya, ini akan memberikan kita mesin virtual yang sangat disederhanakan. Tetapi pertanyaan terbesar adalah: bagaimana dengan EVM yang sudah ada?

Strategi kompatibilitas mundur transisional VM

Saat secara bermakna menyederhanakan (atau bahkan hanya meningkatkan tanpa menambah kompleksitas) bagian manapun dari Mesin Virtual Ethereum (EVM), tantangan terbesar adalah: bagaimana mempertahankan kompatibilitas mundur dengan aplikasi yang sudah ada sambil mencapai tujuan.

Pertama-tama, harus jelas bahwa tidak ada cara tunggal untuk mendefinisikan lingkup "kode sumber Ethereum" (bahkan dalam klien yang sama).

Tujuan adalah untuk meminimalkan cakupan area hijau sebanyak mungkin: yaitu, logika yang harus dijalankan oleh node untuk berpartisipasi dalam konsensus Ethereum, termasuk menghitung keadaan saat ini, bukti, validasi, FOCIL (Lapisan Integritas Konsensus Orde Pertama), konstruksi blok dasar, dll.

Area oranye tidak dapat dikurangi: jika fitur lapisan eksekusi tertentu (baik itu mesin virtual, pra-kompilasi, atau mekanisme lainnya) dihapus dari spesifikasi protokol, atau fungsinya diubah, klien yang terkait dengan pemrosesan blok historis masih harus mempertahankannya - tetapi yang penting, klien baru (seperti ZK-EVMs atau verifikasi formal) dapat sepenuhnya mengabaikan area oranye.

Kategori baru adalah area kuning: jenis kode ini sangat penting untuk memahami dan mengurai status rantai saat ini, dan untuk membangun blok terbaik, tetapi bukan bagian dari konsensus. Sebagai contoh adalah Etherscan(Dan beberapaPembangun Blok) Dukungan untuk operasi pengguna ERC-4337. Jika kami menggunakan implementasi RISC-V on-chain untuk menggantikan fungsi-fungsi besar tertentu dari Ethereum (seperti akun EOA dan dukungan mereka untuk berbagai jenis transaksi lama), maka meskipun kode konsensus mengalami penyederhanaan signifikan, beberapa node profesional mungkin tetap menggunakan kode asli untuk mengurai fungsi-fungsi ini.

Penting bahwa area oranye dan kuning milik 'Gate'Kompleksitas EnkapsulasiSiapa pun yang ingin memahami protokol dapat melewatinya, klien Ethereum juga dapat memilih untuk tidak mengimplementasikannya, dan bug di area-area ini tidak akan menimbulkan risiko konsensus. Ini berarti kompleksitas kode dan dampak negatif yang dibawa oleh area oranye dan kuning jauh lebih kecil dibandingkan dengan area hijau.

Transferkan kode dari zona hijau ke zona kuning, pendekatan ini mirip dengan Apple Inc.Terjemahkan melalui lapisan terjemahan RosettaUntuk memastikan kompatibilitas jangka panjang.

Saya mengusulkan (dipinjam dari@ipsilon/eof-ethereums-gateway-to-risc-v”> Tim Ipsilon’s pandangan terbaru) Proses migrasi mesin virtual berikut (menggunakan migrasi EVM ke RISC-V sebagai contoh, tetapi juga dapat diterapkan pada migrasi EVM ke Cairo, dan bahkan migrasi ke VM yang lebih optimal di masa depan):

1. Semua precompile baru harus ditulis dalam implementasi RISC-V standar on-chain, sehingga ekosistem dapat mulai akrab dan menggunakan RISC-V sebagai mesin virtual.
2. Memperkenalkan RISC-V sebagai pilihan untuk pengembangan kontrak sejajar dengan EVM bagi para pengembang. Protokol ini secara alami mendukung baik RISC-V maupun EVM, memungkinkan kontrak yang ditulis dalam kedua bahasa berinteraksi secara bebas.
3. Ganti semua pra-kompilasi (kecuali operasi kurva eliptis dan KECCAK) dengan implementasi RISC-V. Kami menghapus pra-kompilasi ini melalui hard fork dan pada saat yang sama mengubah kode di alamat yang sesuai (gayut DAO) untuk menjadi implementasi RISC-V. Karena VM RISC-V sangat ringkas, bahkan hanya dengan melakukan ini, struktur keseluruhan menjadi lebih sederhana.
4. Menerapkan penterjemah EVM yang ditulis dalam RISC-V dan mendepatkannya sebagai kontrak pintar di rantai. Setelah beberapa tahun sejak rilis awal, kontrak EVM yang ada akan diproses melalui penterjemah ini.

Setelah menyelesaikan langkah 4, masih akan ada banyak 'implementasi EVM' yang terus digunakan untuk mengoptimalkan konstruksi blok, alat pengembangan, dan analisis on-chain, tetapi mereka tidak akan lagi menjadi bagian dari spesifikasi konsensus utama. Pada saat itu, konsensus Ethereum hanya akan 'secara alami' memahami RISC-V.

Sederhanakan dengan berbagi komponen protokol

Metode penyederhanaan ketiga, dan mungkin yang paling diabaikan, adalah dengan berbagi standar yang seragam di berbagai bagian tumpukan protokol sebanyak mungkin. Biasanya, tidak ada alasan untuk menggunakan protokol yang berbeda untuk tujuan yang sama dalam skenario yang berbeda, tetapi situasi ini masih sering terjadi dalam kehidupan nyata, terutama karena kurangnya komunikasi antara bagian-bagian berbeda dari peta jalan protokol. Berikut adalah beberapa contoh spesifik penyederhanaan Ethereum melalui 'maksimalkan berbagi komponen':

Kode penghapusan terpadu

Kita perlu memperbaiki kode penghapusan dalam tiga skenario:

• Pemantauan ketersediaan data - Klien memverifikasi apakah blok telah dipublikasikan
• Penyiaran P2P yang lebih cepat - Node-node dapat menerima blok setelah menerima n/2 dari n blok, dengan demikian membentuk keseimbangan optimal antara mengurangi laten dan redundansi.
• Penyimpanan Riwayat Terdistribusi - Setiap bagian dari riwayat Ethereum disimpan dalam banyak blok, sehingga (i) blok-blok ini dapat diverifikasi secara independen, dan (ii) separuh dari blok-blok dalam setiap grup dapat memulihkan separuh sisanya, secara signifikan mengurangi risiko kehilangan blok tunggal mana pun.

Jika kita menggunakan kode penghapusan yang sama (baik itu Reed-Solomon, kode linear acak, atau yang lain) dalam tiga kasus penggunaan, kita akan mendapatkan beberapa keuntungan penting:

1. Meminimalkan total baris kode
2. Meningkatkan efisiensi karena jika setiap node harus mengunduh berbagai bagian dari blok untuk satu kasus penggunaan (daripada seluruh blok), data tersebut dapat digunakan untuk kasus penggunaan lainnya
3. Pastikan Verifiabilitas: Semua tiga blok dalam konteks dapat diverifikasi berdasarkan akar

Jika kode koreksi kesalahan yang berbeda memang diperlukan, 'kompatibilitas' setidaknya harus dijamin: misalnya, dalam skenario DAS, Reed-Solomon digunakan secara horizontal dan kode linear acak digunakan secara vertikal, tetapi keduanya berdasarkan pada bidang matematika yang sama.

Format serialisasi yang terpadu

Saat ini, format serialisasi Ethereum sebenarnya hanya "semi-terstandarisasi", karena data dapat di-serialisasi ulang dan disiarkan dalam format apa pun. Satu-satunya pengecualian adalah hash tanda tangan transaksi, di mana format terstandarisasi diperlukan untuk perhitungan hash.
Namun standarisasi format serialisasi di masa depan akan lebih ditingkatkan, karena dua alasan:

• Abstraksi Akun Komprehensif (EIP-7701): Mesin virtual akan dapat melihat seluruh konten transaksi lengkap
• Peningkatan batas gas: Data blok eksekusi perlu dikemas ke dalam blob

Pada saat itu, kita memiliki kesempatan untuk menyatukan solusi serialisasi yang diperlukan untuk tiga aspek saat ini: 1) lapisan eksekusi; 2) lapisan konsensus; 3) ABI pemanggilan kontrak pintar.

Saya menyarankan mengadopsi SSZ(Simple Serialize), karena SSZ memiliki keunggulan berikut:

• Mudah untuk didekode: termasuk di dalam kontrak pintar (berdasarkan desain 4-byte, sedikit kasus batas)
• Banyak digunakan dalam konsensus
• Sangat mirip dengan ABI yang ada: biaya migrasi alat rendah

Saat ini lebih banyak komponen telah terpasangMigrasiKe SSZKerjaKetika merencanakan peningkatan di masa depan, kita harus sepenuhnya mempertimbangkan dan memanfaatkan perkembangan ini.

Struktur pohon yang terpadu

Setelah kita bermigrasi dari EVM ke RISC-V (atau VM minimalist lainnya), pohon Merkle Patricia heksadesimal akan menjadi bottleneck terbesar untuk membuktikan eksekusi blok, bahkan dalam skenario rata-rata. Migrasi ke fungsi hashPohon Binari, akan sangat meningkatkan efisiensi verifikator dan mengurangi biaya data dari node ringan dan skenario lainnya.

Saat menyelesaikan migrasi struktur pohon, kita juga harus memastikan bahwa lapisan konsensus menggunakan struktur pohon yang sama untuk memastikan bahwa seluruh Ethereum - baik lapisan konsensus maupun lapisan eksekusi - dapat diakses dan diurai menggunakan seperangkat kode yang sama.

Dari sekarang ke masa depan

Pemudahan dan desentralisasi memiliki banyak kesamaan. Keduanya adalah persyaratan hulu yang diperlukan untuk mencapai tujuan yang lebih tinggi dari ketahanan sistem. Menekankan pemudahan secara eksplisit memerlukan perubahan budaya. Manfaat pemudahan seringkali sulit terlihat pada tahap awal, tetapi biaya kesempatan dan beban kerja tambahan dari menolak fitur-fitur baru yang "menarik" itu segera terlihat. Namun, seiring waktu, nilai jangka panjang dari pemudahan menjadi semakin jelas—Bitcoin sendiri adalah contoh yang sangat baik.

Saya menyarankan kitaBelajar dari pendekatan tinygradUntuk menetapkan tujuan batas garis kode yang jelas untuk spesifikasi jangka panjang Ethereum, tujuannya adalah membuat kode kritis konsensus Ethereum sesederhana mungkin seperti gaya minimalis Bitcoin. Kode yang berurusan dengan aturan historis Ethereum masih akan ada tetapi harus diisolasi dari jalur kritis konsensus. Pada saat yang sama, kita harus membentuk prinsip desain universal: memilih solusi yang lebih sederhana bila memungkinkan, memprioritaskan kompleksitas terenkapsulasi daripada kompleksitas sistemik, dan cenderung keputusan desain yang memberikan properti dan jaminan yang jelas diverifikasi.

Penafian:

1. Artikel ini diambil dari [vitalik]. Semua hak cipta milik penulis asli [.vitalikSemua. Jika Anda memiliki keberatan terhadap cetakan ulang ini, silakan hubungiGate BelajarTim akan menanganinya dengan tepat waktu.
2. Penafian: Pandangan dan pendapat yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Tim Gate Learn menerjemahkan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali dinyatakan lain.