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

ผู้แต่ง：ชิไคเหว่ย，รักาฟ อการ์วาล

เรียบเรียง: 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 ZK-IBC จาก Polymer Labs และ Telepathy จาก Succinct Labs โพลิเมอร์กำลังพัฒนา IBCs แบบมัลติฮอปเพื่อเพิ่มการเชื่อมต่อและลดจำนวนการเชื่อมต่อแบบจับคู่ที่ต้องใช้

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

ความปลอดภัย

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

** การนำไปใช้ **

มีแผนการพิสูจน์ ZK ที่หลากหลาย เช่น SNARK, STARK, VPD และ SNARG และปัจจุบัน SNARK ถูกใช้อย่างแพร่หลายที่สุด เฟรมเวิร์กการพิสูจน์ SNARK ที่แตกต่างกัน เช่น Groth16, Plonk, Marlin, Halo และ Halo2 เสนอการแลกเปลี่ยนในแง่ของขนาดการพิสูจน์ เวลาพิสูจน์ เวลาในการตรวจสอบ ความต้องการหน่วยความจำ และข้อกำหนดการตั้งค่าที่เชื่อถือได้ นอกจากนี้ยังมีการพิสูจน์ 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 V6) และ 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