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

ความต้องการแนวทางที่ดีกว่า

จนถึงปัจจุบัน เราได้สำรวจวิธีการต่าง ๆ เพื่อแก้ปัญหาในการทำให้ bridged tokens เป็น fungible และแก้ปัญหาเกี่ยวกับการแยกแยะความสามารถในการเหลือเฟื้องและปัญหา UX จากการแสดงของ native token ที่เหมือน canonical บน non-native blockchains:

• สร้างส่วนแทนที่ถูกยอมรับของโทเค็นบนโซนระยะไกลผ่านสะพาน canonical rollup/sidechain ที่ถูกยอมรับ
• สร้างส่วนที่สร้างเสร็จสมบูรณ์ของโทเค็นบนเชนระยะไกลผ่านบริการสะพานบุคคลที่สาม
• สร้างการแสดงข้อมูลแบบแม่นยำของโทเค็นบนโซ่ระยะไกลผ่านบริการสะพานแบบแม่นยำที่ดำเนินการโดยผู้ออกโทเค็น

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

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

• ฟังก์ชันการทํางานสําหรับการสร้างและเบิร์นโทเค็น ERC-20 แบบบัญญัติ
• ความสามารถของเจ้าของโทเค็น

1) กำหนดผู้ดำเนินการสะพานให้เจริญและเผาเหรียญเมื่อมีการสะพานระหว่างเชน;

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

โดยมีความแตกต่างเล็กน้อยระหว่าง ERC-7281 และ ERC-20 tokens ผู้เขียน EIP ได้อธิบายว่า xERC-20 เพื่อผู้อ่านที่ต้องการภาพรวมของ ERC-20 tokens OpenZeppelin มีสิ่งที่ยอดเยี่ยมคู่มือเกี่ยวกับหัวข้อ.

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

คุณสมบัติพิเศษอันหนึ่งที่ ERC-7281 เพิ่มเข้าไปในข้อกำหนดของ ERC-20 คือ Lockbox ที่ทำหน้าที่เป็นสัญญา Wrapper (คล้ายกับสัญญา WETH (Wrapped Ether)) สัญญา Lockbox ห่อหุ้ม ERC-20 tokens เป็น xERC-20 tokens ผ่านกลไก mint-and-burn ที่คุ้นเคย และทำให้ ERC-7281 สามารถทำงานร่วมกับสัญญา ERC-20 ที่มีมาตรฐานที่ขาดหน้าจอ burn/mint และไม่สามารถอัพเกรดได้

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

ความแตกต่างที่ใหญ่ ซึ่งเราจะสำรวจในรายงานนี้ คือว่าผู้ออกโทเค็นสามารถปรับ Exposure เพื่อป้องกันการโจมตีและการลอกเซอร์โดยการกำหนดขีดจำกัดแบบไดนามิกว่าผู้ให้บริการสะพานเฉพาะบาลต้องการสามารถพิมพ์/เผาโดยจำกัดได้เท่าไหร่สำหรับโทเค็นที่เฉพาะบาล ERC-7281 ยังอนุญาตให้ผู้ออกโทเค็น whitelist ผู้ให้บริการสะพานหลายราย เพื่อพิมพ์โทเค็นที่เดียวกันที่สามารถทำงานได้ทั่วโลก ลดความพึงพอใจในผู้ให้บริการเดียวในการประมวลcross-chain bridging operations

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

ภาพรวมของ ERC-7281: โทเค็นที่เชื่อมต่อในรูปแบบของสุรญญา

การเผาและเหรียญสำหรับผู้ใช้

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

สำหรับ ERC-20 โทเคนที่มีอยู่แล้ว มีตรรกะ "lockbox" ที่ถูกนำมาใช้: ผู้ให้บริการสะพานจะห่อโทเคน ERC-20 ที่ผู้ใช้ฝากเข้ามาในรูปของ xERC-20 โดยการโอนไปยังสัญญา Lockbox จากนั้น Lockbox จะอนุญาตให้สะพานสร้าง xERC-20 โทเคนในปริมาณเท่ากัน

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

