เมื่อวานนี้มีเหตุการณ์ที่น่าตกใจเกิดขึ้น: Linea ซึ่งเป็นโซลูชัน Ethereum Layer 2 ที่พัฒนาโดย Consensys ซึ่งเป็น บริษัท แม่ของ Metamask ถูกปิดตัวลงในเชิงรุก เหตุผลอย่างเป็นทางการที่ให้ไว้คือเพื่อลดผลกระทบของเหตุการณ์การแฮ็ก Velocore เหตุการณ์นี้ทําให้นึกถึงกรณีก่อนหน้านี้อย่างหลีกเลี่ยงไม่ได้ที่ BSC chain (BNB Chain) ถูกปิดภายใต้การประสานงานอย่างเป็นทางการเพื่อลดการสูญเสียการแฮ็ก เหตุการณ์เหล่านี้มักทําให้ผู้คนตั้งคําถามถึงค่านิยมแบบกระจายอํานาจที่ Web3 สนับสนุน

เหตุผลหลักที่อยู่เบื้องหลังเหตุการณ์ดังกล่าวอยู่ในความไม่สมบูรณ์ของโครงสร้างพื้นฐานโดยเฉพาะการขาดการกระจายอํานาจ หากบล็อกเชนมีการกระจายอํานาจอย่างเพียงพอก็ไม่ควรปิดตัวลงอย่างง่ายดาย เนื่องจากโครงสร้างที่เป็นเอกลักษณ์ของ Ethereum Layer 2 โซลูชันเลเยอร์ 2 ส่วนใหญ่จึงพึ่งพาซีเควนเซอร์แบบรวมศูนย์ แม้จะมีวาทกรรมที่เพิ่มขึ้นเกี่ยวกับซีเควนเซอร์แบบกระจายอํานาจในช่วงไม่กี่ปีที่ผ่านมาเนื่องจากวัตถุประสงค์และโครงสร้างของเลเยอร์ 2 เราสามารถสันนิษฐานได้ว่าซีเควนเซอร์เลเยอร์ 2 ไม่น่าจะบรรลุการกระจายอํานาจในระดับสูง ในความเป็นจริงพวกเขาอาจจบลงด้วยการกระจายอํานาจน้อยกว่าห่วงโซ่ BSC หากเป็นกรณีนี้จะทําอะไรได้บ้าง? สําหรับเลเยอร์ 2 ความเสี่ยงที่เร่งด่วนที่สุดของซีเควนเซอร์ที่ไม่กระจายอํานาจคือการขาดความต้านทานการเซ็นเซอร์และความมีชีวิตชีวา หากมีเพียงไม่กี่หน่วยงานที่ประมวลผลธุรกรรม (ซีเควนเซอร์) พวกเขามีอํานาจเด็ดขาดว่าจะให้บริการคุณหรือไม่: พวกเขาสามารถปฏิเสธการทําธุรกรรมของคุณได้ตามต้องการทําให้คุณไม่ต้องขอความช่วยเหลือ การแก้ไขปัญหาการต่อต้านการเซ็นเซอร์ในเลเยอร์ 2 เป็นหัวข้อที่สําคัญอย่างชัดเจน ในช่วงไม่กี่ปีที่ผ่านมาโซลูชัน Ethereum Layer 2 ต่างๆได้เสนอแนวทางที่แตกต่างกันในการจัดการปัญหานี้ ตัวอย่างเช่น Loopring, Degate และ StarkEx ได้แนะนําฟังก์ชั่นการถอนบังคับและการหลบหนีฟักในขณะที่ Arbitrum และ Optimistic Rollups อื่น ๆ ได้ใช้คุณสมบัติ Force Inclusion กลไกเหล่านี้สามารถกําหนดการตรวจสอบซีเควนเซอร์เพื่อป้องกันการปฏิเสธธุรกรรมของผู้ใช้โดยพลการ ในบทความวันนี้ NIC Lin จาก Taipei Ethereum Association แบ่งปันประสบการณ์โดยตรงของเขาโดยทดลองกับคุณสมบัติการทําธุรกรรมที่ทนต่อการเซ็นเซอร์ของ Rollups หลักสี่รายการและให้การวิเคราะห์เชิงลึกของกลไก Force Inclusion โดยเน้นที่เวิร์กโฟลว์และวิธีการดําเนินงาน การวิเคราะห์นี้มีค่าอย่างยิ่งสําหรับชุมชน Ethereum และผู้ถือสินทรัพย์รายใหญ่

Transaction Censorship and Force Inclusion Censorship resistance in transactions is important for any blockchain. h2 id="h2-transaction-censorship-and-force-inclusion"Transaction Censorship and Force Inclusion

