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

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

Dominos go in a sequence too :) รูปภาพโดยTom WilsonในUnsplash

การกำหนดการต่อต้านการเซ็นเซอร์

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

กลไกการบังคับให้รวมอยู่ด้วยกัน

วัตถุประสงค์ความปลอดภัยหลักของ OP Stack chains คือ Sequencer ไม่ควรสามารถป้องกันผู้ใช้ไม่ให้ส่งธุรกรรมไปยัง L2 chain ได้

• ความหวังดี

การยกเลิกสมัยใหม่มักจะมีการจัดลําดับแบบรวมศูนย์ ซึ่งหมายความว่าการเซ็นเซอร์โดยซีเควนเซอร์เป็นเรื่องเล็กน้อยเนื่องจากพวกเขาสามารถเลือกที่จะไม่รวมธุรกรรมของผู้ใช้ใด ๆ เพื่อ mitiGate นี้หลาย rollups - รวมถึง OptimismและArbitrum - มีกลไกการรวมอย่างบังคับ กลไกเหล่านี้ช่วยให้ผู้ใช้สามารถให้ความแน่ใจได้ว่าธุรกรรมของพวกเขาจะถูกดำเนินการโดย rollup หลังจากผ่านเวลาล่าช้าบางส่วน โดยไม่ว่าจะเป็นพฤติกรรมของ sequencer การรวมอย่างบังคับจะถูกดำเนินการผ่านสัญญาที่ถูกติดตั้งบน L1 ดังนั้น ธุรกรรมการรวมอย่างบังคับ (ทฤษฎี) จึงมีความต้านทานต่อการเซ็นเซอร์เทียบเท่ากับธุรกรรม Ethereum อื่น ๆ

การรวมบังคับระบุช่วงย่อยที่ต้องเก็บไว้ในการจัดเรียงที่ถูกต้องใด ๆ

การเสริมสร้างที่บังคับก็ได้ถูกนำเสนอสำหรับ Ethereum ผ่านEIP-7547. การรายชื่อที่รวมเข้าไปจะทำให้ข้อเสนอบล็อกสามารถระบุเนื้อหาของบล็อกถัดไปได้บางส่วน ภายใต้สมมติฐานว่าผู้เสนอบล็อกมีส่วนสนับสนุนน้อยกว่าผู้สร้างบล็อกที่จะเซ็นเซอร์ จะเป็นการลดประสิทธิภาพที่มีประสิทธิภาพในการต่อต้านการเซ็นเซอร์

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

การขยายโมเดลของเราในการต่อต้านการเซ็นเซอร์

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

การต่อต้านการเซ็นเซอร์ต้องถูกกำหนดในมุมมองของวัตถุประสงค์ ผู้ใช้ต้องการส่งโทเค็น ซื้อ NFTs, ยืมเงิน ฯลฯ การยืนยันธุรกรรมเป็นส่วนรองของวัตถุประสงค์นั้น². ตัวกรองก็มีเป้าหมายเฉพาะ ความเป้าหมายนั้นอาจเป็นเพื่อป้องกันธุรกรรมแฮ็กบายจากการประสบความสำเร็จ การปฏิบัติตามกฎหมายบางประการ หรือการขัดขวางธุรกิจของคู่แข่ง โดยเราต้องเคารพความตั้งใจของทั้งสองฝ่าย เราจึงต้องนิยิตใหม่เกี่ยวกับการเซ็นเซอร์

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

โดยลูกฟ่างเราจะพูดว่าสำหรับการจับคู่ใด ๆ กับโซ่ มีฟังก์ชันการจัดคะแนนบางอย่าง f ที่ประเมินลำดับผลลัพธ์ และสร้าง 0 (เป้าหมายล้มเหลว) หรือ 1 (เป้าหมายบรรลุ) ในโมเดลนี้ ฟังก์ชันการจัดคะแนนของผู้เซ็นเซอร์ก็คือการปฏิเสธ: f’ = !f ผู้เซ็นเซอร์บรรลุเป้าหมายของพวกเขาเมื่อผู้ใช้ไม่ทำ³

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