เพื่อสะพานโทเค็นกลับสู่เชนหลัก ผู้ดำเนินการสะพานจะเผา xERC-20 โทเคนบนเชนระยะไกล โดยให้ที่อยู่ของผู้ใช้และจํานวนโทเคน ใบเสร็จการเผาถูกส่งต่อไปยังเชนหลักโดยชั้นการขนส่ง หากข้อความการเผาได้รับการตรวจสอบ ผู้ดำเนินการสะพานจะสร้างและเผา xERC-20 โทเคนใหม่บนเชนหลักสําหรับผู้ใช้ หลังจากการตรวจสอบใบเสร็จการเผาโดยสัญญาโทเคน ผู้ดําเนินการสะพานจะปล่อยโทเคน ERC-20 ที่ฝากไว้ให้กับผู้ใช้ การเผา xERC-20 โทเคนบนเชนหลักจะลดจํานวนโทเคนทั้งหมดและขีดจํากัดการเผาของสะพาน

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

ขีดจำกัดอัตราการสร้างและทำลายโทเค็น

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

มีการระบุข้อกำหนด xERC-20 ที่รวมฟังก์ชันเพื่อตรวจสอบขอบเขตการเผาผลาญและการพิมพ์เหรียญสำหรับสะพานที่ได้รับการอนุมัติในการจัดการโทเคน คำสั่ง “mintingMaxLimitOf” จะคืนค่าจำนวนเงินสูงสุดที่สะพานสามารถพิมพ์ และตามคำสั่ง “burningMaxLimit” จะคืนค่าจำนวนเงินสูงสุดที่สะพานสามารถเผาผลาญในระยะเวลาที่ระบุ อย่างเสริมอีก ฟังก์ชันเหล่านี้ยังแสดงจำนวนเงินที่เหลืออยู่ที่สะพานสามารถเผาผลาญและพิมท์ก่อนที่จะถึงขีดจำกัดที่ตั้งไว้

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

พารามิเตอร์ขีดจํากัดอัตรา

มาตรฐานอินเทอร์เฟซโทเคน xERC-20 รวมถึง "Bridge" struct ที่มี "burningParams" และ "mintingParams" (พารามิเตอร์ของฟังก์ชัน rate limit ของโทเคน xERC-20 ควบคุมว่าสะพานสามารถเผาและผสมโทเคนได้เท่าไหร่ในระยะเวลาที่กำหนด). "maxLimit" กำหนดขีดจำกัดสูงสุดในการผสมและเผาโทเคนและเพิ่มขึ้นทุกวินาทีที่อัตราที่กำหนดไว้ ("ratePerSecond").

นี่คือจุดที่เราต้องการแจ้งให้ทราบเพื่อป้องกันความสับสน: “maxLimit” (ตั้งค่าสำหรับการเผาและขุด) ได้ยินมีเสียงเหมือนกับการจำกัดการขุดและการเผาบนช่วงเวลาที่เฉพาะเจาะจง—ไม่ใช่การจำกัดอัตราการเขุดและการเผาตามขอบเขตที่กำหนดล่วงหน้าระหว่างช่วงเวลาที่ตั้งไว้ล่วงหน้า “currentLimit” กำหนดว่าสะพานหนึ่งสามารถขุดหรือเผาเท่าใด และเพิ่มขึ้นตามอัตราที่กำหนดล่วงหน้า ในทวีความต่าง “maxLimit” กำหนดว่าสะพานหนึ่งสามารถขุดหรือเผาเท่าใดต่อวัน

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

xERC-20 Lockbox

โทเค็น ERC-20 ดั้งเดิมไม่ได้ระบุฟังก์ชันสําหรับการเพิ่มและลดอุปทานของโทเค็น (ย้อนกลับไปเมื่อ "tokenomics" หมายถึงการสร้างโทเค็นจํานวนคงที่และบอกผู้ใช้ว่าโทเค็นมีมูลค่าเนื่องจากจะหายากในอีกไม่กี่ปี*) ดังนั้นไม่ใช่ทุกโทเค็น ERC-20 ที่มีฟังก์ชั่นการสร้างและการเผาไหม้ เนื่องจาก ERC-7281 ใช้กลไก mint-and-burn ที่เป็นที่ชื่นชอบของบริดจ์ส่วนใหญ่ (ถ้าไม่ใช่ทั้งหมด) ในปัจจุบัน โทเค็น ERC-20 แบบเดิมหรือไม่สามารถอัปเกรดได้จึงไม่สามารถทํางานนอกกรอบด้วย ERC-7281 ได้

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

สัญญา Lockbox ยืมอย่างมากจากการออกแบบสัญญาห่อหุ้ม WETH ใช้ฟังก์ชัน deposit() เพื่อฝากโทเค็น ERC-20 ที่สอดคล้องกันใน Lockbox และฟังก์ชัน withdraw() สําหรับผู้ให้บริการบริดจ์เพื่อปลดล็อกโทเค็น ERC-20 หลังจากเบิร์นโทเค็นที่ห่อหุ้มบนโดเมนระยะไกล

