Pada awalnya, “the Merge” merujuk pada peristiwa paling penting dalam sejarah protokol Ethereum sejak diluncurkan: transisi yang dinanti-nantikan dan sulit diraih dari proof of work ke proof of stake. Saat ini, Ethereum telah menjadi sistem proof of stake yang berjalan stabil selama hampir tepat dua tahun, dan proof of stake ini telah berjalan dengan sangat baik di stabilitas, kinerja dan menghindari risiko sentralisasiNamun, masih ada beberapa area penting di mana bukti kepemilikan perlu diperbaiki.

Diagram roadmap saya dari tahun 2023 memisahkan ini menjadi beberapa bagian: meningkatkan fitur teknis seperti stabilitas, kinerja, dan aksesibilitas ke validator yang lebih kecil, dan perubahan ekonomi untuk mengatasi risiko sentralisasi. Yang pertama mengambil alih judul untuk 'Penggabungan', dan yang terakhir menjadi bagian dari 'Bencana'.

The Merge, edisi roadmap 2023.

Pos ini akan difokuskan pada bagian “Gabung”: apa yang masih bisa diperbaiki dalam desain teknis bukti kepemilikan, dan apa saja jalur untuk mencapainya?

Ini bukan ditujukan sebagai daftar lengkap hal-hal yang bisa dilakukan untuk bukti kepemilikan; sebaliknya, ini adalah daftar ide-ide yang sedang aktif dipertimbangkan.

Merge: tujuan utama

• Finalitas slot tunggal
• Konfirmasi transaksi dan finalisasi secepat mungkin, sambil mempertahankan desentralisasi
• Meningkatkan kelayakan staking untuk staker solo
• Meningkatkan kekokohan
• Meningkatkan kemampuan Ethereum untuk melawan dan pulih dari serangan 51% (termasuk pembalikan finalitas, pemblokiran finalitas, dan sensorship)

Di bab ini

• Finalitas slot tunggal dan demokratisasi staking
• Pemilihan pemimpin rahasia tunggal
• Konfirmasi transaksi yang lebih cepat
• Area penelitian lainnya

Finalitas slot tunggal dan demokratisasi staking

Masalah apa yang sedang kita selesaikan?

Hari ini, dibutuhkan 2-3 zaman (~15 menit) untuk menyelesaikan blok, dan diperlukan 32 ETH untuk menjadi staker. Awalnya, ini adalah kompromi yang dimaksudkan untuk @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">keseimbangan antara tiga tujuan:

• Maksimalkan jumlah validator yang dapat berpartisipasi dalam staking (ini secara langsung mengimplikasikan meminimalkan ETH minimum yang diperlukan untuk staking)
• Meminimalkan waktu untuk finalisasi
• Meminimalkan biaya menjalankan node, dalam hal ini biaya mengunduh, memverifikasi, dan meneruskan ulang semua tanda tangan validator lainnya

Ketiga tujuan bertentangan: agar finalitas ekonomi menjadi mungkin (artinya: seorang penyerang harus membakar sejumlah besar ETH untuk mengembalikan blok yang telah difinalisasi), Anda memerlukan setiap validator untuk menandatangani dua pesan setiap kali finalitas terjadi. Jika Anda memiliki banyak validator, maka Anda memerlukan waktu lama untuk memproses semua tanda tangan mereka, atau Anda memerlukan node-node yang sangat kuat untuk memproses semua tanda tangan secara bersamaan.

Perhatikan bahwa semua ini bersyarat pada tujuan kunci Ethereum: memastikan bahwa serangan yang sukses pun memiliki biaya tinggi bagi pelaku serangan. Inilah yang dimaksud dengan istilah 'finalitas ekonomi'. Jika kita tidak memiliki tujuan ini, maka kita bisa memecahkan masalah ini dengan memilih secara acak sebuah komite untuk menyelesaikan setiap slot. Rantai yang tidak berusaha mencapai finalitas ekonomi, seperti Algorand,sering melakukan hal iniNamun, masalah dengan pendekatan ini adalah bahwa jika seorang penyerang mengendalikan 51% validator, maka mereka dapat melakukan serangan (mengembalikan blok yang difinalisasi, atau sensor, atau menunda finalitas) dengan biaya yang sangat rendah: hanya bagian dari node mereka yang ada di komite yang dapat terdeteksi sebagai berpartisipasi dalam serangan dan dikenai sanksi, baik melaluipemotonganataufork lunak yang dikoordinasikan secara sosialIni berarti bahwa seorang penyerang dapat secara berulang kali menyerang rantai berkali-kali, kehilangan hanya sebagian kecil dari taruhan mereka selama setiap serangan. Oleh karena itu, jika kita ingin kepastian ekonomi, pendekatan berbasis komite yang naif tidak akan berhasil, dan tampaknya pada pandangan pertama bahwa kita membutuhkan seluruh set validator untuk berpartisipasi.

