Vitalik: Apa saja yang masih bisa ditingkatkan dari Ethereum PoS dan bagaimana cara meningkatkannya?

Artikel ini akan berfokus pada isu "Merge" Ethereum: aspek apa dari desain teknis proof-of-stake yang masih dapat ditingkatkan, dan jalur apa yang dapat diambil untuk mewujudkan peningkatan tersebut?

Penulis:Vitalik Buterin

Penerjemah: Deng Tong, Jinse Finance

Terima kasih khusus kepada Justin Drake, Hsiao-wei Wang, @antonttc, dan Francesco atas masukan dan peninjauannya.

Pada awalnya, "Merge" merujuk pada peristiwa paling penting dalam sejarah protokol Ethereum sejak diluncurkan: transisi yang telah lama dinantikan dan sulit dari proof-of-work ke proof-of-stake. Saat ini, Ethereum telah menjadi sistem proof-of-stake yang berjalan stabil selama hampir dua tahun, dan proof-of-stake ini menunjukkan kinerja yang sangat baik dalam hal stabilitas, performa, dan menghindari risiko sentralisasi. Namun, proof-of-stake masih memiliki beberapa area penting yang perlu ditingkatkan.

Peta jalan saya tahun 2023 membaginya menjadi beberapa bagian: peningkatan fitur teknis seperti stabilitas, performa, dan aksesibilitas bagi validator kecil, serta perubahan ekonomi untuk mengatasi risiko sentralisasi. Bagian pertama mengambil alih judul "Merge", sedangkan bagian kedua menjadi bagian dari "Scourge".

Artikel ini akan berfokus pada bagian "Merge": aspek apa dari desain teknis proof-of-stake yang masih dapat ditingkatkan, dan jalur apa yang dapat diambil untuk mewujudkan peningkatan tersebut?

Ini bukanlah daftar lengkap tentang bagaimana proof-of-stake dapat ditingkatkan; sebaliknya, ini adalah daftar ide yang sedang dipertimbangkan secara aktif.

Finalitas Slot Tunggal dan Demokratisasi Staking

Masalah apa yang sedang kita selesaikan?

Saat ini, dibutuhkan 2-3 epoch (sekitar 15 menit) untuk menyelesaikan satu blok, dan diperlukan 32 ETH untuk menjadi staker. Awalnya, ini merupakan kompromi untuk menyeimbangkan tiga tujuan:

• Maksimalisasi jumlah validator yang dapat berpartisipasi dalam staking (yang secara langsung berarti meminimalkan jumlah minimum ETH yang dibutuhkan untuk staking)
• Meminimalkan waktu finalitas
• Meminimalkan overhead menjalankan node

Ketiga tujuan ini saling bertentangan: untuk mencapai finalitas ekonomi (yaitu penyerang harus membakar banyak ETH untuk membatalkan blok yang sudah final), setiap validator perlu menandatangani dua pesan setiap kali finalitas terjadi. Jadi, jika Anda memiliki banyak validator, Anda harus memilih antara membutuhkan waktu lama untuk memproses semua tanda tangan, atau membutuhkan node yang sangat kuat untuk memproses semua tanda tangan secara bersamaan.

Perlu dicatat bahwa semua ini bergantung pada satu tujuan utama Ethereum: memastikan bahwa bahkan serangan yang berhasil pun akan sangat mahal bagi penyerang. Inilah arti dari istilah "finalitas ekonomi". Jika kita tidak memiliki tujuan ini, kita bisa saja menggunakan komite yang dipilih secara acak (seperti yang dilakukan Algorand) untuk menyelesaikan setiap slot. Namun, masalah dari pendekatan ini adalah jika penyerang benar-benar menguasai 51% validator, mereka dapat melakukan serangan dengan biaya yang sangat rendah (membatalkan blok final, melakukan sensor, atau menunda finalitas): hanya sebagian node dalam komite yang dapat terdeteksi berpartisipasi dalam serangan dan dihukum, baik melalui slashing maupun soft fork minoritas. Ini berarti penyerang dapat berulang kali menyerang rantai tersebut. Oleh karena itu, jika kita menginginkan finalitas ekonomi, pendekatan berbasis komite yang sederhana tidak akan berhasil, dan sekilas, kita memang membutuhkan partisipasi seluruh validator.

Idealnya, kita ingin mempertahankan finalitas ekonomi, sambil meningkatkan dua aspek dari status quo:

• Finalitas blok dalam satu slot (idealnya, mempertahankan atau bahkan mengurangi panjang slot saat ini yaitu 12 detik), bukan 15 menit
• Mengizinkan validator untuk staking dengan 1 ETH (menurunkan dari 32 ETH menjadi 1 ETH)

Tujuan pertama didukung oleh dua argumen, yang keduanya dapat dilihat sebagai "membuat properti Ethereum sejalan dengan properti L1 yang lebih terpusat dan berorientasi pada performa".

Pertama, ini memastikan semua pengguna Ethereum dapat memperoleh manfaat dari tingkat keamanan yang lebih tinggi yang diberikan oleh mekanisme finalitas. Saat ini, sebagian besar pengguna tidak dapat menikmati jaminan ini karena mereka tidak mau menunggu 15 menit; dengan finalitas slot tunggal, pengguna hampir dapat melihat transaksi mereka final segera setelah dikonfirmasi. Kedua, jika pengguna dan aplikasi tidak perlu khawatir tentang kemungkinan rollback rantai (kecuali dalam kasus langka seperti inactivity leak), maka ini menyederhanakan protokol dan infrastruktur di sekitarnya.

Tujuan kedua didorong oleh keinginan untuk mendukung staker individu. Survei berulang kali menunjukkan bahwa faktor utama yang menghalangi lebih banyak orang untuk staking secara individu adalah batas minimum 32 ETH. Menurunkan batas minimum menjadi 1 ETH akan menyelesaikan masalah ini, sehingga masalah lain menjadi faktor pembatas utama bagi staking individu.

Ada satu tantangan: tujuan finalitas yang lebih cepat dan staking yang lebih demokratis bertentangan dengan tujuan meminimalkan overhead. Faktanya, inilah alasan utama kita tidak mengadopsi finalitas slot tunggal sejak awal. Namun, penelitian terbaru telah mengusulkan beberapa cara potensial untuk mengatasi masalah ini.

Apa itu dan bagaimana cara kerjanya?

Finalitas slot tunggal melibatkan penggunaan algoritma konsensus yang dapat menyelesaikan blok dalam satu slot. Ini sendiri bukanlah tujuan yang sulit dicapai: banyak algoritma (seperti konsensus Tendermint) telah mencapainya dengan properti optimal. Salah satu properti ideal yang unik dari Ethereum adalah inactivity leak yang tidak didukung oleh Tendermint, yaitu bahkan jika lebih dari 1/3 validator offline, rantai masih dapat berjalan dan akhirnya pulih. Untungnya, keinginan ini sudah terpenuhi: sudah ada proposal untuk memodifikasi konsensus gaya Tendermint agar mendukung inactivity leak.

Proposal finalitas slot tunggal terdepan

Bagian tersulit adalah mencari tahu bagaimana membuat finalitas slot tunggal tetap berfungsi dengan jumlah validator yang sangat besar, tanpa menyebabkan overhead operator node yang sangat tinggi. Untuk itu, ada beberapa solusi terdepan:

Pilihan 1: Brute force—berusaha mencapai protokol agregasi tanda tangan yang lebih baik, mungkin menggunakan ZK-SNARKs, yang benar-benar memungkinkan kita memproses tanda tangan dari jutaan validator dalam setiap slot.

Horn, salah satu desain yang diusulkan untuk protokol agregasi yang lebih baik.

Pilihan 2: Komite Orbit - mekanisme baru yang memungkinkan komite berukuran sedang yang dipilih secara acak bertanggung jawab untuk menyelesaikan rantai, tetapi dengan cara yang mempertahankan properti biaya serangan yang kita cari.

Salah satu cara memikirkan Orbit SSF adalah, ia membuka ruang kompromi dari x=0 (komite gaya Algorand, tanpa finalitas ekonomi) hingga x=1 (status quo Ethereum), membuka titik-titik di tengah di mana Ethereum masih memiliki finalitas ekonomi yang cukup untuk keamanan ekstrem, tetapi kita juga mendapatkan keuntungan efisiensi karena hanya sampel validator acak berukuran sedang yang berpartisipasi di setiap slot.

