คำอธิบายโดยละเอียดของโมดูลาร์ MEV: ทำอย่างไรจึงจะมีการสั่งซื้อธุรกรรมที่ยุติธรรม?

ผู้เขียนต้นฉบับ: Maven 11

ต้นฉบับเรียบเรียง: ลูฟี่, Foresight News

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

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

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

กฎการเรียงลำดับที่ตรวจสอบได้ (ต่อไปนี้จะเรียกว่า VSR) เป็นหนึ่งในโอกาสที่น่าสนใจที่ได้รับจากการสั่งซื้อแบบควบคุม โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนาที่สนใจในการสร้างระบบการซื้อขายที่ ยุติธรรมกว่า ในแง่ของการดำเนินการ เห็นได้ชัดว่าการสูญเสียของผู้ให้บริการสภาพคล่องเกี่ยวข้องกับการปรับสมดุล (LVR) อย่างไรนั้นอยู่นอกเหนือขอบเขตของบทความนี้ ดังนั้นเราจะหลีกเลี่ยงการพูดถึงประเด็นนี้มากเกินไป โปรดทราบว่าการตั้งค่าที่เรากำลังจะอธิบายนั้นมีไว้สำหรับ AMM เป็นหลัก ไม่ใช่รูปแบบสมุดคำสั่งซื้อ นอกจากนี้ CLOB (และแม้แต่ CEX) จะได้รับประโยชน์อย่างมากจากการใช้ประโยชน์จากการเปรียบเทียบที่ตรวจสอบได้ซึ่งเหมาะสมกับการตั้งค่าเฉพาะของพวกเขา ในการตั้งค่าแบบ off-chain มีความต้องการที่ชัดเจนสำหรับแนวคิดบางประการเกี่ยวกับความรู้เป็นศูนย์หรือการดำเนินการในแง่ดีซึ่งได้รับการสนับสนุนโดยความปลอดภัยทางเศรษฐกิจแบบเข้ารหัสลับ

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

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

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

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

ในกระดาษการออกแบบการแลกเปลี่ยนแบบกระจายอำนาจที่เชื่อถือได้ผ่านกฎการสั่งซื้อที่ตรวจสอบได้”, มาธีอุส วี. ในกรณีที่ไม่ปฏิบัติตามกฎที่ตั้งไว้ ผู้สังเกตการณ์สามารถสร้างข้อพิสูจน์ความล้มเหลวได้ (หรือเนื่องจากข้อจำกัดสามารถตรวจสอบได้ทางคณิตศาสตร์ คุณจึงสามารถจินตนาการถึงวงจร ZK ที่มีข้อจำกัดเหล่านี้ได้ ซึ่งใช้ ZKP เป็นข้อพิสูจน์ความถูกต้อง) แนวคิดหลักคือเพื่อให้ผู้ใช้ปลายทาง (เทรดเดอร์) ได้รับการรับประกันราคาดำเนินการ การรับประกันนี้ทำให้แน่ใจได้ว่าการซื้อขายจะดำเนินการในราคาเดียวกับการซื้อขายเดียวในบล็อก (เห็นได้ชัดว่า มีเวลาแฝงในระดับหนึ่งที่เกี่ยวข้องที่นี่ หากเราถือว่าการสั่งซื้อ/ขาย/ซื้อ/ขายตามลำดับก่อนหลังได้ก่อน ) )) แนวคิดพื้นฐานของข้อเสนอในรายงานคือกฎการสั่งซื้อเหล่านี้จะจำกัดผู้สร้าง (ในสถานการณ์ PBS) หรือผู้สั่งซื้อให้รวมธุรกรรมในทิศทางเดียวกันเท่านั้นหากดำเนินการในราคาที่ดีกว่าราคาที่มีอยู่ในด้านบน ของบล็อก (เช่น ขาย/ขาย) นอกจากนี้ หากมีสถานการณ์ที่คุณขายเมื่อสิ้นสุดชุดการซื้อ การขายจะไม่ได้รับการดำเนินการ (เช่น ซื้อ ซื้อ ขาย) ซึ่งอาจบ่งชี้ว่าผู้ค้นหา (หรือผู้สร้าง) / เครื่องคัดแยก) ใช้การซื้อเหล่านี้เพื่อผลักดันราคาให้อยู่ในความโปรดปราน โดยพื้นฐานแล้วหมายความว่ากฎของโปรโตคอลรับประกันว่าผู้ใช้จะไม่ถูกใช้เพื่อให้ราคาที่ดีกว่าแก่ผู้อื่น (เช่น MEV) หรือมีราคาหลุดเนื่องจากค่าธรรมเนียมลำดับความสำคัญ แน่นอนว่าข้อเสียเปรียบของกฎนี้ (ในกรณีของการขายมากกว่าการซื้อ หรือในทางกลับกัน) ก็คือคุณอาจได้ราคาหางยาวที่ค่อนข้างต่ำ

