การแนะนำ

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

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

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

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

ลองใช้ USDC เป็นตัวอย่างของความไม่เข้ากันระหว่างโทเค็น ERC-20 ที่เหมือนกันในทางทฤษฎีในเครือข่ายที่แตกต่างกัน ใน เครือข่าย Ethereum Layer 2 (L2) เช่น Arbitrum, Base, Optimism เป็นเรื่องปกติที่จะใช้สะพานแบบ canonical เพื่อย้ายโทเค็น ERC-20 ยอดนิยมจาก Ethereum L1 ไปยังเครือข่ายเหล่านี้ โทเค็น L2 ที่มีต้นกำเนิดจาก L1 เหล่านี้มักเรียกกันว่า "สะพาน [ใส่ชื่อโทเค็น]"

ในกรณีของ USDC สัญลักษณ์ทั่วไปคือ USDC.e, USDC.b และอื่นๆ เมื่อเวลาผ่านไป Circle ขยายการใช้งาน USDC ไปยังเครือข่ายอื่นๆ รวมถึง L2 ซึ่ง USDC เปิดใช้งานอยู่แล้วผ่านสะพานแบบ canonical แม้ว่าโทเค็นทั้งสองนี้จะถูกสร้างขึ้นโดยเอนทิตีเดียวกันและมีราคาเท่ากัน แต่ในทางเทคนิคแล้ว โทเค็นทั้งสองนี้แตกต่างกันและไม่สามารถแทนที่กันได้ จึงไม่สามารถ "ทำงานร่วมกัน" ได้ ในขณะที่ USDC ดั้งเดิมสามารถเชื่อมต่อผ่านสะพาน CCTP ของ Circle ได้ แต่ USDC ที่เชื่อมต่อแล้วสามารถเชื่อมต่อกลับไปยัง L1 ได้ผ่านสะพานแบบ canonical เท่านั้น

ERC-7281 แก้ไขปัญหานี้ด้วยการแนะนำส่วนขยาย ERC-20 ซึ่งผู้ปรับใช้โทเค็นสามารถกำหนดและกำหนดค่าพารามิเตอร์แหล่งที่มาของการเชื่อมโยงที่แตกต่างกันสำหรับโทเค็นนั้นได้ ในตัวอย่างด้านบน Circle สามารถปรับใช้โทเค็น USDC สากลบน L2 ทั้งหมด โดยที่บริดจ์มาตรฐาน (เช่น Circle Mint, Circle CCTP และบริดจ์ที่ได้รับการอนุมัติอื่นๆ) ทั้งหมดได้รับการกำหนดให้สามารถสร้างโทเค็นได้ตามตรรกะของบริดจ์ เพื่อลดความเสี่ยงที่ผู้สร้างจะถูกแฮ็ก ผู้ปรับใช้สามารถจำกัดจำนวนโทเค็นที่ผู้สร้างแต่ละรายสามารถสร้างและเผาได้ในช่วงเวลาที่กำหนด โดยบริดจ์ที่เชื่อถือได้มากกว่า เช่น บริดจ์ L2 มาตรฐานจะมีขีดจำกัดที่สูงกว่า และบริดจ์ที่มีฉันทามติแบบรวมศูนย์จะมีขีดจำกัดที่ต่ำกว่า

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

รายงานสองส่วนนี้จะตรวจสอบเหตุผลในการนำมาตรฐานโทเค็นที่เชื่อมโยงกันโดยรัฐบาลมาใช้ และให้ภาพรวมที่ครอบคลุมของข้อกำหนด ERC-7281 (หรือที่เรียกว่า xERC-20) นอกจากนี้ เราจะหารือเกี่ยวกับประโยชน์เชิงบวกและข้อเสียที่อาจเกิดขึ้นจากการนำ ERC-7281 มาใช้สำหรับผู้ใช้ นักพัฒนา ผู้ให้บริการโครงสร้างพื้นฐาน และผู้มีส่วนเกี่ยวข้องอื่นๆ ในระบบนิเวศ Ethereum

การทบทวนเกี่ยวกับสะพานบล็อคเชน

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

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

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

สะพานล็อคแอนด์มิ้นต์

