Celestia Fellows Analyze Rollup (II): 4 โซลูชัน Rollup ใหม่

ขั้นสูง3/2/2024, 6:09:30 AM
เพื่อทำให้ Rollup model เข้าใจง่ายและสามารถวิเคราะห์ได้ง่ายขึ้น นักวิจัย Celestia ชื่อ NashQ ได้แบ่ง Sequencer ของ Rollup เป็นสอง entity ที่มีความ logic คือ Aggregator และ Header Generator ในเวลาเดียวกัน เขาแบ่งกระบวนการ sequencer transaction เป็น 3 ขั้นตอนที่มีความ logic คือ inclusion, ordering, และ execution (inclusion, ordering, และ execution) ด้วยจิตวิเคราะห์นี้ สามารถเห็นภาพรวมของ Sovereign Rollup 6 ตัวแปรที่สำคัญได้ชัดเจนและเข้าใจง่ายขึ้น

บทนำ: บทความนี้ถูกรวมกันโดยนักวิจัยของ Celestia ที่ชื่อ NashQ เกี่ยวกับคำแถลงทั่วไปเกี่ยวกับการวิเคราะห์โมเดล Rollup ซึ่งรวมถึง 4 เวอร์เชนต์ของ Rollup ใหม่ ก่อนหน้านี้ในบทความ " นักวิจัยของ Celestia วิเคราะห์ 6 ตัวแปร Rollup: Sequencer=Aggregator+Header Generator “, เขาระบุโมเดล Rollup 6 รูปแบบที่แตกต่างกัน และบทความนี้เป็นการสร้างรูปแบบใหม่ของโมเดล Rollup 4 ประเภทตามพื้นฐานของบทความนี้

ก่อนหน้านี้ NashQ แบ่งซีเควนเซอร์ซีเควนเซอร์ออกเป็นสองโมดูลคือ Aggregator + Header Producer และตัดวงจรชีวิตของคําแนะนําการทําธุรกรรมเพื่ออธิบายว่า Celestia Sovereign Rollup ทํางานอย่างไรสํารวจความต้านทานการเซ็นเซอร์และกิจกรรมของตัวแปร Rollup ที่แตกต่างกันรวมถึงการกําหนดค่าขั้นต่ําสําหรับผู้ใช้ที่จะลดความน่าเชื่อถือ (นั่นคือเป็น Trustless ประเภทขั้นต่ําของโหนดที่ผู้ใช้ค่าสะสมควรเรียกใช้คืออะไร)

Variant 7 : Based Rollup + Multiple Header Producers + “highest Protocol MEV”

ในตัวแปร Rollup นี้ผู้ใช้เครือข่าย Rollup โพสต์ข้อมูลธุรกรรมโดยตรงไปยังบล็อกเลเยอร์ DA แล้ว Header Producer รับผิดชอบการเรียงลำดับธุรกรรมและ MEV ถูกสกัดออกโดยมัน โดยชัดเจนว่ากระบวนการรวม/การรวมธุรกรรมของตัวแปร Rollup 7 เหมือนกับ Based Rollup ที่ได้ถูกนำเสนอแล้ว ซึ่งถูกดำเนินการโดยชั้น DA (ผู้ใช้โพสต์ธุรกรรมของพวกเขาโดยตรงไปยังชั้น DA) แต่การเรียงลำดับธุรกรรมแตกต่างจาก Based Rollup ในที่ว่าโหนดชั้น DA ไม่รับผิดชอบการเรียงลำดับซึ่งถูกดำเนินการโดย HP (Header Producer)

สมมติว่ามี HPs สามตัวที่แข่งขันกันและปฏิบัติตามโปรโตคอลการจัดสรร MEV ที่เรียกว่า "โปรโตคอล MEV สูงสุด" โปรโตคอลนี้เสนอโดย Skip Protocol ของ Cosmos eco-system ซึ่งแตกต่างจากโครงการ Ether PBS ในการที่ Block Builders จ่าย "เคล็ดลับ" เพิ่มเติมให้กับ Validators ของเครือข่ายบล็อกเชน และบล็อกที่สร้างโดยผู้สร้างที่มีทิปมากที่สุดจะถูกนํามาใช้โดย Validators บล็อกที่สร้างโดยผู้สร้างที่มีทิปมากที่สุดจะถูกนํามาใช้โดยผู้ตรวจสอบความถูกต้อง ในเวลาเดียวกัน SKIP Protocol นําเสนอแนวคิดของ "Sovereign MEV" ซึ่งตั้งใจที่จะให้ผู้ตรวจสอบทั้งหมดและชุมชนของเครือข่ายเครือข่ายสาธารณะมีอิสระในการจัดสรร MEV และแก้ปัญหาการเพิ่มการรวมศูนย์ของผู้สร้างเนื่องจากเอฟเฟกต์มู่เล่ใน Ethernet PBS (แต่นี่ไม่ใช่หลักของบทความนี้) ).

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

