การนำทางเว็บของการทำงานร่วมกัน: เจาะลึกเกี่ยวกับโปรโตคอลการส่งผ่านข้อความโดยพลการ

แนะนำสกุลเงิน

อนาคตคือมัลติเชน การแสวงหาความสามารถในการขยายขนาดได้นำ Ethereum ไปสู่การเพิ่มขึ้น การเปลี่ยนไปใช้บล็อกเชนแบบโมดูลาร์ได้จุดประกายความสนใจให้กับ App Chains และเหนือขอบฟ้า เราได้ยินเสียงกระซิบของโรลอัพเฉพาะแอปพลิเคชัน L3 และ Sovereign Chains

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

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

โซลูชัน AMP ทุกรายการต้องการความสามารถที่สำคัญ 2 ประการ:

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

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

เราแบ่งภาพรวมความสามารถในการทำงานร่วมกันโดยรวมตามกลไกความไว้วางใจและสถาปัตยกรรมการบูรณาการ

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

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

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

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

1. โมเดลแบบจุดต่อจุด: จำเป็นต้องสร้างช่องทางการสื่อสารเฉพาะระหว่างทุกต้นทางและทุกปลายทาง
2. โมเดล Hub และ Spoke: จำเป็นต้องสร้างช่องทางการสื่อสารด้วยฮับกลางที่ช่วยให้สามารถเชื่อมต่อกับบล็อกเชนอื่น ๆ ทั้งหมดที่เชื่อมต่อกับฮับนั้น

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

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

light client จะตรวจสอบฉันทามติของห่วงโซ่ต้นทางบนห่วงโซ่ปลายทางได้อย่างไร

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

1. ความปลอดภัย:

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

1. การนำไปปฏิบัติ: ขึ้นอยู่กับความพร้อมใช้งานของการสนับสนุนสำหรับการเข้ารหัสลับขั้นพื้นฐานที่จำเป็นสำหรับการตรวจสอบ

• หากมีการเชื่อมต่อเชนประเภทเดียวกัน (เฟรมเวิร์กแอปพลิเคชันเดียวกันและอัลกอริธึมที่เป็นเอกฉันท์) การใช้งานไคลเอ็นต์แบบเบาทั้งสองด้านจะเหมือนกัน ตัวอย่าง: IBC สำหรับเชนที่ใช้ Cosmos SDK ทั้งหมด
• หากมีการเชื่อมต่อเชนที่แตกต่างกันสองประเภท (เฟรมเวิร์กแอปพลิเคชันหรือประเภทฉันทามติที่แตกต่างกัน) การใช้งานไคลเอ็นต์แบบเบาจะแตกต่างกัน ตัวอย่าง: การเงินแบบผสมผสานกำลังทำงานเพื่อให้เครือข่าย Cosmos SDK สามารถเชื่อมต่อผ่าน IBC ไปยัง Substrate (เฟรมเวิร์กแอปของระบบนิเวศ Polkadot) ซึ่งจำเป็นต้องมีไคลเอนต์แบบเบา Tendermint บนห่วงโซ่ของวัสดุพิมพ์ และที่เรียกว่าไคลเอนต์แบบเบาที่เพิ่มเข้ากับห่วงโซ่ Cosmos SDK

1. ความท้าทาย:

• ความเข้มข้นของทรัพยากร: การรันไคลเอนท์แบบ pairwise light บนเชนทั้งหมดนั้นมีราคาแพง เนื่องจากการเขียนบนบล็อกเชนนั้นมีราคาแพง และไม่สามารถรันบนเชนที่มีชุดเครื่องมือตรวจสอบแบบไดนามิก เช่น Ethereum ได้
• ความสามารถในการขยาย: จำเป็นต้องมีการใช้งานไคลเอนต์แบบเบาสำหรับการรวมกันของเชนแต่ละอัน เนื่องจากการใช้งานจะแตกต่างกันไปตามสถาปัตยกรรมของห่วงโซ่ จึงเป็นเรื่องยากที่จะปรับขนาดและเชื่อมโยงระบบนิเวศต่างๆ
• การใช้โค้ดในทางที่ผิด: ข้อผิดพลาดในโค้ดอาจทำให้เกิดช่องโหว่ได้ การใช้ประโยชน์จากเครือข่าย BNB ในเดือนตุลาคม 2565 ได้เปิดเผย ช่องโหว่ ด้านความปลอดภัยที่สำคัญซึ่งส่งผลกระทบต่อเครือข่ายที่เปิดใช้งาน IBC ทั้งหมด

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

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