• ผู้ใช้ต้องการเชื่อมโยงโทเค็นจากเชนดั้งเดิมหรือ "โฮม" (ที่ซึ่งโทเค็นถูกออกในตอนแรก) ไปยังเชนอื่น บล็อคเชนทั้งสองไม่สามารถทำงานร่วมกันได้ เนื่องจากแต่ละเชนใช้สถาปัตยกรรมและการออกแบบโปรโตคอลที่แตกต่างกัน ซึ่งป้องกันไม่ให้ผู้ใช้โอนโทเค็นโดยตรงจากที่อยู่กระเป๋าเงินบนเชน A ไปยังที่อยู่กระเป๋าเงินบนเชน B

• ผู้ดำเนินการสะพานจะฝากโทเค็นที่ผู้ใช้ฝากไว้ในเชนต้นกำเนิดในสัญญาอัจฉริยะ และสร้างการแสดง "แบบห่อหุ้ม" ของโทเค็นดั้งเดิมผ่านสัญญาโทเค็นที่ปรับใช้ในเชนเป้าหมาย

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

  
  

สะพานเผาและมิ้นต์

• แทนที่จะล็อคโทเค็นในเอสโครว์ วิธีนี้จะเผา (ทำลาย) โทเค็นในห่วงโซ่แหล่งที่มา

• จากนั้นสะพานจะสร้างปริมาณที่เท่ากันบนห่วงโซ่จุดหมายปลายทาง

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

• วิธีนี้จะช่วยรักษาปริมาณโทเค็นรวมในขณะที่เปิดใช้งานการโอนข้ามสายโซ่

  
  

การสลับอะตอม

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

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

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

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

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

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

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

เหตุใดเราจึงต้องมีสะพาน?

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

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

BobDEX คือระบบแลกเปลี่ยนอัตโนมัติ (Automated Market Maker หรือ AMM) ที่ Bob สร้างขึ้นบน Ethereum เพื่อให้สามารถแลกเปลี่ยนสินทรัพย์ต่างๆ ได้โดยไม่ต้องไว้วางใจใคร BobDEX มีโทเค็นดั้งเดิมคือ $BOB ซึ่งทำหน้าที่เป็นโทเค็นการกำกับดูแลและโทเค็นรางวัล LP ในกรณีหลังนี้ BobDEX จะออกโทเค็น BOB ให้กับผู้ให้บริการสภาพคล่อง (LP) โดยให้สิทธิ์ผู้ใช้ในการจัดหาสภาพคล่องให้กับกลุ่ม โดยได้รับค่าธรรมเนียมเป็นเปอร์เซ็นต์จากค่าธรรมเนียมที่ผู้ใช้ DEX จ่ายในการสลับสินทรัพย์ที่ฝากไว้ในกลุ่ม

ส่วนแบ่งการตลาดของ BobDEX เติบโตขึ้นอย่างมาก แต่ข้อจำกัดของ Ethereum L1 ขัดขวางการเติบโตต่อไป ตัวอย่างเช่น ผู้ใช้บางคนไม่ต้องการใช้ BobDEX บน Ethereum เนื่องจากค่าธรรมเนียมก๊าซที่สูงและความล่าช้าของธุรกรรม ในทำนองเดียวกัน ผู้ใช้คนอื่นๆ ต้องการสัมผัสกับราคาโทเค็น $BOB โดยไม่ต้องถือโทเค็น $BOB ดั้งเดิมบน Ethereum

เพื่อแก้ไขปัญหานี้ บ็อบได้นำ BobDEX เวอร์ชันหนึ่งไปใช้งานบน Arbitrum (การสรุปเลเยอร์ 2 (L2) ที่มีค่าธรรมเนียมต่ำและมีปริมาณงานสูง) และนำ BOB token (wBOB) เวอร์ชันที่ห่อหุ้มไว้ไปใช้งานบน L2 ผ่านสะพาน Arbitrum-Ethereum BobDEX บน Arbitrum นั้นเหมือนกับ BobDEX บน Ethereum ทุกประการ ยกเว้นว่า BobDEX ใช้ wBOB—ไม่ใช่โทเค็น BOB ดั้งเดิม—สำหรับรางวัล LP และการกำกับดูแล