นอกจากนี้ หัวข้อกลุ่มที่เผยแพร่โดย HP จะต้องสามารถสอดคล้องกับกลุ่มธุรกรรมที่สมบูรณ์บนชั้น DA ในขณะที่เป็น Batch

หากมีข้อผิดพลาดในส่วนหัวที่เผยแพร่โดย HP เช่น ผลลัพธ์การดำเนินการธรรมชาติ Stateroot ไม่ถูกต้อง หรือไม่มีการดำเนินการเฉพาะใดๆในชุด (การทำธุรกรรมสูญหาย) โหนดเต็ม Rollup ที่ซื่อสัตย์จะส่งกระจายพิสูจน์การปลอมแปลง Fraud proof ไปยังโหนดแสง อย่างไรก็ตาม โดยทั่วไป (อย่างเต็มใจ) โหนดแสงสามารถยอมรับส่วนหัวที่เผยแพร่โดย HP และเชื่อว่ามันไม่มีปัญหาใดๆ

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

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

กิจกรรม: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

หากเลเยออินโทรไดตี้ชั้น DA มีข้อบกพร่องที่ใช้งาน จะทำให้ Rollup มีข้อบกพร่องที่ใช้งานเช่นกัน ตามพื้นฐานนี้ Rollup จะมีข้อบกพร่องที่ใช้งานเท่านั้นหาก HP ทุกตัวมีข้อบกพร่องที่ใช้งาน

เวอร์เซียนต์ 8: ZK Rollup พร้อมกับ Shared Aggregator + Decentralized Prover

ตัวแปร 8 ใช้ Shared Aggregator (SA) สำหรับการรวมรวมธุรกรรม + การเรียงลำดับ ที่นี่ SA เผยแพร่ชุดธุรกรรมลำดับบนชั้น DA และลำดับธุรกรรมทฤษฎีไม่เปลี่ยนแปลงหลังจากที่ลำดับธุรกรรมถูกส่งไปยังชั้น DA

และก่อนที่ชุดจะถูกส่งไปยังชั้น DA แอ็กกริเกตเตอร์ที่ร่วมกัน สามารถกระจายชุด+หัวหน้า SA ไปยังโหนดเต็มและProver และหัวหน้า SA ไปยังโหนดที่เบา โดยยกเว้นว่าในขณะนี้ชุดที่ไม่ได้อยู่ในชั้น DA ยังคงไม่มั่นคง และอาจถูกแทนที่ได้ทุกเมื่อ

สิ่งสำคัญที่ต้องทราบคือ หัวเรื่องที่เผยแพร่โดย Shared Aggregator SA ไม่เหมือนกับ Batch Header ที่เผยแพร่โดย HP หัวเรื่อง SA ประกอบด้วยการพิสูจน์ทางคริปโตเพื่อให้แน่ใจว่า Batch ที่โหนด Rollup อ่านจากชั้น DA จริงๆ ถูกสร้างโดย SA และไม่ได้ถูกปลอมแปลงโดยมัน

Prover reads the transaction batch Batch from the DA layer (and also synchronizes directly to the shared aggregator), generates a ZK Proof+Batch Header, and publishes it to the DA layer. Obviously Prover acts as the HP.

สําหรับโหนดแสงของ Rollup หลังจากได้รับ ZKProof ลําดับของธุรกรรมที่มีอยู่ในชุดนี้จะเสร็จสิ้น แน่นอนว่า Prover ยังสามารถออกอากาศ ZKP ผ่านเครือข่าย Rollup p2p ภายใต้ห่วงโซ่เลเยอร์ DA เพื่อให้สามารถรับโหนดแสงได้เร็วขึ้น แต่ในเวลานี้ ZKP ยังไม่ได้ส่งไปยังเลเยอร์ DA และไม่มี "ขั้นสุดท้าย"

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

