ชื่อเรื่องเดิม: "Censorship... wat do?》

ชื่อเรื่องเดิม: "

บทความนี้มาจากบัญชีสาธารณะ WeChat Old Yuppie

บทความนี้มาจากบัญชีสาธารณะ WeChat Old Yuppie

แนะนำ

แนะนำ

การเซ็นเซอร์เข้ากันไม่ได้กับค่า Ethereum

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

นักพัฒนาควรทำอย่างไร?

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

ปัญหาเช่นการปรับขนาดสามารถนั่งเบาะหลังได้จริงๆ Ethereum สามารถอยู่รอดได้ด้วยค่าธรรมเนียมที่สูงขึ้นเล็กน้อย แต่ไม่สามารถอยู่รอดได้จากการเซ็นเซอร์ EIP-4844, Danksharding และการอัปเกรดอื่นๆ มีความซับซ้อนและอาจใช้เวลาและความสนใจมาก หากจำเป็นจริงๆ EIP-4488 สามารถนำไปใช้ได้อย่างรวดเร็วและมีประสิทธิภาพมาก

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

MEV-Boost

นอกจากนี้ยังเป็นตลาดหมีและทุกคนยากจนหรือกำลังวิ่งหนี ค่าธรรมเนียมเป็นที่ยอมรับ

เริ่มจากภาพรวมคร่าวๆ ของสถาปัตยกรรมกันก่อน

การจับภาพ MEV ต้องใช้เทคโนโลยีขั้นสูง หากผู้ตรวจสอบความถูกต้องได้รับงานนี้ พวกเขาจะกลายเป็นศูนย์กลาง - เฉพาะผู้ตรวจสอบความถูกต้องที่บรรลุนิติภาวะแล้วเท่านั้นที่สามารถแยก MEV ได้จึงจะได้รับรางวัลการแข่งขัน Proposer-Builder Separation (PBS) ช่วยแก้ปัญหานี้ - สร้างบทบาท "ผู้สร้าง" ใหม่โดยเฉพาะเพื่อสร้างบล็อกที่เหมาะสมที่สุด จากนั้นผู้สร้างจะเสนอราคาต่อผู้เสนอ (ผู้ตรวจสอบความถูกต้อง) เพื่อยอมรับบล็อกของพวกเขา การเป็นผู้ยื่นข้อเสนอยังคงเป็นเรื่องง่าย พวกเขาได้รับรางวัลจากการแข่งขัน = กระจายอำนาจอยู่เสมอ

ในที่สุด PBS จะถูกสร้างขึ้นในโปรโตคอล แต่ยังไม่พร้อม PBS อยู่ที่นี่แล้ว - ขณะนี้ MEV-Boost เป็นหินก้าวนอกโปรโตคอล (แม้จะมีสมมติฐานที่น่าเชื่อถือเป็นพิเศษ) เป็นซอฟต์แวร์เสริมเพิ่มเติมที่ตัวตรวจสอบความถูกต้องสามารถเรียกใช้เพื่อสอบถามการสร้างบล็อกจากภายนอก เครื่องมือตรวจสอบความถูกต้องยังคงมีตัวเลือกในการใช้ไคลเอ็นต์การดำเนินการของตนเองและสร้างบล็อคในเครื่อง

ผู้ค้นหา MEV จำนวนมากใช้กลยุทธ์เฉพาะและเสนอราคาสำหรับผู้สร้างเพื่อรวมไว้ในกลุ่มของพวกเขา ผู้สร้างสามารถรวมบันเดิลเหล่านี้ + สตรีมคำสั่งส่วนตัวอื่น ๆ + ธุรกรรม mempool สาธารณะ → สร้างบล็อกเต็มที่ดีที่สุด ผู้สร้างบางรายสามารถกำหนดการค้นหาและรับบทบาทนี้ได้ด้วยตนเอง

ภาพรวมของขาประจำ

ผู้ถ่ายทอดเป็นตัวกลางที่ทั้งผู้เสนอและผู้สร้างไว้วางใจ พวกเขาได้รับบล็อกของผู้สร้างและดูแลพวกเขาก่อนที่จะส่งไปยังผู้เสนอ สำหรับรีเลย์เฉพาะ กระบวนการอาจมีลักษณะดังนี้:

เป้าหมายการออกแบบ

MEV-Boost กล่าวถึงข้อบกพร่องที่สำคัญสองประการของ MEV-Geth:

1. การมีส่วนร่วมของผู้เดิมพันคนเดียว

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

แผนการนี้หมายถึงการไว้วางใจผู้ให้บริการกลุ่มการขุด - พวกเขาสามารถเห็นบันเดิลเหล่านี้ได้อย่างชัดเจน ดังนั้นพวกเขาจึงสามารถขโมยโอกาสเหล่านี้ได้โดยตรงหากต้องการ ความน่าเชื่อถือนี้ไม่ได้ขยายไปถึงชุดตรวจสอบความถูกต้องของ Ethereum จำนวนมาก นี่คือเหตุผลที่ MEV-Boost ให้บล็อกที่สมบูรณ์แก่ผู้เสนอ ผู้เสนอลงนามและส่งส่วนหัวของบล็อกก่อนที่เนื้อความของบล็อกจะถูกเปิดเผยต่อพวกเขา หากพวกเขาพยายามขโมย MEV หลังจากเห็นเนื้อหาของบล็อก พวกเขาจะต้องเสนอบล็อกใหม่ ลายเซ็นดั้งเดิมของพวกเขาถูกนำเสนอ → ผู้เสนอจะถูกตัดออกสำหรับลายเซ็นที่ซ้ำกัน

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

• หากผู้สร้างบทวิจารณ์เป็นผู้สร้างที่ทำกำไรได้มากที่สุด ผู้เสนอจะถูกบังคับให้เลือกระหว่างสองสิ่งต่อไปนี้ :

• เหตุผลทางเศรษฐกิจ - ยอมรับบล็อกมูลค่าสูงสุดแม้ว่าจะถูกเซ็นเซอร์ก็ตาม

ความบริสุทธิ์ใจ - ยอมรับบล็อกที่มีค่าน้อยกว่าโดยไม่มีการเซ็นเซอร์

ตามหลักการแล้ว สมมติฐานที่เห็นแก่ผู้อื่นควรถูกลบออกทั้งหมดหรือลดให้เหลือน้อยที่สุด

2. ความหลากหลายของลูกค้า

นักขุดส่วนใหญ่ใช้งานไคลเอนต์ Go Ethereum (Geth) ดังนั้น Flashbots จึงแยกมันออกและสร้าง MEV-Geth การเรียกใช้เป็นวิธีเดียวที่จะเข้าร่วมในการประมูล Flashbots PoS เป็นโอกาสในการเพิ่มความหลากหลายของลูกค้า ไซด์คาร์ MEV-Boost สามารถทำงานร่วมกับไคลเอ็นต์ที่เป็นเอกฉันท์และการดำเนินการทั้งหมด

• MEV-Boost เป็นกลางของโครงสร้างพื้นฐาน:

• ผู้ถ่ายทอด - มีอิสระในการทำงานภายใต้ข้อจำกัดหรือนโยบายใดๆ (เช่น การเซ็นเซอร์/ไม่เซ็นเซอร์ การสั่งซื้อที่ "ยุติธรรม"/กำไรสูงสุด เป็นต้น) ผู้ถ่ายทอดสามารถรับบล็อกจากผู้สร้างได้ตามต้องการ

• ผู้สร้าง - มีอิสระที่จะใช้กลยุทธ์ใด ๆ ที่พวกเขาชอบและปรับใช้กับรีเลย์ใด ๆ ที่พวกเขาไว้วางใจซึ่งยินดียอมรับการบล็อกของพวกเขา

MEV-Boost ไม่ได้ตรวจสอบธุรกรรม OFAC หรือธุรกรรมแบบแซนด์วิช ช่วยให้ผู้เสนอสามารถว่าจ้างงานสร้างภายนอกได้โดยเลือกจากผู้ถ่ายทอดที่ตรงกับพวกเขา

ทบทวน

ทบทวน

• นี่คือกรอบการทำงานสำหรับการสนทนาของฉันเกี่ยวกับการทบทวน:

• การตรวจสอบที่อ่อนแอ = ล่าช้า แต่รวมไว้ในที่สุด หาก 50% ของผู้ตรวจสอบความถูกต้องไม่รวมธุรกรรม OFAC โดยเฉลี่ยแล้ว พวกเขาจะถูกรวมหลังจาก 2 ช่วงตึก (24 วินาที) ด้วยการเซ็นเซอร์ 90% พวกมันจะถูกรวมหลังจาก 10 ช่วงตึก (120 วินาที) เป็นต้น

การเซ็นเซอร์ที่เข้มงวด = ธุรกรรมที่ถูกเซ็นเซอร์ไม่รวมอยู่ในเครือข่าย ใน Gasper สิ่งนี้ต้องการให้ 51% ของผู้ตรวจสอบความถูกต้องไม่เพียงแค่เซ็นเซอร์ธุรกรรม OFAC สำหรับบล็อกของตนเองเท่านั้น แต่ยังเพิกเฉยต่อบล็อกใหม่ทั้งหมดที่รวมอยู่ในนั้นด้วย

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

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

• Blocknative

• Eden Network

bloxRoute ผู้ถ่ายทอด "ภายใต้การดูแล"

• ตัวทำซ้ำแบบไม่เซ็นเซอร์:

• bloxRoute ผู้ถ่ายทอด "การเพิ่มผลกำไรสูงสุด"

• Manifold Finance

ผู้ถ่ายทอด "จริยธรรม" สำหรับ bloxRoute

ฉันจะมุ่งเน้นไปที่วิธีลดภัยคุกคามในระดับนี้

ผู้ตรวจสอบความถูกต้องควรทำอย่างไร?

ฉันเขียนกระทู้นี้เมื่อนานมาแล้ว แต่ไม่นานมานี้ ฉันคิดเกี่ยวกับมันอีกครั้ง ฉันยังคงมีความรู้สึกคล้าย ๆ กัน - ฉันคิดว่าเป็นการดีที่สุดที่จะเรียกใช้ MEV-Boost แต่ใช้กับตัวทำซ้ำที่ไม่ถูกเซ็นเซอร์เท่านั้น

พูดตามตรง ถ้าฉันเป็นผู้ตรวจสอบความถูกต้อง ฉันไม่อยากใช้ MEV-Boost เลย Flashbots เป็นตัวดำเนินการ live repeater/builder ที่น่าเชื่อถือที่สุด ดังนั้นฉันจึงไม่สบายใจที่จะใช้บางตัว แต่การส่งเสริมการเซ็นเซอร์อย่างจริงจังนั้นเป็นอันตราย

ดังนั้นการเรียกใช้ไคลเอ็นต์ส่วนตัวจึงฟังดูดีและง่าย แต่ฉันคิดว่าจะเป็นการดีกว่าถ้าเรียกใช้ MEV-Boost กับรีเลย์ที่ไม่ถูกเซ็นเซอร์อื่นๆ มิฉะนั้น การยอมรับในระดับต่ำจะนำมาซึ่งปัจจัยภายนอกเชิงลบ (pga ฯลฯ) นอกจากนี้ ผู้ตรวจสอบความถูกต้องที่ดำเนินการจะได้รับมากกว่าผู้ตรวจสอบความถูกต้องที่เห็นแก่ผู้อื่นซึ่งไม่ได้ทำ - พวกเขาจะเพิ่มส่วนแบ่งการตลาดอย่างเป็นระบบนานพอที่จะดึงดูดผู้ตรวจสอบความถูกต้องที่เห็นแก่ผู้อื่น

การเพิกเฉยต่อ MEV จะไม่ทำให้มันหายไป และเราเคยเห็นสิ่งนี้เกิดขึ้นมาก่อน

การใช้ตัวส่งต่อ Flashbots ที่ต่ำกว่าอาจหมายถึงการตรวจสอบข้อเท็จจริงที่น้อยลง ในขณะที่เขียน - การยอมรับ MEV-Boost คิดเป็น 42% ของผู้ตรวจสอบความถูกต้องและ Flashbots กำลังสร้างบล็อก MEV-Boost ~ 60% = ~ 25% ของบล็อก Ethereum ถูกเซ็นเซอร์ที่นั่น การใช้ MEV-Boost ก็เพิ่มขึ้นอย่างต่อเนื่องเช่นกัน ปัจจุบันมีการตรวจสอบน้อยมากจากผู้ถ่ายทอดรายอื่น (พวกเขาไม่มีส่วนแบ่งการตลาดที่มีความหมาย)