ความแตกต่างระหว่างโทเค็นแอปพลิเคชัน (BOB ที่ห่อหุ้มไว้กับ BOB ดั้งเดิม) ไม่สร้างความแตกต่างจากมุมมองของผู้ใช้ (เช่น ผู้ให้บริการสภาพคล่อง) ที่โต้ตอบกับ BobDEX บน Arbitrum เนื่องจากโทเค็น wBOB ได้รับการหนุนหลังโดยโทเค็น BOB จริงที่ถืออยู่ในสะพาน Arbitrum-Ethereum ผู้ถือโทเค็น wBOB จึงสามารถสลับเป็นโทเค็น BOB ERC-20 ดั้งเดิมบน Ethereum ได้อย่างง่ายดายโดยโต้ตอบกับสัญญาสะพาน

สถานการณ์นี้เป็นสถานการณ์ที่ทั้งสามฝ่ายได้ประโยชน์ทั้ง Bob และผู้ใช้:

1. Bob สามารถดึงดูดผู้ใช้ได้มากขึ้น โดยเฉพาะผู้ใช้ที่ต้องการค่าธรรมเนียมแก๊สต่ำและการยืนยันธุรกรรมที่รวดเร็วเมื่อทำการซื้อขายบน BobDEX

2. LPs สามารถรับรางวัลจากการจัดหาสภาพคล่องให้กับ BobDEX โดยไม่ต้องรับมือกับต้นทุนแก๊สที่สูงของ Ethereum และเวลาในการยืนยันที่ยาวนาน

3. ผู้ถือครองสามารถซื้อโทเค็น wBOB ในตลาดเพื่อทำกำไรจากการเปลี่ยนแปลงราคาโทเค็น BOB โดยไม่ต้องโต้ตอบกับสัญญา BOB ERC-20 บน Ethereum

   
   

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

ผู้ให้กู้ที่จัดหาสภาพคล่องให้กับ AliceLend มั่นใจว่าจะได้รับเงินฝาก: หากผู้ใช้ผิดนัดชำระเงินกู้ AliceLend จะประมูลโทเค็น wBOB ที่ฝากไว้เป็นหลักประกันโดยอัตโนมัติเพื่อชำระคืนให้กับผู้ให้กู้ ในกรณีนี้ ผู้ซื้อหลักประกัน wBOB ที่ชำระแล้วจะได้รับบทบาทเป็น LP บน BobDEX และได้รับการรับประกันเช่นเดียวกันว่าโทเค็น wBOB สามารถแลกเปลี่ยนเป็นโทเค็น BOB ดั้งเดิมได้ในอัตรา 1:1

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

เหตุใดโทเค็นที่เชื่อมโยงจึงไม่สามารถทดแทนได้

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

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

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

• Alice เชื่อมโยง USDC จาก Ethereum ไปยัง Arbitrum ผ่าน Arbitrum bridge แบบดั้งเดิม และรับ 200 USDC.e บน Arbitrum ในขณะที่ Bob เชื่อมโยง USDC ไปยัง Arbitrum ผ่าน Axelar และรับ 200 axlUSDC บน Arbitrum Alice และ Bob ทำข้อตกลงให้ Alice ส่ง 200 USDC ให้กับ Bob (แลกกับ 200 USDT) เพื่อให้ Bob ถอน 400 USDC ไปยัง Ethereum ได้
• บ็อบพยายามถอน 400 USDC ผ่าน axlUSDC แต่กลับได้รับเพียง 200 USDC พร้อมข้อความที่อธิบายว่าสะพานมี 200 USDC เท่านั้นที่สามารถให้บ็อบได้ บ็อบสับสนเนื่องจากโทเค็น ERC-20 ที่ห่อหุ้มไว้ควรจะ "ใช้แทนกันได้" และไม่ควรมีความแตกต่างที่ป้องกันไม่ให้ใครก็ตามแลกเปลี่ยนโทเค็น ERC-20 แบบ 1:1 ในแอปพลิเคชันใดๆ
• บ็อบได้เรียนรู้บทเรียนอันยากลำบากเกี่ยวกับการเชื่อมโยงข้ามเครือข่าย: “โทเค็น ERC-20 ที่สามารถเปลี่ยนแทนกันได้” ไม่ได้หมายความเสมอไปว่า “คุณสามารถแลกเปลี่ยนโทเค็นนี้ 1:1 กับโทเค็น ERC-20 อื่นๆ ข้ามแอปพลิเคชันได้” ความพยายามของบ็อบในการทำธุรกิจเสี่ยงกับอลิซ—เสี่ยงมากเพราะอลิซอาจไม่คืนโทเค็น—กลับกลายเป็นเรื่องเลวร้ายอย่างน่าตกตะลึง

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