1. ความปลอดภัย: zk-SNARK ขึ้นอยู่กับเส้นโค้งวงรีเพื่อความปลอดภัย และ zk-STARK ขึ้นอยู่กับฟังก์ชันแฮช zk-SNARK อาจหรือไม่ต้องการการตั้งค่าที่เชื่อถือได้ การตั้งค่าที่เชื่อถือได้จำเป็นในขั้นต้นเท่านั้น ซึ่งหมายถึงเหตุการณ์การสร้างครั้งแรกของคีย์ที่ใช้ในการสร้างหลักฐานที่จำเป็นสำหรับการตรวจสอบหลักฐานเหล่านั้น หากความลับในเหตุการณ์การตั้งค่าไม่ถูกทำลาย ก็สามารถใช้เพื่อปลอมธุรกรรมโดยการตรวจสอบที่ผิดพลาดได้ ไม่มีการแนะนำสมมติฐานด้านความน่าเชื่อถือเมื่อการตั้งค่าที่เชื่อถือได้เสร็จสิ้น
2. การนำไปปฏิบัติ: แผนการพิสูจน์ ZK ต่างๆ เช่น SNARK, STARK, VPD, SNARG มีอยู่ในปัจจุบัน และปัจจุบัน SNARK ได้รับการยอมรับอย่างกว้างขวางที่สุด การพิสูจน์ ZK แบบเรียกซ้ำเป็นการพัฒนาล่าสุดอีกประการหนึ่งที่ช่วยให้งานการพิสูจน์ทั้งหมดถูกแบ่งระหว่างคอมพิวเตอร์หลายเครื่องแทนที่จะเป็นเพียงเครื่องเดียว ในการสร้างการพิสูจน์ความถูกต้อง จำเป็นต้องใช้หลักพื้นฐานต่อไปนี้:

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

1. ความท้าทาย:

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

1. ตัวอย่าง: Polymer ZK-IBC โดย Polymer Labs, Succinct Labs โพลีเมอร์กำลังทำงานบน IBC ที่เปิดใช้งาน มัลติฮอป เพื่อเพิ่มการเชื่อมต่อในขณะที่ลดจำนวนการเชื่อมต่อแบบคู่ที่จำเป็น

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

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

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

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

ลักษณะสำคัญของกลไกเหล่านี้คือ:

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

• สายโซ่กลางที่มีเครื่องมือตรวจสอบความถูกต้องของตัวเอง: กลุ่มเครื่องมือตรวจสอบภายนอกตรวจสอบห่วงโซ่แหล่งที่มา บรรลุข้อตกลงที่เป็นเอกฉันท์เกี่ยวกับความถูกต้องของธุรกรรมทุกครั้งที่ตรวจพบการโทร และจัดให้มีการรับรองในห่วงโซ่ปลายทางหากบรรลุข้อตกลงร่วมกัน โดยปกติผู้ตรวจสอบความถูกต้องจะต้องวางเดิมพันโทเค็นจำนวนหนึ่งซึ่งสามารถเฉือนได้หากตรวจพบกิจกรรมที่เป็นอันตราย ตัวอย่าง: Axelar Network, Celer IM
• ผ่านทางตัวแทน Off-chain: สามารถใช้ตัวแทน Off-chain เพื่อปรับใช้โซลูชันโรลอัพในแง่ดี โดยที่ในช่วงเวลาที่กำหนดไว้ล่วงหน้า ตัวแทนนอกเครือข่ายจะได้รับอนุญาตให้ส่งหลักฐานการฉ้อโกงและยกเลิกการทำธุรกรรม ตัวอย่าง: Nomad อาศัยตัวแทนนอกเครือข่ายอิสระเพื่อถ่ายทอดส่วนหัวและการพิสูจน์การเข้ารหัส ChainLink CCIP จะใช้ประโยชน์จากเครือข่ายออราเคิลที่มีอยู่สำหรับการตรวจสอบและยืนยันธุรกรรมข้ามเชน

1. ความท้าทาย:

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

1. ข้อดี:

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

เชื่อใจมนุษย์

