Ethereum bertujuan untuk menjadi buku besar dunia: sebuah platform untuk menyimpan aset peradaban dan catatan, yang menjadi lapisan dasar untuk keuangan, pemerintahan, dan sertifikasi data bernilai tinggi. Ini memerlukan dua syarat: skalabilitas dan ketahanan. Hard fork Fusaka bertujuan untuk meningkatkan ruang yang tersedia untuk data lapisan dua (L2) sebesar 10 kali lipat, sementara peta jalan yang direncanakan untuk 2026 juga mengusulkan perluasan besar-besaran yang serupa untuk lapisan satu (L1). Sementara itu, Ethereum telah menyelesaikan pembaruan penggabungan ke mekanisme proof of stake, keanekaragaman kliennya meningkat dengan cepat, serta pekerjaan pada kemampuan verifikasi zero-knowledge (ZK Verifiability) dan ketahanan terhadap komputasi kuantum juga sedang dilanjutkan, berbagai aplikasi semakin kuat.
Artikel ini bertujuan untuk memfokuskan pada satu aspek ketahanan (yang pada akhirnya juga akan mempengaruhi skalabilitas), yang sama pentingnya tetapi sering kali diremehkan, yaitu kesederhanaan protokol.
Salah satu keunggulan Bitcoin adalah protokolnya yang sangat sederhana dan indah.
Blockchain terdiri dari serangkaian blok, di mana setiap blok terhubung dengan blok sebelumnya melalui nilai hash. Validitas blok diverifikasi melalui mekanisme proof of work, yaitu dengan memverifikasi apakah beberapa digit pertama dari nilai hashnya adalah nol. Setiap blok berisi sejumlah transaksi, di mana koin yang digunakan berasal dari hasil penambangan atau dari output transaksi sebelumnya. Mekanisme inti dari protokol Bitcoin terletak di sini. Bahkan siswa SMA yang cerdas dapat sepenuhnya memahami protokol ini, dan programmer bahkan dapat menjadikannya sebagai proyek sampingan untuk menulis klien.
Mempertahankan kesederhanaan protokol memberikan keuntungan kunci bagi Bitcoin atau Ethereum untuk menjadi lapisan dasar netral yang diakui secara global:
Protokol yang sederhana lebih mudah untuk dianalisis, dapat menarik lebih banyak peserta untuk terlibat dalam penelitian, pengembangan, dan kerja tata kelola protokol, sekaligus mengurangi risiko monopoli teknologi.
Struktur protokol yang disederhanakan secara signifikan mengurangi investasi pengembangan yang diperlukan untuk integrasi dengan infrastruktur baru (seperti klien, pembuktian, alat pencatatan, dan alat pengembangan lainnya).
Desain yang sederhana dari perjanjian secara efektif mengurangi biaya pemeliharaan jangka panjang.
Risiko kerentanan serius dalam spesifikasi dan implementasi protokol telah berkurang secara signifikan, dan memudahkan verifikasi keamanan sistem.
Mengurangi permukaan serangan sosial: Penyederhanaan komponen membuat sistem lebih mudah dilindungi dari infiltrasi kepentingan khusus, meningkatkan keamanan keseluruhan.
Dalam sejarahnya, Ethereum sering kali gagal menerapkan prinsip kesederhanaan dalam desain protokol (sebagian alasannya berasal dari keputusan pribadi), yang secara langsung menyebabkan tingginya biaya pengembangan, seringnya masalah keamanan, serta keterasingan budaya pengembangan. Akar dari masalah-masalah ini sering kali terletak pada kejaran terhadap keuntungan jangka pendek yang telah terbukti tidak efektif oleh praktik. Artikel ini akan menjelaskan bagaimana Ethereum dapat mencapai kesederhanaan protokol yang mendekati Bitcoin dalam lima tahun ke depan.
Lapisan Konsensus yang Disederhanakan
Simulasi finalitas tiga slot waktu di 3sf - mini (kode nama jaringan pengujian Ethereum)
Rencana lapisan konsensus versi baru (sebelumnya diberi nama "Beam Chain") bertujuan untuk menggabungkan hasil penelitian selama sepuluh tahun terakhir di bidang teori konsensus, bukti nol pengetahuan (ZK-SNARK), dan ekonomi staking, untuk membangun mekanisme konsensus optimal yang berorientasi pada pengembangan jangka panjang bagi Ethereum. Dibandingkan dengan rantai beacon yang ada, rencana ini memiliki karakteristik yang sangat disederhanakan, yang secara spesifik tercermin dalam beberapa aspek berikut:
Inovasi arsitektur finalitas 3-slot: menghilangkan pembagian konsep slot independen dan epoch, menghapus mekanisme rotasi komite dan komponen kompleks lainnya seperti komite sinkron, secara signifikan menyederhanakan spesifikasi protokol. Implementasi inti hanya memerlukan sekitar 200 baris kode, mencapai tingkat keamanan yang hampir optimal dibandingkan dengan protokol Gasper.
Optimasi manajemen node verifikasi: Dengan membatasi jumlah node verifikasi aktif, aturan pemilihan fork (fork choice rule) dapat mengadopsi skema implementasi yang lebih sederhana, sambil menjaga keamanan sistem.
Peningkatan Protokol Agregasi: Mekanisme agregasi berbasis STARK memungkinkan node mana pun untuk mengambil peran agregasi, menghindari ketergantungan pada kepercayaan terhadap agregator serta masalah pemborosan sumber daya dari bidang bit (bitfield) yang berulang. Meskipun kriptografi agregasi itu sendiri memiliki kompleksitas yang tinggi, karakteristiknya yang sangat terbungkus secara signifikan mengurangi risiko sistemik.
Perbaikan arsitektur jaringan P2P: Dua optimasi di atas memberikan kemungkinan untuk membangun arsitektur jaringan peer-to-peer yang lebih sederhana dan efisien.
Rekonstruksi Proses Verifikasi: Meredesain mekanisme akses masuk, keluar, penarikan, migrasi kunci, dan hukuman malas dari node verifikasi, sambil mengurangi jumlah kode, dan memperjelas mekanisme perlindungan parameter inti (seperti periode subjektif lemah).
Keunggulan teknis: Fitur dekoupling relatif antara lapisan konsensus dan lapisan eksekusi EVM memberikan ruang teknis yang lebih besar untuk optimasi berkelanjutan. Dibandingkan dengan itu, perbaikan sejenis di lapisan eksekusi menghadapi tantangan yang lebih besar.
Lapisan Eksekusi Sederhana
Kompleksitas Mesin Virtual Ethereum (EVM) terus meningkat, di mana banyak desain kompleks telah terbukti tidak perlu (dalam banyak kasus merupakan kesalahan keputusan saya): mesin virtual 256-bit yang terlalu dioptimalkan untuk algoritma kriptografi tertentu, sementara algoritma tersebut kini perlahan-lahan kehilangan pentingnya; serta kontrak prakomposisi yang terlalu dirancang untuk satu skenario penggunaan, di mana tingkat penggunaan aktualnya sangat rendah.
Mencoba menyelesaikan masalah yang ada melalui perbaikan kecil-kecilan sudah tidak mungkin. Menghapus opcode SELFDESTRUCT memerlukan upaya besar tetapi hanya memberikan keuntungan terbatas, dan perdebatan terbaru tentang EOF semakin menyoroti kesulitan dalam melakukan modifikasi bertahap pada mesin virtual.
Sebagai alternatif, saya baru-baru ini mengajukan jalur transformasi yang lebih radikal: daripada melakukan modifikasi skala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan peningkatan kinerja 1,5 kali, lebih baik langsung beralih ke arsitektur mesin virtual yang baru dan jauh lebih unggul untuk mencapai lompatan kinerja seratus kali lipat. Sama seperti penggabungan (The Merge), kami mengurangi jumlah perubahan yang merusak, tetapi meningkatkan nilai strategis dari setiap perubahan. Secara khusus, saya merekomendasikan untuk menggunakan arsitektur RISC-V atau mesin virtual yang digunakan oleh program pembuktian ZK Ethereum sebagai pengganti EVM yang ada. Transformasi ini akan membawa:
Peningkatan Revolusi Efisiensi: Dalam lingkungan bukti ZK, kontrak pintar dapat langsung dijalankan pada arsitektur target tanpa biaya interpreter. Data Succinct menunjukkan bahwa dalam sebagian besar skenario, kinerja dapat meningkat lebih dari seratus kali lipat.
Arsitektur yang sangat disederhanakan: Spesifikasi RISC-V jauh lebih ringkas dibandingkan dengan EVM, dan solusi kandidat lainnya (seperti Cairo) juga memiliki karakteristik kesederhanaan.
Mewarisi keuntungan inti EOF: termasuk manajemen pemotongan kode, dukungan analisis statis yang lebih ramah, dan batas kapasitas kode yang lebih besar.
Ekstensi alat pengembang: Solidity dan Vyper dapat mendukung arsitektur baru melalui penambahan dukungan kompilasi backend; jika memilih RISC-V, pengembang bahasa utama dapat langsung memindahkan kode yang ada.
Optimasi kontrak pra-kompilasi: sebagian besar fungsi pra-kompilasi tidak akan lagi diperlukan, hanya menyisakan operasi kurva eliptik yang sangat dioptimalkan (mungkin akan dihapus seiring perkembangan komputasi kuantum).
Tantangan utama adalah: berbeda dari skema EOF yang dapat segera diterapkan, mesin virtual baru memerlukan waktu lebih lama untuk memberikan manfaat kepada pengembang. Sebagai solusi transisi jangka pendek, beberapa perbaikan EVM yang bernilai tinggi dapat diimplementasikan secara sinkron (seperti meningkatkan batas ukuran kode kontrak, mengoptimalkan instruksi DUP/SWAP).
Transformasi ini akan secara signifikan menyederhanakan arsitektur mesin virtual. Masalah inti adalah: bagaimana cara menangani ekosistem EVM yang ada dengan baik?
Kebijakan kompatibilitas mundur untuk migrasi mesin virtual
Tantangan terbesar dalam menyederhanakan (atau mengoptimalkan tanpa menambah kompleksitas) bagian mana pun dari EVM adalah bagaimana menyeimbangkan pencapaian tujuan yang diharapkan dengan mempertahankan kompatibilitas mundur aplikasi yang ada.
Pertama-tama, perlu ditegaskan bahwa: bahkan untuk klien tunggal, tidak ada standar tunggal untuk mendefinisikan apa itu "repositori kode Ethereum".
Tujuannya adalah meminimalkan area hijau: yaitu node untuk menjalankan logika yang diperlukan untuk berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, menghasilkan dan memverifikasi bukti, FOCIL (catatan: perlu dikonfirmasi apakah ini singkatan istilah profesional) serta proses pembangunan blok "dasar".
Area oranye tidak dapat diperkecil: Jika fungsi lapisan eksekusi (apakah itu mesin virtual, kontrak prakomplilasi, atau mekanisme lain) dihapus dari spesifikasi protokol atau fungsinya berubah, klien yang harus memproses blok sejarah harus mempertahankan fungsi tersebut; namun klien baru (termasuk ZK-EVM atau alat verifikasi formal) dapat sepenuhnya mengabaikan bagian ini.
Area kuning baru: mengacu pada kode yang sangat berharga untuk analisis data di rantai saat ini atau pembangunan blok yang optimal, tetapi tidak termasuk dalam mekanisme konsensus. Contoh klasik adalah dukungan Etherscan dan beberapa pembangun blok untuk operasi pengguna ERC-4337. Jika fungsi inti Ethereum (seperti akun eksternal EOA dan berbagai jenis transaksi lama yang didukungnya) diganti dengan implementasi RISC-V di rantai, maka kode konsensus akan sangat disederhanakan, tetapi node khusus mungkin masih perlu menggunakan kode yang ada untuk pemrosesan analisis.
Kompleksitas area oranye dan kuning termasuk dalam kompleksitas pengemasan, siapa pun yang ingin memahami protokol dapat melewati bagian ini, dan solusi implementasi Ethereum juga dapat memilih untuk mengabaikannya. Selain itu, cacat kode di area ini tidak akan menimbulkan risiko konsensus. Ini berarti bahwa, dibandingkan dengan kompleksitas kode di area hijau, kompleksitas area oranye dan kuning memiliki dampak negatif yang jauh lebih rendah terhadap keseluruhan sistem.
Pemikiran untuk memindahkan kode dari area hijau ke area kuning mirip dengan solusi teknologi yang diimplementasikan oleh Apple melalui lapisan terjemahan Rosetta untuk mencapai kompatibilitas jangka panjang.
Semua kontrak pra-kompilasi yang baru dikembangkan harus mencakup implementasi RISC-V yang sesuai di on-chain. Langkah ini bertujuan untuk mendorong ekosistem secara bertahap beradaptasi dengan lingkungan mesin virtual RISC-V (misalnya, migrasi dari EVM ke RISC-V, solusi ini juga berlaku untuk migrasi dari EVM ke Cairo atau mesin virtual yang lebih baik lainnya):
Dukungan paralel untuk dua mesin virtual: Secara protokol, mendukung secara native dua mesin virtual RISC-V dan EVM. Pengembang dapat bebas memilih bahasa pemrograman, dan kontrak yang ditulis di berbagai mesin virtual dapat berinteraksi tanpa hambatan.
Penggantian kontrak pra-kompilasi secara bertahap: kecuali untuk operasi kurva elips dan algoritma hash KECCAK (karena permintaan kinerja yang sangat dioptimalkan), semua kontrak pra-kompilasi digantikan dengan implementasi RISC-V melalui hard fork.
Tindakan spesifik adalah: menghapus kontrak pra-kompilasi asli sekaligus mengubah kode alamat tersebut (menggunakan mode fork DAO) dari keadaan kosong menjadi implementasi RISC-V yang sesuai. Karena kesederhanaan tinggi arsitektur RISC-V, meskipun hanya menyelesaikan langkah ini, kompleksitas keseluruhan sistem tetap akan berkurang.
Penempatan interpreter EVM di blockchain: Menerapkan interpreter EVM berbasis RISC-V (alat bukti ZK telah mendorong pengembangan semacam ini) dan menyebarkannya sebagai kontrak pintar di blockchain. Setelah beberapa tahun rilis versi awal, kontrak EVM yang ada akan dieksekusi melalui interpreter ini, sehingga menyelesaikan transisi yang mulus ke mesin virtual baru.
Mencapai penyederhanaan melalui komponen protokol berbagi
Setelah langkah keempat selesai, banyak "solusi implementasi EVM" akan tetap ada dan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis data on-chain, tetapi implementasi ini tidak akan lagi menjadi bagian dari spesifikasi konsensus inti. Pada saat itu, mekanisme konsensus Ethereum akan "secara native" hanya mendukung arsitektur RISC-V.
Mewujudkan penyederhanaan melalui komponen protokol berbagi
Metode ketiga untuk mengurangi kompleksitas keseluruhan protokol (yang juga merupakan cara yang paling sering diremehkan) adalah berbagi standar yang konsisten di antara berbagai lapisan tumpukan protokol sebanyak mungkin. Umumnya, tidak perlu dan tidak menguntungkan untuk mengimplementasikan fungsi yang sama dengan protokol yang berbeda di berbagai modul, tetapi pola desain semacam itu masih umum ada, terutama karena kurangnya kolaborasi yang efektif antara bagian-bagian peta jalan protokol. Berikut adalah contoh konkret di mana penguatan penggunaan ulang komponen lintas lapisan dapat menyederhanakan Ethereum.
Solusi kode penghapusan yang dibagikan secara seragam
Tiga jenis skenario aplikasi kode penghapus:
Sampling ketersediaan data: Klien harus menggunakan kode penghapusan untuk memverifikasi apakah blok telah diterbitkan, memastikan integritas data.
Siaran P2P yang efisien: Node dapat mengkonfirmasi blok saat menerima n/2 dari n potongan, mencapai keseimbangan optimal antara pengurangan latensi dan redundansi.
Penyimpanan sejarah terdistribusi: Data sejarah Ethereum dibagi menjadi beberapa blok data, memenuhi:
Setiap blok data dapat diverifikasi secara independen
Dalam setiap grup, n/2 blok data dapat digunakan untuk memulihkan sisa n/2 blok data.
Desain ini secara signifikan mengurangi risiko kehilangan data titik tunggal.
Jika menggunakan kode penghapusan yang sama (seperti kode Reed-Solomon, kode linier acak, dll.) dalam tiga skenario berikut, akan membawa keuntungan signifikan:
Penyederhanaan kode;
Peningkatan efisiensi: Ketika node perlu mengunduh data shard (bukan blok penuh) karena suatu skenario, data tersebut dapat langsung digunakan untuk skenario lain, menghindari transmisi yang berulang;
Semua blok data di semua skenario dapat diverifikasi secara seragam melalui hash akar.
Jika menggunakan kode penghapusan yang berbeda, harus memenuhi persyaratan kompatibilitas: misalnya, dalam pengambilan sampel ketersediaan data (DAS) shard, kode Reed-Solomon horizontal dan kode linier acak vertikal dapat digunakan secara bersamaan, tetapi kedua jenis pengkodean harus dihitung berdasarkan bidang hingga yang sama.
Format serialisasi yang seragam
Format serialisasi Ethereum saat ini masih dalam keadaan semi-normatif—data dapat diserialisasi ulang ke dalam format apa pun dan disebarkan, satu-satunya pengecualian adalah hash tanda tangan transaksi, di mana skenario ini harus menggunakan format normatif untuk memastikan konsistensi hash. Namun di masa depan, tingkat normatif dari format serialisasi akan semakin diperkuat, alasan utamanya termasuk:
Abstraksi Akun (EIP-7701): Konten transaksi lengkap akan sepenuhnya terlihat oleh mesin virtual (VM)
Skenario Batas Gas Tinggi: Seiring dengan peningkatan batas Gas blok, data lapisan eksekusi perlu disimpan dalam struktur blob.
Ketika perubahan di atas terjadi, kita dapat memanfaatkan kesempatan ini untuk menyatukan standar serialisasi tiga lapisan kunci Ethereum: (i) lapisan eksekusi (ii) lapisan konsensus (iii) ABI pemanggilan kontrak pintar
Disarankan untuk menggunakan format serialisasi SSZ, SSZ memiliki keuntungan sebagai berikut:
Dekode yang efisien, termasuk skenario yang melibatkan kontrak pintar, dapat didekode dengan cepat, berkat desain berbasis 4 byte dan penanganan kondisi batas yang lebih sedikit.
Lapisan konsensus digunakan secara luas, telah terintegrasi secara mendalam pada lapisan konsensus.
Sangat mirip dengan ABI yang ada, memudahkan peningkatan dan penyesuaian alat.
Saat ini, tim teknis terkait telah mendorong pekerjaan migrasi penuh SSZ. Disarankan untuk melanjutkan jalur teknis ini dalam rencana peningkatan mendatang dan memperluas berdasarkan hasil yang ada.
Pohon struktur berbagi yang bersatu
Ketika beralih dari EVM ke RISC-V (atau arsitektur mesin virtual lainnya yang lebih sederhana), pohon Merkle Patricia enam cabang akan menjadi bottleneck kinerja terbesar dalam bukti eksekusi blok (bahkan dalam skenario biasa sekalipun). Beralih ke struktur pohon biner yang berbasis fungsi hash yang lebih baik akan secara signifikan meningkatkan efisiensi bukti dan mengurangi biaya penyimpanan data untuk node ringan dan skenario aplikasi lainnya.
Saat melaksanakan migrasi ini, struktur pohon yang sama harus digunakan untuk menyatukan lapisan konsensus dan lapisan eksekusi. Tindakan ini dapat memastikan bahwa seluruh tumpukan Ethereum (termasuk lapisan konsensus dan lapisan eksekusi) menggunakan satu set logika kode yang sama untuk akses dan analisis data.
Jalur evolusi dari keadaan saat ini ke tujuan
Kesederhanaan memiliki kesamaan dengan desentralisasi dalam banyak hal, keduanya merupakan prasyarat dasar untuk mencapai ketahanan sistem. Menetapkan kesederhanaan sebagai nilai inti memerlukan perubahan di tingkat budaya: manfaatnya seringkali sulit untuk terlihat secara instan, sementara keuntungan jangka pendek yang dihasilkan dari mengejar fungsi yang kompleks sangat jelas. Namun, seiring berjalannya waktu, keuntungan dari kesederhanaan akan semakin terlihat - perjalanan perkembangan Bitcoin adalah bukti kuat dari pandangan ini.
Saya mengusulkan untuk merancang protokol Ethereum berdasarkan pengalaman praktis proyek TinyGrad, untuk menetapkan batasan jumlah baris kode yang jelas dalam spesifikasi Ethereum jangka panjang, berusaha agar tingkat kesederhanaan kode kunci konsensus Ethereum mendekati tingkat Bitcoin. Secara spesifik, kode terkait yang menangani aturan sejarah Ethereum dapat tetap dipertahankan, tetapi harus dipisahkan secara ketat dari jalur kunci konsensus, untuk memastikan bahwa ia tidak mempengaruhi logika konsensus inti; pada saat yang sama, dalam pemilihan solusi teknis harus menerapkan filosofi desain "prioritaskan solusi yang lebih sederhana", lebih memilih untuk membungkus kompleksitas daripada menyebarkan kompleksitas sistemik, dan memastikan semua keputusan desain dapat memberikan karakteristik dan jaminan yang jelas dan dapat diverifikasi, sehingga secara keseluruhan membentuk budaya teknologi yang berorientasi pada kesederhanaan.
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 tulisan baru: bagaimana Ethereum mencapai arsitektur yang disederhanakan yang setara dengan Bitcoin?
Judul Asli: Menyederhanakan L1
Ditulis oleh: Vitalik
Compiler: lenaxin, ChainCatcher
Ethereum bertujuan untuk menjadi buku besar dunia: sebuah platform untuk menyimpan aset peradaban dan catatan, yang menjadi lapisan dasar untuk keuangan, pemerintahan, dan sertifikasi data bernilai tinggi. Ini memerlukan dua syarat: skalabilitas dan ketahanan. Hard fork Fusaka bertujuan untuk meningkatkan ruang yang tersedia untuk data lapisan dua (L2) sebesar 10 kali lipat, sementara peta jalan yang direncanakan untuk 2026 juga mengusulkan perluasan besar-besaran yang serupa untuk lapisan satu (L1). Sementara itu, Ethereum telah menyelesaikan pembaruan penggabungan ke mekanisme proof of stake, keanekaragaman kliennya meningkat dengan cepat, serta pekerjaan pada kemampuan verifikasi zero-knowledge (ZK Verifiability) dan ketahanan terhadap komputasi kuantum juga sedang dilanjutkan, berbagai aplikasi semakin kuat.
Artikel ini bertujuan untuk memfokuskan pada satu aspek ketahanan (yang pada akhirnya juga akan mempengaruhi skalabilitas), yang sama pentingnya tetapi sering kali diremehkan, yaitu kesederhanaan protokol.
Salah satu keunggulan Bitcoin adalah protokolnya yang sangat sederhana dan indah.
Blockchain terdiri dari serangkaian blok, di mana setiap blok terhubung dengan blok sebelumnya melalui nilai hash. Validitas blok diverifikasi melalui mekanisme proof of work, yaitu dengan memverifikasi apakah beberapa digit pertama dari nilai hashnya adalah nol. Setiap blok berisi sejumlah transaksi, di mana koin yang digunakan berasal dari hasil penambangan atau dari output transaksi sebelumnya. Mekanisme inti dari protokol Bitcoin terletak di sini. Bahkan siswa SMA yang cerdas dapat sepenuhnya memahami protokol ini, dan programmer bahkan dapat menjadikannya sebagai proyek sampingan untuk menulis klien.
Mempertahankan kesederhanaan protokol memberikan keuntungan kunci bagi Bitcoin atau Ethereum untuk menjadi lapisan dasar netral yang diakui secara global:
Protokol yang sederhana lebih mudah untuk dianalisis, dapat menarik lebih banyak peserta untuk terlibat dalam penelitian, pengembangan, dan kerja tata kelola protokol, sekaligus mengurangi risiko monopoli teknologi.
Struktur protokol yang disederhanakan secara signifikan mengurangi investasi pengembangan yang diperlukan untuk integrasi dengan infrastruktur baru (seperti klien, pembuktian, alat pencatatan, dan alat pengembangan lainnya).
Desain yang sederhana dari perjanjian secara efektif mengurangi biaya pemeliharaan jangka panjang.
Risiko kerentanan serius dalam spesifikasi dan implementasi protokol telah berkurang secara signifikan, dan memudahkan verifikasi keamanan sistem.
Mengurangi permukaan serangan sosial: Penyederhanaan komponen membuat sistem lebih mudah dilindungi dari infiltrasi kepentingan khusus, meningkatkan keamanan keseluruhan.
Dalam sejarahnya, Ethereum sering kali gagal menerapkan prinsip kesederhanaan dalam desain protokol (sebagian alasannya berasal dari keputusan pribadi), yang secara langsung menyebabkan tingginya biaya pengembangan, seringnya masalah keamanan, serta keterasingan budaya pengembangan. Akar dari masalah-masalah ini sering kali terletak pada kejaran terhadap keuntungan jangka pendek yang telah terbukti tidak efektif oleh praktik. Artikel ini akan menjelaskan bagaimana Ethereum dapat mencapai kesederhanaan protokol yang mendekati Bitcoin dalam lima tahun ke depan.
Lapisan Konsensus yang Disederhanakan
Simulasi finalitas tiga slot waktu di 3sf - mini (kode nama jaringan pengujian Ethereum)
Rencana lapisan konsensus versi baru (sebelumnya diberi nama "Beam Chain") bertujuan untuk menggabungkan hasil penelitian selama sepuluh tahun terakhir di bidang teori konsensus, bukti nol pengetahuan (ZK-SNARK), dan ekonomi staking, untuk membangun mekanisme konsensus optimal yang berorientasi pada pengembangan jangka panjang bagi Ethereum. Dibandingkan dengan rantai beacon yang ada, rencana ini memiliki karakteristik yang sangat disederhanakan, yang secara spesifik tercermin dalam beberapa aspek berikut:
Inovasi arsitektur finalitas 3-slot: menghilangkan pembagian konsep slot independen dan epoch, menghapus mekanisme rotasi komite dan komponen kompleks lainnya seperti komite sinkron, secara signifikan menyederhanakan spesifikasi protokol. Implementasi inti hanya memerlukan sekitar 200 baris kode, mencapai tingkat keamanan yang hampir optimal dibandingkan dengan protokol Gasper.
Optimasi manajemen node verifikasi: Dengan membatasi jumlah node verifikasi aktif, aturan pemilihan fork (fork choice rule) dapat mengadopsi skema implementasi yang lebih sederhana, sambil menjaga keamanan sistem.
Peningkatan Protokol Agregasi: Mekanisme agregasi berbasis STARK memungkinkan node mana pun untuk mengambil peran agregasi, menghindari ketergantungan pada kepercayaan terhadap agregator serta masalah pemborosan sumber daya dari bidang bit (bitfield) yang berulang. Meskipun kriptografi agregasi itu sendiri memiliki kompleksitas yang tinggi, karakteristiknya yang sangat terbungkus secara signifikan mengurangi risiko sistemik.
Perbaikan arsitektur jaringan P2P: Dua optimasi di atas memberikan kemungkinan untuk membangun arsitektur jaringan peer-to-peer yang lebih sederhana dan efisien.
Rekonstruksi Proses Verifikasi: Meredesain mekanisme akses masuk, keluar, penarikan, migrasi kunci, dan hukuman malas dari node verifikasi, sambil mengurangi jumlah kode, dan memperjelas mekanisme perlindungan parameter inti (seperti periode subjektif lemah).
Keunggulan teknis: Fitur dekoupling relatif antara lapisan konsensus dan lapisan eksekusi EVM memberikan ruang teknis yang lebih besar untuk optimasi berkelanjutan. Dibandingkan dengan itu, perbaikan sejenis di lapisan eksekusi menghadapi tantangan yang lebih besar.
Lapisan Eksekusi Sederhana
Kompleksitas Mesin Virtual Ethereum (EVM) terus meningkat, di mana banyak desain kompleks telah terbukti tidak perlu (dalam banyak kasus merupakan kesalahan keputusan saya): mesin virtual 256-bit yang terlalu dioptimalkan untuk algoritma kriptografi tertentu, sementara algoritma tersebut kini perlahan-lahan kehilangan pentingnya; serta kontrak prakomposisi yang terlalu dirancang untuk satu skenario penggunaan, di mana tingkat penggunaan aktualnya sangat rendah.
Mencoba menyelesaikan masalah yang ada melalui perbaikan kecil-kecilan sudah tidak mungkin. Menghapus opcode SELFDESTRUCT memerlukan upaya besar tetapi hanya memberikan keuntungan terbatas, dan perdebatan terbaru tentang EOF semakin menyoroti kesulitan dalam melakukan modifikasi bertahap pada mesin virtual.
Sebagai alternatif, saya baru-baru ini mengajukan jalur transformasi yang lebih radikal: daripada melakukan modifikasi skala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan peningkatan kinerja 1,5 kali, lebih baik langsung beralih ke arsitektur mesin virtual yang baru dan jauh lebih unggul untuk mencapai lompatan kinerja seratus kali lipat. Sama seperti penggabungan (The Merge), kami mengurangi jumlah perubahan yang merusak, tetapi meningkatkan nilai strategis dari setiap perubahan. Secara khusus, saya merekomendasikan untuk menggunakan arsitektur RISC-V atau mesin virtual yang digunakan oleh program pembuktian ZK Ethereum sebagai pengganti EVM yang ada. Transformasi ini akan membawa:
Peningkatan Revolusi Efisiensi: Dalam lingkungan bukti ZK, kontrak pintar dapat langsung dijalankan pada arsitektur target tanpa biaya interpreter. Data Succinct menunjukkan bahwa dalam sebagian besar skenario, kinerja dapat meningkat lebih dari seratus kali lipat.
Arsitektur yang sangat disederhanakan: Spesifikasi RISC-V jauh lebih ringkas dibandingkan dengan EVM, dan solusi kandidat lainnya (seperti Cairo) juga memiliki karakteristik kesederhanaan.
Mewarisi keuntungan inti EOF: termasuk manajemen pemotongan kode, dukungan analisis statis yang lebih ramah, dan batas kapasitas kode yang lebih besar.
Ekstensi alat pengembang: Solidity dan Vyper dapat mendukung arsitektur baru melalui penambahan dukungan kompilasi backend; jika memilih RISC-V, pengembang bahasa utama dapat langsung memindahkan kode yang ada.
Optimasi kontrak pra-kompilasi: sebagian besar fungsi pra-kompilasi tidak akan lagi diperlukan, hanya menyisakan operasi kurva eliptik yang sangat dioptimalkan (mungkin akan dihapus seiring perkembangan komputasi kuantum).
Tantangan utama adalah: berbeda dari skema EOF yang dapat segera diterapkan, mesin virtual baru memerlukan waktu lebih lama untuk memberikan manfaat kepada pengembang. Sebagai solusi transisi jangka pendek, beberapa perbaikan EVM yang bernilai tinggi dapat diimplementasikan secara sinkron (seperti meningkatkan batas ukuran kode kontrak, mengoptimalkan instruksi DUP/SWAP).
Transformasi ini akan secara signifikan menyederhanakan arsitektur mesin virtual. Masalah inti adalah: bagaimana cara menangani ekosistem EVM yang ada dengan baik?
Kebijakan kompatibilitas mundur untuk migrasi mesin virtual
Tantangan terbesar dalam menyederhanakan (atau mengoptimalkan tanpa menambah kompleksitas) bagian mana pun dari EVM adalah bagaimana menyeimbangkan pencapaian tujuan yang diharapkan dengan mempertahankan kompatibilitas mundur aplikasi yang ada.
Pertama-tama, perlu ditegaskan bahwa: bahkan untuk klien tunggal, tidak ada standar tunggal untuk mendefinisikan apa itu "repositori kode Ethereum".
Tujuannya adalah meminimalkan area hijau: yaitu node untuk menjalankan logika yang diperlukan untuk berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, menghasilkan dan memverifikasi bukti, FOCIL (catatan: perlu dikonfirmasi apakah ini singkatan istilah profesional) serta proses pembangunan blok "dasar".
Area oranye tidak dapat diperkecil: Jika fungsi lapisan eksekusi (apakah itu mesin virtual, kontrak prakomplilasi, atau mekanisme lain) dihapus dari spesifikasi protokol atau fungsinya berubah, klien yang harus memproses blok sejarah harus mempertahankan fungsi tersebut; namun klien baru (termasuk ZK-EVM atau alat verifikasi formal) dapat sepenuhnya mengabaikan bagian ini.
Area kuning baru: mengacu pada kode yang sangat berharga untuk analisis data di rantai saat ini atau pembangunan blok yang optimal, tetapi tidak termasuk dalam mekanisme konsensus. Contoh klasik adalah dukungan Etherscan dan beberapa pembangun blok untuk operasi pengguna ERC-4337. Jika fungsi inti Ethereum (seperti akun eksternal EOA dan berbagai jenis transaksi lama yang didukungnya) diganti dengan implementasi RISC-V di rantai, maka kode konsensus akan sangat disederhanakan, tetapi node khusus mungkin masih perlu menggunakan kode yang ada untuk pemrosesan analisis.
Kompleksitas area oranye dan kuning termasuk dalam kompleksitas pengemasan, siapa pun yang ingin memahami protokol dapat melewati bagian ini, dan solusi implementasi Ethereum juga dapat memilih untuk mengabaikannya. Selain itu, cacat kode di area ini tidak akan menimbulkan risiko konsensus. Ini berarti bahwa, dibandingkan dengan kompleksitas kode di area hijau, kompleksitas area oranye dan kuning memiliki dampak negatif yang jauh lebih rendah terhadap keseluruhan sistem.
Pemikiran untuk memindahkan kode dari area hijau ke area kuning mirip dengan solusi teknologi yang diimplementasikan oleh Apple melalui lapisan terjemahan Rosetta untuk mencapai kompatibilitas jangka panjang.
Semua kontrak pra-kompilasi yang baru dikembangkan harus mencakup implementasi RISC-V yang sesuai di on-chain. Langkah ini bertujuan untuk mendorong ekosistem secara bertahap beradaptasi dengan lingkungan mesin virtual RISC-V (misalnya, migrasi dari EVM ke RISC-V, solusi ini juga berlaku untuk migrasi dari EVM ke Cairo atau mesin virtual yang lebih baik lainnya):
Dukungan paralel untuk dua mesin virtual: Secara protokol, mendukung secara native dua mesin virtual RISC-V dan EVM. Pengembang dapat bebas memilih bahasa pemrograman, dan kontrak yang ditulis di berbagai mesin virtual dapat berinteraksi tanpa hambatan.
Penggantian kontrak pra-kompilasi secara bertahap: kecuali untuk operasi kurva elips dan algoritma hash KECCAK (karena permintaan kinerja yang sangat dioptimalkan), semua kontrak pra-kompilasi digantikan dengan implementasi RISC-V melalui hard fork.
Tindakan spesifik adalah: menghapus kontrak pra-kompilasi asli sekaligus mengubah kode alamat tersebut (menggunakan mode fork DAO) dari keadaan kosong menjadi implementasi RISC-V yang sesuai. Karena kesederhanaan tinggi arsitektur RISC-V, meskipun hanya menyelesaikan langkah ini, kompleksitas keseluruhan sistem tetap akan berkurang.
Penempatan interpreter EVM di blockchain: Menerapkan interpreter EVM berbasis RISC-V (alat bukti ZK telah mendorong pengembangan semacam ini) dan menyebarkannya sebagai kontrak pintar di blockchain. Setelah beberapa tahun rilis versi awal, kontrak EVM yang ada akan dieksekusi melalui interpreter ini, sehingga menyelesaikan transisi yang mulus ke mesin virtual baru.
Mencapai penyederhanaan melalui komponen protokol berbagi
Setelah langkah keempat selesai, banyak "solusi implementasi EVM" akan tetap ada dan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis data on-chain, tetapi implementasi ini tidak akan lagi menjadi bagian dari spesifikasi konsensus inti. Pada saat itu, mekanisme konsensus Ethereum akan "secara native" hanya mendukung arsitektur RISC-V.
Mewujudkan penyederhanaan melalui komponen protokol berbagi
Metode ketiga untuk mengurangi kompleksitas keseluruhan protokol (yang juga merupakan cara yang paling sering diremehkan) adalah berbagi standar yang konsisten di antara berbagai lapisan tumpukan protokol sebanyak mungkin. Umumnya, tidak perlu dan tidak menguntungkan untuk mengimplementasikan fungsi yang sama dengan protokol yang berbeda di berbagai modul, tetapi pola desain semacam itu masih umum ada, terutama karena kurangnya kolaborasi yang efektif antara bagian-bagian peta jalan protokol. Berikut adalah contoh konkret di mana penguatan penggunaan ulang komponen lintas lapisan dapat menyederhanakan Ethereum.
Solusi kode penghapusan yang dibagikan secara seragam
Tiga jenis skenario aplikasi kode penghapus:
Sampling ketersediaan data: Klien harus menggunakan kode penghapusan untuk memverifikasi apakah blok telah diterbitkan, memastikan integritas data.
Siaran P2P yang efisien: Node dapat mengkonfirmasi blok saat menerima n/2 dari n potongan, mencapai keseimbangan optimal antara pengurangan latensi dan redundansi.
Penyimpanan sejarah terdistribusi: Data sejarah Ethereum dibagi menjadi beberapa blok data, memenuhi:
Setiap blok data dapat diverifikasi secara independen
Dalam setiap grup, n/2 blok data dapat digunakan untuk memulihkan sisa n/2 blok data.
Desain ini secara signifikan mengurangi risiko kehilangan data titik tunggal.
Jika menggunakan kode penghapusan yang sama (seperti kode Reed-Solomon, kode linier acak, dll.) dalam tiga skenario berikut, akan membawa keuntungan signifikan:
Penyederhanaan kode;
Peningkatan efisiensi: Ketika node perlu mengunduh data shard (bukan blok penuh) karena suatu skenario, data tersebut dapat langsung digunakan untuk skenario lain, menghindari transmisi yang berulang;
Semua blok data di semua skenario dapat diverifikasi secara seragam melalui hash akar.
Jika menggunakan kode penghapusan yang berbeda, harus memenuhi persyaratan kompatibilitas: misalnya, dalam pengambilan sampel ketersediaan data (DAS) shard, kode Reed-Solomon horizontal dan kode linier acak vertikal dapat digunakan secara bersamaan, tetapi kedua jenis pengkodean harus dihitung berdasarkan bidang hingga yang sama.
Format serialisasi yang seragam
Format serialisasi Ethereum saat ini masih dalam keadaan semi-normatif—data dapat diserialisasi ulang ke dalam format apa pun dan disebarkan, satu-satunya pengecualian adalah hash tanda tangan transaksi, di mana skenario ini harus menggunakan format normatif untuk memastikan konsistensi hash. Namun di masa depan, tingkat normatif dari format serialisasi akan semakin diperkuat, alasan utamanya termasuk:
Abstraksi Akun (EIP-7701): Konten transaksi lengkap akan sepenuhnya terlihat oleh mesin virtual (VM)
Skenario Batas Gas Tinggi: Seiring dengan peningkatan batas Gas blok, data lapisan eksekusi perlu disimpan dalam struktur blob.
Ketika perubahan di atas terjadi, kita dapat memanfaatkan kesempatan ini untuk menyatukan standar serialisasi tiga lapisan kunci Ethereum: (i) lapisan eksekusi (ii) lapisan konsensus (iii) ABI pemanggilan kontrak pintar
Disarankan untuk menggunakan format serialisasi SSZ, SSZ memiliki keuntungan sebagai berikut:
Dekode yang efisien, termasuk skenario yang melibatkan kontrak pintar, dapat didekode dengan cepat, berkat desain berbasis 4 byte dan penanganan kondisi batas yang lebih sedikit.
Lapisan konsensus digunakan secara luas, telah terintegrasi secara mendalam pada lapisan konsensus.
Sangat mirip dengan ABI yang ada, memudahkan peningkatan dan penyesuaian alat.
Saat ini, tim teknis terkait telah mendorong pekerjaan migrasi penuh SSZ. Disarankan untuk melanjutkan jalur teknis ini dalam rencana peningkatan mendatang dan memperluas berdasarkan hasil yang ada.
Pohon struktur berbagi yang bersatu
Ketika beralih dari EVM ke RISC-V (atau arsitektur mesin virtual lainnya yang lebih sederhana), pohon Merkle Patricia enam cabang akan menjadi bottleneck kinerja terbesar dalam bukti eksekusi blok (bahkan dalam skenario biasa sekalipun). Beralih ke struktur pohon biner yang berbasis fungsi hash yang lebih baik akan secara signifikan meningkatkan efisiensi bukti dan mengurangi biaya penyimpanan data untuk node ringan dan skenario aplikasi lainnya.
Saat melaksanakan migrasi ini, struktur pohon yang sama harus digunakan untuk menyatukan lapisan konsensus dan lapisan eksekusi. Tindakan ini dapat memastikan bahwa seluruh tumpukan Ethereum (termasuk lapisan konsensus dan lapisan eksekusi) menggunakan satu set logika kode yang sama untuk akses dan analisis data.
Jalur evolusi dari keadaan saat ini ke tujuan
Kesederhanaan memiliki kesamaan dengan desentralisasi dalam banyak hal, keduanya merupakan prasyarat dasar untuk mencapai ketahanan sistem. Menetapkan kesederhanaan sebagai nilai inti memerlukan perubahan di tingkat budaya: manfaatnya seringkali sulit untuk terlihat secara instan, sementara keuntungan jangka pendek yang dihasilkan dari mengejar fungsi yang kompleks sangat jelas. Namun, seiring berjalannya waktu, keuntungan dari kesederhanaan akan semakin terlihat - perjalanan perkembangan Bitcoin adalah bukti kuat dari pandangan ini.
Saya mengusulkan untuk merancang protokol Ethereum berdasarkan pengalaman praktis proyek TinyGrad, untuk menetapkan batasan jumlah baris kode yang jelas dalam spesifikasi Ethereum jangka panjang, berusaha agar tingkat kesederhanaan kode kunci konsensus Ethereum mendekati tingkat Bitcoin. Secara spesifik, kode terkait yang menangani aturan sejarah Ethereum dapat tetap dipertahankan, tetapi harus dipisahkan secara ketat dari jalur kunci konsensus, untuk memastikan bahwa ia tidak mempengaruhi logika konsensus inti; pada saat yang sama, dalam pemilihan solusi teknis harus menerapkan filosofi desain "prioritaskan solusi yang lebih sederhana", lebih memilih untuk membungkus kompleksitas daripada menyebarkan kompleksitas sistemik, dan memastikan semua keputusan desain dapat memberikan karakteristik dan jaminan yang jelas dan dapat diverifikasi, sehingga secara keseluruhan membentuk budaya teknologi yang berorientasi pada kesederhanaan.