เพื่อความง่าย ๆ ให้เราสมมติว่าเรากำลังทำงานในโมเดลตัวจัดลำดับมาตรฐาน⁴. เราจะจัดการกับการรวมอย่างบังคับภายใต้การหมุนตำแหน่งภายหลัง ในโมเดลนี้ตัวตำแหน่งมีการควบคุมทั้งหมดของลำดับ และสามารถจำลองออกมาให้ตรงกับผลลัพธ์ใดๆ ซึ่งหมายความว่าพวกเขาสามารถเลือกจากเซตของการเรียงลำดับทั้งหมดได้อย่างอิสระ คำถามแบบลูกศรของเราเกี่ยวกับการเซ็นเซอร์คือ “มีลำดับที่ถูกต้องบางอย่างที่ฟังก์ชัน f ประเมินค่าเป็น 0 หรือไม่” หากมีลำดับเช่นนั้นอยู่ ตัวตำแหน่งสามารถเลือกมัน

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

ปัญหาการส่งมอบ

การมีกลไกการรวมคำหมายว่าการสั่งซื้อเกิดขึ้นในหนึ่งในโหมดสองโหมด: โหมดที่ไม่บังคับหรือบังคับ. มีจุดที่กำหนดที่มันเปลี่ยนจากโหมดที่ไม่บังคับเป็นบังคับ (และในทางกลับกัน). จุดนั้นคือการส่งมอบ. การส่งมอบนี้เป็นปัญหาที่ยากที่จะออกแบบกลไกการรวมที่บังคับ.

จะต้องมีการส่งมอบจากการรวมที่ไม่บังคับไปสู่การรวมที่บังคับ

ธุรกรรมที่บังคับให้ดำเนินการบนสถานะที่มีการส่งมอบ ดังนั้นอีกครั้ง การต่อสู้ในสถานะ⁵rears its ugly head. เมื่อการโอนมอบเป็นไปในชุดของธุรกรรม (เช่นบล็อก) ผู้สร้างชุดสามารถควบคุมสถานะที่โอนมอบได้ หากธุรกรรมการรวมกันที่บังคับใช้อ่านสถานะสาธารณะใด ๆ ผู้สร้างชุดสามารถเพิ่มเติมสถานะนั้นก่อนและหลังการดำเนินการของธุรกรรมที่บังคับใช้ การแข่งขันเพียงพอสำหรับการต่อต้านการเซ็นเซอร์

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

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

ในระบบที่ใช้ในชีวิตประจำวัน

[A]ny user can bypass the Sequencer entirely to submit any Arbitrum transaction (including one that, say, initiates an L2 to L1 message to withdraw funds) directly from layer 1. Thus [sic] mechanism thereby preserves การต่อต้านการเซ็นเซอร์ even if the Sequencer is being completely unresponsive or even malicious.

• Arbitrum

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

สำหรับ EIP-7547, ผู้สร้างเลือกตำแหน่งที่จะเกิดการส่งมือในบล็อก⁸ด้วยเหตุนี้ ผู้สร้างสามารถเลือกตำแหน่งของการส่งมอบภายในบล็อกได้ ซึ่งหมายความว่าพวกเขาสามารถเลือก prefix และ postfix ตามต้องการ⁹ ตราบใดที่พวกเขาเคารพกฎบล็อกก๊าซ คํานําหน้าสามารถใส่ห่วงโซ่ลงในสถานะที่ธุรกรรมจะเปลี่ยนกลับในขณะที่ postfix จะคืนค่าห่วงโซ่กลับสู่สถานะปกติ รายการรวม EIP-7547 ไม่เพียงพอที่จะป้องกันการเซ็นเซอร์สําหรับธุรกรรมใด ๆ ที่เข้าถึงสถานะที่ถกเถียงกัน ปัญหาการส่งต่อทําให้ IL ไม่สามารถรับรองการดําเนินการธุรกรรมในกรณีส่วนใหญ่ได้

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

Case study

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

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

ผู้เรียงลำดับหรือผู้สร้างสามารถควบคุมสถานะที่ส่งต่อได้

นี่ต้องการให้ตัวจัดเรียงมีหลักทรัพย์เพียงพอที่จะยืม USDC แต่มันใช้เฉพาะค่ายืมที่เล็กมากเท่านั้น¹⁰ นอกจากนี้หลักประกันสามารถนํากลับมาใช้ใหม่ได้สําหรับการเซ็นเซอร์ทั้งหมดเนื่องจากการกู้ยืมไม่เคยเปิด ด้วยเหตุนี้ผู้ใช้ AAVE หรือ Compound on Optimism (หรือ Arbitrum หรือการยกเลิกลําดับกลางอื่น ๆ ) จึงไม่รับประกันว่าพวกเขาจะสามารถถอนหลักประกันได้ตลอดไป ซีเควนเซอร์สามารถเซ็นเซอร์การถอนเงินจากตลาดการให้กู้ยืมได้ตลอดเวลา การรวมแบบบังคับนั้นไม่เพียงพอที่จะปกป้องผู้ใช้จากการเซ็นเซอร์

