ผู้เขียนต้นฉบับ: jolestar (X: @jolestar )

ฉันเห็นเพื่อนหลายคนพูดคุยเกี่ยวกับ Based Rollup ซึ่งส่วนใหญ่มาจากมุมมองของความปลอดภัย ฉันอยากจะพูดเกี่ยวกับมุมมองของฉันเกี่ยวกับ Based Booster Rollup จากมุมมองของความสัมพันธ์ระหว่าง L1 และ L2 และการสร้างแอปพลิเคชัน

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

Booster Rollup เริ่มต้นจากอีกมุมมองหนึ่ง จะอ่านสถานะของ L1 โดยตรงผ่านสัญญาบน L2 ได้อย่างไร? จริงๆ แล้วแนวคิดนี้ไม่ซับซ้อน เนื่องจาก Based Rollup กำลังดำเนินการธุรกรรม L2 บน L1 แล้ว จะดำเนินการธุรกรรม L1 ด้วยเช่นกัน ด้วยวิธีนี้ สถานะของ L1 และ L2 จะอยู่ในแผนผังสถานะขนาดใหญ่ และสัญญาของ L2 จะสามารถอ่านสถานะของ L1 ได้โดยตรง

ดังนั้นจึงมีโปรเจ็กต์ที่รวม Based Rollup และ Booster Rollup เรียกว่า Based Booster Rollup (BBR) เช่น taiko

พื้นหลัง BBR

BBR ดึงดูดความสนใจของตลาดนับตั้งแต่มีการเสนอ พื้นหลังหลักคือปัญหาการกระจายตัวที่เกิดจากโซลูชัน L2 หลักในปัจจุบันของ Ethereum การกระจายตัวระหว่าง L1 และ L2 และการกระจายตัวระหว่าง L2 ฟังก์ชันที่มอบให้โดยโซลูชัน L2 ปัจจุบันไม่แตกต่างจาก Alt-L1 มากนัก ทั้งจากมุมมองของนักพัฒนาและผู้ใช้ การอ่านข้อมูล L1 ยังคงต้องอาศัย Oracle สินทรัพย์ยังคงต้องมีการเชื่อมโยง และกระเป๋าสตางค์ต้องเปลี่ยนเครือข่าย การแยกจากกันนี้ยังนำมาซึ่งปัญหาอีกประการหนึ่ง ความผูกพันระหว่าง L1 และ L2 นั้นไม่แน่นแฟ้นนัก L2 สามารถเพิ่มกลไกที่เป็นเอกฉันท์ได้ตลอดเวลาเพื่อให้กลายเป็น Alt-L1 "การพึ่งพาตนเองในฐานะราชา" และช่วยให้นักพัฒนาและผู้ใช้ โดยพื้นฐานแล้วไม่แยแส ความสัมพันธ์การเชื่อมโยงหลักในปัจจุบันมาจากข้อจำกัดของ EF ในเรื่องออร์โธดอกซ์: L2 ต้องใช้ L1 เป็น DA แต่เห็นได้ชัดว่าข้อจำกัดนี้ไม่เข้มงวด

ดังนั้นหากโซลูชัน L2 ในปัจจุบันทั้งหมดถูกแทนที่ด้วยโซลูชัน Based Rollup ปัญหาจะได้รับการแก้ไขหรือไม่ ฉันเดาว่าการมองโลกในแง่ดีและอนุญาโตตุลาการจะกระโดดออกมาและพูดว่า มันจะไม่ง่ายเลยที่จะเปลี่ยนเป็น Based Rollup หรือไม่? ปัจจุบัน โซลูชัน L2 หลักมีกลไก Force Inclusion L2 จะลบ Sequencer โดยตรง และอนุญาตให้ผู้ใช้ส่งธุรกรรมไปยัง L1 ผ่านทาง Force Inclusion

แต่สิ่งนี้สามารถแก้ปัญหาการกระจายตัวของข้อมูลได้หรือไม่? ไม่สามารถ แม้ว่า Arb และ Op จะส่งธุรกรรมไปยัง L1 แบบเรียลไทม์ และบรรจุและจัดเรียงโดย L1 แต่ธุรกรรมทั้งสองยังคงแยกจากกันเนื่องจากแต่ละธุรกรรมรับรู้เฉพาะธุรกรรมของตนเองเท่านั้น ณ จุดนี้ ทุกคนควรเข้าใจว่ากุญแจสำคัญในการแก้ปัญหาการกระจายตัวใน Based Rollup คือการมีธุรกรรมหรือข้อมูลที่สามารถแชร์ระหว่าง L2 และรูปแบบข้อมูลนี้ต้องการ:

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

• ต้องใช้ความเห็นพ้องต้องกันระหว่าง L2 และได้รับการสนับสนุนจาก L2 หลายตัว

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

จาก BBR ถึง BBSR, L2 แบบวางซ้อนกันได้

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

สาเหตุของความขัดแย้งนี้คือทุกคนสับสนกับธุรกรรมหลายประเภท:

1. ธุรกรรมที่ผู้ใช้ส่งโดยตรงไปยัง L1 และดำเนินการและตรวจสอบโดย L1 คือธุรกรรม L1

