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

ผู้แต่งต้นฉบับ: Shi Khai Wei, Raghav Agarwal

การรวบรวมต้นฉบับ: Kxp, BlockBeats

การแนะนำ

มัลติเชนคือแนวโน้มการพัฒนาในอนาคต และการแสวงหาความสามารถในการปรับขนาดได้ทำให้ Ethereum พัฒนาเทคโนโลยี Rollup ในการย้ายไปยังบล็อกเชนแบบโมดูลาร์ ความสนใจได้จ่ายให้กับ Lisk อีกครั้ง และในอนาคตอันใกล้นี้ เราได้ยินข่าวลือเกี่ยวกับ Rollups, L3 และ Sovereign Chain เฉพาะแอปพลิเคชัน แต่ทั้งหมดนี้จะมาพร้อมกับค่าใช้จ่ายในการแยกส่วน และสะพานข้ามโซ่ในปัจจุบันมักมีข้อจำกัดในการทำงานและต้องพึ่งพาผู้ลงนามที่เชื่อถือได้เพื่อความปลอดภัย

ดังนั้น Web3 ที่เชื่อมต่อจะมีลักษณะอย่างไรในท้ายที่สุด เราเชื่อว่าสะพานข้ามสายโซ่จะพัฒนาไปสู่การส่งข้อความข้ามสายโซ่หรือโปรโตคอล "Arbitrary Messaging" (AMP) ในที่สุด เพื่อปลดล็อกสถานการณ์ใหม่ของแอปพลิเคชัน ทำให้แอปพลิเคชันสามารถส่งข้อความโดยพลการระหว่างห่วงโซ่ต้นทางและห่วงโซ่เป้าหมาย นอกจากนี้ เรายังจะได้เห็นการเกิดขึ้นของ "ภูมิทัศน์ของกลไกความน่าเชื่อถือ" ซึ่งผู้สร้างจะทำการแลกเปลี่ยนระหว่างความสามารถในการใช้งาน ความซับซ้อน และความปลอดภัย

โซลูชัน AMP ทุกตัวจำเป็นต้องใช้ฟังก์ชันหลักสองฟังก์ชัน:

• การยืนยัน: ความสามารถในการตรวจสอบความถูกต้องของข้อความจากเชนต้นทางบนเชนเป้าหมาย
• ความมีชีวิตชีวา: ความสามารถในการส่งผ่านข้อมูลจากห่วงโซ่ต้นทางไปยังห่วงโซ่เป้าหมาย

น่าเสียดายที่การตรวจสอบแบบไม่ไว้วางใจ 100% นั้นไม่สามารถทำได้จริง ผู้ใช้ต้องเลือกว่าจะเชื่อถือโค้ด ทฤษฎีเกม มนุษย์ (หรือเอนทิตี) หรือทั้งสองอย่างรวมกัน ขึ้นอยู่กับว่าการตรวจสอบเป็นแบบออนไลน์หรือออฟไลน์

ในเอกสารนี้ เราแบ่งโดเมนความสามารถในการทำงานร่วมกันโดยรวมออกเป็นกลไกที่อิงตามความไว้วางใจและสถาปัตยกรรมที่อิงตามการผสานรวมในแนวตั้ง

กลไกความน่าเชื่อถือ:

1. รหัสความน่าเชื่อถือและคณิตศาสตร์: สำหรับโซลูชันเหล่านี้ มีหลักฐานออนไลน์ที่ทุกคนสามารถตรวจสอบได้ โซลูชันเหล่านี้มักจะใช้ไคลเอ็นต์แบบไลท์ในการตรวจสอบฉันทามติของห่วงโซ่ต้นทางบนห่วงโซ่เป้าหมาย หรือตรวจสอบความถูกต้องของการเปลี่ยนสถานะของห่วงโซ่ต้นทางในห่วงโซ่เป้าหมาย การยืนยันผ่านไคลเอ็นต์แบบไลท์สามารถปรับปรุงประสิทธิภาพผ่านการพิสูจน์ที่ไม่มีความรู้ บีบอัดการคำนวณที่มีความยาวตามอำเภอใจสำหรับการดำเนินการออฟไลน์ และให้การตรวจสอบแบบออนไลน์อย่างง่ายเพื่อพิสูจน์ผลการคำนวณ

2. Trust Game Theory: เมื่อผู้ใช้/แอปพลิเคชันจำเป็นต้องเชื่อถือบุคคลที่สามหรือเครือข่ายของบุคคลที่สามเพื่อรับประกันความถูกต้องของธุรกรรม จะมีการสันนิษฐานเพิ่มเติมเกี่ยวกับความน่าเชื่อถือ ความปลอดภัยของกลไกเหล่านี้สามารถปรับปรุงได้โดยใช้เครือข่ายที่ไม่ได้รับอนุญาตและทฤษฎีเกม เช่น สิ่งจูงใจทางเศรษฐกิจและการรักษาความปลอดภัยในแง่ดี

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

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