Orbit memanfaatkan heterogenitas ukuran deposit validator yang sudah ada untuk mendapatkan sebanyak mungkin finalitas ekonomi, sambil tetap memberikan peran yang sesuai kepada validator kecil. Selain itu, Orbit menggunakan rotasi komite yang lambat untuk memastikan tumpang tindih tinggi antara kuorum yang berdekatan, sehingga finalitas ekonominya tetap berlaku pada batas rotasi komite.

Pilihan 3: Staking dua lapis - mekanisme di mana staker dibagi menjadi dua kategori, satu dengan persyaratan deposit lebih tinggi, satu lagi dengan persyaratan lebih rendah. Hanya lapisan dengan deposit tinggi yang secara langsung berpartisipasi dalam memberikan finalitas ekonomi. Ada berbagai proposal tentang hak dan tanggung jawab lapisan deposit rendah (misalnya, lihat posting Rainbow staking). Ide umum meliputi:

• Hak untuk mendelegasikan stake ke pemegang stake lapisan atas
• Validator lapisan bawah yang dipilih secara acak membuktikan dan harus menyelesaikan setiap blok
• Hak untuk menghasilkan daftar inklusi

Apa kaitannya dengan penelitian yang ada?

• Jalur menuju finalitas slot tunggal (2022):
• Proposal spesifik protokol finalitas slot tunggal Ethereum (2023):
• Orbit SSF:
• Analisis lebih lanjut tentang mekanisme gaya Orbit:
• Horn, protokol agregasi tanda tangan (2022):
• Penggabungan tanda tangan untuk konsensus skala besar (2023):
• Protokol agregasi tanda tangan oleh Khovratovich dkk:
• Agregasi tanda tangan berbasis STARK (2022):
• Rainbow staking:

Apa yang masih harus dilakukan? Apa saja trade-off-nya?

Ada empat jalur utama yang layak (kita juga bisa mengambil jalur campuran):

• Mempertahankan status quo
• Orbit SSF
• SSF brute force
• SSF dengan staking dua lapis

(1) Berarti tidak melakukan apa-apa, mempertahankan staking seperti sekarang, tetapi ini akan membuat pengalaman keamanan dan sifat sentralisasi staking Ethereum menjadi lebih buruk dari yang seharusnya.

(2) Menghindari "teknologi tinggi", dan menyelesaikan masalah dengan memikirkan ulang asumsi protokol secara cerdas: kita melonggarkan persyaratan "finalitas ekonomi", sehingga kita tetap mengharuskan biaya serangan tinggi, tetapi dapat menerima jika biaya serangan mungkin 10 kali lebih rendah dari sekarang (misalnya, biaya serangan 2.5 billions USD, bukan 25 billions USD). Secara umum diyakini bahwa finalitas ekonomi Ethereum saat ini jauh melebihi tingkat yang dibutuhkan, dan risiko keamanan utamanya ada di tempat lain, sehingga ini bisa dibilang pengorbanan yang dapat diterima.

Pekerjaan utama adalah memverifikasi apakah mekanisme Orbit aman dan memiliki properti yang kita inginkan, lalu memformalkan dan mengimplementasikannya sepenuhnya. Selain itu, EIP-7251 (meningkatkan saldo efektif maksimum) memungkinkan penggabungan saldo validator secara sukarela, yang segera mengurangi overhead validasi rantai, dan menjadi tahap awal yang efektif untuk peluncuran Orbit.

(3) Menghindari pemikiran ulang yang cerdas, dan malah menyelesaikan masalah secara paksa dengan teknologi tinggi. Untuk melakukan ini, dibutuhkan pengumpulan tanda tangan dalam jumlah besar (lebih dari 1 juta) dalam waktu yang sangat singkat (5-10 detik).

(4) Menghindari pemikiran ulang yang cerdas dan teknologi tinggi, tetapi memang menciptakan sistem staking dua lapis yang masih memiliki risiko sentralisasi. Risikonya sangat bergantung pada hak spesifik yang diperoleh lapisan staking rendah. Misalnya:

• Jika validator lapisan bawah harus mendelegasikan hak pembuktian mereka ke validator lapisan atas, maka delegasi bisa menjadi terpusat, dan akhirnya kita akan mendapatkan dua lapisan staking yang sangat terpusat.
• Jika lapisan bawah perlu diambil sampel secara acak untuk menyetujui setiap blok, penyerang dapat menghabiskan sedikit ETH untuk mencegah finalitas.
• Jika validator lapisan bawah hanya dapat membuat daftar inklusi, maka lapisan pembuktian mungkin tetap terpusat, dan serangan 51% pada lapisan pembuktian dapat menyensor daftar inklusi itu sendiri.

