Pengantar

Pada tahun 2024, banyak peristiwa signifikan terjadi di sekitar Ethereum. Awal tahun, Ethereum memperkenalkan blob melalui upgrade Dencun. Pembaruan ini secara dramatis mengurangi biaya transaksi untuk rollup yang ada, membentuk dasar untuk ekspansi cepat dari ekosistem rollup.

(Pengurangan biaya di OP Chains setelah peningkatan Dencun | Sumber:Optimisme X)

Namun, seiring dengan migrasi dapps dalam ekosistem ke rollups yang sangat scalable dan jaringan Layer 1 (L1) alternatif, aktivitas pengguna di Ethereum sendiri mulai menurun. Selain itu, ketika rollups berhenti mengirimkan biaya tinggi ke Ethereum, keprihatinan mulai muncul di dalam komunitas.

Selain itu, tahun 2024 merupakan tahun di mana L1 yang berfokus pada skalabilitas seperti Solana dan Sui menunjukkan kekuatan yang signifikan. TPS (transaksi per detik) yang luar biasa yang dihasilkan oleh jaringan-jaringan ini membuat aktivitas di rollups terlihat relatif kecil.

Dalam konteks ini, muncul kritik, seperti “rencana jalan Ethereum yang berpusat pada rollup adalah cacat” atau “pengembangan Ethereum terlalu lambat untuk berhasil.” Apakah Ethereum benar-benar berada di jalan yang benar? Bagaimana Ethereum akan terlihat pada tahun 2025 atau bahkan 2030?

Seri ini membahas bagian dari jalan peta Ethereum di bawah dua topik utama, menganalisis masa depannya berdasarkan detail teknis. Topik pertama adalah Beam Chain.

Apa itu proposal Beam Chain, dan mengapa ini penting?

Jika seseorang harus memilih topik yang paling banyak dibicarakan dalam komunitas Ethereum tahun ini, kemungkinan besar itu adalah pengumuman oleh peneliti Ethereum, Justin Drake, tentang Beam Chain di Devcon. Pengumuman ini menarik minat yang besar dan tentu saja menimbulkan banyak kegaduhan. Mari kita analisis apa arti proposal ini.

Ide inti dari proposal Beam Chain adalah untuk mendesain ulang lapisan konsensus Ethereum secara menyeluruh. Justin Drake menyampaikan tiga alasan berikut mengapa lapisan konsensus saat ini, Beacon Chain, perlu didesain ulang:

• Memahami MEV dengan lebih baik melalui pengalaman masa lalu
• Kemajuan pesat dalam teknologi SNARK (misalnya, pengembangan zkVM berlangsung dengan kecepatan yang mengagumkan, lebih dari 10 kali lebih cepat)
• Menghilangkan "utang teknis" yang ada dalam Beacon Chain

Saat ini, peta jalan lapisan konsensus Ethereum mencakup elemen-elemen berikut:

Diantara ini, keempat area yang ditandai tebal mewakili perubahan yang mendasar yang melampaui sekedar modifikasi pada Beacon Chain. Misalnya, chain snarkification mengacu pada mengubah penanganan keadaan lapisan konsensus menjadi teknologi ZK, membutuhkan perubahan mendasar mulai dari fungsi hash hingga metode merkleizing/serializing state.

Selain itu, slot yang lebih cepat dan finalitas yang lebih cepat adalah desain baru yang diusulkan untuk mencapai peningkatan kinerja sambil menjaga keamanan—faktor yang tidak diprioritaskan dalam desain awal. Mengimplementasikan ini memerlukan perubahan yang luas di lapisan konsensus.

Beam Chain mengusulkan untuk mencapai perubahan ini melalui hard fork tunggal. Untuk merangkum:

1. Mengimplementasikan peta jalan untuk lapisan konsensus Ethereum memerlukan desain ulang lengkap dari lapisan konsensus.
2. Untuk tujuan ini, perubahan besar pada peta jalan akan dikemas dalam hard fork bernama Beam Chain.
3. Ini termasuk empat elemen: waktu blok yang lebih cepat, finalitas yang lebih cepat, snarkifikasi rantai, dan ketahanan kuantum.

Selanjutnya, mari kita jelajahi bagaimana masing-masing dari ini diimplementasikan dan dampak teknis yang menyertainya.

Rincian teknis desain Beam Chain

Slot yang lebih cepat & finalitas yang lebih cepat

Saat ini, waktu slot Ethereum adalah 12 detik, dan dibutuhkan 2-3 epoch (sekitar 15 menit) bagi blok yang terhubung ke slot untuk mencapai finalitas. Memperbaiki waktu ini akan berdampak positif bagi pengguna Ethereum, aplikasi, dan rollups yang dibangun di Ethereum.