งานทำความเข้าใจ

เรามีบางพื้นที่ของการวิจัยตาม

ก่อนอื่น EIP-7547 สามารถปรับปรุงได้อย่างง่ายดายโดยการต้องการให้ธุรกรรม IL ถูกประมวลผลที่สิ้นสุดของบล็อกถัดไป ในบริบทการประมูล PBS การต่อต้านการเซ็นเซอร์เป็น MEV ผู้สร้างได้รับค่าความคุ้มค่าที่ไม่ใช่เศรษฐกิจบางอย่างซึ่งต้องกำหนดค่าความคุ้มค่าที่เป็นส่วนบุคคลใน ETH การต่อต้านการเซ็นเซอร์โดยผู้สร้างจึงทำให้เกิดการเสนอราคาบล็อกของผู้สร้างเพิ่มขึ้น¹¹ สิ่งนี้ขยายไปถึงผู้ค้นหาซึ่งอาจทําการเซ็นเซอร์กลุ่ม มูลค่าทางเศรษฐกิจบางส่วนของการเซ็นเซอร์จะถูกจับโดยผู้เสนอซึ่งเป็นแรงจูงใจในการทนต่อการเซ็นเซอร์แม้ว่าจะไม่ได้เข้าร่วมโดยตรงก็ตาม การวางธุรกรรมการรวมแบบบังคับที่ส่วนท้ายของบล็อกจะลบความสามารถของผู้สร้างบล็อกในการประกบธุรกรรม IL เล็กน้อยและเพิ่มต้นทุนทางเศรษฐกิจของการเซ็นเซอร์ที่ถกเถียงกัน ตัวอย่างเช่น การเซ็นเซอร์การโต้ตอบ AMM ผ่านความขัดแย้งของรัฐอาจต้องยกเลิกการเก็งกําไร AMM หรือค่าใช้จ่ายสูงเพื่อผลักดันตลาดให้พ้นช่วงที่ไม่สามารถชดใช้ได้โดยการปิดแซนด์วิช นอกจากนี้ สิ่งนี้จะจํากัดการรวมกลุ่มการเซ็นเซอร์ที่ผลิตโดยผู้ค้นหา (แทนที่จะเป็นผู้สร้าง) ไว้ที่หนึ่งชุดต่อบล็อก¹² เราขอแนะนําการดําเนินการแบบ top-of-block เนื่องจากคํานําหน้ามีความสําคัญมากกว่า postfix อย่างไรก็ตามซึ่งจะเพิ่มต้นทุนของธุรกรรม IL อย่างมากเนื่องจากจะช่วยให้สามารถแยก MEV แบบ top-of-block ผ่านการรวมแบบบังคับ¹³การลบสิทธิ์ของเซ็นเซอร์ในการต่อท้ายธุรกรรม IL อะตอมิกคือการปรับปรุงเล็กน้อย

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

ประการที่สามมีคลาสที่น่าสนใจของฟังก์ชั่นการให้คะแนน "อิสระ" สิ่งเหล่านี้เป็นเป้าหมายที่ไม่สามารถเซ็นเซอร์โดยความขัดแย้งของรัฐอาจเป็นเพราะพวกเขาไม่สามารถเข้าถึงรัฐที่ถกเถียงกันหรือเพราะรัฐที่ถกเถียงกันที่พวกเขาเข้าถึงมีข้อ จํากัด เพียงพอที่จะทําให้ "เชื่อถือได้" ในแง่หนึ่ง การดําเนินการที่ไม่ขึ้นกับคําสั่งซื้อ ได้แก่ การส่ง ETH ไปยัง EOA ERC-20 ส่วนใหญ่ส่ง¹⁴ และการโต้ตอบ DeFi บางอย่างเช่นการเพิ่มหลักประกันในตลาด การกระทําเหล่านี้ได้รับการคุ้มครองจากการเซ็นเซอร์ผ่านความขัดแย้ง เป้าหมายระดับนี้ยังมีการโต้ตอบที่น่าสนใจในการสื่อสารข้ามสายโซ่ที่ปลอดภัยและการต้านทาน MEV และคุ้มค่ากับการศึกษาเชิงลึกมากขึ้น แอปพลิเคชันและโปรโตคอลอาจได้รับการออกแบบให้รวมเฉพาะการดําเนินการที่เป็นอิสระจากคําสั่งในบางกรณี แต่จําเป็นต้องมีการศึกษาเพิ่มเติม

