Được viết bởi: Alex Hook, Emmanuel Awosika
Biên soạn bởi: Glendon, Techub News
Báo cáo này được chia thành hai phần. Phần 1 phác thảo những thách thức phải đối mặt trong lĩnh vực chuỗi Chuỗi , chẳng hạn như vấn Chuỗi không thể thay thế của token Chuỗi chéo và phân tích các giải pháp chính hiện tại; tiêu chuẩn token ERC-7281, đồng thời phân tích các lợi ích và hạn chế tiềm ẩn khi triển khai ERC-7281 cho người dùng, nhà phát triển, nhà cung cấp cơ sở hạ tầng và những người tham gia khác trong hệ sinh thái Ethereum .
Hiện tại, hoạt động xuyên Chuỗi vẫn gặp nhiều thách thức do những hạn chế cố hữu của phương pháp tương tác blockchain như cầu nối xuyên chuỗi . Ví dụ: cầu nối xuyên chuỗi có thể tiềm ẩn rủi ro về bảo mật (các cuộc tấn công chuỗi Chuỗi hacker đã gây thiệt hại hơn 2,5 tỷ USD) hoặc chúng có thể chậm và tốn kém cũng như có chức năng hạn chế. Hơn nữa, các vấn đề trên có thể tồn tại trong cùng một cầu nối xuyên chuỗi vào cùng một thời điểm.
Ngoài ra, còn có một vấn đề cốt lõi trong lĩnh vực Chuỗi chéo: khi token có thể hoán đổi cho nhau (chẳng hạn như token tiêu chuẩn ERC-20) được Chuỗi chéo với Chuỗi khác nhau thông qua các giao thức chuỗi Chuỗi khác nhau, các token này sẽ trở nên không thể thay thế được. token, do đó mất đi chức năng của chúng như một tài sản có thể chuyển nhượng . Trong bài viết này, chúng ta sẽ khám phá một giải pháp được thiết kế để đảm bảo khả năng thay thế token token trên Chuỗi , bất kể hợp đồng ban đầu của nó tồn tại ở đâu: Tiêu chuẩn token Chuỗi chéo có chủ quyền ERC-7281.
ERC-7281 (còn được gọi là xERC-20) là mở rộng của ERC-20, một tiêu chuẩn để tạo token có thể thay thế trên Ethereum . ERC-7281 cho phép nhiều cầu nối được nhà phát hành token phê duyệt để đúc và đốt các phiên bản token thông báo tiêu chuẩn của token ERC-20 trên Chuỗi từ xa, đảm bảo rằng người dùng nhận được phiên bản chính xác của mã thông báo tại đích khi kết nối token. phiên bản của token(tức là hai token có thể được trao đổi 1:1), ngay cả khi mã token được gửi qua Chuỗi thông qua các đường dẫn/cầu nối khác nhau.
Điều quan trọng là giao thức áp dụng ERC-7281 có thể duy trì quyền kiểm soát token chuỗi Chuỗi (không giống như cầu nối hiện tại kiểm soát trạng thái của token chuỗi Chuỗi ) và có thể hạn chế tốc độ hoạt động đúc, do đó giảm nguy cơ hỏng cầu nối xuyên chuỗi. rủi ro .
Lấy USDC làm ví dụ, chúng ta có thể thấy rằng về mặt lý thuyết, token ERC-20 giống nhau trên Chuỗi khác nhau không thể thay thế cho nhau. Trong các mạng Ethereum L2 (ví dụ: Arbitrum, Base, Optimism), Canonical Bridge thường được sử dụng để chuyển token ERC-20 phổ biến từ Ethereum L1 sang Chuỗi này. Token L2 này có nguồn gốc từ L1 thường được gọi là "Chuỗi chéo [chèn tên token]".
Đối với USDC, các ký hiệu token phổ biến là USDC.e, USDC.b, v.v. Mặc dù hai token đúc bởi cùng một thực thể và có cùng mức giá, nhưng chúng khác nhau về mặt kỹ thuật, token không thể thay thế và do đó không "có thể tương tác" - mặc dù USDC gốc có thể được trao đổi thông qua Giao thức chuyển Chuỗi vòng tròn (CCTP) được sử dụng để trao đổi chéo. - Chuỗi, nhưng USDC chuỗi Chuỗi chỉ có thể xuyên Chuỗi trở lại L1 thông qua một cây cầu tiêu chuẩn.
ERC-7281 giải quyết vấn đề này bằng cách giới thiệu tiện mở rộng ERC-20, trong đó người triển khai token có thể chỉ định và tham số hóa các nguồn gốc chuỗi Chuỗi khác nhau cho nó. Trong ví dụ trên, Circle có thể triển khai mã token USDC phổ quát trên tất cả các L2 trong đó cầu nối xuyên chuỗi tiêu chuẩn (chẳng hạn như Circle Mint, Circle CCTP và cầu nối xuyên chuỗi được phê duyệt khác) được chỉ định để có thể đúc token theo logic của chúng . Để giảm thiểu rủi ro đúc bị hacker , người triển khai có thể giới hạn số lượng token mà mỗi đúc có thể đúc và đốt trong một khoảng thời gian cụ thể - đối với cầu nối xuyên chuỗi đáng tin cậy hơn (chẳng hạn như Cầu nối xuyên chuỗi L2 tiêu chuẩn), có thể có giới hạn cao hơn được thiết lập và đối với các cầu nối có sự đồng thuận tập trung, có thể đặt giới hạn thấp hơn.
Mặc dù ERC-7281 không phải là nỗ lực đầu tiên nhằm tạo ra giải pháp cho token chuỗi Chuỗi có thể thay thế được, nhưng nó có thể giải quyết các vấn đề tồn tại trong các chuỗi Chuỗi, chẳng hạn như khóa nhà cung cấp, mất chủ quyền của nhà phát hành token và liên kết chéo. thanh khoản hướng dẫn token Chuỗi Chi phí cao hơn, chi phí cơ sở hạ tầng tăng lên và rủi ro xảy ra lỗi xuyên Chuỗi tăng lên.
Tổng quan về cơ chế cầu nối xuyên chuỗi
Trước khi đi sâu vào vấn đề về token chuỗi Chuỗi không thể thay thế, chúng ta cần hiểu tại sao token chuỗi Chuỗi tồn tại. Do đó, chúng ta cũng cần hiểu động cơ và cơ chế vận hành của cầu nối xuyên chuỗi- bởi vì cầu nối xuyên chuỗi cung cấp người bán là bên chịu trách nhiệm tạo các phiên bản token Chuỗi chéo.
Cơ chế Chuỗi chéo là một phương tiện truyền thông tin giữa blockchain. Ngoài thông tin tiền tệ thuần túy, cầu nối xuyên chuỗi cũng có thể truyền bất kỳ thông tin hữu ích nào khác, chẳng hạn như tỷ giá hối đoái mã token và trạng thái hợp đồng thông minh trên Chuỗi khác. Tuy nhiên, việc chuyển tài sản(token ) từ Chuỗi này sang Chuỗi chắc chắn là trường hợp sử dụng phổ biến nhất đối với các cầu nối hiện đang tương tác với người dùng.
Phương pháp tạo điều kiện thuận lợi cho việc chuyển tài sản xuyên Chuỗi khác nhau, nhưng quy trình làm việc của token Chuỗi tuân theo một trong ba mẫu cấp cao:
Cầu khóa và cầu bạc hà
Người dùng muốn chuỗi Chuỗi token trên Chuỗi gốc của họ hoặc "Chuỗi nguồn" (Chuỗi được phát hành ban đầu) sang Chuỗi khác. Do mỗi Chuỗi triển khai các thiết kế giao thức và kiến trúc khác nhau nên hai blockchain không tương thích, điều này ngăn người dùng chuyển trực tiếp token từ địa chỉ ví của Chuỗi A sang địa chỉ ví của Chuỗi B.
Nhà cung cấp cầu nối xuyên chuỗi lưu trữ token của người dùng được lưu trữ trên Chuỗi gốc trong hợp đồng thông minh và tạo phiên bản token "được bao bọc" của Token gốc thông qua hợp đồng token được triển khai trên Chuỗi mục tiêu.
Khi người dùng muốn đảo ngược chuỗi Chuỗi(Chuỗi mục tiêu → Chuỗi gốc ), họ sẽ trả lại token được bọc cho cầu nối xuyên chuỗi trên Chuỗi mục tiêu và Chuỗi mục tiêu sẽ tuân theo logic trong cầu nối xuyên chuỗi(chẳng hạn như Bằng chứng không tri thức hoặc trọng tài bên ngoài) Điều này được xác minh và Token gốc .
Đốt và cầu Mint
Thay vì khóa token trong ký quỹ, phương pháp này đốt token trên Chuỗi nguồn;
Cầu nối xuyên chuỗi sẽ đúc số lượng token bằng nhau trên Chuỗi mục tiêu;
Đối với chuyển khoản ngược, token chuỗi Chuỗi sẽ đốt trên Chuỗi mục tiêu và token mới đúc trên Chuỗi nguồn;
Điều này cho phép chuyển Chuỗi chéo trong khi vẫn duy trì tổng lượng cung ứng token .
Hoán đổi nguyên tử nguyên tử
Hoán đổi nguyên tử mở khóa các khoản tiền có cùng giá trị riêng bằng cách khóa chúng với nhau, nghĩa là nếu bí mật của một trong hai bên bị rò rỉ thì bí mật của bên kia cũng vậy. Điều này mang lại cho sự trao đổi tính chất nguyên tử.
Tính nguyên tử có nghĩa là việc trao đổi hoàn tất hoàn toàn (ở cả hai bên) hoặc hoàn toàn không hoàn thành, do đó ngăn chặn việc chuyển tiền gian lận hoặc một phần/thất bại.
Trong số phương pháp trên, phương pháp đầu tiên (khóa và đúc) hiện là phương pháp phổ biến nhất. Giá trị tương đương giữa Token gốc và token được bao bọc tương ứng đúc bởi cầu nối cho phép người dùng " Chuỗi chéo"tài sản và sử dụng token trên một Chuỗi khác với Chuỗi mà chúng được phát hành ban đầu.
Tuy nhiên, các thiết kế mới như cầu nối xuyên chuỗi dựa trên mục đích đã trở nên rất phổ biến. “Ý định” cho phép người dùng thể hiện kết quả mong muốn của một giao dịch (đổi 100 USDC lấy 100 Dai), thay vì phác thảo các bước cụ thể để đạt được kết quả. Ý định đã trở thành một công cụ mở khóa trải nghiệm người dùng mạnh mẽ vì chúng đơn giản hóa đáng kể trải nghiệm trên Chuỗi của mọi người và làm cho crypto dễ sử dụng hơn, đặc biệt là khi kết hợp với các giải pháp trừu tượng hóa Chuỗi .
Mục đích chuỗi Chuỗi cho phép người dùng chuyển token giữa Chuỗi mà không phải lo lắng về sự phức tạp cơ bản của cầu nối xuyên chuỗi. Trong cầu nối xuyên chuỗi dựa trên mục đích, người dùng gửi tiền vào Chuỗi nguồn và chỉ định kết quả mong muốn của họ trên Chuỗi mục tiêu (tức là “ý định” của họ). Các nhà khai thác chuyên nghiệp được gọi là Người bổ sung hoặc Người giải quyết có thể thực hiện việc này bằng cách gửi trước token được yêu cầu cho người dùng trên Chuỗi mục tiêu. Sau đó, nhà điều hành chứng minh rằng việc chuyển tiền đã diễn ra để yêu cầu bồi thường số tiền bị khóa trên Chuỗi nguồn.
Một số cầu nối xuyên chuỗi dựa trên mục đích sử dụng cơ chế khóa và đúc bên trong. Trong trường hợp này, token được bao bọc đúc cầu nối xuyên chuỗi và token này sẽ được gửi đến một trình bổ sung đáp ứng ý định của người dùng hoặc trực tiếp đến người dùng (nếu không có trình bổ sung nào can thiệp). Tuy nhiên, cầu nối xuyên chuỗi dựa trên mục đích bổ sung thêm một lớp hiệu quả thông qua mạng bộ giải của chúng, nhưng về cơ bản chúng vẫn dựa trên các nguyên tắc giống như các cầu nối khóa và đúc truyền thống.
Chúng ta có thể coi mỗi token được gói (dù được tạo thông qua cầu nối xuyên chuỗi truyền thống hay cầu nối xuyên chuỗi dựa trên mục đích) là một "IOU" do nhà cung cấp cầu nối xuyên chuỗi phát hành, hứa hẹn sẽ phát hành một số lượng Token gốc nhất định từ hợp đồng ký quỹ. Giá trị của tài sản được bao bọc này liên quan trực tiếp đến khả năng (được cảm nhận) của nhà cung cấp cầu nối xuyên chuỗi trong việc xử lý các yêu cầu rút tiền từ người nắm giữ mã token quỹ trên chuỗi Chuỗi .
Cầu nối xuyên chuỗi được ủy quyền để khóa Token gốc trên Chuỗi nguồn và đúc token được bao bọc của chúng trên Chuỗi mục tiêu đảm bảo rằng tổng lượng cung ứng token không thay đổi. Đối với một đơn vị Token gốc , chính xác một đơn vị token được gói tương ứng đúc và ngược lại. Nếu một ứng dụng chấp nhận token được bao bọc làm phương tiện trao đổi hoặc sử dụng tài sản được bao bọc làm tiền tệ thì nhà phát triển và người dùng ứng dụng đó có đủ niềm tin vào nhà cung cấp cầu nối xuyên chuỗi để hỗ trợ bảo mật tài sản "thực" của token được bao bọc.
Tại sao cần có cầu nối xuyên chuỗi ?
Bằng cách tạo token chuỗi Chuỗi , cầu nối xuyên chuỗi có thể giao dịch với các phiên bản tài sản tổng hợp trên Chuỗi từ xa, một tính năng mạnh mẽ cho phép cả nhà phát triển và người dùng tận dụng khả năng tương tác chuỗi Chuỗi. Những lợi thế này bao gồm tăng thanh khoản hơn, thu hút người dùng mới và mang lại sự linh hoạt cho người dùng (người dùng có thể tương tác với các ứng dụng từ Chuỗi khác nhau mà không gặp trở ngại).
Để hiểu rõ hơn cách thức hoạt động của điều này trong thực tế và tại sao nó lại quan trọng đối với cả nhà phát triển và người dùng, hãy lấy một sàn giao dịch phi tập trung hư cấu có tên “BobDEX” làm ví dụ. Ví dụ này sẽ chứng minh cách token được bao bọc có thể mở rộng trên Chuỗi , đồng thời nêu bật những lợi ích và sự phức tạp tiềm ẩn có thể phát sinh:
BobDEX là sàn giao dịch nhà tạo lập thị trường tự động (AMM) do Bob tạo ra trên Ethereum , nhằm mục đích đạt được sự trao đổi không cần sự tin cậy giữa tài sản khác nhau. BobDEX có mã Token gốc BOB, vừa là token quản trị vừa là token phần thưởng nhà cung cấp thanh khoản(NHÀ CUNG CẤP THANH KHOẢN ). Trong trường hợp thứ hai, BobDEX phát hành token BOB cho NHÀ CUNG CẤP THANH KHOẢN , cho phép người dùng cung cấp thanh khoản cho nhóm nhận được một phần (được tính bằng phần trăm) phí mà người dùng DEX phải trả để trao đổi tài sản được lưu trữ trong nhóm.
Nhưng khi thị thị phần của BobDEX tăng trưởng mạnh mẽ, những hạn chế của L1 của Ethereum đã cản trở tăng trưởng hơn nữa của nó . Ví dụ: một số người dùng không muốn sử dụng BobDEX trên Ethereum do phí gas cao và trì hoãn giao dịch ; tương tự, những người dùng khác muốn tiếp xúc với token BOB nhưng không muốn giữ token BOB gốc trên Ethereum .
Để giải quyết vấn đề này, Bob đã triển khai một phiên bản BobDEX (bản tổng hợp lớp 2 có chi phí thấp, thông lượng cao) trên Arbitrum và phiên bản token được bao bọc của token BOB trên L2 thông qua cầu Arbitrum -Ethereum ( wBOB). BobDEX trên Arbitrum giống như BobDEX trên Ethereum, nhưng nó sử dụng wBOB (thay vì token BOB gốc) làm phần thưởng NHÀ CUNG CẤP THANH KHOẢN và token quản trị.
Đối với người dùng tương tác với BobDEX trên Arbitrum (chẳng hạn như nhà cung cấp thanh khoản), sự khác biệt về token ứng dụng (BOB được bao bọc so với BOB gốc) là không quan trọng. Điều này là do token wBOB được hỗ trợ bởi token BOB thực tế được giữ trong cầu nối Arbitrum -Ethereum, vì vậy người nắm giữ token wBOB có thể dễ dàng đổi token BOB ERC-20 gốc trên Ethereum bằng cách tương tác với hợp đồng cầu nối.
Chúng ta có thể thấy rằng tình huống này có lợi cho Bob và người dùng:
1. Bob có thể thu hút nhiều người dùng hơn, đặc biệt là những người muốn phí gas thấp hơn và xác nhận giao dịch nhanh chóng khi giao dịch trên BobDEX;
2. NHÀ CUNG CẤP THANH KHOẢN có thể kiếm được phần thưởng bằng cách cung cấp thanh khoản cho BobDEX mà không phải đối mặt với chi phí gas cao và thời gian xác nhận dài của Ethereum ;
3. Nhà đầu tư có thể mua token wBOB trên thị trường để kiếm lợi từ việc thay đổi giá token BOB mà không cần tương tác với hợp đồng BOB ERC-20 trên Ethereum.
Ngoài ra, lợi ích của cầu nối xuyên chuỗi là tăng cường sự đổi mới có thể tổng hợp và mở khóa các trường hợp sử dụng mới nhằm thanh khoản của token cầu nối. Ví dụ: Alice có thể tạo giao thức cho vay có tên "AliceLend" trên Arbitrum , chấp nhận wBOB của người đi vay làm tài sản thế chấp để mở rộng tiện ích của wBOB và tạo ra thị trường vay mượn mới.
Người cho vay cung cấp thanh khoản cho AliceLend được đảm bảo quyền truy cập vào tiền gửi: nếu người dùng không trả được nợ, AliceLend sẽ tự động bán đấu giá token wBOB được ký gửi làm tài sản thế chấp để trả nợ cho người cho vay. Trong trường hợp này, người mua thanh lý tài sản thế chấp wBOB sẽ đảm nhận nhân vật NHÀ CUNG CẤP THANH KHOẢN trên BobDEX với cùng sự đảm bảo rằng token wBOB có thể được trao đổi lấy token BOB gốc theo tỷ lệ 1:1.
Hiện tại, cầu nối xuyên chuỗi cung cấp một giải pháp khả thi để đảm bảo khả năng tương tác giữa Ethereum L2 (trước đây bị cô lập) và tạo điều kiện cho các ứng dụng mới như vay mượn chuỗi Chuỗi và DEX chuỗi Chuỗi. Tuy nhiên, hệ sinh thái cầu nối xuyên chuỗi đang phải đối mặt với những hạn chế cản trở tăng trưởng hơn nữa của nó, chẳng hạn như vấn đề về tính không thể thay thế của token chuỗi Chuỗi .
Tại sao token Chuỗi chéo trở nên không thể thay thế được?
Quy trình làm việc xuyên Chuỗi của cầu khóa và đúc tiền được đề cập ở trên có vẻ đơn giản, nhưng trên thực tế, nó đòi hỏi lượng lớn công việc thiết kế kỹ thuật và cơ chế để hoạt động chính xác.
Thử thách đầu tiên là đảm bảo rằng phiên bản token được bao bọc của token Chuỗi chéo luôn được hỗ trợ bởi Token gốc bị khóa trên Chuỗi nguồn. Nếu kẻ tấn công đúc token Chuỗi chuỗi chéo trên Chuỗi từ xa mà không gửi Token gốc trên Chuỗi nguồn, kẻ tấn công có thể cầu nối xuyên chuỗi. giao thức bị phá sản và ngăn người dùng hợp pháp (những người đã gửi tiền vào hợp đồng cầu nối xuyên chuỗi trước khi đúc token được gói) rút tiền gửi của họ.
Thử thách thứ hai phức tạp hơn và bắt nguồn từ bản chất của token xuyên Chuỗi : hai phiên bản token của cùng một token được nhà cung cấp cầu nối xuyên chuỗi đúc trên cùng một Chuỗi từ xa không thể trao đổi cho nhau theo tỷ lệ 1:1. Về vấn đề này, chúng ta có thể sử dụng ví dụ về hai người dùng đang cố gắng trao đổi token giữa Chuỗi thông qua các đường dẫn khác nhau để minh họa các vấn đề liên quan đến việc di chuyển token qua Chuỗi :
Alice kết nối USDC từ Ethereum với Arbitrum thông qua cầu Arbitrum tiêu chuẩn và nhận được 200 USDC.e trên Arbitrum , trong khi Bob liên Chuỗi chéo USDC với Arbitrum thông qua Axelar và nhận được 200 axlUSDC trên Arbitrum . Alice và Bob đạt được thỏa thuận, Alice gửi 200 USDC cho Bob (đổi lấy 200 USDT) để Bob có thể rút 400 USDC về Ethereum.
Bob đã cố gắng rút 400 USDC qua axlUSDC, nhưng chỉ nhận được 200 USDC. Đồng thời, anh nhận được thông báo cho biết giao thức cầu nối xuyên chuỗi chỉ có thể cung cấp cho Bob 200 USDC. Bob bối rối vì điều này vì token ERC-20 được bao bọc được cho là "có thể thay thế được" và sẽ không có sự khác biệt nào ngăn cản bất kỳ ai trao đổi token ERC-20 theo tỷ lệ 1: 1 trên bất kỳ ứng dụng nào.
Bob đã học được một bài học đắt giá từ cầu nối xuyên chuỗi: “ Token ERC-20 có thể thay thế” không phải lúc nào cũng có nghĩa là “Bạn có thể trao đổi chúng theo token” để trao đổi.” Do đó, nỗ lực của Bob nhằm tham gia một giao dịch rủi ro với Alice (vì Alice có thể không trả lại token) hoàn toàn thất bại.
Tại sao Bob không thể rút 400 USDC? Bởi vì anh ấy và Alice đã nhận được các phiên bản đóng gói khác nhau của cùng một tài sản cơ bản trên Chuỗi mục tiêu, như đã đề cập ở trên, token được phát hành trên Chuỗi khác nhau không tương thích, do đó, Token gốc được phát hành trên Chuỗi không phải gốc là Phiên bản token thực sự là một IOU trong thỏa thuận cầu nối xuyên chuỗi , hứa hẹn trả một lượng Token gốc tương ứng (tùy thuộc vào số tiền còn lại) khi người dùng muốn kết nối trở lại Chuỗi của token .
Do đó, giá trị của mỗi token chuỗi Chuỗi được gắn với nhà cung cấp cầu nối xuyên chuỗi chịu trách nhiệm giữ tiền gửi trên Chuỗi chính và đúc token được gói trên Chuỗi mục tiêu; Nhà cung cấp cầu nối xuyên chuỗi của Bob chỉ có thể trả cho Bob 200 USDC vì đó là số tiền cô ấy có thể trả từ khoản tiền gửi; 200 USDC của Alice không thể rút thông qua nhà cung cấp cầu nối xuyên chuỗi của Bob vì họ chưa bao giờ nhận được khoản tiền gửi hoặc phát hành "IOU" cho Alice. Alice phải rút USDC bị khóa của mình khỏi Arbitrum trên Ethereum và kết nối nó thông qua nhà cung cấp cầu nối xuyên chuỗi của Bob trước khi Bob có thể truy cập vào số token còn lại.
Tình thế tiến thoái lưỡng nan của Bob và Alice chỉ ra một vấn đề với việc bắc Chuỗi chuỗi chéo, đó là nhiều nhà cung cấp cầu nối xuyên chuỗi cạnh tranh đúc nhiều phiên bản token không thể thay thế của cùng một tài sản cơ bản. Ngoài ra, một vấn đề khác với token ERC-20 khác nhau của cùng một tài sản là chúng không thể được giao dịch trong một nhóm thanh khoản duy nhất.
Vẫn sử dụng ví dụ trên, nếu chúng ta có axlUSDC và USDC.e trên Chuỗi và muốn đổi chúng lấy ETH thì chúng ta phải triển khai hai nhóm thanh khoản- ETH/axlUSDC và ETH/USDC.e, dẫn đến Điều này giải quyết được vấn đề -được gọi là vấn đề "phân mảnh thanh khoản " - nghĩa là, cặp giao dịch có thể nằm trong cùng một nhóm thanh khoản sẽ được chia thành các nhóm khác nhau.
Giải pháp cho vấn đề này là lưu hành một phiên bản "tiêu chuẩn" của token trên Chuỗi mục tiêu, để Bob và Alice có thể trao đổi token mà không cần rút tiền khỏi cầu nối của Chuỗi nguồn. Việc có token tiêu chuẩn trên mỗi Chuỗi cũng mang lại lợi ích cho các nhà phát triển vì người dùng có thể nhanh chóng di chuyển giữa các hệ sinh thái mà không phải giải quyết các vấn đề liên quan đến thanh khoản token .
Vì vậy, làm cách nào để chúng tôi triển khai phiên bản tiêu chuẩn của token trên mỗi Chuỗi nơi nó dự kiến sẽ được sử dụng hoặc chuyển giao?
Triển khai token tiêu chuẩn trên nhiều Chuỗi
Tạo mã token tiêu chuẩn cho mỗi Chuỗi không phải là điều dễ dàng và có nhiều tùy chọn, mỗi tùy chọn đều có ưu và nhược điểm riêng. Khi tạo token tiêu chuẩn cho mỗi Chuỗi , chúng ta thường cần suy nghĩ xem ai nên được tin cậy để xác nhận sự tồn tại của IOU (kỳ phiếu) đằng sau giá trị của một token cụ thể. Giả sử bạn là người tạo token và muốn token được sử dụng và chuyển nhượng trên Chuỗi khác nhau mà không gặp phải vấn đề về khả năng thay thế, bạn sẽ có 4 tùy chọn:
1. Đúc token tiêu chuẩn thông qua Rollup/ Sidechain Bridge tiêu chuẩn
2. Đúc token tiêu chuẩn thông qua các nhà cung cấp cầu nối xuyên chuỗi bên thứ ba
3. Đúc token tiêu chuẩn thông qua Cầu phát hành token
4. Sử dụng Hoán đổi nguyên tử để phát hành trực tiếp đa chuỗi
Ba tùy chọn đầu tiên dựa vào các cơ chế cầu nối xuyên chuỗi khác nhau để tạo điều kiện thuận lợi cho việc di chuyển token qua Chuỗi. Tuy nhiên, với tư cách là người tạo token, bạn cũng có thể chọn bỏ qua hoàn toàn cầu nối xuyên chuỗi và phát hành token tự nhiên trên mỗi Chuỗi được hỗ trợ. Theo phương pháp này, thay vì dựa vào token được bao bọc hoặc cơ sở hạ tầng cầu nối xuyên chuỗi , bạn duy trì việc triển khai token độc lập nhưng được phối hợp trên mỗi Chuỗi — tức là , Hoán đổi nguyên tử cho phép trao đổi không cần tin cậy giữa Chuỗi.
Tuy nhiên, phương pháp này đòi hỏi cơ sở hạ tầng phức tạp để duy trì thanh khoản xuyên Chuỗi và tạo điều kiện thuận lợi cho Hoán đổi nguyên tử. Trong lịch sử, sự phức tạp của việc quản lý nhiều hoạt động triển khai gốc đã hạn chế phạm vi của phương pháp này, phương pháp này chủ yếu phù hợp với các giao thức lớn có nguồn lực kỹ thuật lượng lớn .
Đúc token tiêu chuẩn thông qua cầu nối rollup/ sidechain tiêu chuẩn
Nếu một Chuỗi có cầu nối tiêu chuẩn (được công nhận), Chuỗi đó có thể cấp cho người dùng muốn chuỗi Chuỗi từ Chuỗi gốc quyền đúc token chuỗi Chuỗi của giao thức của chuỗi đó. Các giao dịch (gửi tiền và rút tiền) được thực hiện thông qua cầu nối tiêu chuẩn của Chuỗi thường được xác minh bởi bộ xác thực của Chuỗi, điều này mang lại sự đảm bảo mạnh mẽ hơn rằng tiền gửi trên Chuỗi chính hỗ trợ đáng tin cậy cho tất cả các phiên bản token đúc .
Mặc dù Standard Bridge đang đúc phiên bản Standard Token của token nhưng các phiên bản token khác vẫn sẽ tồn tại vì Standard Bridge thường có những hạn chế khiến nó không thể mang lại trải nghiệm tốt nhất cho người dùng. Ví dụ: có sự chậm trễ bảy ngày từ cầu nối Arbitrum/ Optimism đến Ethereum thông qua cầu nối tiêu chuẩn của Rollup, vì giao dịch phải được xác minh bởi người xác thực (và có thể bị tranh chấp thông qua bằng chứng gian lận nếu không hợp lệ), sau đó lớp quyết toán của Rollup (Ethereum) sẽ quyết toán một loạt giao dịch.
Người dùng tổng hợp đang tìm kiếm hiệu quả phải sử dụng các nhà cung cấp cầu nối xuyên chuỗi khác có thể đảm nhận quyền sở hữu các lần thoát Rollup đang chờ xử lý và cung cấp thanh khoản ngay lập tức trên Chuỗi mục tiêu mong muốn của người dùng. Khi những cây cầu như vậy sử dụng mô hình khóa và đúc truyền thống, chúng tôi sẽ có nhiều token token bao bọc được phát hành bởi các giao thức khác nhau và gặp phải các vấn đề tương tự được mô tả trước đó.
Sidechain với các bộ xác thực độc lập có độ trễ thấp hơn vì việc rút tiền được thực hiện ngay sau khi giao thức đồng thuận của sidechain xác nhận khối chứa giao dịch rút tiền. Cầu Polygon PoS là một ví dụ về cầu nối tiêu chuẩn kết nối sidechain với các miền khác nhau, bao gồm Ethereum Rollup và mạng chủ Ethereum .
Lưu ý: Chúng tôi đang đề cập đến Chuỗi Polygon PoS ban đầu, không phải Chuỗi Validium có kế hoạch sử dụng Ethereum để quyết toán . Polygon sẽ trở thành L2 sau khi nó chuyển từ sidechain được bảo mật bởi các trình xác nhận bên ngoài sang Chuỗi Validium được bảo mật bởi sự đồng thuận Ethereum .
Thật không may, các cầu nối sidechain cũng có một điểm yếu chung với các cầu nối tiêu chuẩn Rollup: người dùng chỉ có thể liên Chuỗi giữa một cặp Chuỗi được kết nối. Họ không thể sử dụng các cầu nối tiêu chuẩn để Chuỗi kết chéo với blockchain khác. Nói một cách đơn giản, hiện tại, bạn không thể kết nối Arbitrum với Optimism bằng cách sử dụng cầu nối xuyên chuỗi Arbitrum , cũng như kết nối Polygon với Avalanche thông qua cầu nối xuyên chuỗi Polygon PoS.
Đúc token tiêu chuẩn đúc tiền sử dụng Cầu thanh khoản
Việc dựa vào cầu nối gốc của Rollup để chuyển token tiêu chuẩn sẽ gặp phải các vấn đề như tính thanh khoản kém và sự chậm trễ trong việc chuyển tài sản. Để giải quyết những vấn đề này, một số giao thức hoạt động với cầu nối thanh khoản để tạo điều kiện rút tiền nhanh và độ trễ thấp trên Chuỗi.
Theo thỏa thuận này, một cầu nối thanh khoản được ủy quyền đúc token thông báo bao bọc của token thông báo giao thức trên Chuỗi nguồn và sau đó trao đổi mã token bao bọc lấy token tiêu chuẩn của Token gốc trên Chuỗi mục tiêu thông qua nhóm thanh khoản thuộc sở hữu giao thức.
Token tiêu chuẩn trên Chuỗi mục tiêu thường là các phiên bản đúc bởi cầu nối sidechain /Rollup tiêu chuẩn, mặc dù vẫn tồn tại các trường hợp ngoại lệ (sẽ thảo luận sau). Ví dụ: token tiêu chuẩn cho USDT trên Optimism là opUSDT do Optimism Bridge đúc.
Mỗi cầu nối thanh khoản hoạt động giống như một DEX với một nhà tạo lập thị trường tự động (AMM) thực hiện hoán đổi giữa tài sản được lưu trữ trong các nhóm thanh khoản khác nhau. Để khích lệ nguồn cung thanh khoản , nhóm AMM sẽ phân bổ một phần phí trao đổi cho người nắm giữ token tiêu chuẩn bị khóa trong hợp đồng nhóm.
Điều này tương tự như mô hình của Uniswap ; điểm khác biệt rõ ràng duy nhất là các cặp tài sản thường là cặp cầu nối thanh khoản hoán đổi giữa token Chuỗi chéo và token tiêu chuẩn. Ví dụ: sau khi người dùng liên Chuỗi USDT sang Optimism thông qua Hop, họ sẽ phải đổi hUSDT thông qua nhóm huSDT:opUSDT trên Optimism .
Quy trình làm việc của Chuỗi chéo thông qua cầu thanh khoản như sau:
1. Khóa Token gốc trên Chuỗi nguồn
2. Đúc token Chuỗi chuỗi chéo của Token gốc trên Chuỗi mục tiêu
3. Trao đổi token chuỗi Chuỗi thành token tiêu chuẩn trên Chuỗi tiêu thông qua nhóm AMM
4. Gửi token tiêu chuẩn cho người dùng
Quy trình này tương tự đối với tất cả các cầu nối thanh khoản(Across, Celer, Hop, Stargate, v.v.), nhưng đối với người dùng cuối, quy trình này trông giống như một giao dịch đơn giản mặc dù có nhiều bộ phận chuyển động liên quan.
Khi chuỗi Chuỗi quay trở lại Chuỗi nguồn, người dùng sẽ đốt token tiêu chuẩn hoặc trao đổi mã token tiêu chuẩn với token chuỗi Chuỗi thông qua AMM, sau đó đốt token và cung cấp chứng chỉ biên nhận đốt. Sau khi được xác nhận, người dùng có thể rút Token gốc bị khóa ban đầu. (Giống như thao tác trước, các chi tiết tẻ nhạt của việc di chuyển token trở lại Chuỗi ban đầu sẽ bị ẩn khỏi người dùng và được người giải quyết hoàn toàn quản lý).
Ưu điểm của cầu thanh khoản là nó giải quyết được vấn đề chậm trễ trong cầu nối xuyên chuỗi của Rollup; ví dụ: Hop cho phép các tổ chức chuyên biệt gọi là "Bonders" chứng minh tính hợp lệ của các giao dịch rút tiền của người dùng trên L2 và chịu trách nhiệm từ cầu L1 của Rollup. chi phí thực hiện rút tiền. Mỗi Bonder sẽ chạy một nút đầy đủ cho Chuỗi L2 và có thể xác định liệu giao dịch thoát của người dùng cuối cùng có được xác nhận trên L1 hay không, từ đó giảm rủi ro người dùng bắt đầu rút tiền gian lận và gây tổn thất cho Bonder.
Không giống như cầu tiêu chuẩn, cầu thanh khoản cũng cho phép người dùng di chuyển giữa đa chuỗi . Ví dụ: Hop cho phép người dùng liên Chuỗi giữa Arbitrum và Optimism mà không cần rút tiền về Ethereum trước. Cũng giống như cầu nối L2 đến L1 nhanh, cầu nối L2 đến L2 nhanh cũng yêu cầu Bonder chạy một nút đầy đủ cho Chuỗi L2 nguồn để xác nhận việc rút tiền và sau đó trả trước phí đúc token đúc cho người dùng trên Chuỗi L2 mục tiêu, điều này tạo nên Rollup It dễ kết hợp hơn và cải thiện đáng kể trải nghiệm người dùng .
Tất nhiên, có một số nhược điểm đối với cầu nối thanh khoản , ảnh hưởng đến tính thực tế của đúc token tiêu chuẩn trên Chuỗi L2/L1 bằng cách sử dụng cầu nối tiêu chuẩn của Chuỗi .
Nhược điểm của cầu thanh khoản
Trượt giá
Trượt giá đề cập đến sự khác biệt giữa số lượng token dự kiến nhận được và số lượng token thực sự nhận được khi tương tác với AMM. Thiếu thanh khoản trong tài sản xuyên Chuỗi cũng có thể làm tăng độ trượt giá; nếu không có đủ thanh khoản trong nhóm để tái cân bằng, các giao dịch lớn có thể thay đổi giá đáng kể, khiến người dùng thực hiện giao dịch hoán đổi ở mức giá cao hơn. Về lý thuyết, các nhà kinh doanh chênh lệch giá có nhiệm vụ điều chỉnh chênh lệch giá giữa các nhóm tài sản khác nhau thông qua hoạt động giao dịch, tuy nhiên, cơ chế này có thể bị cản trở khi giao dịch chênh lệch giá liên quan đến token ít hoạt động giao dịch hơn hoặc có giá trị thấp hơn.
Và, điều này cũng ảnh hưởng đến các nhà phát triển xây dựng ứng dụng chuỗi Chuỗi , vì họ phải xem xét các trường hợp xảy ra trượt giá; người dùng có thể không hoàn thành Chuỗi do nhận được số lượng token thấp hơn trên một hoặc nhiều Chuỗi mục tiêu hoạt động.
Để chống lại điều này, các ứng dụng như công cụ tổng hợp chuỗi Chuỗi, không có cách nào để biết liệu cầu nối thanh khoản có đủ thanh khoản để thực hiện các giao dịch hoán đổi trên Chuỗi mục tiêu mà không bị trượt giá hay không, đã áp dụng phương pháp chỉ định khả năng chịu trượt giá tối đa. bằng cách đặt trước phạm vi trượt tối đa có thể chấp nhận được cho chúng. Mặc dù điều này ngăn cản việc khôi phục giao dịch, nhưng người dùng sẽ luôn mất một tỷ lệ phần trăm token Chuỗi chéo của họ, bất kể thanh khoản trong nhóm AMM của cầu nối như thế nào.
Hạn chế thanh khoản
Một thách thức cơ bản đối với cầu nối thanh khoản là phải có đủ thanh khoản trên Chuỗi mục tiêu. Không giống như lock-and đúc truyền thống, trong đó đúc token được hỗ trợ trực tiếp bởi tài sản bị khóa, Thanh khoản Bridge dựa vào token có sẵn trong nhóm AMM để hoàn tất quá trình chuyển giao chuỗi Chuỗi. Khi thanh khoản giảm xuống dưới ngưỡng quan trọng, toàn bộ cơ chế chuỗi Chuỗi có thể thực sự ngừng hoạt động.
Nếu thanh khoản quá thấp, các hoạt động xuyên Chuỗi có thể tạm dừng hoàn toàn, ngăn cản người dùng hoàn thành các giao dịch chuyển tiền dự định;
Người dùng có thể bị buộc phải chia các khoản chuyển khoản lớn thành các giao dịch nhỏ hơn để tránh làm cạn kiệt thanh khoản của nhóm;
Trong thời kỳ thị trường biến động hoặc căng thẳng hơn, nhà cung cấp thanh khoản có thể rút tiền từ các nhóm, đó là lúc chức năng cầu nối xuyên chuỗi là cần thiết nhất;
Việc ra mắt các cặp token mới trở nên đặc biệt khó khăn vì cần lượng lớn thanh khoản ban đầu để vận hành cầu nối xuyên chuỗi .
Yêu cầu thanh khoản tạo ra sự phụ thuộc vòng tròn: cây cầu yêu cầu lượng lớn thanh khoản lớn để hoạt động đáng tin cậy, nhưng việc thu hút nhà cung cấp thanh khoản đòi hỏi phải chứng minh được việc tiếp tục sử dụng và tạo phí cho cây cầu. Vấn đề con gà và quả trứng này đặc biệt nghiêm trọng đối với token mới hoặc token giao dịch ít thường xuyên hơn, có thể gặp khó khăn trong việc duy trì đủ thanh khoản trên nhiều Chuỗi .
Khuyến khích lệ không phù hợp
Vai trò của cầu nối thanh khoản là nó có thể bao trùm việc trao đổi từ token xuyên Chuỗi sang token tiêu chuẩn trên Chuỗi mục tiêu mà không gây trượt giá quá mức cho người dùng, Gas để tương tác với cầu nối cũng xác định giá trị của cầu nối thanh khoản; cầu thanh khoản. Do đó, các nhà tổng hợp chuỗi Chuỗi và đội ngũ dự án phát hành token sẽ ưu tiên cầu nối xuyên chuỗi dựa trên thanh khoản và chi phí giao dịch.
Mặc dù điều này đảm bảo trải nghiệm người dùng tốt hơn cho token dự án chuỗi Chuỗi hoặc người dùng sử dụng công cụ tổng hợp chuỗi Chuỗi để gửi token Chuỗi việc chọn cầu nối xuyên chuỗi cầu nối xuyên chuỗi dựa trên thanh khoản sẽ khiến việc chi tiêu cho khích lệ NHÀ CUNG CẤP THANH KHOẢN trở nên bất địa vị . . Hơn nữa, việc chỉ dựa vào phí giao dịch sẽ tạo ra sự cạnh tranh thiên vị theo hướng có lợi cho cầu nối xuyên chuỗi áp dụng phương pháp tập trung để giảm chi phí vận hành và có thể tính phí thấp hơn cho các giao dịch chuỗi Chuỗi . Trong cả hai trường hợp, cầu nối xuyên chuỗi đều không cạnh tranh được về chỉ báo quan trọng nhất – bảo mật.
Ngoài ra, cầu nối thanh khoản cũng gây bất lợi cho tài sản dài hạn có ít hoạt động giao dịch hơn (khiến chúng ít có khả năng thu hút nhà cung cấp thanh khoản). Các nhà phát hành token đuôi dài (hoặc token mới có khối lượng Chuỗi thấp hơn) sẽ phải xây dựng nhóm AMM và thanh khoản trực tiếp để trang trải Token gốc ( Chuỗi thông qua cầu thanh khoản ) bằng token tiêu chuẩn của hoán đổi token của nhà phát hành giữa hoặc hợp tác với nhà cung cấp cầu nối xuyên chuỗi để tăng cường khích lệ tài chính cho NHÀ CUNG CẤP THANH KHOẢN nhằm cung cấp thanh khoản cho tài sản .
Trải nghiệm người dùng Chuỗi chéo kém
Cầu thanh khoản là một cải tiến so với cầu nối xuyên chuỗi tiêu chuẩn, nhưng không phải là không có vấn đề về trải nghiệm người dùng. Ngoài sự trượt dốc của các sàn giao dịch xuyên Chuỗi , người dùng có thể không hoàn thành ngay các giao dịch xuyên Chuỗi trên Chuỗi mục tiêu vì cầu nối không có đủ thanh khoản để thực hiện các giao dịch bằng token tiêu chuẩn trên Chuỗi mục tiêu. Khi thông báo hoán đổi token của người dùng đến Chuỗi mục tiêu, cây cầu không có cách nào biết được cặp tài sản sẽ có thanh khoản như thế nào, vì vậy tình huống này hầu như không thể tránh khỏi.
Trong trường hợp này, người dùng có hai lựa chọn (không lý tưởng):
Đợi cho đến khi cầu có đủ thanh khoản để hoàn tất việc hoán đổi và rút token tiêu chuẩn. Điều này kém lý tưởng vì có sự chậm trễ trong các giao dịch xuyên Chuỗi và do thanh khoản của nhóm có thể thay đổi tùy ý trong một khoảng thời gian ngắn, nên người dùng không có cách nào để biết liệu họ có nhận được cùng số lượng token mà họ đã báo giá ban đầu hay không.
Nhận token độc quyền cầu nối xuyên chuỗi (ví dụ: hUSDT của Hop Bridge). Điều này chưa tối ưu vì hầu hết các ứng dụng đều muốn tích hợp với token tiêu chuẩn của Token gốc (ví dụ: opUSDT do Optimism Bridge đúc) và có thể không chấp nhận tài sản được bao bọc của người dùng.
Mã token tiêu chuẩn đúc thông qua cầu nối xuyên chuỗi của bên thứ ba
DApps đa chuỗi có thể giải quyết vấn đề về token Chuỗi chéo không thể thay thế bằng cách chọn một cầu nối xuyên chuỗi duy nhất, nghĩa là đúc token tiêu chuẩn của token DApp trên mỗi Chuỗi nơi DApp được triển khai. Tương tự như cách tiêu chuẩn tạo đúc token của dự án, phương pháp này yêu cầu Token mapping đúc trên Chuỗi từ xa phải được ánh xạ tới các hợp đồng token được triển khai trên Chuỗi chính của dự án để đảm bảo rằng lượng cung ứng token toàn cầu vẫn nhất quán. Các nhà cung cấp cầu nối xuyên chuỗi phải theo dõi đúc và đốt token và đảm bảo rằng các hoạt động này được đồng bộ hóa với lượng cung ứng token trên Chuỗi chính.
Trên cơ sở này, vấn đề về token chuỗi Chuỗi không thể thay thế được đã được giải quyết; miễn là người dùng liên Chuỗi thông qua nhà cung cấp cầu nối xuyên chuỗi đã được phê duyệt, họ luôn có thể liên chuỗi chéo với token chuỗi Chuỗi khác ở mức 1: 1 tỷ lệ trao đổi. Ngoài ra, phương pháp này còn giải quyết được vấn đề Chuỗi chuỗi dựa trên thanh khoản trong mô hình cầu tiêu chuẩn:
Người dùng sẽ không bị trượt giá trong các giao dịch chuỗi Chuỗi vì nhà cung cấp cầu nối xuyên chuỗi không cần chuyển đổi token chuỗi Chuỗi của họ thành token tiêu chuẩn thông qua AMM - token được nhà cung cấp cầu nối xuyên chuỗi hỗ trợ là mã thông báo được hỗ trợ bởi mỗi Chuỗi phiên bản token tiêu chuẩn trên. Giá trị của token tiêu chuẩn này được gắn với giá trị của token được nhà cung cấp khóa trên Chuỗi gốc.
Người dùng sẽ hầu như không gặp phải sự chậm trễ nào khi vượt qua Chuỗi vì nhà cung cấp cầu nối xuyên chuỗi có thể bắt đầu đúc token được gói trên Chuỗi mục tiêu ngay khi nhận được thông báo mint().
Các nhà phát triển có thể thuê ngoài việc quản lý triển khai token đa chuỗi cho các nhà cung cấp cầu nối xuyên chuỗi mà không phải lo lắng về việc triển khai các chương trình khích lệ cung cấp thanh khoản hoặc thanh khoản AMM.
Hiện tại, một số ví dụ về tiêu chuẩn token cho các nhà cung cấp cầu nối xuyên chuỗi đơn lẻ bao gồm Token phổ quát toàn Chuỗi (OFT) của LayerZero, Dịch vụ token Chuỗi chéo (ITS) của Axelar , xAsset của Celer và AnyAsset của Multichain. Điều đáng nói là các ví dụ này về bản chất là token độc quyền và không tương thích với token Chuỗi chéo của cùng một token được gửi qua các nhà cung cấp cầu nối xuyên chuỗi khác nhau, vì vậy chi tiết này cũng nêu bật một số vấn đề về chuỗi chéo này liên quan đến phương pháp token Chuỗi như sau:
Khóa nhà cung cấp
Mất chủ quyền giao thức
Rủi ro sập cầu cao
Chức năng tùy chỉnh của mã thông báo trên Chuỗi mục tiêu bị mất
Giới hạn ở Chuỗi nhà cung cấp hỗ trợ
Không thể duy trì cùng một địa chỉ token trên tất cả Chuỗi bắt buộc, điều này có thể ảnh hưởng đến bảo mật người dùng hoặc khiến họ dễ bị tấn công Phishing
Nhược điểm của việc sử dụng cầu nối xuyên chuỗi tiêu chuẩn của bên thứ ba
Khóa nhà cung cấp
Việc chọn một nhà cung cấp cầu nối xuyên chuỗi duy nhất để tạo token tiêu chuẩn trên một hoặc nhiều Chuỗi có thể khiến các nhà phát triển gặp rủi ro bị nhà cung cấp khóa. Vì mỗi nhà cung cấp cầu nối xuyên chuỗi tạo ra token độc quyền chỉ tương thích với cơ sở hạ tầng của họ (và các dự án hệ sinh thái tích hợp ), nên một nhà cung cấp cầu nối xuyên chuỗi duy nhất khóa các nhà phát hành token vào một dịch vụ cầu nối xuyên chuỗi cụ thể một cách hiệu quả và không thể chuyển sang một dịch vụ cầu nối cầu nối xuyên chuỗi khác. -Cầu xích tùy ý trong tương lai.
Mặc dù có thể thay đổi nhà cung cấp cầu nối xuyên chuỗi nhưng chi phí thay thế đủ cao để ngăn cản hầu hết các dự án chọn con đường này.
Ví dụ: giả sử một nhà phát triển (hãy gọi anh ta là Bob) phát hành token (BobToken) trên Ethereum và chọn LayerZero OFT để đúc phiên bản tiêu chuẩn của BobToken trên Optimism, Arbitrum và Base. Lượng cung ứng cố định của BobToken là 1.000.000 và token Chuỗi đúc thông qua LayerZero chiếm 50% tổng lượng cung ứng BobToken đang lưu hành.
Lúc đầu, việc kinh doanh diễn ra suôn sẻ cho đến khi Bob quyết định kết nối BobToken bằng cách cạnh tranh các dịch vụ Chuỗi chéo như Axelar. Tuy nhiên, Bob không thể nói đơn giản: "Tôi muốn chuyển sang Axelar ITS để đúc token tiêu chuẩn của BobToken trên Optimism, Base và Arbitrum "; do tính không tương thích của token OFT và token ITS, Bob có thể gây rắc rối cho người dùng mới và cũ. bởi vì hai BobTokens có thể không thể thay thế cho nhau (ở đây xin giới thiệu lại vấn đề mà chúng tôi đã mô tả trước đó). Đồng thời, các ứng dụng tích hợp với phiên bản LayerZero của BobToken có thể không chấp nhận phiên bản Axelar của BobToken thay thế, điều này sẽ dẫn đến sự phân tán thanh khoản trên Chuỗi L2 khác nhau nơi token cạnh tranh của BobToken cùng tồn tại.
Vậy nếu Bob phải thực hiện chuyển đổi thì anh ấy cần phải làm gì?
Trước tiên, Bob cần thuyết phục người dùng gửi giao dịch để mở mã token BobToken đúc qua LayerZero, giao dịch này đốt mã token OFT Chuỗi và mở khóa BobToken trên Ethereum . Sau đó, người dùng có thể khóa token bằng cách sử dụng Axelar trên Ethereum và nhận BobToken ( token tiêu chuẩn mới được ánh xạ tới nguồn cung cấp hợp đồng token trên Ethereum ) trên Chuỗi mục tiêu. Quá trình này gây tốn kém cho đội ngũ quản lý dự án DAO và tạo ra chi phí hoạt động và phối hợp đáng kể, vì vậy, việc gắn bó với nhà cung cấp ban đầu thường là lựa chọn an toàn nhất.
Mặt khác, các nhà phát triển như Bob cũng có thể gặp rắc rối vì nếu nhà cung cấp cầu nối xuyên chuỗi không tuân thủ các điều khoản của thỏa thuận, có bộ tính năng hạn chế, thiếu tích hợp hệ sinh thái rộng rãi, có trải nghiệm người dùng kém, v.v. Khóa nhà cung cấp sẽ ngăn các nhà phát triển chuyển đổi. Trong khoảng thời gian này, nhà cung cấp cầu nối xuyên chuỗi cũng có thể thực hiện những việc tùy ý, chẳng hạn như hạn chế tỷ lệ người dùng BobToken chuỗi Chuỗi mà không có lý do rõ ràng, tăng phí Chuỗi hoặc thậm chí kiểm duyệt hoạt động chuỗi Chuỗi.
Mất chủ quyền giao thức
Phần kết luận về việc khóa nhà cung cấp ở trên nêu bật một vấn đề khác khi sử dụng cầu nối xuyên chuỗi bên thứ ba tiêu chuẩn: các nhà phát hành token hy sinh quyền kiểm soát token chuỗi Chuỗi tiêu chuẩn để cải thiện trải nghiệm người dùng và thuận tiện hơn. Ví dụ: BobToken trên Ethereum hoàn toàn nằm trong tầm kiểm soát của Bob vì anh ấy kiểm soát hợp đồng token ERC-20 cơ bản, nhưng BobToken trên Optimism, Arbitrum và Base được kiểm soát bởi LayerZero, công ty sở hữu các quyền đối với blockchain này. Hợp đồng OFT của tiêu chuẩn BobToken. token được phát hành trên blockchain .
Mặc dù Bob có thể mong đợi LayerZero giữ token tiêu chuẩn nhất quán với thiết kế ban đầu của Token gốc nhưng điều này không phải lúc nào cũng đúng. Trong trường hợp xấu nhất, BobToken có thể hoạt động rất khác trên Ethereum so với BobToken trên Optimism , bởi vì nhà cung cấp cầu nối xuyên chuỗi triển khai một phiên bản hoàn toàn khác của hợp đồng token- điều này cũng gây ra vấn đề cho người dùng về giao thức vì mục tiêu. và lợi ích của các nhà phát triển giao thức và nhà cung cấp cầu nối xuyên chuỗi có thể khác nhau.
Rủi ro cầu nối xuyên chuỗi rất cao
Trong giải pháp đầu tiên, token được Chuỗi chéo thông qua cầu nối tiêu chuẩn của mỗi Chuỗi và rủi ro của nhà phát hành token từ các lỗ hổng ảnh hưởng đến một cầu nối xuyên chuỗi được giới hạn ở cầu nối đó. Ví dụ: giả sử hacker cố gắng vi phạm cầu thanh khoản và đúc số lượng token được bao bọc không giới hạn mà không cần gửi tài sản thế chấp. Trong trường hợp này, nó chỉ có thể rút thanh khoản tối đa sẵn có của tài sản được bao bọc trong nhóm thanh khoản (ví dụ: Đúc cUSDT trên Optimism → Hoán đổi cUSDT lấy opUSDT tiêu chuẩn → Rút opUSDT sang Ethereum thông qua Chuỗi nhanh → Trên Ethereum cho USDT gốc).
Trong mô hình cầu nối xuyên chuỗi của bên thứ ba, đối với nhà phát hành token , rủi ro do lỗ hổng ảnh hưởng đến cầu nối xuyên chuỗi của đối tác tương đương với tổng lượng token do kẻ tấn công đúc trên Chuỗi xa do cầu nối bị ảnh hưởng triển khai . Điều này hoàn toàn có thể thực hiện được vì token tiêu chuẩn trong đó một Chuỗi có thể được trao đổi lấy token tiêu chuẩn được phát hành trên Chuỗi khác theo tỷ lệ 1:1. Ví dụ như sau:
Giả sử kẻ tấn công xâm phạm cầu nối xuyên chuỗi của bên thứ ba trên Chuỗi B và đúc 1000 token(token ban đầu được phát hành trên Chuỗi A) mà không cần gửi tài sản thế chấp. Token của kẻ tấn công trên Chuỗi B không được ánh xạ tới hợp đồng Chuỗi chính, vì vậy chúng không thể rút khỏi Chuỗi A. Tuy nhiên, nó có thể là chuỗi Chuỗi sang Chuỗi C, trao đổi 1000 token Chuỗi B lấy 1000 token Chuỗi C - hãy nhớ rằng, token chuỗi Chuỗi tiêu chuẩn này đều tương thích và có thể hoán đổi cho nhau vì chúng đến từ cùng một dịch vụ Cầu nối xuyên chuỗi . Token Chuỗi C được ánh xạ tới hợp đồng Chuỗi chính vì chúng được đúc hợp pháp bởi người dùng đã khóa token trên Chuỗi A ( Chuỗi chính của token ), cho phép kẻ tấn công đốt token trên Chuỗi C và rút Chuỗi A trên Token gốc, kẻ tấn công cuối cùng có thể hoàn thành cuộc tấn công bằng cách giao dịch token trên CEX.
Chức năng tùy chỉnh của mã thông báo trên Chuỗi mục tiêu bị mất
Khi sử dụng cầu nối xuyên chuỗi của bên thứ ba, các nhà phát hành token cũng thường mất khả năng triển khai các tính năng tùy chỉnh hoặc hành vi token tồn tại trong quá trình triển khai ban đầu của họ, chẳng hạn như ủy quyền biểu quyết (ZK), cơ chế khởi động lại (stETH, USDM), Phí chuyển khoản chức năng, chức năng danh sách đen và danh sách trắng (USDT, USDC), chuyển khoản có thể tạm dừng và các quy tắc hoặc quyền đúc đặc biệt, v.v. Các chức năng token phổ biến này thường bị loại bỏ do các nhà cung cấp cầu nối xuyên chuỗi Thường sử dụng ERC-20 được tiêu chuẩn hóa Triển khai các hợp đồng có thể không hỗ trợ chức năng chuyên biệt có trong quá trình triển khai token ban đầu.
Việc thiếu các chức năng này sẽ dẫn đến sự không nhất quán trong hoạt động của token trên Chuỗi khác nhau, điều này có thể gây hại cho các ứng dụng tích hợp dựa trên các chức năng tùy chỉnh cụ thể này. Mặc dù việc thúc đẩy tiêu chuẩn hóa token chuỗi Chuỗi dường như có thể đơn giản hóa hoạt động từ góc độ của các nhà cung cấp cầu nối xuyên chuỗi , nhưng trên thực tế, cách tiếp cận này làm suy yếu các chức năng ban đầu của token và có thể cản trở các nhà phát hành sử dụng chúng trong các lĩnh vực mà ứng dụng của họ bao phủ. Duy trì tính nhất quán trong hành vi token trên toàn bộ hệ sinh thái đa chuỗi .
Chuỗi được hỗ trợ hạn chế
Các nhà phát hành token dựa vào kế hoạch mở rộng và mở rộng mạng của nhà cung cấp cầu nối xuyên chuỗi đã chọn của họ. Nếu nhà cung cấp cầu nối xuyên chuỗi không hỗ trợ mạng blockchain cụ thể mà nhà phát hành token muốn mở rộng , họ sẽ phải đối mặt với hai tùy chọn kém lý tưởng:
Đợi nhà cung cấp cầu nối xuyên chuỗi thêm hỗ trợ cho Chuỗi mong muốn, việc này có thể mất nhiều thời gian hoặc có thể không bao giờ được triển khai do chi phí tích hợp cao (ví dụ: EVM của ZKsync Era không tương đương dẫn đến nhiều Dapp không bao giờ được xây dựng trên đó khi triển khai);
Việc sử dụng một nhà cung cấp cầu nối xuyên chuỗi khác cho Chuỗi cụ thể đó sẽ gây ra các vấn đề về token không thể thay thế và phân mảnh thanh khoản.
Hạn chế này có thể ảnh hưởng nghiêm trọng đến chiến lược tăng trưởng của giao thức và khả năng thu hút người dùng mới trên Chuỗi mới nổi. Xin lưu ý rằng các nhà cung cấp cầu nối xuyên chuỗi có thể ưu tiên hỗ trợ Chuỗi phổ biến và bỏ qua các mạng nhỏ hơn hoặc mới hơn có thể mang tính chiến lược đối với các nhà phát hành token .
Địa token Chuỗi chéo không nhất quán
Do đặc thù của ngăn xếp công nghệ (chẳng hạn như không hỗ trợ CREATE2) , các nhà cung cấp cầu nối xuyên chuỗi bên thứ ba có thể sử dụng các địa chỉ khác nhau để triển khai token Chuỗi chéo trên mỗi Chuỗi . Việc thiếu tính nhất quán của địa chỉ đã gây ra nhiều trải nghiệm cho người dùng. vấn đề:
Rủi ro bảo mật: Người dùng phải xác minh các địa chỉ token khác nhau trên mỗi Chuỗi , do đó làm tăng rủi ro tương tác với token lừa đảo;
Độ phức tạp tích hợp: nhà phát triển phải duy trì danh sách các địa chỉ mã token hợp lệ cho mỗi mạng;
Rủi ro Phishing gia tăng: Không có địa chỉ nhất quán để kiểm tra, kẻ xấu có thể dễ dàng lừa gạt người dùng bằng token giả hơn.
Phát hành token tiêu chuẩn thông qua cầu phát hành token
Ngoài các giải pháp được đề cập ở trên, nếu các nhà phát triển muốn duy trì quyền kiểm soát tối đa đối với việc triển khai token của dự án trên chuỗi Chuỗi , họ có thể quản lý việc phát hành các phiên bản token tiêu chuẩn của token trên Chuỗi từ xa, được mô tả là "đáng tin cậy" "bất kỳ nhà phát hành token nào" vì giá trị của mỗi phiên bản token Chuỗi chéo được liên kết chặt chẽ với giá trị token bị khóa bởi giao thức chịu trách nhiệm phát hành phiên bản gốc của token trên Chuỗi nguồn.
Để phương pháp này hoạt động, các nhà phát hành token phải thiết lập cơ sở hạ tầng để quản lý đúc và đốt token trên Chuỗi (đồng thời đảm bảo rằng lượng cung ứng toàn cầu được giữ đồng bộ thông qua ánh xạ tiêu chuẩn).
Các ví dụ nổi tiếng về token tiêu chuẩn ( Token gốc ) do người tạo token phát hành là Dịch chuyển tức thời của MakerDAO và Giao thức chuyển Chuỗi chéo (CCTP) của Circle. Teleport cho phép người dùng di chuyển Dai tiêu chuẩn giữa Ethereum và rollups Ethereum khác nhau. Dai bị đốt trên một Chuỗi và có thể được đúc trên Chuỗi mục tiêu cùng một lúc. CCTP hoạt động tương tự và cho phép chuyển USDC gốc (do Circle phát hành) xuyên Chuỗi thông qua cơ chế đốt và đúc . Trong cả hai trường hợp, nhà phát hành token kiểm soát đúc và đốt mã token tiêu chuẩn.
Phương pháp này cung cấp cho giao thức khả năng kiểm soát hoàn toàn đối với token Chuỗi chéo. Nó giải quyết vấn đề không thể thay thế của cùng một token theo cách hiệu quả nhất - chỉ có một phiên bản tiêu chuẩn của token (do nhà phát hành đúc trên Chuỗi mục tiêu), đảm bảo rằng người dùng token Mọi người trong hệ sinh thái đều có cùng một mã thông báo trải nghiệm khi sử dụng token .
Sử dụng phương pháp này, các ứng dụng cũng có thể loại bỏ các vấn đề phân mảnh thanh khoản do token Chuỗi chéo chính thức trong cùng một hệ sinh thái gây ra. Các nhà phát triển cũng có thể xây dựng các ứng dụng chuỗi Chuỗi mạnh mẽ hơn (ví dụ: hoán đổi Chuỗi chéo và vay mượn Chuỗi chéo) vì cầu nối của nhà phát hành token tiêu chuẩn cho phép chuyển token hiệu quả, liền mạch và an toàn giữa Chuỗi .
Tất nhiên, loại giải pháp này cũng có một số nhược điểm, mô hình này chỉ phù hợp với những người có đủ vốn để triển khai token tiêu chuẩn trên Chuỗi , cũng như chi phí duy trì cơ sở hạ tầng ( oracle , người giám hộ, v.v.) cần thiết cho chéo. - dự án đúc và đốt Chuỗi . Đồng thời, điều này cũng mang lại một số hiệu ứng không mấy lý tưởng, đó là tích hợp chặt chẽ tính bảo mật của tài sản Chuỗi chéo với mô hình bảo mật của giao thức.
Nói một cách khách quan, mối quan hệ này (mối quan hệ giữa phiên bản Chuỗi chéo của token thông báo giao thức và tính bảo mật của giao thức) là thân thiện, bởi vì tính bảo mật của Token gốc hỗ trợ phiên bản token tiêu chuẩn đã phụ thuộc vào tính bảo mật của giao thức, vì vậy người dùng và nhà phát triển bên ngoài sẽ không có những giả định tin cậy mới. Điều này đặc biệt áp dụng cho các cầu nối stablecoin được điều hành bởi các nhà phát hành như Circle và Maker (nay là Sky) - người dùng đã tin tưởng nhà phát hành stablecoin có đủ tài sản để trang trải chi phí trao đổi stablecoin với tiền tệ fiat và do đó tin tưởng vào cầu stablecoin. khó.
Nhưng nó cũng đại diện cho điểm thất bại trung tâm – nếu cơ sở hạ tầng cầu nối của nhà phát hành token bị xâm phạm, giá trị của tất cả token tiêu chuẩn lưu hành trong hệ sinh thái đa chuỗi sẽ bị đe dọa. Điều này cũng có nghĩa là chỉ những người giám sát tập trung (chẳng hạn như Circle trong USDC) mới có thể thực sự triển khai mô hình phát hành token chuỗi Chuỗi tiêu chuẩn này.
suy nghĩ cuối cùng
Khả năng thay thế lẫn nhau tài sản trong Chuỗi chắc chắn là một phần quan trọng trong khả năng tương tác của Rollup, ảnh hưởng đến trải nghiệm chuyển tài sản giữa Chuỗi khác nhau của người dùng. Đồng thời, khả năng token duy trì khả năng thay thế giữa Chuỗi cho đến Chuỗi từ xa cũng sẽ tác động đến hành vi của nhà phát triển, vì một số trường hợp sử dụng nhất định dựa vào tính năng này.
Để giải quyết vấn đề về token Chuỗi chéo không thể thay thế, ngành đã đề xuất các giải pháp khác nhau, bao gồm đúc token tiêu chuẩn thông qua các cầu nối gốc (được triển khai), sử dụng cầu nối chuyên dụng của bên thứ ba đúc token tiêu chuẩn trên nhiều Chuỗi , cũng như sử dụng giao thức -các cầu nối được sở hữu để tạo thuận lợi cho việc di chuyển token và duy trì khả năng thay thế.
Mặc dù phương pháp này giải quyết được nhiều vấn đề cụ thể nhưng chúng không thể giải quyết được tất cả và việc sử dụng chúng để đạt được khả năng thay thế tài sản xuyên Chuỗi đòi hỏi phải thực hiện một số đánh đổi ít lý tưởng hơn. Vậy chúng ta có thể tìm ra phương pháp nào tốt hơn không? Câu trả lời là có.
Chúng tôi cho rằng rằng ERC-7281 là một giải pháp mới cho khả năng thay thế tài sản xuyên Chuỗi , cho phép các giao thức triển khai hiệu quả token tiêu chuẩn trên nhiều Chuỗi mà không ảnh hưởng đến tính bảo mật, chủ quyền hoặc trải nghiệm người dùng.
Thiết kế độc đáo của ERC-7281 cho phép nhiều cầu nối xuyên chuỗi (được đưa vào danh sách cho phép) đúc các phiên bản tiêu chuẩn của token thông báo giao thức trên mỗi Chuỗi được hỗ trợ, đồng thời cho phép các nhà phát triển giao thức điều chỉnh linh hoạt giới hạn đúc trên mỗi cầu nối xuyên chuỗi . Tính năng này giải quyết nhiều vấn đề liên quan đến Đề án lịch sử đối với token tiêu chuẩn đa chuỗi , bao gồm phân mảnh thanh khoản, tính nhất quán khích lệ, vấn đề về trải nghiệm người dùng, bảo mật cầu nối xuyên chuỗi và khả năng tùy chỉnh của token Chuỗi chéo.
Do đó, trong phần tiếp theo của báo cáo về khả năng thay thế tài sản xuyên Chuỗi , chúng tôi sẽ giới thiệu chi tiết ERC-7281 (còn được gọi là xERC-20), phân tích đa chuỗi của xERC-20 bằng cách so sánh nó với tiêu chuẩn đa chuỗi khác thiết kế token , phương pháp token tiêu chuẩn chuỗi và đi sâu vào cách tiêu chuẩn token xERC-20 có thể mang lại lợi ích cho nhà phát triển và người dùng.
Sẽ được tiếp tục.