Finalitas lebih pendek (Orbit SSF)

Topik ini, dikenal di kalangan peneliti Ethereum sebagai SSF (Single Slot Finality), bertujuan untuk mengurangi waktu blok Ethereum mencapai finalitas dari sekitar 15 menit menjadi dalam waktu 12 detik, memberikan pengguna konfirmasi yang lebih cepat. Untuk memahami finalitas slot tunggal, kita harus memahami algoritma konsensus saat ini Ethereum, Gasper.

Prinsip desain utama dari Gasper adalah memastikan bahwa blok yang diusulkan dalam satu slot mencapai tingkat keamanan ekonomi tertentu setelah waktu tertentu sambil meminimalkan beban komunikasi pada setiap validator. Untuk mencapai hal ini, Ethereum membagi seluruh set validator ke dalam komite yang tersebar di 32 slot. Setiap slot dapat berisi hingga 64 komite, dan tujuannya adalah untuk menyusun setiap komite terdiri dari 128 validator (meskipun jumlah ini dapat meningkat jika jumlah total validator aktif melebihi ini).

Validator di setiap komite secara independen memverifikasi blok dan memberikan suara menggunakan tanda tangan BLS. Mekanisme tanda tangan BLS memungkinkan beberapa tanda tangan digabungkan menjadi satu, artinya node yang ditunjuk dalam komite mengumpulkan tanda tangan ini dan menggabungkannya menjadi satu paket data yang kompak. Dengan menyebarkan tanda tangan yang telah digabungkan ini, penawar blok berikutnya dapat mengkonfirmasi dengan data minimal bahwa blok telah diverifikasi dengan benar.

(Aggregasi tanda tangan BLS antara validator Ethereum | Sumber: eth2book)

Secara ringkas, Gasper Ethereum mencapai skalabilitas dan keamanan ekonomi melalui mekanisme berikut:

• Validator didistribusikan di seluruh slot dalam komite selama periode 6.4 menit, menghilangkan kebutuhan komunikasi langsung di antara semua validator.
• Proses tanda tangan terkumpul memastikan bahwa suara validator pada blok dapat diverifikasi menggunakan sejumlah kecil data.

Namun, masalah muncul karena Gasper beroperasi berdasarkan epoch, dan 'konektivitas' antara epoch harus diverifikasi sebelum slot dapat mencapai kepastian. Dalam Gasper, setidaknya dua epoch (64 slot) harus berlalu sebelum mencapai kepastian yang setara dengan keamanan ekonomi Ethereum yang lengkap.

Hal ini menghasilkan representasi diagramatis berikut:

(Economic Finality at Gasper | Source:Orbit SSF)

Ini memperkenalkan berbagai tantangan dan mengurangi pengalaman pengguna. Misalnya:

• Ketika menarik dana dari CEX (pertukaran terpusat) ke Ethereum, atau sebaliknya, periode konfirmasi mungkin sekitar 10 menit, yang cukup berlebihan.
• Rollups Ethereum dan dApps menghadapi risiko bahwa blok L1 yang merekaandalkan mungkin tidak difinalisasi dan dapat menjadi tidak valid. Jika tindakan pencegahan yang tepat tidak diimplementasikan, ini dapat menyebabkan masalah.

Sebagai contoh, pada bulan Maret 2024, Polygon zkEVM mengalami penundaan rantai selama lebih dari dua hari akibat penanganan reorg Ethereum yang tidak tepat.

Mengurangi waktu finalitas bukanlah hal yang tidak mungkin, seperti yang ditunjukkan oleh algoritma konsensus seperti Tendermint, yang sudah diterapkan dalam beberapa protokol. Namun, tantangannya dalam mengadopsi mekanisme Tendermint terletak pada komunikasi P2P yang sering terjadi di antara node, yang menghadirkan keterbatasan skalabilitas.

Dalam Tendermint, jika jumlah node adalah N, kompleksitas pesannya adalah O(N^3). Ini berarti bahwa seiring dengan peningkatan jumlah node, frekuensi komunikasi di antara mereka tumbuh secara eksponensial, membatasi skalabilitas. Oleh karena itu, protokol seperti Ethereum, dengan banyak validator, tidak dapat langsung mengadopsi Tendermint seperti adanya.

Perlu dilakukan pekerjaan tambahan untuk mengatasi masalah ini agar bisa menerapkan konsensus ala Tendermint ke Ethereum.

Sebuah tinjauan tentang proposal Orbit SSF