มูลค่าของโทเค็นที่เชื่อมโยงแต่ละอันจึงถูกผูกไว้กับผู้ให้บริการที่รับผิดชอบในการถือเงินฝากบนโฮมเชนและการสร้างการแสดงบนปลายทาง ผู้ให้บริการที่เชื่อมโยงของ Bob สามารถจ่ายให้ Bob ได้เพียง 200 USDC เท่านั้น เนื่องจากเป็นจำนวนเงินที่ต้องจ่ายจากเงินฝากของเขา ไม่สามารถถอน 200 USDC ของ Alice ผ่านผู้ให้บริการที่เชื่อมโยงของ Bob ได้ เนื่องจากไม่เคยได้รับเงินฝากหรือออก IOU ให้กับ Alice Alice ต้องถอน USDC ที่ถูกล็อคของเธอออกจาก Arbitrum บน Ethereum และเชื่อมโยงผ่านผู้ให้บริการที่เชื่อมโยงของ Bob ก่อนที่ Bob จะสามารถเข้าถึงโทเค็นที่เหลือได้

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

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

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

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

การนำโทเค็นเชิงบัญญัติไปใช้ในเครือข่ายที่แตกต่างกัน

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

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

1. สร้างโทเค็นแบบ Canonical ผ่านสะพานแบบ Rollup/Sidechain แบบดั้งเดิม
2. สร้างโทเค็นมาตรฐานผ่านผู้ให้บริการสะพานบุคคลที่สาม
3. สร้างโทเค็นแบบมาตรฐานผ่านสะพานระหว่างผู้ออกโทเค็น
4. การออกหลายโซ่โดยตรงพร้อมการแลกเปลี่ยนแบบอะตอม

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

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

1. สร้างโทเค็นมาตรฐานผ่านสะพานแบบม้วนมาตรฐาน/โซ่ข้าง

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

แม้ว่าสะพานแบบ canonical จะทำหน้าที่สร้างการแสดงแบบ canonical ของโทเค็น แต่การแสดงแบบอื่นๆ จะยังคงมีอยู่ต่อไป ซึ่งเกิดขึ้นเนื่องจากสะพานแบบ canonical มักมีข้อจำกัดที่ป้องกันไม่ให้มอบประสบการณ์ที่ดีที่สุดให้กับผู้ใช้ ตัวอย่างเช่น การเชื่อมต่อจาก Arbitrum/Optimism ไปยัง Ethereum ผ่านสะพานแบบ canonical ของ rollup จะมีการล่าช้าเจ็ดวัน เนื่องจากธุรกรรมจะต้องผ่านการตรวจสอบโดยผู้ตรวจสอบ และอาจโต้แย้งด้วย หลักฐานการฉ้อโกง หากไม่ถูกต้อง ก่อนที่เลเยอร์การชำระเงินของ rollup (Ethereum - ชำระเงินชุดธุรกรรม)

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

ไซด์เชนที่มีชุดตัวตรวจสอบอิสระจะมีความล่าช้าต่ำกว่า เนื่องจากการดำเนินการถอนเงินจะดำเนินการเมื่อโปรโตคอลฉันทามติของไซด์เชนยืนยันบล็อกที่มีธุรกรรมการถอนเงิน บริดจ์ Polygon PoS เป็นตัวอย่างของบริดจ์มาตรฐานที่เชื่อมต่อไซด์เชนกับโดเมนต่างๆ (รวมถึง Ethereum rollups และ Ethereum mainnet)

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

อย่างไรก็ตาม บริดจ์แบบไซด์เชนยังมีจุดอ่อนเหมือนกับบริดจ์แบบแคนนอนิคัลแบบโรลอัป นั่นคือ ผู้ใช้สามารถบริดจ์ได้ระหว่างเชนที่เชื่อมต่อกันเป็นคู่เท่านั้น ไม่สามารถบริดจ์ไปยังบล็อคเชนอื่น ๆ ได้โดยใช้บริดจ์แบบแคนนอนิคัล ตัวอย่างเช่น ในปัจจุบัน คุณไม่สามารถบริดจ์จาก Arbitrum ไปยัง Optimism ได้โดยใช้ Arbitrum Bridge หรือบริดจ์จาก Polygon ไปยัง Avalanche ผ่านบริดจ์ Polygon PoS