Censorship resistance in transactions is important for any blockchain. หากบล็อกเชนสามารถเซ็นเซอร์และปฏิเสธธุรกรรมของผู้ใช้ได้โดยพลการก็ไม่แตกต่างจากเซิร์ฟเวอร์ Web2 ปัจจุบันการต่อต้านการเซ็นเซอร์ธุรกรรมของ Ethereum ได้รับการรับรองโดยผู้ตรวจสอบจํานวนมาก หากมีคนต้องการเซ็นเซอร์ธุรกรรมของ Bob และป้องกันไม่ให้รวมอยู่ในบล็อกเชนพวกเขาจะต้องติดสินบนผู้ตรวจสอบส่วนใหญ่ของเครือข่ายหรือสแปมเครือข่ายด้วยธุรกรรมขยะที่มีค่าธรรมเนียมสูงกว่าของ Bob ดังนั้นจึงครอบครองพื้นที่บล็อก ทั้งสองวิธีมีค่าใช้จ่ายสูงมาก

หมายเหตุ: ในสถาปัตยกรรม Proposer-Builder Separation (PBS) ปัจจุบันของ Ethereum ค่าใช้จ่ายในการเซ็นเซอร์ธุรกรรมจะลดลงอย่างมาก ตัวอย่างเช่นคุณสามารถดูสัดส่วนของบล็อกที่สอดคล้องกับการเซ็นเซอร์ธุรกรรม Tornado Cash ของ OFAC การต่อต้านการเซ็นเซอร์ในปัจจุบันอาศัยผู้ตรวจสอบอิสระและรีเลย์ที่อยู่นอกเขตอํานาจของ OFAC และหน่วยงานของรัฐอื่น ๆ

แต่สิ่งที่เกี่ยวกับ Rollups? ชุดรวมอัปเดตไม่จําเป็นต้องมีผู้ตรวจสอบจํานวนมากเพื่อความปลอดภัย แม้ว่า Rollup จะมีบล็อกการผลิตเอนทิตีแบบรวมศูนย์ (Sequencer) เพียงบล็อกเดียว แต่ก็ยังคงปลอดภัยเท่ากับเลเยอร์ 1 (L1) อย่างไรก็ตามการต่อต้านความปลอดภัยและการเซ็นเซอร์เป็นสองเรื่องที่แตกต่างกัน Rollup ในขณะที่มีความปลอดภัยเท่ากับ Ethereum ยังคงสามารถเซ็นเซอร์ธุรกรรมของผู้ใช้ได้หากมีซีเควนเซอร์ส่วนกลางเพียงตัวเดียว

Sequencer สามารถปฏิเสธที่จะประมวลผลธุรกรรมของผู้ใช้ส่งผลให้เงินของผู้ใช้ถูกล็อคและไม่สามารถออกจาก Rollup ได้

Force Inclusion mechanism

แทนที่จะกําหนดให้ Rollups มีซีเควนเซอร์แบบกระจายอํานาจจํานวนมาก จะมีประสิทธิภาพมากกว่าในการใช้ประโยชน์จากความต้านทานการเซ็นเซอร์ของเลเยอร์ 1 (L1) โดยตรง:

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

Sequencer ไม่สามารถตรวจสอบธุรกรรม L1 ของผู้ใช้ได้โดยไม่ต้องเสียค่าใช้จ่ายสูง

ธุรกรรมบังคับควรดําเนินการอย่างไร?

หากธุรกรรมได้รับอนุญาตให้เขียนลงในสัญญา Rollup โดยตรงผ่าน Force Inclusion (หมายความว่าจะมีผลทันที) สถานะของ Rollup จะเปลี่ยนไปทันที ตัวอย่างเช่น หาก Bob ใช้กลไก Force Inclusion เพื่อแทรกธุรกรรมที่โอน 1,000 DAI ไปยัง Carol และธุรกรรมจะมีผลทันที ยอดคงเหลือของ Bob จะลดลง 1,000 DAI ในขณะที่ยอดคงเหลือของ Carol จะเพิ่มขึ้น 1,000 DAI ในสถานะที่อัปเดต

หาก Force Inclusion อนุญาตให้เขียนธุรกรรมลงในสัญญา Rollup โดยตรงและมีผลทันทีสถานะของ Rollup จะเปลี่ยนไปทันที หากซีเควนเซอร์กําลังรวบรวมธุรกรรมนอกเครือข่ายพร้อมกันและเตรียมส่งชุดถัดไปไปยังสัญญา Rollup อาจหยุดชะงักโดยธุรกรรมที่แทรกโดยบังคับของ Bob ซึ่งจะมีผลทันที เพื่อหลีกเลี่ยงปัญหานี้ โดยทั่วไป Rollups ไม่อนุญาตให้ธุรกรรม Force Inclusion มีผลทันที ผู้ใช้เริ่มแทรกธุรกรรมของพวกเขาลงในคิวรอบน L1 ซึ่งพวกเขาเข้าสู่สถานะ "เตรียมการ" เมื่อซีเควนเซอร์บรรจุธุรกรรมนอกเครือข่ายเพื่อส่งไปยังสัญญา Rollup สามารถเลือกได้ว่าจะรวมธุรกรรมที่จัดคิวเหล่านี้หรือไม่ หากซีเควนเซอร์เพิกเฉยต่อธุรกรรมในสถานะ "การเตรียมการ" อย่างต่อเนื่องเมื่อระยะเวลาหน้าต่างสิ้นสุดลงผู้ใช้สามารถบังคับให้แทรกธุรกรรมเหล่านี้ลงในสัญญา Rollup ได้ ซีเควนเซอร์สามารถตัดสินใจได้ว่าเมื่อใดควร "รวม" ธุรกรรมจากคิวรอโดยบังเอิญ แต่ก็ยังสามารถปฏิเสธที่จะประมวลผลได้ หากซีเควนเซอร์ปฏิเสธอย่างสม่ําเสมอหลังจากช่วงเวลาหนึ่งทุกคนสามารถใช้ฟังก์ชัน Force Inclusion เพื่อบังคับให้แทรกธุรกรรมลงในสัญญา Rollup ต่อไปเราจะแนะนําการใช้งานกลไกการรวมกําลังในสี่ Rollups ที่โดดเด่น: Optimism, Arbitrum, StarkNet และ zkSync