Active: L = L_da && L_sa && L_pm. ส่วนใดของตัวแปรนี้ล้มเหลวในการใช้งาน Rollup จะล้มเหลวในการใช้งาน หาก Prover ล้มเหลว โหนดแสงจะไม่สามารถซิงโครไนส์ความคืบหน้าของสมุดบัญชี Rollup ได้อย่างมีประสิทธิภาพ แต่เนื่องจากโหนดเต็มซิงโครไนส์ลำดับการทำธุรกรรมทั้งหมด มันสามารถทำความคืบหน้าได้ ในขณะนี้ โหนดเต็มได้รับผลกระทบและโหนดแสงทั้งหมดล้มเหลว ซึ่งเทียบเท่ากับกรณีที่กล่าวถึงก่อนหน้านี้ของ Based Rollup กับ shared aggregator.

การกำหนดค่าขั้นต่ำสำหรับการลดความเชื่อถือ: โหนดเบา DA ระดับเบา + โหนดเครือข่ายอะก์รีเกเตอร์ที่ใช้ร่วมกัน + โหนด Rollup เบา

Variant 9: Shared Aggregator + Decentralized Prover + ZK-Rollup with multiple DAs

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

ขึ้นอยู่กับความต้องการของโปรเจ็กเตอร์ Rollup สามารถปรับแต่ง Rollup ที่ถูกที่สุดปลอดภัยที่สุดใช้งานมากที่สุดและเร็วที่สุดและสามารถเลือกเลเยอร์ DA ที่มีปริมาณงานสูงสุดได้ โดยทั่วไปแบทช์ของความสูงของบล็อกสะสมบางอย่าง (เช่น 10,000th) ไม่จําเป็นต้องมีอยู่ในเลเยอร์ DA ที่แตกต่างกันในเวลาเดียวกัน แต่ถ้าเป็นเช่นนั้นเนื้อหาของพวกเขาจะต้องเหมือนกัน หากมีแบทช์สองชุดที่มีความสูงเท่ากันและเนื้อหาต่างกันในเลเยอร์ DA ที่แตกต่างกันแสดงว่าผู้รวบรวมที่ใช้ร่วมกันมีส่วนร่วมในส้อมบัญชีแยกประเภทโดยเจตนา

ที่นี่เราเลือกตลาด Prover ที่ไม่ centralize เช่นเดียวกับในตัวแปร 8 ที่ Prover ทำหน้าที่ผู้ผลิตหัวเรื่องและเผยแพร่ Batch Header และ ZKProof ณ จุดนี้ Prover จำเป็นต้องแข่งขันผ่านกลไกประมูลทิปที่กล่าวถึงในตัวแปร 7 (ที่ของ SKIP Protocol)

ความเร็วในการตกลงธุรกรรม (ความเร็วในการยืนยันสุดท้าย) ของตัวแปร 9 ได้รับ影響จากชั้น DA ที่เร็วที่สุดที่ใช้งานอยู่ในบล็อก

การต่อต้านการเซ็นเซอร์: ผู้รวบรวมที่ใช้ร่วมกันสามารถมีส่วนร่วมในการโจมตีการเซ็นเซอร์ แต่จํานวนเลเยอร์ DA เสริมจะใหญ่ขึ้นและโอกาสในการโจมตีการเซ็นเซอร์ที่เกี่ยวข้องกับเลเยอร์ DA จะลดลง

Activity: L = ( L_da1 || L_da2) && L_sa && L_pm.

ตัวแปร 9 มีการใช้งานมากกว่าเมื่อเทียบกับตัวแปรก่อนหน้า ตราบใดที่ไม่มีความล้มเหลวของกิจกรรมในเครือข่ายเลเยอร์ DA ทั้งหมดทุกอย่างก็สามารถดําเนินการต่อได้ตามปกติ

ความกำหนดที่ต่ำที่สุดสำหรับการลดความเชื่อถือ: โหนดเบาในชั้น DA ที่แตกต่างกัน + โหนดเบาในเครือข่ายผู้รวมกลุ่มที่ใช้ร่วมกัน + โหนดเบา Rollup

เห็นได้ชัดว่ายิ่งเราใช้เลเยอร์ DA มากเท่าไหร่เราก็ยิ่งต้องเรียกใช้โหนดแสงมากขึ้นเท่านั้น แต่ประโยชน์ของสิ่งนี้อาจแทนที่ค่าใช้จ่าย

ตัวแปร 10: Two ZK-Rollups + Decentralized Prover ด้วยโหนดแสงออนเชนที่เชื่อมต่อกัน (สะพานได้)


