บทนำ

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

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

ปัญหาของการแยกส่วน

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

ประสบการณ์ผู้ใช้: การกระจายตัวบังคับให้ผู้ใช้เปลี่ยนเครือข่ายบ่อยครั้งจัดการสําเนาหลายสําเนาของโทเค็นเดียวกันและเล่นปาหี่กระเป๋าเงินต่างๆ สิ่งนี้เพิ่มแรงเสียดทานและความซับซ้อนทําให้ผู้ใช้เพลิดเพลินกับประสบการณ์ Ethereum ที่ "ใช้งานได้จริง" ได้ยากขึ้น ตัวอย่างเช่น สมมติว่าอลิซมีเงินของเธอในโรลอัพ A แต่ต้องการซื้อโทเค็นที่มีเฉพาะใน Rollup B เท่านั้น แทนที่จะคลิก "ซื้อ" เธอต้องเปลี่ยนเครือข่ายโอนเงินจาก A เป็น B รอการยืนยัน L1 ก่อนจากนั้นจึงดําเนินการซื้อขาย

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

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

การทำงานร่วมกัน

ในพื้นฐานแล้ว การทำงานร่วมกันหมายความว่าการทำให้ธุรกรรมที่เริ่มต้นที่รูปแบบหนึ่งและอัปเดตสถานะที่รูปแบบอื่น - เช่น การส่งโทเค็นจาก Rollup A ไปยัง Rollup B ที่เหมาะสม การกระทำนี้ควรจะเรียบง่ายเพียงแค่ลดยอดคงเหลือของคุณใน A ลงและยอดคงเหลือของคุณใน B ขึ้นพร้อมๆกัน ในทางปฏิบัติ การที่จะบรรลุพฤติกรรมที่เรียบง่าย “ทั้งหมดหรือไม่มี” ระหว่างรูปแบบที่แตกต่างกันนั้นมีความท้าทาย

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

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

บทความนี้เน้นที่การทำงานร่วมกันระดับโปรโตคอลที่ต้องการการบูรณาการ เราไม่รวมทางเลือกสำหรับการเชื่อมต่อภายนอกที่เชื่อมโยงกับผู้ให้บริการ Likuidity และรองรับการโอนโทเคนแบบแท่งเงินเท่านั้น

ความท้าทายของการทำงานร่วมกัน

การทำงานร่วมกันระหว่าง rollups อย่างแท้จริงไม่ได้เกี่ยวข้องกับการส่งข้อความไปมาเท่านั้น มันเกี่ยวกับการให้การทำธุรกรรมเสร็จสิ้นอย่างปลอดภัยและรวดเร็ว การพึ่งพาเฉพาะที่ Ethereum L1 อาจหมายถึงความล่าช้าและค่าใช้จ่ายสูง อลิซมีเงินอยู่ใน rollup A แต่ต้องการซื้อโทเคนที่มีอยู่เฉพาะบน Rollup B มีทางเลือกอยู่ 2 ทาง

• Rollup B ยอมรับเฉพาะเงินของ Alice หากเชื่อมต่อผ่าน Ethereum ในกรณีนี้อลิซจําเป็นต้องถอนเงินของเธอไปที่ L1 จากนั้นฝากไว้ในโรลอัพ B และในที่สุดก็ซื้อโทเค็นในโรลอัพ B ทําให้เกิดความล่าช้าและค่าใช้จ่ายสูง
• Rollup B ให้ทางเลือกที่เร็วและถูกกว่าโดยการประมวลผลการโอนโดยตรง แทนที่จะตกลงบน Ethereum Layer 1 ก่อน อย่างไรก็ตาม เราจะอธิบายต่อไปว่า นี่เป็นการเปิดเผย Rollup B ต่อความเสี่ยงที่อาจเกิดขึ้นถ้า Rollup A เกิดการละเมิด ไม่ตกลง หรือยื่นสถานะการเปลี่ยนแปลงที่ไม่ถูกต้อง

เมื่อ L2 สองรายการมีการโต้ตอบกันที่ความล่าช้ากว่า Ethereum (ย่อความหมายคือ ก่อนที่พวกเขาจะยืนยันหรือตรวจสอบการเปลี่ยนสถานะของพวกเขาไปยัง L1) มีปัญหาพื้นฐานที่สามที่ rollups ต้องจัดการ: การโพลกสากล, การไม่ถูกต้อง, และ การไม่ตกลง