อันที่จริง ฉันไม่คิดว่า "การเซ็นเซอร์น้อยลง" สร้างความแตกต่าง หากอัตราการเซ็นเซอร์ของคุณคือ 20% เทียบกับ 40% เทียบกับ 60% ที่อยู่ OFAC เหล่านั้นจะถูกเซ็นเซอร์และต้องรอ หากอัตราการตรวจสอบเพิ่มขึ้น พวกเขาจะรออีกสักหน่อย

อย่างไรก็ตาม ฉันคิดว่ามันสำคัญมากจากมุมมองของการส่งสัญญาณ Ethereum ควรสื่อสารให้โลกรู้ว่าพฤติกรรมนี้ไม่สอดคล้องกับค่านิยมของเราและจะไม่ยอม

ข้อตกลงทำอะไร?

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

ประดิษฐาน PBS และ crList

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

• crLists ตรวจสอบความสามารถนี้ การใช้งานที่ถูกต้องคือพื้นที่การออกแบบแบบเปิด แต่นี่คือภาพรวมที่เรียบง่ายของ "PBS แบบไฮบริด" ผู้เสนอระบุรายการธุรกรรมที่มีสิทธิ์ทั้งหมดที่พวกเขาเห็นใน mempool ที่ผู้สร้างจะถูกบังคับให้รวม (เว้นแต่ว่าบล็อกจะเต็ม):

• ผู้เสนอเผยแพร่ crList และสรุป crList ซึ่งรวมถึงธุรกรรมที่มีสิทธิ์ทั้งหมด

• ผู้สร้างสร้างบล็อกที่เสนอ จากนั้นส่งการเสนอราคาที่มีแฮชของไดเจสต์ crList เพื่อพิสูจน์ว่าพวกเขาได้เห็น

• ผู้เสนอยอมรับการประมูลและส่วนหัวบล็อกของผู้ชนะการประมูล (พวกเขายังไม่เห็นเนื้อหาของบล็อก)

• ผู้สร้างเผยแพร่บล็อกของพวกเขาและรวมหลักฐานว่าพวกเขาได้รวมธุรกรรมทั้งหมดจาก crList หรือบล็อกนั้นเต็ม มิฉะนั้น บล็อกจะไม่ได้รับการยอมรับจากกฎการเลือกทางแยก

ตัวตรวจสอบความถูกต้องตรวจสอบความถูกต้องของหลักที่ออก

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

Barnabé เสนอแนวคิดอื่นที่คล้ายกัน โดยพื้นฐานแล้ว ผู้เสนอสามารถสร้างคำนำหน้าสำหรับบล็อกเพื่อรวมธุรกรรมที่ถูกเซ็นเซอร์อื่นๆ ไว้ด้านบน จากนั้นผู้สร้างสามารถสร้างส่วนที่เหลือ (หรือทั้งบล็อกหากไม่มีธุรกรรมที่ถูกเซ็นเซอร์ให้รวม)

รักษา Block Proposer Proxy ผ่าน MEV-Boost โดยใช้ EigenLayer

อีกวิธีหนึ่งจะส่งคืนพร็อกซีของผู้เสนอเพื่อแนบธุรกรรม โครงร่างนี้ใช้ EigenLayer เพื่อปรับปรุง MEV-Boost ซึ่งจะเป็นการเพิ่มความต้านทานการเซ็นเซอร์

EigenLayer เป็นคอลเลกชันที่ "คิดค้นขึ้นใหม่" ซึ่งคาดว่าจะเปิดตัวในปลายปีหน้า ผู้ตรวจสอบความถูกต้องของ Ethereum ที่เลือกใช้ EigenLayer จะต้องปฏิบัติตามเงื่อนไขเพิ่มเติมโดยการตั้งค่าที่อยู่การถอนตัวตรวจสอบเป็น EigenLayer smart contract