ตัวแปร 10 เป็นการขยายของตัวแปร 5 ที่มีจุดมุ่งหมายเพื่อสร้าง 2 ZK-Rollups ที่สามารถเชื่อมต่อกัน ต่างกับตัวแปร 5 (เบส์ Rollup+ZKP+Decentralized Prover) ตัวแปร 10 มีบทบาทเพิ่มเติมของ Repeater Relayer ซึ่งครอบคลุม Batch Header+ZK-Proof ในธุรกรรมเดียวกัน การส่งธุรกรรมนี้ไปที่โหนดไฟฟ้า Rollup1 ที่วิ่ง Rollup2 พิสูจน์ว่า Batch ในระดับที่แน่นอนถูกต้อง แน่นอน Rollup2 ยังต้องทำงานกับโหนดไฟฟ้าของเลเยอร์ DA

นี่เป็นข้อกําหนดเบื้องต้นในการรักษาความน่าเชื่อถือของสะพานข้ามสายโซ่ให้น้อยที่สุด อย่างไรก็ตามหากมีการข้ามจาก Ether Rollup (SC Rollup ตามสัญญาอัจฉริยะ) ไปยัง Ether ไม่จําเป็นต้องเรียกใช้โหนดแสง DA-layer ของ Rollup อีกต่อไปเนื่องจาก DA-layer คือ Ether เอง สิ่งนี้แตกต่างอย่างมากจาก Sovereign Rollup ของ Celestia ซึ่ง Rollups ต้องเรียกใช้โหนดแสงชั้น DA ของกันและกันเพื่อข้ามกัน

เมื่อ Relayer ส่งธุรกรรม cross-chain มันจะถูกประมวลผลโดย aggregator 2 และ HP2 ของ Rollup2 เราเพิ่มทั้งสองเข้าไปในกราฟเพื่อเข้าใจว่าโหนดใน Rollup2 จะจัดการกับธุรกรรม cross-Rollup อย่างไร

Relayer ของตัวซ้ำของ Rollup 2 จะได้ Batch Header และ ZKP ของ Rollup 2 และส่งกลับไปที่ Rollup 1 Rollup 1 ยังมีโหนดแสงสำหรับ Rollup 2 และโหนดแสงสำหรับชั้น DA

เราสามารถทําให้โมเดลง่ายขึ้น สมมติว่า Rollups สองตัวใช้ Shared Aggregator และ Header Producer เดียวกันกล่าวอีกนัยหนึ่งคือพวกเขาใช้เลเยอร์ DA ที่ทับซ้อนกัน

ในกรณีนี้ ผู้เร่งเร็วสามารถถูกห้ามโดยตรง โดยที่ Batch Header และ ZK Proof ได้รับการเผยแพร่โดย HP ไปยังชั้น DA เดียวกัน ข้อมูลเช่น Header และ ZKP ของ Rollup อื่นๆ สามารถอ่านได้โดยตรงบนชั้น DA และไม่จำเป็นต้องส่งผ่านไปยัง Shared Aggregator ผ่าน Relayer อีกต่อไป

โดยทั่วไป Rollups ที่ใช้ชั้น DA เดียวกันไม่จำเป็นต้องพึ่งพาที่จะใช้ Relayers (สะพานทะลุสายแบ่งพื้นที่ต่างๆ มีการพึ่งพาโหนด Reley มากมาย) สามารถแก้ไขปัญหาด้านความปลอดภัยของสะพานทะลุสายแบ่งพื้นที่ (จากจุดนี้มองว่า การแปรผันระหว่าง SC Rollups ใน Ethernet จะปลอดภัยกว่าการแปรผันระหว่างโซนต่างๆ บนโซนสาธารณะต่างๆ)

ณจุดนี้ การกำหนดค่าต่ำสุดสำหรับการลดความเชื่อถือ: โหนดเบาระดับ DA + โหนดเบา Rollup

คำแถลง

  1. บทความนี้ถูกพิมพ์ซ้ำจาก [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], ลิขสิทธิ์เป็นของผู้เขียนเดิม[NashQ, Celestia ] หากคุณมีการคัดค้านการพิมพ์ซ้ําโปรดติดต่อ ทีม Gate Learn, ทีมจะได้รับการจัดการตามกระบวนการที่เกี่ยวข้องโดยเร็วที่สุด
  2. ข้อจํากัดความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้แสดงถึงมุมมองส่วนตัวของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
  3. บทความในภาษาอื่น ๆ ถูกแปลโดยทีม Gate Learn และอาจไม่สามารถทำสำเนา แจกจ่าย หรือคัดลอกได้โดยไม่มีการอ้างอิง Gate.io.