• Equivocation: การโรลอัพกระจายสถานะที่ขัดแย้งกันไปยังเชนที่แตกต่างกัน โดยสัญญาให้ทรัพย์สินเดียวกันหลายครั้ง
• ความไม่ถูกต้อง: การเปลี่ยนสถานะอาจจะไม่สามารถพิสูจน์ได้ว่าถูกต้องบน L1 ได้
• การไม่ตกลง: กระบวนการสร้างหลักฐานหรือการตกลงอาจหยุดชะงักไปอย่างไม่มีที่สิ้นสุด

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

ขอให้เราอธิบายความท้าทายเหล่านี้ด้วยตัวอย่าง: สมมติว่า Alice เป็นเจ้าของ 10 ETH บน Scroll mainnet และต้องการโอนให้ Bob ใน Arbitrum ในที่สุด Alice ควรสามารถย้าย Likuidity ระหว่างสองเครือง่าย ๆ ได้ที่ Latency ที่เร็วกว่า Ethereum สมมติว่ามีวิธีการแก้ปัญหาแบบนั้นอยู่แล้ว ในที่นี้ Arbitrum มีการโอนเงินให้ Alice 10 ETH ใน Arbitrum ก่อนที่ Scroll จะส่งอะไรไปที่ L1 สิ่งใดสามารถผิดพลาดได้สำหรับ Arbitrum หรือไม่

• Equivocation: เลื่อน equivocates โดยกระทําใน L1 การเปลี่ยนแปลงสถานะที่แตกต่างกันซึ่งไม่รวมการทําธุรกรรมของอลิซอย่างมีประสิทธิภาพปล้น 10 ETH จาก Arbitrum (ซึ่งจําเป็นต้อง reorg เพื่อให้สามารถชําระได้)
• ความไม่ถูกต้อง: การเลื่อนไม่เทียบเท่ากัน แต่การเปลี่ยนสถานะที่มีการทำธุรกรรมไม่ถูกต้อง และดังนั้น Scroll ไม่สามารถชำระเงิน (เช่น พิสูจน์) บน L1 และมอบเงินให้กับ Arbitrum อีกครั้ง Arbitrum ต้องทำการ reorg เพื่อสามารถชำระเงินได้
• การไม่ตั้งชำระเงิน: สครอลไม่สับสนและการเปลี่ยนสถานะถูกต้อง แต่โปรแวร์ที่ได้รับการกำหนดของสครอลออฟไลน์ และดังนั้นการชำระเงินไม่เกิดขึ้นเลย อาร์บิทรัมจำเป็นต้องทำการ reorg อีกครั้ง

โดย Arbitrum รวมถึง 10 ETH ที่ถูกส่งมาจาก Alice ใน Scroll ก่อนที่ Scroll จะยอมรับบน L1 (ในกรณีของการปฏิเสธ) และก่อนที่ Scroll จะตกลง (ในกรณีของความไม่ถูกต้องและไม่ตกลง) Arbitrum รับความเสี่ยงในเชื่อมโยงโซ่ของมัน ขึ้นอยู่กับข้อคิดการประเมินความปลอดภัยของ Scroll

ความสำคัญของความสามารถในการทำงานร่วมกันของ rollup คือวิธีการระบบจัดการกับการทำเท็จกันได้ โครงสร้างที่แตกต่างกันจะใช้อุปกรณ์ที่แตกต่างกัน ในระบบบางระบบเช่น OP Superchain rollups ถูกออกแบบให้ทำการ reorg ร่วมกัน - หาก rollup หนึ่งทำเท็จ rollups ที่เชื่อมต่อทั้งหมดจะต้องทำการ reorg สถานะของตัวเองเพื่อรักษาความสอดคล้องในระบบ คุณสมบัติที่เรียกว่า cross-chain contingent blocks โครงสร้างอื่นๆ ให้ความสำคัญกับการป้องกันการทำเท็จโดยสมบูรณ์ผ่านกลไกต่างๆ ที่เราจะสำรวจด้านล่าง

ทั้งการไม่ชําระหนี้และความไม่ถูกต้องจะได้รับการแก้ไขเล็กน้อยเมื่อการสร้างหลักฐาน zk แบบเรียลไทม์กลายเป็นจริง (หรือที่เรียกว่าการพิสูจน์แบบเรียลไทม์) อย่างไรก็ตามปัญหาของความเท่าเทียมกันนั้นแตกต่างกันโดยพื้นฐาน หลักฐาน zk สามารถพิสูจน์ได้ว่าอลิซส่ง 10 ETH ให้กับ Bob บน Arbitrum แต่ไม่ได้รับประกันว่า Scroll จะกระทําการเปลี่ยนแปลงนี้ใน L1 การพิสูจน์ Zk เพียงอย่างเดียวไม่แก้และจะไม่แก้ปัญหาความเท่าเทียมกัน จากนั้นอีกครั้งการรอการตั้งถิ่นฐาน L1 แก้ปัญหาความเท่าเทียมกัน แต่ในราคาความได้เปรียบด้านความเร็วของค่าสะสม ดังนั้นเราจึงมุ่งเน้นไปที่ความเท่าเทียมกันก่อนการตั้งถิ่นฐานเช่นการรับประกันการป้องกันความเท่าเทียมกันก่อนที่จะชําระให้กับ Ethereum ดังที่เราจะเห็นแต่ละวิธีเกี่ยวข้องกับการแลกเปลี่ยนที่แตกต่างกันโดยเฉพาะอย่างยิ่งในแง่ของสมมติฐานความไว้วางใจที่เรากล่าวถึงด้านล่าง