สถาปัตยกรรมแบบบูรณาการ:

1. โมเดลแบบจุดต่อจุด: ต้องมีการสร้างช่องทางการสื่อสารเฉพาะระหว่างแต่ละห่วงโซ่ต้นทางและห่วงโซ่เป้าหมาย

2. โมเดลฮับกลาง: ช่องทางการสื่อสารกับฮับกลางจำเป็นต้องสร้างเพื่อให้เกิดการเชื่อมต่อกับบล็อกเชนอื่น ๆ ทั้งหมดที่เชื่อมต่อกับฮับ

โมเดลเพียร์ทูเพียร์นั้นค่อนข้างยากที่จะปรับขนาด เนื่องจากบล็อกเชนที่เชื่อมต่อกันแต่ละอันต้องการช่องทางการสื่อสารที่จับคู่กัน การพัฒนาช่องทางเหล่านี้อาจเป็นเรื่องที่ท้าทายสำหรับบล็อกเชนที่มีฉันทามติและกรอบการทำงานที่แตกต่างกัน อย่างไรก็ตาม บริดจ์แบบจับคู่มีความยืดหยุ่นมากกว่าในการปรับแต่งการกำหนดค่าหากต้องการ วิธีการแบบไฮบริดยังเป็นไปได้ เช่น การกำหนดเส้นทางแบบมัลติฮอปผ่านรีเลย์โดยใช้โปรโตคอล Inter-Blockchain Communication (IBC) ซึ่งขจัดความจำเป็นในการสื่อสารโดยตรงแบบเพียร์ทูเพียร์ แต่ทำให้เกิดความซับซ้อนมากขึ้นในแง่ของความปลอดภัย เวลาแฝง และ ค่าใช้จ่าย.

รหัสความน่าเชื่อถือและคณิตศาสตร์

เพื่อที่จะใช้รหัส/คณิตศาสตร์เท่านั้นในการสันนิษฐานที่เชื่อถือได้ ไคลเอนต์แบบไลท์สามารถใช้เพื่อตรวจสอบความเห็นพ้องของห่วงโซ่ต้นทางในห่วงโซ่เป้าหมายได้ ไคลเอ็นต์/โหนดแบบไลท์คือซอฟต์แวร์ที่เชื่อมต่อกับโหนดแบบเต็มเพื่อโต้ตอบกับบล็อกเชน โดยทั่วไปแล้วไคลเอ็นต์แบบไลท์ในห่วงโซ่เป้าหมายจะเก็บประวัติ (ตามลำดับ) ของส่วนหัวของบล็อกต้นทาง ซึ่งเพียงพอสำหรับการตรวจสอบธุรกรรม พร็อกซีนอกเชน (เช่น รีเลย์) ตรวจสอบเหตุการณ์บนเชนต้นทาง สร้างหลักฐานการรวมการเข้ารหัส และส่งต่อพร้อมกับส่วนหัวของบล็อกไปยังไคลเอ็นต์แบบไลท์บนเชนเป้าหมาย เนื่องจากไคลเอ็นต์แบบไลท์จัดเก็บส่วนหัวของบล็อกตามลำดับ โดยแต่ละส่วนมีแฮชรากของ Merkle ที่สามารถใช้เพื่อพิสูจน์สถานะได้ พวกเขาจึงสามารถตรวจสอบธุรกรรมได้ นี่คือภาพรวมของคุณสมบัติหลักของแนวทางนี้:

ความปลอดภัย

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

ดำเนินการ