สำหรับแพลตฟอร์มสัญญาอัจฉริยะทั่วไป แทบเป็นไปไม่ได้เลยที่จะถือว่ากฎเหล่านี้เป็นกฎการสร้างออนไลน์ที่แท้จริง เนื่องจากคุณไม่สามารถควบคุมการดำเนินการและการสั่งซื้อได้ ในเวลาเดียวกัน คุณกำลังแข่งขันกับผู้อื่น ดังนั้นการพยายามบังคับให้ผู้ที่อยู่ด้านบนสุดของบล็อกจ่ายค่าธรรมเนียมที่มีลำดับความสำคัญจะมีราคาแพงโดยไม่จำเป็น หนึ่งในคุณสมบัติของการตั้งค่าแบบโมดูลาร์คือช่วยให้นักพัฒนาแอปพลิเคชันสามารถปรับแต่งวิธีการทำงานของสภาพแวดล้อมการดำเนินการได้ ไม่ว่าจะเป็นการจัดเรียง การใช้ VM อื่น หรือการเปลี่ยนแปลงแบบกำหนดเองกับ VM ที่มีอยู่ (เช่น การเพิ่ม opcode ใหม่หรือการเปลี่ยนแปลงขีดจำกัดของแก๊ส) ขึ้นอยู่กับนักพัฒนาซอฟต์แวร์ และผลิตภัณฑ์ของพวกเขาจริงๆ

ในกรณีของ Rollup โดยใช้ความพร้อมใช้งานของข้อมูล ชั้นฉันทามติ และชั้นการชำระสภาพคล่อง การตั้งค่าที่เป็นไปได้มีดังนี้:

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

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

แนวคิดที่น่าสนใจอีกประการหนึ่งที่เรากล่าวถึงในโพสต์ที่แล้วคือการใช้เทคโนโลยีที่บุกเบิกโดย Eric Budish ผู้เป็นตำนานและเพื่อนร่วมงานของเขาการประมูลเป็นกลุ่มบ่อยครั้ง (FBA)การประมวลผลธุรกรรมในการประมูลเป็นชุดแทนที่จะเป็นแบบอนุกรม นี่คือเพื่อช่วยระบุความต้องการที่ทับซ้อนกัน (CoW) และรวมโอกาสในการเก็งกำไรเข้ากับการออกแบบกลไกตลาด นอกจากนี้ยังช่วย ต่อต้าน เกมแฝงในการสร้างบล็อกต่อเนื่องกัน (หรือสงครามค่าธรรมเนียมลำดับความสำคัญในบล็อกอนุกรม) ขอขอบคุณ Michael Jordan (DBA) ที่นำบทความนี้มาให้เราทราบและสำหรับงานของเขาในการลด Latency Roast การใช้สิ่งนี้เป็นส่วนหนึ่งของกฎการเลือกส้อมและการสั่งซื้อของ Rollup ก็เป็นคุณสมบัติที่น่าสนใจที่นักพัฒนาสามารถใช้ได้ การตั้งค่า เราได้เห็นแล้ว ได้รับแรงผลักดันอย่างมากในปีที่ผ่านมา โดยเฉพาะอย่างยิ่งกับ Penumbra และ CoWSwap การตั้งค่าที่เป็นไปได้ประการหนึ่งมีลักษณะดังนี้:

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

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