Idealnya, kita ingin mempertahankan finalitas ekonomi, sambil secara bersamaan meningkatkan status quo di dua area:

1. Menyelesaikan blok dalam satu slot (idealnya, menjaga atau bahkan mengurangi panjang saat ini 12s), bukan 15 menit
2. Memungkinkan validator untuk melakukan staking dengan 1 ETH (turun dari 32 ETH)

Tujuan pertama dibenarkan oleh dua tujuan, yang keduanya dapat dianggap sebagai “membawa properti Ethereum sejalan dengan properti rantai L1 berorientasi kinerja (lebih terpusat)”.

Pertama, itu memastikan bahwa semua pengguna Ethereum benar-benar mendapatkan manfaat dari tingkat kepastian keamanan yang dicapai melalui mekanisme finalitas. Hari ini, sebagian besar pengguna tidak melakukannya, karena mereka tidak mau menunggu 15 menit; dengan finalitas slot tunggal, pengguna akan melihat transaksi mereka selesai hampir segera setelah dikonfirmasi. Kedua, itu menyederhanakan protokol dan infrastruktur sekitarnya jika pengguna dan aplikasi tidak perlu khawatir tentang kemungkinan rantai mengalami pembalikan kecuali dalam kasus yang relatif jarang terjadi.kebocoran ketidakaktifan.

Tujuan kedua dibenarkan oleh keinginan untuk mendukung penambang tunggal. Jajak pendapat setelah jajak pendapat secara berulang kali menunjukkan bahwa faktor utama yang mencegah lebih banyak orang untuk melakukan penambangan tunggal adalah minimum 32 ETH. Mengurangi minimum menjadi 1 ETH akan menyelesaikan masalah ini, sampai pada titik di mana kekhawatiran lain menjadi faktor dominan yang membatasi penambangan tunggal.

Terdapat tantangan: tujuan kecepatan finalitas yang lebih cepat dan staking yang lebih terdemokratisasi sama-sama bertentangan dengan tujuan meminimalkan overhead. Dan memang, faktanya inilah alasan utama mengapa kita tidak memulai dengan finalitas satu slot dari awal. Namun, penelitian lebih baru menyajikan beberapa kemungkinan jalan keluar dari masalah tersebut.

Apa itu dan bagaimana cara kerjanya?

Finalitas satu slot melibatkan menggunakan algoritma konsensus yang menyelesaikan blok dalam satu slot. Ini sendiri bukanlah tujuan yang sulit: banyak algoritma, seperti konsensus Tendermint, sudah melakukannya dengan properti optimal. Salah satu properti yang diinginkan yang unik untuk Ethereum, yang tidak didukung oleh Tendermint, adalahkebocoran ketidakaktifan, yang memungkinkan rantai tetap berjalan dan akhirnya pulih bahkan ketika lebih dari 1/3 validator offline. Untungnya, keinginan ini sudah terpenuhi: ada Sudah Proposalyang memodifikasi konsensus gaya Tendermint untuk menyesuaikan kebocoran ketidakaktifan.

Sebuah proposal finalitas slot tunggal terkemuka

Bagian yang lebih sulit dari masalah ini adalah mencari tahu bagaimana membuat finalitas satu slot berfungsi dengan jumlah validator yang sangat tinggi, tanpa menyebabkan overhead operator node yang sangat tinggi. Untuk ini, ada beberapa solusi terkemuka:

• Pilihan 1: Brute force - bekerja keras dalam mengimplementasikan protokol agregasi tanda tangan yang lebih baik, dengan potensi menggunakan ZK-SNARKs, yang sebenarnya akan memungkinkan kami untuk memproses tanda tangan dari jutaan validator dalam setiap slot.

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

• Opsi 2: Komite Orbit- mekanisme baru yang memungkinkan sebuah komite berukuran sedang yang dipilih secara acak bertanggung jawab untuk menyelesaikan rantai, namun dengan cara yang menjaga properti biaya-serangan yang kami cari.

  Salah satu cara untuk memikirkan Orbit SSF adalah bahwa itu membuka ruang opsi kompromi sepanjang spektrum 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 sangat aman, tetapi pada saat yang sama kita mendapatkan manfaat efisiensi dari hanya memerlukan sampel acak berukuran sedang dari validator untuk berpartisipasi dalam setiap slot.

Orbit memanfaatkan perbedaan ukuran deposit validator yang sudah ada untuk mendapatkan sebanyak mungkin finalitas ekonomi yang mungkin, sambil tetap memberikan peran proporsional kepada validator kecil. Selain itu, Orbit menggunakan rotasi komite yang lambat untuk memastikan tumpang tindih tinggi antara kuorum-kuorum yang berdekatan, memastikan bahwa finalitas ekonominya masih berlaku di batas pergantian komite.

• Opsi 3: penyetoran dua tingkat - mekanisme di mana ada dua kelas staker, satu dengan persyaratan deposit yang lebih tinggi dan satu dengan persyaratan deposit yang lebih rendah. Hanya tingkat deposit yang lebih tinggi yang akan terlibat langsung dalam memberikan finalitas ekonomi. Ada berbagai proposal (mis. lihat posting staking Rainbow) untuk persisnya hak dan tanggung jawab apa yang dimiliki oleh tingkat deposit yang lebih rendah. Ide-ide umum termasuk:
  • hak untuk mendelekasikan staking ke staker tingkat lebih tinggi
  • sejumlah contoh acak staker tingkat bawah yang bersaksi, dan diperlukan untuk menyelesaikan setiap blok
  • hak untuk menghasilkan daftar inklusi

Apa beberapa tautan ke penelitian yang ada?