Beberapa strategi dapat dikombinasikan, misalnya:

• (1 + 2): Menambahkan Orbit tanpa menerapkan finalitas slot tunggal.
• (1 + 3): Menggunakan teknik brute force untuk mengurangi ukuran deposit minimum tanpa menerapkan finalitas slot tunggal. Jumlah agregasi yang dibutuhkan 64 kali lebih sedikit daripada kasus (3) murni, sehingga masalahnya menjadi lebih mudah.
• (2 + 3): Menerapkan Orbit SSF dengan parameter konservatif (misalnya komite validator 128k, bukan 8k atau 32k), dan menggunakan teknik brute force untuk membuatnya sangat efisien.
• (1 + 4): Menambahkan Rainbow staking tanpa menerapkan finalitas slot tunggal.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Selain manfaat lainnya, finalitas slot tunggal juga mengurangi risiko beberapa jenis serangan MEV multi-blok. Selain itu, dalam dunia finalitas slot tunggal, desain pemisahan prover-proposer dan pipeline produksi blok dalam protokol perlu dirancang secara berbeda.

Kelemahan dari strategi brute force adalah mereka membuat pemendekan waktu slot menjadi lebih sulit.

Pemilihan Leader Rahasia Tunggal

Masalah apa yang ingin kita selesaikan?

Saat ini, validator mana yang akan mengusulkan blok berikutnya sudah diketahui sebelumnya. Ini menciptakan celah keamanan: penyerang dapat memantau jaringan, mengidentifikasi validator mana yang sesuai dengan alamat IP mana, dan melancarkan serangan DoS pada validator yang akan segera mengusulkan blok.

Apa itu? Bagaimana cara kerjanya?

Cara terbaik untuk mengatasi masalah DoS adalah dengan menyembunyikan informasi tentang validator mana yang akan menghasilkan blok berikutnya, setidaknya sampai blok benar-benar dihasilkan. Perlu dicatat, jika kita menghapus persyaratan "tunggal", ini mudah: salah satu solusi adalah membiarkan siapa pun membuat blok berikutnya, tetapi mengharuskan randao reveal kurang dari 2256 / N. Rata-rata, hanya satu validator yang dapat memenuhi persyaratan ini—tetapi kadang-kadang ada dua atau lebih, kadang-kadang tidak ada. Menggabungkan persyaratan "rahasia" dengan "tunggal" selalu menjadi tantangan.

Protokol pemilihan leader rahasia tunggal menyelesaikan masalah ini dengan menggunakan beberapa teknik kriptografi untuk membuat "ID validator buta" untuk setiap validator, lalu membiarkan banyak proposer memiliki kesempatan untuk mengacak dan membutakan ulang kumpulan ID buta (ini mirip dengan cara kerja mixnet). Pada setiap slot, satu ID buta dipilih secara acak. Hanya pemilik ID buta tersebut yang dapat menghasilkan bukti valid untuk mengusulkan blok, tetapi tidak ada yang tahu ID buta tersebut milik validator yang mana.

Protokol Whisk SSLE

Apa saja tautan ke penelitian yang ada?

• Makalah Dan Boneh (2020):
• Whisk (proposal spesifik Ethereum, 2022):
• Label pemilihan leader rahasia tunggal di ethresear.ch:
• SSLE sederhana menggunakan ring signature:

Apa yang masih harus dilakukan? Apa saja trade-off-nya?

Pada dasarnya, yang tersisa adalah menemukan dan mengimplementasikan protokol yang cukup sederhana sehingga kita dapat dengan mudah menerapkannya di mainnet. Kami sangat menghargai bahwa Ethereum adalah protokol yang cukup sederhana, dan kami tidak ingin kompleksitasnya semakin meningkat. Implementasi SSLE yang kami lihat menambah ratusan baris kode spesifikasi, dan memperkenalkan asumsi baru dalam kriptografi yang kompleks. Menemukan implementasi SSLE yang cukup efisien dan tahan terhadap kuantum juga masih menjadi masalah terbuka.

Pada akhirnya, mungkin saja hanya ketika kita memperkenalkan mekanisme zero-knowledge proof umum di L1 protokol Ethereum untuk alasan lain (misalnya state tree, ZK-EVM), "kompleksitas tambahan marjinal" dari SSLE akan cukup rendah.

