Giới thiệu

Các maxis modul đã nói rằng tương lai của tiền điện tử là một triệu (hoặc hơn) miền và người dùng được kết nối với nhau như Alice đi qua xứ sở thần tiên. Tại sao bạn chỉ stay với một chuỗi nếu bạn có thể truy cập vào công nghệ tiên tiến, ứng dụng mới lạ, sinh lợi khủng từ việc gắn kết/ cung cấp thanh khoản, hiệu suất cao và phí giao dịch cực thấp trên các chuỗi khác?

Tuy nhiên, việc di chuyển giữa các chuỗi khối phức tạp hơn nhiều so với chuyến đi của Alice qua xứ sở thần tiên, chủ yếu do các hạn chế tồn tại trong các phương pháp hiện tại về tương tác giữa các chuỗi khối (ví dụ: cầu nối giữa các chuỗi cross-chain). Đặc biệt, cầu nối giữa các chuỗi cross-chain hiện nay có thể không an toàn (hơn 2.5 tỷ đô la bị mất trong các vụ tấn công cầu nối), chậm, đắt đỏ hoặc giới hạn về chức năng - hoặc hiển thị một sự kết hợp các thuộc tính từ danh sách.

Các vấn đề khác gây ảnh hưởng đến ngành cầu nối là tinh vi hơn nhưng vẫn đủ để biến giấc mơ của modular maxi về hệ sinh thái đa chuỗi thành ác mộng đối với người dùng và nhà phát triển - một ví dụ về điều này là cách các mã thông báo có tính đổi mới (như ERC-20) trở thành không đổi mới khi được cầu nối sang các chuỗi khác nhau thông qua các giao thức cross-chain khác nhau, gây tổn hại đến tính năng của nó như một tài sản chuyển nhượng. Trong bài viết này, chúng tôi sẽ khám phá một giải pháp nhằm bảo tồn tính đổi mới của mã thông báo trên các chuỗi bất kể nơi mà hợp đồng nguồn của mã thông báo tồn tại: ERC-7281: Các Mã Thông Báo Quốc Tế.

ERC-7281 mở rộng ERC-20 - tiêu chuẩn mặc định cho việc tạo mã thông báo có tính chất đồng nhất trên Ethereum - để cho phép đúc và đốt các biểu diễn cơ bản của các mã thông báo ERC-20 trên miền từ xa bằng nhiều cầu được phê duyệt bởi người phát hành mã thông báo. Điều này đảm bảo rằng người dùng cầu kết nối với một mã thông báo ERC-20 sẽ nhận được phiên bản có tính chất đồng nhất của mã thông báo tại điểm đến (tức là, hai mã thông báo có thể được trao đổi 1:1), ngay cả khi mã thông báo được gửi qua các cầu theo các tuyến/ cầu khác nhau. Quan trọng, các giao thức áp dụng ERC-7281 giữ quyền kiểm soát các mã thông báo được cầu kết nối (không giống như hiện trạng nơi cầu kiểm soát một mã thông báo được cầu kết nối) và có thể giới hạn tốc độ đúc để giảm sự phơi bày trong trường hợp cầu gặp sự cố.

Hãy sử dụng USDC làm ví dụ về tính vô hiệu giữa các mã thông báo ERC-20 giống hệt nhau về lý thuyết trên các chuỗi khác nhau. Trong Mạng lưới Ethereum Layer 2 (L2), chẳng hạn như Arbitrum, Base, Optimism, người ta thường sử dụng cầu nối chính tắc để di chuyển các mã thông báo ERC-20 phổ biến từ Ethereum L1 sang các chuỗi này. Các phiên bản này của mã thông báo L2 có nguồn gốc từ L1 thường được gọi là “bắc cầu [chèn tên mã thông báo].”

Trong trường hợp USDC, các ký hiệu phổ biến là USDC.e, USDC.b, v.v. Theo thời gian, Circle mở rộng triển khai USDC sang các chuỗi khác, bao gồm L2s, nơi USDC đã hoạt động thông qua cầu nối chuẩn. Mặc dù hai mã thông báo này được đúc bởi cùng một thực thể và có cùng giá, nhưng chúng là các mã thông báo không thể thay thế khác nhau về mặt kỹ thuật, do đó không thể “tương tác” — trong khi USDC gốc có thể được bắc cầu thông qua cầu CCTP của Circle, USDC bắc cầu chỉ có thể được bắc cầu trở lại L1 thông qua cầu nối chuẩn.

ERC-7281 giải quyết vấn đề này bằng cách giới thiệu một phần mở rộng ERC-20 trong đó những người triển khai token có thể chỉ định và tham số hóa các nguồn cầu nối khác nhau cho nó. Trong ví dụ trên, Circle có thể triển khai một token USDC phổ quát trên tất cả các L2, trong đó các cầu nối chuẩn (ví dụ: Circle Mint, Circle CCTP và các cầu nối được phê duyệt khác) được chỉ định là có khả năng đúc token theo logic của chúng. Để giảm thiểu rủi ro bị hack, người triển khai có thể giới hạn số lượng token mỗi đúc và đốt trong một khoảng thời gian cụ thể - với các cầu nối đáng tin cậy hơn, chẳng hạn như cầu nối L2 chuẩn, có giới hạn cao hơn, và các cầu nối với sự đồng thuận tập trung có giới hạn thấp hơn.

Mặc dù ERC-7281 không phải là sự cố gắng đầu tiên để tạo ra các token chuỗi chéo có thể thay thế, nhưng nó khắc phục các vấn đề liên quan đến các đề xuất trước đó—như kẹt cửa hàng, mất chủ quyền cho người phát hành token, chi phí cao để tạo thanh khoản cho các token cầu nối, chi phí cơ sở hạ tầng và tăng cường rủi ro khi cầu nối gặp sự cố.

Báo cáo hai phần này sẽ xem xét lý do để giới thiệu một tiêu chuẩn mã thông báo cầu nối chủ quyền và cung cấp một cái nhìn tổng quan toàn diện về đặc tả ERC-7281 (còn được biết đến là xERC-20). Chúng tôi cũng sẽ thảo luận về những lợi ích tích cực và nhược điểm tiềm năng của việc 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à các bên khác trong hệ sinh thái Ethereum.

Một bài tập làm mới về những cây cầu blockchain

Trước khi đào sâu vào vấn đề về các token cầu không thể thay thế, điều này giúp hiểu vì sao các token cầu tồn tại trong lần đầu tiên. Điều này, lần lượt, yêu cầu hiểu động cơ và hoạt động của các cầu blockchain - vì các nhà điều hành cầu là những người chịu trách nhiệm cho việc tạo ra phiên bản token được cầu.

Một cầu là cơ chế để chuyển thông tin giữa các chuỗi khối. Bên cạnh các thông tin thuần túy về tiền tệ, cầu có thể truyền bất kỳ thông tin hữu ích nào như tỷ lệ token và trạng thái hợp đồng thông minh trên các chuỗi khác. Tuy nhiên, việc chuyển tài sản (token) từ một chuỗi sang khác là trường hợp sử dụng phổ biến nhất hiện nay cho người dùng tương tác với một cầu.

Các phương pháp để hỗ trợ chuyển đổi tài sản qua chuỗi khác nhau khác nhau, nhưng quy trình cầu nối token thường theo một trong ba mẫu cao cấp:

Khóa và đúc cầu

• Một người dùng muốn kết nối một token từ chuỗi gốc hoặc ‘nhà’ (nơi nó được phát hành ban đầu) sang một chuỗi khác. Hai chuỗi khối không tương thích, vì mỗi chuỗi triển khai các kiến trúc và thiết kế giao thức khác nhau, điều này ngăn người dùng chuyển token trực tiếp từ một địa chỉ ví trên chuỗi A sang một địa chỉ ví trên chuỗi B.
• Người vận hành cầu sẽ đặt cọc các token được người dùng gửi trên chuỗi gốc vào một hợp đồng thông minh và tạo ra một phiên bản token “wrapped” của token gốc thông qua một hợp đồng token triển khai trên chuỗi đích.
• Khi người dùng muốn cầu nối theo hướng ngược lại (chuỗi đích → chuỗi nguồn), họ trả lại các token đã được bọc cho cầu trên chuỗi đích, mà cầu này xác minh theo logic trong cầu (ví dụ, chứng minh ZK hoặc một quyết định ngoại vi) và phát hành các token gốc từ kho dự trữ trên chuỗi chính.

Cầu đốt và đúc tiền