1.1. สร้างโทเค็นแบบ Canonical โดยใช้สะพานสภาพคล่อง

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

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

การแสดงแบบมาตรฐานของโทเค็นบนเครือข่ายปลายทางมักจะเป็นเวอร์ชันที่สร้างขึ้นโดยเครือข่ายย่อย/สะพานรวมแบบมาตรฐาน แม้ว่าจะมีข้อยกเว้นอยู่ (ตามที่เราจะเห็นในภายหลัง) ตัวอย่างเช่น เวอร์ชันมาตรฐานของ USDT บน Optimism คือ opUSDT ที่สร้างขึ้นโดย Optimism Bridge

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

สิ่งนี้คล้ายกับโมเดลของ Uniswap ความแตกต่างที่สังเกตเห็นได้เพียงอย่างเดียวคือคู่สินทรัพย์มักจะเป็นการแสดงสะพานสภาพคล่องของโทเค็นเทียบกับการแสดงแบบมาตรฐาน ตัวอย่างเช่น ผู้ใช้ที่เชื่อมต่อ USDT กับ Optimism ผ่าน Hop จะต้องสลับ hUSDT บน Optimism ผ่านพูล huSDT:opUSDT

เวิร์กโฟลว์สำหรับการเชื่อมโยงผ่านสะพานสภาพคล่องจะมีลักษณะดังนี้:

• ล็อคโทเค็นดั้งเดิมบนเชนแหล่งที่มา
• ตัวแทนสะพานมินต์ของโทเค็นดั้งเดิมบนเชนเป้าหมาย
• สลับการแสดงแบบบริดจ์กับการแสดงแบบแคนนอนิคัลบนเชนเป้าหมายผ่านพูล AMM
• ส่งโทเค็นมาตรฐานให้กับผู้ใช้

กระบวนการนี้คล้ายคลึงกันสำหรับสะพานสภาพคล่องทั้งหมด (Across, Celer, Hop, Stargate เป็นต้น) อย่างไรก็ตาม กระบวนการนี้มักจะถูกแยกออกจากผู้ใช้ปลายทาง โดยเฉพาะอย่างยิ่งโดยตัวแก้ปัญหา/ตัวเติม และจะรู้สึกเหมือนเป็นธุรกรรมเดียว แม้ว่าจะมีส่วนที่เคลื่อนไหวจำนวนมากก็ตาม

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

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

นอกจากนี้ Liquidity Bridge ยังช่วยให้ผู้ใช้สามารถย้ายระหว่างเชนต่างๆ ได้มากขึ้น ซึ่งต่างจาก canonical bridge ตัวอย่างเช่น Hop ช่วยให้ผู้ใช้ย้ายระหว่าง Arbitrum และ Optimism ได้โดยไม่ต้องถอนออกไปยัง Ethereum ก่อน เช่นเดียวกับ L2→L1 bridging ที่รวดเร็ว L2→L2 bridging ที่รวดเร็วนั้น Bonders ต้องรันโหนดเต็มสำหรับเชน L2 ต้นทางเพื่อยืนยันการถอนออกก่อนที่จะจ่ายค่าใช้จ่ายของการสร้างโทเค็นให้กับผู้ใช้ในเชน L2 ปลายทาง ซึ่งจะทำให้สามารถประกอบระหว่าง rollup ได้มากขึ้น และปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างมาก เนื่องจากผู้ใช้สามารถย้ายโทเค็นข้าม rollup ได้โดยไม่มีปัญหา

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

ข้อเสียของสะพานสภาพคล่อง

1. การลื่นไถล

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

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

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

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

2. ข้อจำกัดด้านสภาพคล่อง

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

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

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

3. แรงจูงใจที่ไม่สอดคล้องกัน

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

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

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

4. การเชื่อมโยง UX ไม่ดี

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

ผู้ใช้มีสองทางเลือกในสถานการณ์นี้ (ทั้งสองทางเลือกไม่เหมาะสม):

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

2. สร้างโทเค็นมาตรฐานผ่านสะพานบุคคลที่สามมาตรฐาน

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

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

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

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

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

• นักพัฒนาสามารถจัดการการใช้งานโทเค็นแบบหลายโซ่ให้กับตัวกลางโดยไม่ต้องกังวลเกี่ยวกับการจัดเตรียมสภาพคล่อง AMM หรือโปรแกรมจูงใจด้านการจัดหาสภาพคล่องด้วยตนเอง

  
  