ข้อผิดพลาดสองประเภทแรกที่ไฮไลต์ในข้อมูลจําเพาะ ("IXERC-20Lockbox_NotNative" และ "IXERC-20Lockbox_Native") เกิดขึ้นเมื่อผู้ใช้พยายามฝากโทเค็นในสัญญา Lockbox ที่ไม่ถูกต้อง Lockbox สามารถเป็นแบบเนทีฟหรือไม่ใช่แบบเนทีฟขึ้นอยู่กับประเภทของโทเค็นที่รองรับ

Native Lockboxes ดูแลโทเค็นดั้งเดิมนั่นคือโทเค็นที่ใช้ในการชําระค่าธรรมเนียมก๊าซให้กับผู้ตรวจสอบความถูกต้อง ตัวอย่างของโทเค็นที่จะมี Lockbox ดั้งเดิมสําหรับห่อเป็นโทเค็น xERC-20 คือ ETH: การตัด ETH ลงในโทเค็น xERC-20 จะต้องเรียกฟังก์ชัน depositNative() ของ Lockbox และฝาก ETH เพื่อรับการแสดง ETH ที่เข้ากันได้กับ ERC7281

Lockboxes ปกติ (ไม่ใช่เจ้าของภาษา) ดูแลโทเค็น ERC-20 เช่น USDC, DAI, WETH, USDT เป็นต้น ตัวอย่างเช่นในการสร้าง USDC เป็นโทเค็น xERC-20 ผู้ใช้จะเรียก deposit() ในสัญญา Lockbox หลังจากล็อค USDC

การเรียกเงินฝาก () กับ ETH จะส่งผลให้เงินเหล่านั้นถูกล็อคตลอดไปเนื่องจากสัญญา Lockbox ปกติสามารถห่อและแกะโทเค็น ERC-20 ได้เท่านั้น การเรียก depositNative() ด้วยโทเค็น ERC-20 จะให้ผลลัพธ์ที่คล้ายคลึงกันเนื่องจากสัญญา Lockbox ดั้งเดิมมีไว้เพื่อทํางานกับโทเค็นดั้งเดิมไม่ใช่โทเค็น ERC-20

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

สัญญาอะแดปเตอร์

ในกรณีที่โปรโตคอลการเชื่อมโยงไม่ได้ออกแบบมาเพื่อรับรู้การดําเนินการที่มีอยู่ในโทเค็น xERC-20 (mint / burn, การบันทึกที่สอดคล้องกันและอื่น ๆ ) แอปสามารถสร้างสัญญาอะแด็ปเตอร์ได้ สัญญาเหล่านี้ทําหน้าที่เป็นเครื่องห่ออัตโนมัติและเครื่องแกะ — แปลมาตรฐาน ERC-20 อนุมัติ + พฤติกรรมการโทรอย่างมีประสิทธิภาพเป็นรูปแบบ mint / burn ที่มีรายละเอียดปลีกย่อยมากขึ้นตามที่กําหนดโดย xERC-20

นี่เป็นเรื่องที่จำเป็นเพราะโปรโตคอลสะพานหลายตัว (เช่น CCIP ของ Chainlink) ยังคงถูกปรับให้เหมาะสมกับพฤติกรรม ERC-20 แบบดั้งเดิม สัญญาอะแดปเตอร์สามารถสะพาน (ba-dum-tss) ช่องโหว่ความเข้ากันได้นี้ได้โดยการฝากโทเคนเข้าไปยังกล่องล็อกเพื่อสร้าง xERC-20 บนเชนต้นทาง และภายหลังเมื่อได้รับข้อความบนเชนปลายทางแล้ว จะกระตุ้นกลไกการถอนเพื่อกลับสู่สินทรัพย์แบบปกติ

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

ทําไมต้อง ERC-7281? กรณีมาตรฐานโทเค็นเชื่อมอธิปไตย

ในระดับสูง ERC-7281 มีเป้าหมายกว้าง ๆ สี่ประการ:

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