โปรโตคอลสามารถปรับใช้โดยไม่ได้รับอนุญาตบน EigenLayer และพยายามกระตุ้นให้ผู้ตรวจสอบความถูกต้องเหล่านี้เลือกที่จะรักษาความปลอดภัยโซลูชันของตนเอง (นอกเหนือจาก Ethereum) ด้วยเดิมพันเดียวกัน ผู้ตรวจสอบเลือกเข้าร่วมแอปพลิเคชัน EigenLayer ใด ๆ ที่พวกเขาเลือก พวกเขาสามารถถูกขวานได้เนื่องจากละเมิดกฎของแอปพลิเคชัน สิ่งนี้ทำให้โปรโตคอลอื่นๆ (ไม่ว่าจะเป็นสะพานข้ามโซ่ใหม่ เลเยอร์ความพร้อมใช้งานของข้อมูล หรืออื่นๆ) สามารถใช้ประโยชน์จากชุดย่อยที่ปลอดภัยทางเศรษฐกิจของ Ethereum ได้โดยตรง

• แล้วสิ่งนี้นำไปใช้กับ MEV-Boost ได้อย่างไร? ผู้เข้าร่วมที่เลือกโครงสร้างนี้ทำสิ่งต่อไปนี้:

• ผู้เสนอเดิมพัน ETH ของพวกเขาอีกครั้งด้วย EigenLayer

• ผู้สร้างส่งบล็อกของพวกเขา (builder_part) ไปยังผู้ส่งต่อพร้อมกับ Merkle_root ของธุรกรรมที่มีอยู่และการเสนอราคา

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

• ผู้เสนอเลือกการเสนอราคาสูงสุดจากรีเลย์ที่เชื่อมต่อทั้งหมด

• ผู้เสนอสร้างบล็อกทางเลือกสำรอง B_alt ของตนเองในเครื่อง

• ผู้เสนอส่งการรับรองไปยัง merkle_root ของผู้ชนะการประมูล เชื่อมต่อกับ commit_B_alt ที่มุ่งมั่น (ไม่ใช่ส่วนหัวของบล็อก อาจเป็นรากธุรกรรม) และส่งไปยังบล็อก B_alt ของตนเอง

• ผู้ถ่ายทอดจะเปิดเผย builder_part ที่มีธุรกรรมอ้างอิงและส่งไปยังผู้เสนอ

ผู้เสนอสร้างบล็อกใหม่ที่มี builder_part และต่อท้าย offerr_part เพิ่มเติม (หากพวกเขาเห็นธุรกรรมอื่น ๆ ที่พวกเขาต้องการรวมไว้และมีที่ว่างในบล็อก) หากผู้ถ่ายทอดไม่สามารถปล่อยธุรกรรมพื้นฐานได้ ผู้เสนอบล็อกจะเสนอบล็อก B_alt ที่พวกเขาสร้างขึ้น

หากผู้เสนอเสนอบล็อกอื่นที่ไม่ใช่ B_alt ผู้เสนอจะต้องรวม builder_part มิฉะนั้นจะถูกสับผ่าน EigenLayer นี่เป็นเงื่อนไขเพิ่มเติมที่พวกเขาต้องปฏิบัติตาม สิ่งนี้ทำให้ไม่ต้องเชื่อถือผู้เสนอ หากพวกเขาพยายามขโมย MEV หลังจากเห็นธุรกรรมที่เกี่ยวข้อง พวกเขาจะต้องเสนอบล็อกอื่นที่ไม่ใช่ B_alt และจะถูกเฉือน

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

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

โปรดทราบว่า builder_part อาจเป็นเพียงส่วนหนึ่งของบล็อกหรือบล็อกทั้งหมด หากใช้ก๊าซทั้งหมด 30 ล้านถัง แน่นอนว่าไม่มีการรับประกันว่าจะรวมก๊าซทั้งหมด แต่ EIP-1559 ช่วยให้มั่นใจได้ว่ามีพื้นที่ว่างเกือบตลอดเวลา

ปีศาจที่คุณรู้จักกับปีศาจที่คุณไม่รู้จัก

