บทนำ:

ฉาก Bitcoin Layer2 ในปัจจุบันคึกคักด้วยโซลูชันทางเทคโนโลยีที่หลากหลายมาบรรจบกันในหม้อหลอมละลายของระบบนิเวศ BTC ด้วยความก้าวหน้าอย่างรวดเร็วของการทําซ้ําในสาขาบล็อกเชนซึ่งคําศัพท์และมาตรฐานระดับมืออาชีพมีการพัฒนาอย่างต่อเนื่องผ่านการวิจัยนวัตกรรมและการดําเนินการทางวิศวกรรมหลายโครงการจึงหันไปใช้ "การสร้างแนวคิด" หรือ "การผูกปมแนวคิด" เพื่อความแตกต่างและความสนใจกลายเป็นกฎที่ไม่ได้พูดในอุตสาหกรรม ตัวอย่างเช่น โครงการบล็อกเชนแบบแยกส่วนหลายโครงการที่เริ่มใช้งานในระบบนิเวศ Ethereum/Celestia ได้กระโดดขึ้นไปบน bandwagon "Bitcoin Layer2" โดยพากย์เสียงตัวเองเป็น "Rollups" แม้ว่าโซลูชันทางเทคนิคของพวกเขามักจะไม่เป็นไปตามมาตรฐาน Rollup ก็ตาม อย่างไรก็ตามคําว่า "Rollup" ได้รับการยอมรับอย่างมีนัยสําคัญทําให้เป็นประโยชน์สําหรับวัตถุประสงค์ในการส่งเสริมการขาย ผู้ดําเนินการโครงการหลายคนติดป้ายตัวเองว่าเป็น Rollups หรือแยกแนวคิด Rollup กระแสหลักด้วยคุณสมบัติที่คลุมเครือเช่น "Sovereign Rollup" การลอกเลเยอร์ของ "XX Rollups" เหล่านี้กลับมาหลายโครงการมีพื้นฐานมาจาก "การตรวจสอบฝั่งไคลเอ็นต์" หรือ "sidechains" เพียงใช้สโลแกน "XX Rollup" เพื่อความสะดวก แม้ว่ากลยุทธ์การส่งเสริมการขายนี้เป็นเรื่องปกติ แต่ก็มีแนวโน้มที่จะทําให้เข้าใจผิดก่อให้เกิดอันตรายมากกว่าผลดีต่อผู้ที่แสวงหาความจริง

(วิธีการนี้สรุปโดยรัฐมนตรีโฆษณาชวนเชื่อของนาซี Goebbels ว่าเป็น "การโฆษณาชวนเชื่อแบบโกหก" มักพบในหมู่ผู้ดําเนินโครงการ) แล้วเราจะแยกแยะพฤติกรรม "Rollup concept hitchhiking" ได้อย่างไร? บางทีการเริ่มต้นด้วยหลักการแรกการกําหนดหมวดหมู่โครงการ Layer2 ที่แตกต่างกันและระดับความปลอดภัยและฟังก์ชันการทํางานตามมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวางในตะวันตกและทั่วทั้งอุตสาหกรรมสามารถให้ความชัดเจนได้ ไม่จําเป็นต้องเกี่ยวกับโซลูชันที่เลือก หัวใจหลักอยู่ที่ว่าการออกแบบกลไกของโครงการช่วยให้มั่นใจได้ถึงความปลอดภัยและความน่าเชื่อถือของเครือข่าย Layer2 และเพิ่มขีดความสามารถให้กับ BTC mainnet อย่างแท้จริง

บทความนี้จะใช้ Chainway ซึ่งเป็นโครงการ Bitcoin Layer2 เป็นกรณีศึกษาเพื่อผ่าลักษณะ "การตรวจสอบฝั่งไคลเอ็นต์" ที่ซ่อนอยู่เบื้องหลังสโลแกน "Rollup" ของบางโครงการ เรามุ่งมั่นที่จะแยกความแตกต่างอย่างชัดเจนระหว่าง "Sovereign Rollup" และ "การตรวจสอบฝั่งไคลเอ็นต์" และความแตกต่างที่สําคัญจาก ZKRollups หรือ OPRollups มาตรฐานอุตสาหกรรมที่ใช้สัญญาอัจฉริยะ นี่ไม่ได้หมายความว่า Sovereign Rollups หรือการตรวจสอบฝั่งไคลเอ็นต์นั้นด้อยกว่า ZK Rollups ในด้านความปลอดภัยและความน่าเชื่อถือ ทุกอย่างขึ้นอยู่กับรายละเอียดการใช้งานเฉพาะของพวกเขา Chainway ซึ่งโดยทั่วไปคือการตรวจสอบฝั่งไคลเอ็นต์ Layer2 ได้เสนอรูปแบบธุรกรรมต่อต้านการเซ็นเซอร์ที่เรียกใช้บน BTC ด้วยการตรวจสอบนอกห่วงโซ่โดยใช้ ZK Proofs แบบเรียกซ้ําคล้ายกับที่ใช้โดยห่วงโซ่สาธารณะ MINA โดยวางตําแหน่งไว้ข้างหน้าโครงการ Bitcoin Layer2 จํานวนมาก เราเชื่อว่าการวิจัยเทคโนโลยีของ Chainway นั้นมีค่า โดยนําเสนอข้อมูลเชิงลึกที่สําคัญสําหรับผู้สังเกตการณ์ Bitcoin Layer2 (ภาพส่งเสริมการขายของ Chainway สร้างแบรนด์เป็น ZK Rollup แต่โซลูชันเก่าคือการตรวจสอบฝั่งไคลเอ็นต์ โดย ZKR เป็นอีกโครงการหนึ่งของพวกเขา ปัจจุบันยังไม่บรรลุฉันทามติของลูกค้านอกเครือข่ายหรือการแลกเปลี่ยนข้อความที่เชื่อถือได้)