วิสัยทัศน์เดิมในการสร้างข้อกำหนด ERC-20 คือการให้แน่นอนและการทำงานร่วมกันอย่างไม่มีรอยต่อระหว่างโทเคนบนเอเธอเรียมากับแอปพลิเคชันและโครงสร้าง Ethereum อย่างไม่มีรอยต่อ อย่างไรก็ตามหลังจากที่นำแผนการขยายของ rollup-centric เข้ามาใช้ ปัญหาของข้อจำกัดของ atomic composability ก็เกิดขึ้นและการสร้างโดเมนที่แตกต่างกันมากมายทำให้คุณสมบัติที่แน่นอนลดลง xERC-20 ช่วยให้สามารถรวบรวม Likuiditi จากสะพาน cross-rollup ต่างๆ เข้ามารวมอยู่ในโทเคน multi-rollup โดยสะท้อนวิสัยทัศน์เดิมของ Ethereum

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

2. Bootstrapping ที่ปราศจากสภาพคล่องสําหรับโทเค็นข้ามสายโซ่: โปรโตคอล DAOs ไม่ควรถูกบังคับให้ใช้ทรัพยากรที่สําคัญ (ทางการเงิน) ในการบูตสภาพคล่องสําหรับโทเค็นบริดจ์ซึ่งเป็นส่วนหนึ่งของแผนการขยายหลายสาย ไม่เพียง แต่การเชื่อมโยงตามสภาพคล่องไม่ดีสําหรับ UX แต่การใช้จ่ายในสิ่งจูงใจในการจัดหาสภาพคล่องอาจเป็นไปไม่ได้สําหรับทีมโครงการเนื่องจากจํานวนบล็อกเชนเพิ่มขึ้นในไม่ช้า

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

เราสามารถขยายขอบเขตของเป้าหมายเหล่านี้ได้เพิ่มเติมเพื่อดูว่า ERC-7281 มอบประโยชน์อย่างไรสำหรับโปรโตคอลและชุมชน

การวิเคราะห์ประโยชน์ของ ERC-7281

การปรับปรุง UX และกำจัดการแบ่งส่วนของ Likelihood

ERC-7281 แก้ปัญหาการพึ่งพาเส้นทางรุ่นต่างๆที่อธิบายไว้ในบทนํา

ความขึ้นอยู่กับเส้นทางสามารถเป็นพิเศษต่อเฉพาะโซน (เช่น ETH ที่ bridged มาจาก Ethereum → Arbitrum → Optimism แตกต่างจาก ETH ที่ bridged มาจาก Ethereum → Optimism → Arbitrum) หรือเป็นพิเศษต่อเฉพาะสะพาน (เช่น ETH ที่ bridged มาจาก Ethereum ไปยัง Optimism ผ่าน Celer แตกต่างจาก ETH ที่ bridged มาจาก Ethereum ไปยัง Optimism ผ่าน Connext)

การพึ่งพาเส้นทางเป็นคุณลักษณะด้านความปลอดภัยที่มีค่า แต่ก็อาจเป็นอันตรายต่อการเชื่อมโยง UX และความสามารถในการประกอบข้ามสายโซ่ ตัวอย่างเช่นผู้ใช้ไม่สามารถจัดหาสภาพคล่องโดยทางโปรแกรมให้กับ DEX ข้ามสายโซ่ที่ทํางานบน Optimism และ Arbitrum เนื่องจากแอปพลิเคชันต้องยอมรับ opETH หรือ arbETH

ERC-7281 ช่วยในการแก้ปัญหาโดยการนำเสนอ xERC-20 tokens ที่ยังคงสามารถแลกเปลี่ยนได้ไม่ว่าผู้ใช้จะทำการเชื่อมต่อไปยังโซนใดหรือผู้ให้บริการการเชื่อมต่อใด ๆ ที่ใช้ในการเชื่อมต่อ tokens สมมติว่าผู้ใช้ต้องการย้าย wrapped USDT จาก Arbitrum ไปยัง Optimism โดยที่ไม่ต้องถอนออกไปยัง Ethereum ก่อน ผู้ให้บริการการเชื่อมต่อสามารถเผา xERC-20 tokens บน Arbitrum และสร้าง xERC-20s บน Optimism - มูลค่าของ tokens ที่สร้างบน Optimism ยังคงเชื่อมโยงกับ tokens ที่ฝากไว้ใน Lockbox และถูกทำการรีแมพเพื่อรักษาการสนับสนุนอย่าง 1:1