Celestia Fellows Analyze Rollup (II): 4 โซลูชัน Rollup ใหม่

ขั้นสูง3/2/2024, 6:09:30 AM
เพื่อทำให้ Rollup model เข้าใจง่ายและสามารถวิเคราะห์ได้ง่ายขึ้น นักวิจัย Celestia ชื่อ NashQ ได้แบ่ง Sequencer ของ Rollup เป็นสอง entity ที่มีความ logic คือ Aggregator และ Header Generator ในเวลาเดียวกัน เขาแบ่งกระบวนการ sequencer transaction เป็น 3 ขั้นตอนที่มีความ logic คือ inclusion, ordering, และ execution (inclusion, ordering, และ execution) ด้วยจิตวิเคราะห์นี้ สามารถเห็นภาพรวมของ Sovereign Rollup 6 ตัวแปรที่สำคัญได้ชัดเจนและเข้าใจง่ายขึ้น

บทนำ: บทความนี้ถูกรวมกันโดยนักวิจัยของ Celestia ที่ชื่อ NashQ เกี่ยวกับคำแถลงทั่วไปเกี่ยวกับการวิเคราะห์โมเดล Rollup ซึ่งรวมถึง 4 เวอร์เชนต์ของ Rollup ใหม่ ก่อนหน้านี้ในบทความ " นักวิจัยของ Celestia วิเคราะห์ 6 ตัวแปร Rollup: Sequencer=Aggregator+Header Generator “, เขาระบุโมเดล Rollup 6 รูปแบบที่แตกต่างกัน และบทความนี้เป็นการสร้างรูปแบบใหม่ของโมเดล Rollup 4 ประเภทตามพื้นฐานของบทความนี้

ก่อนหน้านี้ NashQ แบ่งซีเควนเซอร์ซีเควนเซอร์ออกเป็นสองโมดูลคือ Aggregator + Header Producer และตัดวงจรชีวิตของคําแนะนําการทําธุรกรรมเพื่ออธิบายว่า Celestia Sovereign Rollup ทํางานอย่างไรสํารวจความต้านทานการเซ็นเซอร์และกิจกรรมของตัวแปร Rollup ที่แตกต่างกันรวมถึงการกําหนดค่าขั้นต่ําสําหรับผู้ใช้ที่จะลดความน่าเชื่อถือ (นั่นคือเป็น Trustless ประเภทขั้นต่ําของโหนดที่ผู้ใช้ค่าสะสมควรเรียกใช้คืออะไร)

Variant 7 : Based Rollup + Multiple Header Producers + “highest Protocol MEV”

ในตัวแปร Rollup นี้ผู้ใช้เครือข่าย Rollup โพสต์ข้อมูลธุรกรรมโดยตรงไปยังบล็อกเลเยอร์ DA แล้ว Header Producer รับผิดชอบการเรียงลำดับธุรกรรมและ MEV ถูกสกัดออกโดยมัน โดยชัดเจนว่ากระบวนการรวม/การรวมธุรกรรมของตัวแปร Rollup 7 เหมือนกับ Based Rollup ที่ได้ถูกนำเสนอแล้ว ซึ่งถูกดำเนินการโดยชั้น DA (ผู้ใช้โพสต์ธุรกรรมของพวกเขาโดยตรงไปยังชั้น DA) แต่การเรียงลำดับธุรกรรมแตกต่างจาก Based Rollup ในที่ว่าโหนดชั้น DA ไม่รับผิดชอบการเรียงลำดับซึ่งถูกดำเนินการโดย HP (Header Producer)

สมมติว่ามี HPs สามตัวที่แข่งขันกันและปฏิบัติตามโปรโตคอลการจัดสรร MEV ที่เรียกว่า "โปรโตคอล MEV สูงสุด" โปรโตคอลนี้เสนอโดย Skip Protocol ของ Cosmos eco-system ซึ่งแตกต่างจากโครงการ Ether PBS ในการที่ Block Builders จ่าย "เคล็ดลับ" เพิ่มเติมให้กับ Validators ของเครือข่ายบล็อกเชน และบล็อกที่สร้างโดยผู้สร้างที่มีทิปมากที่สุดจะถูกนํามาใช้โดย Validators บล็อกที่สร้างโดยผู้สร้างที่มีทิปมากที่สุดจะถูกนํามาใช้โดยผู้ตรวจสอบความถูกต้อง ในเวลาเดียวกัน SKIP Protocol นําเสนอแนวคิดของ "Sovereign MEV" ซึ่งตั้งใจที่จะให้ผู้ตรวจสอบทั้งหมดและชุมชนของเครือข่ายเครือข่ายสาธารณะมีอิสระในการจัดสรร MEV และแก้ปัญหาการเพิ่มการรวมศูนย์ของผู้สร้างเนื่องจากเอฟเฟกต์มู่เล่ใน Ethernet PBS (แต่นี่ไม่ใช่หลักของบทความนี้) ).

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