สมมติว่าปิด Flashbots ปีศาจที่คุณรู้ว่ามันถูกขัดขวาง - การตรวจสอบข้อเท็จจริงส่วนใหญ่อาจจะหายไป ฟังดูดีใช่ไหม?

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

ในความเห็นของฉัน ความเสี่ยงสูงสุดของเหตุการณ์นี้มาจาก Exclusive Order Flow (EOF):

ผู้สร้างสามารถมั่นใจได้ว่าคำสั่งเฉพาะจะถูกส่งไปยังพวกเขาเท่านั้น (เช่น สัญญาว่าจะไม่ทำกับผู้ใช้ก่อนหน้าและให้ส่วนลดสำหรับผลกำไรในภายหลัง) เราสามารถเห็นตัวอย่างแรก ๆ ของสิ่งนี้ จากนั้นพวกเขาสามารถเสนอราคาที่สูงขึ้น ชนะบล็อกมากขึ้น และพิสูจน์ข้อตกลงพิเศษได้มากขึ้น

เครื่องมือสร้างบล็อกแบบรวมศูนย์สามารถสร้างความหายนะได้:

เช่า

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

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

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

ทบทวน

ทบทวน

ประการแรก สิ่งที่หรูหราเช่น crList ไม่ใช่แบบเรียลไทม์ ทุกวันนี้ เว็บเสี่ยงต่อการถูกเซ็นเซอร์เป็นพิเศษ

• ในตัวอย่างด้านล่าง ฉันถือว่าตลาดประกอบด้วยผู้สร้างเพียงสองคน:

• B₁ = ตัวสร้างการต่อต้านการเซ็นเซอร์

B₂ = ผู้สร้างที่มีสิทธิ์เซ็นเซอร์

หาก B₂ ได้รับส่วนแบ่งการตลาดอย่างมีนัยสำคัญในวันนี้ พวกเขาสามารถบังคับใช้การเซ็นเซอร์ที่อ่อนแออย่างมีความหมายได้ และเราก็เห็นเช่นนั้น อย่างไรก็ตาม โปรดจำไว้ว่านี่ไม่ใช่การเซ็นเซอร์ที่เข้มงวด

ตลาดที่มีการแข่งขันอย่างสมบูรณ์พร้อมตัวตรวจสอบที่มีเหตุผลช่วยป้องกันการเซ็นเซอร์ที่อ่อนแอได้ในทุกสถานการณ์ ภายใต้เงื่อนไขเครือข่ายที่เหมาะสม สิ่งอื่นๆ ที่เท่าเทียมกัน ให้เสนอราคา B₁ ≥ ราคาเสนอ B₂ ทั้งสองสามารถรวมธุรกรรม mempool สาธารณะ แต่ B₁ เท่านั้นที่สามารถรวมธุรกรรม OFAC ดังนั้น PBS ที่แข่งขันได้จึงมีความทนทานต่อการเซ็นเซอร์เพียง 1/N ตามที่ผู้สร้างสันนิษฐานไว้

แน่นอนว่านี่ไม่ใช่ความจริง - ผู้สร้างมีขั้นตอนการสั่งซื้อและอัลกอริทึมที่แตกต่างกัน ส่งผลให้เกิดการเสนอราคาที่แตกต่างกัน อย่างไรก็ตาม สิ่งนี้แสดงให้เห็นอย่างชัดเจนว่าเหตุใดเราจึงควรพยายามแข่งขันในตลาดที่มีการแข่งขันสูง หาก B₂ ควบคุมส่วนแบ่งการตลาดมากเกินไปเนื่องจาก EOF หรือเหตุผลอื่นๆ พวกเขาสามารถดำเนินการตรวจสอบข้อเท็จจริงที่มีความหมายได้

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