ตัวอย่างบางส่วนของโทเค็นของผู้ให้บริการบริดจ์เดียวที่มีอยู่ทั่วไป ได้แก่ Omnichain Fungible Token (OFT) ของ LayerZero, Interchain Token Service (ITS) ของ Axelar, xAsset ของ Celer และ anyAsset ของ Multichain ตัวอย่างทั้งหมดเป็นโทเค็นที่เป็นกรรมสิทธิ์โดยพื้นฐานและเข้ากันไม่ได้กับการแสดงของโทเค็นเดียวกันที่ส่งผ่านผู้ให้บริการบริดจ์รายอื่น รายละเอียดที่ละเอียดอ่อนนี้เน้นถึงปัญหาบางประการเกี่ยวกับแนวทางนี้ในการจัดการโทเค็นบริดจ์ กล่าวคือ:

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

ข้อเสียของการใช้บริดจ์บุคคลที่สามแบบมาตรฐาน

1. การล็อคอินของผู้ขาย

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

เป็นไปได้ที่จะเปลี่ยนผู้ให้บริการสะพานเชื่อม แต่ค่าใช้จ่ายในการเปลี่ยนนั้นสูงพอที่จะทำให้โครงการส่วนใหญ่ไม่กล้าที่จะเลือกเส้นทางนี้ หากจะให้เห็นภาพคร่าวๆ สมมติว่านักพัฒนารายหนึ่ง (ซึ่งเราจะเรียกว่า Bob) ได้ออกโทเค็น (BobToken) บน Ethereum และเลือก LayerZero OFT เพื่อสร้าง BobToken เวอร์ชันมาตรฐานบน Optimism, Arbitrum และ Base BobToken มีอุปทานคงที่ที่ 1,000,000 โทเค็น และโทเค็นสะพานเชื่อมที่สร้างผ่าน LayerZero คิดเป็น 50% ของอุปทาน BobToken ทั้งหมดที่หมุนเวียนอยู่

การจัดการธุรกิจดำเนินไปอย่างราบรื่นจนกระทั่ง Bob ตัดสินใจว่าผู้ใช้จะดีกว่าหากเชื่อมโยง BobTokens ผ่านบริการสะพานที่แข่งขันกัน (เช่น Axelar) อย่างไรก็ตาม Bob ไม่สามารถพูดได้ง่ายๆ ว่า "ฉันกำลังเปลี่ยนไปใช้ Axelar ITS เพื่อสร้างการแสดงแบบแผนของ BobToken บน Optimism, Base และ Arbitrum" เนื่องจากโทเค็น OFT และโทเค็น ITS เข้ากันไม่ได้ Bob จึงเสี่ยงที่จะสร้างความปวดหัวให้กับทั้งผู้ใช้เก่าและผู้ใช้ใหม่ เนื่องจาก BobToken สองอันอาจใช้แทนกันไม่ได้ (ทำให้เกิดปัญหาที่เราอธิบายไว้ก่อนหน้านี้อีกครั้ง) ยิ่งไปกว่านั้น แอปพลิเคชันที่ผสานรวมกับ BobToken เวอร์ชันของ LayerZero ไม่สามารถยอมรับ BobToken เวอร์ชันของ Axelar เป็นตัวทดแทนได้ ซึ่งจะทำให้สภาพคล่องของ BobToken แตกกระจายบนเชนต่างๆ ที่มีการแสดง BobToken ที่แข่งขันกันอยู่ร่วมกัน

เพื่อให้การเปลี่ยนแปลงเป็นไปได้ Bob ต้องโน้มน้าวผู้ใช้ให้แกะการแสดงแทนของ BobToken ที่สร้างขึ้นผ่าน LayerZero โดยส่งธุรกรรมที่เผาโทเค็น OFT ที่เชื่อมโยงและปลดล็อก BobToken บน Ethereum ตอนนี้ผู้ใช้สามารถเปลี่ยนไปใช้การแสดงแทนแบบมาตรฐานใหม่ของ BobToken ได้โดยล็อกโทเค็นด้วย Axelar บน Ethereum และรับ BobToken แบบมาตรฐาน (ที่แมปกับอุปทานของสัญญาโทเค็นบน Ethereum) บนห่วงโซ่ปลายทาง วิธีนี้ทั้งมีค่าใช้จ่ายสูงและยังต้องประสานงานและดำเนินการเพิ่มเติมจำนวนมากสำหรับทีมจัดการโครงการ DAO ดังนั้นการยึดตามผู้ให้บริการที่เลือกจึงมักเป็นตัวเลือกที่ปลอดภัยที่สุด

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