2. ผู้ใช้ส่งโดยตรงไปยัง L1 แต่ L1 ไม่ได้ตรวจสอบและดำเนินการธุรกรรมข้อมูลของโปรโตคอลที่ใช้ร่วมกันระหว่าง L2 โดยตรง ซึ่งอาจเรียกว่าธุรกรรม L1.5

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

Based Rollup เกี่ยวข้องกับ 1 และ 2 เท่านั้น 3 เป็นวิธีการทำงานปัจจุบันของ Sequencer Rollup ทั้งสองสามารถรวมกันได้อย่างสมบูรณ์

สมมติว่ามีแผน Rollup ดังกล่าว:

1. Sequencer จะซิงโครไนซ์ธุรกรรม L1 ทั้งหมด (รวมถึง L1.5) โดยอัตโนมัติ และดำเนินการตามลำดับที่กำหนดโดย L1

2. Sequencer รับธุรกรรม L2 ในเวลาเดียวกัน จัดเรียงธุรกรรมพร้อมกับธุรกรรม L1 แล้วดำเนินการ

ผ่าน 1 จะใช้ Base และ Booster และผ่าน 2 จะได้รับการยืนยันธุรกรรม L2 อย่างรวดเร็วโดยไม่สูญเสียประสบการณ์ผู้ใช้ หากคุณทำตามรูปแบบการตั้งชื่อก่อนหน้านี้ สิ่งนี้ควรจะเรียกว่า BBSR (Based Booster Sequencer Rollup) แต่มันยาวนิดหน่อยและไม่เข้าใจง่าย ดังนั้นฉันจึงเรียกมันว่า Stackable L2, stacked L2 ตามชื่อที่แนะนำ L2 จะถูกซ้อนกัน บน L1 และ L2 มีธุรกรรมและสถานะทั้งหมดของ L1 นี่คือ วิธีแก้ปัญหาของ @RoochNetwork

จะมั่นใจได้อย่างไรว่าธุรกรรม DA ของ L2? โรลอัพหรือโรลเอาท์?

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

การฝึกปฏิบัติ BBSR/Stackable L2 ของระบบนิเวศ Bitcoin

คำอธิบายก่อนหน้านี้ล้วนมาจากมุมมองของ Ethereum และ Rooch คือแนวทางปฏิบัติ BBSR หรือ Stackable L2 แรกของ Bitcoin เรามาพูดถึงความแตกต่างทางนิเวศวิทยาของ Bitcoin กันดีกว่า

ไม่มีสัญญาอัจฉริยะแบบทัวริงที่สมบูรณ์บน Bitcoin L2 และโหมดการสะสมตามจะกลายเป็นข้อได้เปรียบอย่างแท้จริง เนื่องจากชุดสะสมตามไม่จำเป็นต้องใช้ L1 ในการดำเนินการและตรวจสอบธุรกรรม จึงจำเป็นต้องมีเพียงการรับรอง Permission Less และ DA เท่านั้น สิ่งนี้ยังบังคับให้โครงการในระบบนิเวศ Bitcoin เริ่มออกแบบโปรโตคอลตามโครงสร้างข้อมูลเมื่อนานมาแล้ว ไม่ว่าจะเป็นเหรียญสีหรือ RGB ในภายหลัง, Taproot Assets, Ordinals Inscription, Atomics, Runs ฯลฯ ล้วนเป็นความพยายาม ในหมวดหมู่นี้ สามารถรวมไว้ภายใต้แนวคิดทั่วไปของโปรโตคอล CSV (การตรวจสอบฝั่งไคลเอ็นต์) และธุรกรรมของพวกเขาเป็นธุรกรรม L1.5 ทั่วไปทั้งหมด หากโครงการในระบบนิเวศ Ethereum ต้องการใช้ L2 แบบอิงและออกแบบโปรโตคอลที่ใช้ร่วมกันระหว่าง L2 หลายตัว โดยทั่วไปจะคล้ายกับโปรโตคอลข้างต้น

ลองใช้ Rooch เป็นตัวอย่างเพื่ออธิบายโหมดการทำงานของ BBSR บน Bitcoin:

1. ผู้ใช้จะส่งธุรกรรม L1 และ L1.5 ไปยัง Bitcoin โดยตรง เนื่องจากโปรโตคอลเป็นแบบสาธารณะ จุดเริ่มต้นจึงสามารถเป็นแอปพลิเคชันใดก็ได้

2. Rooch จะซิงโครไนซ์ธุรกรรม L1 ทั้งหมด ประมวลผล UTXO ในนั้น และค้นหาว่ามีข้อมูลโปรโตคอลเพิ่มเติมหรือไม่ จากนั้นใช้โมดูล Move ที่เกี่ยวข้องเพื่อประมวลผล ตัวอย่างเช่น ธุรกรรมที่ระบุว่าเป็น Inscription จะถูกประมวลผลโดยโมดูล ord ในขณะที่ธุรกรรมของ Babylon Stake จะถูกประมวลผลโดยโมดูล bbn

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

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

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