โปรดทราบว่า crList ไม่สามารถกำจัดความเป็นไปได้นี้ได้อย่างสมบูรณ์ หาก B₂ สร้างบล็อกที่มีค่าที่สุดอย่างสม่ำเสมอ ผู้เสนอที่เผยแพร่รายการ crLists ที่มีธุรกรรม OFAC จะรู้ว่าพวกเขาจะไม่สามารถยอมรับบล็อกที่ให้ผลกำไรสูงสุดได้ การตัดสินใจที่มีเหตุผลทางเศรษฐกิจคือการแพร่ภาพ crList ที่ว่างเปล่า อย่างไรก็ตาม หากความแตกต่างระหว่างราคาเสนอ B₁ และราคาเสนอ B₂ นั้นไม่มีนัยสำคัญ (แม้จะเป็นผลดีกับ B₁) เนื่องจากการแข่งขันในตลาด ก็เป็นข้อสันนิษฐานที่สมเหตุสมผลที่ผู้ตรวจสอบความถูกต้องจะเผยแพร่ crlist

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

นวัตกรรมผู้สร้างน้อยลง

PBS เป็นโอกาสสำหรับผู้สร้างในการนำเสนอคุณสมบัติใหม่ที่เป็นนวัตกรรมใหม่ (เช่น การสรุปบัญชี การยืนยันล่วงหน้า)

ผู้สร้างที่แข่งขันได้ได้รับการสนับสนุนให้สร้างนวัตกรรมในการทำงานเพื่อดึงดูดผู้ใช้ OF ผู้สร้างที่มีรากฐานที่มั่นคงไม่ได้ แม้ว่าผู้สร้างรายอื่นจะเริ่มเสนอคุณสมบัติที่ดีกว่า ค่าใช้จ่ายในการเปลี่ยนอาจสูงเกินไปหรือทำไม่ได้เลย (ใช้เวลานานมากในการรวมธุรกรรม ไม่มีวันบล็อก ธุรกรรม PFOF ฯลฯ สำหรับผู้สร้างรายอื่น)

• โปรดทราบว่าได้รับ OF≠PFOF เนื่องจากฟังก์ชันที่เหนือกว่า:

• ได้รับจากฟังก์ชันการทำงานที่เหนือกว่า - อุปสรรคในการเข้าคือการจัดหาฟังก์ชันการทำงานใหม่

PFOF - อุปสรรคในการเข้าคือการชำระเงินที่ชัดเจน ผู้ใช้ต้องรอเป็นเวลานาน และอาจถึงขั้นละเมิดสัญญา

พูดง่ายๆ ก็คือ PFOF ในที่นี้หมายถึงความพิเศษ แต่ฟังก์ชันไม่ใช่ หากผู้สร้างบางรายให้เฉพาะคุณลักษณะที่ต้องการเพื่อแลกกับ EOF สิ่งนี้จะไม่เป็นที่พึงปรารถนาเช่นเดียวกับ PFOF

แล้ว EOF ล่ะ?

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

ผู้สร้างการกระจายอำนาจ

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

นอกจากนี้ยังมีพื้นที่การออกแบบที่กว้างขึ้นสำหรับวิธีที่ตลาดเครื่องมือสร้างแบบกระจายศูนย์แบ่งปันขั้นตอนการสั่งซื้ออย่างปลอดภัย

นี่คือเป้าหมายที่ระบุไว้ในหน้าแรกของ Flashbots:

เรากำลังสร้างเครือข่ายการสร้างบล็อกแบบกระจายศูนย์เพื่อให้อำนาจแก่ผู้ใช้และเพิ่มการกระจายอำนาจสูงสุดให้กับบล็อกเชนสาธารณะ

Flashbots ทำอะไร?

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

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

ต้องบอกว่าโดยส่วนตัวแล้วฉันพบว่าเป็นการยากที่จะให้เหตุผลในการเซ็นเซอร์อย่างชัดเจนโดยหวังว่าจะป้องกันไม่ให้ผู้อื่นทำเช่นนั้นอีกในอนาคต

โอเพ่นซอร์สผู้สร้างและเป็นผู้นำตลาด

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

วิจัย

วิจัย

การวิจัย Flashbots ควรมุ่งเน้นไปที่การแก้ปัญหาการเซ็นเซอร์ต่อไป - ผู้สร้างแบบกระจายศูนย์ รวมรายการ โฟลว์คำสั่งที่ใช้ร่วมกัน ฯลฯ นี่คือเป้าหมายที่ระบุไว้ของ Flashbots

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

ความคืบหน้าที่สำคัญเกี่ยวกับการวิจัยนี้จำเป็นต้องดำเนินการและเปิดกว้างในระยะเวลาอันใกล้นี้

