เอกสารนี้ได้รับแรงบันดาลใจมาจากงานของเราที่เกี่ยวกับ FOCIL ความเห็นสังสัย 23, ที่นี่เรารู้สึกว่าโปรโตคอลต้องการความพิจารณาอย่างรอบคอบมากขึ้นเกี่ยวกับข้อจำกัดทรัพยากรเนื่องจากรายละเอียดบางประการยังไม่ได้ระบุโดยชัดเจนในโพสต์การวิจัย FOCIL Ethereum 14.

Prerequisite

ก่อนที่เราจะเริ่มต้น เราสมมติว่ามีการติดตั้งตามนี้เพื่อกำหนดสภาพเบื้องต้นที่สะอาดสำหรับการพิจารณาของเรา:

• การติดตั้งขึ้นอยู่กับการแยกฮาร์ดโฟร์คของ Electra นอกจากนี้ยังเหมาะสมที่จะทบทวนการทำงานนี้บน EIP-7732 (ePBS) เพื่อเปรียบเทียบ
• เรากำลังสมมติการสร้างบล็อกโดยเดี่ยวและปล่อยตัวออกมา ที่นี่ผู้เสนอไม่ได้เริ่ม MEV-Boost นี่เป็นส่วนประกอบสำคัญที่สุดในการทำถูก ในขณะที่ Builder API เป็นความพิจารณารอง
• เรากำลังสมมติว่าคุณเป็นผู้เสนอแนะเดี่ยวที่มีความต้องการในการคำนวณทั่วไป เป็นเหมือนเชื่อมต่อกับเครือข่าย Ethereum ในปัจจุบัน

นักแสดง

ก่อนที่เราจะดำเนินการต่อ เราสมมติว่าผู้กระทำต่อไปนี้เป็นส่วนหนึ่งของโปรโตคอลและวิเคราะห์ความรับผิดชอบของพวกเขา:

• คณะกรรมการรายการสมาชิก (IL) ผู้รับผิดชอบในการจำกัดผู้เสนอช่องต่อไปด้วยชุดของธุรกรรมในรายการการรวม
• ผู้เสนอข้อเสนอที่รับผิดชอบในการเสนอช่องต่อไป
• ผู้รับรองที่กำลังรับรองสำหรับสล็อตถัดไปสำหรับหัวของโซ่
• Nodes, ซึ่งกำลังตรวจสอบและติดตามโซ่ ผู้เสนอและผู้รับรองเป็นส่วนหนึ่งของโหนดที่มีเอเธอร์ที่ถูกพนัน

ไทม์ไลน์

เราสมมติกาว่าในไทม์ไลน์ต่อไปนี้ คณะกรรมการ IL ผู้เสนอแนะ และผู้รับรองทำการกระทำบางอย่างอย่างซื่อสัตย์:

• Slot n-1, t=6: คณะกรรมการ IL ตีพิมพ์รายการรวมท้องถิ่น (ILs) ของพวกเขาเกี่ยวกับเรื่องสากลหลังจากที่เรียนรู้เนื้อหาของบล็อก n-1
• Slot n-1, t=9: ผู้ตรวจสอบและโหนดการยืนยันที่ซื่อสัตย์ล็อคในมุมมองของ ILs ท้องถิ่นของพวกเขา
• ช่อง n, t=0: ผู้เสนอบล็อกสำหรับช่อง n ปล่อยบล็อก B ที่รวมพลังงานที่ควรตรงตามข้อกำหนดของ IL
• Slot n, t=4: Attesters for slot n vote on block B, verifying the IL aggregation by comparing it to their local IL views and confirming whether block B is “valid”
  • เราโอเวอร์โหลดคำว่า "ถูกต้อง" เมื่ออ้างถึงบล็อก แต่มันอาจหมายถึง "สามารถนำเข้าได้" "ที่สำคัญ" หรือบางสิ่งอื่น ๆ ดูคำถามที่เปิดเพื่อความชัดเจนเพิ่มเติม

ช่วงเวลา 1: คณะกรรมการ IL ปล่อย IL ท้องถิ่น

นักแสดง: คณะกรรมการรายชื่อความร่วมมือ

สมาชิกคณะกรรมการ IL ดึงรายการธุรกรรม IL จาก EL ไคลเอนต์โดยใช้หัว (การโทร CL → EL) จากนั้นพวกเขาเซ็นรับรอง IL ท้องถิ่น (ธุรกรรม + สรุป) และปล่อยให้เข้าสู่เครือข่ายการสะท้อนกัน

การพิจารณาทรัพยากร