นอกจากนี้ยังควรชี้ให้เห็นว่าการออกแบบที่คล้ายกับที่เราเพิ่งแนะนำนั้นมีการพูดคุยกันในฟอรัม Ethresear.ch ย้อนกลับไปในปี 2018 (ดูที่นี่). ในโพสต์ พวกเขากล่าวถึงเอกสารสองฉบับที่ให้กลไกการประมูลแบบเป็นชุดบน Plasma (เรียงลำดับจากพรีเควลไปจนถึง Rollup สมัยใหม่) โดยแต่ละชุดจะยอมรับคำสั่งซื้อเพื่อซื้อโทเค็น ERC 20 อื่น ๆ ในราคาที่จำกัดสูงสุด คำสั่งซื้อเหล่านี้จะถูกรวบรวมในช่วงเวลาหนึ่งและจัดให้มีราคาชำระที่สม่ำเสมอสำหรับคู่การซื้อขายโทเค็นทั้งหมด แนวคิดทั่วไปเบื้องหลังโมเดลนี้คือ จะช่วยขจัดปรากฏการณ์ที่เกิดขึ้นในแนวหน้าซึ่งพบได้ทั่วไปใน AMM ที่ได้รับความนิยม

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

สิ่งนี้ควรชัดเจนสำหรับคนส่วนใหญ่ แต่ก็ยังจำเป็นต้องกล่าวถึงเมื่อพูดถึงลำดับระดับภาพรวม หากคุณสามารถควบคุมการสั่งซื้อได้ คุณจะสามารถ แยก ค่าของโปรโตคอลได้ง่ายขึ้น เนื่องจากคุณควบคุมอำนาจในการเรียงลำดับธุรกรรมใหม่ ซึ่งโดยปกติจะขึ้นอยู่กับค่าธรรมเนียมลำดับความสำคัญใน L1 ส่วนใหญ่ (การตั้งค่า MEV-boost-esque) โดยจะให้ความสำคัญกับค่าธรรมเนียมที่ชำระโดยผู้เข้าร่วมที่ซับซ้อนซึ่งดึงมูลค่าจากห่วงโซ่ ผู้เล่นเหล่านี้มักจะยินดีจ่ายเงินก้อนโต (จนกว่าจะไม่มีมูลค่าอีกต่อไป) อย่างไรก็ตาม การยกเลิกส่วนใหญ่ในปัจจุบันใช้กลไกมาก่อนได้ก่อน การสกัด MEV ส่วนใหญ่เกิดขึ้นผ่านสงครามล่าช้า ซึ่งทำให้โครงสร้างพื้นฐานชุดสะสมมีความเครียดอย่างรุนแรง ด้วยเหตุผลข้างต้น เราอาจเห็น Rollups จำนวนมากขึ้นเรื่อยๆ เริ่มใช้โครงสร้างการจัดอันดับด้วยแนวคิดค่าธรรมเนียมลำดับความสำคัญ (เช่น กลไกการเพิ่มเวลาของ Arbitrum)

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

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

หากเราถือว่า Rollup มีกลไก PBS บางส่วน ขั้นตอนการสั่งซื้อและกระบวนการเชิงพาณิชย์อาจเป็นดังนี้:

จากนี้ การค้าของผู้สั่งซื้อ Rollup และผู้เสนออาจเป็นไปตามสูตรต่อไปนี้:

ปริมาณการไหลเวียน (PoS) + รายได้ค่าธรรมเนียม (+ลำดับความสำคัญ) - ต้นทุนของ DA, ผับของรัฐ, พื้นที่จัดเก็บ

วิธีที่ดีในการดูว่าขณะนี้มีการดึงมูลค่าเท่าใดบน Ethereum (โดยเฉพาะการเก็งกำไร) สามารถพบได้ที่ Mevboost.pics ซึ่งให้ภาพรวมที่ดีว่าสามารถดึงมูลค่าได้มากเพียงใดจากความไร้ประสิทธิภาพ

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

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

กฎการสั่งซื้อข้างต้นเป็นตัวอย่างที่การปรับแต่งโครงสร้างพื้นฐานอย่างละเอียดสามารถปรับปรุงแอปพลิเคชันที่สร้างขึ้นด้านบนได้อย่างมาก