การทำงานของรีพีตเตอร์

จริง ๆ แล้ว ฉันคิดซ้ำแล้วซ้ำเล่าเกี่ยวกับผู้ทำซ้ำ - พวกเขาควรเรียกใช้หรือไม่ ฉันถาม Vitalik, Justin Drake, Phil Daian, Zaki Manian และ Francesco D'Amato

Vitalik ย้ำทางเลือกหนึ่ง — Flashbots สามารถแยกเอนทิตีการวิจัยที่เป็นกลางออกจากเอนทิตีการดำเนินงานขององค์กร สิ่งนี้จะขจัดความขัดแย้งทางผลประโยชน์ในการวิจัย และเราไม่จำเป็นต้องตั้งคำถามถึงแรงจูงใจของผู้ปฏิบัติงานอีกต่อไป เราเข้าใจเพียงว่าพวกเขากำลังทำงานเพื่อตัวเอง เช่นเดียวกับคนอื่นๆ ส่วนใหญ่ในสาขานี้ ข้อเสียของสิ่งนี้คือฝ่ายวิจัยและฝ่ายผลิตภัณฑ์ร่วมกันสร้างวงรอบข้อเสนอแนะในเชิงบวกซึ่งสร้างความก้าวหน้าที่มีความหมาย และคุณอาจเสี่ยงที่จะสูญเสียบางส่วนไป เราเห็นว่า MEV-Boost นั้นเริ่มต้นจากการวิจัยและนำมาใช้ในภายหลังโดยฝ่ายผลิตภัณฑ์

• หากพวกเขาหยุดเรียกใช้ตัวทำซ้ำ ปัญหาจะไม่หายไปอย่างสมบูรณ์ อัตราการเซ็นเซอร์อาจลดลง แต่ผู้ถ่ายทอดการตรวจสอบรายอื่นอาจเติมเต็มช่องว่าง ภัยคุกคามจากการเซ็นเซอร์รูปแบบใหม่ที่คาดไม่ถึงอาจปรากฏขึ้นเมื่อเวลาผ่านไป การมีส่วนร่วมของ Flashbots ในฐานะผู้ส่งต่อ/ผู้สร้างมีผลสองประการต่อการนำ MEV-Boost มาใช้โดยรวม:

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

หากพวกเขากำลังจะเรียกใช้รีเลย์ต่อไป คุณควรกำหนดขีดจำกัดของเปอร์เซ็นต์ของผู้ตรวจสอบความถูกต้องในท้ายที่สุดในบางประเด็น อันที่จริงแล้วการเซ็นเซอร์นั้นอ่อนแอ แต่ฉันยังคงเห็นความแตกต่างอย่างมากในสัญญาณระหว่างการตรวจทาน 1% และ 99% สิ่งนี้จะมีความจำเป็นมากที่สุดหากเปอร์เซ็นต์ของบล็อก Ethereum ที่ถูกเซ็นเซอร์ยังคงเพิ่มขึ้น และไม่มีการดำเนินการเปลี่ยนแปลงใหม่เพื่อลดสิ่งนี้ (ไม่ว่าจะเป็น crLists ข้อเสนอ EigenLayer เป็นต้น)

ความคิดสุดท้าย

ความคิดสุดท้าย

ฉันพูดถึง Flashbots ที่นี่ด้วยเหตุผลหลายประการ พวกเขาเป็นแหล่งเซ็นเซอร์ที่สำคัญอย่างแน่นอน แต่พวกเขายังสร้างงานที่ใช้งานอยู่ในระบบนิเวศ Ethereum ในปริมาณที่น่าแปลกใจ นอกจากนี้ ฉันเชื่อว่าพวกเขามีความรับผิดชอบที่สำคัญต่อระบบนิเวศ หากพวกเขาต้องยืนอยู่ระหว่างผู้สร้างชุมชนที่เป็นกลางและผู้ดำเนินการองค์กรแบบดั้งเดิม ท้ายที่สุดแล้ว เพราะพวกเขาฉลาด พวกเขาอาจสร้างสรรค์สิ่งเจ๋งๆ

ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