ข้อความหลัก: Chainway เป็นโครงการ Bitcoin Layer2 ที่รู้จักกันดีในชุมชนตะวันตกซึ่งมักเรียกว่า "ZK Rollup" โดย KOL จํานวนมากในขณะที่เอกสารทางเทคนิคระบุว่าเป็น "Sovereign Rollup" เมื่อเร็ว ๆ นี้ Chainway ยังประกาศโครงการใหม่ Citea โดยอ้างว่าเป็น ZK Rollup ที่ใช้ BitVM อย่างไรก็ตามเนื่องจาก Citrea ยังไม่ได้ให้รายละเอียดเกี่ยวกับโซลูชันการตรวจสอบ ZK ตาม BitVM บทความนี้จะมุ่งเน้นไปที่การตีความทางเทคนิคของโซลูชันก่อนหน้าของ Chainway โดยสรุปโซลูชันทางเทคนิคที่เปิดเผยต่อสาธารณะของ Chainway เกี่ยวข้องกับการเผยแพร่ข้อมูล DA ผ่านโปรโตคอล Ordinals โดยใช้ BTC เป็นเลเยอร์ DA และเผยแพร่รายละเอียดการเปลี่ยนแปลงสถานะ (State diff) + ZK Proof เพื่อตรวจสอบความถูกต้องของการเปลี่ยนแปลงสถานะใน Layer1 ซึ่งเทียบเท่ากับการเผยแพร่ข้อมูลธุรกรรมที่สมบูรณ์และตรวจสอบได้ อย่างไรก็ตาม เนื่องจาก Layer1 ไม่ได้ตรวจสอบ ZK Proofs โดยตรง ด้วยการตรวจสอบที่ดําเนินการโดยลูกค้า/โหนดอิสระนอกเครือข่าย และฐานรหัสปัจจุบันของ Chainway ยังไม่บรรลุฉันทามติในหมู่ลูกค้านอกเครือข่าย และไม่ได้อ้างว่าแก้ปัญหานี้บนโซเชียลมีเดีย โซลูชันทางเทคนิคที่เปิดเผยต่อสาธารณะของ Chainway จึงอยู่ในหมวดหมู่ "การตรวจสอบฝั่งไคลเอ็นต์" แม้จะคล้ายกับโปรโตคอลที่จัดทําดัชนีด้วยการเข้ารหัสที่รองรับการเชื่อมโยงสินทรัพย์ ส่วนต่อไปนี้จะแนะนําการใช้งานทางเทคนิคเฉพาะของ Chainway และวิเคราะห์รูปแบบความปลอดภัย

Sovereign Rollup: การเผยแพร่เลเยอร์ข้อมูล (DA) + การยืนยันอยู่นอกเชือก

ในเอกสารทางเทคนิคของ Chainway จะใช้แนวคิดของ Sovereign Rollup จาก Celestia Sovereign Rollup นั้นแตกต่างจากแนวคิด Rollup กระแสหลักภายในชุมชน Ethereum และอุตสาหกรรมที่กว้างขึ้น (smart contract Rollup) ดังนั้นโครงสร้างของ Sovereign Rollup คืออะไรกันแน่?