การนำไลต์ไคลเอนต์ไปใช้นั้นขึ้นอยู่กับความพร้อมใช้งานของการเข้ารหัสดั้งเดิมที่จำเป็นสำหรับการรับรองความถูกต้อง หากเชนประเภทเดียวกันเชื่อมต่อกัน หมายความว่าพวกมันใช้กรอบงานแอปพลิเคชันเดียวกันและอัลกอริทึมที่สอดคล้องกัน การใช้งานไคลเอ็นต์แบบเบาที่ปลายทั้งสองจะเหมือนกัน ตัวอย่างเช่น ห่วงโซ่ที่ใช้ Cosmos SDK ทั้งหมดใช้โปรโตคอล Inter-Blockchain Communication (IBC) ในทางกลับกัน การนำไปใช้งาน เช่น ไคลเอ็นต์แบบไลท์นั้นขึ้นอยู่กับการสนับสนุนสำหรับการเข้ารหัสดั้งเดิมที่จำเป็นสำหรับการตรวจสอบสิทธิ์ หากเชนประเภทเดียวกันเชื่อมต่อกัน เช่น พวกเขาแชร์เฟรมเวิร์กแอปพลิเคชันและอัลกอริทึมที่สอดคล้องกัน ดังนั้นการใช้งานไคลเอ็นต์แบบเบาทั้งสองฝั่งจะเหมือนกัน ตัวอย่างเช่น โปรโตคอล Inter-Blockchain Communication (IBC) ใช้สำหรับเชนที่ใช้ Cosmos SDK ทั้งหมด ในทางกลับกัน หากเชื่อมต่อเชนสองประเภทที่แตกต่างกัน เช่น เฟรมเวิร์กแอปพลิเคชันหรือประเภทฉันทามติที่แตกต่างกัน การใช้งานไคลเอ็นต์แบบเบาจะแตกต่างกัน ตัวอย่างเช่น Composable Finance ซึ่งกำลังดำเนินการเชื่อมต่อห่วงโซ่ Cosmos SDK กับเฟรมเวิร์กแอปพลิเคชัน Substrate ของระบบนิเวศ Polkadot ผ่านทาง IBC สิ่งนี้ต้องการไคลเอ็นต์แบบเบา Tendermint บน Substrate chain และไคลเอนต์แบบเบา "อ้วน" บนสาย Cosmos SDK เมื่อเร็ว ๆ นี้ พวกเขาสร้างการเชื่อมต่อครั้งแรกระหว่าง Polkadot และ Kusama ผ่านทาง IBC

ท้าทาย

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

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

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

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

การพิสูจน์ด้วยความรู้เป็นศูนย์เป็นวิธีแก้ปัญหาสำหรับความไว้วางใจจากบุคคลที่สาม

สามารถใช้การพิสูจน์ความรู้เป็นศูนย์เพื่อตรวจสอบความถูกต้องของการเปลี่ยนสถานะของห่วงโซ่ต้นทางบนห่วงโซ่เป้าหมาย เมื่อเปรียบเทียบกับการดำเนินการคำนวณบนเชนทั้งหมด การพิสูจน์ ZK จะดำเนินการเฉพาะส่วนการตรวจสอบของการคำนวณบนเชน ในขณะที่การคำนวณจริงเกิดขึ้นนอกเชน วิธีการนี้ช่วยให้สามารถตรวจสอบได้รวดเร็วและมีประสิทธิภาพมากกว่าการเรียกใช้การคำนวณเดิมซ้ำ ตัวอย่างเช่น Polymer Labs'; Polymer ZK-IBC; และ Succinct Labs'; Telepathy โพลิเมอร์กำลังพัฒนา IBCs แบบมัลติฮอปเพื่อเพิ่มการเชื่อมต่อและลดจำนวนการเชื่อมต่อแบบจับคู่ที่ต้องใช้

ลักษณะสำคัญของกลไกประกอบด้วย:

ความปลอดภัย

ความปลอดภัยของ zk-SNARK อาศัยเส้นโค้งวงรี ในขณะที่ zk-STARK อาศัยฟังก์ชันแฮช zk-SNARK อาจต้องการการตั้งค่าที่เชื่อถือได้ รวมถึงการสร้างคีย์เริ่มต้นที่ใช้เพื่อสร้างหลักฐานที่ใช้ในการยืนยัน กุญแจสำคัญคือการทำลายความลับของเหตุการณ์การตั้งค่าเพื่อป้องกันไม่ให้ธุรกรรมถูกตรวจสอบโดยการปลอมแปลง เมื่อการตั้งค่าที่เชื่อถือได้เสร็จสมบูรณ์ จะไม่มีการแนะนำสมมติฐานความน่าเชื่อถือเพิ่มเติม นอกจากนี้ เฟรมเวิร์ก ZK ที่ใหม่กว่า (เช่น Halo และ Halo;2;) ขจัดความจำเป็นในการตั้งค่าที่เชื่อถือได้โดยสิ้นเชิง

ดำเนินการ