Orbit SSF bertujuan untuk memodifikasi mekanisme komite Gasper untuk mengurangi waktu finalitas slot sambil mempertahankan keamanan ekonomi yang tinggi.

Usulan ini adalah untuk mengurangi ukuran epoch dari 32 slot menjadi satu slot (~12 detik). Namun, seperti yang disebutkan sebelumnya, ini akan meningkatkan penggunaan sumber daya untuk komunikasi validator, yang akan berdampak negatif pada desentralisasi Ethereum.

Untuk mengatasi ini, Orbit SSF mengusulkan ide-ide berikut:

Meningkatkan jumlah staking maksimum untuk setiap validator Ethereum dapat mencapai tingkat keamanan ekonomi yang sama dengan jumlah validator yang lebih sedikit.

Daripada memiliki beberapa komite per slot, Orbit SSF menyarankan untuk memperkenalkan satu 'super komite'. Validator dengan jumlah staking yang lebih tinggi hampir selalu akan dimasukkan secara proporsional dalam komite, memastikan bahwa tingkat keamanan ekonomi yang sama tetap dipertahankan meskipun dengan jumlah komite yang lebih sedikit.

Peningkatan Ethereum berikutnya, Pectra, termasuk EIP-7251, yang mengusulkan peningkatan jumlah staking maksimum (MaxEB) untuk validator dari 32 ETH menjadi 2048 ETH. Meskipun usulan ini menarik bagi operator infrastruktur node Ethereum, ini juga merupakan prasyarat untuk Orbit SSF.

Namun, jika validator dengan jumlah staking besar hampir selalu termasuk dalam komite, validator solo yang lebih kecil mungkin mengalami pengurangan reward, yang berpotensi merugikan desentralisasi Ethereum. Untuk mencegah hal ini, Orbit SSF menyesuaikan reward agar APR meningkat secara linear dengan jumlah staking sambil memastikan validator yang lebih besar lebih sering dimasukkan dalam komite.

(Hadiah dan Probabilitas untuk dimasukkan dalam komite di Orbit SSF | Sumber:Orbit SSF)

Selain itu, Orbit SSF bergerak menuju 'finalitas berbasis komite.' Dalam Gasper, komite hanya dapat berkontribusi pada finalitas setelah dua atau lebih epoch berlalu, tetapi Orbit SSF memungkinkan setiap komite yang ditugaskan slot untuk berkontribusi pada finalitas secara real-time. Tujuannya adalah membuat komite menjadi kontributor aktif pada finalitas dan mencapai skalabilitas lebih cepat.

(Finality in Orbit SSF menggunakan Cap-and-slow-rotate | Sumber:Orbit SSF)

Kuncinya di sini terletak pada komposisi anggota komite. Orbit SSF mengusulkan mekanisme "rotasi lambat" di mana validator pasak besar secara matematis hampir tetap di dalam komite sementara validator yang lebih kecil diputar masuk dan keluar. Hal ini memungkinkan nilai F, yang mewakili ambang keamanan ekonomi, ditetapkan sangat tinggi sambil mempertahankan overhead komunikasi minimal di antara validator dan memastikan waktu finalitas tetap rendah.

Sebagai contoh, menetapkan n = 3 dan F yang cukup besar akan memungkinkan Ethereum mencapai finalitas dalam sekitar tiga slot, sehingga mewujudkan visi Justin Drake tentang FFG 3-slot.

Namun, meningkatkan F ke tingkat seluruh kumpulan validator Ethereum tidaklah mudah. Hal ini dapat mengurangi biaya pelaksanaan serangan 51% terhadap Ethereum. Oleh karena itu, tantangan utama bagi Orbit SSF ke depan adalah menentukan bagaimana meningkatkan F secara teknis untuk memastikan keamanan Ethereum tetap kokoh tanpa mengorbankan dekonsentrasi yang banyak.

Waktu slot yang lebih singkat (slot 4 detik)Meskipun SSF (atau finalitas 3 slot) tercapai, pengguna Ethereum masih akan mengalami waktu konfirmasi transaksi minimum 12 detik. Hal ini mengakibatkan dua kekurangan utama bagi pengguna:

1. Latensi yang panjang dibandingkan dengan L1 lain seperti Solana dan Sui
2. Ranah yang lebih rentan terhadap MEV (MEV berkurang saat waktu blok memendek, membuat pengguna Ethereum lebih rentan terhadap MEV)