ที่สําคัญ ERC-7281 ให้ประโยชน์ของการปรับใช้โทเค็นบริดจ์แบบบัญญัติเช่น CCTP (Cross-Chain Transfer Protocol) ของ Circle โดยไม่ต้องให้โปรโตคอลมีการดูแลโทเค็นบริดจ์แบบรวมศูนย์ ตัวอย่างเช่น สภาพคล่องจะถูกรวมไว้รอบๆ การแสดงโทเค็นของโครงการตามบัญญัติ ซึ่งช่วยปรับปรุงยูทิลิตี้โทเค็นสําหรับแอปพลิเคชัน DeFi และลดค่าใช้จ่ายในการสร้างตลาดที่แตกต่างกันสําหรับสินทรัพย์เดียวกันในเวอร์ชันต่างๆ

ส่งเสริมอํานาจอธิปไตยสําหรับผู้ออกโทเค็น

xERC-20s ถูกอธิบายว่าเป็น "โทเค็นที่เชื่อมอํานาจอธิปไตย" เนื่องจากผู้ออกโทเค็นไม่ได้ถูกล็อคให้ใช้ตัวเลือกเฉพาะสําหรับการสร้างการแสดงตามบัญญัติของโทเค็นและรักษาการควบคุมการออกแบบและการจัดการโทเค็นบริดจ์ในการปรับใช้ ERC-7281 เป็นลูกผสมระหว่าง "การสร้างโทเค็น Canonical ผ่านบริดจ์ของบุคคลที่สาม" และ "การสร้างโทเค็น Canonical ผ่านสะพานที่ควบคุมโดยผู้ออกโทเค็น" ที่รวมอํานาจอธิปไตยประสบการณ์ผู้ใช้และการกระจายอํานาจในแพ็คเกจเดียวกัน

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

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

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

Beefy ซึ่งเป็นโปรโตคอลการทําฟาร์มผลผลิตได้นํา xERC-20 มาใช้ด้วยเหตุผลนี้ ตามที่เอกสารบริดจ์ของโครงการอธิบายไว้ ERC-7281 ทําให้โครงการมีตัวเลือกเพิ่มเติมสําหรับการเชื่อมโยงโทเค็นซึ่งจําเป็นหลังจากพันธมิตรสะพานรายใหญ่ประสบปัญหาการแฮ็ก (ธีมที่คุ้นเคยกับชาว crypto อย่างรวดเร็ว) และให้การควบคุมการออกแบบกลไกการเชื่อมโยงอย่างละเอียดยิ่งขึ้น ในกรณีของ Beefy คุณสมบัติรายการอนุญาตของ ERC-7281 ทําให้โปรโตคอลสามารถเลือกพันธมิตรการเชื่อมโยงที่หลากหลายและเสนอตัวเลือกที่แตกต่างกันระหว่างการปรับให้เหมาะสมกับความเร็วการกระจายอํานาจค่าใช้จ่ายและความปลอดภัยเมื่อเชื่อมโยงโทเค็น mooBIFI

การปรับตัวให้สอดคล้องกับสิทธิและประโยชน์ที่ดีขึ้นเพิ่มความแข่งขันและความปลอดภัย

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

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

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

การจัดการความเสี่ยงที่ดีขึ้นสําหรับผู้ออกโทเค็น

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

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

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

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

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

ปรับปรุงความสามารถในการทํางานร่วมกันระหว่างระบบนิเวศ

การสร้างเวิร์กโฟลว์แอปพลิเคชันที่ซับซ้อนซึ่งต้องใช้โทเค็นการกําหนดเส้นทางผ่านโซ่จํานวนเท่าใดก็ได้เป็นเรื่องยากในปัจจุบันเนื่องจากการกําหนดราคาที่คาดเดาไม่ได้ของบริดจ์ที่ใช้สภาพคล่อง ตัวอย่างเช่นตัวรวบรวมสะพานที่เชื่อมจาก Ethereum → Linea → Base มีสองตัวเลือก:

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

ในการเปรียบเทียบผู้รวบรวมบริดจ์สามารถทราบจํานวนโทเค็นที่พวกเขาควรคาดหวังล่วงหน้าในแต่ละโดเมนที่เกี่ยวข้องกับการทําธุรกรรมข้ามสายโซ่โดยการตรวจสอบ mintingLimit และ burningLimit สําหรับสะพานที่ได้รับอนุญาตให้สร้างโทเค็นเฉพาะ เป็นที่ยอมรับว่าบริดจ์สามารถกด maxLimit ระหว่างเวลาที่ออกอากาศธุรกรรมและธุรกรรมที่เข้าถึงโดเมนซึ่งหมายความว่าผู้ใช้ไม่สามารถรับโทเค็น Canonical ที่ปลายทางได้