ซีเควนเซอร์สามารถเลือกได้ว่าจะรับธุรกรรมจากคิวรอเมื่อใด

ซีเควนเซอร์ยังคงสามารถปฏิเสธที่จะประมวลผลธุรกรรมในคิวรอได้

หากซีเควนเซอร์ปฏิเสธที่จะประมวลผลธุรกรรมอย่างสม่ําเสมอหลังจากช่วงเวลาหนึ่งทุกคนสามารถใช้ฟังก์ชัน Force Inclusion เพื่อบังคับให้แทรกธุรกรรมลงในสัญญา Rollup ต่อไปเราจะแนะนําวิธีการใช้งานกลไกการรวมพลังในสี่ Rollups ที่โดดเด่น: Optimism, Arbitrum, StarkNet และ zkSync

Optimism's Force Inclusion mechanism

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

ข้อความผู้ใช้ที่ฝากจาก L1 ถึง L2

สัญญา L1CrossDomainMessenger

เมื่อผู้ใช้ต้องการฝากโทเค็น ETH หรือ ERC-20 ลงใน Optimism พวกเขาจะโต้ตอบกับสัญญา L1StandardBridge บน L1 ผ่านหน้าเว็บส่วนหน้าโดยระบุจํานวนเงินที่จะฝากและที่อยู่ L2 ที่จะได้รับสินทรัพย์เหล่านี้ จากนั้นสัญญา L1StandardBridge จะส่งต่อข้อความไปยังสัญญา L1CrossDomainMessenger ซึ่งทําหน้าที่เป็นสะพานการสื่อสารหลักระหว่าง L1 และ L2 L1StandardBridge ใช้ส่วนประกอบการสื่อสารนี้เพื่อโต้ตอบกับ L2StandardBridge บน L2 โดยกําหนดว่าใครสามารถสร้างโทเค็นบน L2 หรือปลดล็อกโทเค็นจาก L1 นักพัฒนาที่ต้องการสร้างสัญญาที่ทํางานร่วมกันและซิงโครไนซ์สถานะระหว่าง L1 และ L2 สามารถสร้างได้ที่ด้านบนของสัญญา L1CrossDomainMessenger

ข้อความของผู้ใช้ที่ส่งจาก L1 ถึง L2 ผ่านสัญญา CrossDomainMessenger

หมายเหตุ: ในบางภาพในบทความนี้ CrossDomainMessenger เขียนเป็น CrossChainMessenger

OptimismPortal สัญญา

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

L2 แปลงพารามิเตอร์ของเหตุการณ์ Transaction Deposited ที่ปล่อยออกมาจาก OptimismPortal เป็นธุรกรรม L2

ตัวอย่างเช่นเมื่อผู้ใช้ฝากเงิน 0.01 ETH ผ่านสัญญา L1StandardBridge ข้อความและ ETH จะถูกส่งไปยังสัญญา OptimismPortal (ที่อยู่ 0xbEb5 ... 06Ed). ไม่กี่นาทีต่อมาสิ่งนี้จะถูกแปลงเป็นธุรกรรม L2: ผู้ส่งข้อความคือสัญญา L1CrossDomainMessenger ผู้รับคือสัญญา L2CrossDomainMessenger บน L2 และเนื้อหาข้อความระบุว่า L1StandardBridge ได้รับเงินมัดจํา 0.01 ETH จาก Bob สิ่งนี้จะทําให้เกิดกระบวนการเพิ่มเติมเช่นการสร้าง 0.01 ETH สําหรับ L2StandardBridge ซึ่งต่อมาโอนไปยัง Bob

วิธีทริกเกอร์