โดยพื้นฐานแล้ว Sovereign Rollup ที่ใช้ Bitcoin นั้นค่อนข้างคล้ายกับ "กลุ่มลูกค้านอกเครือข่าย/sidechain ที่เผยแพร่ข้อมูล DA บน BTC blockchain" ลักษณะสําคัญคือไม่จําเป็นต้องมีสัญญาอัจฉริยะในเลเยอร์ 1 เพื่อตรวจสอบการเปลี่ยนสถานะ/การดําเนินการข้ามสายโซ่สําหรับเลเยอร์ 2 โดยพื้นฐานแล้วจะใช้ BTC เป็นเลเยอร์ DA และรูปแบบความปลอดภัยส่วนใหญ่คล้ายกับ "การตรวจสอบฝั่งไคลเอ็นต์" แน่นอนว่าโซลูชัน Sovereign Rollup ที่ปลอดภัยกว่านั้นอาศัยชั้นการชําระเงินของบุคคลที่สามนอกห่วงโซ่ Bitcoin (คล้ายกับ sidechain) เพื่อทําการตรวจสอบการเปลี่ยนสถานะ นอกจากนี้ในหมู่ลูกค้าอิสระที่แตกต่างกัน / โหนดเต็มรูปแบบมีระดับของฉันทามติหรือข้อความที่เชื่อถือได้ผ่านเพื่อบรรลุ "ข้อตกลง" เกี่ยวกับการกระทําที่ถกเถียงกันบางอย่าง อย่างไรก็ตาม บางโครงการ Sovereign Rollup มีพื้นฐานมาจาก "การตรวจสอบฝั่งไคลเอ็นต์" ล้วนๆ โดยขาดข้อความที่เชื่อถือได้ที่ส่งผ่านระหว่างไคลเอ็นต์/โหนดอิสระ

เพื่อให้เข้าใจแนวคิดที่เป็นเอกลักษณ์ของ "Sovereign Rollup" ได้ดีขึ้นการเปรียบเทียบกับ Rollup สัญญาอัจฉริยะจะเป็นประโยชน์ บน Ethereum โซลูชันเลเยอร์ 2 ส่วนใหญ่เป็น smart contract Rollups เช่น Arbitrum และ StarkNet โครงสร้างของสัญญาอัจฉริยะ Rollup สามารถมองเห็นได้ในแผนภาพต่อไปนี้:

(Imagine a diagram here)

ในแผนภาพเราจะเห็นคําศัพท์หลายคําที่เกี่ยวข้องกับการเล่าเรื่องบล็อกเชนแบบแยกส่วนซึ่งอธิบายได้ดังนี้:

• ชั้นการดําเนินการ: ดำเนินการธุรกรรมของผู้ใช้ อัปเดตสถานะบล็อกเชน และส่งข้อมูลไปยังเลเยอร์ DA และเลเยอร์การตั้งถิ่น

• ชั้นการตั้งบัญชี: ตรวจสอบการเปลี่ยนสถานะจากเลเยอร์การดำเนินการ แก้ข้อพิพาท (เช่น พิสูจน์การฉ้อโกง) และให้โมดูลสะพานสำหรับการจัดการสินทรัพย์การสะพานระหว่าง L1-L2

• ชั้นข้อมูลสามารถใช้งาน (DA): ทําหน้าที่เหมือนกระดานข่าวขนาดใหญ่รับข้อมูลการเปลี่ยนสถานะที่ส่งโดยชั้นการดําเนินการและให้ข้อมูลนี้ในลักษณะที่ไม่น่าเชื่อถือแก่ทุกคน

• ชั้น Consensus: รับรองความสมบูรณ์ของการจัดลำดับการทำธุรกรรม ฟังก์ชันของมันดูเหมือนจะใกล้เคียงกับชั้น DA (วิธีการของ Ethereum community ในการจัดลำดับชั้นบล็อกเชนแบบโมดูลไม่รวมชั้นเชื่อมั่น)
  
  จากการสถาปัตยกรรมของสมาร์ทคอนแทร็ก Rollups เราเห็นว่า Ethereum รับบทบาทของชั้นสุดท้ายสามชั้นนอกจากชั้นการปฏิบัติงาน แผนภูมิอีกแบบสามารถให้มุมมองรายละเอียดของบทบาทที่ Ethereum เล่นในสมาร์ทคอนแทร็ก Rollups
  
  ในทวีความเชื่อถือได้ต่างกันอย่างมีนัยสำคัญในที่ว่าพวกเขาทำให้การรับผิดชอบบางส่วนเลื่อนออกจากบล็อกเชนแบบโมโนลิทิกอย่างอีเทอเรียม โดยเฉพาะอย่างยิ่งพวกเขาไม่พึงพอใจในสัญญาอัจฉริยะบนเลเยอร์ฐาน (เลเยอร์ 1) สำหรับการตรวจสอบการเปลี่ยนสถานะหรือการจัดการข้อพิพาท แทนที่นั้น งานเหล่านี้จะถูกจัดการโดยไคลเอนต์ออฟไชน์หรือผ่านชั้นการตกลงของบุคคลที่สาม โดยเน้นการใช้วิธีการที่แตกต่างในการบรรลุประสิทธิภาพและความปลอดภัยในระบบบล็อกเชน