2. การสูญเสียอำนาจอธิปไตยของพิธีสาร

ส่วนสรุปของหัวข้อก่อนหน้าเกี่ยวกับการผูกขาดของผู้ขายเน้นถึงปัญหาอีกประการหนึ่งในการใช้บริดจ์บุคคลที่สามตามหลักเกณฑ์: ผู้ให้บริการโทเค็นแลกเปลี่ยนการควบคุมโทเค็นที่บริดจ์ตามหลักเกณฑ์เพื่อแลกกับความสะดวกที่มากขึ้นและปรับปรุง UX ในการใช้ตัวอย่างก่อนหน้า: BobToken บน Ethereum อยู่ภายใต้การควบคุมของ Bob อย่างสมบูรณ์เนื่องจากเขาควบคุมสัญญาโทเค็น ERC-20 ที่เป็นพื้นฐาน แต่ BobToken บน Optimism, Arbitrum และ Base ถูกควบคุมโดย LayerZero ซึ่งเป็นเจ้าของสัญญา OFT ที่ออกการแสดงแทนตามหลักเกณฑ์ของ BobToken บนบล็อคเชนเหล่านั้น

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

3. มีความเสี่ยงสูงต่อการเสียหายของสะพาน

ในแนวทางแรก ซึ่งโทเค็นจะถูกเชื่อมโยงข้ามสายโซ่ผ่านสะพานมาตรฐานของแต่ละสายโซ่ ความเสี่ยงต่อผู้สร้างโทเค็นจากการโจมตีที่ส่งผลกระทบต่อสะพานหนึ่งจะถูกจำกัดไว้เฉพาะที่สะพานนั้น ตัวอย่างเช่น สมมติว่าแฮกเกอร์สามารถเจาะสะพานสภาพคล่องหนึ่งแห่งได้และสร้างโทเค็นที่ห่อหุ้มไว้จำนวนไม่จำกัดโดยไม่ต้องฝากหลักประกัน ในกรณีนั้น แฮกเกอร์สามารถถอนสภาพคล่องได้เพียงสูงสุดเท่าที่มีสำหรับสินทรัพย์ที่ห่อหุ้มไว้ในกลุ่มสภาพคล่องเท่านั้น (เช่น การสร้าง cUSDT บน Optimism → สวอป cUSDT สำหรับ opUSDT มาตรฐาน → ถอน opUSDT ไปยัง Ethereum ผ่านสะพานด่วน → แลกเปลี่ยนสำหรับ USDT ดั้งเดิมบน Ethereum)

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

สมมติว่าผู้โจมตีทำลายสะพานของบุคคลที่สามบนเชน B และสร้างโทเค็น 1,000 โทเค็น (ซึ่งโทเค็นจะถูกออกในตอนแรกบนเชน A) โดยไม่ได้ฝากหลักประกัน โทเค็นของผู้โจมตีบนเชน B ไม่ถูกแมปกับสัญญาเชนหลัก ดังนั้นจึงไม่สามารถถอนออกจากเชน A ได้ อย่างไรก็ตาม ผู้โจมตีสามารถเชื่อมต่อกับเชน C และแลกเปลี่ยนโทเค็นเชน B 1,000 โทเค็นเป็นเชน C 1,000 โทเค็นได้ โปรดจำไว้ว่าโทเค็นข้ามเชนแต่ละโทเค็นเข้ากันได้และแลกเปลี่ยนได้เนื่องจากมาจากบริการบริดจ์เดียวกัน โทเค็นเชน C ถูกแมปกับสัญญาเชนหลักเนื่องจากถูกสร้างอย่างถูกต้องโดยผู้ใช้ที่ล็อกโทเค็นบนเชน A (เชนหลักของโทเค็น) ทำให้ผู้โจมตีสามารถเผาโทเค็นบนเชน C และถอนโทเค็นดั้งเดิมบนเชน A และอาจทำแผนการเดินทางให้เสร็จสิ้นโดยการแลกเปลี่ยนโทเค็นผ่าน CEX หรือ fiat offramp