มีแผนการพิสูจน์ ZK ที่หลากหลาย เช่น SNARK, STARK, VPD และ SNARG และปัจจุบัน SNARK ถูกใช้อย่างแพร่หลายที่สุด เฟรมเวิร์กการพิสูจน์ SNARK ที่แตกต่างกัน เช่น Groth;16, Plonk, Marlin, Halo และ Halo;2; เสนอการแลกเปลี่ยนในแง่ของขนาดการพิสูจน์ เวลาพิสูจน์ เวลาในการตรวจสอบ ความต้องการหน่วยความจำ และข้อกำหนดการตั้งค่าที่เชื่อถือได้ นอกจากนี้ยังมีการพิสูจน์ ZK แบบเรียกซ้ำ ทำให้สามารถกระจายปริมาณงานการพิสูจน์ไปยังคอมพิวเตอร์หลายเครื่องแทนที่จะเป็นเครื่องเดียว เพื่อสร้างการพิสูจน์ความถูกต้อง จะต้องดำเนินการหลักเบื้องต้นต่อไปนี้: การตรวจสอบรูปแบบลายเซ็นที่ใช้โดยตัวตรวจสอบความถูกต้อง การจัดเก็บหลักฐานของรหัสสาธารณะของตัวตรวจสอบความถูกต้องในข้อผูกพันชุดตัวตรวจสอบความถูกต้องที่จัดเก็บบนสายโซ่ และการติดตามชุดตัวตรวจสอบความถูกต้อง ซึ่งอาจ เปลี่ยนแปลงบ่อย

ท้าทาย

การใช้รูปแบบลายเซ็นต่างๆ ใน zkSNARK จำเป็นต้องดำเนินการทางคณิตศาสตร์นอกโดเมนและการดำเนินการเส้นโค้งวงรีที่ซับซ้อน ซึ่งไม่ใช่เรื่องเล็กน้อยและอาจต้องการการใช้งานที่แตกต่างกันขึ้นอยู่กับกรอบงานและความเห็นพ้องของเชนที่แตกต่างกัน การตรวจสอบวงจร ZK เป็นงานที่ท้าทายและเกิดข้อผิดพลาดได้ง่าย นักพัฒนาจำเป็นต้องคุ้นเคยกับภาษาเฉพาะโดเมน เช่น Circom, Cairo และ Noir หรือใช้วงจรโดยตรง ซึ่งทั้งสองอย่างนี้อาจเป็นเรื่องที่ท้าทายและทำให้การยอมรับช้าลง หากเวลาและความพยายามพิสูจน์ได้ว่าสูงมาก อาจมีการจัดการโดยทีมงานเฉพาะและฮาร์ดแวร์เฉพาะเท่านั้น ซึ่งอาจนำไปสู่การรวมศูนย์ เวลาในการสร้างการพิสูจน์ที่นานขึ้นก็ทำให้เกิดความล่าช้าเช่นกัน เทคนิคต่างๆ เช่น Incrementally Verifiable Computation (IVC) สามารถเพิ่มประสิทธิภาพเวลาการพิสูจน์ได้ แต่ส่วนใหญ่ยังอยู่ในขั้นตอนการวิจัยเพื่อรอการนำไปใช้ เวลาในการตรวจสอบและปริมาณงานที่นานขึ้นจะเพิ่มต้นทุนในเครือข่าย

เชื่อถือทฤษฎีเกม

โปรโตคอลการทำงานร่วมกันตามทฤษฎีเกมสามารถแบ่งกว้างๆ ออกเป็นสองประเภท ตามวิธีที่พวกเขาสร้างแรงจูงใจให้พฤติกรรมที่ซื่อสัตย์โดยหน่วยงานที่เข้าร่วม:

ประเภทแรกคือกลไกการรักษาความปลอดภัยทางเศรษฐกิจที่ผู้ดำเนินการภายนอกหลายคน (เช่น ผู้ตรวจสอบความถูกต้อง) ร่วมมือกันเพื่อให้ได้ฉันทามติเพื่อกำหนดสถานะที่อัปเดตของห่วงโซ่ต้นทาง ในการเป็นผู้ตรวจสอบความถูกต้อง ผู้เข้าร่วมจำเป็นต้องเดิมพันโทเค็นจำนวนหนึ่ง ซึ่งอาจลดลงได้ในกรณีที่มีกิจกรรมที่เป็นอันตราย ในการตั้งค่าที่ไม่มีการอนุญาต ทุกคนสามารถสะสมเงินเดิมพันและเป็นผู้ตรวจสอบได้ นอกจากนี้ ยังมีสิ่งจูงใจทางเศรษฐกิจ เช่น รางวัลบล็อกให้กับผู้ตรวจสอบความถูกต้องที่ปฏิบัติตามโปรโตคอลเพื่อให้แน่ใจว่ามีแรงจูงใจทางเศรษฐกิจสำหรับพฤติกรรมที่ซื่อสัตย์ อย่างไรก็ตาม หากจำนวนเงินที่อาจถูกขโมยเกินจำนวนเงินเดิมพัน ผู้เข้าร่วมอาจสมรู้ร่วมคิดเพื่อขโมยเงิน ตัวอย่างของโปรโตคอลที่ใช้กลไกการรักษาความปลอดภัยแบบประหยัด ได้แก่ Axelar และ Celer IM