• Jalur menuju finalitas slot tunggal (2022): @vbuterin/single_slot_finality"">https://notes.ethereum.org/@vbuterin/single_slot_finality
• Sebuah proposal konkret untuk protokol finalitas slot tunggal untuk Ethereum (2023): https://eprint.iacr.org/2023/280
• Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
• Analisis lebih lanjut tentang mekanisme gaya Orbit: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464
• Horn, protokol agregasi tanda tangan (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
• Penggabungan tanda tangan untuk konsensus berskala besar (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
• Protokol agregasi tanda tangan yang diusulkan oleh Khovratovich dkk: @7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/"">https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
• Agregasi tanda tangan berbasis STARK (2022): @vbuterin/stark_aggregation"">https://hackmd.io/@vbuterin/stark_aggregation
• Staking pelangi: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

Apa yang harus dilakukan, dan apa saja kompromi yang harus dibuat?

Ada empat kemungkinan jalur utama yang dapat diambil (dan kita juga dapat mengambil jalur hibrida):

1. Menjaga status quo
2. Brute-force SSF
3. Orbit SSF
4. SSF dengan staking dua tingkat

(1) berarti tidak melakukan pekerjaan dan meninggalkan penstakan apa adanya, tetapi itu membuat pengalaman keamanan Ethereum dan sifat sentralisasi penstakan menjadi lebih buruk dari yang seharusnya.

(2) secara paksa masalah ini dengan teknologi tinggi. Membuat ini terjadi memerlukan pengumpulan sejumlah besar tanda tangan (1 juta+) dalam waktu yang sangat singkat (5-10 detik). Salah satu cara untuk memahami pendekatan ini adalah bahwa itu melibatkanmeminimalkan kompleksitas sistemik dengan mengadopsi kompleksitas terenkapsulasi secara penuh

(3) menghindari “high tech”, dan memecahkan masalah dengan pemikiran ulang yang cerdik seputar asumsi protokol: kita mengendurkan kebutuhan akan “finalitas ekonomi” sehingga kita memerlukan serangan untuk mahal, tetapi tidak masalah jika biaya serangan mungkin 10x lebih rendah dari sekarang (misalnya biaya serangan $2,5 miliar daripada $25 miliar). Pandangan umum adalah bahwa Ethereum saat ini memiliki finalitas ekonomi yang jauh lebih banyak dari yang diperlukan, dan risiko keamanan utamanya berada di tempat lain, dan oleh karena itu ini bisa dikatakan sebagai pengorbanan yang dapat diterima.

Pekerjaan utama yang harus dilakukan adalah memverifikasi bahwa mekanisme Orbit aman dan memiliki properti yang kita inginkan, dan kemudian sepenuhnya memformalkan dan mengimplementasikannya. Selain itu, EIP-7251 (meningkatkan maksimum saldo efektif)memungkinkan konsolidasi saldo validator sukarela yang segera mengurangi beban verifikasi rantai agak, dan bertindak sebagai tahap awal yang efektif untuk peluncuran Orbit.

(4) menghindari pemikiran pintar dan teknologi tinggi, namun menciptakan sistem staking dua tingkat yang masih memiliki risiko sentralisasi. Risiko tersebut sangat bergantung pada hak-hak spesifik yang diperoleh dari tingkat staking yang lebih rendah. Sebagai contoh:

• Jika staker tingkat rendah perlu mendelagasikan hak-hak pengesahan mereka kepada staker tingkat tinggi, maka delegasi bisa sentralisasi dan akhirnya kita akan memiliki dua tingkat staking yang sangat terpusat.
• Jika sampel acak dari tier bawah diperlukan untuk menyetujui setiap blok, maka seorang penyerang bisa menghabiskan jumlah ETH yang sangat kecil untuk menghalangi finalitas.
• Jika para stakers tingkat rendah hanya dapat membuat daftar inklusi, maka lapisan saksi mungkin tetap terpusat, di mana pada titik tersebut serangan 51% terhadap lapisan saksi dapat menyensor daftar inklusi itu sendiri.

Beberapa strategi dapat digabungkan, misalnya:

(1 + 2): gunakan teknik kekerasan untuk mengurangi ukuran deposit minimum tanpa melakukan finalitas slot tunggal. Jumlah agregasi yang diperlukan 64x lebih sedikit daripada kasus (3) murni, sehingga masalahnya menjadi lebih mudah.

(1 + 3): tambahkan Orbit tanpa melakukan finalitas slot tunggal

(2 + 3): lakukan Orbit SSF dengan parameter konservatif (misalnya, komite validator 128k alih-alih 8k atau 32k), dan gunakan teknik brute-force untuk membuatnya sangat efisien.

(1 + 4): tambahkan staking pelangi tanpa melakukan finalitas slot tunggal

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

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

Strategi kekerasan memiliki kelemahan bahwa mereka membuat lebih sulit untuk mengurangi waktu slot.

Pemilihan pemimpin rahasia tunggal

Masalah apa yang sedang kita selesaikan?

Hari ini, validator mana yang akan mengajukan blok berikutnya sudah diketahui sebelumnya. Hal ini menciptakan kerentanan keamanan: seorang penyerang dapat memantau jaringan, mengidentifikasi validator mana yang sesuai dengan alamat IP mana, dan melakukan serangan DoS pada setiap validator tepat saat mereka akan mengajukan blok.

Apa itu dan bagaimana cara kerjanya?

Cara terbaik untuk memperbaiki masalah DoS adalah dengan menyembunyikan informasi tentang validator mana yang akan memproduksi blok berikutnya, setidaknya hingga saat blok benar-benar diproduksi. Perhatikan bahwa ini mudah jika kita menghapus persyaratan “tunggal”: satu solusiadalah memungkinkan siapa pun membuat blok berikutnya, tetapi memerlukan Randao mengungkapkan menjadi kurang dari 2256 / N. Rata-rata, hanya satu validator yang dapat memenuhi persyaratan ini - tetapi terkadang ada dua atau lebih dan terkadang nol. Menggabungkan persyaratan "kerahasiaan" dengan persyaratan "tunggal" telah lama menjadi masalah yang sulit.

Protokol pemilihan pemimpin rahasia tunggal menyelesaikan ini dengan menggunakan beberapa teknik kriptografi untuk membuat ID validator "buta" untuk setiap validator, dan kemudian memberi banyak pengusul kesempatan untuk mengacak-dan-membutakan kembali kumpulan ID yang dibutakan (ini mirip dengan bagaimana mixnetselama setiap slot, ID terblinded acak dipilih. Hanya pemilik ID terblinded tersebut yang dapat menghasilkan bukti valid untuk mengusulkan blok, tetapi tidak ada yang tahu validator mana yang sesuai dengan ID terblinded tersebut.

Protokol SSLE Whisk

Apa beberapa tautan ke penelitian yang sudah ada?

• Paper oleh Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
• Whisk (proposal konkret untuk Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
• Tag pemilihan pemimpin rahasia tunggal di ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
• SSLE disederhanakan menggunakan tanda tangan lingkaran: https://ethresear.ch/t/simplified-ssle/12315

Apa yang harus dilakukan, dan apa saja tradeoffsnya?

Secara realistis, yang tersisa adalah menemukan dan mengimplementasikan protokol yang cukup sederhana sehingga kami nyaman mengimplementasikannya di mainnet. Kami sangat menghargai Ethereum sebagai protokol yang cukup sederhana, dan kami tidak ingin kompleksitas meningkat lebih jauh. Implementasi SSLE yang kami lihat menambah ratusan baris kode spesifikasi, dan memperkenalkan asumsi baru dalam kriptografi yang rumit. Menemukan implementasi SSLE yang cukup efisien dan tahan terhadap kuantum juga merupakan masalah terbuka.

Mungkin akan terjadi kasus di mana kompleksitas tambahan yang diperkenalkan oleh SSLE hanya turun cukup setelah kita mengambil langkah dan memperkenalkan mesin untuk melakukan bukti pengetahuan nol tujuan umum ke dalam protokol Ethereum di L1 untuk alasan lain (mis. pohon keadaan, ZK-EVM).

Salah satu opsi alternatif adalah dengan tidak mempermasalahkan SSLE, dan menggunakan mitigasi di luar protokol (misalnya di lapisan p2p) untuk menyelesaikan masalah DoS.

Bagaimana cara kerjanya dengan bagian lain dari peta jalan?

Jika kita menambahkan mekanisme pemisahan atester-penjuru (APS), misalnya. Tiket Eksekusi, maka blok eksekusi (yaitu blok yang berisi transaksi Ethereum) tidak akan memerlukan SSLE, karena kita bisa mengandalkan pembangun blok yang berspesialisasi. Namun, kita masih akan mendapatkan manfaat dari SSLE untuk blok konsensus (yaitu blok yang berisi pesan protokol seperti bukti, mungkin potongan-potongan daftar inklusi, dll).

Konfirmasi transaksi lebih cepat

Masalah apa yang sedang kita selesaikan?

Ada nilai dalam Ethereum’s waktu konfirmasi transaksi semakin berkurang, dari 12 detik turun ke contohnya 4 detik. Melakukan hal ini akan secara signifikan meningkatkan pengalaman pengguna dari kedua L1 dan rollups berbasis, sambil membuat protokol defi lebih efisien. Hal ini juga akan memudahkan L2s untuk mendekentralisasi, karena akan memungkinkan sejumlah besar aplikasi L2 untuk bekerja pada berbasis rollups, mengurangi permintaan untuk L2 membangun urutan desentralisasi berbasis komite mereka sendiri.

Apa itu dan bagaimana cara kerjanya?

Ada secara umum dua keluarga teknik di sini:

1. Mengurangi waktu slot, hingga contohnya. 8 detikatau 4 detik. Ini tidak harus berarti penyelesaian dalam 4 detik: penyelesaian secara inheren memerlukan tiga putaran komunikasi, sehingga kita dapat membuat setiap putaran komunikasi menjadi blok terpisah, yang setelah 4 detik setidaknya akan mendapatkan konfirmasi awal.
2. Izinkan pengusul untuk mempublikasikan pra-konfirmasi selama slot. Secara ekstrem, pengusul dapat memasukkan transaksi yang mereka lihat ke dalam blok mereka secara real time, dan segera mempublikasikan pesan pra-konfirmasi untuk setiap transaksi ("Transaksi pertama saya adalah 0×1234 ...", "Transaksi kedua saya adalah 0×5678 ..."). Kasus pengusul menerbitkan dua konfirmasi yang bertentangan dapat ditangani dengan dua cara: (i) dengan memotong pengusul, atau (ii) dengan menggunakan penguji untuk memilih mana yang datang lebih awal.

Apa beberapa tautan ke penelitian yang ada?

• Berdasarkan pra-konfirmasi: https://ethresear.ch/t/based-preconfirmations/17353
• Komitmen proposer yang ditegakkan protokol (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protokol-enforced-proposer-commitments-pepc/13879
• Periode yang berselang di sepanjang rantai paralel (ide zaman 2018 untuk mencapai latensi rendah):https://ethresear.ch/t/staggered-periods/1793

Apa yang perlu dilakukan, dan apa yang harus dikorbankan?

Jauh dari jelas betapa praktisnya untuk mengurangi slot times. Bahkan saat ini, para staker di banyak wilayah dunia mengalami kesulitan mendapatkan attestasi yang dimasukkan dengan cepat. Mencoba slot times 4 detik berisiko mengcentralisasi set validator, dan membuatnya tidak praktis untuk menjadi validator di luar beberapa geografi yang beruntung karena laten. Secara khusus, beralih ke slot times 4 detik akan memerlukan pengurangan batas laten jaringan ("delta") menjadi dua detik.

Pendekatan proposer pra-konfirmasi memiliki kelemahan bahwa itu dapat sangat meningkatkan waktu inklusi kasus rata-rata, tetapi tidak kasus terburuk: jika proposer saat ini berfungsi dengan baik, transaksi Anda akan dikonfirmasi sebelumnya dalam 0,5 detik daripada dimasukkan dalam (rata-rata) 6 detik, tetapi jika proposer saat ini offline atau tidak berfungsi dengan baik, Anda masih harus menunggu hingga 12 detik penuh untuk slot berikutnya untuk dimulai dan menyediakan proposer baru.

Selain itu, ada pertanyaan terbuka tentang bagaimana pra-konfirmasi akan diberi insentif. Pengusul memiliki insentif untuk memaksimalkan opsionalitas mereka selama mungkin. Jika attester menandatangani ketepatan waktu pra-konfirmasi, maka pengirim transaksi dapat membuat sebagian dari biaya tergantung pada pra-konfirmasi langsung, tetapi ini akan memberi beban ekstra pada attester, dan berpotensi mempersulit attester untuk terus berfungsi sebagai "pipa bodoh" netral.

Di sisi lain, jika kita tidak mencoba ini dan menjaga waktu finalitas pada 12 detik (atau lebih lama), ekosistem akan memberikan bobot yang lebih besar pada mekanisme pra-konfirmasi yang dibuat oleh layer 2, dan interaksi lintas-layer-2 akan memakan waktu lebih lama.

Bagaimana cara interaksi dengan bagian lain dari peta jalan?

Prekonfirmasi berbasis proposer secara realistis bergantung pada mekanisme pemisahan attester-proposer (APS), misalnya.tiket eksekusi. Jika tidak, tekanan untuk memberikan pra-konfirmasi real-time mungkin terlalu sentralisasi bagi validator reguler.

Tepatnya seberapa singkat waktu slot dapat juga tergantung pada struktur slot, yang sangat tergantung pada versi-versi APS, daftar inklusi, dll yang kami implementasikan. Ada struktur slot yang berisi lebih sedikit putaran dan oleh karena itu lebih ramah terhadap waktu slot singkat, tetapi mereka membuat kompromi di tempat lain.

Area riset lainnya

pemulihan serangan 51%

Seringkali diasumsikan bahwa jika terjadi serangan 51% (termasuk serangan yang tidak dapat dibuktikan secara kriptografis, seperti sensor), komunitas akan bersatu untuk melaksanakan fork lunak minoritasyang memastikan pihak baik menang, dan pihak buruk menjadi tidak aktif atau dipotong. Namun, tingkat ketergantungan yang berlebihan pada lapisan sosial ini bisa dikatakan tidak sehat. Kita dapat mencoba mengurangi ketergantungan pada lapisan sosial, dengan membuat proses pemulihan sesederhana mungkin.

Automasi penuh tidak mungkin, karena jika itu terjadi, itu akan dihitung sebagai algoritma konsensus yang toleran kesalahan >50%, dan kita sudah tahu (sangat membatasi)keterbatasan matematis dari jenis algoritma tersebutNamun kita dapat mencapai otomatisasi parsial: misalnya, seorang klien dapat secara otomatis menolak untuk menerima rantai sebagai final, atau bahkan sebagai kepala pilihan garpu, jika itu sensor transaksi yang telah lama dilihat klien. Salah satu tujuan utamanya adalah memastikan bahwa pihak jahat dalam serangan setidaknya tidak dapat dengan cepat meraih kemenangan bersih.

Meningkatkan ambang kuorum

Hari ini, sebuah blok selesai jika 67% staker mendukungnya. Ada argumen bahwa ini terlalu agresif. Hanya ada satu kegagalan finalitas (sangat singkat) dalam semua sejarah Ethereum. Jika persentase ini meningkat, misalnya. hingga 80%, maka jumlah tambahan periode non-finalitas akan relatif rendah, tetapi Ethereum akan mendapatkan properti keamanan: khususnya, banyak situasi yang lebih kontroversial akan mengakibatkan penghentian finalitas sementara. Ini tampaknya situasi yang jauh lebih sehat daripada "pihak yang salah" mendapatkan kemenangan instan, baik ketika pihak yang salah adalah penyerang, dan ketika itu adalah klien yang memiliki bug.

Ini juga memberikan jawaban atas pertanyaan 'apa tujuan dari penambang tunggal'? Saat ini, sebagian besar penambang sudah menambang melalui kolam, dan tampaknya sangat tidak mungkin untuk mendapatkan penambang tunggal hingga 51% dari ETH yang dipertaruhkan. Namun, mendapatkan penambang tunggal hingga menjadi minoritas pemblokiran kuorum, terutama jika kuorumnya adalah 80% (sehingga minoritas pemblokiran kuorum hanya membutuhkan 21%), tampaknya potensial tercapai jika kita bekerja keras. Selama penambang tunggal tidak ikut dalam serangan 51% (baik reversion finality maupun sensorship), serangan tersebut tidak akan mendapatkan 'kemenangan bersih', dan penambang tunggal akan termotivasi untuk membantu mengorganisir fork lunak minoritas.

Perhatikan bahwa ada interaksi antara ambang kuorum dan mekanisme Orbit: jika kita akhirnya menggunakan Orbit, maka apa arti tepat dari "21% dari para pemegang saham" akan menjadi pertanyaan yang lebih rumit, dan akan bergantung sebagian pada distribusi validator.

Quantum-resistance

Metaculus saat ini percaya, meskipun dengan bilah kesalahan yang lebar, komputer kuantum itu kemungkinan akan mulai memecahkan kriptografi beberapa waktu di tahun 2030-an:

Para ahli komputasi kuantum seperti Scott Aaronson juga baru-baru ini mulai mempertimbangkan kemungkinan komputer kuantum benar-benar berfungsi dalam jangka menengahjauh lebih serius. Hal ini memiliki konsekuensi di sepanjang seluruh peta jalan Ethereum: ini berarti bahwa setiap bagian dari protokol Ethereum yang saat ini bergantung pada kurva eliptis akan perlu memiliki pengganti yang tahan terhadap kuantum berbasis hash atau lainnya. Ini terutama berarti bahwa kita tidak bisa mengasumsikan bahwa kita akan dapat bergantung padasifat-sifat unggul dari agregasi BLSuntuk memproses tanda tangan dari set validator besar selamanya. Hal ini membenarkan konservatisme dalam asumsi seputar kinerja desain proof-of-stake, dan juga merupakan alasan untuk lebih proaktif dalam mengembangkan alternatif yang tahan terhadap kuantum.

Penafian:

1. Artikel ini dicetak ulang dari [Vitalik Buterin], Semua hak cipta milik penulis asli [Vitalik Buterin]. Jika ada keberatan terhadap cetakan ulang ini, harap hubungi Belajar Gatetim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.