• Thay vì khóa các token trong hợp đồng gửi giữ, phương pháp này đốt (phá hủy) các token trên chuỗi nguồn;
• Cầu nối sau đó phát hành một số lượng tương đương trên chuỗi đích;
• Đối với chuyến đi ngược lại, các token đã được cầu nối được đốt cháy trên chuỗi đích trước khi token mới được tạo trên chuỗi nguồn;
• Điều này giữ nguyên tổng cung token trong khi cho phép chuyển giao dịch qua chuỗi cross.

Giao dịch nguyên tử

• Phương pháp này trực tiếp trao đổi tài sản trên chuỗi nguồn cho tài sản trên chuỗi đích với một bên thứ ba.
• Giao dịch hoán đổi nguyên tử hoạt động thông qua việc khóa tài sản với cùng một giá trị bí mật để mở khóa chúng, điều này có nghĩa là nếu bên nào đã tiết lộ bí mật thì cũng có thể được tiết lộ trên phía kia. Điều này mang lại tính chất nguyên tử cho các giao dịch hoán đổi.
• Tính nguyên tử đồng nghĩa với việc hoán đổi hoàn thành hoàn toàn (trên cả hai phía) hoặc không hoàn toàn, ngăn chặn gian lận hoặc chuyển khoản không hoàn chỉnh/ thất bại.

Phương pháp đầu tiên (khóa và phát hành) hiện tại là phổ biến nhất. Sự tương đương về giá trị giữa một token gốc và phiên bản được phát hành bởi một cầu nối cho phép người dùng “chuyển” tài sản qua chuỗi và sử dụng token trên một chuỗi riêng biệt so với nơi ban đầu phát hành.