ประเภทที่สองคือกลไกการรักษาความปลอดภัยในแง่ดี ซึ่งโซลูชันอาศัยสมมติฐานที่ว่าผู้เข้าร่วมบล็อกเชนจำนวนน้อยเท่านั้นที่ซื่อสัตย์และปฏิบัติตามกฎของโปรโตคอล ในแนวทางนี้ ผู้เข้าร่วมที่ซื่อสัตย์ทำหน้าที่เป็นหลักประกัน ตัวอย่างเช่น โซลูชันที่ดีที่สุดช่วยให้ทุกคนสามารถส่งหลักฐานการฉ้อโกงได้ แม้ว่าจะมีแรงจูงใจทางการเงิน แต่ผู้สังเกตการณ์ที่ซื่อสัตย์อาจพลาดธุรกรรมที่เป็นการฉ้อโกง Optimistic Rollups ก็ใช้กลไกนี้เช่นกัน Nomad และ ChainLink CCIP เป็นตัวอย่างของโปรโตคอลที่ใช้กลไกความปลอดภัยในแง่ดี ในกรณีของ Nomad ผู้สังเกตการณ์สามารถพิสูจน์การฉ้อโกงได้ แม้ว่าพวกเขาจะถูกอนุญาตพิเศษในขณะที่เขียน ChainLink CCIP วางแผนที่จะใช้เครือข่ายป้องกันการฉ้อโกงซึ่งประกอบด้วยเครือข่ายแบบกระจายของออราเคิลเพื่อตรวจจับกิจกรรมที่เป็นอันตราย แม้ว่าจะไม่ทราบการใช้งานเครือข่ายต่อต้านการฉ้อโกงของ CCIP

ความปลอดภัย

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

ดำเนินการ

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

อีกวิธีหนึ่งในการดำเนินการเกี่ยวข้องกับการใช้พร็อกซีแบบออฟไลน์ พร็อกซีแบบออฟไลน์ถูกใช้เพื่อใช้งานโซลูชันที่มีลักษณะคล้าย Rollups ในแง่ดี ภายในกรอบเวลาที่กำหนดไว้ล่วงหน้า พร็อกซีออฟไลน์เหล่านี้สามารถส่งหลักฐานการฉ้อโกงและย้อนกลับธุรกรรมได้หากจำเป็น ตัวอย่างเช่น Nomad อาศัยพร็อกซีออฟไลน์อิสระในการถ่ายทอดส่วนหัวและการพิสูจน์การเข้ารหัส ในทางกลับกัน ChainLink CCIP วางแผนที่จะใช้ประโยชน์จากเครือข่ายออราเคิลที่มีอยู่เพื่อตรวจสอบและรับรองการทำธุรกรรมข้ามสายโซ่

จุดแข็งและความท้าทาย

ข้อได้เปรียบที่สำคัญของโซลูชัน AMP ตามทฤษฎีเกมคือการเพิ่มประสิทธิภาพทรัพยากร เนื่องจากโดยทั่วไปแล้วกระบวนการตรวจสอบจะเป็นแบบออฟไลน์ ซึ่งช่วยลดความต้องการทรัพยากร นอกจากนี้ กลไกเหล่านี้ยังสามารถปรับขนาดได้เนื่องจากกลไกที่เป็นเอกฉันท์ยังคงเหมือนเดิมสำหรับเชนประเภทต่างๆ และสามารถขยายไปสู่บล็อกเชนที่แตกต่างกันได้อย่างง่ายดาย

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

เชื่อมนุษย์

โซลูชันที่ต้องการความไว้วางใจในหน่วยงานของมนุษย์สามารถแบ่งกว้างๆ ออกเป็นสองประเภท:

1. ความปลอดภัยด้านชื่อเสียง: โซลูชันเหล่านี้อาศัยการใช้งานแบบหลายลายเซ็น ซึ่งหลายหน่วยงานตรวจสอบและลงนามธุรกรรม เมื่อถึงเกณฑ์ขั้นต่ำ ถือว่าธุรกรรมนั้นถูกต้อง สมมติฐานในที่นี้คือหน่วยงานส่วนใหญ่มีความซื่อสัตย์ และหากหน่วยงานเหล่านี้ส่วนใหญ่ลงนามในธุรกรรมใดธุรกรรมหนึ่ง แสดงว่าธุรกรรมนั้นถูกต้อง สิ่งเดียวที่เสี่ยงในที่นี้คือชื่อเสียงของหน่วยงานที่เกี่ยวข้อง ตัวอย่างบางส่วน ได้แก่ Multichain (Anycall V;6;) และ Wormhole ช่องโหว่ยังคงมีอยู่เนื่องจากช่องโหว่ของสัญญาอัจฉริยะดังที่แสดงให้เห็นโดยการแฮ็ก Wormhole ในต้นปี 2565