สัญญาโรลอัพบน Ethereum ได้รับหลักฐานความถูกต้องหรือหลักฐานการฉ้อโกงเพื่อตรวจสอบความถูกต้องของการเปลี่ยนสถานะเลเยอร์ 2 เป็นมูลค่าการกล่าวขวัญว่าสัญญาอัจฉริยะ Rollup ทําหน้าที่เป็นเอนทิตีเลเยอร์การชําระเงินในสถาปัตยกรรมบล็อกเชนแบบแยกส่วน สัญญาชั้นการชําระเงินมักจะรวมถึงโมดูลการเชื่อมโยงเพื่อจัดการสินทรัพย์ที่เชื่อมโยงจาก Ethereum ไปยังเลเยอร์ 2 สําหรับ Data Availability (DA) สัญญาเลเยอร์การชําระเงินสามารถกําหนดให้ Sequencer โพสต์ข้อมูลธุรกรรมล่าสุด/รายละเอียดการเปลี่ยนแปลงสถานะบนห่วงโซ่ได้ หากไม่มีการโพสต์ DA on-chain เป็นไปไม่ได้ที่จะอัปเดตสถานะ L2 ที่บันทึกไว้ในสัญญา Rollup ได้สําเร็จ

(ZK Rollup หรือ Optimistic Rollup สามารถบังคับข้อมูล DA ให้โพสต์บนเชนได้ หากไม่มี สถานะที่บันทึกในเลเยอร์การชำระเงินจะไม่สามารถอัพเดตได้) จากการวิเคราะห์โมเดลความปลอดภัยและตัวชี้วัดความเสี่ยงของ Bitcoin/Ethereum Layer 2 โซลูชันด้วยทฤษฎีถัง ชัดเจนว่า Rollups สมารถพึงพอใจกับสัญญาอัจฉริยะในเลเยอร์ 1 อย่างมาก สำหรับเลเยอร์ 1 อย่าง BTC ซึ่งมีความยากลำบากในการสนับสนุนตรรกะธุรกิจที่ซับซ้อน การสร้างเลเยอร์ 2 ที่สอดคล้องกับ Ethereum Rollups เป็นสิ่งที่เป็นไปไม่ได้ทั้งนี้ โซลูชัน Rollup ที่เป็นอิสระ อย่างไรก็ตาม ไม่จำเป็นต้องใช้สัญญาในเลเยอร์ 1 เพื่อการตรวจสอบสถานะ/การเชื่อมต่อ โครงสร้างของพวกเขาคือดังนี้: (ที่นี่ คำอธิบายของโครงสร้างหายไป แสดงถึงว่ามีการตั้งใจรวมภาพหรือรายละเอียดเพิ่มเติมไว้ในข้อความแต่ไม่ได้ระบุ)

ใน Sovereign Rollups, โหนดนอกเลเยอร์การให้ข้อมูล (DA) ทำหน้าที่เป็นหน่วยงานสำหรับการดำเนินการธุรกรรมและการชำระเงิน เสนอระดับความอิสระที่สูงขึ้น ขั้นตอนการทำงานคือดังนี้:

โหนดในเลเยอร์การดําเนินการของ sovereign Rollup ส่งข้อมูลธุรกรรม/รายละเอียดการเปลี่ยนแปลงสถานะไปยังเลเยอร์ DA ในขณะที่เลเยอร์การชําระเงิน/ไคลเอ็นต์พยายามรับและตรวจสอบข้อมูล สิ่งสําคัญคือต้องทราบว่าเนื่องจากโมดูลเลเยอร์การตั้งถิ่นฐานไม่ได้อยู่ในเลเยอร์ 1 ในทางทฤษฎีแล้ว Sovereign Rollups ไม่สามารถบรรลุสะพานที่มีความปลอดภัยเทียบเท่ากับเลเยอร์ 1 ได้ พวกเขามักจะพึ่งพาสะพานทนายความหรือโซลูชันการเชื่อมโยงของบุคคลที่สาม ปัจจุบันการดําเนินการตามแผนการยืนยันแบบ sovereign Rollup/client verification นั้นค่อนข้างง่ายโดยต้องการเพียงการเผยแพร่ข้อมูลบนห่วงโซ่ Bitcoin (BTC) โดยใช้โปรโตคอลที่คล้ายกับ Ordinals สําหรับการตรวจสอบนอกเครือข่ายและฉันทามติมีความยืดหยุ่นอย่างมาก ในความเป็นจริง sidechains จํานวนมากเพียงแค่เผยแพร่ข้อมูล DA ในห่วงโซ่ BTC โดยพื้นฐานแล้วจะกลายเป็น "Rollups อธิปไตยตาม BTC" แม้ว่าความปลอดภัยเฉพาะจะเป็นที่น่าสงสัย อย่างไรก็ตามปัญหาคือปริมาณข้อมูลของ Bitcoin ต่ํามากโดยสูงสุด 4MB ต่อบล็อกและเวลาบล็อกเฉลี่ย 10 นาทีแปลเป็นปริมาณข้อมูลเพียง 6KB / s โซลูชันเลเยอร์ 2 ที่อ้างว่าเป็น Sovereign Rollups อาจไม่สามารถเผยแพร่ข้อมูล DA ทั้งหมดบน BTC chain ได้ ดังนั้นพวกเขาจึงอาจเลือกใช้วิธีการอื่น เช่น การเผยแพร่ข้อมูล DA นอกเครือข่ายและจัดเก็บ datahash บน BTC chain เป็นรูปแบบหนึ่งของ "ความมุ่งมั่น" หรือหาวิธีบีบอัดข้อมูล DA สูง (เช่น ใช้ State diff + ZK Proof ตามที่ Chainway กล่าวอ้าง) เห็นได้ชัดว่าโหมดนี้ไม่สอดคล้องกับคําจํากัดความของ "sovereign Rollup" หรือ Rollup ที่เหมาะสมซึ่งแสดงถึงตัวแปรที่มีความปลอดภัยที่น่าสงสัย เราคาดการณ์ว่าโครงการเลเยอร์ 2 ส่วนใหญ่ที่มีแบนเนอร์ "Rollup" จะไม่เผยแพร่ข้อมูล DA ทั้งหมดบนห่วงโซ่ BTC ดังนั้นโซลูชันที่ใช้งานได้จริงของพวกเขาอาจไม่ตรงกับการอ้างสิทธิ์ "ZK Rollup" หรือ "OP Rollup" ที่ทําในเอกสารไวท์เปเปอร์ของพวกเขา