1. ข้อสันนิษฐานโดยสุจริตส่วนใหญ่: โซลูชันเหล่านี้อาศัยการใช้งานหลายซิกโดยที่หลายหน่วยงานตรวจสอบและลงนามในธุรกรรม เมื่อถึงเกณฑ์ขั้นต่ำแล้ว ธุรกรรมจะถือว่าถูกต้อง ข้อสันนิษฐานในที่นี้คือหน่วยงานส่วนใหญ่มีความซื่อสัตย์ และหากหน่วยงานเหล่านี้ส่วนใหญ่ลงนามในธุรกรรมใดธุรกรรมหนึ่ง ก็ถือว่าถูกต้อง สิ่งเดียวที่เป็นเดิมพันที่นี่คือชื่อเสียงของหน่วยงานที่เข้าร่วม ตัวอย่าง: มัลติเชน (Anycall V6), รูหนอน การใช้ประโยชน์เนื่องจากข้อบกพร่องของสัญญาอัจฉริยะยังคงเป็นไปได้ ดังที่เห็นได้จาก การเจาะระบบ Wormhole ในต้นปี 2565
2. ความเป็นอิสระ: โซลูชันเหล่านี้แบ่งกระบวนการส่งข้อความทั้งหมดออกเป็นสองส่วน และอาศัยหน่วยงานอิสระที่แตกต่างกันในการจัดการทั้งสองกระบวนการ ข้อสันนิษฐานในที่นี้คือทั้งสองเอนทิตีเป็นอิสระจากกันและไม่ได้สมรู้ร่วมคิด ตัวอย่าง: LayerZero ส่วนหัวของบล็อกจะถูกสตรีมตามความต้องการโดยออราเคิลแบบกระจายอำนาจ และการพิสูจน์ธุรกรรมจะถูกส่งผ่านรีเลย์ หากหลักฐานตรงกับส่วนหัว ธุรกรรมจะถือว่าถูกต้อง แม้ว่าการจับคู่พิสูจน์จะขึ้นอยู่กับรหัส/คณิตศาสตร์ ผู้เข้าร่วมจะต้องเชื่อถือเอนทิตีให้คงความเป็นอิสระ แอปพลิเคชันที่สร้างบน LayerZero มีตัวเลือกในการเลือก Oracle และ Relayer (หรือโฮสต์ Oracle/Relayer ของตนเอง) ซึ่งจะช่วยจำกัดความเสี่ยงต่อการสมรู้ร่วมคิดของ Oracle/Relayer แต่ละรายการ ผู้ใช้จำเป็นต้องไว้วางใจว่า LayerZero บุคคลที่สาม หรือตัวแอปพลิเคชันเองกำลังเรียกใช้ oracle และตัวส่งต่ออย่างเป็นอิสระและไม่มีเจตนาร้าย

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

เหนือกว่าสมมติฐานด้านความไว้วางใจและอนาคตของการทำงานร่วมกัน

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