Selain itu, waktu blok 12 detik sangat tidak menguntungkan untuk rollup, terutama rollup berbasis. Misalnya, Taiko menerapkan rollup berbasis dengan memposting setiap blok L2 ke L1. Akibatnya, waktu blok Taiko bisa meningkat menjadi minimal 12 detik dan kadang-kadang melebihi 24 detik.

Dua solusi telah diusulkan untuk mengatasi ini:

a. Mengurangi waktu blok Ethereum menjadi 4 atau 8 detik

b. Gunakan prekonfirmasi

Mengurangi waktu blok Ethereum

Mengurangi waktu blok Ethereum adalah topik diskusi aktif. Ini telah diformalkan sebagai EIP-7782, yang mengusulkan pengurangan waktu slot dari 12 detik menjadi 8 detik, sehingga meningkatkan skalabilitas Ethereum sebesar 33%. Namun, waktu slot 8 detik mungkin tidak optimal untuk pengalaman pengguna atau rollups berbasis. Mencapai waktu slot yang lebih singkat tampaknya lebih diinginkan.

Dengan demikian, waktu blok yang lebih pendek dapat menyebabkan peningkatan sentralisasi set validator. Karena kendala fisik, validator yang berjarak geografis menghadapi waktu komunikasi yang lebih lama, dan waktu slot 4 detik dapat membuat komunikasi tidak memungkinkan dalam beberapa skenario.

Statistik waktu penyebaran blok Ethereum mainnet memberikan wawasan tentang kelayakan waktu blok 4 detik. Grafik di bawah ini menunjukkan distribusi waktu penyebaran blok.

(CDF of waktu kedatangan pesan | Sumber:Gossipsub Penyebaran Pesan Latensi)

Sekitar 98% blok dipropagasi dalam waktu 4 detik, sedangkan sekitar 2% membutuhkan waktu lebih lama. Berdasarkan data ini, waktu blok 4 detik mungkin memungkinkan. Namun, waktu blok melibatkan lebih dari sekadar komunikasi—termasuk eksekusi dan pemungutan suara. Mengingat faktor-faktor ini, hanya sekitar 2 detik dari waktu blok 4 detik yang tersedia untuk komunikasi. Dalam kondisi ini, mencapai waktu blok 4 detik merupakan tantangan.

Untuk mengatasi hal ini, ukuran data yang ditransmisikan harus dikurangi, kinerja komponen P2P di klien harus dimaksimalkan, atau komunikasi fisik harus menjadi lebih efisien.

Menggunakan preconfirmations

Sementara itu, pra-konfirmasi dapat meningkatkan pengalaman pengguna. Pra-konfirmasi memungkinkan entitas produsen blok untuk menjanjikan kepada pengguna, “Transaksi Anda akan dimasukkan ke dalam blok berikutnya,” memberikan hasil kepada pengguna lebih cepat dari waktu slot.

Keuntungan dari pra-konfirmasi adalah bahwa validator L1 dapat menggunakannya tanpa memerlukan fork atau modifikasi klien. Sebagai contoh, Commit-Boost adalah perangkat lunak yang memungkinkan validator Ethereum untuk menghasilkan dan menyebarkan pra-konfirmasi dengan aman.

Commit-Boost, seperti MEV-Boost, adalah sidecar opsional untuk validator, yang memungkinkan mereka untuk secara aman menghasilkan dan menyebarkan "komitmen." Tergantung pada kasus penggunaan, komitmen ini dapat berbagai bentuk:

Dengan menggunakan arsitektur pra-konfirmasi tipe ketiga, laten yang dirasakan oleh pengguna dapat signifikan berkurang bahkan dengan waktu blok yang lebih lama. Ketika validator menerima transaksi pengguna, mereka dapat mengeksekusinya dan mengembalikan hasilnya ke pengguna. Karena hasil ini didasarkan pada komitmen validator dan bukan penciptaan blok, pengguna dapat menerimanya dalam hitungan milidetik.

Namun, efektivitas Commit-Boost bergantung pada adopsi validator. Jika hanya sedikit validator yang menggunakannya, dampak terhadap UX akan minimal. Meski begitu, Commit-Boost telah mendapatkan dukungan kuat dari komunitas Ethereum dan berpotensi menjadi middleware yang luas seperti MEV-Boost. Ini telah mendapat dukungan dari operator validator terkenal seperti Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41, dan Figment. Selain itu, ini telah mendapatkan hibah dari EF, Lido, dan Eigenlayer dan menikmati dukungan kuat dari pembangun blok Titan.

Meskipun begitu, seperti yang disebutkan sebelumnya, pra-konfirmasi lebih cenderung digunakan sebagai sidecar di luar rantai seperti MEV-Boost daripada diintegrasikan langsung ke dalam protokol.

