Ethereum bertujuan untuk menjadi buku besar global, yang memerlukan skalabilitas dan ketahanan. Artikel ini berfokus pada pentingnya kesederhanaan protokol, mengusulkan untuk secara signifikan mengurangi kompleksitas dengan menyederhanakan lapisan konsensus (3-slot finalitas, STARK agregasi) dan lapisan eksekusi (mengganti EVM dengan RISC-V atau mesin virtual serupa), mengurangi biaya pengembangan, risiko kesalahan, dan permukaan serangan. Disarankan untuk melakukan transisi yang mulus melalui strategi kompatibilitas ke belakang (seperti interpreter EVM di on-chain) 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, dengan menekankan pentingnya kesederhanaan dalam budaya dan menetapkan target jumlah baris kode maksimum.
Tujuan Ethereum adalah 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: skala dan ketahanan. Rencana hard fork Fusaka akan meningkatkan ruang yang tersedia untuk data L2 sebesar 10 kali lipat, sementara roadmap 2026 yang diusulkan saat ini juga merencanakan peningkatan besar serupa untuk lapisan L1. Sementara itu, Ethereum telah menyelesaikan transisi ke bukti kepemilikan (PoS), keragaman klien meningkat dengan cepat, penelitian verifikasi zero-knowledge (ZK) dan ketahanan kuantum juga berjalan dengan baik, ekosistem aplikasi semakin kuat.
Artikel ini bertujuan untuk fokus pada elemen ketahanan (bahkan skalabilitas) yang sama pentingnya tetapi sering dianggap remeh: kesederhanaan protokol.
Keindahan paling mengagumkan dari protokol Bitcoin terletak pada kesederhanaan yang elegan:
Ada sebuah rantai yang terdiri dari blok, di mana setiap blok terhubung dengan blok sebelumnya melalui hash.
Validitas blok diverifikasi melalui proof of work (PoW), yaitu dengan 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 siswa SMA yang cerdas dapat sepenuhnya memahami cara kerja protokol Bitcoin, dan seorang programmer bahkan dapat menulis klien sebagai proyek sampingan.
Kesederhanaan protokol memberikan banyak keuntungan kunci bagi Bitcoin (serta Ethereum) untuk menjadi lapisan dasar global yang terpercaya dan netral:
1. Mudah dipahami: Mengurangi kompleksitas protokol, memungkinkan lebih banyak orang untuk terlibat dalam penelitian, pengembangan, dan pengelolaan protokol, serta mengurangi risiko dominasi oleh elit teknis.
2. Mengurangi Biaya Pengembangan: Menyederhanakan protokol secara signifikan mengurangi biaya untuk menciptakan infrastruktur baru (seperti klien baru, pembuktian, alat pengembang, dll.).
4. Mengurangi Risiko Kesalahan: Mengurangi kemungkinan terjadinya kesalahan katastrofik dalam spesifikasi dan implementasi protokol, serta memudahkan verifikasi bahwa kesalahan semacam itu tidak ada.
5. Memperkecil Permukaan Serangan: Mengurangi komponen kompleks dalam protokol, mengurangi risiko serangan oleh kelompok kepentingan tertentu.
Sepanjang sejarah, Ethereum (kadang-kadang karena keputusan pribadi saya) sering kali gagal untuk tetap sederhana, yang mengakibatkan biaya pengembangan yang terlalu tinggi, peningkatan risiko keamanan, dan keterasingan budaya penelitian dan pengembangan, sementara manfaat dari pencarian kompleksitas ini sering terbukti ilusif. Artikel ini akan mengeksplorasi bagaimana Ethereum lima tahun ke depan dapat mendekati kesederhanaan Bitcoin.
Lapisan Konsensus Sederhana
Desain lapisan konsensus baru (dulu disebut "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:
1. Desain Final 3-slot: Menghapus konsep slot, epoch, reorganisasi 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.
2. Mengurangi Jumlah Validator Aktif: Mengizinkan penggunaan aturan pemilihan fork yang lebih sederhana untuk meningkatkan keamanan.
3. Protokol Agregasi Berbasis STARK: Siapa saja dapat menjadi agregator, tanpa perlu mempercayai agregator atau membayar biaya tinggi untuk bidang yang berulang. Kompleksitas kriptografi agregasi cukup tinggi, tetapi kompleksitasnya sangat terbungkus, sehingga risiko sistemik relatif rendah.
4. Menyederhanakan Arsitektur P2P: Faktor-faktor di atas mungkin mendukung arsitektur jaringan peer-to-peer yang lebih sederhana dan lebih kuat.
5. Mendesain ulang mekanisme validator: termasuk mekanisme masuk, keluar, penarikan, konversi kunci, kebocoran ketidakaktifan, dll., menyederhanakan jumlah baris kode dan memberikan jaminan yang lebih jelas (seperti periode subyektivitas yang lemah).
Keuntungan dari lapisan konsensus adalah relatif mandirinya dari lapisan eksekusi EVM, sehingga memiliki ruang yang lebih 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 kompleksitas tersebut terbukti tidak perlu (sebagian karena kesalahan keputusan pribadi saya): mesin virtual 256-bit terlalu mengoptimalkan bentuk kriptografi tertentu yang kini sudah mulai usang, prekompilasi (precompiles) dioptimalkan untuk satu kasus penggunaan tetapi jarang digunakan.
Mengatasi masalah ini satu per satu memiliki efek yang terbatas. Misalnya, menghapus opcode SELFDESTRUCT memerlukan usaha yang besar, namun hanya memberikan keuntungan kecil. Perdebatan terbaru mengenai EOF (EVM Object Format) juga menunjukkan tantangan serupa.
Saya baru-baru ini mengajukan rencana yang lebih radikal: alih-alih melakukan perubahan berskala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan 1,5 kali keuntungan, lebih baik beralih ke mesin virtual yang lebih baik dan lebih sederhana untuk mencapai keuntungan 100 kali. Mirip dengan "The Merge", kami mengurangi jumlah perubahan yang merusak, tetapi membuat setiap perubahan lebih bermakna. Secara khusus, saya menyarankan untuk mengganti EVM dengan RISC-V, atau mesin virtual lain yang digunakan oleh pembuktian ZK Ethereum. Ini akan membawa:
1. Peningkatan Efisiensi yang Signifikan: Eksekusi kontrak pintar (dalam pembuktian) tidak memerlukan biaya interpreter, berjalan secara langsung. Data dari Succinct menunjukkan bahwa dalam banyak skenario kinerja dapat ditingkatkan lebih dari 100 kali lipat.
2. Peningkatan Kesederhanaan yang Signifikan: Spesifikasi RISC-V jauh lebih sederhana dibandingkan EVM, dan alternatifnya (seperti Cairo) juga sama sederhana.
3. Motivasi untuk mendukung EOF: seperti pemisahan kode, analisis statis yang lebih ramah, batas ukuran kode yang lebih besar, dll.
4. Lebih Banyak Pilihan Pengembang: Solidity dan Vyper dapat menambahkan backend untuk dikompilasi ke mesin virtual baru. Jika memilih RISC-V, pengembang bahasa mainstream juga dapat dengan mudah memindahkan kode ke mesin virtual tersebut.
5. Menghapus sebagian besar pra-kompilasi: Mungkin hanya mempertahankan operasi kurva elips yang sangat dioptimalkan (setelah komputer kuantum menjadi umum, bahkan ini juga akan menghilang).
Kekurangan utama adalah, berbeda dengan EOF yang sudah siap, keuntungan dari mesin virtual baru memerlukan waktu yang lebih lama untuk memberikan manfaat kepada pengembang. Kita dapat mengatasi masalah ini dengan menerapkan peningkatan 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 utama adalah: bagaimana menangani EVM yang ada?
Kebijakan Kompatibilitas Mundur untuk Transisi Mesin Virtual
Tantangan terbesar dalam menyederhanakan (atau memperbaiki tanpa menambah kompleksitas) EVM adalah bagaimana menyeimbangkan pencapaian tujuan dengan kompatibilitas mundur aplikasi yang ada.
Pertama-tama perlu ditegaskan: repositori kode Ethereum (bahkan dalam klien tunggal) tidak memiliki satu cara definisi saja.
Tujuannya adalah untuk memperkecil area hijau: logika yang diperlukan untuk node berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, pembuktian, 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, prekompilasi, dll.), klien yang memproses blok sejarah masih perlu 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 pembangunan blok, tetapi tidak termasuk dalam logika konsensus. Misalnya, Etherscan dan beberapa pembangun blok mendukung operasi pengguna ERC-4337. Jika kita mengganti beberapa fungsi Ethereum (seperti EOA dan jenis transaksi lama yang didukung) dengan implementasi RISC-V di atas rantai, 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 menimbulkan risiko konsensus. Oleh karena itu, kompleksitas kode di area oranye dan kuning jauh lebih kecil bahayanya dibandingkan dengan kompleksitas area hijau.
Gagasan untuk memindahkan kode dari area hijau ke area kuning mirip dengan strategi Apple yang memastikan kompatibilitas jangka panjang melalui lapisan penerjemah 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 diterapkan untuk EVM ke Cairo atau RISC-V ke mesin virtual yang lebih baik):
1. Meminta pra-kompilasi baru untuk menyediakan implementasi RISC-V di blockchain: Membiarkan ekosistem secara bertahap beradaptasi dengan mesin virtual RISC-V.
2. Memperkenalkan RISC-V sebagai opsi pengembang: Protokol mendukung RISC-V dan EVM, kontrak dari kedua mesin virtual dapat berinteraksi secara bebas.
3. Mengganti sebagian besar pra-kompilasi: Kecuali operasi kurva elips dan KECCAK (karena membutuhkan kecepatan ekstrem), menggantikan pra-kompilasi lainnya dengan RISC-V. Menghapus pra-kompilasi 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, akan menyederhanakan protokol secara signifikan.
4. Mengimplementasikan interpreter EVM dalam RISC-V: Sebagai kontrak pintar yang diunggah ke blockchain (karena pembuktian ZK diperlukan). Setelah beberapa tahun rilis awal, kontrak EVM yang ada dijalankan melalui interpreter ini.
Setelah menyelesaikan langkah 4, banyak "implementasi EVM" masih akan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis rantai, tetapi tidak lagi menjadi bagian dari spesifikasi 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 seragam di berbagai bagian tumpukan protokol sebanyak mungkin. Protokol yang berbeda melakukan hal yang sama dalam skenario yang berbeda biasanya tidak ada manfaatnya, tetapi pola ini tetap sering muncul, terutama karena berbagai bagian dari peta jalan protokol kurang berkomunikasi. Berikut adalah beberapa contoh konkret yang menyederhanakan Ethereum melalui berbagi komponen.
Kode Koreksi yang Seragam
Kami membutuhkan kode penghapusan dan penyisipan dalam tiga skenario:
1. Sampling Ketersediaan Data: Klien memverifikasi bahwa blok telah diterbitkan.
2. Penyiaran P2P yang lebih cepat: Node dapat menerima blok setelah menerima n/2 segmen, mencapai keseimbangan antara latensi dan redundansi.
3. Penyimpanan Sejarah Terdistribusi: Data sejarah Ethereum disimpan dalam potongan, setiap kelompok n/2 potongan dapat memulihkan potongan yang tersisa, mengurangi risiko kehilangan potongan tunggal.
Jika menggunakan kode penghapusan yang sama (apakah itu Reed-Solomon, kode linier acak, dll.) dalam tiga skenario, Anda akan mendapatkan keuntungan berikut:
1. Minimalkan Jumlah Kode: Mengurangi jumlah total baris kode.
2. Meningkatkan efisiensi: Jika node mengunduh sebagian segmen untuk suatu skenario, data tersebut dapat digunakan untuk skenario lainnya.
3. Pastikan Verifiabilitas: Semua potongan dari skenario dapat diverifikasi berdasarkan akar.
Jika menggunakan kode penghapusan yang berbeda, setidaknya harus memastikan kompatibilitas, misalnya kode Reed-Solomon untuk pengambilan data yang tersedia pada tingkat yang beroperasi di domain yang sama dengan kode linier acak vertikal.
Format Serialisasi Terpadu
Format serialisasi Ethereum saat ini hanya sebagian terstandardisasi, karena data dapat diserialisasi dan disiarkan kembali dalam format apa pun. Pengecualian adalah hash tanda tangan transaksi, yang memerlukan format yang terstandarisasi untuk hashing. Di masa depan, tingkat standarisasi format serialisasi akan meningkat lebih lanjut karena alasan berikut:
1. Abstraksi Akun Penuh (EIP-7701): Konten lengkap transaksi terlihat oleh mesin virtual.
2. Batas Gas yang Lebih Tinggi: Data lapisan eksekusi perlu dimasukkan ke dalam blok data (blobs).
Saat itu, kita memiliki kesempatan untuk menyatukan format serialisasi tiga tingkat Ethereum: lapisan eksekusi, lapisan konsensus, dan ABI pemanggilan kontrak pintar.
Saya mengusulkan untuk menggunakan SSZ, karena SSZ:
Mudah untuk didekode: termasuk dalam kontrak pintar (karena desain berbasis 4 byte dan sedikit kasus tepi).
Telah digunakan secara luas di lapisan konsensus.
Sangat mirip dengan ABI yang ada: Penyesuaian alat relatif mudah.
Sudah ada upaya untuk migrasi penuh ke SSZ, kita harus mempertimbangkan dan melanjutkan upaya ini saat merencanakan peningkatan di masa depan.
Struktur Pohon yang Terpadu
Jika beralih dari EVM ke RISC-V (atau mesin virtual minimal lainnya yang dapat dipilih), pohon Merkle Patricia heksadesimal akan menjadi hambatan terbesar dalam membuktikan eksekusi blok, bahkan dalam kasus rata-rata. Beralih ke pohon biner yang didasarkan pada 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 diakses dan dianalisis melalui kode yang sama.
Dari Sekarang Hingga Masa Depan
Kesederhanaan dalam banyak hal mirip dengan desentralisasi, keduanya merupakan tujuan ketahanan yang hulu. Menekankan kesederhanaan dengan jelas memerlukan perubahan budaya tertentu. Manfaatnya seringkali sulit untuk diukur, sementara upaya tambahan dan biaya melepaskan beberapa fitur yang mencolok terlihat segera. Namun, seiring berjalannya 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 norma jangka panjang Ethereum, agar kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin. Kode yang menangani aturan sejarah Ethereum akan terus ada, tetapi harus ditempatkan di luar jalur kunci konsensus. Pada saat yang sama, kita harus memegang prinsip memilih solusi yang lebih sederhana, dengan prioritas memilih yang membungkus 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
Ringkasan
Ethereum bertujuan untuk menjadi buku besar global, yang memerlukan skalabilitas dan ketahanan. Artikel ini berfokus pada pentingnya kesederhanaan protokol, mengusulkan untuk secara signifikan mengurangi kompleksitas dengan menyederhanakan lapisan konsensus (3-slot finalitas, STARK agregasi) dan lapisan eksekusi (mengganti EVM dengan RISC-V atau mesin virtual serupa), mengurangi biaya pengembangan, risiko kesalahan, dan permukaan serangan. Disarankan untuk melakukan transisi yang mulus melalui strategi kompatibilitas ke belakang (seperti interpreter EVM di on-chain) 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, dengan menekankan pentingnya kesederhanaan dalam budaya dan menetapkan target jumlah baris kode maksimum.
Tujuan Ethereum adalah 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: skala dan ketahanan. Rencana hard fork Fusaka akan meningkatkan ruang yang tersedia untuk data L2 sebesar 10 kali lipat, sementara roadmap 2026 yang diusulkan saat ini juga merencanakan peningkatan besar serupa untuk lapisan L1. Sementara itu, Ethereum telah menyelesaikan transisi ke bukti kepemilikan (PoS), keragaman klien meningkat dengan cepat, penelitian verifikasi zero-knowledge (ZK) dan ketahanan kuantum juga berjalan dengan baik, ekosistem aplikasi semakin kuat.
Artikel ini bertujuan untuk fokus pada elemen ketahanan (bahkan skalabilitas) yang sama pentingnya tetapi sering dianggap remeh: kesederhanaan protokol.
Keindahan paling mengagumkan dari protokol Bitcoin terletak pada kesederhanaan yang elegan:
Ada sebuah rantai yang terdiri dari blok, di mana setiap blok terhubung dengan blok sebelumnya melalui hash.
Validitas blok diverifikasi melalui proof of work (PoW), yaitu dengan 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 siswa SMA yang cerdas dapat sepenuhnya memahami cara kerja protokol Bitcoin, dan seorang programmer bahkan dapat menulis klien sebagai proyek sampingan.
Kesederhanaan protokol memberikan banyak keuntungan kunci bagi Bitcoin (serta Ethereum) untuk menjadi lapisan dasar global yang terpercaya dan netral:
1. Mudah dipahami: Mengurangi kompleksitas protokol, memungkinkan lebih banyak orang untuk terlibat dalam penelitian, pengembangan, dan pengelolaan protokol, serta mengurangi risiko dominasi oleh elit teknis.
2. Mengurangi Biaya Pengembangan: Menyederhanakan protokol secara signifikan mengurangi biaya untuk menciptakan infrastruktur baru (seperti klien baru, pembuktian, alat pengembang, dll.).
3. Mengurangi beban pemeliharaan: Mengurangi biaya pemeliharaan perjanjian jangka panjang.
4. Mengurangi Risiko Kesalahan: Mengurangi kemungkinan terjadinya kesalahan katastrofik dalam spesifikasi dan implementasi protokol, serta memudahkan verifikasi bahwa kesalahan semacam itu tidak ada.
5. Memperkecil Permukaan Serangan: Mengurangi komponen kompleks dalam protokol, mengurangi risiko serangan oleh kelompok kepentingan tertentu.
Sepanjang sejarah, Ethereum (kadang-kadang karena keputusan pribadi saya) sering kali gagal untuk tetap sederhana, yang mengakibatkan biaya pengembangan yang terlalu tinggi, peningkatan risiko keamanan, dan keterasingan budaya penelitian dan pengembangan, sementara manfaat dari pencarian kompleksitas ini sering terbukti ilusif. Artikel ini akan mengeksplorasi bagaimana Ethereum lima tahun ke depan dapat mendekati kesederhanaan Bitcoin.
Lapisan Konsensus Sederhana
Desain lapisan konsensus baru (dulu disebut "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:
1. Desain Final 3-slot: Menghapus konsep slot, epoch, reorganisasi 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.
2. Mengurangi Jumlah Validator Aktif: Mengizinkan penggunaan aturan pemilihan fork yang lebih sederhana untuk meningkatkan keamanan.
3. Protokol Agregasi Berbasis STARK: Siapa saja dapat menjadi agregator, tanpa perlu mempercayai agregator atau membayar biaya tinggi untuk bidang yang berulang. Kompleksitas kriptografi agregasi cukup tinggi, tetapi kompleksitasnya sangat terbungkus, sehingga risiko sistemik relatif rendah.
4. Menyederhanakan Arsitektur P2P: Faktor-faktor di atas mungkin mendukung arsitektur jaringan peer-to-peer yang lebih sederhana dan lebih kuat.
5. Mendesain ulang mekanisme validator: termasuk mekanisme masuk, keluar, penarikan, konversi kunci, kebocoran ketidakaktifan, dll., menyederhanakan jumlah baris kode dan memberikan jaminan yang lebih jelas (seperti periode subyektivitas yang lemah).
Keuntungan dari lapisan konsensus adalah relatif mandirinya dari lapisan eksekusi EVM, sehingga memiliki ruang yang lebih 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 kompleksitas tersebut terbukti tidak perlu (sebagian karena kesalahan keputusan pribadi saya): mesin virtual 256-bit terlalu mengoptimalkan bentuk kriptografi tertentu yang kini sudah mulai usang, prekompilasi (precompiles) dioptimalkan untuk satu kasus penggunaan tetapi jarang digunakan.
Mengatasi masalah ini satu per satu memiliki efek yang terbatas. Misalnya, menghapus opcode SELFDESTRUCT memerlukan usaha yang besar, namun hanya memberikan keuntungan kecil. Perdebatan terbaru mengenai EOF (EVM Object Format) juga menunjukkan tantangan serupa.
Saya baru-baru ini mengajukan rencana yang lebih radikal: alih-alih melakukan perubahan berskala menengah (tetapi tetap merusak) pada EVM untuk mendapatkan 1,5 kali keuntungan, lebih baik beralih ke mesin virtual yang lebih baik dan lebih sederhana untuk mencapai keuntungan 100 kali. Mirip dengan "The Merge", kami mengurangi jumlah perubahan yang merusak, tetapi membuat setiap perubahan lebih bermakna. Secara khusus, saya menyarankan untuk mengganti EVM dengan RISC-V, atau mesin virtual lain yang digunakan oleh pembuktian ZK Ethereum. Ini akan membawa:
1. Peningkatan Efisiensi yang Signifikan: Eksekusi kontrak pintar (dalam pembuktian) tidak memerlukan biaya interpreter, berjalan secara langsung. Data dari Succinct menunjukkan bahwa dalam banyak skenario kinerja dapat ditingkatkan lebih dari 100 kali lipat.
2. Peningkatan Kesederhanaan yang Signifikan: Spesifikasi RISC-V jauh lebih sederhana dibandingkan EVM, dan alternatifnya (seperti Cairo) juga sama sederhana.
3. Motivasi untuk mendukung EOF: seperti pemisahan kode, analisis statis yang lebih ramah, batas ukuran kode yang lebih besar, dll.
4. Lebih Banyak Pilihan Pengembang: Solidity dan Vyper dapat menambahkan backend untuk dikompilasi ke mesin virtual baru. Jika memilih RISC-V, pengembang bahasa mainstream juga dapat dengan mudah memindahkan kode ke mesin virtual tersebut.
5. Menghapus sebagian besar pra-kompilasi: Mungkin hanya mempertahankan operasi kurva elips yang sangat dioptimalkan (setelah komputer kuantum menjadi umum, bahkan ini juga akan menghilang).
Kekurangan utama adalah, berbeda dengan EOF yang sudah siap, keuntungan dari mesin virtual baru memerlukan waktu yang lebih lama untuk memberikan manfaat kepada pengembang. Kita dapat mengatasi masalah ini dengan menerapkan peningkatan 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 utama adalah: bagaimana menangani EVM yang ada?
Kebijakan Kompatibilitas Mundur untuk Transisi Mesin Virtual
Tantangan terbesar dalam menyederhanakan (atau memperbaiki tanpa menambah kompleksitas) EVM adalah bagaimana menyeimbangkan pencapaian tujuan dengan kompatibilitas mundur aplikasi yang ada.
Pertama-tama perlu ditegaskan: repositori kode Ethereum (bahkan dalam klien tunggal) tidak memiliki satu cara definisi saja.
Tujuannya adalah untuk memperkecil area hijau: logika yang diperlukan untuk node berpartisipasi dalam konsensus Ethereum, termasuk menghitung status saat ini, pembuktian, 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, prekompilasi, dll.), klien yang memproses blok sejarah masih perlu 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 pembangunan blok, tetapi tidak termasuk dalam logika konsensus. Misalnya, Etherscan dan beberapa pembangun blok mendukung operasi pengguna ERC-4337. Jika kita mengganti beberapa fungsi Ethereum (seperti EOA dan jenis transaksi lama yang didukung) dengan implementasi RISC-V di atas rantai, 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 menimbulkan risiko konsensus. Oleh karena itu, kompleksitas kode di area oranye dan kuning jauh lebih kecil bahayanya dibandingkan dengan kompleksitas area hijau.
Gagasan untuk memindahkan kode dari area hijau ke area kuning mirip dengan strategi Apple yang memastikan kompatibilitas jangka panjang melalui lapisan penerjemah 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 diterapkan untuk EVM ke Cairo atau RISC-V ke mesin virtual yang lebih baik):
1. Meminta pra-kompilasi baru untuk menyediakan implementasi RISC-V di blockchain: Membiarkan ekosistem secara bertahap beradaptasi dengan mesin virtual RISC-V.
2. Memperkenalkan RISC-V sebagai opsi pengembang: Protokol mendukung RISC-V dan EVM, kontrak dari kedua mesin virtual dapat berinteraksi secara bebas.
3. Mengganti sebagian besar pra-kompilasi: Kecuali operasi kurva elips dan KECCAK (karena membutuhkan kecepatan ekstrem), menggantikan pra-kompilasi lainnya dengan RISC-V. Menghapus pra-kompilasi 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, akan menyederhanakan protokol secara signifikan.
4. Mengimplementasikan interpreter EVM dalam RISC-V: Sebagai kontrak pintar yang diunggah ke blockchain (karena pembuktian ZK diperlukan). Setelah beberapa tahun rilis awal, kontrak EVM yang ada dijalankan melalui interpreter ini.
Setelah menyelesaikan langkah 4, banyak "implementasi EVM" masih akan digunakan untuk mengoptimalkan pembangunan blok, alat pengembang, dan analisis rantai, tetapi tidak lagi menjadi bagian dari spesifikasi 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 seragam di berbagai bagian tumpukan protokol sebanyak mungkin. Protokol yang berbeda melakukan hal yang sama dalam skenario yang berbeda biasanya tidak ada manfaatnya, tetapi pola ini tetap sering muncul, terutama karena berbagai bagian dari peta jalan protokol kurang berkomunikasi. Berikut adalah beberapa contoh konkret yang menyederhanakan Ethereum melalui berbagi komponen.
Kode Koreksi yang Seragam
Kami membutuhkan kode penghapusan dan penyisipan dalam tiga skenario:
1. Sampling Ketersediaan Data: Klien memverifikasi bahwa blok telah diterbitkan.
2. Penyiaran P2P yang lebih cepat: Node dapat menerima blok setelah menerima n/2 segmen, mencapai keseimbangan antara latensi dan redundansi.
3. Penyimpanan Sejarah Terdistribusi: Data sejarah Ethereum disimpan dalam potongan, setiap kelompok n/2 potongan dapat memulihkan potongan yang tersisa, mengurangi risiko kehilangan potongan tunggal.
Jika menggunakan kode penghapusan yang sama (apakah itu Reed-Solomon, kode linier acak, dll.) dalam tiga skenario, Anda akan mendapatkan keuntungan berikut:
1. Minimalkan Jumlah Kode: Mengurangi jumlah total baris kode.
2. Meningkatkan efisiensi: Jika node mengunduh sebagian segmen untuk suatu skenario, data tersebut dapat digunakan untuk skenario lainnya.
3. Pastikan Verifiabilitas: Semua potongan dari skenario dapat diverifikasi berdasarkan akar.
Jika menggunakan kode penghapusan yang berbeda, setidaknya harus memastikan kompatibilitas, misalnya kode Reed-Solomon untuk pengambilan data yang tersedia pada tingkat yang beroperasi di domain yang sama dengan kode linier acak vertikal.
Format Serialisasi Terpadu
Format serialisasi Ethereum saat ini hanya sebagian terstandardisasi, karena data dapat diserialisasi dan disiarkan kembali dalam format apa pun. Pengecualian adalah hash tanda tangan transaksi, yang memerlukan format yang terstandarisasi untuk hashing. Di masa depan, tingkat standarisasi format serialisasi akan meningkat lebih lanjut karena alasan berikut:
1. Abstraksi Akun Penuh (EIP-7701): Konten lengkap transaksi terlihat oleh mesin virtual.
2. Batas Gas yang Lebih Tinggi: Data lapisan eksekusi perlu dimasukkan ke dalam blok data (blobs).
Saat itu, kita memiliki kesempatan untuk menyatukan format serialisasi tiga tingkat Ethereum: lapisan eksekusi, lapisan konsensus, dan ABI pemanggilan kontrak pintar.
Saya mengusulkan untuk menggunakan SSZ, karena SSZ:
Mudah untuk didekode: termasuk dalam kontrak pintar (karena desain berbasis 4 byte dan sedikit kasus tepi).
Telah digunakan secara luas di lapisan konsensus.
Sangat mirip dengan ABI yang ada: Penyesuaian alat relatif mudah.
Sudah ada upaya untuk migrasi penuh ke SSZ, kita harus mempertimbangkan dan melanjutkan upaya ini saat merencanakan peningkatan di masa depan.
Struktur Pohon yang Terpadu
Jika beralih dari EVM ke RISC-V (atau mesin virtual minimal lainnya yang dapat dipilih), pohon Merkle Patricia heksadesimal akan menjadi hambatan terbesar dalam membuktikan eksekusi blok, bahkan dalam kasus rata-rata. Beralih ke pohon biner yang didasarkan pada 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 diakses dan dianalisis melalui kode yang sama.
Dari Sekarang Hingga Masa Depan
Kesederhanaan dalam banyak hal mirip dengan desentralisasi, keduanya merupakan tujuan ketahanan yang hulu. Menekankan kesederhanaan dengan jelas memerlukan perubahan budaya tertentu. Manfaatnya seringkali sulit untuk diukur, sementara upaya tambahan dan biaya melepaskan beberapa fitur yang mencolok terlihat segera. Namun, seiring berjalannya 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 norma jangka panjang Ethereum, agar kode kunci konsensus Ethereum mendekati kesederhanaan Bitcoin. Kode yang menangani aturan sejarah Ethereum akan terus ada, tetapi harus ditempatkan di luar jalur kunci konsensus. Pada saat yang sama, kita harus memegang prinsip memilih solusi yang lebih sederhana, dengan prioritas memilih yang membungkus kompleksitas daripada kompleksitas sistemik, dan membuat pilihan desain yang memberikan atribut dan jaminan yang jelas.