4. การสูญเสียคุณสมบัติโทเค็นที่กำหนดเอง

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

ฟีเจอร์โทเค็นทั่วไป เช่น การมอบสิทธิ์โหวต (ZK) กลไกการปรับฐานใหม่ (stETH, USDM) ความสามารถในการจ่ายค่าธรรมเนียมในการโอน (memecoins) ฟังก์ชันแบล็คลิสต์และไวท์ลิสต์ (USDT, USDC) การโอนที่หยุดชะงัก และกฎการสร้างหรือสิทธิ์พิเศษ มักจะถูกลบออกเมื่อโทเค็นถูกเชื่อมโยงผ่านผู้ให้บริการบุคคลที่สาม เนื่องจากเวอร์ชันที่เชื่อมโยงโดยทั่วไปจะใช้การใช้งาน ERC-20 ขั้นพื้นฐาน การสูญเสียฟังก์ชันนี้ทำให้เกิดความไม่สอดคล้องกันในวิธีการทำงานของโทเค็นในเชนต่างๆ และอาจทำลายการบูรณาการที่ขึ้นอยู่กับฟีเจอร์ที่กำหนดเองเหล่านี้ได้

การกำหนดมาตรฐานโทเค็นแบบบริดจ์นั้นแม้จะดูง่ายกว่าในมุมมองของผู้ให้บริการบริดจ์ แต่ก็ลดความสามารถของโทเค็นลงอย่างมีประสิทธิผล และอาจขัดขวางความสามารถของผู้ให้บริการในการรักษาพฤติกรรมโทเค็นที่สอดคล้องกันในระบบนิเวศแบบมัลติเชนทั้งหมดของแอปพลิเคชัน ปัญหาเหล่านี้อาจทำให้การขยายข้ามเชนกลายเป็นฝันร้ายสำหรับนักพัฒนา และเป็นอุปสรรคต่อการบรรลุความฝันของแอปที่อยู่บนเชนหลายเชน

5. โซ่รองรับที่จำกัด

ผู้ให้บริการโทเค็นจะต้องพึ่งพาแผนความครอบคลุมและการขยายเครือข่ายของผู้ให้บริการสะพานที่เลือก หากผู้ให้บริการสะพานไม่รองรับเครือข่ายบล็อคเชนเฉพาะที่ผู้ให้บริการโทเค็นต้องการขยายเครือข่าย พวกเขาจะต้องเผชิญกับทางเลือกที่ไม่เหมาะสมสองทาง:

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

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

6. ที่อยู่โทเค็นข้ามสายโซ่ที่ไม่สอดคล้องกัน

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

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

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

3. สร้างโทเค็นมาตรฐานผ่านสะพานผู้ออกโทเค็น

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

เพื่อให้แนวทางดังกล่าวทำงานได้ ผู้สร้างโทเค็นจะต้องตั้งค่าโครงสร้างพื้นฐานเพื่อจัดการการผลิตและการเผาโทเค็นที่เชื่อมโยงข้ามสายโซ่ (ขณะเดียวกันก็ต้องแน่ใจว่าอุปทานทั่วโลกยังคงซิงโครไนซ์กันผ่านการทำแผนที่แบบมาตรฐาน) ตัวอย่างที่โดดเด่นของการแสดงแบบมาตรฐานของโทเค็นที่ผู้สร้างโทเค็นออก ได้แก่ Teleport ของ MakerDAO และ Cross-Chain Transfer Protocol (CCTP) ของ Circle

Teleport ช่วยให้ผู้ใช้ย้าย DAI แบบมาตรฐานระหว่าง Ethereum และ Ethereum rollup ต่างๆ ผ่านการดำเนินการแบบ fast-path และ slow-path DAI จะถูกเบิร์นบนเชนเดียวและสร้างบนเชนเป้าหมาย CCTP ทำงานในลักษณะเดียวกันและเปิดใช้งานการโอน USDC ดั้งเดิมแบบข้ามเชน (ออกโดย Circle) ผ่านกลไกเบิร์นและมินต์ ในทั้งสองกรณี ผู้ออกโทเค็นจะควบคุมการสร้างและการเบิร์นการแสดงแบบมาตรฐานของโทเค็น

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

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

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

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

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

ความคิดสุดท้าย

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

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

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

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

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

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

โปรดติดตามต่อไป!