Peran Beam Chain dalam slot yang lebih cepat

Seperti yang dibahas dalam presentasi Justin Drake, tujuan Beam Chain adalah untuk mengurangi waktu blok. Oleh karena itu, penelitian dan implementasi kemungkinan akan fokus pada pengurangan waktu slot menjadi 4 detik tanpa mengorbankan desentralisasi. Hal ini mungkin dapat diatasi dengan snarkifikasi penuh Ethereum, yang akan dijelaskan di bagian akhir artikel ini.

Snarkifikasi Rantai dan Ketahanan Kuantum

Justin menyatakan dalam presentasinya bahwa tujuan Beam Chain adalah untuk menggunakanteknologi ZK untuk menyimpulkan klien konsensus. Apa artinya ini, bagaimana bisa dicapai, dan mengapa ini diperlukan?

Snarkifikasi rantai

Saat ini, Ethereum Beacon Chain mencapai konsensus dengan meminta validator untuk "mengeksekusi ulang" setiap blok untuk memverifikasi bahwa root status yang dihasilkan benar. Proses eksekusi ulang ini menyebabkan ketidakefisienan dan menjadi hambatan dalam menurunkan persyaratan perangkat keras untuk validator.

Beam Chain bertujuan untuk menggantikan proses re-eksekusi ini dengan 'verifikasi' menggunakan teknologi ZK. Ini akan secara signifikan menurunkan persyaratan perangkat keras untuk validator dan memungkinkan siapa saja menjalankan node Ethereum dari mana saja. Untuk mencapai hal ini, Beam Chain dan Ethereum akan menggunakan ZK SNARKs.

ZK dalam protokol Ethereum

ZK SNARKs memiliki dua properti berikut:

1. Mereka memungkinkan verifikasi bahwa suatu perhitungan tertentu telah dilakukan tanpa perlu menjalankan perhitungan tersebut ulang
2. Ukuran bukti lebih kompak dibandingkan dengan data asli

Ideanya adalah menerapkan ZK pada komputasi dan data yang diperlukan untuk konsensus di Ethereum, menghasilkan bukti bahwa logika yang ditentukan telah diikuti. Ini berarti validator dapat mencapai konsensus dengan memverifikasi bukti ZK daripada menjalankan ulang seluruh blok dan menyimpan status terbaru. Memverifikasi bukti ZK jauh lebih efisien dalam hal ukuran data dan skalabilitas daripada menjalankan ulang.

Akibatnya, persyaratan perangkat keras untuk validator Ethereum dapat dikurangi secara dramatis. Misalnya, Vitalik telah menyatakan dalam artikel The Verge bahwa tujuannya adalah untuk memungkinkan validator beroperasi bahkan di lingkungan yang terbatas sumber daya seperti smartwatch.

Apa yang perlu dilakukan?

Langkah pertama adalah mengubah fungsi transisi keadaan menjadi snarkifikasi. Fungsi transisi keadaan umumnya memiliki bentuk berikut:

f(S,B)=S’

Di sini:

• S: Pra-status dari blockchain
• B: Blok yang diberikan
• S': Status terkini dari blockchain setelah menjalankan blok
• f: Fungsi transisi keadaan

Semua blockchain didasarkan pada fungsi transisi status deterministik, dan Ethereum bukanlah suatu pengecualian. Ethereum memiliki fungsi transisi status yang berbeda untuk lapisan konsensus dan eksekusi. Mengonversi keduanya ke Snark akan memungkinkan verifikasi seluruh sistem Ethereum menggunakan ZK, sehingga memungkinkan validator yang sepenuhnya ringan.

Dalam Beam Chain, tujuannya adalah untuk melakukan snarkify pada fungsi transisi status dari lapisan konsensus. Saat ini, fungsi transisi status dalam lapisan konsensus Ethereum dieksekusi pada setiap slot dan melakukan tindakan-tindakan berikut:

• Memperbarui informasi slot dan header blok setelah menerima sebuah blok
• Memverifikasi tanda tangan validator yang mengusulkan blok
• Memvalidasi transaksi dalam blok
• Memproses penarikan, pemangkasan, finalisasi blok, dan informasi lainnya setiap kali terjadi transisi epoch

Fungsi ini dieksekusi setiap kali validator menerima blok dari validator lain. Jika fungsi ini di-snarkified, validator tidak lagi perlu mengeksekusi fungsi transisi status secara langsung. Sebaliknya, mereka bisa memverifikasi bukti yang menunjukkan bahwa fungsi tersebut dieksekusi dengan benar.

