XRPL x Axelar: 'Native Cross-Chain' hay vụ mua lại lỗ hổng? - Góc nhìn audit
Nếu tôi nói với bạn rằng XRP Ledger — mạng lưới được thiết kế với nguyên tắc 'tối giản để an toàn' — vừa giới thiệu một tính năng 'native cross-chain transfer' thông qua Axelar, điều đầu tiên tôi sẽ làm là mở block explorer và tìm kiếm một hợp đồng thông minh tên là AxelarGateway. Tôi đã làm điều đó. Không tồn tại. Sau đó tôi tìm trên danh sách amendment của XRPL. Không có bất kỳ amendment nào liên quan đến việc thay đổi giao thức để hỗ trợ GMP. Vậy 'native' mà thông báo nói đến nằm ở đâu? Câu trả lời ngắn gọn: nó nằm ở một lớp mà bạn không thể nhìn thấy từ bên ngoài. Và đó chính là vấn đề.
Bởi vì trong kỹ thuật, không có cái gọi là 'native' mà không có code. Native có nghĩa là một phần của hệ thống, được tích hợp sâu vào cơ chế đồng thuận, hoặc ít nhất là một hợp đồng được xác minh trên mainnet. Khi một tính năng không đáp ứng được những tiêu chí đó, nó chỉ là một lớp sơn. Trong một thị trường tăng giá, lớp sơn này có thể che giấu một cấu trúc rủi ro mà người dùng không hề hay biết.
Để hiểu tại sao tích hợp này lại đáng chú ý, cần phải nhìn lại kiến trúc của cả hai hệ thống. XRPL được khởi tạo vào năm 2012 với một mục tiêu duy nhất: thanh toán xuyên biên giới nhanh và rẻ. Nó không có máy ảo Turing-complete. Thay vào đó, nó sử dụng Cobalt — một ngôn ngữ lập trình riêng, chỉ có một bộ tập lệnh giới hạn. Điều này có nghĩa là phần lớn các hợp đồng thông minh trên Ethereum không thể chạy trên XRPL. Các nhà phát triển phải viết lại hoàn toàn bằng Cobalt. Cơ chế đồng thuận của XRPL dựa trên UNL — một danh sách các validator do Ripple và cộng đồng giới thiệu. Mạng lưới này có thể xác nhận một khối trong 3-5 giây với phí gần bằng 0. Nhưng cái giá phải trả là sự đơn giản: không có composability, không có DeFi phức tạp, không có hệ sinh thái sôi động.
Axelar, ra mắt năm 2021 bởi các nhà nghiên cứu từ MIT, là một mạng lưới trung gian với khoảng 75 validator. Nó sử dụng giao thức General Message Passing (GMP). Ý tưởng rất đơn giản: mỗi chuỗi tham gia sẽ triển khai một hợp đồng gateway; các validator của Axelar lắng nghe các sự kiện trên tất cả các chuỗi, ký các tin nhắn khi có đủ 2/3 trọng số staking, và truyền tin nhắn đến chuỗi đích. Đây là một mô hình 'validator network' — về cơ bản khác với mô hình light-client mà Cosmos IBC sử dụng, nơi mỗi chuỗi tự xác minh trạng thái của chuỗi khác.
Bối cảnh quan trọng: các cây cầu xuyên chuỗi đã trở thành mục tiêu lớn nhất của hacker trong lịch sử crypto. Ronin mất 600 triệu USD, Wormhole mất 325 triệu USD, Poly Network mất 611 triệu USD. Tất cả đều có chung một đặc điểm: chúng dựa vào một nhóm validator hoặc relayer tập trung, và khi nhóm đó bị xâm phạm, toàn bộ tài sản bị rút sạch. Đây là một sự thật mà bất kỳ ai làm audit đều nhớ như in.
Bây giờ, hãy xem điều gì sẽ xảy ra khi XRPL 'tích hợp' Axelar. Về mặt kỹ thuật, có một khả năng duy nhất khả thi trong ngắn hạn: một hợp đồng gateway được viết bằng Cobalt, triển khai trên XRPL, hoạt động như một tài khoản ký quỹ đa chữ ký. Khi người dùng muốn chuyển XRP sang Ethereum, họ gửi XRP vào hợp đồng này. Các validator Axelar quan sát giao dịch, xác nhận và ký một thông điệp trên Ethereum để mint token tương ứng. Người dùng nhận được XRP bắc cầu (wrapped XRP) ở đầu kia.
Có thể thấy ngay một sự bất đối xứng: tài sản của người dùng đang nằm trong một két sắt, nhưng chìa khóa của két sắt không do XRPL nắm giữ. Chìa khóa nằm trong tay 2/3 validator Axelar. Nếu các validator này bị tấn công hoặc thông đồng, họ có thể rút toàn bộ tài sản trong gateway. Đây là một mô hình tin cậy yếu hơn so với UNL của XRPL — nơi Ripple kiểm soát danh sách validator dựa trên danh tính thực. Axelar validator là những người stake token AXL, có thể ẩn danh. Một validator ẩn danh, stake lớn, bị hack — một kịch bản đã từng xảy ra với các mạng tương tự.
Sự khác biệt với IBC càng rõ ràng hơn. IBC sử dụng light-client verification: mỗi chuỗi tự kiểm tra các block header của chuỗi đối tác, xác minh chữ ký của validator trên chính chuỗi đó, và không cần một lớp trung gian nào. Điều này loại bỏ hoàn toàn rủi ro bên thứ ba. Nhưng triển khai IBC trên XRPL đòi hỏi phải viết code verify header trong Cobalt — một công việc khó khăn, đòi hỏi phải thay đổi giao thức và có thể mất nhiều năm. Axelar là một lối tắt. Một lối tắt chấp nhận rủi ro.
Ở đây, kinh nghiệm cá nhân của tôi có giá trị. Tôi đã dành 3 tháng để đọc hợp đồng The DAO vào năm 2017 và tìm ra lỗ hổng reentrancy mà nhiều người bỏ qua. Một trong những lý do khiến lỗ hổng đó tồn tại là vì các tác giả của hợp đồng đã vay mượn các pattern phổ biến từ những hệ thống khác mà không hiểu đầy đủ về môi trường thực thi mới. Khi bạn viết một hợp đồng gateway trong Cobalt — một ngôn ngữ không có thư viện chuẩn, không có các mẫu an toàn có sẵn như trong Solidity — bạn đang tái tạo lại bánh xe bằng một loại gỗ chưa từng được kiểm chứng. Một lỗi logic trong việc xử lý tin nhắn GMP có thể dẫn đến mất vĩnh viễn.
Về mặt tokenomics, thông báo này thay đổi vai trò của XRP một cách tinh tế. XRP vốn là một token thanh toán. Giờ đây, nó trở thành một tài sản xuyên chuỗi — có thể được sử dụng làm tài sản thế chấp trên các giao thức DeFi ở chuỗi khác. Điều này mở ra một thị trường mới, nhưng đồng thời cũng tạo ra dòng chảy hai chiều: thanh khoản có thể chảy từ XRPL ra ngoài để tìm kiếm lợi suất, làm giảm thanh khoản trên chính XRPL. AXL, ngược lại, hưởng lợi trực tiếp từ mỗi giao dịch xuyên chuỗi — vì mọi giao dịch đều phải trả phí bằng AXL. Đây là một động cơ rõ ràng: Axelar cần XRPL như một nguồn doanh thu, trong khi XRPL chỉ nhận được một giá trị tùy chọn — khả năng có thể sử dụng trong tương lai. Sự bất đối xứng giá trị này thường bị bỏ qua.
Một chi tiết quan trọng khác mà hầu hết mọi người không để ý: Hooks. Hooks là một cơ chế cho phép chạy code trước hoặc sau một giao dịch trên XRPL, nhưng nó vẫn đang trong giai đoạn thử nghiệm. Nếu gateway của Axelar dựa trên Hooks, thì nó chưa thể hoạt động trên mainnet ổn định. Nếu không dựa trên Hooks, thì làm thế nào để hợp đồng Cobalt phản hồi lại các sự kiện một cách tự động? Câu trả lời có thể nằm ở việc sử dụng một tập hợp các tài khoản đa chữ ký hoặc một cơ chế off-chain. Cả hai đều không được nói đến trong thông báo. Điều này khiến tôi tự hỏi: thông báo này được viết bởi đội ngũ marketing hay đội ngũ kỹ thuật?
Đây là điểm mù quan trọng nhất. Khi một mạng lưới như XRPL, vốn được xây dựng dựa trên uy tín của nó về sự an toàn và ổn định, tuyên bố một tính năng là 'native', nó đang cho mượn uy tín của mình cho một hệ thống mà nó không kiểm soát. Người dùng XRPL — những người đã quen với việc XRP không bao giờ bị hack trong hơn 10 năm — sẽ tự động tin tưởng vào tính năng mới này. Họ sẽ không đọc hợp đồng. Họ sẽ không kiểm tra validator set. Họ sẽ chỉ thấy chữ 'native' và bấm nút chuyển tiền.
Nếu Axelar gặp sự cố — một validator hack, một lỗi trong hợp đồng, một cuộc tấn công quản trị — thì tổn hại sẽ không chỉ dừng lại ở số tiền bị mất. Nó sẽ làm tổn hại đến niềm tin vào XRPL. Đây là một sự liên kết rủi ro bất đối xứng: XRPL chịu rủi ro danh tiếng, còn Axelar hưởng lợi từ uy tín đó. Trong một thị trường tăng, khi mọi người đang chạy theo giá, những cấu trúc rủi ro như thế này thường bị đánh giá thấp. Tôi đã thấy điều này xảy ra với các dự án khác — nơi các mối quan hệ đối tác hào nhoáng che giấu những khiếm khuyết kỹ thuật cơ bản. Một nhà phân tích tốt không bao giờ nhìn vào logo; họ nhìn vào mã.
Vậy tôi sẽ làm gì với thông tin này? Tôi sẽ không gửi bất kỳ tài sản có giá trị đáng kể nào qua cây cầu trong 90 ngày đầu tiên. Tôi sẽ chờ đợi một báo cáo kiểm toán công khai từ một công ty có uy tín, và tôi sẽ tìm kiếm bằng chứng on-chain về việc gateway thực sự được sử dụng. Nếu khối lượng xuyên chuỗi sau 30 ngày dưới 1 triệu USD, đó là một con số đáng lo ngại — nó cho thấy không có nhu cầu thực tế, chỉ có một thông cáo báo chí.
Nhưng câu hỏi lớn hơn vẫn còn đó: tại sao XRPL lại chọn Axelar thay vì IBC? Câu trả lời nằm ở chi phí và tốc độ, không phải ở công nghệ. Và khi một quyết định kỹ thuật được đưa ra vì chi phí thay vì an toàn, người dùng cuối cùng sẽ phải trả giá. Trong một thị trường tăng, giá đó thường không được nhìn thấy cho đến khi quá muộn.