สุดท้าย ให้เราสรุปโดยสั้น ๆ ถึงความแตกต่างระหว่าง Sovereign Rollups และ Smart Contract Rollups ด้วย

1. ความสามารถในการอัพเกรด:การอัปเดตการวางท้ายของสมาร์ทคอนแทรค Rollups นั้นเกี่ยวข้องกับการอัปเดตสมาร์ทคอนแทรคที่ต้องการทีมพัฒนาใช้สมาร์ทคอนแทรคที่สามารถอัปเกรดได้ การอัปเกรดสมาร์ทคอนแทรคประเภทนี้มักจะถูกควบคุมโดยทีมพัฒนา Rollup ผ่าน multi-signature ในทวีคู่เปรียบเทียบนั้น กฎการอัปเกรดสำหรับ sovereign Rollups คล้ายกับการทำ soft และ hard fork ในบล็อกเชนทั่วไป โดยที่โหนดสามารถเลือกที่จะอัปเดตเวอร์ชันได้โดยอิสระ และไคลเอ็นต์ที่แตกต่างกันสามารถเลือกที่จะยอมรับการอัปเกรดหรือไม่ จากมุมมองนี้ sovereign Rollups มีความสามารถในการอัปเกรดที่ดีกว่า smart contract Rollups

2. สะพาน:ในเงื่อนไขที่เหมาะสม สะพานสำหรับ smart contract Rollups จะเป็นไปตามความน่าเชื่อถือที่ต่ำที่สุด แต่ความสามารถในการอัพเกรดของสัญญาสามารถมีผลต่อความปลอดภัยของพวกเขา ภายใต้โครงการ sovereign Rollup นักพัฒนาต้องสร้างส่วนประกอบสะพานภายใต้เชนเลเยอร์ 1 เอง และสะพานที่สร้างขึ้นมีความน่าเชื่อถือน้อยกว่าสะพาน smart contract

โครงสร้าง BTC DA

ในข้อความดังกล่าว พวกเราได้กล่าวถึงว่าเพื่อนำมาใช้ Rollup ที่เป็นของชาติ ที่มี BTC เป็นพื้นฐาน สำคัญอยู่ที่การใช้โปรโตคอล Ordinals เพื่อให้ BTC ใช้เป็นชั้นข้อมูลสำหรับการให้ข้อมูล (DA) Chainway ได้นำวิธีนี้มาใช้

เราสามารถตรวจสอบการส่งข้อมูล DA จากตัวจัดลำดับ Chainway โดยมี transaction hash คือ:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, แสดงได้ดังนี้:

สคริปต์ธุรกรรมนี้ยืมมาจากแนวทางของ Ordinals Protocol ในการใช้ OP_0 OP_IF สําหรับการเขียนข้อมูลเพื่อเขียนข้อมูล DA (ความพร้อมใช้งานของข้อมูล) ของ Rollup ลงในห่วงโซ่ BTC สิ่งนี้เกี่ยวข้องกับการเผยแพร่การเปลี่ยนแปลงสถานะและ ZK Proofs ซึ่งเทียบเท่ากับความปลอดภัยในการเผยแพร่ข้อมูลธุรกรรมดั้งเดิม แต่อนุญาตให้ลดขนาดข้อมูลได้อย่างมาก นอกเหนือจากข้อมูล DA แล้วซีเควนเซอร์ยังเขียนข้อมูลการตรวจสอบสิทธิ์บางอย่างลงในธุรกรรมโดยที่สําคัญที่สุดคือซีเควนเซอร์ Rollup ที่ลงนามในข้อมูล DA ด้วยคีย์ส่วนตัวเพื่อให้แน่ใจว่าการส่งมาจากซีเควนเซอร์ สิ่งสําคัญคือต้องทราบว่าธุรกรรมใด ๆ ที่เกี่ยวข้องกับการส่งข้อมูล DA มีศูนย์ไบนารี 16 ตัวที่ส่วนท้ายของแฮชธุรกรรม (เช่นไบต์สองไบต์ติดต่อกันเป็นศูนย์) ข้อ จํากัด นี้สามารถเห็นได้ในรหัส:

ในกราฟธุรกรรมตัวอย่างที่กล่าวถึงก่อนหน้านี้ตัวเลขสุ่ม "b715" ถูกใช้เพื่อปรับค่าแฮชของธุรกรรมเพื่อให้หางมีศูนย์ 16 ตัวที่เฉพาะเจาะจง หลักการนี้คล้ายกับการขุด Bitcoin ซึ่งมีการเพิ่มตัวเลขสุ่ม nonce เพื่อทําให้บิต N ชั้นนําของแฮชเป็นศูนย์ทั้งหมดซึ่งเป็นไปตามเงื่อนไขข้อ จํากัด เฉพาะ การออกแบบนี้มีจุดมุ่งหมายเพื่อลดความยุ่งยากในการรับข้อมูล DA (Data Availability) เมื่อโหนด Layer2 ใด ๆ ต้องการเข้าถึงข้อมูล DA จะต้องสแกนบล็อก BTC (Bitcoin) สําหรับธุรกรรมทั้งหมดที่ตั้งค่าให้ลงท้ายด้วยศูนย์ 16 ตัวซึ่งแยกแยะธุรกรรมที่เริ่มต้นโดยตัวเรียงลําดับ Chainway ได้อย่างมีประสิทธิภาพเมื่อส่งข้อมูลจากธุรกรรมอื่น ๆ บนบล็อกเชน Bitcoin ในข้อความต่อไปนี้ธุรกรรมดังกล่าวที่มีข้อมูล DA และตรงตามข้อกําหนดของการลงท้ายด้วยศูนย์ 16 ตัวจะเรียกว่า "ธุรกรรมมาตรฐาน Chainway" จุดเน้นของบทความนี้คือวิธีที่ Chainway บรรลุการต่อต้านการเซ็นเซอร์ เนื่องจากตัวเรียงลําดับ Layer2 อาจจงใจปฏิเสธคําขอธุรกรรมจากผู้ใช้รายใดรายหนึ่งจึงต้องใช้รูปแบบพิเศษเพื่อให้ผู้ใช้สามารถเริ่มต้นธุรกรรมที่ต่อต้านการเซ็นเซอร์ได้ เพื่อตอบสนองต่อปัญหานี้ Chainway อนุญาตให้ผู้ใช้เปิด "ธุรกรรมบังคับ" เมื่อผู้ใช้ส่งประกาศธุรกรรมนี้ภายในบล็อก BTC ตัวเรียงลําดับ Chainway จะต้องประมวลผลคําขอธุรกรรมนี้ใน Layer2 มิฉะนั้นจะไม่สามารถผลิตบล็อกได้ตามปกติหรือบล็อกที่ผลิตจะไม่ได้รับการยอมรับจากลูกค้านอกเครือข่าย โครงสร้างพารามิเตอร์ของธุรกรรมบังคับมีดังนี้:

ธุรกรรมนี้จะถูกส่งไปยังบล็อกเชน Bitcoin ในฐานะ "ธุรกรรมข้อมูลจําเพาะของ Chainway" โดยมีแฮชธุรกรรมลงท้ายด้วยศูนย์ 16 ตัว ตัวเรียงลําดับ ChainWay เมื่อสร้างบล็อก L2 จะต้องมี "ธุรกรรมข้อกําหนด Layer2" ที่เปิดเผยบนบล็อกเชน BTC แต่ยังไม่ได้บันทึกไว้ในบัญชีแยกประเภท L2 และรวมไว้ใน Merkle Tree โดยเขียนราก Merkle ลงในส่วนหัวของบล็อก L2 เมื่อผู้ใช้เริ่มต้นธุรกรรมที่มีพลังโดยตรงบนบล็อกเชน BTC ตัวเรียงลําดับจะต้องประมวลผล มิฉะนั้นจะไม่สามารถสร้างบล็อกที่ถูกต้องถัดไปได้ ไคลเอนต์ Chainway นอกห่วงโซ่ BTC สามารถตรวจสอบหลักฐาน ZK ก่อนเพื่อตรวจสอบความถูกต้องของบล็อก L2 ที่ส่งโดยตัวเรียงลําดับตรวจสอบราก Merkle ของส่วนหัวบล็อก L2 และตัดสินว่าตัวเรียงลําดับได้รวมคําขอธุรกรรมที่บังคับไว้จริงหรือไม่ เวิร์กโฟลว์สามารถอ้างถึงผังงานต่อไปนี้ได้ โปรดทราบว่าเนื่องจากข้อ จํากัด ของพื้นที่แผนภาพด้านล่างจึงไม่มีการตัดสินเงื่อนไขใน verify_relevant_tx_list:

โดยสรุป ไคลเอ็นต์/โหนด Chainway จะซิงค์กับบล็อกเมนเน็ต BTC และสแกนหา "ข้อมูล DA" ที่เผยแพร่โดยตัวเรียงลําดับ Chainway จากพวกเขา มันตรวจสอบว่าข้อมูลเหล่านี้ได้รับการเผยแพร่โดยตัวเรียงลําดับที่กําหนดและมี "ธุรกรรมมาตรฐาน Chainway" ทั้งหมดที่ส่งไปยังห่วงโซ่ BTC เห็นได้ชัดว่าตราบใดที่ผู้ใช้สามารถสร้างธุรกรรมที่ตรงตามเกณฑ์ที่ระบุเป็น "ธุรกรรมมาตรฐาน" และส่งไปยังห่วงโซ่ BTC ในที่สุดธุรกรรมนี้จะรวมอยู่ในบัญชีแยกประเภท L2 ท้องถิ่นของลูกค้า Chainway มิฉะนั้นบล็อก L2 ที่ออกโดยตัวเรียงลําดับ Chainway จะถูกปฏิเสธโดยไคลเอนต์ หากรวมกับฉันทามติ / การส่งข้อความแจ้งเตือนนอกเครือข่ายที่เชื่อถือได้รูปแบบการทําธุรกรรมต่อต้านการเซ็นเซอร์ของ Chainway จะเข้าใกล้วิธีการต่อต้านการเซ็นเซอร์ในอุดมคติของ Sovereign Rollups ตัวอย่างเช่นโซลูชัน Sovereign Rollup บางตัวได้ระบุไว้อย่างชัดเจนว่าในกรณีที่มีการบล็อกที่ไม่ถูกต้องข้อความเตือนการแจ้งเตือนจะถูกเผยแพร่ในหมู่ไคลเอนต์นอกเครือข่ายเพื่อเพิ่มความปลอดภัยโดยเฉพาะอย่างยิ่งการปล่อยให้ไคลเอนต์แสงที่ไม่สามารถซิงค์ข้อมูล DA ที่สมบูรณ์รู้เกี่ยวกับความผิดปกติของเครือข่าย หากบล็อกไม่ได้รวม "ธุรกรรมบังคับ" ไว้ตามความเป็นจริง จะทําให้เกิดการออกอากาศการแจ้งเตือนนอกเครือข่ายอย่างชัดเจน อย่างไรก็ตาม Chainway ยังไม่ได้ดําเนินการด้านนี้ (อย่างน้อยวัสดุที่เผยแพร่ในปัจจุบันและที่เก็บรหัสแสดงให้เห็นว่ายังไม่ได้ดําเนินการทางเทคนิคของส่วนนี้)

วัสดุอ้างอิง: นักวิจัย Celestia วิเคราะห์ตัวแปร Rollup 6 ประเภท: Sequencer=Aggregator+Header Generator แม้จะมีฉันทามติระหว่างลูกค้า/โหนดนอกเครือข่าย แต่ประสิทธิภาพการต่อต้านการเซ็นเซอร์ของ "ธุรกรรมบังคับ" ของ Chainway นั้นไม่แข็งแกร่งเท่ากับ Rollups สัญญาอัจฉริยะเช่น Arbitrum เนื่องจากในที่สุด Arbitrum One จะตรวจสอบให้แน่ใจว่า "ธุรกรรมที่ถูกบังคับ" รวมอยู่ในบัญชีแยกประเภท Layer2 ผ่านสัญญาบน Layer1 ซึ่งสืบทอดคุณสมบัติต่อต้านการเซ็นเซอร์ของ Layer1 อย่างสมบูรณ์ Sovereign Rollups ไม่สามารถจับคู่ Rollups สัญญาอัจฉริยะได้อย่างชัดเจนในด้านนี้ เนื่องจากประสิทธิภาพการต่อต้านการเซ็นเซอร์ในท้ายที่สุดขึ้นอยู่กับส่วนประกอบนอกเครือข่าย นอกจากนี้ยังกําหนดว่าแนวทางของแผน "Sovereign Rollups" และ "การตรวจสอบลูกค้า" โดยพื้นฐานแล้วไม่สามารถสืบทอดคุณสมบัติต่อต้านการเซ็นเซอร์ของ Layer1 ได้อย่างเต็มที่ เช่น Arbitrum One, Loopring, dydx และ Degate เนื่องจากธุรกรรมที่ถูกบังคับสามารถรวมอยู่ในบัญชีแยกประเภท Layer2 ได้อย่างราบรื่นหรือไม่นั้นขึ้นอยู่กับการตัดสินใจของเอนทิตีนอกเครือข่ายของ Layer2 ซึ่งไม่เกี่ยวข้องกับ Layer1 เอง เห็นได้ชัดว่าแนวทางของ Chainway ซึ่งอาศัยดุลยพินิจของลูกค้านอกเครือข่ายเพียงอย่างเดียวสืบทอดความน่าเชื่อถือของ DA ของ Layer1 เท่านั้นไม่ใช่คุณสมบัติต่อต้านการเซ็นเซอร์เต็มรูปแบบ คล้ายกับหลักฐาน ZK ซ้ําของ MINA