Dalam kasus ini, siapa yang menghasilkan bukti ZK? Biasanya, seseorang mungkin mengasumsikan bahwa proposer blok juga bertanggung jawab untuk menghasilkan bukti ZK. Namun, penting untuk dicatat bahwa tidak semua validator dapat menghasilkan bukti ZK.

Beam Chain bertujuan untuk mencapai kinerja di mana bukti ZK dapat dihasilkan dalam 3 detik pada laptop standar. Namun, bahkan jika tujuan ini tercapai, validator yang berjalan pada perangkat seperti smartwatch atau smartphone mungkin tidak memiliki sumber daya yang cukup untuk menghasilkan bukti ZK.

Di sini, jaringan dapat mengandalkan altruisme. Hanya satu bukti ZK untuk transisi status lapisan konsensus yang diperlukan per blok, dan tidak harus dihasilkan oleh penawar blok. Dengan kata lain, selama setidaknya satu entitas dalam jaringan menghasilkan bukti ZK untuk setiap blok, dapat memastikan bahwa blok Beam Chain dihasilkan dengan benar.

Masa Depan: Snarkifikasi penuh Ethereum

Perubahan ini sendiri mungkin tidak signifikan meningkatkan kinerja validator. Fungsi peralihan status lapisan konsensus melibatkan tindakan yang relatif ringan dibandingkan dengan fungsi peralihan status lapisan eksekusi. Namun, bottleneck utama bukan terletak pada sumber daya yang diperlukan untuk menjalankan fungsi peralihan status tetapi pada bandwidth jaringan. Validator kesulitan mencapai konsensus dalam waktu yang dialokasikan ketika ukuran data (blok) yang mereka pertukarkan meningkat. Ini adalah salah satu alasan mengapa Ethereum telah mempertahankan batas gas 30M selama tiga tahun terakhir.

Jika perubahan ini diimplementasikan bersamaan dengan snarkification dari lapisan eksekusi, validator hanya perlu bertukar jumlah data yang jauh lebih kecil dibandingkan dengan seluruh blok. Hal ini karena bukti SNARK jauh lebih kompak dibandingkan dengan data asli. Validator Ethereum yang sepenuhnya snarkified akan bertukar data yang lebih sedikit, mengurangi persyaratan jaringan dibandingkan dengan sistem saat ini.

Secara ringkas, berikut adalah keuntungan dari snarkification penuh Ethereum bagi validator.

1. Validator hanya perlu memverifikasi bukti, bukan menjalankan kembali perhitungan, mengurangi tuntutan komputasi
2. Validator bertukar data bukti bukan data blok lengkap, mengurangi kebutuhan bandwidth jaringan

Akibatnya, ekosistem Ethereum dapat mengalami perubahan yang signifikan. Misalnya:

• Hal-hal seperti “Aplikasi Node Ethereum” dapat memungkinkan validator beroperasi pada perangkat mobile.
• Siapa pun yang memenuhi persyaratan staking minimum dapat menjalankan node Ethereum, secara signifikan mengurangi hambatan menjadi validator.

Ini akan membuat partisipasi validator menjadi lebih mudah diakses dan terdesentralisasi.

Tanda tangan tahan quantum

Apakah snarkifying fungsi transisi state saja sudah cukup untuk Beam Chain sebagai lapisan konsensus?

Masalah apa yang akan dihadapi Ethereum di dunia pasca-kuantum?

Ada area lain yang Beam Chain bertujuan untuk disnarkifikasi: pembangkitan tanda tangan. Lapisan konsensus Ethereum saat ini menggunakan tanda tangan validator sebagai data kesaksian untuk menyelesaikan blok dan menentukan rantai yang benar dalam hal terjadi fork.

Saat ini Ethereum menggunakan tanda tangan BLS untuk tujuan ini, yang, seperti yang dijelaskan sebelumnya, memiliki sifat agregasi, memungkinkan beberapa tanda tangan digabungkan menjadi satu. Agregasi ini secara signifikan meningkatkan efisiensi proses konsensus Ethereum. Namun, mekanisme tanda tangan ini memiliki masalah mendasar: rentan terhadap komputer kuantum.

Tanda tangan BLS yang digunakan dalam Beacon Chain Ethereum didasarkan pada kurva eliptik. Keamanan mekanisme tanda tangan berbasis kurva eliptik bergantung pada Discrete Logarithm Problem (DLP), yang kekuatan komputasi superior komputer kuantum dapat mengorbankannya. Hal ini membuat tanda tangan berbasis kurva eliptik rentan terhadap komputer kuantum.

