อนาคตของ Ethereum II - การต่อต้านการเซ็นเซอร์

บทความนี้เกี่ยวกับ Futures of Ethereum จะสำรวจการต่อสู้อย่างต่อเนื่องเพื่อต้านทานการเซ็นเซอร์ การตรวจสอบผลกระทบของแรงกดดันด้านกฎระเบียบ บทบาทของการแยก Proposer-Builder (PBS) และโซลูชันที่เป็นไปได้ เช่น mempool ที่เข้ารหัสเพื่อรักษาความเป็นกลางและกระจายอำนาจของเครือข่าย Ethereum ได้นำโครงสร้าง PBS มาใช้เพื่อลดความเสี่ยงในการรวมศูนย์ผลกำไรจาก MEV ในระบบนี้ ผู้เสนอบล็อก (โหนดตรวจสอบปกติ) มอบหมายการสร้างบล็อกให้กับผู้สร้างเฉพาะทางซึ่งจะปรับการสั่งธุรกรรมให้เหมาะสมที่สุดเพื่อเพิ่มการสกัด MEV ให้สูงสุด จากนั้นผู้เสนอจะเลือกและลงนามในบล็อกที่ทำกำไรได้มากที่สุดก่อนจะออกอากาศไปยังเครือข่าย MEV-Boost ซึ่งเป็นกลไกการประมูลบล็อกนอกเครือข่าย ถูกใช้กันอย่างแพร่หลายใน Ethereum ในปัจจุบันเพื่ออำนวยความสะดวกให้กับกระบวนการนี้ MEV-Boost ช่วยให้ผู้สร้างเฉพาะทางสามารถส่งข้อเสนอราคาให้กับผู้เสนอราคาเพื่อแข่งขันกันเพื่อให้บล็อกของตนรวมอยู่ในนั้น แม้ว่าชุดตัวตรวจสอบของ Ethereum จะยังคงกระจายอำนาจอย่างมาก แต่การสร้างบล็อก โดยเฉพาะบล็อกที่ได้รับการปรับให้เหมาะสมสำหรับ MEV นั้นมีความซับซ้อนและใช้ทรัพยากรมาก เมื่อพิจารณาจากภาระด้านการคำนวณและโครงสร้างพื้นฐานที่สูงนี้ การรวมการสร้างบล็อกเข้าด้วยกันในขณะที่ยังคงรักษาการรับรองบล็อกให้กระจายอำนาจจึงมีประสิทธิภาพมากกว่า นี่คือหลักการสำคัญของ PBS: PBS จะแจกจ่ายกำไร MEV บางส่วนให้กับผู้ตรวจสอบอย่างยุติธรรมด้วยการประมูลที่เกิดขึ้นในแต่ละบล็อก ในขณะเดียวกันก็รับรองว่าผู้ตรวจสอบทั่วไป (รวมถึงผู้เดิมพันที่บ้าน) จะไม่ต้องแบกรับภาระกับความซับซ้อนของการสร้างบล็อก ด้วยการแยกบทบาทเฉพาะนี้ออกไป PBS จึงรักษาการกระจายอำนาจของเครือข่าย Ethereum โดยรวมเอาไว้ได้พร้อมทั้งเพิ่มประสิทธิภาพของการผลิตบล็อก อย่างไรก็ตาม เนื่องจากผู้สร้างที่ประสบความสำเร็จต้องใช้ทรัพยากรจำนวนมากและกระแสธุรกรรมที่มีเอกสิทธิ์ จึงมีเพียงไม่กี่รายเท่านั้นที่ชนะการประมูลอย่างสม่ำเสมอ ผู้สร้างบางรายรักษาความโดดเด่นด้วยการทำข้อตกลงพิเศษกับกระเป๋าเงิน dApps และผู้ให้บริการกระแสคำสั่งซื้อเฉพาะ เพื่อให้แน่ใจว่าสามารถเข้าถึงธุรกรรม MEV สูงได้ ซึ่งจะช่วยให้พวกเขามีความได้เปรียบในการแข่งขันในการประมูลแบบบล็อก ส่งผลให้การแข่งขันระหว่างผู้สร้างลดน้อยลงเมื่อเวลาผ่านไป ส่งผลให้เกิดโครงสร้างผูกขาด ปัจจุบัน ประมาณ 90% ของบล็อค Ethereum ถูกสร้างขึ้นผ่าน MEV-Boost โดยมีเพียงสองหน่วยงานเท่านั้นคือ Beaverbuild และ Titan Builder ที่สร้างบล็อคเหล่านี้ 95% ความเข้มข้นนี้ทำให้เกิดความกังวลเกี่ยวกับการต่อต้านการเซ็นเซอร์ ความยุติธรรมของธุรกรรม และการกระจายอำนาจในระยะยาวของการผลิตบล็อค Ethereum แม้ว่าการหยุดชะงักหรือพฤติกรรมที่เป็นอันตรายของผู้สร้างเหล่านี้จะไม่ได้ส่งผลกระทบต่อความปลอดภัยของเครือข่าย Ethereum มากนัก แต่ก็ถือเป็นภัยคุกคามร้ายแรงต่อการต่อต้านการเซ็นเซอร์ หากผู้สร้าง MEV-Boost ทั้งหมดตัดสินใจเซ็นเซอร์ธุรกรรมจากผู้ใช้บางราย ผู้ใช้เหล่านั้นจะสามารถส่งธุรกรรมผ่านบล็อกที่สร้างขึ้นโดยผู้ตรวจสอบที่ไม่ได้ใช้ MEV-Boost เท่านั้น ซึ่งคิดเป็นประมาณ 10% ของทั้งหมด ดังนั้น การประมวลผลธุรกรรมดังกล่าวจะใช้เวลาเฉลี่ย 10 บล็อก (ประมาณ 2 นาที) สถานการณ์ดังกล่าวทำให้เกิดประเด็นสำคัญ 2 ประเด็น: ช่องโหว่ด้านกฎระเบียบ ประการแรก อาจทำให้ Ethereum เสี่ยงต่อกฎระเบียบมากขึ้น ตัวอย่างเช่น มาตรการคว่ำบาตร Tornado Cash ที่ ส่งผลให้ผู้สร้างและผู้ตรวจสอบจำนวนมากเซ็นเซอร์ธุรกรรมที่เกี่ยวข้องกับบัญชีที่ถูก OFAC คว่ำบาตร OFAC กำหนดในปี 2022 การแข่งขันที่ไม่เป็นธรรมในโปรโตคอลเช่นการประมูล ประการที่สอง การเซ็นเซอร์สามารถบิดเบือนผลลัพธ์ของการประมูลแบบออนเชนได้ ตัวอย่างเช่น ลองพิจารณาการประมูลที่ขาย NFT หนึ่งรายการให้กับผู้เสนอราคาสูงสุดในแต่ละบล็อก ผู้สร้างบล็อกสามารถเซ็นเซอร์การเสนอราคาอื่นๆ ทั้งหมดในขณะที่เสนอราคาต่ำมาก ทำให้พวกเขาสามารถซื้อ NFT ได้ในราคาที่ลดลงอย่างมาก มีวิธีแก้ปัญหาต่างๆ เกิดขึ้นเพื่อแก้ไขปัญหาเหล่านี้ โพสต์นี้จะอธิบายวิธีแก้ปัญหาเหล่านี้ในสองหมวดหมู่หลัก และจะหารือถึงรูปแบบการต่อต้านการเซ็นเซอร์ที่อาจเกิดขึ้นในอนาคตของ Ethereum วิธีแก้ปัญหาที่เป็นไปได้ 1: รายการรวม พื้นหลัง: ข้อเสนอการรวมรายการเบื้องต้น EIP-7547 Inclusion List เป็นโซลูชันที่ต้านทานการเซ็นเซอร์ซึ่งรับรองว่าธุรกรรมบางอย่างจะรวมอยู่ในบล็อก โดยทั่วไปแล้วสามารถนำไปปฏิบัติได้ดังนี้: นี่เป็นแบบจำลองทางจิตที่เรียบง่าย: ก่อนที่ผู้สร้างจะสร้างบล็อก ผู้เสนอจะส่งคำสั่งพร้อมกับ 'รายการรวม' ที่ระบุว่า "รวมธุรกรรมเหล่านี้ไว้ในบล็อก" ผู้สร้างจะต้องรวมธุรกรรมเหล่านี้ไว้ในบล็อกที่พวกเขาสร้างขึ้น และหากสร้างบล็อกโดยไม่มีธุรกรรมอยู่ในรายการรวม บล็อกนั้นจะถือว่าไม่ถูกต้อง สำหรับ Ethereum ก่อน PBS mempool ซึ่งเป็นส่วนที่ทำธุรกรรมก่อนที่จะป้อนลงในบล็อกนั้นรวมอยู่ใน Ethereum เป็นส่วนประกอบที่ไม่มีฉันทามติ ดังนั้น จากมุมมองของเลเยอร์ฉันทามติของ Ethereum จึงไม่ทราบว่าธุรกรรมที่อยู่ในบล็อกนั้นมาจากที่ใด เหตุผลหลักประการหนึ่งที่ MEV นำไปสู่การเซ็นเซอร์ก็คือ mempool เป็นส่วนประกอบที่ไม่ได้รับความยินยอมจากทุกฝ่าย ดังนั้นผู้สร้างที่สร้างบล็อกจึงมีอำนาจโดยสมบูรณ์ในการกำหนดว่าธุรกรรมใดที่ต้องเซ็นเซอร์หรือรวมไว้ในบล็อก รายการรวมจะแนะนำกลไกที่ใช้ตัวตรวจสอบหลายตัวเพื่อทำหน้าที่เป็น "เมมพูลบนเชน" บนเลเยอร์ฉันทามติ ด้วยวิธีนี้ เลเยอร์ฉันทามติจะจำกัดอำนาจของผู้สร้างในการเลือกธุรกรรมเพื่อให้ต้านทานการเซ็นเซอร์ได้เพียงพอ ข้อเสนอที่โดดเด่นที่สุดข้อหนึ่งสำหรับการนำ Inclusion List มาใช้คือ หรือ Forward Inclusion List ข้อเสนอนี้ให้ผู้เสนอสามารถรวมธุรกรรมได้สูงสุด 16 รายการไว้ใน Inclusion List กลไก "การส่งต่อ" ทำให้มั่นใจว่า Inclusion List ที่เสนอสำหรับบล็อก N จะถูกนำไปใช้กับบล็อก N+1 EIP-7547 ข้อเสนอนี้เดิมตั้งใจให้เป็นส่วนหนึ่งของการอัปเกรด Pectra ของ Ethereum แต่สุดท้ายก็ถูกแยกออก และเหตุผลหนึ่งก็คือปัญหาความเข้ากันได้ระหว่างกลไกการส่งต่อและ EIP-3074 EIP-3074 แนะนำรูปแบบของการแยกบัญชีดั้งเดิมที่ใช้รหัสปฏิบัติการที่เรียกว่า AUTHCALL ซึ่งช่วยให้บัญชีหนึ่งสามารถปรับสมดุลของ EOA (บัญชีที่เป็นเจ้าของจากภายนอก) ได้หลายบัญชี กลไกนี้สามารถทำลายรายการรวมได้อย่างง่ายดาย ตัวอย่างเช่น สมมติว่า Alice รวมธุรกรรม (A) ไว้ในรายการการรวม โดยที่ EOA ของเธอส่ง ETH ให้กับ Bob ในเวลาเดียวกัน เธอสร้างธุรกรรมอื่น (B) โดยใช้ AUTHCALL ของ EIP-3074 เพื่อโอนยอดคงเหลือของ EOA ทั้งหมดไปยังบัญชีอื่น สมมติว่าธุรกรรม B รวมอยู่ในบล็อก N ในขณะที่ธุรกรรม A รวมอยู่ในรายการการรวมสำหรับบล็อก N+1 นี่คือปัญหาสำคัญ: เมื่อผู้เสนอสร้างรายการการรวม พวกเขาไม่ทราบว่าผู้สร้างจะรวมธุรกรรมใดไว้ในบล็อกปัจจุบัน ในสถานการณ์นี้ ธุรกรรม B ในบล็อก N ทำให้ธุรกรรม A ไม่ถูกต้อง ดังนั้น ผู้สร้างสำหรับบล็อก N+1 จะไม่สามารถสร้างบล็อกที่ถูกต้องได้เนื่องจากธุรกรรม A ในรายการการรวมไม่ถูกต้อง มีการพยายามแก้ไขปัญหานี้โดยใช้ข้อจำกัดเพิ่มเติมภายในรายการรวม อย่างไรก็ตาม ปัญหาหลักยังคงอยู่: EIP-3074 อนุญาตให้จัดการยอดคงเหลือใน EOA อื่นๆ โดยพื้นฐาน การตรวจสอบง่ายๆ เช่น การยืนยันที่อยู่ "ผู้ส่ง" ไม่สามารถตรวจจับการรบกวนระหว่างธุรกรรมรายการรวมและธุรกรรมอื่นๆ ได้ ปัญหาดังกล่าวเรียกว่าปัญหาความพร้อมใช้งานของข้อมูลฟรี ซึ่งกล่าวถึงในบทความ 'No Free Lunch - a new inclusion list design' แม้ว่า EIP-3074 จะถูกแยกออกจากการอัปเกรด Pectra แต่ก็มีฟังก์ชันการทำงานที่คล้ายกัน (EIP-7702) รวมอยู่ด้วย ดังนั้น จะต้องแก้ไขปัญหาเหล่านี้ก่อนจึงจะนำ EIP-7547 มาใช้งานบนเครือข่ายหลักของ Ethereum ได้ นอกจากนี้ EIP-7547 ยังเผชิญกับความท้าทายเพิ่มเติม เช่น ข้อจำกัดที่ผู้เสนอเพียงรายเดียวเท่านั้นที่สามารถสร้างรายการรวมต่อบล็อกได้ ปัจจัยเหล่านี้ทำให้ยากต่อการนำ EIP-7547 ไปใช้กับเครือข่ายหลัก Ethereum ตามที่เป็นอยู่ ดังนั้น EIP-7547 จึงถูกแยกออกจากการอัปเกรด Pectra โฟกัส ไม่มีวิธีแก้ไขปัญหาเหล่านี้หรือไม่? เมื่อไม่นานมานี้ โซลูชันที่เรียกว่า FOCIL (Fork-choice enforced Inclusion Lists) ได้รับความสนใจอย่างมากในระบบนิเวศ Ethereum และถือเป็นโซลูชันที่มีแนวโน้มมากที่สุดที่จะถูกนำไปใช้งานบนเครือข่ายหลักของ Ethereum โดย FOCIL ที่ได้รับการเสนอเป็น ได้แนะนำกลไกที่ไม่เพียงแต่เอนทิตีเดียวแต่หลายเอนทิตีเสนอ Inclusion Lists รายละเอียดและลักษณะเฉพาะของ FOCIL มีดังนี้: EIP-7805 โดยพื้นฐานแล้ว FOCIL ใช้แนวคิด Inclusion List ซึ่งหมายความว่ามีผู้จัดทำรายการธุรกรรมที่ต้องรวมอยู่ในทุกบล็อก และผู้เสนอจะต้องรวมรายการธุรกรรมเหล่านี้ไว้ อย่างไรก็ตาม FOCIL แตกต่างจาก EIP-7547 ในสองประเด็นสำคัญ: แทนที่จะมีผู้เสนอเพียงรายเดียว คณะกรรมการ IL จำนวน 16 คนจะเสนอรายการการรวมอย่างอิสระ รายการรวมที่เสนอสำหรับบล็อก N จะรวมอยู่ในบล็อก N เอง ไม่ใช่บล็อก N+1 รายละเอียดกลไก การสร้าง Inclusion List สำหรับบล็อก N เริ่มต้นเมื่อสล็อตสำหรับบล็อก N-1 เริ่มต้น คณะกรรมการ IL ที่ได้รับการคัดเลือกแบบสุ่มซึ่งประกอบด้วยผู้ตรวจสอบ 16 คนจะได้รับบล็อก N-1 ตั้งเป็นหัวหน้า สร้าง Inclusion List ตามลำดับ และเผยแพร่ผ่าน peer-to-peer กระบวนการก่อสร้างสิ้นสุดลงหลังจากเวลาผ่านไป 9 วินาทีจากช่วง N-1 ที่กินเวลานาน 12 วินาที หลังจากนั้น คณะกรรมการจะไม่สามารถเพิ่มรายการลงในรายการได้อีก เมื่อได้รับรายการเหล่านี้ผ่านเครือข่าย P2P แล้ว ผู้สร้างบล็อก N จะต้องรวมรายการเหล่านี้ไว้ขณะก่อสร้างบล็อก ไม่นานหลังจากเริ่มช่วง N บล็อกจะถูกส่งไปยังผู้เสนอ ผู้ตรวจสอบที่ยืนยันบล็อก N จะเปรียบเทียบธุรกรรมในรายการการรวมที่ได้รับก่อนหน้านี้กับธุรกรรมที่รวมอยู่ในบล็อก N เพื่อให้แน่ใจว่าเป็นไปตามข้อกำหนด ข้อดีของ FOCIL เมื่อเทียบกับ EIP-7547 เมื่อเปรียบเทียบกับ EIP-7547 ที่เสนอไปก่อนหน้านี้ FOCIL มีประโยชน์ดังต่อไปนี้: ความต้านทานการเซ็นเซอร์ที่สูงขึ้น แต่ละสล็อตจะมีคณะกรรมการ IL ซึ่งประกอบด้วยผู้ตรวจสอบ 16 คน ทำหน้าที่จัดทำรายชื่อรวม ซึ่งจะช่วยให้ต้านทานการเซ็นเซอร์ได้ดีกว่า EIP-7547 ที่มีเพียงผู้ตรวจสอบเพียงคนเดียวเท่านั้นที่รับผิดชอบ การใช้งานที่ราบรื่น ด้วยการใช้ API forkChoiceUpdate มาตรฐานที่ใช้โดยไคลเอนต์ฉันทามติ จึงสามารถรวม Inclusion Lists เข้ากับโปรโตคอลได้ง่ายขึ้นและราบรื่นยิ่งขึ้น การต่อต้านการเซ็นเซอร์แบบ “เรียลไทม์” ต่างจาก EIP-7547 ที่รายการการรวมที่เสนอสำหรับบล็อก N+1 ทำให้เกิดความล่าช้า FOCIL จะรวม IL ไว้ในบล็อกที่เสนอสำหรับ N เอง ช่วยให้สามารถรวมธุรกรรมได้โดยไม่เกิดความล่าช้า การสร้างบล็อกและรายการรวมพร้อมกันนี้ช่วยให้มั่นใจได้ว่าสามารถใช้งานร่วมกับกลไกการแยกบัญชีที่เสนอไว้ก่อนหน้านี้ เช่น EIP-3074 หรือ EIP-7702 ได้ บล็อกก่อนหน้านี้ไม่สามารถทำให้ธุรกรรมในรายการรวมเป็นโมฆะได้ ผู้สร้างจะได้รับ IL ก่อนที่จะสรุปการสร้างบล็อก ซึ่งทำให้ผู้สร้างสามารถแยกธุรกรรมใดๆ ที่จะทำให้ IL ไม่ถูกต้องได้ กระบวนการนี้ตรงไปตรงมา: ผู้สร้างจะบันทึกค่า nonce และยอดคงเหลือของ EOA ทั้งหมดที่เกี่ยวข้องกับ IL และอัปเดตค่าเหล่านี้ทุกครั้งที่มีการเปลี่ยนแปลงเกิดขึ้น วิธีการง่ายๆ นี้ช่วยให้ผู้สร้างสามารถตรวจสอบความถูกต้องของธุรกรรม IL และสร้างบล็อกได้สำเร็จ บทบาทของ FOCIL ในบล็อค FOCIL อนุญาตให้มีรายการรวมสูงสุด 16 รายการต่อบล็อก โดยแต่ละรายการมีขนาดสูงสุดที่ 8KB (8192 ไบต์) หากไม่มีการทับซ้อนในธุรกรรมที่เสนอโดยรายการรวม 16 รายการ ขนาดสูงสุดของธุรกรรม IL ในบล็อกเดียวอาจสูงถึง 128KB ข้อจำกัดนี้ได้รับการออกแบบมาเพื่อลดการใช้ทรัพยากรสำหรับผู้ตรวจสอบในขณะที่รายการรวมแพร่กระจายผ่านเครือข่าย P2P ดังนั้น สามารถสร้างบล็อก Ethereum ได้มากเพียงใดโดยใช้ IL ภายใต้ FOCIL? ในอดีต ขนาดบล็อก Ethereum โดยเฉลี่ยอยู่ที่ประมาณ 80–100KB โดยมีสูงสุดประมาณ 300KB หากไม่มีการทับซ้อนในธุรกรรมที่เสนอโดย Inclusion List ทั้ง 16 รายการ ในทางทฤษฎีแล้ว เป็นไปได้ที่จะสร้างบล็อก Ethereum ทั้งหมดโดยใช้เฉพาะธุรกรรม IL อย่างไรก็ตาม สถานการณ์นี้ไม่น่าจะเกิดขึ้น เนื่องจากธุรกรรมใน Inclusion List มักมีแหล่งที่มาจาก mempool สาธารณะ จึงมีความเป็นไปได้สูงที่จะเกิดการทับซ้อนกัน เว้นแต่สมาชิกคณะกรรมการ IL ทั้ง 16 คนจะใช้การกำหนดค่าที่แตกต่างกันโดยสิ้นเชิง โดยสรุป ธุรกรรมใน Inclusion Lists ของ FOCIL คาดว่าจะครอบครองระหว่าง 6–10% และสูงถึง 100% ของบล็อก Ethereum โดยกรณีต่างๆ จะมีแนวโน้มเข้าใกล้ช่วง 6–10% โดยมีเงื่อนไขว่าสมาชิกคณะกรรมการ IL กำลังพิจารณา mempool สาธารณะเดียวกัน เหนือกว่า FOCIL: การรวม APS เข้ากับ FOCIL ความเป็นมาของ APS เหตุผลหนึ่งที่ FOCIL กลายมาเป็นโซลูชันชั้นนำก็คือ การทำงานร่วมกันที่มีศักยภาพกับข้อเสนอ Attester-Proposer Separation (APS) เช่น APS คืออะไร และช่วยเสริม FOCIL ได้อย่างไร Execution Tickets APS เสนอให้แยกบทบาทของผู้เสนอและผู้รับรองสำหรับบล็อก ใน Ethereum การสร้างบล็อกภายใต้ PBS เกี่ยวข้องกับการแบ่งบทบาทระหว่างผู้เสนอที่เสนอบล็อกและผู้สร้างที่สร้างเนื้อหาบล็อก สิ่งนี้จะป้องกันไม่ให้กลุ่มการเดิมพันแบบรวมศูนย์ที่ก่อตั้งโดยพันธมิตรผู้เสนอและผู้สร้างผูกขาดผลกำไร MEV และบันทึก APR ที่สูงกว่าผู้ตรวจสอบปกติมาก ซึ่งอาจทำให้การดำเนินการของผู้ตรวจสอบรวมศูนย์ได้ ปัญหาได้รับการแก้ไขผ่าน MEV-Boost และมีการเสนอระบบรีเลย์ในโปรโตคอล (ePBS) เพื่อแก้ไขข้อกังวลด้านการรวมอำนาจที่เหลืออยู่ อย่างไรก็ตาม PBS เป็นโครงสร้างที่เหมาะสมที่สุดจริงหรือ บทบาทสำคัญอย่างหนึ่งของเลเยอร์ฉันทามติของ Ethereum คือการแจกจ่ายรางวัลและกำหนดบทลงโทษต่อผู้ตรวจสอบ หากกระบวนการนี้กลายเป็นแบบรวมศูนย์ เชนจะได้รับผลกระทบจากเอนทิตีแบบรวมศูนย์ โดยไม่คำนึงถึงการโหวตของผู้ตรวจสอบ ดังนั้น เลเยอร์ฉันทามติควรยังคงกระจายอำนาจอย่างมาก อย่างไรก็ตาม เลเยอร์การดำเนินการไม่มีข้อจำกัดเหมือนกัน งานต่างๆ เช่น การสกัด MEV และการสั่งธุรกรรมนั้นมีความซับซ้อนและมีกลยุทธ์ในตัว จำเป็นต้องมีเอนทิตีแบบรวมศูนย์ หากงานเหล่านี้ถูกกำหนดให้กับผู้ตรวจสอบทั้งหมด ก็จะผลักดันให้ห่วงโซ่มุ่งไปสู่การรวมศูนย์ ในเรื่องนี้ ปรัชญาของ Ethereum คือ 'ผู้เข้าร่วมที่มีฉันทามติไม่ควรได้รับแรงจูงใจให้ทำตามภารกิจที่ซับซ้อนเพื่อผลกำไรส่วนบุคคล' ผ่านทาง PBS Ethereum จะแยกผู้ตรวจสอบออกจากผู้ดำเนินการ MEV (ผู้สร้าง ผู้ค้นหา) เพื่อกระจายกำไร MEV อย่างเท่าเทียมกันไปทั่วทั้งเครือข่าย อย่างไรก็ตาม ผู้เสนอสามารถใช้กลยุทธ์ที่ไม่ธรรมดาเพื่อให้ได้กำไรเพิ่มเติม: การสมคบคิดระหว่างผู้เสนอราคาและผู้สร้าง ผู้สร้างนั้นรวมศูนย์อยู่แล้ว แต่ผู้เสนอก็แสดงการรวมศูนย์บางส่วนด้วย ตัวอย่างเช่น Coinbase ถือครองประมาณ 10% ของ ETH ทั้งหมดที่ถือครอง หาก Coinbase สมคบคิดกับผู้สร้างรายใดรายหนึ่งเพื่อยอมรับเฉพาะบล็อกของตนเท่านั้น ก็จะทำให้เกิดเวกเตอร์การรวมศูนย์ที่สำคัญในระบบนิเวศ เกมจับเวลาผู้เสนอ เวลาบล็อก 12 วินาทีที่ค่อนข้างยาวนานของ Ethereum ทำให้เกิดพลวัตที่น่าสนใจที่เรียกว่าเกมการกำหนดเวลา ซึ่งผู้เสนอจะเลื่อนการเผยแพร่บล็อกเพื่อเพิ่มผลกำไร MEV ให้สูงสุด โดยทั่วไปแล้ว MEV ที่มีอยู่ในบล็อกจะเพิ่มขึ้นแบบเชิงเส้นเมื่อเวลาผ่านไป ผู้เสนอสามารถเลื่อนการเผยแพร่แบบบล็อกออกไปเพื่อเพิ่ม MEV ให้ได้มากที่สุด โดยเผยแพร่ก่อนที่จะเสี่ยงต่อการถูกปฏิเสธจากผู้เสนอรายต่อไป ดังนั้น ผู้เสนอสามารถเลื่อนการเผยแพร่บล็อกได้นานแค่ไหนภายในช่วงเวลาเดียว (12 วินาที) ตามข้อกำหนดของโปรโตคอล Ethereum เพื่อให้ผู้เสนอรายต่อไปพิจารณาว่าบล็อกก่อนหน้านี้ถูกต้อง บล็อกจะต้องได้รับคะแนนเสียงจากผู้ตรวจสอบ (ผู้รับรอง) 40% ที่ได้รับมอบหมายให้คณะกรรมการในช่วงเวลาก่อนหน้านี้ บนเครือข่าย Ethereum หลักในปัจจุบัน จุดที่ได้รับคะแนนเสียงผู้ตรวจสอบ 40% จะเกิดขึ้นภายในเวลาประมาณ 3.8 วินาทีหลังจากเริ่มสล็อต ผู้เสนอที่พยายามเล่นเกมจับเวลา จะต้องนำกลยุทธ์ในการยืดเวลาการเผยแพร่แบบเป็นบล็อกออกไปให้นานที่สุดเท่าที่จะเป็นไปได้ โดยรอจนกว่าจะได้รับคะแนนเสียงเพียงพอ (40% หรือมากกว่า) เพื่อหลีกเลี่ยงการปฏิเสธจากผู้เสนอรายต่อไป อย่างไรก็ตาม ผลลัพธ์ไม่ได้สอดคล้องกับเจตนาของผู้เสนอเสมอไป หากบล็อกไม่ได้รับคะแนนโหวต 40% ผู้เสนอรายต่อไปจะปฏิเสธบล็อกนั้น ในกรณีดังกล่าว ผู้ตรวจสอบที่โหวตให้กับบล็อกที่ถูกปฏิเสธจะโหวตให้กับบล็อกที่ไม่อยู่ในห่วงโซ่หลัก ส่งผลให้มีการลดโทษ หากสถานการณ์นี้ยังคงเกิดขึ้น ผู้ตรวจสอบอาจเลื่อนการโหวตของตนออกไปเพื่อสังเกตสถานะของเครือข่ายและให้แน่ใจว่าการโหวตของตนถูกต้อง พฤติกรรมดังกล่าวอาจเพิ่มจำนวนการจัดระเบียบใหม่ในห่วงโซ่ได้ โดยสรุป เกมการกำหนดเวลาของผู้เสนออาจส่งผลกระทบเชิงลบต่อผลลัพธ์ตามฉันทามติของ Ethereum และจะต้องป้องกัน บทบาทของ APS APS เป็นโซลูชันที่ออกแบบมาเพื่อแก้ไขปัญหานี้ APS เสนอให้สร้างผู้เสนอแยกต่างหากสำหรับเลเยอร์การดำเนินการ โดยแยกเลเยอร์ฉันทามติจาก MEV อย่างสมบูรณ์ ตัวอย่างเช่น ข้อเสนอ APS ตัวแทนหนึ่งรายการคือ Execution Ticket ซึ่งแนะนำ "ผู้เสนอการดำเนินการ" ที่แตกต่างจากผู้เสนอบีคอนเชน ในระบบนี้ โปรโตคอลจะสร้างและขายตั๋วการดำเนินการ ซึ่งให้สิทธิ์แก่ผู้ถือตั๋วในการได้รับเลือกแบบสุ่มเป็นผู้เสนอการดำเนินการสำหรับแต่ละบล็อก ผู้เสนอการดำเนินการเหล่านี้จะทำหน้าที่ในส่วนที่ผู้เสนอบีคอนเชนใน MEV-Boost ดำเนินการอยู่ โดยรับเพย์โหลดการดำเนินการและเสนอเพย์โหลดเหล่านั้น เหตุผลเบื้องหลังการออกแบบนี้คือเพื่อการรวมศูนย์ผู้เสนอการดำเนินการไม่ใช่เรื่องยุ่งยาก จริงๆ แล้ว การแยกพวกเขาออกจากเลเยอร์ฉันทามติจะช่วยปรับปรุงระบบโดยรวมให้ดีขึ้น แล้วงานอะไรที่ผู้เสนอบีคอนเชนจะจัดการภายใต้ APS? นอกเหนือจากการจัดการเงินฝากของผู้ตรวจสอบ รางวัล และค่าปรับ (การเปลี่ยนแปลงสถานะภายในเชนบีคอน) ผู้เสนอเลเยอร์ฉันทามติยังมีบทบาทสำคัญใน APS ด้วย นั่นคือการสร้างรายการการรวมและส่งต่อไปยังเลเยอร์การดำเนินการ เป็นที่พึงปรารถนามากกว่าที่ Inclusion List จะพึ่งพาชุดตัวตรวจสอบแบบกระจายอำนาจของเลเยอร์ฉันทามติ แทนที่จะใช้ผู้เสนอการดำเนินการแบบรวมศูนย์มากกว่า ซึ่งจะช่วยลดโอกาสที่ผู้โจมตีเซ็นเซอร์จะสมคบคิดกับผู้เสนอเพื่อเซ็นเซอร์ธุรกรรม ดังนั้นข้อเสนอ APS เช่น Execution Ticket จึงแนะนำกลไกที่ผู้ตรวจสอบชั้นฉันทามติสร้างรายการการรวมเป็นส่วนหนึ่งของบล็อกบีคอน จากนั้นรายการเหล่านี้จะทำหน้าที่เป็นพื้นฐานสำหรับผู้เสนอการดำเนินการเพื่อสร้างและเสนอบล็อกเต็ม โดยสรุป โซลูชันการต้านทานการเซ็นเซอร์ตาม Inclusion List สอดคล้องกับวิสัยทัศน์ของ Ethereum สำหรับ APS อย่างสมบูรณ์แบบ ดังนั้น FOCIL จึงถือเป็นหนึ่งในโซลูชันที่มีแนวโน้มมากที่สุดสำหรับการต้านทานการเซ็นเซอร์ ข้อดีของ FOCIL FOCIL รับประกันการต้านทานการเซ็นเซอร์ที่มีประสิทธิภาพ ในขณะที่ยังคงรักษาการใช้ทรัพยากรเครือข่ายในระดับที่เหมาะสม โดยจำกัด IL แต่ละรายการให้มีขนาด 8KB และมีคณะกรรมการ IL ที่ประกอบด้วยผู้ตรวจสอบ 16 ราย (ซึ่งเท่ากับขนาดของ blob หนึ่งรายการ) แผนภูมิด้านล่างแสดงให้เห็นว่าธุรกรรมใช้เวลานานเท่าใดจึงจะรวมอยู่ในห่วงโซ่ โดยขึ้นอยู่กับเปอร์เซ็นต์ของผู้ตรวจสอบที่ซื่อสัตย์ในคณะกรรมการ IL แม้ว่าจะมีผู้ตรวจสอบเพียง 15% ในคณะกรรมการที่ไม่เซ็นเซอร์ ธุรกรรมก็ยังสามารถรวมอยู่ในห่วงโซ่ได้ทันที ซึ่งแสดงให้เห็นว่าคณะกรรมการขนาดเล็กที่มีผู้ตรวจสอบเพียง 16 คนสามารถต้านทานการเซ็นเซอร์ได้อย่างมีประสิทธิภาพ วิธีแก้ปัญหาที่เป็นไปได้ 2: ผู้เสนอ/ผู้สร้างพร้อมกันหลายราย จะเป็นอย่างไรหากผู้เข้าร่วมหลายคนเสนอบล็อกทั้งหมดพร้อมกัน แนวคิดนี้เรียกว่า "ผู้เสนอพร้อมกันหลายราย" แทนที่เอนทิตีเดียวจะเสนอบล็อกในแต่ละครั้ง เอนทิตีหลาย ๆ ตัวจะเสนอบล็อกพร้อมกันสำหรับสล็อตเดียวกัน ภายใต้เงื่อนไขบางประการ การนำโซลูชันดังกล่าวมาใช้สามารถเพิ่มต้นทุนการเซ็นเซอร์ได้อย่างมาก Ethereum มีกลไกที่เปิดเผยผู้เสนอ 32 บล็อกในแต่ละยุคพร้อมกัน การตั้งค่านี้ช่วยให้เกิดสถานการณ์ที่ใครบางคนอาจพยายาม "ติดสินบน" ผู้เสนอเพื่อเซ็นเซอร์ธุรกรรมเฉพาะ แต่จะเกิดอะไรขึ้นหากบล็อกไม่ได้ถูกเสนอโดยบุคคลเดียวแต่โดยผู้เสนอ N รายพร้อมกัน ในสถานการณ์นี้ การใช้กลไกเช่นคำแนะนำแบบมีเงื่อนไขทำให้สามารถแนะนำ "ทางเลือกที่ยากลำบาก" ให้กับผู้เสนอ N ราย ส่งผลให้ต้นทุนการเซ็นเซอร์เพิ่มขึ้นอย่างมาก ตัวอย่างเช่น ลองนึกภาพสถานการณ์ที่ผู้เสนอ N รายได้รับมอบหมายให้สร้างบล็อก อลิซขอให้พวกเขารวมธุรกรรมของเธอเข้าไป และบ็อบกำลังพยายามเซ็นเซอร์ธุรกรรมของอลิซ อลิซสามารถเสนอสินบนให้กับผู้เสนอเพื่อรวมธุรกรรมของเธอเข้าไป ในขณะที่บ็อบสามารถติดสินบนพวกเขาเพื่อให้เซ็นเซอร์ธุรกรรมนั้นได้เช่นกัน ในสถานการณ์นี้ อลิซสามารถใช้กลยุทธ์การติดสินบนที่เพิ่มต้นทุนการเซ็นเซอร์ของบ็อบได้อย่างมีประสิทธิภาพ ดังนี้: หากมีผู้เสนอสองรายขึ้นไปรวมธุรกรรมไว้ด้วย อลิซจะให้คำแนะนำเล็กๆ น้อยๆ แก่ผู้เสนอแต่ละราย หากมีผู้เสนอเพียงรายเดียวที่รวมธุรกรรมนี้ไว้ อลิซจะทิป T จำนวนมากให้กับผู้เสนอรายนั้น ในกรณีนี้ ผู้เสนอจะพบว่าตัวเองอยู่ในสถานการณ์ที่คล้ายกับ "นักโทษแห่งทางตัน" กลยุทธ์ที่ดีที่สุดสำหรับผู้เสนอแต่ละคนในเกมนี้คือการรวมธุรกรรมไว้ด้วยกันแทนที่จะเซ็นเซอร์มัน หากต้องการให้ Bob เซ็นเซอร์ธุรกรรมของ Alice ได้สำเร็จ เขาจะต้องติดสินบนผู้เสนอทั้งหมด N ราย ทำให้เขาต้องเสียเงิน NT ในทางกลับกัน Alice จำเป็นต้องใช้เงิน NT เพียงเล็กน้อยเพื่อให้แน่ใจว่าธุรกรรมของเธอถูกรวมไว้ด้วยกัน ซึ่งจะทำให้ต้นทุนการเซ็นเซอร์เพิ่มขึ้นอย่างมาก แนวคิดนี้สามารถนำไปใช้กับ PBS ได้หลายวิธี เช่น ผู้เสนอหลายรายสามารถสร้างบล็อกได้พร้อมกัน หรือผู้สร้างหลายรายสามารถสร้างบล็อกได้พร้อมกัน หัวข้อนี้จะแนะนำกลไกสองประการในการบรรลุผลดังกล่าวภายในโครงสร้าง PBS: BRAID - ผู้เสนอพร้อมกันหลายราย BuilderNet - โปรแกรมสร้างหลายโปรแกรมพร้อมกัน ถักเปีย ภาพรวมของ BRAID BRAID เป็นโซลูชันต้านทานการเซ็นเซอร์ Ethereum ที่ได้รับการเสนอโดย Max Resnick ซึ่งเป็นส่วนหนึ่งของกลุ่มกลไกพิเศษ กลไกดังกล่าวมีพื้นฐานมาจากแนวคิดที่เรียบง่ายแต่ทรงพลัง นั่นคือ แทนที่จะรันเชนเดียวอย่างที่ Ethereum ทำอยู่ในปัจจุบัน เชน LMD-GHOST ที่ซิงโครไนซ์กัน k เชนจะทำงานแบบคู่ขนาน กล่าวอีกนัยหนึ่ง ด้วย BRAID ผู้เสนอ k คนจะสร้างบล็อกของตนเองสำหรับแต่ละสล็อตพร้อมกัน BRAID ทำงานอย่างไร คำถามที่ชัดเจนเกิดขึ้น: บล็อก k บล็อกได้รับการประมวลผลอย่างไร เนื่องจากบล็อกเหล่านี้จะต้องถูกรวมเข้าเป็นหนึ่งเดียวเพื่อรักษาบล็อคเชนเดียว BRAID จึงใช้กฎการจัดลำดับที่กำหนดไว้ล่วงหน้าเพื่อรวมบล็อกเหล่านี้เข้าด้วยกัน ตัวอย่างเช่น บล็อกต่างๆ สามารถรวมกันได้โดยการลบรายการที่ซ้ำกันและเรียงลำดับธุรกรรมตามลำดับค่าธรรมเนียมที่ลดลง จากนั้นบล็อกที่เสร็จสมบูรณ์จะประกอบด้วยธุรกรรมที่รวบรวมและเรียงลำดับแล้ว ข้อดีและข้อจำกัด BRAID มีข้อดีหลายประการ: ความต้านทานการเซ็นเซอร์ที่แข็งแกร่ง การให้ผู้เสนอหลายรายทำงานพร้อมๆ กันนั้น ทำให้ BRAID เพิ่มต้นทุนการเซ็นเซอร์อย่างมาก เนื่องจากจะต้องมีการให้สินบนแก่หน่วยงานหลายราย การสั่งการธุรกรรมแบบบังคับ กลไกนี้จะกำหนดการสั่งธุรกรรมอย่างชัดเจน ทำให้เหมาะกับการใช้งาน เช่น การประมูลแบบออนเชนแบบเรียลไทม์ที่มีความอ่อนไหวต่อลำดับธุรกรรม โปรดทราบว่านี่ไม่ใช่ข้อได้เปรียบเสมอไป เนื่องจากสิ่งนี้จะป้องกันไม่ให้แอปพลิเคชันบางตัวนำกฎการเรียงลำดับเฉพาะแอปของตัวเองไปใช้งาน อย่างไรก็ตาม BRAID ก็มีข้อจำกัดเช่นกัน เนื่องจาก k chain ทั้งหมดต้องซิงโครไนซ์กัน ผู้ตรวจสอบจึงต้องใช้ทรัพยากรเครือข่ายเพิ่มเติม ซึ่งขัดกับเป้าหมายของ Ethereum ที่ต้องการลดข้อกำหนดของผู้ตรวจสอบ บิลเดอร์เน็ต ภาพรวมของ BuilderNet BuilderNet เป็นโซลูชั่นที่ Flashbots เสนอเพื่อเพิ่มความต้านทานการเซ็นเซอร์โดยอนุญาตให้เอนทิตีหลายตัวทำหน้าที่เป็นผู้สร้างบล็อกพร้อมกัน BuilderNet เวอร์ชันเริ่มต้นใช้โมเดลผู้ดำเนินการหลายราย โดยที่หน่วยงานต่างๆ หลายแห่งดำเนินการโปรแกรมสร้างเดียวโดยปฏิบัติตามแนวทางการกำกับดูแลที่แตกต่างกัน วิธีนี้ช่วยให้ทนทานต่อการเซ็นเซอร์ได้ดีกว่าโปรแกรมสร้างที่มีผู้ดำเนินการรายเดียว BuilderNet ถือเป็นก้าวสำคัญในการสร้างโซลูชันโปรแกรมสร้างพร้อมกันหลายรายการ BuilderNet รุ่นแรกนั้นดำเนินการร่วมกันโดย Flashbots, Beaverbuild และ Nethermind และมีแผนที่จะรับผู้สร้างรายอื่นๆ เพิ่มเติมในอนาคต แผนการกระจายอำนาจในอนาคตสำหรับ BuilderNet ปัจจุบันโมเดลผู้ปฏิบัติการหลายรายยังคงปรากฏเป็นผู้สร้างรายเดียวต่อผู้สังเกตการณ์ภายนอก ซึ่งจำกัดระดับการต้านทานการเซ็นเซอร์ที่สามารถทำได้ การเปิดตัว BuilderNet ในอนาคตมีจุดมุ่งหมายเพื่อกระจายเครือข่ายให้กว้างขึ้นและเพิ่มการต้านทานการเซ็นเซอร์ผ่านการเปลี่ยนแปลงต่อไปนี้: การแบ่งปันลำดับขั้นตอนระหว่างผู้สร้าง BuilderNet เวอร์ชันในอนาคตจะกระจายกระบวนการสร้างบล็อก ทำให้ผู้สร้างรายหนึ่งสามารถเลือกธุรกรรมที่ถูกเซ็นเซอร์โดยผู้สร้างอีกรายหนึ่งได้ ในทางทฤษฎี ตราบใดที่มีผู้สร้างที่ไม่เซ็นเซอร์อย่างน้อยหนึ่งราย ธุรกรรมของผู้ใช้ทั้งหมดจะยังคงรวมอยู่ในบล็อกได้ คาดว่าแนวทางนี้จะพัฒนา BuilderNet ให้เป็นโมเดล Multiple Concurrent Builder อย่างแท้จริง โครงสร้างพื้นฐานแบบกระจายอำนาจ BuilderNet เวอร์ชันปัจจุบันใช้โครงสร้างพื้นฐานแบบรวมศูนย์สำหรับการรับธุรกรรมและการจัดเก็บข้อมูล และการมีส่วนร่วมต้องได้รับอนุญาต เวอร์ชันในอนาคตมีจุดมุ่งหมายเพื่อแก้ไขปัญหานี้โดยทำให้ BuilderNet ไม่ต้องมีการอนุญาต TEE เพื่อ UX และ DX ที่ดีขึ้น BuilderNet ยังสร้างสภาพแวดล้อมที่เป็นมิตรต่อผู้ใช้มากยิ่งขึ้นสำหรับแอป กระเป๋าสตางค์ โปรแกรมค้นหา และผู้ใช้โดยใช้ประโยชน์จากสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ TEE ช่วยให้แน่ใจว่าซอฟต์แวร์ทำงานตามที่กำหนดไว้โดยอิงตามความน่าเชื่อถือของฮาร์ดแวร์ ซึ่งจะช่วยป้องกันไม่ให้ผู้สร้างละเว้นข้อมูลหรือแก้ไขโค้ดโดยพลการ การใช้ BuilderNet ช่วยให้ผู้ค้นหาได้รับการรับประกันที่สูงขึ้นเมื่อส่งชุดข้อมูลไปยังผู้สร้าง เนื่องจาก TEE จะบังคับใช้การดำเนินการตามตรรกะการแจกจ่ายรางวัลแก่ผู้ค้นหาที่ร่วมสร้างบล็อก หากตรรกะการแจกจ่ายรางวัลมีความยุติธรรมเพียงพอ ผู้ค้นหาจะได้รับการรับประกันทางเศรษฐกิจที่เทียบได้กับสัญญาอย่างเป็นทางการกับผู้สร้าง นอกเหนือจากโปรแกรมค้นหา แอป และกระเป๋าเงินที่ต้องการจับภาพ MEV ยังสามารถได้รับประโยชน์จากสถาปัตยกรรมของ BuilderNet อีกด้วย BuilderNet ใน L2s ลักษณะที่น่าสังเกตอย่างหนึ่งของ BuilderNet คือความสามารถในการนำไปใช้กับโซลูชั่นเลเยอร์ 2 Ethereum L2 กำลังพัฒนาระบบพิสูจน์และสถาปัตยกรรมตัวตรวจสอบแบบกระจายอำนาจเพื่อสืบทอดความปลอดภัยของ Ethereum แม้ว่าระบบเหล่านี้จะช่วยรับประกันความปลอดภัยของเงินของผู้ใช้ในบริดจ์ แต่ก็ไม่ได้สืบทอดความต้านทานการเซ็นเซอร์ของ Ethereum ในปัจจุบันกลไกธุรกรรมบังคับสำหรับธุรกรรม L1 ถึง L2 ใช้เวลาไม่เกิน 12–24 ชั่วโมง (ขึ้นอยู่กับการออกแบบ) เพื่อรวมธุรกรรมใน L2 ซึ่งล้มเหลวในการให้ความต้านทานการเซ็นเซอร์แบบเรียลไทม์ การเอาท์ซอร์สการสร้างบล็อกให้กับ BuilderNet ทำให้ L2 สามารถต้านทานการเซ็นเซอร์ได้ดีกว่าซีเควนเซอร์เดี่ยว พร้อมทั้งเปิดใช้งานการแจกจ่าย MEV ผ่านการสั่งธุรกรรมที่บังคับใช้ด้วย TEE ซึ่งคล้ายกับสถาปัตยกรรมอย่าง Unichain บทสรุป ในทางอุดมคติ บล็อคเชนควรต้านทานการเซ็นเซอร์ และชุมชน Ethereum ได้เสนอโซลูชันต่างๆ เพื่อแก้ไขปัญหาความต้านทานการเซ็นเซอร์ที่เกิดจากการรวมศูนย์ของผู้สร้าง โซลูชันที่มีแนวโน้มมากที่สุดคือ FOCIL ซึ่งผู้ตรวจสอบ 16 รายเสนอรายการการรวมสำหรับแต่ละบล็อก ซึ่งให้ความต้านทานการเซ็นเซอร์ที่มีประสิทธิภาพและเข้ากันได้กับ APS คาดว่าจะมีการหารือเกี่ยวกับ FOCIL เพื่อรวมไว้ในการอัปเกรด Fusaka ที่กำหนดไว้ในช่วงปลายปี 2025 หรือต้นปี 2026 ในเวลาเดียวกัน การอภิปรายเกี่ยวกับโมเดล Multiple Concurrent Builder ที่นำโดย Flashbots ยังคงดำเนินต่อไป การกระจายอำนาจของตัวสร้างอาจช่วยปรับปรุงความต้านทานการเซ็นเซอร์ของ Ethereum ได้อย่างมาก และสามารถนำมาใช้ได้โดยไม่ขึ้นกับการพัฒนา Ethereum หลัก ทำให้นำไปใช้ได้รวดเร็วยิ่งขึ้น ด้วยความคิดริเริ่มเหล่านี้ Ethereum จึงก้าวหน้าอย่างต่อเนื่องไปสู่ชั้นการดำเนินการที่เป็นกลางอย่างน่าเชื่อถือ ซึ่งไม่มีหน่วยงานใดหน่วยงานหนึ่งมีอิทธิพลที่ไม่เหมาะสมเหนือการรวมธุรกรรม ด้วยการรวมรายการการรวมที่ขับเคลื่อนโดยผู้ตรวจสอบของ FOCIL เข้ากับการกระจายอำนาจที่เป็นไปได้ของผู้สร้างบล็อก Ethereum สามารถเพิ่มความยืดหยุ่นต่อการเซ็นเซอร์ในขณะที่ยังคงประสิทธิภาพและความยุติธรรมในการแจกจ่าย MEV ในขณะที่โซลูชันเหล่านี้พัฒนาขึ้น เครือข่ายยังคงยึดมั่นในหลักการพื้นฐานของการกระจายอำนาจ การเข้าถึงโดยไม่ต้องขออนุญาต และความเป็นกลาง เพื่อให้แน่ใจว่า Ethereum ยังคงเป็นชั้นการชำระเงินที่แข็งแกร่งและต้านทานการเซ็นเซอร์ในอนาคต บทความเวอร์ชันนี้ได้รับการตีพิมพ์ครั้งแรก - ที่นี่