2. ความเป็นอิสระ: โซลูชันเหล่านี้แบ่งกระบวนการส่งข้อความทั้งหมดออกเป็นสองส่วนและพึ่งพาหน่วยงานอิสระที่แตกต่างกันเพื่อจัดการทั้งสองกระบวนการ สมมติฐานที่นี่คือหน่วยงานทั้งสองนี้เป็นอิสระจากกันและไม่สามารถสมรู้ร่วมคิด LayerZero เป็นตัวอย่าง ส่วนหัวของบล็อกจะถูกส่งตามความต้องการผ่านออราเคิลแบบกระจาย และหลักฐานการทำธุรกรรมจะถูกส่งผ่านรีเลย์ หากหลักฐานตรงกับส่วนหัว ถือว่าธุรกรรมนั้นถูกต้อง ในขณะที่การพิสูจน์การจับคู่อาศัยรหัส/คณิตศาสตร์ ผู้เข้าร่วมต้องเชื่อมั่นว่าเอนทิตีเหล่านี้ยังคงเป็นอิสระและไม่มีเจตนาร้าย แอปพลิเคชันที่สร้างขึ้นบน ;LayerZero; สามารถเลือกออราเคิลและรีเลย์ของตน (หรือโฮสต์ออราเคิล/รีเลย์ของตนเอง) จึงช่วยจำกัดความเสี่ยงให้กับออราเคิล/รีเลย์แต่ละตัว ผู้ใช้ปลายทางต้องเชื่อมั่นว่า LayerZero บุคคลที่สาม หรือแอปพลิเคชันเองกำลังเรียกใช้ออราเคิลและรีเลย์อย่างอิสระ โดยไม่มีเจตนาร้าย

ในทั้งสองวิธี ชื่อเสียงของหน่วยงานบุคคลที่สามที่เข้าร่วมจะขัดขวางพฤติกรรมที่เป็นอันตราย สิ่งเหล่านี้มักเป็นหน่วยงานที่ได้รับความเคารพอย่างดีใน Validator และชุมชน Oracle และหากพวกเขาประพฤติตนที่มุ่งร้าย พวกเขาเสี่ยงต่อความเสียหายด้านชื่อเสียงและผลกระทบเชิงลบต่อกิจกรรมทางธุรกิจอื่นๆ

ข้อควรพิจารณาเพิ่มเติมสำหรับโซลูชัน AMP

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

ความสมบูรณ์ของรหัส

การแฮ็กล่าสุดใช้ประโยชน์จากข้อผิดพลาดของโค้ด โดยเน้นย้ำถึงความจำเป็นในการตรวจสอบที่มีประสิทธิภาพ การให้รางวัลข้อบกพร่อง และการใช้งานไคลเอนต์ที่หลากหลาย หากผู้ตรวจสอบทั้งหมด (ในแง่เศรษฐกิจ/แง่ดี/ความปลอดภัยด้านชื่อเสียง) เรียกใช้ไคลเอ็นต์เดียวกัน (ซอฟต์แวร์สำหรับการตรวจสอบ) ก็จะเพิ่มการพึ่งพาโค้ดเบสเดียวและลดความหลากหลายของไคลเอ็นต์ ตัวอย่างเช่น Ethereum อาศัยไคลเอ็นต์การดำเนินการหลายอย่าง เช่น geth, netermind, erigon, besu, akula การใช้งานหลายภาษาในหลายๆ ภาษาอาจเพิ่มความหลากหลาย โดยไม่มีไคลเอ็นต์รายใดมีอำนาจเหนือเครือข่าย ขจัดจุดล้มเหลวที่อาจเกิดขึ้นเพียงจุดเดียว การมีไคลเอนต์หลายตัวยังช่วยรักษาความพร้อมใช้งานในกรณีที่มีตัวตรวจสอบความถูกต้อง/ผู้ลงนาม/ไคลเอนต์ไลท์จำนวนน้อยที่ล้มเหลวเนื่องจากข้อผิดพลาด/การโจมตีในการใช้งานเฉพาะ

การตั้งค่าและการอัพเกรด