Komputasi kuantum telah berkembang pesat, seperti yang dibuktikan oleh perkembangan terbaru Google dengan chip komputasi kuantum seperti Willow. Google mengklaim bahwa Willow dapat melakukan perhitungan dalam 5 menit yang akan membutuhkan superkomputer selama 10^25 tahun. Meskipun hal ini belum mengancam keamanan kurva eliptis secara mendasar, kemajuan yang terus berlanjut dengan kecepatan ini bisa mengancam sistem blockchain dalam beberapa tahun ke depan.

(Transisi ke Standar Kriptografi Pasca Kuantum | Sumber: NIST IR 8547)

Institut Nasional Standar dan Teknologi Amerika Serikat (NIST) telah memulai upaya untuk menstandardisasi algoritma tanda tangan tahan-kuantum untuk mengatasi keruntuhan sistem yang ada yang diakibatkan oleh komputer kuantum yang diperkirakan akan terjadi.

Ethereum juga menanggapi masalah ini dengan serius. Di Beam Chain, tujuannya adalah untuk mencapai algoritma tanda tangan tahan kuantum.

Ada beberapa jenis tanda tangan tahan kuantum, tetapi presentasi Beam Chain karya Justin secara khusus menyebutkan algoritma tanda tangan berbasis hash. Berbeda dengan kurva eliptis, tanda tangan berbasis hash tidak bergantung pada mekanisme matematis, sehingga membuatnya jauh lebih sulit bagi komputer kuantum untuk dikompromikan. Sebagai hasilnya, tanda tangan berbasis hash dianggap tahan kuantum, dan Beam Chain bertujuan untuk mengadopsi tanda tangan tersebut.

Tantangan dan peran ZK

Tantangan utama adalah tanda tangan berbasis hash tidak memiliki properti agregasi yang ada pada tanda tangan BLS. Ethereum mengandalkan agregasi tanda tangan selama konsensus untuk mencapai efisiensi. Tanpa agregasi, Ethereum tidak akan lagi dapat menampung kumpulan validator besar.

ZK dapat digunakan untuk mengatasi ini. Ini melibatkan memanfaatkan Agregasi Bukti, teknologi yang menggabungkan beberapa bukti ZK menjadi satu bukti. Mekanisme ini bekerja sebagai berikut:

(Diagram Agregasi Bukti | Sumber: Figment Capital)

1. Validator menandatangani blok menggunakan algoritma tahan kuanta.
2. Tanda tangan dikirim ke pengumpul**atau Komite agregasi.
3. Agregator menghasilkan bukti ZK yang memverifikasi kebenaran tanda tangan.
4. Dengan menggunakan teknik agregasi bukti, penagregat menggabungkan bukti-bukti baru dengan yang sudah ada saat tanda tangan baru diterima.

Pendekatan ini memungkinkan Ethereum mencapai efisiensi yang sama dengan agregasi tanda tangan BLS sambil juga mencapai ketahanan kuantum pada tingkat konsensus.

Peran ZK dalam Beam Chain

Secara ringkas, rantai Beam dengan ZK akan memberikan keunggulan berikut:

1. Mengaktifkan validator untuk melakukan verifikasi bukti daripada eksekusi ulang untuk fungsi transisi status lapisan konsensus yang berkontribusi pada persyaratan validator ringan.
2. Melayani sebagai dasar untuk algoritma agregasi untuk tanda tangan tahan kuantum, meningkatkan efisiensi lapisan konsensus.

zkVM sebagai dasar untuk ZK di Beam Chain

Sistem bukti yang mendasari ZK di Beam Chain akan menjadi zkVM. zkVM berbasis Risc-V memungkinkan pembuktian program dalam bahasa apapun, menawarkan fleksibilitas yang lebih besar.

(Transisi status Beam akan dikompilasi ke dalam Risc-V dan dibuktikan di zkVMs | Sumber: Pengumuman Rantai Beam oleh Justin Drake)

Ini sejalan dengan ekosistem klien Ethereum yang ada, yang dikembangkan dalam berbagai bahasa, menjaga keragaman dan toleransi kesalahan Ethereum. Dalam rantai Beam masa depan, berbagai klien akan menulis fungsi transisi status dalam berbagai bahasa pemrograman, mengkompilasinya ke Risc-V, dan memungkinkannya untuk dibuktikan dalam zkVM berbasis Risc-V. Untuk alasan ini, zkVM adalah pilihan alami untuk Beam Chain.

Kesimpulan

Jika Beam Chain berhasil diimplementasikan, Ethereum kemungkinan akan memiliki fitur-fitur berikut:

1. Pengguna akan mengalami konfirmasi transaksi dalam waktu 4 detik, dengan finalitas dicapai dalam waktu 12 detik.
2. Validator akan memverifikasi transisi keadaan di lapisan konsensus menggunakan bukti ZK. Jika lapisan eksekusi juga diubah menjadi snarkified, validator hanya membutuhkan jumlah data minimal untuk berpartisipasi dalam konsensus.
3. Tanda tangan validator akan tahan terhadap kuantum
4. t, mencegah komputer kuantum mengompromikan konsensus Ethereum.

Saat ini, Beam Chain belum diakui secara resmi sebagai bagian dari jalan peta Ethereum. Mengimplementasikannya akan membutuhkan penelitian, pengembangan, dan pengujian yang intensif selama periode yang lama. Namun, jika Ethereum melanjutkan dengan fork Beam Chain, perbaikan UX yang dihasilkan dapat menjadi transformatif.

Ini menyimpulkan eksplorasi kami tentang bagaimana Ethereum mungkin berkembang dalam lima tahun melalui lensa Beam Chain. Pada artikel berikutnya, kami akan menguji seperti apa penampilan Ethereum pada tahun 2025 dari dua sudut pandang: UX dan ketahanan terhadap sensor.

Lampiran: Pertanyaan Umum tentang Beam Chain

(Q): Proposal Justin Drake dibahas secara pribadi. Bukankah ini bertentangan dengan nilai inti Ethereum untuk menjadi "terbuka"?

(A): Tidak. Usulan Beam Chain hanya mengusulkan implementasi beberapa bagian dari roadmap Ethereum secara langsung. Apakah akan diimplementasikan atau tidak, masih memerlukan diskusi komunitas. Semua topik yang dibahas di atas sudah memiliki EIP atau postingan terkait di Ethresear.ch. Hal ini menunjukkan bahwa Beam Chain bukanlah usulan yang mengusulkan arah baru yang sebelumnya tidak diungkapkan untuk Ethereum. Selain itu, diskusi mengenai roadmap Ethereum dilakukan secara publik selama All Core Devs Call dua mingguan, di mana siapa pun dapat berpartisipasi. Jika seseorang tidak setuju dengan roadmap atau memiliki ide baru, mereka dapat menyampaikan pendapat mereka selama panggilan tersebut atau mengajukan usulan baru dalam bentuk EIP atau postingan di Ethresear.ch.

Secara ringkas, proposal Beam Chain dari Justin bukan tentang mengubah roadmap — tetapi lebih tentang menggabungkan bagian-bagian roadmap di bawah satu nama atau meme yang sama.

(Q): Apakah 5 tahun terlalu lama untuk mengimplementasikan Beam Chain?

(A): Lima tahun mungkin terasa lama, tapi dua faktor perlu dipertimbangkan:

1. Ethereum dibangun dengan arsitektur multi-klien.
2. Ethereum memiliki jumlah validator terbesar dibandingkan dengan blockchain lainnya.

(Diversitas klien konsensus | Sumber: Keragaman Klien Ethereum)

Mekanisme konsensus Ethereum mengikuti protokol berbasis BFT di mana jika lebih dari sepertiga validator bertindak berbeda dari yang lain, blok tidak dapat difinalisasi. Jika Ethereum dibangun hanya dengan satu atau dua klien, bug apa pun dalam klien-klien ini dapat mengganggu produksi blok. Oleh karena itu, Ethereum selalu bertujuan untuk memiliki arsitektur multi-klien yang dikembangkan dalam beberapa bahasa pemrograman. Keragaman ini terlihat dalam ekosistem klien Ethereum saat ini.

Seperti yang ditunjukkan pada gambar, lapisan konsensus Ethereum saat ini beroperasi dengan setidaknya empat klien. Untuk mengganti Rantai Suar dengan Rantai Balok, keempat tim klien harus berkolaborasi dalam pengembangan. Mempertimbangkan hal ini dan set validator Ethereum yang besar, proses pengembangan Beam Chain harus memprioritaskan stabilitas dan tidak dapat dipercepat ke jangka waktu beberapa bulan atau 1-2 tahun.

Disclaimer:

1. Artikel ini dicetak ulang dari [2077riset]. Semua hak cipta milik penulis asli [tumpukan sm]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyataan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini sepenuhnya merupakan pandangan penulis dan tidak merupakan nasihat investasi apa pun.
3. Tim Pembelajaran Gate melakukan terjemahan artikel ke dalam bahasa lain. Kecuali disebutkan, menyalin, mendistribusikan, atau plagiarisme artikel yang diterjemahkan dilarang.