หากคุณต้องการบังคับให้รวมธุรกรรมในสัญญา Rollup ของ Optimism เป้าหมายของคุณคือเพื่อให้แน่ใจว่าธุรกรรม "เริ่มต้นและดําเนินการจากที่อยู่ L2 ของคุณบน L2" สามารถดําเนินการได้สําเร็จ เพื่อให้บรรลุเป้าหมายนี้คุณควรส่งข้อความโดยตรงไปยังสัญญา OptimismPortal โดยใช้ที่อยู่ L2 ของคุณ (โปรดทราบว่าสัญญา OptimismPortal อยู่ใน L1 จริง ๆ แต่รูปแบบที่อยู่ OP ตรงกับรูปแบบที่อยู่ L1 ดังนั้นคุณสามารถเรียกสัญญานี้โดยใช้บัญชี L1 ที่มีที่อยู่เดียวกันกับบัญชี L2 ของคุณ) "ผู้ส่ง" ของธุรกรรม L2 ที่ได้มาจากเหตุการณ์ Transaction Deposited ที่ปล่อยออกมาจากสัญญานี้จะเป็นบัญชี L2 ของคุณ และรูปแบบธุรกรรมจะสอดคล้องกับธุรกรรม L2 มาตรฐาน

ในธุรกรรม L2 ที่ได้มาจากเหตุการณ์ Transaction Deposited Bob เองจะเป็นผู้ริเริ่ม ผู้รับจะเป็นสัญญา Uniswap; และจะรวมถึง ETH ที่ระบุ ราวกับว่า Bob กําลังเริ่มต้นธุรกรรม L2 ด้วยตัวเอง

ในการใช้ฟังก์ชัน Force Inclusion ของ Optimism คุณต้องเรียกฟังก์ชัน depositTransaction ของสัญญา OptimismPortal โดยตรงและป้อนพารามิเตอร์ของธุรกรรมที่คุณต้องการดําเนินการบน L2 ฉันทําการทดลอง Force Inclusion อย่างง่าย เป้าหมายของการทําธุรกรรมนี้คือการโอนเงินด้วยตนเองบน L2 โดยใช้ที่อยู่ของฉัน (0xeDc1... 6909) และมีข้อความว่า "การรวมพลัง" นี่คือธุรกรรม L1 ที่ฉันดําเนินการโดยเรียกฟังก์ชัน depositTransaction ผ่านสัญญา OptimismPortal ดังที่คุณเห็นจากเหตุการณ์ Transaction Deposited ที่ปล่อยออกมาทั้งผู้ส่งและผู้รับเป็นตัวฉันเอง

ค่าที่เหลือในคอลัมน์ข้อมูลทึบแสงเข้ารหัสข้อมูลเช่น "จํานวน ETH บุคคลที่เรียกฟังก์ชัน depositTransaction ที่แนบมา" "ตัวเริ่มต้นธุรกรรม L2 ต้องการส่งไปยังผู้รับเท่าใด ETH" "GasLimit ธุรกรรม L2" และ "ข้อมูลสําหรับผู้รับ L2" หลังจากถอดรหัสข้อมูลนี้คุณจะได้รับรายละเอียดต่อไปนี้: "จํานวน ETH บุคคลที่เรียก depositTransaction ที่แนบมา": 0 เพราะฉันไม่ได้ฝาก ETH จาก L1 ถึง L2 "ตัวเริ่มต้นธุรกรรม L2 ต้องการส่งไปยังผู้รับ ETH เท่าใด": 5566 (WEI); "ธุรกรรม L2 GasLimit": 50000; "ข้อมูลสําหรับตัวรับสัญญาณ L2": 0x666f72636520696e636c7573696f6e ซึ่งเป็นการเข้ารหัสเลขฐานสิบหกของสตริง "การรวมแรง" ไม่นานหลังจากนั้นธุรกรรม L2 ที่แปลงแล้วก็ปรากฏขึ้น: ธุรกรรม L2 ที่ฉันโอน 5566 wei ให้กับตัวเองโดยมีฟิลด์ข้อมูลที่มีสตริง "การรวมแรง" นอกจากนี้ ในบรรทัดที่สองถึงบรรทัดสุดท้ายของส่วนแอตทริบิวต์อื่น ๆ TxnType (ชนิดธุรกรรม) จะแสดงเป็นธุรกรรมระบบ 126 (ระบบ) ซึ่งระบุว่าธุรกรรมนี้ไม่ได้เริ่มต้นโดยฉันบน L2 แต่ถูกแปลงจากเหตุการณ์ที่ฝากของธุรกรรม L1

ธุรกรรม L2 ที่แปลงแล้ว

หากคุณต้องการเรียกสัญญา L2 ผ่าน Force Inclusion และส่งข้อมูลที่แตกต่างกันคุณเพียงแค่กรอกพารามิเตอร์ในฟังก์ชัน depositTransaction อย่าลืมใช้ที่อยู่ L1 เดียวกันกับบัญชี L2 ของคุณเมื่อเรียกใช้ฟังก์ชัน depositTransaction ด้วยวิธีนี้เมื่อเหตุการณ์ที่ฝากถูกแปลงเป็นธุรกรรม L2 ผู้ริเริ่มจะเป็นบัญชี L2 ของคุณ Sequencer Window โหนด Optimism L2 ที่แปลงเหตุการณ์ Transaction Deposited เป็นธุรกรรม L2 คือ Sequencer จริงๆ เนื่องจากสิ่งนี้เกี่ยวข้องกับการสั่งซื้อธุรกรรม มีเพียง Sequencer เท่านั้นที่สามารถตัดสินใจได้ว่าเมื่อใดควรแปลงเหตุการณ์เป็นธุรกรรม L2 เมื่อ Sequencer ฟังเหตุการณ์ TransactionDeposited ไม่จําเป็นต้องแปลงเหตุการณ์เป็นธุรกรรม L2 ทันที อาจมีความล่าช้า ระยะเวลาสูงสุดของการหน่วงเวลานี้เรียกว่าหน้าต่างซีเควนเซอร์ ปัจจุบันหน้าต่างซีเควนเซอร์บนเมนเน็ตมองโลกในแง่ดีคือ 24 ชั่วโมง ซึ่งหมายความว่าเมื่อผู้ใช้ฝากเงินจาก L1 หรือใช้ Force Inclusion สําหรับการทําธุรกรรมในสถานการณ์ที่เลวร้ายที่สุดมันจะรวมอยู่ในประวัติการทําธุรกรรม L2 หลังจาก 24 ชั่วโมง

