Ethereum bertujuan untuk menjadi buku besar global yang membutuhkan skalabilitas dan ketahanan. Artikel ini berfokus pada pentingnya kesederhanaan protokol, mengusulkan untuk secara signifikan mengurangi kompleksitas dengan menyederhanakan lapisan konsensus (finalitas 3-slot, agregasi STARK) dan lapisan eksekusi (mengganti EVM dengan RISC-V atau mesin virtual serupa) untuk mengurangi biaya pengembangan, risiko kesalahan, dan permukaan serangan. Disarankan untuk transisi yang mulus melalui strategi kompatibilitas ke belakang (seperti interpreter EVM di dalam rantai) dan menyatukan kode penghapusan, format serialisasi (SSZ), dan struktur pohon untuk lebih menyederhanakan. Tujuannya adalah agar kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin, meningkatkan ketahanan dan partisipasi, dan perlu memberi perhatian budaya pada kesederhanaan serta menetapkan target jumlah baris kode maksimum.
Tujuan Ethereum adalah untuk menjadi buku besar global: platform untuk menyimpan aset dan catatan peradaban manusia, melayani bidang keuangan, pemerintahan, dan sertifikasi data bernilai tinggi. Ini memerlukan dukungan dari dua aspek: skalabilitas dan ketahanan. Rencana hard fork Fusaka akan meningkatkan ruang ketersediaan data L2 sebanyak 10 kali lipat, sementara peta jalan yang diusulkan untuk tahun 2026 juga berencana untuk membawa peningkatan besar yang serupa untuk lapisan L1. Sementara itu, Ethereum telah menyelesaikan transisi ke bukti kepemilikan (PoS), keberagaman klien meningkat dengan cepat, penelitian verifikasi nol-pengetahuan (ZK), dan ketahanan kuantum juga sedang berkembang secara stabil, ekosistem aplikasi semakin kuat.
Artikel ini bertujuan untuk memfokuskan pada satu elemen ketahanan (bahkan skalabilitas) yang sama pentingnya namun seringkali diremehkan: kesederhanaan protokol.
Keanggunan kesederhanaan adalah hal yang paling mengagumkan dari protokol Bitcoin:
Terdapat sebuah rantai yang terdiri dari blok-blok, di mana setiap blok terhubung dengan blok sebelumnya melalui hash.
Validitas blok diverifikasi melalui proof of work (PoW), yaitu memeriksa apakah beberapa digit awal dari nilai hash adalah nol.
Setiap blok berisi transaksi, koin yang digunakan dalam transaksi berasal dari hadiah penambangan atau dari output transaksi sebelumnya.
Hanya itu saja! Bahkan seorang pelajar SMA yang pintar pun dapat sepenuhnya memahami cara kerja protokol Bitcoin, dan seorang programmer bahkan dapat menulis klien sebagai proyek sampingan.
Simplicity dari protokol memberikan banyak keuntungan kunci bagi Bitcoin (dan Ethereum) untuk menjadi lapisan dasar global yang dapat dipercaya dan netral:
Mudah dipahami: Mengurangi kompleksitas protokol, memungkinkan lebih banyak orang untuk berpartisipasi dalam penelitian, pengembangan, dan tata kelola protokol, mengurangi risiko dominasi kelas elit teknis.
Mengurangi biaya pengembangan: Menyederhanakan protokol secara signifikan mengurangi biaya untuk membuat infrastruktur baru (seperti klien baru, pembuktian, alat pengembang, dll).
Mengurangi risiko kesalahan: Mengurangi kemungkinan terjadinya kesalahan bencana dalam spesifikasi dan implementasi protokol, serta memudahkan verifikasi bahwa kesalahan semacam itu tidak ada.
Mempersempit Permukaan Serangan: Mengurangi komponen kompleks dalam protokol, mengurangi risiko diserang oleh kelompok kepentingan tertentu.
Dalam sejarahnya, Ethereum (kadang-kadang karena keputusan pribadi saya) sering kali gagal mempertahankan kesederhanaan, yang mengakibatkan biaya pengembangan yang terlalu tinggi, peningkatan risiko keamanan, dan budaya penelitian dan pengembangan yang tertutup, sementara manfaat dari pengejaran kompleksitas ini sering kali terbukti ilusif. Artikel ini akan membahas bagaimana Ethereum lima tahun ke depan dapat mendekati kesederhanaan Bitcoin.
Lapisan konsensus yang disederhanakan
Desain lapisan konsensus baru (dulu dikenal sebagai "rantai penanda") bertujuan untuk memanfaatkan pengalaman selama sepuluh tahun terakhir dalam teori konsensus, pengembangan ZK-SNARK, ekonomi staking, dan bidang lainnya, untuk membangun lapisan konsensus yang lebih sederhana dan optimal dalam jangka panjang. Dibandingkan dengan rantai penanda yang ada, desain baru ini secara signifikan menyederhanakan:
Desain final 3-slot: Menghapus konsep slot, epoch, pengelompokan komite, dan mekanisme pemrosesan efisien terkait (seperti komite sinkron). Implementasi dasar finalitas 3-slot hanya memerlukan sekitar 200 baris kode, dan dibandingkan dengan Gasper, keamanannya mendekati optimal.
Mengurangi jumlah validator aktif: Memungkinkan penggunaan aturan pemilihan fork yang lebih sederhana untuk meningkatkan keamanan.
Protokol agregasi berbasis STARK: Siapa pun dapat menjadi agregator, tanpa perlu mempercayai agregator atau membayar biaya tinggi untuk ruang penyimpanan yang berulang. Kompleksitas kriptografi agregasi cukup tinggi, tetapi kompleksitas tersebut sangat terbungkus, dengan risiko sistemik yang rendah.
Penyederhanaan Arsitektur P2P: Faktor-faktor di atas mungkin mendukung arsitektur jaringan peer-to-peer yang lebih sederhana dan lebih kuat.
Mendesain ulang mekanisme validator: termasuk mekanisme masuk, keluar, penarikan, peralihan kunci, kebocoran ketidakaktifan, dan lainnya, menyederhanakan jumlah baris kode dan memberikan jaminan yang lebih jelas (seperti periode subjektivitas lemah).
Keuntungan dari lapisan konsensus adalah relatif independennya dari lapisan eksekusi EVM, sehingga ada ruang yang besar untuk perbaikan berkelanjutan. Tantangan yang lebih besar adalah bagaimana menerapkan penyederhanaan serupa di lapisan eksekusi.
Lapisan Eksekusi Sederhana
Kompleksitas EVM semakin meningkat, dan banyak dari kompleksitas tersebut terbukti tidak perlu (sebagian karena kesalahan keputusan pribadi saya): mesin virtual 256-bit terlalu dioptimalkan untuk bentuk kriptografi tertentu yang kini sudah mulai usang, prekompilasi dioptimalkan untuk satu kasus penggunaan namun jarang digunakan.
Menangani masalah ini satu per satu memiliki efek yang terbatas. Misalnya, menghapus opcode SELFDESTRUCT membutuhkan usaha yang sangat besar, tetapi hanya memberikan sedikit keuntungan. Perdebatan baru-baru ini tentang EOF (EVM Object Format) juga menunjukkan tantangan serupa.
Saya baru-baru ini mengajukan rencana yang lebih radikal: alih-alih melakukan perubahan skala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan 1,5 kali lipat keuntungan, lebih baik beralih ke mesin virtual yang lebih baik dan lebih sederhana untuk mendapatkan 100 kali lipat keuntungan. Mirip dengan "The Merge", kita mengurangi jumlah perubahan yang merusak, tetapi membuat setiap perubahan lebih berarti. Secara khusus, saya menyarankan untuk mengganti EVM dengan RISC-V, atau mesin virtual lain yang digunakan oleh pembuktian ZK Ethereum. Ini akan membawa:
Peningkatan efisiensi yang signifikan: Eksekusi kontrak pintar (di dalam pembuktian) tidak memerlukan biaya interpreter, langsung dijalankan. Data dari Succinct menunjukkan bahwa dalam banyak skenario, kinerja dapat meningkat lebih dari 100 kali.
Peningkatan Kesederhanaan yang Signifikan: Spesifikasi RISC-V jauh lebih sederhana dibandingkan EVM, dan alternatif (seperti Cairo) juga sangat ringkas.
Motivasi mendukung EOF: seperti pemisahan kode, analisis statis yang lebih ramah, batas ukuran kode yang lebih besar, dll.
Lebih banyak pilihan pengembang: Solidity dan Vyper dapat menambahkan backend untuk dikompilasi ke mesin virtual baru. Jika memilih RISC-V, pengembang bahasa arus utama juga dapat dengan mudah memindahkan kode ke mesin virtual tersebut.
Menghapus sebagian besar precompiled: mungkin hanya menyisakan operasi kurva eliptik yang sangat dioptimalkan (setelah komputer kuantum menjadi umum, bahkan ini juga akan hilang).
Kekurangan utama adalah, berbeda dengan EOF yang sudah siap, manfaat dari mesin virtual baru membutuhkan waktu lebih lama untuk dirasakan oleh pengembang. Kita dapat mengatasi masalah ini dengan menerapkan perbaikan EVM bernilai tinggi dalam jangka pendek (seperti meningkatkan batas ukuran kode kontrak, mendukung DUP/SWAP17–32).
Ini akan membawa mesin virtual yang lebih sederhana. Tantangan inti adalah: bagaimana menangani EVM yang ada?
Kebijakan kompatibilitas mundur untuk transisi mesin virtual
Tantangan terbesar dalam menyederhanakan (atau meningkatkan tanpa menambah kompleksitas) EVM adalah bagaimana menyeimbangkan pencapaian tujuan dengan kompatibilitas mundur aplikasi yang ada.
Pertama-tama perlu dipahami: repositori kode Ethereum (bahkan dalam satu klien saja) tidak memiliki satu definisi tunggal.
Tujuannya adalah untuk memperkecil area hijau sebanyak mungkin: logika yang diperlukan untuk node berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, bukti, verifikasi, FOCIL (aturan pemilihan fork) dan pembangunan blok "biasa".
Area oranye tidak dapat dikurangi: Jika spesifikasi protokol menghapus atau mengubah fungsi lapisan eksekusi tertentu (seperti mesin virtual, pra-kompilasi, dll.), klien yang memproses blok sejarah masih harus mempertahankan kode terkait. Namun, klien baru, ZK-EVM atau pembuktian formal dapat sepenuhnya mengabaikan area oranye.
Area kuning yang baru ditambahkan: sangat berharga untuk memahami rantai saat ini atau mengoptimalkan konstruksi blok, tetapi tidak termasuk dalam logika konsensus. Misalnya, Etherscan dan beberapa pembangun blok mendukung operasi pengguna ERC-4337. Jika kita menggantikan beberapa fungsi Ethereum (seperti EOA dan jenis transaksi lama yang didukungnya) dengan implementasi RISC-V di on-chain, kode konsensus akan sangat disederhanakan, tetapi node khusus mungkin tetap menggunakan kode asli untuk analisis.
Kompleksitas area oranye dan kuning adalah kompleksitas pengemasan, orang yang memahami protokol dapat melewati bagian-bagian ini, Ethereum dapat mengabaikannya, kesalahan di area ini tidak akan memicu risiko konsensus. Oleh karena itu, kompleksitas kode di area oranye dan kuning jauh lebih kecil bahayanya dibandingkan dengan kompleksitas area hijau.
Pemindahan kode dari area hijau ke area kuning mirip dengan strategi Apple yang memastikan kompatibilitas jangka panjang melalui lapisan terjemahan Rosetta.
Terinspirasi oleh artikel terbaru dari tim Ipsilon, saya mengusulkan proses perubahan mesin virtual berikut (menggunakan EVM ke RISC-V sebagai contoh, tetapi juga dapat digunakan untuk EVM ke Cairo atau RISC-V ke mesin virtual yang lebih baik):
Meminta penyusunan pra-kompilasi baru untuk menyediakan implementasi RISC-V di dalam blockchain: Membiarkan ekosistem secara bertahap beradaptasi dengan mesin virtual RISC-V.
Memperkenalkan RISC-V sebagai opsi pengembang: Protokol mendukung RISC-V dan EVM, kontrak dari kedua mesin virtual dapat berinteraksi secara bebas.
Mengganti sebagian besar precompiled: Kecuali untuk operasi kurva elips dan KECCAK (karena kebutuhan kecepatan ekstrem), gunakan RISC-V untuk mengganti precompiled lainnya. Menghapus precompiled melalui hard fork, sekaligus mengubah kode alamat tersebut (mirip dengan fork DAO) dari kosong menjadi implementasi RISC-V. Mesin virtual RISC-V sangat sederhana, bahkan jika berhenti di sini sudah menyederhanakan protokol secara signifikan.
Menerapkan interpreter EVM di RISC-V: sebagai kontrak pintar yang dihubungkan ke rantai (karena pembuktian ZK diperlukan). Setelah beberapa tahun rilis awal, kontrak EVM yang ada dijalankan melalui interpreter ini.
Setelah menyelesaikan langkah ke-4, banyak "implementasi EVM" masih akan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis rantai, tetapi tidak lagi menjadi bagian dari norma konsensus kunci. Konsensus Ethereum akan "secara native" hanya memahami RISC-V.
Menyederhanakan melalui komponen protokol berbagi
Cara ketiga untuk mengurangi kompleksitas total protokol (juga yang paling mudah diremehkan) adalah dengan berbagi standar yang uniform di berbagai bagian tumpukan protokol sebanyak mungkin. Protokol yang melakukan hal yang sama di berbagai skenario biasanya tidak ada gunanya, tetapi pola ini tetap sering muncul, terutama karena berbagai bagian peta jalan protokol kurang komunikasi. Berikut adalah beberapa contoh konkret tentang bagaimana berbagi komponen menyederhanakan Ethereum.
Unified erasure code
Kami memerlukan kode penghapusan di tiga skenario:
Sampling ketersediaan data: Klien memverifikasi bahwa blok telah diterbitkan.
Siaran P2P yang lebih cepat: Node dapat menerima blok setelah menerima n/2 segmen, mencapai keseimbangan antara latensi dan redundansi.
Penyimpanan sejarah terdistribusi: penyimpanan data sejarah Ethereum dalam potongan, setiap grup n/2 potongan dapat memulihkan potongan yang tersisa, mengurangi risiko kehilangan potongan tunggal.
Jika menggunakan kode penghapusan yang sama (baik itu Reed-Solomon, kode linier acak, dll) dalam tiga skenario, Anda akan memperoleh keuntungan berikut:
Minimalkan jumlah kode: kurangi total jumlah baris kode.
Meningkatkan efisiensi: Jika node mengunduh sebagian potongan untuk suatu skenario, data ini dapat digunakan untuk skenario lain.
Pastikan verifikasi: Semua potongan dari skenario dapat diverifikasi berdasarkan akar.
Jika menggunakan kode penghapusan yang berbeda, setidaknya harus memastikan kompatibilitas, misalnya kode Reed-Solomon tingkat sampling ketersediaan data dan kode linier acak vertikal beroperasi di domain yang sama.
Format serialisasi yang seragam
Format serialisasi Ethereum saat ini hanya sebagian terstandarisasi, karena data dapat diserialisasi dan disiarkan dalam format apa pun. Pengecualian adalah hash tanda tangan transaksi, yang perlu di-hash dalam format yang terstandarisasi. Di masa depan, tingkat standarisasi format serialisasi akan meningkat lebih lanjut karena alasan berikut:
Abstraksi Akun Lengkap (EIP-7701): Konten lengkap transaksi terlihat oleh mesin virtual.
Batas Gas yang lebih tinggi: Data lapisan eksekusi harus dimasukkan ke dalam blok data (blobs).
Saat itu, kita memiliki kesempatan untuk menyelaraskan format serialisasi tiga tingkat Ethereum: lapisan eksekusi, lapisan konsensus, dan panggilan ABI kontrak pintar.
Saya mengusulkan untuk menggunakan SSZ, karena SSZ:
Mudah untuk mendekode: termasuk dalam kontrak pintar (karena desain berbasis 4 byte dan sedikit kasus tepi).
Sudah digunakan secara luas di lapisan konsensus.
Sangat mirip dengan ABI yang ada: penyesuaian alat relatif sederhana.
Telah ada upaya untuk migrasi sepenuhnya ke SSZ, kita harus mempertimbangkan dan melanjutkan upaya ini saat merencanakan upgrade di masa depan.
Struktur pohon terintegrasi
Jika bermigrasi dari EVM ke RISC-V (atau mesin virtual minimum lainnya yang dapat dipilih), pohon Merkle Patricia heksadesimal akan menjadi kendala terbesar dalam membuktikan eksekusi blok, bahkan dalam kasus rata-rata sekalipun. Migrasi ke pohon biner yang berbasis fungsi hash yang lebih baik akan secara signifikan meningkatkan efisiensi pembuktian, sambil mengurangi biaya data dalam skenario seperti klien ringan.
Saat migrasi, pastikan lapisan konsensus menggunakan struktur pohon yang sama. Ini akan memungkinkan lapisan konsensus Ethereum dan lapisan eksekusi untuk diakses dan dianalisis melalui kode yang sama.
Dari sekarang hingga masa depan
Kesederhanaan dalam banyak hal mirip dengan desentralisasi, keduanya merupakan hulu dari tujuan ketahanan. Menekankan kesederhanaan dengan jelas memerlukan perubahan budaya tertentu. Manfaatnya seringkali sulit untuk diukur, sementara biaya dari upaya tambahan dan pengorbanan beberapa fitur mencolok terlihat langsung. Namun, seiring waktu, manfaatnya akan semakin jelas — Bitcoin itu sendiri adalah contoh yang sangat baik.
Saya mengusulkan untuk meniru tinygrad, menetapkan target jumlah baris kode maksimum yang jelas untuk standar jangka panjang Ethereum, sehingga kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin. Kode yang menangani aturan sejarah Ethereum akan tetap ada, tetapi harus ditempatkan di luar jalur kunci konsensus. Pada saat yang sama, kita harus memegang prinsip memilih solusi yang lebih sederhana, mengutamakan pengemasan kompleksitas daripada kompleksitas sistemik, dan membuat pilihan desain yang memberikan atribut dan jaminan yang jelas.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Vitalik Blog: Bagaimana membuat Ethereum 5 tahun ke depan menjadi semudah Bitcoin
Penulis | Vitalik Buterin
Kompilasi | GaryMa Wu berkata tentang blockchain
Tautan asli:
Ringkasan
Ethereum bertujuan untuk menjadi buku besar global yang membutuhkan skalabilitas dan ketahanan. Artikel ini berfokus pada pentingnya kesederhanaan protokol, mengusulkan untuk secara signifikan mengurangi kompleksitas dengan menyederhanakan lapisan konsensus (finalitas 3-slot, agregasi STARK) dan lapisan eksekusi (mengganti EVM dengan RISC-V atau mesin virtual serupa) untuk mengurangi biaya pengembangan, risiko kesalahan, dan permukaan serangan. Disarankan untuk transisi yang mulus melalui strategi kompatibilitas ke belakang (seperti interpreter EVM di dalam rantai) dan menyatukan kode penghapusan, format serialisasi (SSZ), dan struktur pohon untuk lebih menyederhanakan. Tujuannya adalah agar kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin, meningkatkan ketahanan dan partisipasi, dan perlu memberi perhatian budaya pada kesederhanaan serta menetapkan target jumlah baris kode maksimum.
Tujuan Ethereum adalah untuk menjadi buku besar global: platform untuk menyimpan aset dan catatan peradaban manusia, melayani bidang keuangan, pemerintahan, dan sertifikasi data bernilai tinggi. Ini memerlukan dukungan dari dua aspek: skalabilitas dan ketahanan. Rencana hard fork Fusaka akan meningkatkan ruang ketersediaan data L2 sebanyak 10 kali lipat, sementara peta jalan yang diusulkan untuk tahun 2026 juga berencana untuk membawa peningkatan besar yang serupa untuk lapisan L1. Sementara itu, Ethereum telah menyelesaikan transisi ke bukti kepemilikan (PoS), keberagaman klien meningkat dengan cepat, penelitian verifikasi nol-pengetahuan (ZK), dan ketahanan kuantum juga sedang berkembang secara stabil, ekosistem aplikasi semakin kuat.
Artikel ini bertujuan untuk memfokuskan pada satu elemen ketahanan (bahkan skalabilitas) yang sama pentingnya namun seringkali diremehkan: kesederhanaan protokol.
Keanggunan kesederhanaan adalah hal yang paling mengagumkan dari protokol Bitcoin:
Terdapat sebuah rantai yang terdiri dari blok-blok, di mana setiap blok terhubung dengan blok sebelumnya melalui hash.
Validitas blok diverifikasi melalui proof of work (PoW), yaitu memeriksa apakah beberapa digit awal dari nilai hash adalah nol.
Setiap blok berisi transaksi, koin yang digunakan dalam transaksi berasal dari hadiah penambangan atau dari output transaksi sebelumnya.
Hanya itu saja! Bahkan seorang pelajar SMA yang pintar pun dapat sepenuhnya memahami cara kerja protokol Bitcoin, dan seorang programmer bahkan dapat menulis klien sebagai proyek sampingan.
Simplicity dari protokol memberikan banyak keuntungan kunci bagi Bitcoin (dan Ethereum) untuk menjadi lapisan dasar global yang dapat dipercaya dan netral:
Mudah dipahami: Mengurangi kompleksitas protokol, memungkinkan lebih banyak orang untuk berpartisipasi dalam penelitian, pengembangan, dan tata kelola protokol, mengurangi risiko dominasi kelas elit teknis.
Mengurangi biaya pengembangan: Menyederhanakan protokol secara signifikan mengurangi biaya untuk membuat infrastruktur baru (seperti klien baru, pembuktian, alat pengembang, dll).
Mengurangi beban pemeliharaan: Mengurangi biaya pemeliharaan perjanjian jangka panjang.
Mengurangi risiko kesalahan: Mengurangi kemungkinan terjadinya kesalahan bencana dalam spesifikasi dan implementasi protokol, serta memudahkan verifikasi bahwa kesalahan semacam itu tidak ada.
Mempersempit Permukaan Serangan: Mengurangi komponen kompleks dalam protokol, mengurangi risiko diserang oleh kelompok kepentingan tertentu.
Dalam sejarahnya, Ethereum (kadang-kadang karena keputusan pribadi saya) sering kali gagal mempertahankan kesederhanaan, yang mengakibatkan biaya pengembangan yang terlalu tinggi, peningkatan risiko keamanan, dan budaya penelitian dan pengembangan yang tertutup, sementara manfaat dari pengejaran kompleksitas ini sering kali terbukti ilusif. Artikel ini akan membahas bagaimana Ethereum lima tahun ke depan dapat mendekati kesederhanaan Bitcoin.
Lapisan konsensus yang disederhanakan
Desain lapisan konsensus baru (dulu dikenal sebagai "rantai penanda") bertujuan untuk memanfaatkan pengalaman selama sepuluh tahun terakhir dalam teori konsensus, pengembangan ZK-SNARK, ekonomi staking, dan bidang lainnya, untuk membangun lapisan konsensus yang lebih sederhana dan optimal dalam jangka panjang. Dibandingkan dengan rantai penanda yang ada, desain baru ini secara signifikan menyederhanakan:
Desain final 3-slot: Menghapus konsep slot, epoch, pengelompokan komite, dan mekanisme pemrosesan efisien terkait (seperti komite sinkron). Implementasi dasar finalitas 3-slot hanya memerlukan sekitar 200 baris kode, dan dibandingkan dengan Gasper, keamanannya mendekati optimal.
Mengurangi jumlah validator aktif: Memungkinkan penggunaan aturan pemilihan fork yang lebih sederhana untuk meningkatkan keamanan.
Protokol agregasi berbasis STARK: Siapa pun dapat menjadi agregator, tanpa perlu mempercayai agregator atau membayar biaya tinggi untuk ruang penyimpanan yang berulang. Kompleksitas kriptografi agregasi cukup tinggi, tetapi kompleksitas tersebut sangat terbungkus, dengan risiko sistemik yang rendah.
Penyederhanaan Arsitektur P2P: Faktor-faktor di atas mungkin mendukung arsitektur jaringan peer-to-peer yang lebih sederhana dan lebih kuat.
Mendesain ulang mekanisme validator: termasuk mekanisme masuk, keluar, penarikan, peralihan kunci, kebocoran ketidakaktifan, dan lainnya, menyederhanakan jumlah baris kode dan memberikan jaminan yang lebih jelas (seperti periode subjektivitas lemah).
Keuntungan dari lapisan konsensus adalah relatif independennya dari lapisan eksekusi EVM, sehingga ada ruang yang besar untuk perbaikan berkelanjutan. Tantangan yang lebih besar adalah bagaimana menerapkan penyederhanaan serupa di lapisan eksekusi.
Lapisan Eksekusi Sederhana
Kompleksitas EVM semakin meningkat, dan banyak dari kompleksitas tersebut terbukti tidak perlu (sebagian karena kesalahan keputusan pribadi saya): mesin virtual 256-bit terlalu dioptimalkan untuk bentuk kriptografi tertentu yang kini sudah mulai usang, prekompilasi dioptimalkan untuk satu kasus penggunaan namun jarang digunakan.
Menangani masalah ini satu per satu memiliki efek yang terbatas. Misalnya, menghapus opcode SELFDESTRUCT membutuhkan usaha yang sangat besar, tetapi hanya memberikan sedikit keuntungan. Perdebatan baru-baru ini tentang EOF (EVM Object Format) juga menunjukkan tantangan serupa.
Saya baru-baru ini mengajukan rencana yang lebih radikal: alih-alih melakukan perubahan skala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan 1,5 kali lipat keuntungan, lebih baik beralih ke mesin virtual yang lebih baik dan lebih sederhana untuk mendapatkan 100 kali lipat keuntungan. Mirip dengan "The Merge", kita mengurangi jumlah perubahan yang merusak, tetapi membuat setiap perubahan lebih berarti. Secara khusus, saya menyarankan untuk mengganti EVM dengan RISC-V, atau mesin virtual lain yang digunakan oleh pembuktian ZK Ethereum. Ini akan membawa:
Peningkatan efisiensi yang signifikan: Eksekusi kontrak pintar (di dalam pembuktian) tidak memerlukan biaya interpreter, langsung dijalankan. Data dari Succinct menunjukkan bahwa dalam banyak skenario, kinerja dapat meningkat lebih dari 100 kali.
Peningkatan Kesederhanaan yang Signifikan: Spesifikasi RISC-V jauh lebih sederhana dibandingkan EVM, dan alternatif (seperti Cairo) juga sangat ringkas.
Motivasi mendukung EOF: seperti pemisahan kode, analisis statis yang lebih ramah, batas ukuran kode yang lebih besar, dll.
Lebih banyak pilihan pengembang: Solidity dan Vyper dapat menambahkan backend untuk dikompilasi ke mesin virtual baru. Jika memilih RISC-V, pengembang bahasa arus utama juga dapat dengan mudah memindahkan kode ke mesin virtual tersebut.
Menghapus sebagian besar precompiled: mungkin hanya menyisakan operasi kurva eliptik yang sangat dioptimalkan (setelah komputer kuantum menjadi umum, bahkan ini juga akan hilang).
Kekurangan utama adalah, berbeda dengan EOF yang sudah siap, manfaat dari mesin virtual baru membutuhkan waktu lebih lama untuk dirasakan oleh pengembang. Kita dapat mengatasi masalah ini dengan menerapkan perbaikan EVM bernilai tinggi dalam jangka pendek (seperti meningkatkan batas ukuran kode kontrak, mendukung DUP/SWAP17–32).
Ini akan membawa mesin virtual yang lebih sederhana. Tantangan inti adalah: bagaimana menangani EVM yang ada?
Kebijakan kompatibilitas mundur untuk transisi mesin virtual
Tantangan terbesar dalam menyederhanakan (atau meningkatkan tanpa menambah kompleksitas) EVM adalah bagaimana menyeimbangkan pencapaian tujuan dengan kompatibilitas mundur aplikasi yang ada.
Pertama-tama perlu dipahami: repositori kode Ethereum (bahkan dalam satu klien saja) tidak memiliki satu definisi tunggal.
Tujuannya adalah untuk memperkecil area hijau sebanyak mungkin: logika yang diperlukan untuk node berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, bukti, verifikasi, FOCIL (aturan pemilihan fork) dan pembangunan blok "biasa".
Area oranye tidak dapat dikurangi: Jika spesifikasi protokol menghapus atau mengubah fungsi lapisan eksekusi tertentu (seperti mesin virtual, pra-kompilasi, dll.), klien yang memproses blok sejarah masih harus mempertahankan kode terkait. Namun, klien baru, ZK-EVM atau pembuktian formal dapat sepenuhnya mengabaikan area oranye.
Area kuning yang baru ditambahkan: sangat berharga untuk memahami rantai saat ini atau mengoptimalkan konstruksi blok, tetapi tidak termasuk dalam logika konsensus. Misalnya, Etherscan dan beberapa pembangun blok mendukung operasi pengguna ERC-4337. Jika kita menggantikan beberapa fungsi Ethereum (seperti EOA dan jenis transaksi lama yang didukungnya) dengan implementasi RISC-V di on-chain, kode konsensus akan sangat disederhanakan, tetapi node khusus mungkin tetap menggunakan kode asli untuk analisis.
Kompleksitas area oranye dan kuning adalah kompleksitas pengemasan, orang yang memahami protokol dapat melewati bagian-bagian ini, Ethereum dapat mengabaikannya, kesalahan di area ini tidak akan memicu risiko konsensus. Oleh karena itu, kompleksitas kode di area oranye dan kuning jauh lebih kecil bahayanya dibandingkan dengan kompleksitas area hijau.
Pemindahan kode dari area hijau ke area kuning mirip dengan strategi Apple yang memastikan kompatibilitas jangka panjang melalui lapisan terjemahan Rosetta.
Terinspirasi oleh artikel terbaru dari tim Ipsilon, saya mengusulkan proses perubahan mesin virtual berikut (menggunakan EVM ke RISC-V sebagai contoh, tetapi juga dapat digunakan untuk EVM ke Cairo atau RISC-V ke mesin virtual yang lebih baik):
Meminta penyusunan pra-kompilasi baru untuk menyediakan implementasi RISC-V di dalam blockchain: Membiarkan ekosistem secara bertahap beradaptasi dengan mesin virtual RISC-V.
Memperkenalkan RISC-V sebagai opsi pengembang: Protokol mendukung RISC-V dan EVM, kontrak dari kedua mesin virtual dapat berinteraksi secara bebas.
Mengganti sebagian besar precompiled: Kecuali untuk operasi kurva elips dan KECCAK (karena kebutuhan kecepatan ekstrem), gunakan RISC-V untuk mengganti precompiled lainnya. Menghapus precompiled melalui hard fork, sekaligus mengubah kode alamat tersebut (mirip dengan fork DAO) dari kosong menjadi implementasi RISC-V. Mesin virtual RISC-V sangat sederhana, bahkan jika berhenti di sini sudah menyederhanakan protokol secara signifikan.
Menerapkan interpreter EVM di RISC-V: sebagai kontrak pintar yang dihubungkan ke rantai (karena pembuktian ZK diperlukan). Setelah beberapa tahun rilis awal, kontrak EVM yang ada dijalankan melalui interpreter ini.
Setelah menyelesaikan langkah ke-4, banyak "implementasi EVM" masih akan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis rantai, tetapi tidak lagi menjadi bagian dari norma konsensus kunci. Konsensus Ethereum akan "secara native" hanya memahami RISC-V.
Menyederhanakan melalui komponen protokol berbagi
Cara ketiga untuk mengurangi kompleksitas total protokol (juga yang paling mudah diremehkan) adalah dengan berbagi standar yang uniform di berbagai bagian tumpukan protokol sebanyak mungkin. Protokol yang melakukan hal yang sama di berbagai skenario biasanya tidak ada gunanya, tetapi pola ini tetap sering muncul, terutama karena berbagai bagian peta jalan protokol kurang komunikasi. Berikut adalah beberapa contoh konkret tentang bagaimana berbagi komponen menyederhanakan Ethereum.
Unified erasure code
Kami memerlukan kode penghapusan di tiga skenario:
Sampling ketersediaan data: Klien memverifikasi bahwa blok telah diterbitkan.
Siaran P2P yang lebih cepat: Node dapat menerima blok setelah menerima n/2 segmen, mencapai keseimbangan antara latensi dan redundansi.
Penyimpanan sejarah terdistribusi: penyimpanan data sejarah Ethereum dalam potongan, setiap grup n/2 potongan dapat memulihkan potongan yang tersisa, mengurangi risiko kehilangan potongan tunggal.
Jika menggunakan kode penghapusan yang sama (baik itu Reed-Solomon, kode linier acak, dll) dalam tiga skenario, Anda akan memperoleh keuntungan berikut:
Minimalkan jumlah kode: kurangi total jumlah baris kode.
Meningkatkan efisiensi: Jika node mengunduh sebagian potongan untuk suatu skenario, data ini dapat digunakan untuk skenario lain.
Pastikan verifikasi: Semua potongan dari skenario dapat diverifikasi berdasarkan akar.
Jika menggunakan kode penghapusan yang berbeda, setidaknya harus memastikan kompatibilitas, misalnya kode Reed-Solomon tingkat sampling ketersediaan data dan kode linier acak vertikal beroperasi di domain yang sama.
Format serialisasi yang seragam
Format serialisasi Ethereum saat ini hanya sebagian terstandarisasi, karena data dapat diserialisasi dan disiarkan dalam format apa pun. Pengecualian adalah hash tanda tangan transaksi, yang perlu di-hash dalam format yang terstandarisasi. Di masa depan, tingkat standarisasi format serialisasi akan meningkat lebih lanjut karena alasan berikut:
Abstraksi Akun Lengkap (EIP-7701): Konten lengkap transaksi terlihat oleh mesin virtual.
Batas Gas yang lebih tinggi: Data lapisan eksekusi harus dimasukkan ke dalam blok data (blobs).
Saat itu, kita memiliki kesempatan untuk menyelaraskan format serialisasi tiga tingkat Ethereum: lapisan eksekusi, lapisan konsensus, dan panggilan ABI kontrak pintar.
Saya mengusulkan untuk menggunakan SSZ, karena SSZ:
Mudah untuk mendekode: termasuk dalam kontrak pintar (karena desain berbasis 4 byte dan sedikit kasus tepi).
Sudah digunakan secara luas di lapisan konsensus.
Sangat mirip dengan ABI yang ada: penyesuaian alat relatif sederhana.
Telah ada upaya untuk migrasi sepenuhnya ke SSZ, kita harus mempertimbangkan dan melanjutkan upaya ini saat merencanakan upgrade di masa depan.
Struktur pohon terintegrasi
Jika bermigrasi dari EVM ke RISC-V (atau mesin virtual minimum lainnya yang dapat dipilih), pohon Merkle Patricia heksadesimal akan menjadi kendala terbesar dalam membuktikan eksekusi blok, bahkan dalam kasus rata-rata sekalipun. Migrasi ke pohon biner yang berbasis fungsi hash yang lebih baik akan secara signifikan meningkatkan efisiensi pembuktian, sambil mengurangi biaya data dalam skenario seperti klien ringan.
Saat migrasi, pastikan lapisan konsensus menggunakan struktur pohon yang sama. Ini akan memungkinkan lapisan konsensus Ethereum dan lapisan eksekusi untuk diakses dan dianalisis melalui kode yang sama.
Dari sekarang hingga masa depan
Kesederhanaan dalam banyak hal mirip dengan desentralisasi, keduanya merupakan hulu dari tujuan ketahanan. Menekankan kesederhanaan dengan jelas memerlukan perubahan budaya tertentu. Manfaatnya seringkali sulit untuk diukur, sementara biaya dari upaya tambahan dan pengorbanan beberapa fitur mencolok terlihat langsung. Namun, seiring waktu, manfaatnya akan semakin jelas — Bitcoin itu sendiri adalah contoh yang sangat baik.
Saya mengusulkan untuk meniru tinygrad, menetapkan target jumlah baris kode maksimum yang jelas untuk standar jangka panjang Ethereum, sehingga kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin. Kode yang menangani aturan sejarah Ethereum akan tetap ada, tetapi harus ditempatkan di luar jalur kunci konsensus. Pada saat yang sama, kita harus memegang prinsip memilih solusi yang lebih sederhana, mengutamakan pengemasan kompleksitas daripada kompleksitas sistemik, dan membuat pilihan desain yang memberikan atribut dan jaminan yang jelas.