นอกจากนี้ หัวข้อกลุ่มที่เผยแพร่โดย HP จะต้องสามารถสอดคล้องกับกลุ่มธุรกรรมที่สมบูรณ์บนชั้น DA ในขณะที่เป็น Batch

หากมีข้อผิดพลาดในส่วนหัวที่เผยแพร่โดย HP เช่น ผลลัพธ์การดำเนินการธรรมชาติ Stateroot ไม่ถูกต้อง หรือไม่มีการดำเนินการเฉพาะใดๆในชุด (การทำธุรกรรมสูญหาย) โหนดเต็ม Rollup ที่ซื่อสัตย์จะส่งกระจายพิสูจน์การปลอมแปลง Fraud proof ไปยังโหนดแสง อย่างไรก็ตาม โดยทั่วไป (อย่างเต็มใจ) โหนดแสงสามารถยอมรับส่วนหัวที่เผยแพร่โดย HP และเชื่อว่ามันไม่มีปัญหาใดๆ

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

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

กิจกรรม: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

หากเลเยออินโทรไดตี้ชั้น DA มีข้อบกพร่องที่ใช้งาน จะทำให้ Rollup มีข้อบกพร่องที่ใช้งานเช่นกัน ตามพื้นฐานนี้ Rollup จะมีข้อบกพร่องที่ใช้งานเท่านั้นหาก HP ทุกตัวมีข้อบกพร่องที่ใช้งาน

เวอร์เซียนต์ 8: ZK Rollup พร้อมกับ Shared Aggregator + Decentralized Prover

ตัวแปร 8 ใช้ Shared Aggregator (SA) สำหรับการรวมรวมธุรกรรม + การเรียงลำดับ ที่นี่ SA เผยแพร่ชุดธุรกรรมลำดับบนชั้น DA และลำดับธุรกรรมทฤษฎีไม่เปลี่ยนแปลงหลังจากที่ลำดับธุรกรรมถูกส่งไปยังชั้น DA

และก่อนที่ชุดจะถูกส่งไปยังชั้น DA แอ็กกริเกตเตอร์ที่ร่วมกัน สามารถกระจายชุด+หัวหน้า SA ไปยังโหนดเต็มและProver และหัวหน้า SA ไปยังโหนดที่เบา โดยยกเว้นว่าในขณะนี้ชุดที่ไม่ได้อยู่ในชั้น DA ยังคงไม่มั่นคง และอาจถูกแทนที่ได้ทุกเมื่อ

สิ่งสำคัญที่ต้องทราบคือ หัวเรื่องที่เผยแพร่โดย Shared Aggregator SA ไม่เหมือนกับ Batch Header ที่เผยแพร่โดย HP หัวเรื่อง SA ประกอบด้วยการพิสูจน์ทางคริปโตเพื่อให้แน่ใจว่า Batch ที่โหนด Rollup อ่านจากชั้น DA จริงๆ ถูกสร้างโดย SA และไม่ได้ถูกปลอมแปลงโดยมัน

Prover reads the transaction batch Batch from the DA layer (and also synchronizes directly to the shared aggregator), generates a ZK Proof+Batch Header, and publishes it to the DA layer. Obviously Prover acts as the HP.

สําหรับโหนดแสงของ Rollup หลังจากได้รับ ZKProof ลําดับของธุรกรรมที่มีอยู่ในชุดนี้จะเสร็จสิ้น แน่นอนว่า Prover ยังสามารถออกอากาศ ZKP ผ่านเครือข่าย Rollup p2p ภายใต้ห่วงโซ่เลเยอร์ DA เพื่อให้สามารถรับโหนดแสงได้เร็วขึ้น แต่ในเวลานี้ ZKP ยังไม่ได้ส่งไปยังเลเยอร์ DA และไม่มี "ขั้นสุดท้าย"

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