Arbitrum's Force Inclusion Mechanism

In Optimism, the L1 deposit operation triggers a Transaction Deposited event, and then it's just a matter of waiting for the Sequencer to include the operation. h2 id="h2-arbitrum-s-force-inclusion-mechanism"Arbitrum's Force Inclusion Mechanism In Optimism, the L1 deposit operation triggers a Transaction Deposited event, and then it's just a matter of waiting for the Sequencer to include the operation. อย่างไรก็ตามใน Arbitrum การดําเนินการบน L1 (เช่นการฝากเงินหรือการส่งข้อความไปยัง L2) จะถูกเก็บไว้ในคิวบน L1 แทนที่จะปล่อยเหตุการณ์ ซีเควนเซอร์มีช่วงเวลาเฉพาะที่จะรวมธุรกรรมที่จัดคิวเหล่านี้ไว้ในประวัติการทําธุรกรรม L2 หากซีเควนเซอร์ไม่ทําเช่นนั้นภายในกรอบเวลานี้ทุกคนสามารถก้าวเข้ามาเพื่อทําการรวมในนามของซีเควนเซอร์ให้เสร็จสมบูรณ์

Arbitrum รักษาคิวในสัญญา L1 หาก Sequencer ไม่สามารถประมวลผลธุรกรรมในคิวภายในระยะเวลาหนึ่งทุกคนสามารถบังคับให้รวมธุรกรรมเหล่านี้ลงในประวัติธุรกรรม L2 ได้ ในการออกแบบของ Arbitrum การดําเนินการใน L1 เช่นเงินฝากจะต้องผ่านสัญญากล่องจดหมายล่าช้าซึ่งตามชื่อที่แนะนําการดําเนินการเหล่านี้จะล่าช้าก่อนที่จะมีผลบังคับใช้ อีกสัญญาหนึ่งคือ Sequencer Inbox เป็นที่ที่ Sequencer อัปโหลดธุรกรรม L2 ไปยัง L1 โดยตรง ทุกครั้งที่ Sequencer อัปโหลดธุรกรรม L2 ก็สามารถนําธุรกรรมที่รอดําเนินการบางอย่างจากกล่องจดหมายที่ล่าช้าและรวมไว้ในประวัติการทําธุรกรรม

เมื่อซีเควนเซอร์เขียนธุรกรรมใหม่ อาจรวมถึงธุรกรรมจาก DelayedInbox

การออกแบบที่ซับซ้อนและการขาดวัสดุอ้างอิง

หากคุณอ้างถึงเอกสารอย่างเป็นทางการของ Arbitrum เกี่ยวกับ Sequencer และ Force Inclusion คุณจะพบคําอธิบายทั่วไปเกี่ยวกับวิธีการทํางานของ Force Inclusion พร้อมกับชื่อพารามิเตอร์และฟังก์ชันบางอย่าง: ผู้ใช้จะเรียกฟังก์ชัน sendUnsignedTransaction ในสัญญา DelayedInbox ก่อน หาก Sequencer ไม่รวมไว้ภายในประมาณ 24 ชั่วโมง ผู้ใช้สามารถเรียกใช้ฟังก์ชัน forceInclusion บนสัญญา SequencerInbox อย่างไรก็ตามเอกสารอย่างเป็นทางการไม่ได้ให้ลิงก์ไปยังฟังก์ชันเหล่านี้ดังนั้นคุณต้องค้นหาในรหัสสัญญาด้วยตัวเอง เมื่อคุณพบฟังก์ชัน sendUnsignedTransaction คุณจะรู้ว่าคุณต้องกรอกค่า nonce และค่า maxFeePerGas ด้วยตัวคุณเอง ใครเป็นใคร? maxFeePerGas ของเครือข่ายใด คุณควรกรอกข้อมูลให้ถูกต้องอย่างไร? ไม่มีเอกสารอ้างอิงแม้แต่ NatSpec นอกจากนี้คุณยังจะได้พบกับฟังก์ชันที่คล้ายกันมากมายในสัญญา Arbitrum: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. ไม่มีเอกสารที่อธิบายความแตกต่างระหว่างฟังก์ชันเหล่านี้วิธีการใช้งานหรือวิธีการกรอกพารามิเตอร์แม้แต่ NatSpec