Pilihan lain adalah mengabaikan SSLE sama sekali, dan menggunakan mitigasi di luar protokol (misalnya di lapisan p2p) untuk mengatasi masalah DoS.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Jika kita menambahkan mekanisme pemisahan prover-proposer (APS), seperti eksekusi tiket, maka blok eksekusi (yaitu blok yang berisi transaksi Ethereum) tidak akan memerlukan SSLE, karena kita dapat mengandalkan builder blok khusus. Namun, untuk blok konsensus (yaitu blok yang berisi pesan protokol seperti bukti, bagian daftar inklusi, dll.), kita masih akan mendapat manfaat dari SSLE.

Konfirmasi Transaksi Lebih Cepat

Masalah apa yang sedang kita selesaikan?

Mengurangi waktu konfirmasi transaksi Ethereum lebih lanjut, dari 12 detik menjadi 4 detik, sangat berharga. Ini akan secara signifikan meningkatkan pengalaman pengguna L1 dan berbasis rollup, sekaligus membuat protokol defi lebih efisien. Ini juga akan memudahkan L2 untuk terdesentralisasi, karena akan memungkinkan banyak aplikasi L2 berjalan di atas rollup, sehingga mengurangi kebutuhan L2 untuk membangun urutan desentralisasi berbasis komite mereka sendiri.

Apa itu? Bagaimana cara kerjanya?

Ada dua teknik utama di sini:

• Mengurangi waktu slot, misalnya menjadi 8 detik atau 4 detik. Ini tidak selalu berarti finalitas 4 detik: finalitas pada dasarnya membutuhkan tiga putaran komunikasi, jadi kita bisa membuat setiap putaran komunikasi sebagai blok terpisah, dan setelah 4 detik setidaknya mendapatkan konfirmasi awal.
• Mengizinkan proposer untuk menerbitkan pre-confirmation selama proses slot. Dalam kasus ekstrem, proposer dapat secara real-time memasukkan transaksi yang mereka lihat ke dalam blok mereka, dan segera menerbitkan pesan pre-confirmation untuk setiap transaksi ("transaksi pertama saya adalah 0×1234...", "transaksi kedua saya adalah 0×5678..."). Jika proposer menerbitkan dua konfirmasi yang saling bertentangan, ada dua cara untuk menanganinya: (i) dengan melakukan slashing pada proposer, atau (ii) dengan meminta validator memilih mana yang lebih awal.

Apa saja tautan ke penelitian yang ada?

• Berdasarkan pre-confirmation:
• PEPC (Protocol Enforced Proposer Commitments):
• Interleaved epochs on parallel chains (ide tahun 2018 untuk latensi rendah):

Apa yang masih harus dilakukan, dan apa saja trade-off-nya?

Masih belum jelas seberapa praktis mengurangi waktu slot. Bahkan hari ini, banyak staker di seluruh dunia kesulitan mendapatkan bukti dengan cukup cepat. Mencoba waktu slot 4 detik berisiko membuat kumpulan validator menjadi terpusat, dan karena latensi, menjadi validator di luar beberapa wilayah istimewa menjadi tidak realistis.

Kelemahan dari metode pre-confirmation proposer adalah ia dapat sangat meningkatkan waktu inklusi rata-rata, tetapi tidak memperbaiki waktu inklusi terburuk: jika proposer saat ini berjalan dengan baik, transaksi Anda akan mendapatkan pre-confirmation dalam 0,5 detik, bukan (rata-rata) 6 detik untuk dimasukkan, tetapi jika proposer saat ini offline atau berjalan buruk, Anda masih harus menunggu 12 detik penuh untuk memulai slot berikutnya dan mendapatkan proposer baru.

Selain itu, masih ada pertanyaan terbuka tentang bagaimana memberi insentif pada pre-confirmation. Proposer termotivasi untuk memaksimalkan opsionalitas mereka selama mungkin. Jika validator menandatangani ketepatan waktu pre-confirmation, pengirim transaksi dapat membayar sebagian biaya sebagai syarat untuk pre-confirmation segera, tetapi ini menambah beban pada validator, dan mungkin membuat validator lebih sulit untuk tetap menjadi "pipa bodoh" yang netral.