ผู้ใช้และนักพัฒนาจำเป็นต้องทราบว่าผู้ตรวจสอบความถูกต้อง/ผู้สังเกตการณ์สามารถเข้าร่วมเครือข่ายในลักษณะที่ไม่ได้รับอนุญาตได้หรือไม่ มิฉะนั้น ความไว้วางใจจะถูกซ่อนโดยหน่วยงานที่เลือกการอนุญาต การอัปเกรดเป็นสัญญาอัจฉริยะอาจทำให้เกิดช่องโหว่ที่อาจนำไปสู่การโจมตีและอาจเปลี่ยนสมมติฐานความน่าเชื่อถือได้ โซลูชันต่างๆ สามารถนำมาใช้เพื่อลดความเสี่ยงเหล่านี้ได้ ตัวอย่างเช่น ในการสร้างอินสแตนซ์ปัจจุบัน สามารถอัปเกรดเกตเวย์ Axelar ได้ แต่ต้องได้รับการอนุมัติจากคณะกรรมการออฟไลน์ (4/8 threshold) อย่างไรก็ตาม ในอนาคตอันใกล้นี้ Axelar วางแผนที่จะกำหนดให้ผู้ตรวจสอบความถูกต้องทั้งหมดร่วมกันอนุมัติการอัปเกรดใดๆ ไปยังเกตเวย์ สัญญาหลักของ Wormhole สามารถอัปเกรดและจัดการได้ผ่านระบบการกำกับดูแลบนเครือข่ายของ Wormhole LayerZero อาศัยสัญญาอัจฉริยะที่ไม่เปลี่ยนรูปและไลบรารีที่ไม่เปลี่ยนรูปเพื่อหลีกเลี่ยงการอัปเกรดใดๆ แต่สามารถพุชไลบรารีใหม่ได้ dapps ที่ตั้งค่าเริ่มต้นจะได้รับเวอร์ชันที่ใหม่กว่า dapps ที่ตั้งค่าเวอร์ชันด้วยตนเองจำเป็นต้องตั้งค่าเป็นเวอร์ชันใหม่

ค่าที่แยกได้สูงสุด (MEV)

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

ความแน่นอนของห่วงโซ่แหล่งที่มา

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

แนวโน้มและแนวโน้มในอนาคต การรักษาความปลอดภัยที่ปรับแต่งได้และแนบได้

เพื่อตอบสนองกรณีการใช้งานที่หลากหลายได้ดีขึ้น โซลูชัน AMP ได้รับแรงจูงใจเพื่อให้นักพัฒนาซอฟต์แวร์มีความยืดหยุ่นมากขึ้น Axelar แนะนำวิธีการเปิดใช้งานความสามารถในการปรับขนาดของการส่งข้อความและการตรวจสอบโดยไม่ต้องเปลี่ยนลอจิกเลเยอร์ของแอปพลิเคชัน HyperLane V2 นำเสนอโมดูลที่ช่วยให้นักพัฒนาสามารถเลือกได้จากหลายตัวเลือก เช่น การรักษาความปลอดภัยแบบประหยัด การรักษาความปลอดภัยในแง่ดี การรักษาความปลอดภัยแบบไดนามิก และการรักษาความปลอดภัยแบบไฮบริด CelerIM ให้การรักษาความปลอดภัยในแง่ดีเพิ่มเติมนอกเหนือไปจากความปลอดภัยทางเศรษฐกิจ โซลูชันจำนวนมากรอการยืนยันจำนวนบล็อกขั้นต่ำที่กำหนดไว้ล่วงหน้าในซอร์สเชนก่อนที่จะส่งข้อความ LayerZero ช่วยให้นักพัฒนาอัปเดตพารามิเตอร์เหล่านี้ได้ เราคาดว่าโซลูชัน AMP บางอย่างจะยังคงมีความยืดหยุ่นมากขึ้น แต่ตัวเลือกการออกแบบเหล่านี้ต้องมีการหารือกัน แอปพลิเคชันควรสามารถกำหนดค่าความปลอดภัยได้ในระดับใด และจะเกิดอะไรขึ้นหากแอปพลิเคชันได้รับการออกแบบด้วยสถาปัตยกรรมที่ไม่เหมาะสม การรับรู้ของผู้ใช้เกี่ยวกับแนวคิดพื้นฐานเบื้องหลังความปลอดภัยมีแนวโน้มที่จะมีความสำคัญมากขึ้นเรื่อยๆ ในท้ายที่สุด เราคาดการณ์การรวมและการสรุปของโซลูชัน AMP ซึ่งอาจอยู่ในรูปแบบขององค์ประกอบหรือการรักษาความปลอดภัย "ส่วนเสริม" บางรูปแบบ

ความสมบูรณ์ของกลไก "รหัสความน่าเชื่อถือและคณิตศาสตร์"

