Dokumen ini didorong oleh karya kami pada Spesifikasi konsensus FOCIL 23, di mana kami menyadari bahwa protokol ini membutuhkan pertimbangan yang lebih matang mengenai batasan sumber daya karena beberapa detail tidak secara eksplisit ditentukan dalam FOCIL pos penelitian Ethereum 14.

Persyaratan

Sebelum kita memulai, kami berasumsi pengaturan berikut untuk membangun dasar yang bersih untuk pertimbangan kami:

• Pengaturan ini didasarkan pada hard fork Electra. Juga masuk akal untuk meninjau ulang ini di atas EIP-7732 (ePBS) untuk perbandingan
• Kami berasumsi tentang membangun dan melepaskan blok solo, di mana pengusul tidak menjalankan MEV-Boost. Ini adalah komponen utama pertama yang harus benar, sementara Builder API adalah pertimbangan sekunder.
• Kami mengasumsikan pengaturan penambang tunggal dengan kebutuhan komputasi, memori, dan bandwidth yang tipikal yang dapat Anda ikuti dengan mudah pada rantai Ethereum saat ini

Aktor

Sebelum kita melanjutkan, kita mengasumsikan bahwa aktor-aktor berikut adalah bagian dari protokol dan menganalisis tanggung jawab mereka:

• Anggota komite Daftar Inklusi (IL), yang bertanggung jawab untuk membatasi pengusul slot berikutnya dengan kumpulan transaksi daftar inklusi
• Penyaji, yang bertanggung jawab untuk mengusulkan slot berikutnya
• Attesters, yang memberi kesaksian untuk slot berikutnya untuk kepala rantai
• Node, yang memverifikasi dan mengikuti rantai. Penyelenggara dan penguji adalah bagian dari node yang telah melakukan staking Ether

Timeline

Kami mengasumsikan timeline berikut di mana komite IL, pengusul, dan saksi melakukan beberapa tindakan jujur:

• Slot n-1, t=6: Komite IL menerbitkan Daftar Inklusi lokal (IL) mereka tentang topik global setelah mempelajari konten blok n-1
• Slot n-1, t=9: Attesters dan node verifikasi yang jujur mengunci pandangan mereka terhadap IL lokal
• Slot n, t=0: Penyarankan blok untuk slot n melepaskan blok B, yang mencakup muatan yang harus memenuhi persyaratan IL
• Slot n, t=4: Attesters untuk slot n memilih pada blok B, memverifikasi agregasi IL dengan membandingkannya dengan pandangan IL lokal mereka dan mengkonfirmasi apakah blok B adalah “valid”
  • Kita membebani kata 'valid' ketika merujuk pada blok, tetapi itu bisa berarti 'dapat diimpor,' 'kanonikal', atau sesuatu yang lain. Lihat pertanyaan terbuka untuk klarifikasi lebih lanjut

Interval 1: Komite IL Merilis IL Lokal

Aktor: Komite Daftar Inklusi

Anggota komite IL mengambil daftar transaksi IL dari klien EL yang diberikan kepala (panggilan CL → EL), kemudian mereka menandatangani IL lokal (transaksi + ringkasan) dan melepaskannya ke jaringan gosip.

Pertimbangan Sumber Daya

• Mengambil transaksi IL dari mempool EL → CPU/MEM
• Menandatangani daftar inklusi → CPU
• Mengunggah daftar inklusi ke jaringan gossip → Bandwidth (Unggah)

Aktor: Node (termasuk Pemeriksa)

Node yang mengikuti rantai akan mengunduh IL, memverifikasinya untuk anti-DOS (belum mengimpor ke EL), dan meneruskannya ke simpul lain. Node juga mengimpor IL ke pilihan fork dan melacak IL mana yang telah dilihat menggunakan cache aggreGate. Attester dan node yang mengikuti rantai harus memiliki pandangan yang sama tentang rantai.

Pertimbangan Sumber Daya

• Mengunduh IL → Bandwidth (Unduhan)
• Meneruskan IL → Bandwidth (Unggahan)
• Memverifikasi IL untuk anti-DOS → CPU/MEM
• Caching terlihat dan menggabungkan ILs → MEM

Aktor: Penyaji