แน่นอนว่าระบบนิเวศของ Bitcoin ก็มีความท้าทายในเส้นทางนี้เช่นกัน:

1. การออกแบบดั้งเดิมของ Bitcoin ไม่ได้มีพื้นที่เพียงพอสำหรับการขยายสำหรับสถานการณ์ DA นี้ ดังนั้นรูปแบบในการเขียนข้อมูลไปยัง Bitcoin จึงเป็นหนึ่งในทิศทางที่โปรโตคอลต่างๆ ก่อนหน้านี้ได้พยายามสำรวจ เช่น OP_RETURN ที่ฝังข้อมูล ผ่านทาง Witness และแม้กระทั่งด้วยลายเซ็น ปัจจุบันยังขาดโซลูชันที่ได้มาตรฐาน

2. ระบบนิเวศของ Bitcoin ยังไม่บรรลุฉันทามติในวงกว้างเกี่ยวกับคุณค่าของข้อมูลที่ฝังอยู่ในห่วงโซ่ นี่เป็นทิศทางที่ฉันเรียกร้องตั้งแต่จารึกครั้งล่าสุด ดาต้าบัส) ค่า

ค่าของ L1 เป็นบัสข้อมูลสาธารณะทั่วโลก

นับตั้งแต่ DeFi ในช่วงฤดูร้อน เขตข้อมูล Crypto ทั้งหมดได้สำรวจแอปพลิเคชันใหม่ๆ นอกเหนือจาก DeFi ไม่ว่าจะเป็นความคลั่งไคล้การจารึก Bitcoin หรือการอภิปรายตาม Rollup ล่าสุด ก็สามารถเข้าใจได้ว่าเป็นการค้นพบคุณค่าของ L1 อีกครั้งในฐานะบัสข้อมูล จากมุมมองของระบบแบบกระจาย การแยกระหว่างระบบสามารถทำได้ผ่านบัสข้อมูล และการแยกส่วนระหว่างระบบเป็นหนึ่งในข้อกำหนดเบื้องต้นที่สำคัญสำหรับการได้รับสิทธิ์ที่น้อยลง ตัวอย่างเช่น การแลกเปลี่ยนแบบกระจายอำนาจในระบบนิเวศของ Crypto ใช้ Data Bus ของบล็อกเชนอย่างเต็มที่เพื่อให้บรรลุการเชื่อมต่อแบบ "กระจายอำนาจ" ซึ่งเป็นเรื่องยากที่จะบรรลุโดยตรงในระบบการเงินแบบดั้งเดิม หากคุณต้องการรองรับแอปพลิเคชันที่ซับซ้อนมากขึ้น คุณเพียงแค่ต้องอัปเกรดธุรกรรมการถ่ายโอนแบบธรรมดาเป็นธุรกรรมโปรโตคอลของแอปพลิเคชันเพื่อให้ได้รับสิทธิ์ระดับแอปพลิเคชันน้อยลง และวิธีการนี้จะรบกวนแอปพลิเคชันที่มีอยู่น้อยที่สุด

บทความนี้จะกล่าวถึง BBR จากมุมมองของระบบนิเวศและการประยุกต์เป็นหลัก ความปลอดภัยของโหมด BBR และการทำงานร่วมกันของสถานะ L1, L1.5 และ L2 ในโหมด BBR จะกล่าวถึงโดยละเอียดในบทความต่อๆ ไป สิ่งที่แนบมาคือลิงก์ที่เกี่ยวข้องในตอนท้าย รวมถึงบทความในอดีตของฉันและคำอธิบายของแฟน ๆ เกี่ยวกับ Rollup ตามมุมที่ต่างกัน

ลิงค์ที่เกี่ยวข้อง:
1. Stackable L2 — โซลูชันการขยายบล็อคเชนใหม่ https://rooch.network/zh-CN/blog/stackable-l2

2. ควรทำอย่างไรกับเลเยอร์ 2 ของ Bitcoin? https://x.com/jolestar/status/1717358817992995120 ฉันออกแบบแผนเริ่มต้นจาก L2 เกี่ยวกับวิธีใช้สถานะและข้อมูลบน Bitcoin L1 ในความคิดเห็น เพื่อนคนหนึ่งกล่าวถึงแผนของ Booster และท้ายที่สุด แผนของ Booster ก็คือ นำมาใช้ในทางปฏิบัติ

3. คำจารึกนั้นเป็นข้อบกพร่องหรือคุณสมบัติหรือไม่? https://x.com/jolestar/status/1732711942563959185 อธิบายคุณค่าของการจารึกจากมุมมองของวิธีสร้าง L2 รวมถึงปัญหาความเข้ากันได้ของแรงจูงใจของ L1 และ L2

4. หารือเกี่ยวกับ Rollup ตามทฤษฎีการลบ @kerne l1 983 https://web3 caff.com/zh/archives/108241

5. บทความของ @jason_chen 998 เกี่ยวกับ Based Rollup https://x.com/jason_chen998/status/1799692331635048697

6. รายงานการวิจัยการติดตามตาม Rollup https://research.web3 caff.com/zh/archives/22719

ลิงค์เดิม