ในขั้นตอนสุดท้ายที่เหมาะสม ข้อความข้ามเชนทั้งหมดจะถูกลดความน่าเชื่อถือลงด้วยการใช้การพิสูจน์แบบไม่มีความรู้ (ZK) เราได้เห็นโครงการที่คล้ายกันเช่น Polymer Labs และ Succict Labs เกิดขึ้น Multichain ยังได้ตีพิมพ์เอกสารทางเทคนิค zkRouter เกี่ยวกับการทำงานร่วมกันผ่านการพิสูจน์ ZK ด้วย Axelar Virtual Machine ที่เพิ่งประกาศเมื่อเร็ว ๆ นี้ นักพัฒนาสามารถใช้ประโยชน์จาก Interchain Amplifier เพื่อสร้างการเชื่อมต่อใหม่ไปยังเครือข่าย Axelar โดยไม่ต้องขออนุญาต ตัวอย่างเช่น เมื่อไคลเอนต์ไฟแรงและหลักฐาน ZK ได้รับการพัฒนาสำหรับสถานะของ Ethereum นักพัฒนาสามารถรวมเข้ากับเครือข่าย Axelar ได้อย่างง่ายดายเพื่อแทนที่หรือปรับปรุงการเชื่อมต่อที่มีอยู่ Celer Network ประกาศเปิดตัว Brevis ซึ่งเป็นแพลตฟอร์มพิสูจน์ข้อมูลข้ามเชน ZK ที่ช่วยให้ dApps และสัญญาอัจฉริยะเข้าถึง คำนวณ และใช้ข้อมูลตามอำเภอใจบนบล็อกเชนหลายตัว Celer ใช้ zkBridge สินทรัพย์ที่เน้นผู้ใช้เป็นหลัก โดยใช้วงจร ZK light client สำหรับการข้ามเชนระหว่างเครือข่ายทดสอบ Ethereum Goerli และเครือข่ายทดสอบ BNB Chain LayerZero กล่าวถึงความเป็นไปได้ในการเพิ่มไลบรารีข้อความพิสูจน์ที่ปรับให้เหมาะสมใหม่ในอนาคตในเอกสารประกอบ โครงการที่ใหม่กว่าเช่น Lagrange กำลังสำรวจการรวมหลักฐานหลายรายการจากห่วงโซ่แหล่งที่มาหลายแห่ง ในขณะที่ Herodotus ทำให้การจัดเก็บหลักฐานเป็นไปได้ด้วยการพิสูจน์ ZK อย่างไรก็ตาม การเปลี่ยนแปลงนี้จะต้องใช้เวลา เนื่องจากแนวทางนี้ยากที่จะปรับขนาดทั่วทั้งบล็อกเชนที่อาศัยกลไกและกรอบการทำงานที่เป็นเอกฉันท์ที่แตกต่างกัน

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

1. ผ่านการตรวจสอบและค่าบั๊ก ความเป็นไปได้ในการใช้ประโยชน์จากโค้ดจะลดลง เมื่อเวลาผ่านไป การเชื่อถือระบบเหล่านี้จะกลายเป็นเรื่องง่ายขึ้น เนื่องจากประวัติของพวกเขากลายเป็นเครื่องพิสูจน์ความปลอดภัย

2. ค่าใช้จ่ายในการสร้างปรู๊ฟ ZK จะลดลง ด้วยการวิจัยและพัฒนาเพิ่มเติมเกี่ยวกับ ZKP, ZKP แบบเรียกซ้ำ, การรวมหลักฐาน, รูปแบบพับ และฮาร์ดแวร์พิเศษ เราคาดว่าต้นทุนเวลาในการสร้างการพิสูจน์และการตรวจสอบจะลดลงอย่างมาก ทำให้เป็นแนวทางที่คุ้มค่ามากขึ้น

3. บล็อกเชนจะสนับสนุน ZK มากขึ้น ในอนาคต zkEVM จะสามารถแสดงหลักฐานที่ชัดเจนเกี่ยวกับความถูกต้องของการดำเนินการ และโซลูชันที่อิงกับไคลเอนต์แบบ light จะสามารถตรวจสอบการดำเนินการของซอร์สเชนและความสอดคล้องกันได้อย่างง่ายดาย ในขั้นตอนสุดท้ายของ Ethereum มีการวางแผนที่จะ "zk-SNARK ทุกอย่าง" รวมถึงกลไกที่เป็นเอกฉันท์

ข้อมูลรับรองบุคคล ชื่อเสียง และอัตลักษณ์

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

สรุปแล้ว

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

ลิงค์ต้นฉบับ