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 nêu ra những thách thức mà lĩnh vực chuỗi chéo phải đối mặt, chẳng hạn như vấn đề không thể thay thế của mã thông báo chuỗi chéo và phân tích các vấn đề đó. Giải pháp chính hiện tại; Phần 2 sẽ khám phá tiêu chuẩn mã thông báo chuỗi chéo có chủ quyền ERC-7281 và phân tích các lợi ích cũng như 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 phải đối mặt với nhiều thách thức do những hạn chế cố hữu của các phương pháp tương tác blockchain như cầu nối chuỗi chéo. Ví dụ: cầu nối chuỗi chéo có thể tiềm ẩn rủi ro về bảo mật (các cuộc tấn công chuỗi chéo của tin tặc đã gây thiệt hại hơn 2,5 tỷ USD) hoặc chúng có thể chậm, tốn kém và 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ây cầu 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: chuyển đổi các mã thông báo có thể hoán đổi cho nhau (như mã thông báo tiêu chuẩn ERC-20) thông qua các chuỗi chéo khác nhau các giao thức khi mã thông báo được liên kết chéo với các chuỗi khác nhau, các mã thông báo này sẽ trở thành mã thông báo không thể thay thế, do đó mất chức năng là 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ế của mã thông báo trên các chuỗi, bất kể hợp đồng ban đầu của nó tồn tại ở đâu: Tiêu chuẩn mã thông báo chuỗi chéo có chủ quyền ERC-7281.
ERC-7281 (còn được gọi là xERC-20) là phần mở rộng của ERC-20, một tiêu chuẩn để tạo mã thông báo có thể thay thế trên Ethereum. ERC-7281 cho phép nhiều cầu nối được nhà phát hành mã thông báo phê duyệt để đúc và ghi các phiên bản mã thông báo tiêu chuẩn của mã thông báo ERC-20 trên các chuỗi từ xa, đảm bảo rằng người dùng nhận được những gì họ nhận được tại đích khi kết nối mã thông báo ERC-20 là phiên bản có thể thay thế được. mã thông báo (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 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 mã thông báo chuỗi chéo (không giống như trạng thái hiện tại của các cầu nối kiểm soát mã thông báo chuỗi chéo), và tốc độ của hoạt động đúc có thể bị hạn chế, do đó giảm rủi ro trong trường hợp xảy ra sự cố cầu xuyên chuỗi.
Lấy USDC làm ví dụ, chúng ta có thể thấy rằng về mặt lý thuyết, các token ERC-20 giống nhau trên các 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 các token ERC-20 phổ biến từ Ethereum L1 sang các chuỗi này. Các mã thông báo L2 này có nguồn gốc từ L1 thường được gọi là “chuỗi chéo [chèn tên mã thông báo]”.
Đối với USDC, các ký hiệu token phổ biến là USDC.e, USDC.b, v.v. Mặc dù cả hai mã thông báo đều được tạo 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, mã thông báo 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 cho chéo chuỗi, nhưng USDC chuỗi chéo chỉ có thể chuỗi chéo 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 các tiện ích mở rộng ERC-20, trong đó người triển khai mã thông báo có thể chỉ định và tham số hóa các nguồn gốc chuỗi chéo khác nhau cho nó. Trong ví dụ trên, Circle có thể triển khai mã thông báo USDC phổ quát trên tất cả các L2 trong đó các cầu nối chuỗi chéo tiêu chuẩn (chẳng hạn như Circle Mint, Circle CCTP và các cầu nối chuỗi chéo được phê duyệt khác) được chỉ định để có thể đúc mã thông báo theo logic của chúng . Để giảm thiểu nguy cơ máy đào bị hack, người triển khai có thể giới hạn số lượng token mà mỗi máy đào có thể đúc và hủy trong một khoảng thời gian cụ thể - đối với các cầu nối chuỗi chéo đáng tin cậy hơn (chẳng hạn như Cầu nối chuỗi chéo 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 các mã thông báo chuỗi chéo có thể hoán đổi cho nhau, nhưng nó có thể giải quyết được các vấn đề tồn tại trong chuỗi chéo , chẳng hạn như cung cấp tính năng khóa Nhà giao dịch, mất chủ quyền của nhà phát hành mã thông báo, chi phí cao của mã thông báo chuỗi chéo dẫn đến tính thanh khoản, chi phí cơ sở hạ tầng tăng lên và nguy cơ lỗi chuỗi chéo tăng lên, v.v.
Thảo luận chuyên sâu về tính năng không thể thay thế Mã thông báo chuỗi chéo Trước khi đặt câu hỏi, trước tiên chúng ta cần hiểu lý do tại sao mã thông báo chuỗi chéo 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 chuỗi chéo - bởi vì nhà cung cấp cầu nối chuỗi chéo là nhà cung cấp. bên chịu trách nhiệm tạo các phiên bản mã thông báo chuỗi chéo.
Cơ chế chuỗi chéo là phương tiện truyền tải thông tin giữa các chuỗi khối. Ngoài thông tin tiền tệ thuần túy, các cầu nối chuỗi chéo 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ã thông báo 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 (mã thông báo) từ chuỗi này sang chuỗi khác 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.
Các phương pháp hỗ trợ chuyển tài sản xuyên chuỗi khác nhau, nhưng quy trình làm việc của mã thông báo chuỗi chéo thường tuân theo một trong ba mẫu cấp cao:
< p style="text-align: left;">Lock and Mint BridgeHy vọng của người dùng để xâu chuỗi chéo các mã thông báo trên chuỗi gốc của nó hoặc "chuỗi nguồn" (chuỗi được phát hành ban đầu) sang chuỗi khác. Vì mỗi chuỗi triển khai một kiến trúc và thiết kế giao thức khác nhau nên hai chuỗi khối không tương thích, điều này ngăn người dùng chuyển trực tiếp mã thông báo 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 chuỗi chéo lưu trữ các mã thông báo được người dùng lưu trữ trên chuỗi gốc trong các hợp đồng thông minh và triển khai chúng trên mục tiêu Bật -hợp đồng mã thông báo chuỗi tạo ra các phiên bản mã thông báo "được bao bọc" của mã thông báo gốc.
Khi người dùng muốn đảo ngược chuỗi chéo (chuỗi đích → chuỗi gốc), họ sẽ trả lại các mã thông báo được gói cho chuỗi mục tiêu. chuỗi mục tiêu sẽ xác minh điều này dựa trên logic trong cầu nối chuỗi chéo (chẳng hạn như bằng chứng không có kiến thức hoặc trọng tài bên ngoài) và giải phóng mã thông báo gốc từ tài khoản ký quỹ trên chuỗi gốc.
Cầu phá hủy và đúc tiền
Phương pháp này không khóa các mã thông báo đang bị giam giữ mà phá hủy các mã thông báo trên chuỗi nguồn;
Chuỗi chéo này The Bridge sẽ đúc một lượng token bằng nhau trên chuỗi mục tiêu;
Để chuyển ngược lại, các token chuỗi chéo nằm trên chuỗi mục tiêu bị phá hủy và sau đó các mã thông báo mới được tạo ra trên chuỗi nguồn;
Điều này có thể duy trì mã thông báo trong khi đạt được tổng chuyển khoản xuyên chuỗi cung cấp.
Hoán đổi nguyên tử
Nguyên tử hoán đổi 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à quá trình 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 ngừa gian lận hoặc chuyển khoản một phần/thất bại .
Trong số các phương pháp trên, phương pháp đầu tiên (khóa và đúc) hiện là phổ biến nhất. Giá trị tương đương giữa mã thông báo gốc và mã thông báo được bao bọc tương ứng được tạo 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 mã thông báo 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 chuỗi chéo 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 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 tiền điện tử 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 trên chuỗi.
Mục đích chuỗi chéo 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 tiềm ẩn của cầu nối chuỗi chéo. Trong cầu nối chuỗi chéo 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 các mã thông báo đượ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 chuỗi chéo dựa trên mục đích sử dụng cơ chế khóa và truyền bên trong. Trong trường hợp này, các mã thông báo được bao bọc sẽ được đúc qua cầu chuỗi và các mã thông báo 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ác cầu nối chuỗi chéo 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 mã thông báo được gói (dù được tạo thông qua cầu nối chuỗi chéo truyền thống hay cầu nối chuỗi chéo dựa trên mục đích) là một "IOU" do nhà cung cấp cầu nối chuỗi chéo phát hành, hứa hẹn sẽ nhận được từ ký quỹ Một số lượng mã thông báo gốc nhất định được phát hành trong hợp đồng. Giá trị của những 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 chuỗi chéo trong việc xử lý các yêu cầu rút tiền từ những người nắm giữ mã thông báo ký quỹ trên chuỗi gốc.
Các cầu nối chuỗi chéo được ủy quyền để khóa mã thông báo gốc trên chuỗi nguồn và đúc mã thông báo được bao bọc của chúng trên chuỗi mục tiêu đảm bảo rằng tổng nguồn cung cấp mã thông báo được duy trì không đổi. Đối với một đơn vị mã thông báo gốc, chính xác một đơn vị mã thông báo được gói tương ứng sẽ được tạo ra và ngược lại. Nếu một ứng dụng chấp nhận mã thông báo đượ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 chuỗi chéo để hỗ trợ bảo mật tài sản "thực" của mã thông báo được bao bọc.
Bằng cách tạo mã thông báo chuỗi chéo, cầu nối chuỗi chéo 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ác nhà phát triển Mọi người cũng như người dùng có thể tận dụng khả năng tương tác xuyên chuỗi. Những lợi thế này bao gồm tăng thêm tính thanh khoả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ừ các 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 tính năng 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 bắt đầu với một công cụ có tên Hãy sử dụng sàn giao dịch phi tập trung hư cấu “ BobDEX” làm ví dụ. Ví dụ này sẽ chứng minh cách mã thông báo được bao bọc có thể mở rộng quy mô trên các 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 được tạo bởi Bob trên Ethereum Một hệ thống tự động sàn giao dịch tạo lập thị trường (AMM) được thiết kế để cho phép trao đổi không cần sự tin cậy giữa các tài sản khác nhau. BobDEX có mã thông báo gốc BOB, vừa là mã thông báo quản trị vừa là mã thông báo phần thưởng của nhà cung cấp thanh khoản (LP). Trong trường hợp thứ hai, BobDEX phát hành mã thông báo BOB cho LP, cho phép người dùng cung cấp tính 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 giữ trong nhóm.
Nhưng khi thị phần của BobDEX tăng lên đáng kể, những hạn chế của Ethereum L1 đã cản trở sự phát triển 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ễ giao dịch; tương tự, những người dùng khác muốn tiếp xúc với mã thông báo BOB nhưng không muốn giữ mã thông báo 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 thông lượng cao, chi phí thấp) trên Arbitrum và đã thông qua Arbitrum -Ethereum Bridge triển khai phiên bản mã thông báo được bao bọc của mã thông báo BOB (wBOB) trên L2. BobDEX trên Arbitrum giống như BobDEX trên Ethereum, nhưng nó sử dụng wBOB (thay vì mã thông báo BOB gốc) làm mã thông báo quản trị và phần thưởng LP.
Đố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ề mã thông báo được áp dụng (BOB được bao bọc so với BOB gốc) không phải là không quan trọng. Điều này là do mã thông báo wBOB được hỗ trợ bởi mã thông báo BOB thực tế được giữ trong cầu nối Arbitrum-Ethereum, vì vậy chủ sở hữu mã thông báo wBOB có thể dễ dàng đổi mã thông báo 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 tôi 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 có 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. 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 mã thông báo wBOB trên thị trường để kiếm lợi nhuận từ giá mã thông báo BOB. thay đổi mà không 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 chuỗi chéo là tăng cường đổi mới có thể kết hợp và mở khóa các trường hợp sử dụng mới giúp thúc đẩy tính thanh khoản của mã thông báo 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 cho vay 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á mã thông báo 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 vai trò LP trên BobDEX với cùng sự đảm bảo rằng mã thông báo wBOB có thể được đổi thành mã thông báo BOB gốc theo tỷ lệ 1:1.
Hiện tại, các cầu nối chuỗi chéo được sử dụng để đả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 thuận lợi cho các ứng dụng mới như cho vay chuỗi chéo và chuỗi chéo DEX) cung cấp một giải pháp khả thi. Tuy nhiên, hệ sinh thái cầu nối chuỗi chéo đang phải đối mặt với những hạn chế cản trở sự phát triển hơn nữa của nó, chẳng hạn như vấn đề về tính không thể thay thế của các mã thông báo chuỗi chéo.
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 rất nhiều công việc thiết kế kỹ thuật và cơ chế hoạt động bình thường. .
Thách thức đầu tiên là đảm bảo rằng phiên bản mã thông báo được bao bọc của mã thông báo chuỗi chéo luôn được hỗ trợ bởi mã thông báo gốc bị khóa trên chuỗi nguồn. Nếu kẻ tấn công đúc mã thông báo chuỗi chéo trên chuỗi từ xa mà không gửi mã thông báo gốc trên chuỗi nguồn, kẻ tấn công có thể cung cấp mã thông báo chuỗi chéo bằng cách trao đổi mã thông báo được bọc (đúc một cách gian lận) với mã thông báo gốc trên chuỗi chính Giao thức cầu nối. phá sản và ngăn cả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 chuỗi trước khi đúc các mã thông báo được gói) rút tiền gửi của họ.
Thử thách thứ hai tinh tế hơn và bắt nguồn từ bản chất của mã thông báo chuỗi chéo: hai phiên bản của cùng một mã thông báo được tạo ra trên cùng một chuỗi từ xa bởi chuỗi chéo Các phiên bản Token của nhà cung cấp cầu nối chuỗi không thể trao đổi với 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 mã thông báo giữa các chuỗi thông qua các đường dẫn khác nhau để minh họa các vấn đề liên quan đến mã thông báo di động chuỗi chéo:
Alice kết nối USDC từ Ethereum với Arbitrum thông qua cầu Arbitrum tiêu chuẩn và nhận 200 USDC.e trên Arbitrum, trong khi Bob liên kết chéo USDC với Arbitrum thông qua Axelar Arbitrum và nhận 200 axlUSDC trên Arbitrum. Alice và Bob đi đến thỏa thuận trong đó 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, nhưng chỉ nhận được 200 USDC và cũng nhận được thông báo cho biết rằng chuỗi chéo giao thức cầu nối Chỉ có thể cung cấp 200 USDC cho Bob. Bob bối rối vì điều này vì mã thông báo 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 mã thông báo 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 sâu sắc từ cầu nối chuỗi chéo: "Mã thông báo 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 nó với các token ERC-20 khác theo tỷ lệ 1:1 trong các ứng dụng khác nhau.” 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, các mã thông báo được phát hành trên các chuỗi khác nhau không tương thích, do đó, các mã thông báo gốc được phát hành trên chuỗi không phải gốc là phiên bản mã thông báo thực sự là IOU trong thỏa thuận cầu nối chuỗi chéo, 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 gốc của token.
Do đó, giá trị của mỗi mã thông báo chuỗi chéo có liên quan đến cầu nối chuỗi chéo chịu trách nhiệm giữ tiền gửi trên chuỗi chính và đúc mã thông báo được gói trên chuỗi móc nối nhà cung cấp; nhà cung cấp cầu nối chuỗi chéo của Bob chỉ có thể trả cho Bob 200 USDC vì đó là số tiền anh ta có thể trả từ khoản tiền gửi của mình; 200 USDC của Alice không thể rút được thông qua nhà cung cấp cầu nối chuỗi chéo của Bob vì số tiền đó chưa bao giờ được nhận. gửi tiền 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 chuỗi chéo của Bob trước khi Bob có thể truy cập vào số token còn lại.
Tình huống khó xử của Bob và Alice chỉ ra một vấn đề với kết nối chuỗi chéo, đó là nhiều nhà cung cấp cầu nối chuỗi chéo cạnh tranh tạo ra nhiều phiên bản mã thông báo không thể thay thế của cùng một nội dung cơ bản. Ngoài ra, một vấn đề khác với các token ERC-20 khác nhau của cùng một nội dung 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 luồng Thanh khoản nhóm - ETH/axlUSDC và ETH/USDC.e, dẫn đến cái gọi là vấn đề "phân mảnh thanh khoản" - nghĩa là, các 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 phiên bản "tiêu chuẩn" của mã thông báo trên chuỗi mục tiêu, để Bob và Alice có thể trao đổi mã thông báo và Có không cần mọi người phải rút khỏi cầu nối của chuỗi nguồn. Việc có mã thông báo 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 tính thanh khoản của mã thông báo.
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 mã thông báo trên mỗi chuỗi nơi nó dự kiến sẽ được sử dụng hoặc chuyển giao?
Tạo mã thông báo tiêu chuẩn cho mỗi chuỗi Không có xu dễ mua và có nhiều lựa chọn, mỗi lựa chọn đều có ưu và nhược điểm riêng. Khi tạo mã thông báo 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 mã thông báo cụ thể. Giả sử bạn là người tạo mã thông báo và muốn mã thông báo được sử dụng và chuyển nhượng trên các 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 . Tạo mã thông báo tiêu chuẩn thông qua Rollup/Sidechain Bridge tiêu chuẩn
2. Chuỗi chéo thông qua các bên thứ ba Nhà cung cấp cầu nối tạo ra mã thông báo tiêu chuẩn
3. Đúc các token tiêu chuẩn thông qua cầu nối nhà phát hành token
;">4. Sử dụng hoán đổi nguyên tử để phát hành trực tiếp trên nhiều chuỗi
Ba tùy chọn đầu tiên dựa vào các cơ chế cầu nối chuỗi chéo khác nhau để tạo điều kiện thuận lợi cho việc di chuyển mã thông báo xuyên chuỗi. Tuy nhiên, với tư cách là người tạo mã thông báo, bạn cũng có thể chọn bỏ qua hoàn toàn các cầu nối chuỗi chéo và phát hành mã thông báo tự nhiên trên mỗi chuỗi được hỗ trợ. Theo cách tiếp cận này, thay vì dựa vào các mã thông báo được bao bọc hoặc cơ sở hạ tầng cầu nối chuỗi chéo, bạn duy trì việc triển khai mã thông báo độ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 các chuỗi.
Tuy nhiên, cách tiếp cận này đòi hỏi cơ sở hạ tầng phức tạp để duy trì tính thanh khoản chuỗi chéo và tạo điều kiện thuận lợi cho việc 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ớn.
Đúc cá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 tiêu chuẩn ( được công nhận), chuỗi này có thể cấp cho người dùng muốn chuỗi chéo từ chuỗi gốc quyền đúc mã thông báo chuỗi chéo trong giao thức của họ. 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 mã thông báo được đúc.
Mặc dù Standard Bridge đang tạo ra phiên bản Standard Token của token nhưng các phiên bản token khác sẽ vẫn tồn tại. Điều này là do Standard Bridge thường có những hạn chế và không thể cung cấp cho người dùng. trải nghiệm tốt nhất Ví dụ: việc kết nối từ Arbitrum/Optimism sang Ethereum thông qua cầu nối tiêu chuẩn của Rollup có độ trễ bảy ngày do 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 giải quyết của Rollup (Ethereum ) sẽ giải quyết một loạt giao dịch.
Người dùng Rollup theo đuổi hiệu quả phải sử dụng các nhà cung cấp cầu nối chuỗi chéo khác có thể đảm nhận quyền sở hữu các lần thoát Rollup đang chờ xử lý và thực thi tại đích mong muốn của người dùng. Cung cấp tính thanh khoản ngay lập tức trên chuỗi . 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 mã thông báo 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 đó.
Sidechains với bộ trình xác thực độc lập có độ trễ thấp hơn do khối chứa giao dịch rút tiền được thực thi sau khi giao thức đồng thuận của sidechain xác nhận việc 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 các sidechain với các miền khác nhau, bao gồm Ethereum Rollup và Ethereum mainnet.
Lưu ý: Chúng tôi đang đề cập đến chuỗi Polygon PoS ban đầu, không phảichuỗi Validium có kế hoạch sử dụng Ethereum để thanh toán . Polygon sẽ trở thành L2 sau khi nó chuyển từ chuỗi bên đượ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ầu chuỗi bên cũng có một điểm yếu chung với cầu tiêu chuẩn Rollup: người dùng chỉ có thể kết nối giữa một cặp chuỗi được kết nối. chuỗi chéo. Họ không thể sử dụng cầu nối tiêu chuẩn để liên kết chéo với các chuỗi khối 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 chuỗi chéo Arbitrum, cũng như kết nối Polygon với Avalanche thông qua cầu nối chuỗi chéo Polygon PoS.
Việc sử dụng cầu nối thanh khoản để đúc mã thông báo tiêu chuẩn
Việc dựa vào cầu nối gốc của Rollup để chuyển mã thông báo tiêu chuẩn sẽ gây ra một số vấn đề, chẳng hạn như tính thanh khoản kém hiệu suất và chuyển giao tài sản bị trì hoã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 các chuỗi.
Theo cách sắp xếp này, một cầu nối thanh khoản được ủy quyền tạo ra các mã thông báo bao bọc các mã thông báo giao thức trên chuỗi nguồn, sau đó được tạo ra thông qua nhóm thanh khoản thuộc sở hữu của giao thức, Trao đổi mã được bao bọc mã thông báo cho mã thông báo tiêu chuẩn của mã thông báo gốc đó trên chuỗi mục tiêu.
Mã thông báo tiêu chuẩn trên chuỗi mục tiêu thường là phiên bản được tạo ra bởi cầu nối sidechain/Rollup tiêu chuẩn, mặc dù vẫn có những trường hợp ngoại lệ (sẽ thảo luận sau). Ví dụ: mã thông báo 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 tương tự như một DEX với một nhà tạo lập thị trường tự động (AMM), được sử dụng để thực hiện các khoản tiền được lưu trữ trong các nhóm thanh khoản khác nhau. Trao đổi giữa các cặp tài sản. . Để khuyến khích nguồn cung thanh khoản, nhóm AMM sẽ phân bổ một phần phí trao đổi cho những người nắm giữ mã thông báo 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ặp tài sản thường là cặp cầu nối thanh khoản trao đổi giữa token xuyên chuỗi và token tiêu chuẩn. Ví dụ: sau khi người dùng liên kết chéo USDT với 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 mã thông báo gốc trên chuỗi nguồn
< p style="text-align: left;">2. Đào mã thông báo chuỗi chéo của mã thông báo gốc trên chuỗi mục tiêu3. mã thông báo chuỗi trên mục tiêu thông qua nhóm AMM Trao đổi mã thông báo chuỗi chéo thành mã thông báo tiêu chuẩn trên chuỗi
4. Gửi mã thông báo tiêu chuẩn cho người dùng
Khi chuỗi chéo quay trở lại chuỗi nguồn, người dùng sẽ hủy mã thông báo tiêu chuẩn hoặc trao đổi mã thông báo tiêu chuẩn với mã thông báo chuỗi chéo thông qua AMM, sau đó hủy xu xu và cung cấp bằng chứng về biên nhận tiêu hủy. Sau khi được xác nhận, người dùng có thể rút mã thông báo 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 mã thông báo 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 vấn đề chậm trễ trong cầu nối chuỗi chéo Rollup; ví dụ: Hop cho phép các tổ chức chuyên biệt được gọi là "Bonders" thực hiện; hoạt động trên L2 Chứng minh tính hợp lệ của giao dịch rút tiền của người dùng và chịu chi phí rút tiền từ cầu L1 của Rollup. 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 nguy cơ 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 nhiều chuỗi hơn. Ví dụ: Hop cho phép người dùng liên kết chéo 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 mã thông báo 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ố hạn chế đối với cầu nối thanh khoản, điều này ảnh hưởng đến tính thực tế của việc đúc mã thông báo 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 mã thông báo dự kiến sẽ nhận được và số lượng mã thông báo thực sự nhận được khi tương tác với AMM. Thiếu thanh khoản trong tài sản chuỗi chéo 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 các token có ít hoạt động giao dịch hơn hoặc có giá trị thấp hơn.
Ngoài ra, điều này cũng sẽ tác động đến các nhà phát triển xây dựng ứng dụng chuỗi chéo, vì họ phải xem xét các trường hợp xảy ra trượt giá; quá nhỏ để hoàn thành hoạt động chuỗi chéo.
Để giải quyết vấn đề này, các ứng dụng như công cụ tổng hợp chuỗi chéo (không có cách nào để biết liệu cầu thanh khoản có đủ thanh khoản để trang trải chuỗi mục tiêu hay không) trao đổi không bị trượt), áp dụng chiến lược chỉ định dung sai trượt tối đa, bằng cách đặt trước phạm vi trượt tối đa được người dùng chấp nhận và cung cấp cho họ báo giá. 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 mã thông báo chuỗi chéo của họ, bất kể tính thanh khoản trong nhóm AMM của cầu nối như thế nào.
Hạn chế thanh khoản
Thách thức cơ bản mà cầu thanh khoản phải đối mặt là chuỗi mục tiêu phải có có đủ thanh khoản. Không giống như lock-and-mint truyền thống, trong đó việc đúc token được hỗ trợ trực tiếp bởi các tài sản bị khóa, Liquidity Bridge dựa vào các token có sẵn trong nhóm AMM để hoàn tất quá trình chuyển giao chuỗi chéo. Khi thanh khoản giảm xuống dưới ngưỡng quan trọng, toàn bộ cơ chế chuỗi chéo 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ể dừng hoàn toàn, ngăn người dùng hoàn thành Các khoản chuyển khoản dự kiến;
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 tính 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, các nhà cung cấp thanh khoản có thể rút tiền khỏi nhóm và đây là lúc chức năng cầu nối chuỗi chéo là cần thiết nhất;
Việc ra mắt các cặp mã thông báo mới trở nên đặc biệt khó khăn vì cần một lượng lớn thanh khoản ban đầu để giúp cầu nối chuỗi chéo hoạt động.
Các yêu cầu về thanh khoản tạo ra sự phụ thuộc vòng tròn: cây cầu yêu cầu lượng thanh khoản lớn để hoạt động đáng tin cậy, nhưng thu hút các nhà cung cấp thanh khoản Người nộp đơn sẽ cần phải chứng minh việc tiếp tục sử dụng và chi phí của cây cầu. Vấn đề con gà và quả trứng này đặc biệt nghiêm trọng đối với các 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.
Cơ chế khuyến khích không phù hợp
Vai trò của cầu thanh khoản là nó có thể bao trùm trao đổi mã thông báo chuỗi thành mã thông báo 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, từ quan điểm của người dùng, chi phí Gas khi tương tác với cầu cũng quyết định giá trị của cầu thanh khoản. Do đó, các nhà tổng hợp chuỗi chéo và nhóm dự án phát hành mã thông báo sẽ ưu tiên các cầu nối chuỗi chéo dựa trên tính thanh khoản và chi phí giao dịch.
Mặc dù điều này có thể đảm bảo trải nghiệm người dùng tốt hơn cho mã thông báo dự án chuỗi chéo hoặc người dùng sử dụng công cụ tổng hợp chuỗi chéo để gửi mã thông báo qua các chuỗi, theo quy trình Việc lựa chọn các cầu nối chuỗi chéo một cách tình dục khiến các cầu nối chuỗi chéo không thể dành ưu đãi LP vào thế bất lợi. 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ác cầu nối chuỗi chéo áp dụng cách tiếp cận 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 chéo. Trong cả hai trường hợp, các cầu nối chuỗi chéo đều không cạnh tranh được về thước đo quan trọng nhất – bảo mật.
Hơn nữa, cầu nối thanh khoản cũng gây bất lợi cho các 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 các nhà cung cấp thanh khoản hơn). Các nhà phát hành mã thông báo đuôi dài (hoặc mã thông báo mới có khối lượng chuỗi chéo 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 mã thông báo gốc (chuỗi chéo thông qua cầu thanh khoản) bằng mã thông báo tiêu chuẩn của hoán đổi mã thông báo của nhà phát hành giữa các LP, hoặc làm việc với nhà cung cấp cầu nối chuỗi chéo để tăng cường khuyến khích tài chính cho LP nhằm cung cấp tính 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 giải pháp thay thế cho chuỗi chéo tiêu chuẩn bridge Đã được cải thiện nhưng không phải không có vấn đề về trải nghiệm người dùng. Ngoài sự trượt giá 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 mã thông báo 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ó tính 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 tùy chọn (không lý tưởng):
Đợi cho đến khi cây 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 tính 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 mã thông báo độc quyền của cầu nối chuỗi chéo (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 mã thông báo tiêu chuẩn của mã thông báo gốc (ví dụ: opUSDT do Optimism Bridge tạo ra) và có thể không chấp nhận tài sản được bao bọc từ người dùng.
DApps đa chuỗi có thể giải quyết vấn đề về khả năng không thể thay thế của mã thông báo chuỗi chéo bằng cách chọn một cầu nối chuỗi chéo duy nhất, nghĩa là tạo ra mã thông báo tiêu chuẩn của mã thông báo 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 ra các token của dự án, cách tiếp cận này yêu cầu các token được đú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 nguồn cung cấp token toàn cầu vẫn nhất quán. Các nhà cung cấp cầu nối chuỗi chéo phải theo dõi việc đúc và đốt mã thông báo và đảm bảo rằng các hoạt động này được đồng bộ hóa với việc cung cấp mã thông báo trên chuỗi chính.
Trên cơ sở này, vấn đề về khả năng không thể thay thế của mã thông báo chuỗi chéo đã được giải quyết miễn là người dùng liên kết chuỗi thông qua một cầu nối chuỗi chéo đã được phê duyệt; nhà cung cấp, Chúng luôn có thể được trao đổi với các mã thông báo chuỗi chéo khác theo tỷ lệ 1:1. Ngoài ra, phương pháp này còn giải quyết vấn đề chuỗi chéo 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 xuyên chuỗi vì các nhà cung cấp cầu nối chuỗi chéo không cần chuyển đổi mã thông báo chuỗi chéo của họ thành mã thông báo tiêu chuẩn thông qua AMM - mã thông báo được các nhà cung cấp cầu nối chuỗi chéo hỗ trợ là phiên bản mã thông báo tiêu chuẩn. trên mỗi chuỗi. Giá trị của các mã thông báo tiêu chuẩn này được gắn với giá trị của các mã thông báo do nhà cung cấp khóa trên chuỗi gốc.
Người dùng sẽ khó gặp phải bất kỳ sự chậm trễ nào khi băng qua chuỗi, vì nhà cung cấp cầu nối chuỗi có thể nhận được mint() Ngay sau tin nhắn , việc đúc các token được gói bắt đầu trên chuỗi mục tiêu.
Các nhà phát triển có thể thuê ngoài việc quản lý triển khai mã thông báo đa chuỗi cho các nhà cung cấp cầu nối chuỗi mà không phải lo lắng về việc khởi chạy luồng AMM Cung cấp các chương trình khuyến khích về tính thanh khoản hoặc tính thanh khoản.
Hiện tại, một số ví dụ về tiêu chuẩn mã thông báo cho một nhà cung cấp cầu nối chuỗi chéo duy nhất bao gồm mã thông báo phổ quát toàn chuỗi (OFT) của LayerZero, dịch vụ mã thông báo chuỗi chéo của Axelar ( ITS), 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à các mã thông báo độc quyền và không tương thích với các mã thông báo chuỗi chéo của cùng một mã thông báo được gửi qua các nhà cung cấp cầu nối chuỗi chéo khác nhau, vì vậy chi tiết này cũng nêu bật một số vấn đề liên quan đến chuỗi chéo này với phương pháp xử lý mã thông báo chuỗi như sau:
Khóa nhà cung cấp
Cầu Nguy cơ thất bại cao
< /li>Các 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 ở các chuỗi được nhà cung cấp hỗ trợ
Không thể giữ nguyên địa chỉ mã thông báo của tất cả các chuỗi bắt buộc, điều này có thể ảnh hưởng đến bảo mật của người dùng hoặc khiến chúng dễ bị tấn công lừa đảo
Sử dụng chuỗi chéo tiêu chuẩn của bên thứ ba Nhược điểm của Bridges
Khóa nhà cung cấp
Việc chọn một nhà cung cấp cầu nối chuỗi chéo duy nhất trong một hoặc Tạo mã thông báo tiêu chuẩn trên nhiều chuỗi có thể khiến các nhà phát triển phải nỗ lực có nguy cơ bị nhà cung cấp khóa. Vì mỗi nhà cung cấp cầu nối chuỗi chéo tạo ra các mã thông báo độ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 chuỗi chéo duy nhất khóa các nhà phát hành mã thông báo vào một dịch vụ cầu nối chuỗi chéo 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 chuỗi chéo khác. -Cầu xích theo ý muốn trong tương lai.
Mặc dù có thể thay đổi nhà cung cấp cầu nối chuỗi chéo, nhưng chi phí thay thế đủ cao để ngă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 mã thông báo (BobToken) trên Ethereum và chọn LayerZero OFT Phiên bản tiêu chuẩn của BobToken được đúc trên Optimism, Arbitrum và Cơ sở. BobToken có nguồn cung cố định là 1.000.000 và mã thông báo chuỗi chéo được đúc thông qua LayerZero chiếm 50% tổng nguồn cung BobToken đang lưu hành.
Lúc đầu, công 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 cho một dịch vụ xuyên chuỗi như Axelar. Tuy nhiên, Bob không thể nói đơn giản: "Tôi muốn chuyển sang Axelar ITS để đúc cá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ế, dẫn đến tính thanh khoản bị phân mảnh trên các chuỗi L2 nơi các mã thông báo BobToken cạnh tranh 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ở khóa mã thông báo được bọc BobToken được đúc thông qua LayerZero, mã thông báo này sẽ phá hủy mã thông báo OFT chuỗi chéo và mở khóa ether BobToken trên thị trường. Sau đó, người dùng có thể khóa mã thông báo của mình bằng cách sử dụng Axelar trên Ethereum và nhận BobToken (mã thông báo tiêu chuẩn mới được ánh xạ tới nguồn cung cấp hợp đồng mã thông báo trên Ethereum) trên chuỗi mục tiêu. Quá trình này gây tốn kém cho nhóm 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 chuỗi chéo không tuân thủ các điều khoản của thỏa thuận và có bộ tính năng hạn chế, thiếu tích hợp hệ sinh thái rộng rãi, trải nghiệm người dùng kém, v.v., việc khóa nhà cung cấp sẽ ngăn cả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 chuỗi chéo 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 chéo mà không có lý do rõ ràng, tăng phí chuỗi chéo hoặc thậm chí kiểm duyệt các hoạt động chuỗi chéo.
Mất chủ quyền giao thức
Kết luận trên về việc khóa nhà cung cấp nhấn mạnh Một vấn đề khác với sử dụng cầu nối chuỗi chéo tiêu chuẩn của bên thứ ba: Các nhà phát hành mã thông báo hy sinh quyền kiểm soát mã thông báo chuỗi chéo 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 mã thông báo 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 trong các lĩnh vực này. hợp đồng mã thông báo tiêu chuẩn BobToken được phát hành trên blockchain.
Mặc dù Bob có thể mong đợi LayerZero giữ mã thông báo tiêu chuẩn nhất quán với thiết kế ban đầu của mã thông báo 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 chuỗi chéo triển khai một phiên bản hoàn toàn khác của hợp đồng mã thông báo - điều này cũng gây ra vấn đề cho người dùng 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 chuỗi chéo có thể khác nhau.
Nguy cơ hỏng cầu chuỗi chéo cao
Trong giải pháp đầu tiên, token Cross -các chuỗi được tiến hành thông qua cầu tiêu chuẩn của mỗi chuỗi và rủi ro đối với nhà phát hành mã thông báo do lỗ hổng ảnh hưởng đến một cầu nối chuỗi được giới hạn ở cây cầu đó. Ví dụ: giả sử một 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 mức 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ụ: Mint 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 chéo nhanh → Trên Ethereum Trao đổi nó trên thị trường cho USDT gốc).
Trong mô hình cầu nối chuỗi chéo của bên thứ ba, đối với các nhà phát hành mã thông báo, rủi ro do các lỗ hổng ảnh hưởng đến cầu nối chuỗi chéo của đối tác tương đương với Tổng số tiền số token do kẻ tấn công tạo ra trên các chuỗi từ xa được triển khai bởi cây cầu bị ảnh hưởng. Điều này hoàn toàn có thể xảy ra vì token tiêu chuẩn trên một chuỗi có thể được trao đổi lấy token tiêu chuẩn được phát hành trên các 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 chuỗi chéo của bên thứ ba trên chuỗi B và đúc 1000 mã thông báo (mã thông báo 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. Mã thông báo 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ể xuyên chuỗi sang chuỗi C, trao đổi 1000 mã thông báo chuỗi B lấy 1000 mã thông báo chuỗi C - hãy nhớ rằng các mã thông báo chuỗi chéo 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 chuỗi chéo. Mã thông báo 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 mã thông báo của họ trên Chuỗi A (chuỗi chính của mã thông báo), cho phép kẻ tấn công phá hủy mã thông báo trên Chuỗi C và rút Chuỗi A trên mã thông báo 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 chuỗi chéo của bên thứ ba, nhà phát hành mã thông báo cũng thường mất các chức năng tùy chỉnh hoặc khả năng triển khai hành vi mã thông báo tồn tại trong quá trình triển khai ban đầu, chẳng hạn như ủy quyền biểu quyết (ZK), cơ chế khởi động lại (stETH, USDM), chức năng phí chuyển khoản, chức năng danh sách đen và danh sách trắng (USDT, USDC), Chuyển khoản bị đình chỉ và đúc tiền đặc biệt quy tắc hoặc quyền, v.v. Các chức năng mã thông báo phổ biến này thường bị loại bỏ. Điều này là do các nhà cung cấp cầu nối chuỗi chéo thường sử dụng các hợp đồng triển khai ERC-20 được tiêu chuẩn hóa, có thể không hỗ trợ các tính năng Chuyên dụng ban đầu có trong quá trình triển khai mã thông báo.
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 các mã thông báo trên các 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 vào 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 mã thông báo chuỗi chéo 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 chuỗi chéo, 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 mã thông báo và có thể cản trở các nhà phát hành sử dụng chúng trong các khu vực được ứng dụng của họ bao phủ. Duy trì tính nhất quán của hành vi mã thông báo trên toàn bộ hệ sinh thái đa chuỗi.
Các chuỗi được hỗ trợ có giới hạn
Các nhà phát hành mã thông báo dựa vào sự lựa chọn của họ về mạng lưới của nhà cung cấp cầu nối chuỗi chéo kế hoạch bao phủ và mở rộng. Nếu nhà cung cấp cầu nối chuỗi chéo không hỗ trợ mạng blockchain cụ thể mà nhà phát hành mã thông báo muốn mở rộng, họ sẽ phải đối mặt với hai lựa chọn kém lý tưởng:
Đợi nhà cung cấp cầu nối chuỗi chéo 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ụ: Sự không tương đương EVM của ZKsync Era khiến nhiều Dapp không bao giờ được triển khai trên đó);
Sử dụng các khoảng thời gian khác nhau cho chuỗi cụ thể này. nhưng điều này lại gây ra các vấn đề về mã thông báo không thể thay thế và sự 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 các chuỗi mới nổi. Xin lưu ý rằng các nhà cung cấp cầu nối chuỗi chéo có thể ưu tiên hỗ trợ các 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 mã thông báo.
Địa chỉ mã thông báo chuỗi chéo không nhất quán
Do tính đặ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 chuỗi chéo bên thứ ba có thể sử dụng các địa chỉ khác nhau để triển khai mã thông báo 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 vấn đề về trải nghiệm người dùng:
Rủi ro bảo mật: Người dùng phải xác minh các địa chỉ mã thông báo khác nhau trên mỗi chuỗi, do đó làm tăng nguy cơ tương tác với các mã thông báo lừa đảo;
Độ phức tạp của việc tích hợp: nhà phát triển phải duy trì danh sách các địa chỉ mã thông báo hợp lệ cho mỗi mạng;
Rủi ro lừa đảo 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 tiền giả hơn.
Phát hành mã thông báo tiêu chuẩn thông qua cầu phát hành mã thông báo
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 mã thông báo của dự án trên chuỗi chéo, họ có thể quản lý việc phát hành phiên bản mã thông báo tiêu chuẩn của mã thông báo trên chuỗi từ xa, được mô tả là "Mã thông báo đáng tin cậy nhà phát hành" vì giá trị của mỗi phiên bản mã thông báo chuỗi chéo được liên kết chặt chẽ với giá trị mã thông báo 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 mã thông báo trên chuỗi nguồn.
Để phương pháp này hoạt động, các nhà phát hành mã thông báo phải thiết lập cơ sở hạ tầng để quản lý việc đúc và đốt mã thông báo chuỗi chéo (đồng thời đảm bảo rằng nguồn cung Toàn cầu được đồng bộ hóa) .
Các ví dụ đáng chú ý về mã thông báo tiêu chuẩn (mã thông báo gốc) do người tạo mã thông báo phát hành là Teleport của MakerDAO và Giao thức chuyển chuỗi chéo (CCTP) của Circle. Dịch chuyển tức thời cho phép người dùng di chuyển DAI tiêu chuẩn giữa Ethereum và các bản cuộn Ethereum khác nhau. DAI bị phá hủy 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ế ghi và đúc. Trong cả hai trường hợp, nhà phát hành mã thông báo sẽ kiểm soát việc đúc và đốt mã thông báo tiêu chuẩn.
Phương pháp này cung cấp cho giao thức toàn quyền kiểm soát các mã thông báo chuỗi chéo. Nó giải quyết vấn đề không thể thay thế của cùng một mã thông báo theo cách hiệu quả nhất - chỉ có một phiên bản tiêu chuẩn của mã thông báo (do nhà phát hành trên chuỗi mục tiêu tạo ra), đảm bảo rằng người dùng có thể Mọi người trong hệ sinh thái đều có cùng một mã thông báo kinh 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 các mã thông báo chuỗi chéo không 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 chéo mạnh mẽ hơn (ví dụ: hoán đổi chuỗi chéo và cho vay chuỗi chéo) vì cầu nối nhà phát hành mã thông báo tiêu chuẩn cho phép chuyển mã thông báo hiệu quả, liền mạch và an toàn giữa các 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 các chuỗi và duy trì chéo. chuỗi Các dự án có cơ sở hạ tầng (nhà tiên tri, người bảo vệ, v.v.) cần có chi phí để đúc và phá hủy chúng. Đồ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 các phiên bản chuỗi chéo của mã thông báo giao thức và bảo mật giao thức) rất thân thiện vì mã thông báo tiêu chuẩn được hỗ trợ Tính bảo mật của mã gốc của phiên bản mã thông báo đã 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 không phải chịu gánh nặng với các 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 tổ chức 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ệ pháp định và do đó tin tưởng vào cầu ổn định. khó.
Nhưng nó cũng là điểm thất bại chính - nếu cơ sở hạ tầng cầu nối của nhà phát hành mã thông báo bị xâm phạm, thì tất cả các mã thông báo lưu hành trong hệ sinh thái đa chuỗi Giá trị của tiêu chuẩn token 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 mã thông báo chuỗi chéo tiêu chuẩn này.
Khả năng thay thế lẫn nhau của tài sản chuỗi chéo chắc chắn là khả năng tương tác tập hợp Một thành phần quan trọng ảnh hưởng đến trải nghiệm của người dùng về chuyển tài sản giữa các chuỗi khác nhau. Đồng thời, khả năng mã thông báo duy trì khả năng thay thế giữa các 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ề mã thông báo 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 việc tạo ra các mã thông báo tiêu chuẩn thông qua các cầu nối gốc (đã triển khai), sử dụng chuyên dụng cầu nối của bên thứ ba để tạo ra các mã thông báo tiêu chuẩn trên nhiều chuỗi và sử dụng các cầu nối thuộc sở hữu của giao thức để tạo điều kiện thuận lợi cho việc di chuyển mã thông báo và duy trì khả năng thay thế.
Mặc dù các 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ả các vấn đề và việc sử dụng chúng để đạt được khả năng thay thế của tài sản chuỗi chéo ít nhiều. sự đánh đổi lý tưởng cần được thực hiện. Vậy chúng ta có thể tìm ra cách nào tốt hơn không? Câu trả lời là có.
Chúng tôi tin rằng ERC-7281 là một giải pháp có thể thay thế tài sản xuyên chuỗi mới cho phép các giao thức được triển khai hiệu quả trên nhiều chuỗi Mã thông báo tiêu chuẩn mà không phải hy sinh 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 chuỗi chéo (được đưa vào danh sách cho phép) tạo ra các phiên bản tiêu chuẩn của mã 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 tiền trên mỗi cầu nối chuỗi. Tính năng này giải quyết nhiều vấn đề liên quan đến đề xuất lịch sử đối với mã thông báo tiêu chuẩn đa chuỗi, bao gồm phân mảnh thanh khoản, tính nhất quán khuyến khích, vấn đề về trải nghiệm người dùng, bảo mật cầu nối chuỗi và khả năng tùy chỉnh của mã thông báo chuỗi chéo.
Vì vậy, trong phần tiếp theo của báo cáo về khả năng thay thế tài sản chuỗi chéo, chúng ta sẽ đi sâu vào chi tiết về ERC-7281 (còn được gọi là xERC-20), thông qua So sánh với các thiết kế mã thông báo tiêu chuẩn đa chuỗi khác, phân tích cách tiếp cận mã thông báo tiêu chuẩn đa chuỗi của xERC-20 và đi sâu vào 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.
Còn tiếp.
Với sự ra mắt của TOMA chỉ còn một tuần nữa, trò chơi Telegram Tomarket đã chuyển từ The Open Network (TON) sang Aptos, một blockchain lớp 1 đối thủ. Động thái bất ngờ này đặt ra câu hỏi: TON có đang mất đi lợi thế của mình không?
CatherineQuỹ Cayman Islands của OpenSea đã thúc đẩy sự suy đoán về việc ra mắt token, với cộng đồng NFT hy vọng sẽ có đợt airdrop để thưởng cho những người dùng đầu tiên. Điều này diễn ra trong bối cảnh khối lượng giao dịch giảm và sự cạnh tranh ngày càng tăng.
KikyoSuchir Balaji, cựu nghiên cứu viên 26 tuổi của OpenAI, được phát hiện đã chết trong căn hộ của mình ở San Francisco vào ngày 26 tháng 11, với chính quyền phán quyết rằng đó là một vụ tự tử. Trước khi qua đời, Balaji đã chỉ trích mạnh mẽ việc các công ty AI sử dụng tài liệu có bản quyền, làm dấy lên mối lo ngại về các hoạt động đạo đức của các hệ thống AI tạo ra như ChatGPT.
AnaisMark Zuckerberg và Elon Musk phản đối việc OpenAI chuyển sang mô hình vì lợi nhuận, nêu ra những lo ngại về mặt đạo đức và pháp lý liên quan đến việc sử dụng sai mục đích các nguồn lực từ thiện. Điều này đặt ra một câu hỏi rộng hơn: Khi nào AI vượt qua ranh giới đạo đức?
CatherineTrung Quốc đã thành lập một ủy ban tiêu chuẩn AI gồm 41 thành viên do Bộ Công nghiệp và Công nghệ thông tin đứng đầu để thiết lập các quy tắc toàn ngành cho việc phát triển, thử nghiệm và triển khai AI. Các thành viên chủ chốt bao gồm các giám đốc điều hành hàng đầu từ Baidu, Alibaba, Tencent, Huawei, SenseTime và iFlyTek, cùng với các chuyên gia học thuật và viễn thông.
WeatherlyNuruhussein Hussein bị cáo buộc đóng giả làm tài xế Uber để đánh cắp hàng trăm nghìn đô la tiền điện tử bằng cách lừa hành khách giao nộp điện thoại. Liệu dịch vụ gọi xe có trở thành mục tiêu mới của tội phạm không?
KikyoTài khoản X của Drake đã bị hack để quảng bá cho một đồng tiền meme giả dựa trên Solana, “Anita,” lợi dụng mối quan hệ của anh với nền tảng cờ bạc Stake. Vụ lừa đảo đã lừa những người theo dõi đầu tư hơn 5 triệu đô la trước khi các bài đăng bị xóa.
AnaisMarc Andreessen, đồng sáng lập Andreessen Horowitz, cảnh báo các quy định về AI của Biden có thể kìm hãm sự đổi mới và tập trung hóa sự phát triển. Ủng hộ sự kiểm soát tối thiểu của chính phủ, ông ủng hộ Trump vì lập trường ủng hộ đổi mới của ông. Sự chia rẽ này có khiến nhiều nhà lãnh đạo công nghệ hơn ngả về phía Trump không?
CatherineMột người Singapore 32 tuổi đã bị bắt tại Thái Lan vì vai trò của anh ta trong một vụ lừa đảo tiền điện tử đã lừa đảo các nhà đầu tư 22,4 triệu baht. Vụ lừa đảo liên quan đến một nền tảng giao dịch giả mạo đã lừa nạn nhân chuyển tiền vào các tài khoản gian lận do một mạng lưới tội phạm kiểm soát.
AnaisWeChat đã đóng 209 tài khoản liên quan đến việc sử dụng AI để mạo danh người nổi tiếng cho mục đích tiếp thị gian lận, sau nhiều báo cáo của người dùng. Nền tảng này đã xóa 532 nội dung lừa đảo và cam kết tăng cường các biện pháp chống lại các vụ lừa đảo do AI điều khiển.
Joy