คุณลองกรอกพารามิเตอร์และส่งธุรกรรมด้วยวิธีการลองผิดลองถูกโดยหวังว่าจะพบการใช้งานที่ถูกต้อง อย่างไรก็ตามคุณพบว่าฟังก์ชันทั้งหมดเหล่านี้ใช้นามแฝงที่อยู่กับที่อยู่ L1 ของคุณทําให้ผู้ส่งธุรกรรมบน L2 เป็นที่อยู่ที่แตกต่างอย่างสิ้นเชิงทําให้ที่อยู่ L2 ของคุณไม่ได้ใช้งาน ต่อมาคุณบังเอิญสะดุดกับผลการค้นหาของ Google ที่เปิดเผยว่า Arbitrum มีไลบรารี Tutorial พร้อมสคริปต์ที่แสดงวิธีการส่งธุรกรรม L2 จาก L1 (โดยพื้นฐานแล้ว Force Inclusion) บทช่วยสอนแสดงรายการฟังก์ชันที่ไม่ได้กล่าวถึงก่อนหน้านี้: sendL2Message น่าแปลกที่พารามิเตอร์ข้อความที่จําเป็นคือธุรกรรม L2 ที่ลงนามโดยใช้บัญชี L2 ใครจะรู้ว่า "ข้อความที่ส่งไปยัง L2 ผ่าน Force Inclusion" เป็น "ธุรกรรม L2 ที่ลงนามแล้ว" นอกจากนี้ยังไม่มีเอกสารหรือ NatSpec อธิบายว่าจะใช้ฟังก์ชันนี้เมื่อใดและอย่างไร

สรุป: การสร้างธุรกรรมบังคับด้วยตนเองบน Arbitrum นั้นค่อนข้างซับซ้อน ขอแนะนําให้ทําตามบทช่วยสอนอย่างเป็นทางการและใช้ Arbitrum SDK ซึ่งแตกต่างจาก Rollups อื่น ๆ, Arbitrum ขาดเอกสารนักพัฒนาที่ชัดเจนและคําอธิบายประกอบรหัส. ฟังก์ชั่นจํานวนมากขาดคําอธิบายสําหรับวัตถุประสงค์และพารามิเตอร์ทําให้นักพัฒนาใช้เวลามากกว่าที่คาดไว้ในการรวมและใช้งาน ฉันยังขอความช่วยเหลือใน Arbitrum Discord แต่ไม่ได้รับคําตอบที่น่าพอใจ เมื่อถามใน Discord พวกเขาสั่งให้ฉันดู sendL2Message เท่านั้นและไม่ได้อธิบายฟังก์ชั่นของวิธีการอื่น ๆ (รวมถึงที่กล่าวถึงในเอกสาร Force Inclusion เช่น sendUnsignedTransaction) วัตถุประสงค์วิธีใช้หรือเวลาที่จะใช้

กลไก ForceInclusion ของ StarkNet

น่าเสียดายที่ปัจจุบัน StarkNet ไม่มีกลไกการรวมพลัง มีเพียงสองบทความในฟอรัมอย่างเป็นทางการที่กล่าวถึงการเซ็นเซอร์และการรวมกําลัง เหตุผลที่ไม่สามารถพิสูจน์ธุรกรรมที่ล้มเหลวคือระบบพิสูจน์ความรู้เป็นศูนย์ของ StarkNet ไม่สามารถพิสูจน์ธุรกรรมที่ล้มเหลวได้ดังนั้นจึงไม่อนุญาตให้รวม Force Inclusion หากมีคนประสงค์ร้าย (หรือไม่ตั้งใจ) Force รวมถึงธุรกรรมที่ล้มเหลวและไม่สามารถพิสูจน์ได้ StarkNet จะติดขัด: เพราะเมื่อรวมธุรกรรมแล้ว Prover จะต้องพิสูจน์ธุรกรรมที่ล้มเหลว แต่ไม่สามารถทําได้ StarkNet คาดว่าจะแนะนําความสามารถในการพิสูจน์ธุรกรรมที่ล้มเหลวในเวอร์ชัน v0.15.0 หลังจากนั้นควรใช้กลไก Force Inclusion ต่อไป