ในส่วนนี้เราจะขยายเสริมองค์ประกอบอื่น ๆ ของ Chainway ที่นอกจากการใช้ BTC เป็นชั้น DA ยังนำ ZK proofs แบบ recursive ที่คล้ายกับ MINA มาปฏิบัติด้วย โครงสร้างโดยรวมแสดงในแผนภาพต่อไปนี้:

ตัวเรียงลําดับในเครือข่าย Chainway หลังจากประมวลผลธุรกรรมของผู้ใช้จะสร้างหลักฐาน ZK (Zero-Knowledge) ขั้นสุดท้ายพร้อมกับรายละเอียดของการเปลี่ยนแปลงสถานะ (state diff) สําหรับบัญชีต่างๆ และเผยแพร่บนบล็อกเชน Bitcoin (BTC) โหนดแบบเต็มจะซิงค์ข้อมูลในอดีตทั้งหมดของ Chainway ที่เผยแพร่บนบล็อคเชน BTC หลักฐาน ZK แต่ละรายการไม่เพียง แต่ต้องพิสูจน์กระบวนการเปลี่ยนสถานะของบล็อกปัจจุบัน แต่ยังรับประกันความถูกต้องของหลักฐาน ZK ของบล็อกก่อนหน้า จากรูปแบบนี้เราจะเห็นว่าทุกครั้งที่มีการสร้างหลักฐานใหม่โดยพื้นฐานแล้วจะเป็นการยืนยันการพิสูจน์ก่อนหน้านี้ในลักษณะที่เกิดขึ้นซ้ํา ๆ และหลักฐาน ZK ล่าสุดสามารถรับประกันความถูกต้องของการพิสูจน์ ZK ทั้งหมดโดยเริ่มจากบล็อกแหล่งกําเนิด การออกแบบนี้คล้ายกับของ MINA เมื่อ "ไคลเอนต์แสง" ที่ซิงค์เฉพาะส่วนหัวของบล็อกหรือที่เรียกว่าโหนดแสงเข้าร่วมเครือข่ายจะต้องตรวจสอบความถูกต้องของ ZK Proof ล่าสุดที่เปิดเผยบนบล็อกเชน BTC เพื่อยืนยันว่าข้อมูลในอดีตของห่วงโซ่ทั้งหมดและการเปลี่ยนสถานะทั้งหมดถูกต้อง หากตัวเรียงลําดับกระทําการโดยมีเจตนาร้ายจงใจปฏิเสธที่จะยอมรับธุรกรรมบังคับหรือไม่ใช้หลักฐาน ZK ก่อนหน้านี้สําหรับการพิสูจน์ซ้ําไคลเอ็นต์จะไม่สามารถยอมรับหลักฐาน ZK ที่สร้างขึ้นใหม่ได้ (แม้ว่าจะสร้างขึ้น แต่ก็ไม่ได้รับการยอมรับ) ดังที่แสดงในแผนภาพด้านล่าง:

สรุป

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

วันนี้ โดยการศึกษาเฉพาะทางเกี่ยวกับโซลูชั่นทางเทคนิคของ Chainway เราพบว่าประเภทเทคโนโลยีที่โปรโมทโดยชุมชนของโครงการไม่ใช่ Rollup ในทางที่แพร่หลาย โดยที่พิจารณาถึงว่ามีโปรเจกต์ Bitcoin Layer2 ที่มีมากมายอยู่แล้ว (ซึ่งอาจจะเพิ่มมากขึ้นได้ในรอบครึ่งปี) เพื่อลดค่าใช้จ่ายทางการรับรู้ของคำศัพท์ทางเทคนิค เราจะดำเนินการศึกษาอย่างลึกซึ้งเกี่ยวกับการจำแนกประเภทของ Layer2 solutions และมาตรฐานสำหรับความปลอดภัย ความสมบูรณ์ของฟังก์ชัน และการประเมิน ติดตามดูนะคะ!

ข้อความปลดประจำ：

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