อย่างไรก็ตาม, ERC-7281 ยังคงเป็นการปรับปรุงในเรื่องนี้เหตุผลดังต่อไปนี้:

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

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

เนื่องจากการสะพาน xERC-20 ไม่ได้เป็นเรื่องของการเคลื่อนไหว Likuidity ผู้ใช้สามารถมั่นใจได้ว่าการซื้อขาย cross-chain จะไม่เกิด Slippage แม้ว่าจะไม่ทำการดำเนินการทันที

ผู้รวบรวมการเชื่อมโยงไม่ใช่คนเดียวที่ได้รับประโยชน์จากการปรับปรุงความสามารถในการประกอบนี้ แอปพลิเคชันข้ามสายสัมพันธ์ใด ๆ สามารถควบคุมความสามารถในการฆ่าเชื้อราของโทเค็น xERC-20 เพื่อสร้างแอปพลิเคชันที่น่าตื่นเต้นยิ่งขึ้น วันนี้ยากขึ้นเนื่องจากปัญหาเกี่ยวกับการพึ่งพาเส้นทาง: สมมติว่านักพัฒนาต้องการเชื่อมโยง ETH จาก Ethereum เปิดตําแหน่งการให้กู้ยืมใน Arbitrum DEX และใช้ผลกําไรเพื่อซื้อ NFT บน Optimism ก่อนที่จะเชื่อมโยงกลับไปที่ Ethereum ที่นี่นักพัฒนาต้องตรวจสอบให้แน่ใจว่าได้รวมเข้ากับผู้ให้บริการบริดจ์ในเครือข่ายเหล่านั้นเนื่องจากคุณไม่สามารถสลับเวอร์ชันที่เป็นกรรมสิทธิ์ได้อย่างง่ายดายซึ่งไม่เป็นเช่นนั้นเมื่อโทเค็นบริดจ์ของโครงการสามารถเปลี่ยนได้หลังจากใช้ xERC-20

เวิร์กโฟลว์นี้คล้ายกับบริดจ์ผู้ออกโทเค็นที่อธิบายไว้ก่อนหน้านี้ ลองใช้ Circle CCTP เป็นตัวอย่าง:

Cross-Chain Transfer Protocol ของ Circle ช่วยให้ผู้ใช้มีโทเค็น USDC เวอร์ชันมาตรฐานที่เป็นหนึ่งเดียวโดยไม่ต้องติดอยู่ในระบบนิเวศของเชน การถ่ายโอนข้ามสายโซ่ทั้งหมดจะถูกประมวลผลผ่านโปรโตคอลโดยใช้รูปแบบการเผาไหม้และเหรียญกษาปณ์

อย่างไรก็ตาม ในขณะที่ CCTP เป็นโปรโตคอลแบบศูนย์กลาง โดยที่ผู้ดำเนินการของ Circle เท่านั้นที่ได้รับอนุญาตให้ทำการเผาและสร้างเหรียญ USDC xERC-20 จะลดความเสี่ยงที่เกี่ยวกับความน่าเชื่อถือโดยการอนุญาตให้หลายหน่วยงานที่มีกลไกการรักษาความปลอดภัยต่าง ๆ ทำการดำเนินการถ่ายโอน cross-chain

สนับสนุนวิสัยทัศน์ของ Ethereum เกี่ยวกับอนาคตแบบมัลติเชนที่เน้นการสะสม

ERC-7281 สามารถเร่งแผนงานที่เน้นการรวบรวมของ Ethereum โดยให้โครงการมีความมั่นใจในการปรับใช้โทเค็นบน EVM L2 ใหม่ที่อาจขาดโปรไฟล์ความปลอดภัยที่แข็งแกร่งของเครือข่าย L2 ที่จัดตั้งขึ้น ตัวอย่างเช่นสะพานบัญญัติของโรลอัพขั้นที่ 0 มีความปลอดภัยน้อยกว่าเนื่องจาก Ethereum L1 ไม่รับประกันความปลอดภัยของสะพาน โครงการโทเค็นสามารถทยอยเปิดตัวไปยังห่วงโซ่ดังกล่าวโดยให้สิทธิ์การทําเหรียญที่ จํากัด แก่สะพานบัญญัติและเพิ่มขีด จํากัด การทําเหรียญเมื่อการสะสมก้าวไปสู่ขั้นตอนที่ 1

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