โครงสร้างการทำงานร่วมกัน

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

โดยสรุปโมเดลเครือข่าย (mesh model) คือที่ rollups เชื่อมต่อโดยตรงกันและมีความเชื่อในกันที่จะไม่เทียบเท่ากันเพื่อให้ได้ความสมบูรณ์ก่อนการตกลง

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

เครื่องต่อเข้า

โมเดลเชือกทำงานเหมือนที่คุณคาดหวัง โดย rollups ที่สื่อสารกันโดยตรงในขณะที่ยังคงรับผิดชอบในการตัดสินใน Ethereum L1 โดยตนเอง:

เมื่อมี rollups มากขึ้นและเชื่อมต่อกันในเครือข่ายขนาดใหญ่นี้ ความโตนิยมและความขึ้นอยู่กับอีกฝั่งมีความยุ่งเหยิงสำหรับการขยายขอบเขตได้ หาก Arbitrum เชื่อว่า Scroll แต่ไม่เชื่อว่า zkSync แล้ว Scroll จึงไม่สามารถเชื่อว่า zkSync ในขณะที่ยังรักษาความเชื่อของ Arbitrum ได้ เฉพาะ "กลุ่มเชื่อ" ที่แยกต่างหาก กลุ่มของ rollups สามารถมีปฏิสัมพันธ์กับกันในเครือข่ายได้ ปัญหาขึ้นอยู่กับอีกฝั่งเพิ่มขึ้นเมื่อมี rollups มากขึ้นและมีความซับซ้อนในกรณีการทำงานร่วมกัน ที่ความปลอดภัยของทั้งหมดถูก จำกัด โดยความปลอดภัยของ rollup ที่อ่อนแอที่สุด

ในขณะที่ระบบเครือข่ายเชื่อถือในเรื่องความปลอดภัยก่อนการตกลงระหว่างกัน แต่พวกเขาสามารถตรวจจับการทะเลาะเอกพร้อมกับการตกลง ทำให้เกิดการ Reorg ในทุกๆ rollup ที่เชื่อมต่อกัน

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

Hub

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

ข้อดีของวิธีการนี้คือการเพิ่ม rollups เพิ่มเติมในระบบไม่สร้างปัญหาเชื่อมโยงมากขึ้น เนื่องจากชั้น interop ทำหน้าที่เป็น "shield" ระหว่างแต่ละ rollup สามารถรวม L2 chains อย่างอิสระ รวมถึง L3s และ app rollups ทั้งหมดที่ต้องทำคือรวมเข้ากับ hub และเพลิดเพลินกับประโยชน์

ข้อเสียหลักของวิธีการนี้คือ rollup ทั้งหมดมีการพึ่งพากันใน hub ที่ได้รับอำนาจที่สำคัญ

โดยเฉพาะอย่างยิ่งสำหรับการป้องกันความสงสัยก่อนการตัดสิน เราต้องให้ความมั่นใจว่าฮับจะไม่ทำการคุกคามกับ equivocating rollup ระบบฮับจึงจะแทนที่ความไว้วางใจระหว่าง rollups ในการออกแบบเครือข่าย ด้วยความไว้วางใจในชั้นที่ใช้ร่วมกันเดียวซึ่งต้องไม่ทำการคุกคามกับ rollups อื่นเพื่อเขิน

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