• การดึงธุรกรรม IL จาก mempool EL → CPU/MEM
• เซ็นรายการรวม → CPU
• Uploading the inclusion list to the gossip network → Bandwidth (Upload)

นักแสดง: โหนด (รวมถึง Attesters)

โหนดที่ติดตามโซ่จะดาวน์โหลด IL ตรวจสอบมันเพื่อต่อต้าน DOS (ไม่นำเข้าไปยัง EL โดยอันที่จริง) และส่งต่อไปยังเพื่อนร่วมทางอื่น ๆ โหนดยังนำ IL เข้าสู่การเลือกคำแข้งและติดตาม IL ที่เห็นได้โดยใช้แคช AggreGate ผู้รับรองและโหนดที่ติดตามโซ่ควรมีมุมมองเดียวกันของโซ่

การพิจารณาทรัพยากร

• ดาวน์โหลด IL → แบนด์วิท (ดาวน์โหลด)
• การส่ง IL → แบนด์วิดธ์ (อัปโหลด)
• การตรวจสอบ IL สำหรับการป้องกัน DOS → CPU/MEM
• การแคชเห็นและการรวมกลุ่ม ILs → MEM

นักแสดง: ผู้เสนอ

ผู้เสนอแนวคิดสำหรับสล็อตถัดไปรับบทบาทในการตรวจสอบเครือข่าย IL และเก็บรวบรวม IL ในระดับท้องถิ่น จากนั้นในช่วงเวลา IL การรวมรายการ (ระยะ #2) ผู้เสนอแนวคิดจะอัปเดตกระบวนการสร้างบล็อกด้วยรายการธุรกรรม IL เพื่อรวมในบล็อกของตน สิ่งนี้ต้องการการเรียกใช้จาก CL ถึง EL

การพิจารณาทรัพยากร

• สืบทอดค่าใช้จ่ายเดียวกันกับโหนดที่ตามโซ่

เคสของผู้เสนอ

หากผู้เสนอช่องถัดไปสังเกตเห็นจำนวนเพียงพอของรายการการรวมตามคำสั่งหลักที่ไม่เคยเห็น ผู้เสนอจะต้องขอบล็อกบีคอนที่ขาดหายอย่างดำเนินการด้วยตนเอง นำเข้าบล็อกและสร้างบนบล็อกนั้น

สรุป

จากข้อมูลข้างต้นเราสามารถระบุพื้นที่ที่ใช้ทรัพยากรมากและ จํากัด ให้แคบลง:

• ผลกระทบของ CPU จาก IL Committee: การเรียกดูธุรกรรม IL จาก EL และการเซ็นลายเซ็น: แม้ว่าจะมีความต้องการทรัพยากรที่นี่ แต่คาดว่าจะไม่แพงมากและไม่เป็นปัญหาใหญ่
• ผลกระทบแบนด์วิดธ์ของโหนด: โหนดที่ดาวน์โหลดและอัปโหลด ILs อาจใช้แบนด์วิดท์จํานวนมากโดยเฉพาะอย่างยิ่งโพสต์การวิจัยในปัจจุบันระบุว่าขนาดรายการรวมมีความยืดหยุ่น / ไม่มีขอบเขต สิ่งนี้ทําให้เกิดความเสี่ยง DOS ที่อาจเกิดขึ้นเนื่องจากสมาชิกคณะกรรมการ IL ที่เป็นอันตรายอาจทําให้เครือข่ายมีธุรกรรมจํานวนมากแม้ว่าจะไม่ถูกต้องก็ตาม โหนดจะยังคงนินทาเกี่ยวกับ IL ก่อนที่จะนําเข้า ILs มาตรการต่อต้าน DoS จําเป็นต้องได้รับการพิจารณาอย่างรอบคอบ

ช่วง 2: โหนดล็อกมุมมองของพวกเขา, ผู้เสนอนำเข้าธุรกรรม IL

นักแสดง: ผู้เสนอ

ผู้เสนออัปเดตกระบวนการสร้างบล็อกด้วยรายการธุรกรรมรายการการรวม นี่คือการเรียก CL → EL

การพิจารณาทรัพยากร

• อัปเดตกระบวนการสร้างบล็อกด้วยรายการธุรกรรมในรายการรวม → CPU/MEM

นักแสดง: โหนด (รวมถึงผู้รับรอง)

มุมมองรายการการรวมล็อก หยุดการยอมรับรายการการรวมท้องถิ่นตั้งแต่จุดนี้

ประเมินการใช้ทรัพยากร

• มุมมองรายการการรวมท้องถิ่น → ไม่มี

สรุป

• ผลกระทบของ CPU ของผู้เสนอ: การนำเข้าธุรกรรม IL เข้าสู่กระบวนการสร้างบล็อกอาจทำให้กระบวนการสร้างบล็อกถูกขัดขวาง ซึ่งอาจทำให้ CPU ของไคลเอ็นต์ชั้นการปฏิบัติงานถูกเครื่องมือในการจำลองธุรกรรม สภาพนี้อาจกลายเป็นซับซ้อนเมื่อมีการสรุปบัญชีเนื่องจากธุรกรรมอาจทำให้ยกเลิกกันได้ ควรวิเคราะห์เพิ่มเติม

ช่วงเวลาที่ 3: ผู้เสนอแบล็กเปิดตัว

นักแสดง: ผู้เสนอ

ผู้เสนอดึงข้อมูลการปฏิบัติงานจากไคลเอ็นต์ (CL → การโทร EL) และปล่อยมันไปยังเครือข่ายการเส่นข่ายบีคอน ทุกคนจึงทำการตรวจสอบบล็อก

การพิจารณาทรัพยากร

• การเรียกรับ payload จาก EL client → CPU/MEM

นักแสดง: โหนด

โหนดจะได้รับบล็อก Beacon และทำการตรวจสอบ ขั้นตอนการตรวจสอบใหม่รวมถึงการตรวจสอบการสร้างรายการการรวมข้อมูลและการยืนยันว่ารายการการรวมข้อมูลทำให้ฟังก์ชันการประเมินมีความสมบูรณ์ซึ่งจะเสร็จสิ้นบน CL การตรวจสอบเงื่อนไข IL (ว่าสามารถข้ามได้เนื่องจากความขัดแย้งหรือไม่) จะถูกดำเนินการบน EL

ข้อควรพิจารณาเกี่ยวกับทรัพยากร

• การตรวจสอบว่ารายการการรวมถูกพอใจบน CL → CPU
• การตรวจสอบเงื่อนไขการรวมลิสต์บน EL → CPU

สรุป

หน้าที่เพิ่มเติมสำหรับผู้เสนอไม่ใช่ปัญหาที่สำคัญ ขั้นตอนการยืนยันข้อมูลใหม่สำหรับโหนด - การตรวจสอบและยืนยันว่ารายการการรวมตัวอยู่ในเงื่อนไขที่น่าพอใจ - อาจทำให้มีการใช้งาน CPU เพิ่มขึ้นบ้าง แต่ดูเหมือนไม่ใช่ปัญหาใหญ่

ช่วงเวลา 4: คณะกรรมการผู้รับรอง

นักแสดง: Attester

ผู้รับรองโหวตเพื่อบล็อกบีคอนโด้โดยใช้กฎการเลือก LMD GHOST fork ผู้รับรองจะโหวตเฉพาะสำหรับบล็อกบีคอนที่ประทับใจฟังก์ชันการประเมินรายการการรวมเวลา 1

การพิจารณาทรัพยากร

• การลงคะแนนเสมือนจะเลือกบล็อคที่เข้าข่ายการประเมินรายการรายการ → ไม่มีค่าใช้จ่ายเพิ่มเติม

สรุป

ไม่มีความแตกต่างกับวันนี้

สรุปการพิจารณาทรัพยากร

เหมือนที่เห็นข้างต้น ปัญหาทรัพยากรที่สำคัญที่สุดเกี่ยวกับการอัปโหลดรายการการรวมอยู่ที่การดาวน์โหลดและภายในมุมมองของโหนดที่สามารถทำสแปมได้ ปัญหาที่สำคัญอีกประการหนึ่งคือภาระของโหนดในการตรวจสอบและนำเข้ารายการการรวม รวมถึงความต้องการของผู้เสนอในการอัปเดตกระบวนการสร้างบล็อกของตนเพื่อทำให้รายการการรวมนั้นเป็นไปตามต้องการ ประการเหล่านี้ต้องให้ความระมัดระวังและออกแบบอย่างรอบคอบเพื่อให้มั่นใจในประสิทธิภาพและความปลอดภัย

คำถามที่เปิด

จากนั้นเราจะกล่าวถึงคำถามที่เปิดเผยหลายข้อที่จะมีผลต่อวิธีการเขียนข้อกำหนด:

1. บล็อกที่ไม่พอใจกับฟังก์ชั่นการประเมิน: วิธีการจัดการกับบล็อกที่ล้มเหลวในการประเมินรายการการรวมและประเด็นการออกแบบที่เกี่ยวข้องสำหรับเงื่อนไขเช่นนี้
   • ควรจะถูกจัดการเช่นเดียวกับ blobs และไม่สามารถนำเข้าได้หรือไม่?
   • ควรจะไม่ถูกกรองโดยการเลือกคัดเลือกทางสะพานหรือไม่?
   • ไม่ควรเป็นสถานะที่ถูกต้องในฟังก์ชันการเปลี่ยนสถานะ
2. ความเท่าเทียมกันของรายการรวม: หากสมาชิกคณะกรรมการรายชื่อรวมส่งรายชื่อรวมเวอร์ชันต่างๆไปยังโหนดที่แตกต่างกันและพวกเขาทั้งหมดได้รับการเผยแพร่ทั่วทั้งเครือข่ายผลที่ตามมาของการกระทํานี้คืออะไร? พฤติกรรมดังกล่าวจะส่งผลเสียต่อผู้เสนอการสร้างบล็อกถัดไปได้อย่างไร?
3. Proposer Already Building on a Different Head: หากผู้เสนอบัญชีสร้างบนหัวที่แตกต่างจากที่ส่งโดยคณะกรรมการรายชื่อการรวมเข้าด้วยกัน และต้องเปลี่ยนมุมมองหัวของมัน ผลที่เกิดขึ้นจากการดำเนินการนี้สำหรับความถูกต้องของบล็อกและพฤติกรรมของผู้เสนอบัญชีคืออะไร?
4. การยกเลิกธุรกรรมรายการรวม: ธุรกรรมรายการรวมภายในอาจถูกทําให้เป็นโมฆะได้สองสามวิธี แม้ว่าธุรกรรมเหล่านี้จะเป็นโมฆะ แต่บล็อกก็ยังสามารถตอบสนองฟังก์ชันการประเมินได้ ธุรกรรมอาจถูกยกเลิกเมื่อรายการรวมหลายรายการรวมเข้าด้วยกันหรือกับธุรกรรมในบล็อก นอกเหนือจากการตรวจสอบ nonce ทั่วไปแล้วการแยกบัญชียังแนะนําวิธีใหม่ ๆ สําหรับการทําธุรกรรมที่จะเป็นโมฆะเนื่องจากยอดคงเหลือสามารถระบายออกได้ด้วย nonce แบบคงที่ ตัวสร้างบล็อกต้องดําเนินการจําลองเพิ่มเติมเท่าใดเนื่องจากการทําธุรกรรมเป็นโมฆะและสิ่งนี้ส่งผลต่อการประมวลผล CPU มากน้อยเพียงใดยังคงต้องรอดูสําหรับทั้งนักแสดง MEV-Boost และผู้สร้างท้องถิ่น
5. ข้อสังเกตของผู้เสนอของ Subnet คณะกรรมการ IL: ผู้เสนอจะตรวจสอบเครือข่ายย่อยของคณะกรรมการรายชื่อรวมเพื่อทราบว่าเมื่อใดที่พร้อมจะสร้าง aggreGate มีวิธีการออกแบบสองวิธีที่นี่และควรพิจารณาเพิ่มเติม แนวทางแรกคือผู้เสนอโลภซึ่งผู้เสนอรอจนถึง t = 9 รวบรวม ILs ให้ได้มากที่สุดส่งไปยัง EL และ EL จะอัปเดตบล็อก แนวทางที่สองคือผู้เสนอแบบคัดเลือกซึ่งผู้เสนอจะรอจนกว่าจะมีรายการรวมที่เพียงพอเพื่อตอบสนองฟังก์ชัน eval ส่งไปยัง EL และสามารถทําได้ในเวลาน้อยกว่า t = 9s หรือก่อนหน้านี้ คําถามคือแนวทางที่สองแสดงให้เห็นถึงการเพิ่มประสิทธิภาพเพื่อให้ผู้เสนอปล่อยรายการรวม aggreGate ก่อนหน้านี้หรือไม่ วิธีที่สองอาจเหมาะสําหรับ IL ที่มีขีด จํากัด ก๊าซเฉพาะของตัวเองเท่านั้น

คำเตือน:

1. บทความนี้พิมพ์ซ้ําจาก [ethresear]. สิทธิ์ในการเผยแพร่ทั้งหมดเป็นของผู้เขียนเท่านั้น [ terence]. หากมีการคัดค้านการเผยแพร่นี้โปรดติดต่อGate Learnทีมงาน และพวกเขาจะจัดการด้วยความรวดเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เกิดเป็นการให้คำแนะนำทางการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว เว้นแต่จะกล่าวถึง