ข้อเสียที่อาจเกิดขึ้นจากการใช้ ERC-7281

ค่าใช้จ่ายเพิ่มขึ้นสำหรับทีมจัดการโครงการ DAO

ในขณะที่ ERC-7281 มีความน่าสนใจมากสำหรับโปรโตคอล DAOs อาจลังเลที่จะนำ xERC-20 tokens เข้ามาเนื่องจากภาระงานด้านดำเนินการที่สำคัญที่ทีมโครงการ DAO จะต้องรับผิดชอบในการจัดการ xERC-20 tokens บนการใช้งานต่างๆ

Gerard Persoon’s จัดการโทเค็นบริดจ์บนเชนจํานวนมากรวมถึงรายการที่ไม่สมบูรณ์ของงานที่ต้องทำครั้งเดียวและที่เกิดซ้ำ ที่โปรโตคอลต้องดำเนินการหลังจากที่โยกย้ายจาก ERC-20 เป็น xERC-20:

นั้นคือรายการงานที่ยาวมาก

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

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

ตัวอย่างเช่น สมาชิกในทีมคอร์ Lido โครงการ (เพื่อตอบสนองต่อข้อเสนอสําหรับ Lido ในการปรับใช้ wstETH เป็นโทเค็น xERC-20 ในการปรับใช้ทั้งหมด) ความรับผิดชอบในปัจจุบันของทีม PM ที่เกี่ยวข้องกับโครงสร้างพื้นฐานการทํางานร่วมกันและเปรียบเทียบชุดกับชุดความรับผิดชอบที่สมาชิกในทีมคนเดียวกันจะต้องสันนิษฐานหาก Lido DAO ลงมติให้ wstETH ในทุกโดเมนย้ายไปยังเวอร์ชัน xERC-20

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

สิ่งนี้ไม่ควรตีความว่าเป็นการตัดสินคุณค่าบน ERC-7281 อย่างไรก็ตาม แต่ละโครงการจะมีโปรไฟล์ความเสี่ยงเป้าหมายระยะยาวและทรัพยากรที่แตกต่างกันและปัจจัยเหล่านี้รวมกันเป็นตัวกําหนดว่าผลประโยชน์ระยะยาวของการนํา ERC-7281 มาใช้มีมากกว่าต้นทุนระยะสั้นและต่อเนื่องในการทําเช่นนั้นหรือไม่

ตัวอย่างเช่น โครงการขนาดเล็กอาจพบว่าการจัดการค่าใช้จ่ายในการออกโทเค็น xERC-20 ทําได้ยากขึ้น และเลือกที่จะเลือกใช้บริการเชื่อมต่อโทเค็นแบบมัลติเชนที่มีการจัดการ เช่น ITS (Interchain Token Service) ของ Axelar หรือ NTT (Native Token Transfers) ของ Wormhole โครงการที่จัดตั้งขึ้นอาจมีทรัพยากรในการจัดการค่าใช้จ่ายในการบริหารและการดําเนินงานของการออกโทเค็น xERC-20 และอาจพิจารณาการควบคุมที่ ERC-7281 จ่ายให้คุ้มค่ากับค่าใช้จ่ายเพิ่มเติมของการจัดการโทเค็นข้ามสายโซ่

ความยากลําบากในการโยกย้ายโทเค็นที่มีอยู่ไปยังมาตรฐาน xERC-20

สําหรับโครงการที่ไม่มีอินเทอร์เฟซ mint/burn หรือไม่สามารถอัปเกรดสัญญาโทเค็นเพื่อใช้ IERC20 ผ่านการสืบทอดและมีการแสดงโทเค็นดั้งเดิมที่หมุนเวียนบนเชนที่ไม่ใช่เนทีฟอยู่แล้วการย้ายไปยังโทเค็น xERC-20 เป็นกระบวนการที่ยาวนานซึ่งต้องการการประสานงานอย่างมากและเกี่ยวข้องกับเว็บที่ซับซ้อนของผู้เข้าร่วมตั้งแต่ผู้ถือโทเค็น การแลกเปลี่ยน (DEXes และ CEXes) บริดจ์พันธมิตร และแอปพลิเคชันที่รวมเข้ากับโทเค็น ERC-20 ดั้งเดิม แม้จะมีการจัดการส่วนนี้โปรโตคอลยังคงแบกรับค่าใช้จ่ายในการแกะ ERC-20s ออกเป็น xERC-20s เพื่อให้กระบวนการย้ายข้อมูลเสร็จสมบูรณ์

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