• การใช้ rollup ที่มีอยู่: ตัวเลือกนี้มีข้อดีคือมันเป็นวิธีที่ง่ายที่สุดเนื่องจาก rollup มีอยู่แล้วและน่าจะผ่านการทดสอบในสงครามแล้ว และมันจะเป็นเรื่องของการใช้งานสมาร์ทคอนแทรคต์บนมัน
• การสร้างส่วนประกอบที่ถูกกำหนด: แทนที่จะขอให้ rollups พึ่งพากับคุณสมบัติด้านความปลอดภัยของ rollup ที่มีอยู่เราจึงสร้างส่วนประกอบใหม่ที่จะทำหน้าที่เป็นศูนย์กลาง ข้อดีที่นี่คือส่วนประกอบใหม่นี้จะมีพื้นที่เสียบัก/การโจมตีที่ลดลงโดยเฉพาะที่ถูกออกแบบมาเพื่อการต้องการต่างๆ (และอาจจะได้รับการตรวจสอบอย่างเป็นทางการ!)
• การใช้ Ethereum L1 ตัวเอง: ตัวเลือกนี้เกี่ยวข้องกับการใช้การยืนยันก่อนที่จะตั้งโดยตรงบน Layer 1 เพื่อให้ได้สิ่งที่ดีที่สุดจากทั้งสองโลก: ใช้ชั้นที่มีการกระจายอย่างสูงสุดสำหรับความมีชีวิตชีวาและความปลอดภัยในขณะที่มีการยืนยันอย่างใกล้เคียงทันที ลดเวลาถอนเงิน เป็นต้น

ในกรณีที่ใช้พิสูจน์ zk ทั้งสามแบบนี้สามารถใช้แนวคิดของการรวบรวมพิสูจน์เพื่อลดค่าใช้จ่ายอีกต่อไปโดยการให้ L1 ตรวจสอบพิสูจน์เดียวที่รวมกันจากพิสูจน์รายบุคคลหลายๆ จาก rollups ทั้งหมดที่รองรับโดย hub

ระบบที่มีอยู่

โปรเจคต์หลายๆ โปรเจคต์ได้เสนอวิธีการทำงานร่วมกันที่แตกต่างกัน ซึ่งสามารถจัดหมวดหมู่ได้ดังนี้

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

โซลูชันเหล่านี้อาจเปลี่ยนไปใช้ฮับบางประเภทเนื่องจากกลุ่มความไว้วางใจไม่สามารถขยายได้เกินกว่าการรวมตัวกันครั้งใหญ่สองสามครั้งเพื่อให้บรรลุขั้นสุดท้ายก่อนการตั้งถิ่นฐาน

ระบบฮับ Espresso และ zkSync’s โซ่ยืดหยุ่นระบบเกต ที่ Scroll เราได้สำรวจการออกแบบระบบเกตที่สามารถเป็นมากขึ้นและเชื่อถือได้มากยิ่งขึ้นสำหรับการแก้ปัญหาการทำงานร่วมกันที่มีความยืดหยุ่นมากขึ้นการนำเสนอที่งานสัมมนาคริปโตเธคนอมิกซ์ที่ Columbia ปี 2024 นี้จะให้ภาพรวมของการออกแบบ โดยจะมีรายละเอียดเพิ่มเติมในโพสต์ต่อไป

ระบบอื่น ๆ รอลอัพที่มีฐานที่สามารถเปิดให้เห็นถึงความสามารถในการทำงานร่วมกันอย่างเดียวกับกันเองไม่เพียงแต่กันเอง เเต่ยังสามารถใช้ Ethereum L1 สำหรับการป้องกันการขัดแย้ง

AggLayer ของ Polygon เป็นระบบประเภทหนึ่งที่ให้บริการเส้นทางร่วมที่ทุกๆคนสามารถสื่อสารกัน อย่างไรก็ตาม มันแตกต่างกันด้วยการหลีกเลี่ยงความสมัครใจเพิ่มเติมในชั้นที่ใช้ร่วมกันนั้น แทนที่จะรอการตกลงและใช้พิสิฐ เพื่อความปลอดภัย การเทียบเคียงจึงถูกป้องกันเฉพาะในเวลาชําระบัญชีเท่านั้น การยืนยันล่วงหน้าสามารถเลือกใช้เพื่อเสนอการรับประกันขั้นสุดท้ายได้เร็วขึ้น AggLayer เพิ่งประกาศ ความร่วมมือด้วยระบบ Espresso ซึ่งให้กลไกการเรียงลำดับที่ใช้ร่วมกัน

สรุป

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

ข้อความปฏิเสธความรับผิดชอบ:

1. บทความนี้ถูกพิมพ์ใหม่จาก [ Scroll Research]. All copyrights belong to the original author [Alejandro Ranchal-Pedrosa]. หากมีการทยอยเป็นขั้นต่อการพิมพ์ฉบับนี้ โปรดติดต่อ Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่สมบูรณ์ของคำแนะนำในการลงทุนใด ๆ
3. ทีม Gate Learn ทำการแปลบทความเป็นภาษาอื่น ๆ การคัดลอก การกระจาย หรือการลอกเลียนบทความที่แปลนั้นถูกห้าม นอกจากจะได้ระบุไว้