Active: L = L_da && L_sa && L_pm. ส่วนใดของตัวแปรนี้ล้มเหลวในการใช้งาน Rollup จะล้มเหลวในการใช้งาน หาก Prover ล้มเหลว โหนดแสงจะไม่สามารถซิงโครไนส์ความคืบหน้าของสมุดบัญชี Rollup ได้อย่างมีประสิทธิภาพ แต่เนื่องจากโหนดเต็มซิงโครไนส์ลำดับการทำธุรกรรมทั้งหมด มันสามารถทำความคืบหน้าได้ ในขณะนี้ โหนดเต็มได้รับผลกระทบและโหนดแสงทั้งหมดล้มเหลว ซึ่งเทียบเท่ากับกรณีที่กล่าวถึงก่อนหน้านี้ของ Based Rollup กับ shared aggregator.

การกำหนดค่าขั้นต่ำสำหรับการลดความเชื่อถือ: โหนดเบา DA ระดับเบา + โหนดเครือข่ายอะก์รีเกเตอร์ที่ใช้ร่วมกัน + โหนด Rollup เบา

Variant 9: Shared Aggregator + Decentralized Prover + ZK-Rollup with multiple DAs

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

ขึ้นอยู่กับความต้องการของโปรเจ็กเตอร์ Rollup สามารถปรับแต่ง Rollup ที่ถูกที่สุดปลอดภัยที่สุดใช้งานมากที่สุดและเร็วที่สุดและสามารถเลือกเลเยอร์ DA ที่มีปริมาณงานสูงสุดได้ โดยทั่วไปแบทช์ของความสูงของบล็อกสะสมบางอย่าง (เช่น 10,000th) ไม่จําเป็นต้องมีอยู่ในเลเยอร์ DA ที่แตกต่างกันในเวลาเดียวกัน แต่ถ้าเป็นเช่นนั้นเนื้อหาของพวกเขาจะต้องเหมือนกัน หากมีแบทช์สองชุดที่มีความสูงเท่ากันและเนื้อหาต่างกันในเลเยอร์ DA ที่แตกต่างกันแสดงว่าผู้รวบรวมที่ใช้ร่วมกันมีส่วนร่วมในส้อมบัญชีแยกประเภทโดยเจตนา

ที่นี่เราเลือกตลาด Prover ที่ไม่ centralize เช่นเดียวกับในตัวแปร 8 ที่ Prover ทำหน้าที่ผู้ผลิตหัวเรื่องและเผยแพร่ Batch Header และ ZKProof ณ จุดนี้ Prover จำเป็นต้องแข่งขันผ่านกลไกประมูลทิปที่กล่าวถึงในตัวแปร 7 (ที่ของ SKIP Protocol)

ความเร็วในการตกลงธุรกรรม (ความเร็วในการยืนยันสุดท้าย) ของตัวแปร 9 ได้รับ影響จากชั้น DA ที่เร็วที่สุดที่ใช้งานอยู่ในบล็อก

การต่อต้านการเซ็นเซอร์: ผู้รวบรวมที่ใช้ร่วมกันสามารถมีส่วนร่วมในการโจมตีการเซ็นเซอร์ แต่จํานวนเลเยอร์ DA เสริมจะใหญ่ขึ้นและโอกาสในการโจมตีการเซ็นเซอร์ที่เกี่ยวข้องกับเลเยอร์ DA จะลดลง

Activity: L = ( L_da1 || L_da2) && L_sa && L_pm.

ตัวแปร 9 มีการใช้งานมากกว่าเมื่อเทียบกับตัวแปรก่อนหน้า ตราบใดที่ไม่มีความล้มเหลวของกิจกรรมในเครือข่ายเลเยอร์ DA ทั้งหมดทุกอย่างก็สามารถดําเนินการต่อได้ตามปกติ

ความกำหนดที่ต่ำที่สุดสำหรับการลดความเชื่อถือ: โหนดเบาในชั้น DA ที่แตกต่างกัน + โหนดเบาในเครือข่ายผู้รวมกลุ่มที่ใช้ร่วมกัน + โหนดเบา Rollup

เห็นได้ชัดว่ายิ่งเราใช้เลเยอร์ DA มากเท่าไหร่เราก็ยิ่งต้องเรียกใช้โหนดแสงมากขึ้นเท่านั้น แต่ประโยชน์ของสิ่งนี้อาจแทนที่ค่าใช้จ่าย

ตัวแปร 10: Two ZK-Rollups + Decentralized Prover ด้วยโหนดแสงออนเชนที่เชื่อมต่อกัน (สะพานได้)