Di sisi lain, jika kita tidak mencoba melakukan ini dan mempertahankan waktu finalitas pada 12 detik (atau lebih lama), ekosistem akan semakin mengandalkan mekanisme pre-confirmation yang dibuat oleh L2, dan interaksi lintas L2 akan membutuhkan waktu lebih lama.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Pre-confirmation berbasis proposer sebenarnya bergantung pada mekanisme pemisahan prover-proposer (APS), seperti eksekusi tiket. Jika tidak, tekanan untuk menyediakan pre-confirmation real-time mungkin terlalu besar bagi validator biasa.

Bidang Penelitian Lainnya

Pemulihan Serangan 51%

Umumnya diyakini bahwa jika terjadi serangan 51% (termasuk serangan yang tidak dapat dibuktikan secara kriptografis, seperti sensor), komunitas akan bersatu untuk menerapkan soft fork minoritas, memastikan pihak baik menang, dan pihak jahat mengalami inactivity leak atau slashing. Namun, tingkat ketergantungan pada lapisan sosial ini bisa dibilang tidak sehat. Kita dapat mencoba mengurangi ketergantungan pada lapisan sosial, dan membuat proses pemulihan semiautomatis sebanyak mungkin.

Otomatisasi penuh tidak mungkin dilakukan, karena jika bisa, itu akan dihitung sebagai algoritma konsensus toleransi kesalahan >50%, dan kita sudah mengetahui keterbatasan matematis (sangat ketat) dari algoritma semacam itu. Namun, kita dapat mencapai otomatisasi parsial: misalnya, jika klien mendeteksi sensor pada transaksi yang telah cukup lama terlihat oleh klien, klien dapat secara otomatis menolak menerima rantai sebagai final, bahkan menolak menerimanya sebagai kepala pilihan fork. Tujuan utama adalah memastikan bahwa pihak jahat dalam serangan setidaknya tidak dapat menang dengan cepat.

Meningkatkan Ambang Kuorum

Saat ini, jika 67% staker mendukung, blok akan menjadi final. Ada yang berpendapat ini terlalu agresif. Dalam seluruh sejarah Ethereum, hanya ada satu kegagalan finalitas (sangat singkat). Jika persentase ini dinaikkan menjadi 80%, jumlah periode non-finalitas yang bertambah akan relatif sedikit, tetapi Ethereum akan mendapatkan keamanan: khususnya, banyak kasus yang lebih kontroversial akan menyebabkan finalitas berhenti sementara. Ini tampaknya lebih sehat daripada "pihak yang salah" langsung menang, baik pihak yang salah adalah penyerang, atau klien memiliki bug.

Ini juga menjawab pertanyaan "apa gunanya staker individu". Saat ini, sebagian besar staker sudah staking melalui pool, dan tampaknya tidak mungkin staker individu dapat mencapai 51% dari ETH yang di-stake. Namun, jika kita berusaha, memungkinkan staker individu mencapai minoritas penghalang mayoritas, terutama jika mayoritas mencapai 80% (sehingga minoritas penghalang mayoritas hanya membutuhkan 21%) tampaknya mungkin dicapai. Selama staker individu tidak berpartisipasi dalam serangan 51% (baik itu pembalikan finalitas atau sensor), serangan semacam itu tidak akan mendapatkan "kemenangan bersih", dan staker individu akan secara aktif membantu mengorganisir soft fork minoritas.

Ketahanan terhadap Kuantum

Metaculus saat ini memperkirakan, meskipun dengan margin kesalahan besar, bahwa komputer kuantum kemungkinan akan mulai memecahkan kriptografi pada tahun 2030-an:

Pakar komputasi kuantum seperti Scott Aaronson, baru-baru ini juga mulai lebih serius mempertimbangkan kemungkinan komputer kuantum benar-benar berfungsi dalam jangka menengah. Ini berdampak pada seluruh roadmap Ethereum: ini berarti setiap bagian protokol Ethereum yang saat ini bergantung pada kurva eliptik membutuhkan alternatif berbasis hash atau ketahanan kuantum lainnya. Ini terutama berarti kita tidak bisa berasumsi bahwa kita akan selamanya dapat mengandalkan properti agregasi BLS yang luar biasa untuk menangani tanda tangan dari kumpulan validator besar. Ini membuktikan bahwa kehati-hatian dalam asumsi performa desain proof-of-stake adalah masuk akal, dan juga alasan untuk lebih aktif mengembangkan alternatif ketahanan kuantum.