สรุป

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

We’d like to thank ไมค์ นอยเดอร์, Tarun Chitra, และ Brandon Curtisสำหรับการตรวจสอบและข้อเสนอแนะ

1

เหมือนเป็นปกติสำหรับ L1s นี้ได้รับการดำเนินการโดยการปฏิเสธบล็อกที่ไม่ถูกต้องในขณะที่ใน rollups นี้ได้รับการดำเนินการโดยการบังคับลำดับที่ไม่ถูกต้องให้เป็นลำดับที่ถูกต้องผ่านฟังก์ชั่นการกรองบางอย่าง

2

นี่ไม่ใช่โพสต์เกี่ยวกับความตั้งใจ โลกไม่ต้องการอีกต่อไป

3

เห็นได้ชัดว่านี่เป็นแบบจําลองที่ไม่สมบูรณ์เนื่องจากไม่ได้คํานึงถึงค่าอัตนัยของผลลัพธ์ ตัวอย่างเช่น เซ็นเซอร์อาจสูญเสียเงินจํานวนเท่าใดก็ได้หากการเซ็นเซอร์ล้มเหลว (เช่น เพราะพวกเขาอาจถูกตํารวจฝรั่งเศสจับกุมหากพวกเขาล้มเหลวในการเซ็นเซอร์พฤติกรรมบางอย่าง) ในทางกลับกันผู้ใช้สามารถยืนหยัดที่จะได้รับ / สูญเสียเงินจํานวนเท่าใดก็ได้หากเป้าหมายของพวกเขาไม่ประสบความสําเร็จในกรอบเวลาที่กําหนด (เช่นพวกเขาได้กู้ยืมเงิน $ 100mm + กับโทเค็นของตนเองและจําเป็นต้องวางหลักประกันตําแหน่งใหม่ก่อนที่จะชําระบัญชี)

4

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

5

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

6

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

7

เราได้รับการครอบคลุมเฉพาะการใช้ความขัดแย้งของสถานะในการย้อนกลับธุรกรรมในบทความของเราในปี 2017Miners ไม่ใช่เพื่อนของคุณ”. ในช่วงนั้นคำว่า “MEV” ยังไม่ได้ใช้งาน

8

รู้จักกันดีว่า PBS ทำให้การต่อต้านการเซ็นเซอร์ซับซ้อนขึ้นอย่างมาก ดู VB's@vbuterin/pbs_censorship_resistance">บันทึกการวิจัย

9

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

10

การยืมถือเพียงไม่กี่วินาที ถ้ามี Rollup sequencers บางกรณีสามารถถือ timestamp หรือขอบเขตบล็อกเพื่อทำให้เวลายืมเป็น 0 ในบางกรณี

11

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

12

โปรดทราบว่าสิ่งนี้อาศัยกฎการประมูล MEV ที่ป้องกันไม่ให้ธุรกรรมระหว่างกันจากกลุ่มต่างๆ และไม่อนุญาตให้ทําธุรกรรม "ต้องย้อนกลับ" หากกฎเหล่านั้นได้รับการผ่อนคลายเพื่อให้การรวมกลุ่ม txns ถูกแทรกแซงและ / หรือหากผู้สร้างเริ่มสนับสนุนบล็อก "ต้องย้อนกลับ" ในการรวมกลุ่มการป้องกันจะระเหยไป ไดนามิกนี้เกิดขึ้นเนื่องจากหากธุรกรรม IL ต้องอยู่ที่จุดสิ้นสุดของบล็อกจะไม่มีการทําธุรกรรมที่ไม่ถูกบังคับและดังนั้นจึงอาจเกิดการเซ็นเซอร์ผู้ค้นหาได้มากที่สุด

13

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

14

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

ข้อความประกาศ

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