ตัวแปร 10 เป็นการขยายของตัวแปร 5 ที่มีจุดมุ่งหมายเพื่อสร้าง 2 ZK-Rollups ที่สามารถเชื่อมต่อกัน ต่างกับตัวแปร 5 (เบส์ Rollup+ZKP+Decentralized Prover) ตัวแปร 10 มีบทบาทเพิ่มเติมของ Repeater Relayer ซึ่งครอบคลุม Batch Header+ZK-Proof ในธุรกรรมเดียวกัน การส่งธุรกรรมนี้ไปที่โหนดไฟฟ้า Rollup1 ที่วิ่ง Rollup2 พิสูจน์ว่า Batch ในระดับที่แน่นอนถูกต้อง แน่นอน Rollup2 ยังต้องทำงานกับโหนดไฟฟ้าของเลเยอร์ DA

นี่เป็นข้อกําหนดเบื้องต้นในการรักษาความน่าเชื่อถือของสะพานข้ามสายโซ่ให้น้อยที่สุด อย่างไรก็ตามหากมีการข้ามจาก Ether Rollup (SC Rollup ตามสัญญาอัจฉริยะ) ไปยัง Ether ไม่จําเป็นต้องเรียกใช้โหนดแสง DA-layer ของ Rollup อีกต่อไปเนื่องจาก DA-layer คือ Ether เอง สิ่งนี้แตกต่างอย่างมากจาก Sovereign Rollup ของ Celestia ซึ่ง Rollups ต้องเรียกใช้โหนดแสงชั้น DA ของกันและกันเพื่อข้ามกัน

เมื่อ Relayer ส่งธุรกรรม cross-chain มันจะถูกประมวลผลโดย aggregator 2 และ HP2 ของ Rollup2 เราเพิ่มทั้งสองเข้าไปในกราฟเพื่อเข้าใจว่าโหนดใน Rollup2 จะจัดการกับธุรกรรม cross-Rollup อย่างไร

Relayer ของตัวซ้ำของ Rollup 2 จะได้ Batch Header และ ZKP ของ Rollup 2 และส่งกลับไปที่ Rollup 1 Rollup 1 ยังมีโหนดแสงสำหรับ Rollup 2 และโหนดแสงสำหรับชั้น DA

เราสามารถทําให้โมเดลง่ายขึ้น สมมติว่า Rollups สองตัวใช้ Shared Aggregator และ Header Producer เดียวกันกล่าวอีกนัยหนึ่งคือพวกเขาใช้เลเยอร์ DA ที่ทับซ้อนกัน

ในกรณีนี้ ผู้เร่งเร็วสามารถถูกห้ามโดยตรง โดยที่ Batch Header และ ZK Proof ได้รับการเผยแพร่โดย HP ไปยังชั้น DA เดียวกัน ข้อมูลเช่น Header และ ZKP ของ Rollup อื่นๆ สามารถอ่านได้โดยตรงบนชั้น DA และไม่จำเป็นต้องส่งผ่านไปยัง Shared Aggregator ผ่าน Relayer อีกต่อไป

โดยทั่วไป Rollups ที่ใช้ชั้น DA เดียวกันไม่จำเป็นต้องพึ่งพาที่จะใช้ Relayers (สะพานทะลุสายแบ่งพื้นที่ต่างๆ มีการพึ่งพาโหนด Reley มากมาย) สามารถแก้ไขปัญหาด้านความปลอดภัยของสะพานทะลุสายแบ่งพื้นที่ (จากจุดนี้มองว่า การแปรผันระหว่าง SC Rollups ใน Ethernet จะปลอดภัยกว่าการแปรผันระหว่างโซนต่างๆ บนโซนสาธารณะต่างๆ)

ณจุดนี้ การกำหนดค่าต่ำสุดสำหรับการลดความเชื่อถือ: โหนดเบาระดับ DA + โหนดเบา Rollup

คำแถลง

  1. บทความนี้ถูกพิมพ์ซ้ำจาก [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], ลิขสิทธิ์เป็นของผู้เขียนเดิม[NashQ, Celestia ] หากคุณมีการคัดค้านการพิมพ์ซ้ําโปรดติดต่อ ทีม Gate Learn, ทีมจะได้รับการจัดการตามกระบวนการที่เกี่ยวข้องโดยเร็วที่สุด
  2. ข้อจํากัดความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้แสดงถึงมุมมองส่วนตัวของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
  3. บทความในภาษาอื่น ๆ ถูกแปลโดยทีม Gate Learn และอาจไม่สามารถทำสำเนา แจกจ่าย หรือคัดลอกได้โดยไม่มีการอ้างอิง Gate.io.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!