• ความสมบูรณ์ของโค้ด: การแฮ็กจำนวนหนึ่งในอดีตได้ใช้ประโยชน์จากข้อบกพร่องในโค้ดซึ่งจำเป็นต้องมีการตรวจสอบที่เชื่อถือได้ ค่าหัวข้อบกพร่องที่วางแผนไว้อย่างดี และการใช้งานไคลเอนต์หลายตัว หากผู้ตรวจสอบความถูกต้องทั้งหมด (ในด้านเศรษฐกิจ/ในแง่ดี/ความปลอดภัยด้านชื่อเสียง) เรียกใช้ไคลเอนต์เดียวกัน (ซอฟต์แวร์สำหรับการตรวจสอบ) มันจะเพิ่มการพึ่งพาโค้ดเบสเดียว และลดความหลากหลายของไคลเอนต์ ตัวอย่างเช่น Ethereum อาศัยไคลเอนต์การดำเนินการหลายตัว เช่น geth, nethermind, erigon, besu, akula การใช้งานหลายภาษาในหลายภาษามีแนวโน้มที่จะเพิ่มความหลากหลายโดยไม่ต้องมีไคลเอ็นต์ใด ๆ ครอบงำเครือข่าย ดังนั้นจึงช่วยลดจุดล้มเหลวเพียงจุดเดียวที่อาจเกิดขึ้นได้ การมีไคลเอนต์หลายตัวยังช่วยให้มีความมีชีวิตชีวาได้ หากผู้ตรวจสอบ/ผู้ลงนาม/ไคลเอนต์แบบ light ส่วนน้อยหยุดทำงานเนื่องจากการหาประโยชน์/ข้อบกพร่องในการใช้งานเฉพาะรายการเดียว
• การตั้งค่าและความสามารถในการอัปเกรด: ผู้ใช้และนักพัฒนาจำเป็นต้องทราบว่าผู้ตรวจสอบ/ผู้ดูสามารถเข้าร่วมเครือข่ายในลักษณะที่ไม่ได้รับอนุญาตหรือไม่ ไม่เช่นนั้นความไว้วางใจจะถูกซ่อนไว้โดยการเลือกเอนทิตีที่ได้รับอนุญาต การอัปเกรดเป็นสัญญาอัจฉริยะอาจทำให้เกิดข้อบกพร่องซึ่งอาจนำไปสู่การหาประโยชน์หรือแม้กระทั่งอาจเปลี่ยนแปลงสมมติฐานด้านความน่าเชื่อถือได้ สามารถใช้โซลูชันต่างๆ เพื่อลดความเสี่ยงเหล่านี้ได้ ตัวอย่างเช่น ในอินสแตนซ์ปัจจุบัน เกตเวย์ Axelar สามารถอัปเกรดได้ขึ้นอยู่กับการอนุมัติจากคณะกรรมการออฟไลน์ (เกณฑ์ 4/8) อย่างไรก็ตาม ในอนาคตอันใกล้นี้ Axelar วางแผนที่จะกำหนดให้ผู้ตรวจสอบความถูกต้องทั้งหมดอนุมัติการอัปเกรดเกตเวย์ร่วมกัน สัญญาหลักของ Wormhole สามารถอัพเกรดได้ และจัดการผ่านระบบกำกับดูแลแบบออนไลน์ของ Wormhole LayerZero อาศัยสัญญาอัจฉริยะที่ไม่เปลี่ยนรูปและไลบรารีที่ไม่เปลี่ยนรูปแบบเพื่อหลีกเลี่ยงการอัพเกรดใดๆ อย่างไรก็ตาม มันสามารถพุชไลบรารีใหม่ได้ และ DApps ที่มีการตั้งค่าเริ่มต้นจะได้รับเวอร์ชันที่อัปเดต และ DApps ที่ตั้งค่าเวอร์ชันด้วยตนเองจะต้องตั้งค่าเป็นเวอร์ชันใหม่ .
• MEV: บล็อกเชนที่แตกต่างกันจะไม่ซิงโครไนซ์ผ่านนาฬิกาทั่วไป และมีเวลาที่แตกต่างกันจนกว่าจะถึงขั้นสุดท้าย เป็นผลให้ลำดับและเวลาของการดำเนินการในห่วงโซ่ปลายทางอาจแตกต่างกันไปตามเครือข่ายต่างๆ MEV ในโลกแบบ cross-chain เป็นสิ่งที่ท้าทายในการกำหนดให้ชัดเจน โดยจะแนะนำการแลกเปลี่ยนระหว่างความมีชีวิตชีวาและลำดับการดำเนินการ ช่องทางที่สั่งซื้อจะรับประกันการส่งข้อความตามคำสั่งซื้อ แต่ช่องทางจะปิดหากมีข้อความใดข้อความหนึ่งหมดเวลา แอปพลิเคชันอื่นอาจต้องการสถานการณ์ที่ไม่จำเป็นต้องสั่งซื้อ แต่ไม่กระทบต่อการส่งข้อความอื่น

แนวโน้มและแนวโน้มในอนาคต:

• การรักษาความปลอดภัยที่ปรับแต่งได้และเพิ่มเติม: เพื่อรองรับกรณีการใช้งานที่หลากหลายได้ดียิ่งขึ้น โซลูชัน AMP จึงได้รับการจูงใจให้มอบความยืดหยุ่นให้กับนักพัฒนามากขึ้น Axelar แนะนำแนวทาง สำหรับการอัปเกรดการส่งผ่านข้อความและการตรวจสอบ โดยไม่มีการเปลี่ยนแปลงตรรกะของเลเยอร์แอปพลิเคชัน HyperLane V2 เปิดตัวโมดูลที่ช่วยให้นักพัฒนาสามารถเลือกได้จากหลายตัวเลือก เช่น ความปลอดภัยทางเศรษฐกิจ ความปลอดภัยในแง่ดี ความปลอดภัยแบบไดนามิก และความปลอดภัยแบบไฮบริด CelerIM นำเสนอการรักษาความปลอดภัยในแง่ดีเพิ่มเติมพร้อมกับความมั่นคงทางเศรษฐกิจ โซลูชันจำนวนมากรอการยืนยันบล็อกตามจำนวนขั้นต่ำที่กำหนดไว้ล่วงหน้าในห่วงโซ่ต้นทางก่อนที่จะส่งข้อความ LayerZero ช่วยให้นักพัฒนาอัปเดตพารามิเตอร์เหล่านี้ได้ เราคาดว่าโซลูชัน AMP บางส่วนจะยังคงให้ความยืดหยุ่นมากขึ้นต่อไป แต่ตัวเลือกการออกแบบเหล่านี้รับประกันว่าจะมีการพูดคุยกัน แอพควรสามารถกำหนดค่าความปลอดภัยได้ในระดับใด และจะเกิดอะไรขึ้นหากแอพใช้สถาปัตยกรรมการออกแบบที่ต่ำกว่ามาตรฐาน ความตระหนักของผู้ใช้เกี่ยวกับแนวคิดพื้นฐานเบื้องหลังความปลอดภัยอาจมีความสำคัญมากขึ้น ท้ายที่สุดแล้ว เราคาดการณ์ถึงการรวมตัวและความเป็นนามธรรมของโซลูชัน AMP ซึ่งอาจอยู่ในรูปแบบของ การรักษาความปลอดภัยแบบผสมผสานหรือการรักษาความปลอดภัย "เพิ่มเติม"
• การเติบโตและการสุกงอมของกลไก "รหัสความเชื่อถือ/คณิตศาสตร์": ในช่วงท้ายเกมที่สมบูรณ์แบบ ข้อความข้ามสายโซ่ทั้งหมดจะถูกลดความน่าเชื่อถือให้เหลือน้อยที่สุดโดยใช้การพิสูจน์ความรู้แบบศูนย์ (ZK) เพื่อยืนยันข้อความและสถานะ เราเห็นการเปลี่ยนแปลงนี้แล้วจากการเกิดขึ้นของโครงการต่างๆ เช่น Polymer Labs และ Succinct Labs Multichain เพิ่ง เผยแพร่ เอกสารทางเทคนิคของ zkRouter เพื่อเปิดใช้งานการทำงานร่วมกันผ่านการพิสูจน์ ZK ด้วย Axelar Virtual Machine ที่เพิ่ง ประกาศไป เมื่อเร็วๆ นี้ นักพัฒนาสามารถใช้ประโยชน์จาก Interchain Amplifier เพื่อตั้งค่าการเชื่อมต่อใหม่ไปยังเครือข่าย Axelar โดยไม่ได้รับอนุญาต ตัวอย่างเช่น เมื่อ light-client ที่แข็งแกร่งและการพิสูจน์ ZK สำหรับสถานะของ Ethereum ได้รับการพัฒนาแล้ว นักพัฒนาก็สามารถรวมเข้ากับเครือข่าย Axelar ได้อย่างง่ายดายเพื่อแทนที่หรือปรับปรุงการเชื่อมต่อที่มีอยู่ LayerZero ในเอกสารกล่าวถึงความเป็นไปได้ในการเพิ่มไลบรารีข้อความพิสูจน์อักษรที่ได้รับการปรับปรุงใหม่ในอนาคต โปรเจ็กต์ใหม่ๆ เช่น Lagrange กำลังสำรวจการรวบรวมการพิสูจน์หลายรายการจากแหล่งต่างๆ หลายแห่ง และ Herodotus กำลังทำให้การพิสูจน์การจัดเก็บข้อมูลเป็นไปได้ผ่านการพิสูจน์ ZK อย่างไรก็ตาม การเปลี่ยนแปลงนี้จะใช้เวลาเนื่องจากแนวทางนี้เป็นเรื่องยากที่จะปรับขนาดระหว่างบล็อกเชน โดยอาศัยกลไกและกรอบการทำงานที่เป็นเอกฉันท์ที่แตกต่างกัน ZK เป็นเทคโนโลยีที่ค่อนข้างใหม่และซับซ้อนซึ่งท้าทายในการตรวจสอบ และในปัจจุบัน การสร้างการตรวจสอบและพิสูจน์อักษรยังไม่คุ้มค่ากับต้นทุน เราเชื่อว่าในระยะยาว เพื่อรองรับแอปพลิเคชันข้ามสายโซ่ที่ปรับขนาดได้สูงบนบล็อกเชน โซลูชัน AMP จำนวนมากมีแนวโน้มที่จะเสริมมนุษย์และหน่วยงานที่เชื่อถือได้ด้วยซอฟต์แวร์ที่ตรวจสอบได้ เนื่องจาก:
• ความเป็นไปได้ของการใช้ประโยชน์จากโค้ดสามารถลดลงได้ผ่านการตรวจสอบและค่าหัวบั๊ก เมื่อเวลาผ่านไป การเชื่อถือระบบเหล่านี้ก็จะง่ายขึ้น เนื่องจากประวัติของระบบจะทำหน้าที่เป็นข้อพิสูจน์ถึงความปลอดภัย
• ต้นทุนในการสร้างหลักฐาน ZK จะลดลง ด้วยการวิจัยและพัฒนาที่มากขึ้นใน ZKP, ZK แบบเรียกซ้ำ, การรวมการพิสูจน์ และฮาร์ดแวร์เฉพาะทาง เราคาดหวังว่าเวลาและต้นทุนในการสร้างและการตรวจสอบการพิสูจน์จะลดลงอย่างมาก ทำให้เป็นแนวทางที่คุ้มต้นทุนมากขึ้น
• Blockchains จะเป็นมิตรกับ zk มากขึ้น ในอนาคต zkEVM จะสามารถพิสูจน์ความถูกต้องของการดำเนินการโดยสรุป และโซลูชันที่ใช้ไคลเอนต์แบบเบาจะสามารถตรวจสอบทั้งการดำเนินการและความเห็นพ้องต้องกันของห่วงโซ่ต้นทางบนห่วงโซ่ปลายทางได้อย่างง่ายดาย ในช่วงท้ายเกมของ Ethereum ยังมีแผนที่จะ “zk-SNARK ทุกอย่าง” รวมถึงความเห็นพ้องต้องกันด้วย
• การพิสูจน์ความเป็นมนุษย์/ ชื่อเสียง/ ตัวตน: ความปลอดภัยของระบบที่ซับซ้อน เช่น โซลูชัน AMP ไม่สามารถสรุปได้ผ่านเฟรมเวิร์กเดียว และรับประกันว่าโซลูชันมีหลายชั้น ตัวอย่างเช่น พร้อมด้วยสิ่งจูงใจทางเศรษฐกิจ Axelar ได้ใช้ การลงคะแนนแบบกำลังสอง เพื่อป้องกันการกระจุกตัวของอำนาจการลงคะแนนในกลุ่มย่อยของโหนดและส่งเสริมการกระจายอำนาจ การพิสูจน์ความเป็นมนุษย์ ชื่อเสียง และอัตลักษณ์อื่นๆ ยังช่วยเสริมกลไกในการตั้งค่าและการอนุญาตได้อีกด้วย

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

เราขอขอบคุณ Bo Du และ Peter Kim จาก Polymer Labs, Galen Moore จาก Axelar Network, Uma Roy จาก Succinct Labs, Max Glassman และ Ryan Zarick จาก LayerZero สำหรับการตรวจสอบและให้ข้อเสนอแนะอันมีค่าของพวกเขา

รายการอ้างอิง:

• แอ็กเซลาร์: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introcing-the-cross-chain-interoperability-protocol-ccip/
• ดีบริดจ์: https://docs.debridge.finance/
• ไอบีซี: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• มัลติเชน: https://docs.multichain.org/getting-started/introduction
• เร่ร่อน: https://docs.nomad.xyz/nomad-101/introduction
• โพลีเมอร์แล็บ: https://polymerlabs.medium.com/
• รวบรัด Labs: https://blog.succinct.xyz/
• รูหนอน: https://docs.wormhole.com/wormhole/

รายการอ่านเพิ่มเติม:

• การนำทางบริดจ์การส่งข้อความตามอำเภอใจ: กรอบงานการเปรียบเทียบ: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• กรอบการทำงานความเสี่ยง L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horatius ที่สะพาน: https://maven11.substack.com/p/horatius-at-the-bridge

ข้อสงวนสิทธิ์：

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