zkSync สําหรับการส่งข้อความ L1->L2 และ Force Inclusion ได้รับการจัดการผ่านฟังก์ชัน requestL2Transaction ของสัญญา MailBox ผู้ใช้ระบุที่อยู่ L2, calldata, จํานวน ETH ที่จะแนบ, ค่า L2GasLimit และรายละเอียดอื่น ๆ ฟังก์ชัน requestL2Transaction รวมพารามิเตอร์เหล่านี้เข้ากับธุรกรรม L2 และวางไว้ใน PriorityQueue เมื่อ Sequencer บรรจุธุรกรรมและอัปโหลดไปยัง L1 (ผ่านฟังก์ชัน commitBatches) จะระบุจํานวนธุรกรรมที่จะใช้จาก PriorityQueue เพื่อรวมไว้ในบันทึกธุรกรรม L2 ในแง่ของการรวมกําลัง zkSync นั้นคล้ายกับการมองโลกในแง่ดีโดยที่ที่อยู่ L2 ของผู้ริเริ่ม (เช่นเดียวกับที่อยู่ L1) ถูกใช้เพื่อเรียกฟังก์ชันที่เกี่ยวข้องและกรอกรายละเอียดที่จําเป็น (callee, calldata ฯลฯ ) แทนที่จะเป็น Arbitrum ซึ่งต้องใช้ธุรกรรม L2 ที่ลงนาม อย่างไรก็ตามในการออกแบบมันคล้ายกับ Arbitrum เนื่องจากทั้งคู่รักษาคิวบน L1 และ Sequencer ใช้ธุรกรรมที่รอดําเนินการที่ส่งโดยตรงจากผู้ใช้จากคิวและเขียนลงในประวัติการทําธุรกรรม

หากคุณฝากเงิน ETH ผ่านบริดจ์อย่างเป็นทางการของ zkSync เช่นธุรกรรมนี้จะเรียกฟังก์ชัน requestL2Transaction ของสัญญา MailBox ฟังก์ชันนี้วางธุรกรรม Deposit ETH L2 ลงใน PriorityQueue และปล่อยเหตุการณ์ NewPriorityRequest เนื่องจากสัญญาเข้ารหัสข้อมูลธุรกรรม L2 เป็นสตริงไบต์จึงไม่สามารถอ่านได้ง่าย อย่างไรก็ตามหากคุณดูพารามิเตอร์ของธุรกรรม L1 นี้คุณจะเห็นว่าผู้รับ L2 เป็นผู้ริเริ่มการทําธุรกรรมด้วย (เนื่องจากเป็นการฝากเงินให้กับตัวเอง) หลังจากนั้นครู่หนึ่งเมื่อ Sequencer นําธุรกรรม L2 นี้ออกจาก PriorityQueue และรวมไว้ในประวัติการทําธุรกรรมมันจะถูกแปลงเป็นธุรกรรม L2 ที่คุณโอนให้ตัวเอง จํานวนเงินที่โอนจะเป็นจํานวนเงิน ETH ที่ผู้ริเริ่มแนบมาในธุรกรรม L1 Deposit ETH ในธุรกรรมการฝากเงิน L1 ทั้งผู้ริเริ่มและผู้รับจะถูก 0xeDc1... 6909 จํานวนเงินคือ 0.03 ETH และไม่มีข้อมูลการโทร ใน L2 จะมีธุรกรรมที่ 0xeDc1... 6909 โอนให้ตัวเอง ชนิดธุรกรรม (TxnType) คือ 255 ซึ่งระบุธุรกรรมของระบบ จากนั้นเช่นเดียวกับที่ฉันทดลองกับฟังก์ชันธุรกรรมบังคับในการมองโลกในแง่ดีมาก่อนฉันเรียกฟังก์ชัน requestL2Transaction ของ zkSync และเริ่มธุรกรรมการโอนด้วยตนเอง: ไม่มี ETH แนบมาและ calldata มีการเข้ารหัส HEX ของสตริง "การรวมแรง" จากนั้นสิ่งนี้ถูกแปลงเป็นธุรกรรม L2 ที่ฉันโอนไปยังตัวเองด้วย calldata ที่มีสตริงเลขฐานสิบหกสําหรับ "การรวมกําลัง": 0x666f72636520696e636c7573696f6e เมื่อซีเควนเซอร์นําธุรกรรมจาก PriorityQueue และเขียนลงในประวัติการทําธุรกรรม จะถูกแปลงเป็นธุรกรรม L2 ที่สอดคล้องกัน การใช้ฟังก์ชัน requestL2Transaction ผู้ใช้สามารถส่งข้อมูลบน L1 ด้วยบัญชี L1 เดียวกันกับที่อยู่ L2 ระบุผู้รับ L2 จํานวน ETH ที่จะแนบและข้อมูลการโทร หากผู้ใช้ต้องการเรียกสัญญาอื่นหรือรวมข้อมูลที่แตกต่างกันพวกเขาเพียงแค่ต้องกรอกพารามิเตอร์ในฟังก์ชัน requestL2Transaction ยังไม่มีฟังก์ชันการรวมกําลังสําหรับผู้ใช้ แม้ว่าธุรกรรม L2 ที่อยู่ใน PriorityQueue จะมีระยะเวลารอที่คํานวณได้สําหรับการรวมโดย Sequencer แต่การออกแบบปัจจุบันของ zkSync ไม่มีฟังก์ชัน Force Inclusion ที่อนุญาตให้ผู้ใช้บังคับใช้ได้ ซึ่งหมายความว่ามันเป็นเพียงการแก้ปัญหาบางส่วน แม้ว่าจะมี "ระยะเวลารอการรวม" แต่ในที่สุดก็ขึ้นอยู่กับว่า Sequencer ตัดสินใจที่จะรวมไว้หรือไม่: Sequencer สามารถรวมไว้ได้หลังจากระยะเวลาหมดอายุหรือไม่รวมธุรกรรมใด ๆ จาก PriorityQueue ในอนาคต zkSync ควรเพิ่มฟังก์ชันที่อนุญาตให้ผู้ใช้บังคับให้รวมธุรกรรมลงในประวัติการทําธุรกรรม L2 หาก Sequencer ไม่ได้รวมไว้หลังจากระยะเวลารอ นี่จะเป็นกลไกการรวมกองกําลังที่มีประสิทธิภาพอย่างแท้จริง สรุป