Tuy nhiên, các thiết kế mới - chẳng hạn như cầu nối dựa trên mục đích - đã trở nên khá phổ biến. “Ý định” cho phép người dùng thể hiện kết quả mong muốn cho các giao dịch (“hoán đổ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 đã nổi lên như một mở khóa UX mạnh mẽ vì chúng đơn giản hóa rất nhiều trải nghiệm onchain cho mọi người và làm cho tiền điện tử dễ sử dụng hơn, đặc biệt là khi được ghép nối với giải pháp trừu tượng chuỗi.

chuỗi cross ý định Cho phép người dùng chuyển mã thông báo giữa các chuỗi mà không phải lo lắng về sự phức tạp cơ bản của việc bắc cầu. Trong các cầu nố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 đích (“ý định” của họ). Các toán tử chuyên biệt được gọi là “fillers” hoặc “solvers” có thể thực hiện ý định này bằng cách gửi trước các token được yêu cầu cho người dùng trên chuỗi đích. Các nhà khai thác sau đó chứng minh việc chuyển tiền xảy ra để yêu cầu các khoản tiền bị khóa trên chuỗi nguồn là khoản hoàn trả.

Một số cầu nối dựa trên cơ chế khóa và đúc bên dưới. Trong trường hợp này, cầu nối đúc các token bọc được gửi entweder đến filler đã thực hiện ý định của người dùng - hoặc trực tiếp đến người dùng nếu không có filler tham gia. Mặc dù cầu nối dựa trên ý định thêm một lớp hiệu suất thông qua mạng giải quyết của họ, nhưng chúng vẫn dựa vào cùng nguyên tắc với cầu nối khóa và đúc truyền thống.

Chúng ta có thể coi mỗi token được bọc, cho dù được tạo ra thông qua cầu nối truyền thống hoặc dựa trên ý định, như một IOU từ người điều hành cầu nối, cam kết phát hành một số lượng token gốc từ hợp đồng giữ token. Giá trị của những tài sản được bọc này tương quan trực tiếp với khả năng (được cho là) của người điều hành cầu nối để xử lý yêu cầu từ người nắm giữ rút token gốc được gửi đến trên chuỗi gốc của token.

Cầu nối được ủy quyền để khóa các mã thông báo cơ bản trên chuỗi nguồn và đúc các biểu diễn được bọc của chúng trên chuỗi đích đảm bảo rằng tổng nguồn cung của mã thông báo không đổi. Đối với một đơn vị của mã thông báo cơ bản, chính xác một đơn vị của mã thông báo được bọc tương ứng được đúc và ngược lại. Nếu một ứng dụng chấp nhận mã thông báo được bọc làm phương tiện trao đổi hoặc sử dụng tài sản được bọc làm tiền tệ, các nhà phát triển và người dùng của ứng dụng tin tưởng nhà cung cấp cầu nối để đảm bảo tài sản “thực” hỗ trợ mã thông báo được bọc.

Tại sao chúng ta cần cầu?

Khả năng thực hiện giao dịch với phiên bản tổng hợp của một tài sản trên một chuỗi từ xa - được kích hoạt bởi các cầu nối tạo ra những biểu tượng của tài sản - là một tính năng mạnh mẽ và cho phép các nhà phát triển và người dùng cùng nhau tận dụng những lợi ích của khả năng tương tác giữa các chuỗi. Một số lợi ích này bao gồm tiếp cận với nhiều thanh khoản hơn, tiếp cận với người dùng mới và linh hoạt cho người dùng (có thể tương tác với các ứng dụng ưa thích từ các chuỗi khác nhau mà không gặp khó khăn).

Để hiểu rõ hơn về cách thức hoạt động này trong thực tế và tại sao nó quan trọng đối với cả nhà phát triển và người dùng, hãy xem xét một ví dụ cụ thể sử dụng một sàn giao dịch phi tập trung hư cấu có tên là BobDEX. Ví dụ này sẽ thể hiện cách các token được bọc cho phép mở rộng qua chuỗi cross trong khi nêu bật cả những lợi ích và những vấn đề tiềm ẩn có thể phát sinh:

BobDEX là một sàn giao dịch Automated Market Maker (AMM) mà Bob tạo trên Ethereum để cho phép hoán đổi tin cậy giữa các tài sản khác nhau. BobDEX có một token native là $BOB, đồng thời là một token quản trị và một token thưởng LP. Trong trường hợp sau, BobDEX phát hành các token BOB cho nhà cung cấp thanh khoản (LP), cho phép người dùng cung cấp thanh khoản vào một pool nhận được một phần trăm phí được trả bởi người dùng DEX hoán đổi tài sản được gửi vào pool.

Phần trăm thị trường của BobDEX đã tăng đáng kể, nhưng các hạn chế của Ethereum L1 đang ngăn cản sự phát triển tiếp theo. 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ễ truyền giao dịch; tương tự, các người dùng khác mong muốn tiếp xúc với giá của token $BOB mà không cần phải giữ token $BOB gốc trên Ethereum.

Để giải quyết vấn đề, Bob triển khai một phiên bản của BobDEX trên Arbitrum (một hình thức Layer 2 (L2) rollup với phí thấp, khả năng xử lý cao) và triển khai một phiên bản wrapped của token BOB (wBOB) trên L2 thông qua cầu nối Arbitrum-Ethereum. BobDEX trên Arbitrum giống hệt BobDEX trên Ethereum, ngoại trừ việc sử dụng wBOB—không phải là token BOB gốc—cho phần thưởng LP và quản trị.

Sự khác biệt giữa các mã token ứng dụng (wrapped BOB so với native BOB) không tạo ra sự khác biệt từ quan điểm của người dùng (ví dụ, nhà cung cấp thanh khoản) tương tác với BobDEX trên Arbitrum. Vì các mã token wBOB được bảo đảm bằng các mã token BOB thực tế được giữ trong cầu nối Arbitrum-Ethereum, các chủ sở hữu mã token wBOB có thể dễ dàng đổi chúng thành các mã token BOB ERC-20 native trên Ethereum bằng cách tương tác với hợp đồng cầu nối.

Tình hình là một thắng lợi cho Bob và người dùng:

1. Bob có thể thu hút thêm người dùng, đặc biệt là những người muốn phí gas thấp và xác nhận giao dịch nhanh khi giao dịch trên BobDEX
2. LP có thể kiếm được phần thưởng từ việc 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 lâu của Ethereum
3. Người hodlers có thể mua các token wBOB trên thị trường để thu lợi từ sự thay đổi giá của các token BOB mà không cần tương tác với hợp đồng BOB ERC-20 trên Ethereum

Các lợi ích của việc nối cũng mở rộng đến việc tăng cường sự đổi mới có thể ghép nối và mở khóa các trường hợp sử dụng mới tận dụng thanh khoản của một token đã được nối. Ví dụ, Alice có thể tạo ra một giao protocô cho vay gọi là AliceLend trên Arbitrum mà chấp nhận wBOB là tài sản đảm bảo từ người vay để mở rộng tiện ích của wBOB và tạo ra một thị trường mới chocho vay và mượn.

Những người cho vay cung cấp thanh khoản cho AliceLend chắc chắn sẽ nhận được tiền gửi: nếu người dùng không trả nợ vay, AliceLend sẽ tự động đấu giá các token wBOB được gửi làm tài sản đảm bảo để bồi thường cho những người cho vay. Trong trường hợp này, người mua tài sản đảm bảo wBOB bị thanh lý sẽ đảm nhận vai trò của LP trên BobDEX và có cùng bảo đảm rằng token wBOB có thể được trao đổi 1:1 cho token BOB ban đầu.

Chuỗi cross bridging ở dạng hiện tại đã cung cấp một giải pháp thực tế để đảm bảo tính tương thích giữa các Ethereum L2 (trước đó là các hệ thống độc lập)và tạo điều kiện cho các ứng dụng mới (ví dụ, cho vay cross-chain và cross-chain DEXes). Nhưng hệ sinh thái kết nối hiện đang gặp phải các hạn chế gây trở ngại cho sự phát triển tiếp theo, như tính không thể thay thế của các token cross-chain - chúng ta sẽ tìm hiểu vấn đề này chi tiết sau đây.

Tại sao token kết nối trở thành không thể thay thế?

Quy trình cầu nối khóa và đúc mô tả trước đó trông đơn giản trên giấy nhưng, trong thực tế, đòi hỏi rất nhiều nỗ lực thiết kế kỹ thuật và cơ cấu để hoạt động đúng cách.

Thử thách đầu tiên là đảm bảo rằng những phiên bản đóng gói của một token được nối tiếp luôn được hỗ trợ bởi các token bản địa bị khóa trên chuỗi nguồn. Nếu một kẻ tấn công tạo ra phiên bản của một token tại một chuỗi từ xa mà không gửi tiền tệ bản địa tại chuỗi nguồn, nó có thể làm cho cầu nối trở nên vô giá trị bằng cách hoán đổi (phiên bản được tạo ra bằng gian lận) của các token được đóng gói với các token bản địa trên chuỗi gốc và ngăn chặn người dùng hợp pháp - những người đã gửi tiền tại hợp đồng cầu nối trước khi đóng gói token - khỏi rút tiền gửi.

Thách thức thứ hai tinh vi hơn và phát sinh từ bản chất của các token được nối: hai biểu diễn của một token được đúc bởi các nhà cung cấp cầu ở cùng một chuỗi từ xa không thể trao đổi 1:1 cho một cái khác. Chúng ta có thể sử dụng một ví dụ khác về hai người dùng cố gắng trao đổi token được nối thông qua các tuyến đường khác nhau để minh họa khía cạnh này của vấn đề liên quan đến việc di chuyển token qua các chuỗi:

• Alice cầu nối USDC từ Ethereum đến Arbitrum thông qua cầu Arbitrum cổ điển và nhận 200 USDC.e trên Arbitrum, trong khi Bob cầu nối USDC đến Arbitrum thông qua Axelar và nhận 200 axlUSDC trên Arbitrum. Alice và Bob ký một 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 thông qua axlUSDC và chỉ nhận được 200 USDC, kèm theo thông báo giải thích rằng cầu nối chỉ có 200 USDC mà nó có thể cung cấp cho Bob. Bob bối rối vì các token ERC-20 được bao bọc nên được coi là “đồng dạng” và không nên có sự chênh lệch ngăn cản bất kỳ ai trao đổi token ERC-20 1:1 trên bất kỳ ứng dụng nào.
• Bob học một bài học khó khăn về cross-chain bridging: “fungible ERC-20 token” không luôn có nghĩa là “bạn có thể trao đổi token này một cách 1:1 với các token ERC-20 khác trên các ứng dụng”. Sự cố giao dịch mạo hiểm của Bob với Alice - mạo hiểm vì Alice có thể không trả lại các token - đã đi sai lầm một cách đáng kinh ngạc.

Bob sau khi bị lừa đảo trên một trao đổi

Tại sao Bob không thể rút 400 USDC nếu anh ta và Alice nhận được phiên bản được bọc của cùng một tài sản cơ bản trên chuỗi đích? Bạn sẽ nhớ rằng chúng tôi đã đề cập đến việc các token được phát hành trên các chuỗi khác nhau không tương thích, vì vậy biểu diễn của một token gốc được phát hành trên một chuỗi không gốc là một IOU từ cầu nối hứa trả lại một số lượng token gốc (tùy thuộc vào số lượng còn lại) khi người dùng muốn cầu nối trở lại chuỗi gốc của token.

Giá trị của mỗi token được kết nối qua cầu nối được liên kết với nhà cung cấp cầu nối chịu trách nhiệm giữ tiền gửi trên chuỗi gốc và đúc biểu tượng trên chuỗi đích; Nhà cung cấp cầu nối của Bob chỉ có thể trả cho Bob 200 USDC vì đó là số tiền nó có để chi trả từ tiền gửi của mình; 200 USDC của Alice không thể rút qua nhà cung cấp cầu nối của Bob vì nó không bao giờ nhận được tiền gửi hoặc phát hành một IOU cho Alice. Alice phải rút tiền USDC bị khóa của mình từ Arbitrum trên Ethereum và cầu nối qua nhà cung cấp cầu nối của Bob trước khi Bob có thể truy cập vào các 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 nối cầu giữa các lĩnh vực nơi mà nhiều phiên bản không thể thay thế được của tài sản gốc được tạo ra bởi các nhà cung cấp cầu cạnh tranh. Một vấn đề khác với các phiên bản 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 cùng một hồ bơi thanh khoản duy nhất.

Sử dụng ví dụ trước, nếu chúng ta có axlUSDC và USDC.e trên chuỗi và muốn hoán đổi chúng thành ETH và ngược lại, chúng ta phải triển khai hai nhóm thanh khoản — ETH / axlUSDC và ETH / USDC.e. Điều này dẫn đến một cuộc thăm dò được gọi là “phân mảnh thanh khoản” — một tình huống mà các nhóm giao dịch có tính thanh khoản nhỏ hơn mức họ có thể có vì có nhiều nhóm phù hợp về cơ bản với cùng một cặp giao dịch.

Giải pháp là có một phiên bản “chuẩn” duy nhất của một token lưu hành trên chuỗi đích để Bob và Alice có thể trao đổi token mà không cần mỗi người rút tiền từ cầu nối tại chuỗi nguồn. Việc có một token chuẩn mỗi chuỗi cũng có lợi cho các nhà phát triển, vì người dùng có thể nhanh chóng chuyển đổi giữa các hệ sinh thái mà không cần phải đối mặt với vấn đề về tính thanh khoản của token.

Vậy, chúng ta phải làm thế nào để triển khai phiên bản chính thức của một token trên mỗi chuỗi mà nó mong đợi được sử dụng và chuyển giữa? Phần tiếp theo sẽ giải thích một số cách tiếp cận phổ biến để tạo các token chính thức trên nhiều chuỗi.

Triển khai token chuỗi cổ điển trên các chuỗi khác nhau

Việc tạo một token chuỗi chuẩn không phải là điều dễ dàng, và có nhiều lựa chọn với sự đánh đổi và ưu điểm khác nhau. Khi tạo một token chuỗi chuẩn, chúng ta thường cần nghĩ về việc tin tưởng ai về sự tồn tại của các IOUs hậu thuẫn giá trị của một token cụ thể. Giả sử bạn là người tạo ra một token và bạn muốn nó có thể sử dụng và chuyển nhượng trên các chuỗi khác nhau mà không gặp vấn đề về tính đồng dạng; bạn có bốn lựa chọn:

1. Mint canonical tokens qua cầu nối canonical rollup/sidechain
2. Tạo mã thông báo đại diện thông qua nhà cung cấp cầu nối bên thứ ba
3. Tạo ra các token chuẩn qua một cầu nối của người phát hành token
4. Phát hành đa chuỗi trực tiếp với giao dịch atomic

Ba tùy chọn đầu tiên dựa trên các cơ chế cầu nối khác nhau để tạo điều kiện cho việc chuyển đổi mã thông báo giữa các chuỗi khác nhau. Tuy nhiên, như một nhà tạo mã thông báo, bạn cũng có thể chọn bỏ qua cơ chế cầu nối hoàn toàn bằng cách phát hành mã thông báo theo cách tự nhiên trên mỗi chuỗi được hỗ trợ. Theo phương pháp này, thay vì phụ thuộc vào các mã thông báo bọc hoặc cơ sở hạ tầng cầu nối, bạn duy trì các triển khai mã thông báo riêng biệt nhưng được phối hợp trên các chuỗi - với các giao dịch đổi mới nguyên tử cho phép trao đổi không đáng tin cậy giữa các chuỗi.

Phương pháp này yêu cầu cơ sở hạ tầng tinh vi để duy trì tính thanh khoản trên các chuỗi và tạo điều kiện cho giao dịch tức thì, tuy nhiên. Sự phức tạp trong việc quản lý nhiều phiên bản cài đặt gốc đã giới hạn phương pháp này chỉ dành cho các giao thức lớn với nguồn lực kỹ thuật đáng kể.

1. Tạo ra các token cơ bản thông qua cầu nối canonical rollup/sidechain

Nếu một chuỗi có một cầu nối cổ đại (được thánh hiến), bạn có thể gán quyền tạo ra phiên bản của mã token giao thức của bạn cho người dùng muốn cầu nối từ chuỗi gốc. Các giao dịch được định tuyến qua cầu nối cổ đại của chuỗi (tiền gửi và rút tiền) thường được xác minh bởi bộ xác minh của chuỗi, đảm bảo rằng tiền gửi trên chuỗi gốc đáng tin cậy hỗ trợ tất cả các phiên bản được tạo ra.

Mặc dù cầu nối chuỗi cross đang tạo ra biểu diễn chuẩn của một token, các biểu diễn khác vẫn sẽ tồn tại. Điều này xảy ra đơn giản vì cầu nối chuỗi cross thường có các hạn chế ngăn chặn họ khỏi việc cung cấp trải nghiệm tốt nhất cho người dùng. Ví dụ, việc cầu nối từ Arbitrum/Optimism sang Ethereum thông qua cầu nối chuỗi cross của rollup gây ra một sự trễ 7 ngày vì các giao dịch phải được xác minh bởi người xác minh—và có thể bị tranh cãi bởi một bằng chứng gian lận, nếu không hợp lệ—trước tầng giải quyết cuộc cách mạng (Ethereum—giải quyết một lô giao dịch.

Người dùng Rollup muốn thoát ra nhanh hơn phải sử dụng những nhà cung cấp cầu nối khác có thể tiếp quản quyền sở hữu của các thoát rollup đang chờ xử lý và cung cấp thanh khoản trước cho chuỗi mục tiêu mà người dùng mong muốn. Khi những cầu nối như vậy sử dụng mô hình khoá và phát hối truyền thống, chúng ta sẽ có nhiều phiên bản được bọc của một mã thông báo được phát hành bởi các giao thức khác nhau và đối mặt với những vấn đề tương tự như đã được mô tả trước đây.

Các sidechain với bộ xác nhận độc lập có độ trễ thấp hơn vì việc rút tiền được thực hiện sau khi giao thức đồng thuận của sidechain xác nhận một khối chứa giao dịch rút tiền. Cầu Polygon PoS là một ví dụ về một cầu cơ bản kết nối một sidechain với các miền khác nhau (bao gồm Ethereum rollups và Ethereum mainnet).

Lưu ý: Chúng tôi đề cập đến chuỗi PoS gốc của Polygon, không phải chuỗi cross.chuỗi validium được kế hoạch sẽ sử dụng Ethereum để thanh toán. Polygon sẽ trở thành L2 sau khi quá trình chuyển đổi từ sidechain được bảo mật bởi các trình xác thực bên ngoài sang validium được bảo mật bởi sự đồng thuận Ethereum hoàn tất.

Tuy nhiên, cầu sidechain cũng chia sẻ một điểm yếu với cầu chuẩn rollup: người dùng chỉ có thể cầu giữa một cặp chuỗi được kết nối. Họ không thể cầu sang các blockchain khác bằng cầu chuẩn. Ví dụ, bạn không thể cầu từ Arbitrum sang Optimism hiện nay bằng Cầu Arbitrum hoặc cầu từ Polygon sang Avalanche qua Cầu PoS Polygon.

1.1. Tạo ra các token chuỗi sử dụng cầu nối thanh khoản

Phụ thuộc vào cầu nối bản địa của một rollup để di chuyển các token cơ bản đi kèm với một số vấn đề, như thanh khoản kém và chậm trễ trong việc di chuyển tài sản. Các giao thức giải quyết vấn đề này bằng cách làm việc với các cầu nối thanh khoản để tạo điều kiện cho việc rút tiền nhanh chóng và cầu nối có độ trễ thấp.

Theo sắp xếp này, cầu nối thanh khoản được phê duyệt (a) tạo ra biểu diễn bọc của token của giao thức trên chuỗi nguồn (b) đổi token bọc để biểu diễn chính thức tại điểm đến thông qua một hồ bơi thanh khoản thuộc giao thức.

Biểu diễn cơ bản của mã thông báo trên chuỗi đích thường là phiên bản được đúc bởi cầu nối chuỗi phụ/phân tầng cơ bản, mặc dù có các ngoại lệ (như chúng ta sẽ thấy sau). Ví dụ, phiên bản cơ bản của USDT trên Optimism là opUSDT được đúc bởi Cầu nối Optimism.

Mỗi cầu nối thanh khoản hoạt động như một DEX với một Automated Market Maker (AMM) để thực hiện trao đổi giữa các cặp tài sản được gửi trong các hồ bơi thanh khoản khác nhau. Để khuyến khích cung cấp thanh khoản, các hồ bơi AMM chia sẻ một phần phí trao đổi cho những người nắm giữ các token quan trọng trong các hợp đồng hồ bơi.

Điều này tương tự như mô hình của Uniswap; sự khác biệt duy nhất đáng chú ý là cặp tài sản thường là biểu diễn của cầu nối thanh khoản của một token so với biểu diễn cơ bản. Ví dụ, một người dùng chuyển USDT sang Optimism qua Hop sẽ phải đổi hUSDT trên Optimism qua cặp giao dịch huSDT:opUSDT.

Quy trình cho việc nối thông qua một cầu thanh khoản sẽ trông như thế này:

• Khóa token bản địa trên chuỗi nguồn
• Đại diện cầu mint của token bản địa trên chuỗi mục tiêu
• Hoán đổi biểu diễn được cầu nối với biểu diễn chuẩn trên chuỗi mục tiêu thông qua AMM pool
• Gửi tokens chuỗi cross cho người dùng

Quy trình này tương tự cho tất cả các cầu nối thanh khoản (Across, Celer, Hop, Stargate, v.v.). Tuy nhiên, thông thường nó được trừu tượng hóa đối với người dùng cuối - đặc biệt là bởi các trình giải/quyết và sẽ cảm nhận như một giao dịch duy nhất mặc dù liên quan đến nhiều yếu tố chuyển động.

Khi cầu nối trở lại chuỗi nguồn, người dùng đốt cháy biểu tượng đại diện hoặc hoán đổi token đại diện cânonical với biểu tượng đại diện cầu nối thông qua AMM trước khi đốt cháy biểu tượng đó và cung cấp biên nhận chứng minh đốt cháy. Sau khi được xác nhận, người dùng có thể rút ra các token bản địa bị khóa ở đầu. (Giống như thao tác trước đó, chi tiết xử lý token trở lại chuỗi gốc được ẩn khỏi người dùng và được quản lý bởi những người giải quyết vấn đề).

Viaduct nước là xuất sắc, chủ yếu là vì nó sửa chữa vấn đề độ trễ trong viaduct; ví dụ, Hop cho phép các bên chuyên biệt được biết đến là “Bonders” điều chứng sự hợp lệ của giao dịch rút tiền của người dùng trên L2 và trả trước chi phí rút tiền từ cầu nối L1 của viaduct. Mỗi Bonder vận hành một nút đầy đủ cho chuỗi L2 và có thể xác định xem giao dịch rút tiền của người dùng cuối cùng sẽ được xác nhận trên L1, giảm thiểu rủi ro người dùng khởi xướng một giao dịch rút tiền gian lận và gây thiệt hại cho Bonder.

Các cầu thanh khoản cũng cho phép người dùng chuyển đổi giữa nhiều chuỗi hơn, khác với các cầu chuẩn; ví dụ, Hop cho phép người dùng chuyển đổi giữa Arbitrum và Optimism mà không cần rút tiền về Ethereum trước. Giống như việc chuyển đổi nhanh từ L2→L1, việc chuyển đổi nhanh từ L2→L2 yêu cầu Bonders chạy một nút đầy đủ cho chuỗi nguồn L2 để xác nhận rút tiền trước khi trả chi phí đúc token cho người dùng trên chuỗi đích L2. Điều này cho phép sự kết hợp linh hoạt hơn giữa rollups và cải thiện đáng kể trải nghiệm người dùng, khi họ có thể chuyển đổi token qua các rollups mà không gặp vấn đề nào.

Tuy nhiên, việc kết nối thanh khoản cũng có những hạn chế ảnh hưởng đến tính hữu dụng của việc sử dụng cầu của một chuỗi để tạo ra biểu tượng được phong tỏa trên chuỗi L2 / L1.

Nhược điểm của cầu thanh khoản

1. Slippage

Slippage là sự khác biệt về số lượng token dự kiến và nhận được khi tương tác với AMM. Slippage xảy ra do AMM định giá các giao dịch trao đổi theo thanh khoản hiện tại trong một pool - giá cả được duy trì sao cho cân bằng được giữa số dư của mỗi tài sản trong một cặp sau khi giao dịch được thực hiện, điều này có thể thay đổi giữa thời điểm người dùng khởi tạo một giao dịch và thời điểm trao đổi được thực hiện.

Sự thiếu thanh khoản cho tài sản được nối chuỗi cũng có thể làm tăng độ trượt giá; nếu hồ bơi không có đủ thanh khoản để cân bằng một bên của hồ bơi, một giao dịch lớn có thể dịch chuyển giá một cách đáng kể và dẫn đến người dùng thực hiện trao đổi với giá cao hơn. Nhà bình đẳng thị trường được kỳ vọng sẽ giúp điều chỉnh sự chênh lệch giữa các hồ bơi giao dịch cùng một tài sản nhưng có thể bị ngăn cản khỏi giao dịch bình đẳng thị trường liên quan đến các mã thông báo có hoạt động / giá trị giao dịch thấp.

Đ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 cross-chain khi họ phải tính đến các trường hợp biên mà trong đó sự trượt giá xảy ra; người dùng không thể hoàn thành một hoạt động chuỗi cross do nhận số lượng token thấp hơn trên một hoặc nhiều chuỗi đích.

Các ứng dụng như cầu nối tổng hợp (không thể biết liệu một cầu nối thanh khoản có đủ thanh khoản để thực hiện một giao dịch trên chuỗi đích mà không xảy ra trượt giá) giải quyết vấn đề bằng cách chỉ định một ngưỡng chịu đựng trượt giá tối đa và sử dụng nó để cung cấp báo giá cho người dùng. Mặc dù điều này ngăn chặn việc hủy giao dịch, người dùng luôn mất một phần trăm của token được cầu nối - bất kể thanh khoản trong các hồ bơi AMM của cầu nối.

2. Hạn chế thanh khoản

Thách thức cơ bản với các cầu nối thanh khoản là yêu cầu tuyệt đối về đủ thanh khoản trên chuỗi đích. Khác với các cầu nối lock-and-mint truyền thống, trong đó việc đúc token được trực tiếp hỗ trợ bởi tài sản bị khóa, các cầu nối thanh khoản phụ thuộc vào sự có sẵn của token trong các AMM pool để hoàn thành các giao dịch chéo chuỗi. Khi thanh khoản giảm dưới ngưỡng nguy hiểm, cơ chế cầu nối toàn bộ có thể ngừng hoạt động hiệu quả.

• Các hoạt động cầu có thể hoàn toàn ngừng lại nếu thanh khoản giảm quá thấp, ngăn ngừa người dùng hoàn thành các giao dịch chuyển tiền theo ý định;
• Người dùng có thể bị buộc phải chia nhỏ các giao dịch lớn thành các giao dịch nhỏ hơn để tránh làm cạn kiệt tính thanh khoản của hồ bơi;
• Trong các giai đoạn biến động cao hoặc áp lực thị trường, nhà cung cấp thanh khoản có thể rút khỏi các nhóm, chính xác khi chức năng cầu nối cần thiết nhất;
• Quá trình khởi tạo cặp token mới trở nên đặc biệt thách thức, vì yêu cầu có thanh khoản ban đầu đáng kể để cầu nối hoạt động.

Yêu cầu thanh khoản tạo ra một phụ thuộc vòng tròn: cầu cần có thanh khoản đáng kể để hoạt động đáng tin cậy, nhưng thu hút các nhà cung cấp thanh khoản đòi hỏi phải chứng minh sự sử dụng cầu nhất quán và tạo ra phí. Vấn đề gà và trứng này đặc biệt nghiêm trọng đối với các mã thông báo mới hoặc ít được giao dịch, có thể gặp khó khăn trong việc duy trì đủ thanh khoản trên nhiều chuỗi.

3. Động cơ không cùng hướng

Một cầu nối thanh khoản hữu ích trong phạm vi mà nó có thể thực hiện các giao dịch trao đổi từ biểu diễn đã được cầu nối sang mã thông báo chính trên chuỗi đích mà không làm người dùng chịu mất mát quá mức; các chi phí gas khi tương tác với cầu nối cũng xác định giá trị của một cầu nối thanh khoản từ quan điểm của người dùng. Do đó, các tổ chức tổng hợp cầu nối và nhóm dự án, khi phát hành một mã thông báo, ưu tiên cầu nối dựa trên lượng thanh khoản và chi phí giao dịch.

Trong khi điều này đảm bảo người dùng cầu nối token của dự án hoặc sử dụng trình tự tập trung cầu nối để gửi token qua chuỗi có trải nghiệm người dùng tốt hơn, việc lựa chọn cầu nối dựa trên thanh khoản đặt cầu nối không thể chi tiêu cho cung cấp động viên tài trợ thanh khoản (LP) ở thế thua thiệt. Hơn nữa, việc lựa chọn cầu nối dựa trên phí giao dịch thuần túy thiên vị cuộc cạnh tranh ủng hộ cầu nối áp dụng cách tiếp cận tập trung để giảm chi phí vận hành và có thể thu phí thấp hơn cho các giao dịch cầu nối. Trong cả hai trường hợp, cầu nối không cạnh tranh với có lẽ là chỉ số quan trọng nhất: bảo mật.

Các cầu nối dựa trên thanh khoản cũng không ưa chuộng các tài sản dạng dài đuôi có hoạt động giao dịch thấp hơn (làm cho chúng ít có khả năng thu hút LP). Người phát hành các mã thông báo dạng dài đuôi (hoặc mã thông báo mới có khối lượng cầu nối thấp) sẽ phải thiết lập các bể AMM và khởi động thanh khoản để bao phủ việc trao đổi các mã thông báo gốc (được cầu nối qua cầu nối thanh khoản) thành biểu diễn tiêu chuẩn của mã thông báo của người phát hành hoặc làm việc với các nhà điều hành cầu nối để tăng cường động lực tài chính cho LP cung cấp thanh khoản cho tài sản đó.

4. Giao diện người dùng kém chất lượng cho việc kết nối chuỗi cross

Các cầu nối thanh khoản là một cải tiến so với các cầu nối chuẩn, nhưng cũng không tránh được các vấn đề UX. Ngoài việc phải chịu sự trượt giá trên các giao dịch trên chuỗi cross-chain, người dùng cũng có thể không thể hoàn thành giao dịch cầu nối ngay lập tức trên chuỗi đích vì cầu nối không có đủ thanh khoản để thực hiện giao dịch với token chuẩn trên chuỗi đích. Cầu nối không thể biết được có bao nhiêu thanh khoản cho một cặp tài sản sẽ tồn tại đến khi tin nhắn của người dùng để trao đổi token đến chuỗi đích, vì vậy trường hợp biên này hầu như không thể tránh được.

Người dùng có hai lựa chọn trong tình huống này (cả hai đều không tối ưu):

• Đợi đến khi cầu có đủ thanh khoản để hoàn tất việc hoán đổi và rút các token chính thức. Điều này không tối ưu vì sự trì hoãn trong giao dịch cầu và người dùng không thể biết liệu họ có nhận được số lượng token được trích dẫn ban đầu hay không, vì thanh khoản của pool có thể thay đổi tùy ý trong thời gian rất ngắn.
• Nhận biểu tượng đặc quyền của cầu (ví dụ, hUSDT cho Cầu Hop). Điều này không phải là tối ưu vì hầu hết các ứng dụng sẽ ưu tiên tích hợp với biểu tượng cơ bản của một token bản địa (ví dụ, opUSDT được phát hành bởi Cầu Optimism) và có thể không chấp nhận tài sản được bọc của người dùng.

2. Mint canonical tokens qua một cầu nối bên thứ ba canonical

Một ứng dụng đa chuỗi có thể giải quyết vấn đề về non-fungible bridged tokens bằng cách chọn một cầu duy nhất để tạo các biểu diễn chuẩn của token của ứng dụng trên mỗi chuỗi nơi ứng dụng được triển khai. Như với các cầu chuẩn tạo các biểu diễn được phê duyệt của token dự án, phương pháp này yêu cầu ánh xạ các token được tạo ra trên các chuỗi từ xa với hợp đồng token được triển khai trên chuỗi chính của dự án - đảm bảo nguồn cung cấp token giữ nguyên trên toàn cầu. Nhà cung cấp cầu phải theo dõi việc tạo ra và đốt cháy token và đảm bảo các hoạt động tạo và đốt cháy token luôn đồng bộ với nguồn cung cấp token trên chuỗi chính.

Việc sử dụng một nhà cung cấp cầu duy nhất mang lại sự linh hoạt hơn cho các nhóm dự án, đặc biệt là khi các cầu của bên thứ ba được khích lệ để hỗ trợ cầu kết nối giữa một loạt các hệ sinh thái rộng lớn hơn so với các cầu chuẩn chỉ kết nối tối đa một chuỗi. Nếu một cầu tồn tại trên tất cả các chuỗi mà một ứng dụng được triển khai, người dùng có thể nhanh chóng di chuyển qua chuỗi khác mà không cần rút về chuỗi gốc; nhà cung cấp cầu chỉ cần đảm bảo rằng các token được tạo ra trên chuỗi đích A được đốt trước khi người dùng tạo ra token trên chuỗi đích B và các token chuẩn trên chuỗi B được (đồng) ánh xạ với token trên chuỗi gốc.

Vấn đề của các token cầu không thể thay thế cũng được loại bỏ; miễn là người dùng sử dụng nhà cung cấp cầu được phê duyệt, họ luôn có thể trao đổi chúng 1:1 với các token cầu khác. Phương pháp này cũng khắc phục những vấn đề liên quan đến thanh khoản trong mô hình cầu tiêu chuẩn:

• Người dùng không phải chịu sự trượt giá trên các giao dịch cầu nối vì nhà cung cấp cầu nối không cần chuyển đổi biểu diễn của mình thành một biểu diễn chuẩn thông qua một AMM - token của nhà cung cấp cầu nối là biểu diễn chuẩn của token được kết nối trên mọi lĩnh vực. Giá trị của các biểu diễn này được cố định vào giá trị của các token bị khóa bởi nhà cung cấp cầu nối trên chuỗi native của token.
• Người dùng gặp ít hoặc không gặp trễ trong quá trình cầu nối vì nhà cung cấp cầu nối có thể tạo ra phiên bản bọc trên chuỗi đích ngay sau khi tin nhắn mint() đến đích.
• Nhà phát triển có thể giao việc quản lý triển khai token đa chuỗi cho các nhà điều hành cầu mà không cần lo lắng về việc khởi động thanh khoản AMM hoặc các chương trình khuyến mãi cung cấp thanh khoản.

Một số ví dụ về các token cung cấp bởi một nhà cung cấp cầu duy nhất trong tự nhiên bao gồm Mã thông báo Fungible Omnichain (OFT) của LayerZero, Dịch vụ Mã thông báo Interchain (ITS) của Axelar, xAsset của Celer và anyAsset của Multichain. Tất cả các ví dụ đều là mã thông báo độc quyền và không tương thích với các phiên bản của cùng một mã thông báo gửi qua một nhà cung cấp cầu khác. Chi tiết tinh tế này nhấn mạnh một số vấn đề với phương pháp xử lý các token cầu. Cụ thể là sau đây:

• Khóa nhà cung cấp
• Mất chủ quyền
• Tiếp xúc cao với sự cố sập cầu
• Mất các tính năng tùy chỉnh của token trên các chuỗi mục tiêu
• Bị hạn chế trong chuỗi được hỗ trợ bởi nhà cung cấp
• Không thể duy trì cùng địa chỉ mã thông báo trên tất cả các chuỗi mong muốn, điều này có thể gây hại cho an ninh người dùng hoặc làm cho họ dễ bị lừa đảo

Nhược điểm của việc sử dụng cầu nối bên thứ ba theo chuẩn

1. Vendor lock-in

Chọn một nhà cung cấp cầu nối duy nhất để tạo ra các biểu diễn văn bản chính thức trên một hoặc nhiều chuỗi tiếp tục đưa nhà phát triển vào rủi ro bị khóa bởi nhà cung cấp. Khi mỗi nhà cung cấp cầu nối tạo ra một biểu diễn độc quyền tương thích chỉ với cơ sở hạ tầng của nó (và các dự án hệ sinh thái tích hợp), mô hình nhà cung cấp cầu duy nhất khóa một nhà phát hành mã thông báo vào dịch vụ cầu nối cụ thể mà không có khả năng chuyển sang cầu nối khác trong tương lai.

Có thể chuyển đổi nhà cung cấp cầu nối, nhưng chi phí chuyển đổi đủ cao để ngăn cản hầu hết các dự án đi theo con đường này. Để có một ý tưởng sơ bộ, giả sử một nhà phát triển (mà chúng tôi sẽ gọi là Bob) đã phát hành một mã thông báo (BobToken) trên Ethereum và chọn LayerZero OFT để tạo ra phiên bản chính thức của BobToken trên Optimism, Arbitrum và Base. BobToken có cung cấp cố định là 1.000.000 mã thông báo, và các mã thông báo được tạo ra thông qua cầu nối LayerZero chiếm 50% tổng cung cấp BobTokens hiện có.

Sắp xếp kinh doanh diễn ra một cách trôi chảy cho đến khi Bob quyết định người dùng sẽ tốt hơn khi kết nối BobTokens thông qua một dịch vụ cầu nối cạnh tranh (ví dụ, Axelar). Tuy nhiên, Bob không thể đơn giản nói lên và nói, “Tôi đang chuyển sang Axelar ITS để tạo ra các biểu diễn chính thức của BobToken trên Optimism, Base và Arbitrum”; vì các token OFT và ITS không tương thích, Bob rủi ro tạo ra phiền toái cho cả người dùng cũ và người dùng mới khi có thể hai BobToken không thể hoán đổi (đưa lại vấn đề chúng ta đã mô tả trước đây). Hơn nữa, các ứng dụng tích hợp với phiên bản BobToken của LayerZero không thể chấp nhận phiên bản BobToken của Axelar như là một phương thức thay thế - làm phân mảnh tính thanh khoản cho BobToken trên các chuỗi khác nhau nơi các biểu diễn cạnh tranh của BobToken cùng tồn tại.

Để việc chuyển đổi trở nên có thể, Bob cần thuyết phục người dùng mở bao bọc đại diện của BobToken được đúc thông qua LayerZero bằng cách gửi một giao dịch đốt các token OFT được cầu nối và mở khóa BobTokens trên Ethereum. Người dùng hiện có thể chuyển sang biểu diễn canon mới của BobToken bằng cách khóa token với Axelar trên Ethereum và nhận BobTokens canon (được ánh xạ với nguồn cung của hợp đồng token trên Ethereum) trên chuỗi đích. Điều này không chỉ tốn kém mà còn gây ra chi phí và chi phí vận hành lớn cho các nhóm quản lý dự án DAO, vì vậy việc tuân theo nhà cung cấp được chọn thường là tùy chọn an toàn nhất.

Tuy nhiên, điều này để lại vị trí khó khăn cho các nhà phát triển như Bob khi các nhà cung cấp cầu nối có khả năng khóa chân khách hàng, làm cho việc chuyển đổi bất khả thi nếu một nhà cung cấp cầu nối không thực hiện các điều khoản của thỏa thuận, có một bộ tính năng giới hạn, thiếu tích hợp hệ sinh thái mở rộng, cung cấp trải nghiệm người dùng kém chất lượng, v.v. Nó cũng cung cấp cho các cầu nối với đòn bẩy gần như vô hạn: nhà cung cấp cầu nối có thể làm những điều tùy tiện như giới hạn tốc độ người dùng kết nối BobTokens mà không có lý do rõ ràng, tăng phí kết nối, hoặc thậm chí kiểm duyệt các hoạt động kết nối. Trong trường hợp này, Bob không thể làm gì hơn ngoài việc giữ tay trắng trợn, vì việc chấm dứt mối quan hệ thương mại với cầu nối bên thứ ba có vấn đề cũng phức tạp như việc tiếp tục với mối quan hệ kinh doanh.

2. Mất chủ quyền cho các giao thức

Phần kết luận của phần trước về ràng buộc nhà cung cấp đưa ra một vấn đề khác khi sử dụng một cầu thứ ba cổ điển: các nhà phát hành token đánh đổi quyền kiểm soát các token cầu cổ điển để đổi lấy sự tiện lợi lớn hơn và cải tiến UX. Để sử dụng ví dụ trước: BobToken trên Ethereum hoàn toàn nằm trong quyền kiểm soát của Bob khi 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, người sở hữu hợp đồng OFT phát hành biểu diễn cổ điển của BobToken trên những blockchain đó.

Trong khi Bob có thể mong đợi LayerZero sẽ điều chỉnh các biểu diễn chuẩn với thiết kế ban đầu của mã thông báo nguyên thủy, nhưng điều này không phải lúc nào cũng đúng. Trong các kịch bản xấu nhất, hành vi của BobToken trên Ethereum có thể không tương đồng đáng kể so với BobToken trên Optimism do nhà cung cấp cầu nối triển khai một phiên bản hợp đồng mã thông báo hoàn toàn khác nhau, gây ra vấn đề cho người dùng của giao thức. Vấn đề này cũng có thể trở nên nghiêm trọng hơn do các yếu tố chủ yếu-tác tử, trong đó mục tiêu và lợi ích của giao thức và nhà cung cấp cầu nối không tương đồng.

3. Tiếp xúc cao với sự cố cầu

Trong phương pháp đầu tiên, nơi các mã thông báo được nối cross-chain thông qua cầu nối chính thức của mỗi chuỗi, mối nguy hiểm đối với nhà phát hành mã thông báo từ một cuộc tấn công ảnh hưởng đến một cầu nối được giới hạn trong cầu nối đó. Ví dụ, giả sử một hacker thành công trong việc xâm nhập vào một cầu nối thanh khoản và tạo ra số lượng vô hạn của một mã thông báo đã được gói mà không cần gửi tài sản thế chấp. Trong trường hợp đó, nó chỉ có thể rút lên đến số lượng thanh khoản tối đa có sẵn cho tài sản đã được gói trong các hồ bơi thanh khoản (ví dụ: tạo cUSDT trên Optimism → đổi cUSDT thành opUSDT chính thức → rút opUSDT đến Ethereum qua cầu nhanh → đổi lấy USDT gốc trên Ethereum).

Trong mô hình cầu gác bên thứ ba, rủi ro đối với một nhà phát hành token từ một lỗ hổng ảnh hưởng đến cầu gác đối tác tương đương với tổng số lượng token mà một kẻ tấn công đúc được trên chuỗi từ xa mà cầu gác bị ảnh hưởng đã triển khai. Điều này là có thể vì mỗi biểu diễn cầu gác trên tất cả các chuỗi có thể được trao đổi 1:1 cho các token cầu gác được phát hành trên các chuỗi khác:

Giả sử một kẻ tấn công xâm nhập vào cầu bên thứ ba trên chuỗi B và đúc ra 1000 token (nơi mà token được phát hành ban đầu trên chuỗi A) mà không cần đặt cọc. Các token của kẻ tấn công trên chuỗi B không được ánh xạ vào hợp đồng chuỗi chủ, vì vậy nó không thể rút tiền từ chuỗi A. Tuy nhiên, nó có thể cầu đến chuỗi C và trao đổi 1000 token chuỗi B cho 1000 token chuỗi C - hãy nhớ rằng mỗi token liên chuỗi tương thích và có thể thay thế vì chúng có nguồn gốc từ cùng một dịch vụ cầu. Các token chuỗi C được ánh xạ vào hợp đồng chuỗi chủ vì chúng được đúc ra hợp pháp bởi người dùng đã khóa token trên chuỗi A (chuỗi chủ của token), cho phép kẻ tấn công đốt token trên chuỗi C và rút token bản địa trên chuỗi A và có thể hoàn tất chương trình bằng cách trao đổi token qua một CEX hoặc lối thoát fiat.

(Nguồn)

Mất các tính năng token tùy chỉnh

Khi sử dụng một cầu nối bên thứ ba theo chuẩn, người phát hành token 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 của token tồn tại trong việc triển khai ban đầu của mình. Điều này xảy ra vì nhà cung cấp cầu nối thường sử dụng các hợp đồng triển khai chuẩn ERC-20 mà có thể không hỗ trợ chức năng chuyên biệt có mặt trong triển khai ban đầu của token.

Các tính năng thông thường của token như ủy quyền bỏ phiếu (ZK), cơ chế rebasing (stETH, USDM), khả năng phí chuyển nhượng (memecoins), chức năng đen và trắng danh sách (USDT, USDC), chuyển khoản có thể tạm dừng và quy tắc hoặc quyền đặc biệt về việc đúc đồng thường bị loại bỏ khi token được cầu nối thông qua một nhà cung cấp bên thứ ba, vì phiên bản được cầu nối thường sử dụng một phiên bản ERC-20 cơ bản. Sự mất đi các tính năng này tạo ra sự không nhất quán trong cách hoạt động của token trên các chuỗi khác nhau và có thể gây ra sự cố với các tích hợp phụ thuộc vào các tính năng tùy chỉnh này.

Việc tiêu chuẩn hóa các token cầu nối, mặc dù đơn giản hơn đối với nhà cung cấp cầu nối, nhưng thực tế làm giảm khả năng của token và có thể cản trở khả năng duy trì hành vi token nhất quán trên toàn bộ hệ sinh thái đa chuỗi của ứng dụng. Những vấn đề như vậy có thể khiến việc mở rộng đa chuỗi trở thành một cơn ác mộng đối với các nhà phát triển và đại diện cho một rào cản đối với việc hiện thực hóa giấc mơ về ứng dụng tồn tại trên nhiều chuỗi.

Chuỗi hỗ trợ hạn chế

Các nhà phát hành Token trở nên phụ thuộc vào phạm vi mạng lưới và kế hoạch mở rộng của nhà cung cấp cầu nối mà họ đã chọn. Nếu nhà cung cấp cầu nối không hỗ trợ mạng blockchain cụ thể mà nhà phát hành token muốn mở rộng đến, họ phải đối mặt với hai lựa chọn không tối ưu:

• Chờ nhà cung cấp cầu nối thêm hỗ trợ cho chuỗi mong muốn, điều này có thể mất rất nhiều thời gian hoặc không bao giờ xảy ra do chi phí tích hợp cao (ví dụ: sự không tương đương EVM của thời đại ZKsync đã khiến nhiều ứng dụng phi tập trung không bao giờ triển khai trên nó)
• Sử dụng một nhà cung cấp cầu khác cho chuỗi cụ thể đó, điều này lại đưa ra vấn đề về các mã thông báo không thể thay thế và phân mảnh thanh khoản

Hạn chế này có thể ảnh hưởng đáng kể đến chiến lược phát triển của giao thức và khả năng tiếp cận người dùng mới trên các chuỗi mới nổi. Các nhà cung cấp cầu nối có thể ưu tiên hỗ trợ các chuỗi phổ biến trong khi bỏ qua các mạng nhỏ hơn hoặc mới mà có thể quan trọng chiến lược cho người phát hành token.

Địa chỉ token chuỗi cross không nhất quán

Các nhà cung cấp cầu nối bên thứ ba có thể triển khai các token được cầu nối với địa chỉ khác nhau trên mỗi chuỗi do đặc điểm của ngăn xếp công nghệ của họ-ví dụ, không hỗ trợ choCREATE2. Thiếu sự nhất quán về địa chỉ, điều này dẫn đến nhiều vấn đề về trải nghiệm người dùng (UX):

• Rủi ro an ninh: Người dùng phải xác minh địa chỉ mã thông báo khác nhau trên mỗi chuỗi, tăng nguy cơ tương tác với mã thông báo giả mạo;
• Độ phức tạp tích hợp: Nhà phát triển phải duy trì danh sách địa chỉ token hợp lệ cho mỗi mạng;
• Rủi ro lừa đảo gia tăng: Các tác nhân xấu có thể dễ dàng lừa người dùng bằng các token giả mạo vì không có địa chỉ nhất quán để kiểm tra.

Những hạn chế này, kết hợp với những vấn đề đã được thảo luận trước đó về việc bị kẹt trong hợp đồng với nhà cung cấp, mất chủ quyền và nhiều rủi ro khi cầu gãy, làm nổi bật những hạn chế đáng kể khi phụ thuộc vào các cầu của bên thứ ba cho việc triển khai token qua chuỗi. Hiểu biết này giúp xác định tại sao các giải pháp thay thế như ERC-7281 cần thiết để giải quyết những thách thức này một cách toàn diện hơn.

3. Tạo ra các token chuẩn thông qua cầu nối token-issuer

Nếu một nhà phát triển muốn giữ quyền kiểm soát tối đa về triển khai cross-chain của một dự án token, nó có thể quản lý việc phát hành các phiên bản chính thức của token trên các chuỗi từ xa. Điều này được mô tả là “tin tưởng nhà phát hành token,” vì giá trị của mỗi phiên bản token được kết nối với các token bị khóa trên chuỗi gốc của token bằng giao thức chịu trách nhiệm phát hành phiên bản ban đầu của token trên chuỗi nguồn.

Để phương pháp này hoạt động, người phát hành token phải thiết lập cơ sở hạ tầng để quản lý việc phát hành và tiêu hủy các token cầu nối chuỗi cross-chain (đồng thời đảm bảo nguồn cung toàn cầu được đồng bộ thông qua ánh xạ chuẩn).

Một số ví dụ đáng chú ý về biểu diễn cơ sở của một token được phát hành bởi người tạo token là Teleport của MakerDAOvà của Circle Giao thức Chuyển tiền qua chuỗi Cross (CCTP). Teleport cho phép người dùng di chuyển DAI chuẩn giữa Ethereum và các Ethereum rollups khác thông qua các hoạt động fast-path và slow-path. DAI được đốt trên một chuỗi và được tạo trên chuỗi đích. CCTP hoạt động tương tự và cho phép chuyển tiền giữa các chuỗi khác nhau của native USDC (do Circle phát hành) thông qua cơ chế đốt và tạo mới. Trong cả hai trường hợp, nhà phát hành token kiểm soát việc tạo và đốt các biểu diễn chuẩn của một token.

Phương pháp này cung cấp sự kiểm soát hoàn toàn đối với các token được cầu nối cho các giao thức. Và nó khắc phục vấn đề về việc biểu diễn không thể chuyển đổi của cùng một token một cách hiệu quả nhất có thể — chỉ tồn tại một phiên bản chính thức của token (được đúc bởi người phát hành tại chuỗi đích), đảm bảo người dùng có cùng trải nghiệm khi sử dụng một token trên mọi hệ sinh thái mà người phát hành token hỗ trợ.

Với phương pháp này, các ứng dụng cũng được hưởng lợi từ việc loại bỏ sự phân tán thanh khoản do các biểu đồ không chính thức, cầu nối đại diện cho token giao thức đang lưu thông trong cùng một hệ sinh thái. Các nhà phát triển cũng có thể xây dựng các ứng dụng chuỗi chéo mạnh mẽ hơn (ví dụ: giao dịch chuỗi chéo và cho vay chuỗi chéo) khi các cầu nối token pháp lý cho phép việc chuyển đổi token giữa các chuỗi tiết kiệm vốn, liền mạch và an toàn.

Tuy nhiên, nhược điểm của các cầu nối phát hành mã thông báo chính tắc là mô hình này chỉ khả thi đối với các dự án có đủ vốn để trang trải chi phí triển khai chuỗi chéo mã thông báo và duy trì cơ sở hạ tầng (oracles, keepers, v.v.) cần thiết để thực hiện đúc và đốt chuỗi chéo. Điều này cũng có tác dụng hơi không mong muốn là kết hợp chặt chẽ tính bảo mật của tài sản bắc cầu với mô hình bảo mật của giao thức.

Mối quan hệ này (giữa các phiên bản cầu nối của các token giao thức và bảo mật của giao thức) là hòa đồng vì an ninh của các token gốc hỗ trợ các biểu diễn chuẩn đã phụ thuộc vào bảo mật của giao thức, vì vậy người dùng và các nhà phát triển bên ngoài không đặt ra các giả định tin cậy mới. Điều này đặc biệt đúng với cầu nối stablecoinđược vận hành bởi các nhà phát hành như Circle và Maker (hiện là Sky)—người dùng đã tin tưởng các nhà phát hành đồng bạc ổn định đã có đủ tài sản để đền bù đồng bạc ổn định cho tiền tệ, vì vậy việc tin tưởng vào an ninh của một cầu đồng bạc ổn định không khó.

Nhưng điều này cũng đại diện cho một điểm trung tâm của sự thất bại nếu cơ sở hạ tầng cầu nối của người phát hành mã thông báo bị xâm phạm, giá trị của tất cả các biểu diễn chính thức đang lưu thông trong hệ sinh thái đa chuỗi sẽ gặp nguy hiểm. Điều này cũng ngụ ý rằng chỉ có người giữ tài sản tập trung (ví dụ: Circle trong trường hợp USDC) mới có thể triển khai mô hình phát hành các biểu diễn chính thức qua cầu.

Ý kiến cuối cùng

Như được hiển thị trong báo cáo này, tính tương đồng của tài sản cross-chain là một phần quan trọng của tính tương tác rollup với những ảnh hưởng đối với trải nghiệm chuyển đổi giữa các chuỗi khác nhau. Khả năng của token duy trì tính tương đồng khi được kết nối với các chuỗi từ xa cũng ảnh hưởng đến trải nghiệm của nhà phát triển khi một số trường hợp sử dụng phụ thuộc vào tính năng này.

Đã đề xuất nhiều giải pháp khác nhau để giải quyết vấn đề về các token chuỗi chéo không thể hoán đổi - nhiều trong số đó chúng tôi đã đề cập trong báo cáo này. Điều này bao gồm việc phát hành token chuẩn thông qua cầu nối bản địa (được khắc ghi), sử dụng cầu nối bên thứ ba chuyên dụng để phát hành token chuẩn trên nhiều chuỗi và sử dụng cầu nối sở hữu giao thức để tạo điều kiện cho việc di chuyển token và bảo vệ tính liên hoàn.

Mặc dù những phương pháp này giải quyết các vấn đề cụ thể, nhưng không thể giải quyết tất cả các vấn đề và việc sử dụng chúng để kích hoạt tính linh hoạt của tài sản qua chuỗi cross đòi hỏi một số sự đánh đổi không mong muốn. Liệu chúng ta có thể tìm ra một phương pháp tốt hơn không? Câu trả lời là có.

ERC-7281 là một cách tiếp cận mới đối với tính khả năng thay thế tài sản qua chuỗi cross-chain, giảm thiểu nhược điểm liên quan đến các cách tiếp cận hiện có. Còn được biết đến với tên gọi là xERC-20, ERC-7281 cho phép các giao thức triển khai hiệu quả các mã thông báo chính tắc trên nhiều chuỗi mà không đánh đổi 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 (được liệt kê trắng) tạo ra phiên bản chính thức của token của một 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 giới hạn tạo token theo cầu cụ thể. Tính năng này giải quyết nhiều vấn đề liên quan đến các đề xuất lịch sử cho token chính thức đa chuỗi - bao gồm sự phân mảnh thanh khoản, cân nhắc động viên, mối quan tâm về trải nghiệm người dùng, nguy cơ an ninh cầu, tính tùy chỉnh (của token chuỗi-cross), và nhiều vấn đề khác.

Phần tiếp theo và cuối cùng của báo cáo gồm hai phần của chúng tôi về khả năng thay thế tài sản chuỗi chéo sẽ bao gồm chi tiết ERC-7281 và khám phá cách tiêu chuẩn mã thông báo xERC-20 có thể mang lại lợi ích cho nhà phát triển và người dùng. Chúng tôi sẽ so sánh ERC-7281 với các thiết kế khác cho mã thông báo canonical đa chuỗi, khám phá cách tiếp cận của xERC-20 đối với mã thông báo canonical đa chuỗi và nêu bật các cân nhắc cho các giao thức và nhà phát triển muốn xây dựng dựa trên tiêu chuẩn.

Hãy tiếp tục theo dõi!

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được sao chép từ [[](https://research.2077.xyz/making-crosschain-tokens-fungible-part-1#introduction)[Nghiên cứu 2077](https://research.2077.xyz/)\]. Tất cả bản quyền thuộc về tác giả gốc [Alex HookvàEmmanuel Awosika]. Nếu có ý kiến ​​phản đối việc tái bản này, xin vui lòng liên hệ với Cổng họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. Tuyên bố từ chối trách nhiệm: Quan điểm và ý kiến được diễn đạt trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi có đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là cấm.