พื้นผิวความเสี่ยงที่ใหญ่ขึ้นสําหรับการกํากับดูแล DAO

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

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

ตัวอย่างเช่นโครงการที่มีชื่อเสียงเช่น Lido ถูกตรวจสอบเกี่ยวกับปัญหาการบริหารจัดการ เพิ่มการควบคุมที่เกี่ยวกับการจัดการโทเค็น จะเพิ่มความเสี่ยงของการเข้าครองการบริหาร การโจมตีการบริหารอาจมีผลกระทบทั่วไปหากโครงการรวมโทเค็น ERC-20 ทั้งหมดเข้าไปใน Lockbox และ DAO ควบคุมมัน ผู้โจมตีอาจได้รับควบคุมของ Lockbox และนำเสนอผู้ให้บริการสะพานที่ไม่เป็นมลที่น่าเชื่อถือ ทำให้โทเค็น xERC-20 บนเครือสายอื่นเป็นค่าเป็นศูนย์

สถานการณ์นี้มีความคล้ายคลึงกับการหาประโยชน์จาก Multichain ซึ่งช่องโหว่ในโครงสร้างพื้นฐานการลงนามแบบหลายฝ่าย (MPC) อนุญาตให้แฮกเกอร์ประนีประนอมที่อยู่ Multichain หลักที่ดูแลโทเค็นดั้งเดิมบน Ethereum และ Dogecoin โทเค็นเหล่านี้สนับสนุนโทเค็นที่สร้างขึ้นบนเชนที่ไม่ใช่เนทีฟ เช่น Fantom และ Moonriver ซึ่งสร้างเอฟเฟกต์โดมิโนที่ส่งผลให้โครงการอื่นๆ ประสบความสูญเสียอันเป็นผลมาจากการโจมตีสัญญาอัจฉริยะของ Multichain บน Ethereum และ โดเกคอยน์

ความไม่ลงรอยกันกับโปรโตคอลการกระจายอํานาจสูงสุด

ERC-7281 เหมาะกับวัตถุประสงค์เมื่อโทเค็นออกโดยโปรโตคอลที่มีการกํากับดูแลโทเค็นหรือเอนทิตีแบบรวมศูนย์ (เช่น USDC ของ Circle หรือ CZKC Stablecoin). อย่างไรก็ตาม มันไม่มีค่าเท่าหากโปรโตคอลมีการกระจายอํานาจสูงสุดและขาดการกํากับดูแลอย่างเป็นทางการ—Liquity's LUSD stablecoin เป็นตัวอย่างของโทเค็นที่ยากต่อการเข้ากันได้กับมาตรฐาน xERC-20

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

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

เราได้กล่าวไปแล้วว่าการพึ่งพาเส้นทางทํางานอย่างไรและเหตุใดจึงช่วยรับประกันว่าการหาประโยชน์ที่มีผลต่อห่วงโซ่ A จะไม่ส่งผลกระทบต่อห่วงโซ่ B หรือการหาประโยชน์ที่เกี่ยวข้องกับสะพาน A บนโซ่ A จะไม่ส่งผลกระทบต่อสะพาน B บนโซ่ B ERC-7281 จะลบการพึ่งพาเส้นทางซึ่งมีประโยชน์ แต่ยังแนะนําการแลกเปลี่ยนเกี่ยวกับความปลอดภัย:

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

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

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

ค่าใช้จ่ายสําหรับการผสานรวมระบบนิเวศ

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

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

สรุป

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

ผู้เล่นหลักหลายรายในพื้นที่เชื่อมโยงรวมถึง Hyperlane, Omni, Sygma, Router Protocol และ Everclear ได้มุ่งมั่นที่จะนํา ERC-7281 มาใช้ซึ่งบ่งบอกถึงแรงฉุดที่สําคัญสําหรับข้อเสนอนี้ แม้แต่ผู้ออกโทเค็นที่จัดตั้งขึ้น (ซึ่งมีกลไกการทํางานสําหรับการเชื่อมโยงโทเค็น) เช่น Circle ก็แสดงความสนใจใน ERC-7281 เพื่อจัดการกับความท้าทายที่เกิดจากโทเค็นที่ไม่ได้รับการอนุมัติซึ่งส่งผลกระทบต่อผู้ใช้และนักพัฒนา

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

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

ปฏิเสธ:

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