Penyaji untuk slot berikutnya secara aktif memantau jaringan gosip IL, mengumpulkan dan mengumpulkan IL lokal, kemudian pada batas pengumpulan IL (interval #2) penyaji memperbarui proses pembangunan blok dengan daftar transaksi IL yang akan disertakan untuk bloknya. Ini memerlukan panggilan CL ke EL.

Pertimbangan Sumber Daya

• Mewarisi biaya yang sama seperti node-node yang mengikuti rantai

Kasus Ujung Penyaji

Jika proposer slot berikutnya mengamati jumlah daftar inklusi yang cukup berdasarkan hash induk yang belum pernah dilihat, proposer akan perlu meminta secara manual blok beacon yang hilang, mengimpor blok tersebut, dan membangun di atas blok tersebut.

Kesimpulan

Berdasarkan hal di atas, kita dapat mengidentifikasi area-area yang berpotensi memakan banyak sumber daya dan mempersempit fokus pada area tersebut:

• Dampak CPU Komite IL: pengambilan transaksi IL dari EL & penandatanganan: meskipun ada tuntutan sumber daya di sini, ini diasumsikan relatif murah dan bukan merupakan kekhawatiran utama.
• Dampak bandwidth node: Node yang mengunduh dan mengunggah IL mungkin menggunakan banyak bandwidth, terutama penelitian saat ini menyatakan bahwa ukuran daftar inklusi bersifat fleksibel/tidak terbatas. Hal ini menghadirkan risiko DOS potensial, karena anggota komite IL jahat dapat membanjiri jaringan dengan sejumlah transaksi besar, bahkan jika transaksi tersebut tidak valid. Node masih akan membicarakan IL sebelum mengimpor IL. Langkah-langkah Anti-DoS perlu dipertimbangkan dengan hati-hati.

Interval 2: Node mengunci tampilan mereka, pengimpor proposer transaksi IL

Aktor: Penyusun

Penyusun memperbarui proses pembangunan blok dengan daftar transaksi dalam daftar inklusi. Ini adalah panggilan CL → EL.

Pertimbangan Sumber Daya

• Memperbarui proses pembangunan blok dengan daftar transaksi daftar inklusi → CPU/MEM

Aktor: Node (termasuk Pemberi Bukti)

Tampilkan daftar inklusi kunci. Berhenti menerima daftar inklusi lokal mulai dari titik ini.

Pertimbangan Sumber Daya

• Tampilan daftar inklusi lokal terkunci → Tidak Ada

Kesimpulan

• Dampak CPU dari Proposer: Mengimpor transaksi IL ke dalam proses pembangunan blok dapat mengganggu proses pembangunan blok, yang dapat membebani CPU klien lapisan eksekusi selama simulasi transaksi. Hal ini dapat menjadi rumit dalam abstraksi akun karena transaksi dapat saling membatalkan. Hal ini perlu dianalisis lebih lanjut.

Interval 3: Pengusul Melepaskan Blok

Aktor: Pengusul

Pengusul mengambil muatan eksekusi dari klien EL (panggilan CL → EL), dan melepaskannya ke jaringan gossip blok beacon. Setelah itu, semua orang memverifikasi blok tersebut.

Pertimbangan Sumber Daya

• Mengambil muatan dari klien EL → CPU/MEM

Aktor: Nodes

Node menerima blok penanda dan memverifikasinya. Langkah verifikasi baru termasuk memeriksa konstruksi aggreGate daftar inklusi dan memastikan apakah daftar inklusi memenuhi fungsi evaluasi, yang akan diselesaikan di CL. Pemeriksaan kondisi IL (apakah mereka dapat dilewati karena konflik atau tidak) akan dilakukan di EL.

Pertimbangan Sumber Daya

• Memverifikasi bahwa daftar inklusi terpenuhi pada CL → CPU
• Memverifikasi kondisi daftar inklusi pada EL → CPU

Kesimpulan

Tugas tambahan untuk pengusul sepertinya tidak menjadi kekhawatiran yang signifikan. Langkah verifikasi baru untuk node - memeriksa dan memverifikasi bahwa daftar inklusi memenuhi kondisi yang memuaskan - mungkin memperkenalkan beban CPU tambahan, tetapi tidak tampak menjadi masalah utama.

Interval 4: Komite Attester

Aktor: Penguji

Pengesahkan memilih blok pancang menggunakan aturan pilihan fork LMD GHOST. Pengesahkan hanya akan memilih blok pancang yang memenuhi fungsi evaluasi daftar inklusi, berdasarkan pengamatan dari Interval 1.

Pertimbangan Sumber Daya

• Attesters memilih blok yang memenuhi fungsi evaluasi daftar inklusi → Tidak ada biaya tambahan

Kesimpulan

Tidak ada perbedaan dari hari ini.

Ringkasan Pertimbangan Sumber Daya

Seperti yang terlihat di atas, tantangan sumber daya yang paling signifikan berkaitan dengan unggahan daftar inklusi, unduhan, dan potensi spam dari perspektif node. Kekhawatiran utama lainnya adalah beban pada node untuk memverifikasi dan mengimpor daftar inklusi, serta kebutuhan proposer untuk memperbarui proses pembangunan bloknya untuk memenuhi daftar inklusi. Aspek-aspek ini membutuhkan pertimbangan dan desain yang hati-hati untuk memastikan efisiensi dan keamanan.

Pertanyaan Terbuka

Berdasarkan hal di atas, kami menguraikan beberapa pertanyaan terbuka yang akan mempengaruhi bagaimana spesifikasinya ditulis:

1. Blok Tidak Memenuhi Fungsi Evaluasi: Bagaimana seharusnya sebuah blok yang gagal dalam fungsi evaluasi daftar inklusi diatasi, dan pertimbangan desain apa yang masuk ke dalam kondisi tersebut?
   • Apakah itu harus diperlakukan secara serupa dengan blob dan tidak dapat diimpor?
   • Haruskah tidak difilter oleh pilihan fork?
   • Haruskah itu tidak valid dalam fungsi transisi keadaan?
2. Penyetaraan Daftar Inklusi: Jika anggota komite daftar inklusi mengirimkan versi daftar inklusi yang berbeda ke node yang berbeda, dan semuanya dipropaGasikan di seluruh jaringan, apa konsekuensi dari tindakan ini? Bagaimana perilaku seperti itu dapat berdampak negatif terhadap pengusul yang membangun blok berikutnya?
3. Proposer Sudah Membangun pada Head yang Berbeda: Jika proposer membangun pada head yang berbeda dari yang dikirim oleh komite daftar inklusi, dan dengan demikian perlu mengubah pandangannya, apa konsekuensi dari tindakan ini terhadap validitas blok dan perilaku proposer?
4. Invalidasi Transaksi Daftar Inklusi: Transaksi daftar inklusi lokal dapat dinvalisasi dengan beberapa cara. Meskipun transaksi ini dinvalisasi, blok masih harus dapat memenuhi fungsi evaluasi. Transaksi dapat dinvalisasi saat beberapa daftar inklusi bergabung satu sama lain atau dengan transaksi dalam blok. Selain pemeriksaan nonce yang khas, abstraksi akun memperkenalkan cara baru bagi transaksi untuk dinvalisasi, karena saldo dapat dikuras dengan nonce statis. Seberapa banyak simulasi tambahan yang dibutuhkan oleh pembangun blok karena invalidasi transaksi dan seberapa besar ini mempengaruhi komputasi CPU-nya masih harus dilihat baik untuk aktor MEV-Boost maupun pembangun lokal.
5. Pengamatan Pengusul terhadap Subnet Komite IL: Pengusul memantau subnet komite daftar inklusi untuk mengetahui kapan siap untuk membangun aggreGate. Ada dua pendekatan desain di sini, dan ada baiknya mempertimbangkannya lebih lanjut. Pendekatan pertama adalah pengusul serakah, di mana pengusul menunggu sampai t = 9, mengumpulkan IL sebanyak mungkin, mengirimkannya ke EL, dan EL memperbarui bloknya. Pendekatan kedua adalah pengusul selektif, di mana pengusul menunggu sampai memiliki daftar inklusi yang cukup untuk memenuhi fungsi eval, mengirimkannya ke EL, dan dapat melakukan ini dalam waktu kurang dari t = 9s atau bahkan lebih awal. Pertanyaannya adalah apakah pendekatan kedua membenarkan optimasi untuk memungkinkan pengusul merilis daftar inklusi aggreGate sebelumnya. Pendekatan kedua mungkin hanya cocok untuk IL dengan batas gas khusus sendiri.

Disclaimer：

1. Artikel ini dicetak ulang dari [ ethresear]. Semua hak cipta milik penulis asli [terence]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan pendapat yang diungkapkan 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.