L1 อาศัยผู้ตรวจสอบจํานวนมากเพื่อให้แน่ใจว่าเครือข่าย "ความปลอดภัย" และ "การต่อต้านการเซ็นเซอร์" อย่างไรก็ตาม Rollups มีความต้านทานการเซ็นเซอร์ที่อ่อนแอกว่าเนื่องจากธุรกรรมเขียนโดย Sequencer สองสามตัวหรือแม้แต่ตัวเดียว ดังนั้น Rollups จําเป็นต้องมีกลไก Force Inclusion เพื่อให้ผู้ใช้สามารถข้าม Sequencer และเขียนธุรกรรมลงในประวัติป้องกันการเซ็นเซอร์โดย Sequencer จากการทําให้ Rollup ไม่สามารถใช้งานได้และป้องกันไม่ให้ผู้ใช้ถอนเงิน Force Inclusion ช่วยให้ผู้ใช้สามารถบังคับให้เขียนธุรกรรมลงในประวัติได้ แต่การออกแบบต้องเลือกว่า "ธุรกรรมสามารถแทรกลงในประวัติได้ทันทีและมีผลทันที" หากอนุญาตให้มีผลทันที จะส่งผลเสียต่อ Sequencer เนื่องจากธุรกรรมที่รอดําเนินการใน L2 อาจได้รับผลกระทบจากธุรกรรมที่รวมไว้จาก L1 ดังนั้นกลไกการรวมกําลังในปัจจุบันใน Rollups จึงวางธุรกรรมที่แทรกจาก L1 เข้าสู่สถานะรอและให้ Sequencer มีกรอบเวลาในการตอบสนองและตัดสินใจว่าจะรวมธุรกรรมที่รอดําเนินการเหล่านี้หรือไม่ zkSync และ Arbitrum ทั้งคู่รักษาคิวบน L1 เพื่อจัดการธุรกรรม L2 หรือข้อความที่ส่งจาก L1 ถึง L2 Arbitrum เรียกมันว่า DelayedInbox; zkSync เรียกมันว่า PriorityQueue อย่างไรก็ตามวิธีการส่งธุรกรรม L2 ของ zkSync นั้นคล้ายกับ Optimism มากกว่าซึ่งข้อความจะถูกส่งจาก L1 โดยใช้ที่อยู่ L2 ดังนั้นเมื่อแปลงเป็นธุรกรรม L2 ตัวเริ่มต้นคือที่อยู่ L2 ฟังก์ชั่นสําหรับการส่งธุรกรรม L2 ในแง่ดีเรียกว่า depositTransaction; ใน zkSync เรียกว่า requestL2Transaction ในทางตรงกันข้าม Arbitrum สร้างธุรกรรม L2 ที่สมบูรณ์และลงนามจากนั้นส่งผ่านฟังก์ชัน sendL2Message บน L2, Arbitrum ใช้ลายเซ็นเพื่อคืนค่าผู้ลงนามเป็นผู้ริเริ่มธุรกรรม L2 ปัจจุบัน StarkNet ไม่มีกลไกการรวมพลัง zkSync มีกลไก Force Inclusion ที่ใช้ไปครึ่งหนึ่ง — มี PriorityQueue และธุรกรรม L2 แต่ละรายการในคิวมีระยะเวลาที่ถูกต้องในการรวม แต่ระยะเวลาที่ใช้ได้นี้เป็นเพียงการแสดงเท่านั้น ในทางปฏิบัติ Sequencer สามารถเลือกที่จะไม่รวมธุรกรรม L2 ใด ๆ จาก PriorityQueue

ข้อจํากัดความรับผิดชอบ:

1. บทความนี้ส่งต่อจาก: [Geek Web3] ชื่อเดิมคือ "ทฤษฎีและการปฏิบัติ: วิธีทริกเกอร์ธุรกรรมที่ทนต่อการเซ็นเซอร์ใน Ethereum Rollup", การระบุลิขสิทธิ์ของผู้เขียนต้นฉบับ [NIC Lin, Head of Taipei Ethereum Meetup] หากคุณมีการคัดค้านการพิมพ์ซ้ําโปรดติดต่อ Gate Learn Team ทีมงานจะจัดการโดยเร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

2. ข้อจํากัดความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้แสดงถึงมุมมองส่วนตัวของผู้เขียนเท่านั้นและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ

3. บทความเวอร์ชันภาษาอื่นแปลโดยทีม Gate Learn โดยไม่ต้องอ้างอิง Gate.io ห้ามคัดลอกแจกจ่ายหรือลอกเลียนแบบบทความที่แปลแล้ว