Op-ed: Tưởng tượng lại các cầu nối xuyên chuỗi: Hãy ngừng cố gắng trở thành các giao thức thanh khoản

Sau một số khai thác quy mô lớn của các cây cầu, rất nhiều ôxy được đưa ra cho nhận định rằng công nghệ chuỗi chéo vốn có nhiều khiếm khuyết - rằng khả năng tương tác chuỗi chéo có nghĩa là rủi ro. Với ước tính khoảng 2 tỷ đô la bị mất do 13 vụ hack cầu trong năm nay, ngày càng khó để bỏ qua lập luận này.

At deBridge, chúng tôi nghĩ rằng không chỉ bắt buộc mà còn không thể tránh khỏi mà tất cả các cầu nối xuyên chuỗi hoàn toàn suy nghĩ lại về cách tiếp cận của họ đối với việc tổng hợp thanh khoản.

Hạn chế của thanh khoản bị khóa

Bằng cách khóa thanh khoản để cung cấp định tuyến chuỗi chéo (như hầu hết mọi cây cầu hiện nay đều làm), các cây cầu đã tự đặt mình vào một cuộc cạnh tranh mà họ nhất định phải thua. Chúng tôi đang thấy các cầu nối đối mặt với các giao thức thanh khoản được xây dựng có mục đích, được thiết lập như BÓNG MA, Hợp chấtvà frax, các dự án chắc chắn sẽ kiếm tiền từ thanh khoản một cách hiệu quả và an toàn hơn. Ví dụ có rất nhiều cầu nối với hàng trăm triệu đô la trong TVL, với khả năng sử dụng thanh khoản bị khóa cực kỳ thấp.

Với thiết kế này, các dự án cầu buộc phải chạy các chiến dịch khai thác thanh khoản không bền vững mà không đưa ra được các giải pháp hiệu quả vốn dài hạn. Trừ khi các ưu đãi mã thông báo được duy trì vô thời hạn - một tham vọng không chắc chắn đối với bất kỳ dự án nào - các nhà cung cấp thanh khoản chắc chắn sẽ loại bỏ vốn để theo đuổi các cơ hội có năng suất cao hơn.

Để tổng hợp thanh khoản một cách an toàn, các cầu nối sẽ cần có các chính sách bảo hiểm để cho phép các nhà cung cấp thanh khoản có khả năng phòng ngừa rủi ro. Đây là một khoản chi phí khác khiến việc kiếm tiền từ thanh khoản trở nên khó khăn hơn. Đó là lý do tại sao hầu hết các cây cầu hiện tại không có lợi nhuận, vì chi phí và phần thưởng khai thác thanh khoản được trả thường vượt quá lợi nhuận ròng của giao thức.

Ở đây cũng có những cân nhắc về mặt kiến ​​trúc, vì chuyển giao giá trị xuyên chuỗi là một yêu cầu có thể được giải quyết theo nhiều cách khác nhau. Tất cả các cầu hiện có đều giải quyết các lệnh này từ các nhóm thanh khoản của riêng họ, nơi thanh khoản liên tục bị khóa khi cần thiết chỉ vào thời điểm chính xác việc chuyển giao giá trị sẽ được thực hiện.

Kích thước của lệnh cũng có thể khác nhau - nếu nó vượt quá kích thước của nhóm thanh khoản của cây cầu, thì người gửi sẽ kết thúc với các mã thông báo được bao bọc hoặc một giao dịch bị đình chỉ / bị kẹt vô thời hạn. Mặt khác, nếu lệnh quá nhỏ so với quy mô của nhóm thanh khoản, thì việc sử dụng thanh khoản rất thấp và không hiệu quả. Vòng luẩn quẩn này càng làm nổi bật rằng cách tiếp cận giao thức thanh khoản này đối với thiết kế cầu là không hiệu quả và sai về cơ bản.

Giải quyết vấn đề bảo mật

Vấn đề quan trọng như hiện nay, tính không bền vững về kinh tế không phải là thách thức chính duy nhất ở đây. Ngay cả khi giả sử các cây cầu đã tìm ra cách để sử dụng phương pháp thanh khoản bị khóa và duy trì hiệu quả vốn, thì hiện tại, rõ ràng rằng việc xây dựng một giao thức thanh khoản an toàn là một nhiệm vụ tốn nhiều công sức. Thật vậy, bằng cách cố ý hoặc vô tình trở thành các giao thức thanh khoản, các dự án cầu nối đang tự đặt cho mình nhiệm vụ to lớn là bảo vệ bề mặt tấn công từ nhiều phía.

Để bắt đầu ở cấp độ cao, một trong những vấn đề rõ ràng với cầu nối kiểu thanh khoản bị khóa là nó tạo ra hiệu ứng nhân rủi ro, nơi các lỗ hổng của một chuỗi được hỗ trợ có thể tràn sang làm ảnh hưởng đến nguồn vốn được nắm giữ trong các hệ sinh thái khác.

Ở đây, có vấn đề về bảo mật bằng proxy. Một cây cầu có thể có toàn bộ cơ sở thanh khoản của nó bị xâm phạm nếu có một lỗ hổng tiềm ẩn trong cơ sở mã của một blockchain / L2 được hỗ trợ. Chúng tôi đã thấy khả năng này vào đầu năm nay với một lỗ hổng được phát hiện trong Lạc quan, cho phép những kẻ tấn công lấy một số lượng tài sản tùy ý và có thể trao đổi chúng lấy các mã thông báo trong các hệ sinh thái khác.

Tuần trước, tôi đã phát hiện (và báo cáo) một lỗi nghiêm trọng (đã được vá đầy đủ) trong @optimismPBC (một “giải pháp mở rộng quy mô lớp 2” cho Ethereum) sẽ cho phép kẻ tấn công in số lượng mã thông báo tùy ý, mà tôi đã giành được tiền thưởng 2,000,042 đô la. https://t.co/J6KOlU8aSW

- Jay Freeman (saurik) (@saurik) 10 Tháng hai, 2022

Một lần nữa, bất kỳ vấn đề nào với cơ chế đồng thuận của một chuỗi cũng có thể dẫn đến sự lây lan hệ thống, gây rủi ro cho bất kỳ thanh khoản nào bị khóa trong các chuỗi được hỗ trợ khác. Trong trường hợp này, cây cầu chỉ đơn giản là truyền phát khai thác đến các chuỗi khác. Điều này có thể bao gồm các cuộc tấn công 51% hoặc các lỗi cấp giao thức khác.

Bên cạnh những loại rủi ro kế thừa này, chúng ta ngày càng thấy những tình huống mà các sai lầm của chính các dự án cầu nối, bằng cách này hay cách khác, gây ra mất thanh khoản bị khóa. Từ việc nâng cấp giao thức bị lỗi, thiết kế hợp đồng thông minh kém hoặc cơ sở hạ tầng bị xâm phạm của trình xác thực, có nhiều tình huống mà các tác nhân xấu có thể khai thác các lỗ hổng trong chính cây cầu.

Tất cả những rủi ro này nhanh chóng phức tạp và - như chúng ta đã thấy trong quá nhiều trường hợp - cuối cùng được tạo ra bởi các nhà cung cấp thanh khoản khi họ mất khả năng mua lại của tài sản được bao bọc của họ. Một khả năng như vậy là không thể chấp nhận được.

Rất ít người phủ nhận lời hứa to lớn về khả năng tương tác chuỗi chéo để đẩy việc áp dụng Web3 lên một tầm cao mới. Nhưng với quy mô và tần suất khai thác cầu tuyệt đối, rõ ràng là thiết kế cơ bản của công nghệ bắc cầu cần phải được hình dung lại từ những nguyên tắc đầu tiên. Thiết kế giao thức thanh khoản-chuyển đổi cầu nối không hoạt động.

Có cách nào chúng ta có thể nghĩ ra một cách tiếp cận cơ bản mới và độc đáo để thiết kế cầu nối, một phương pháp loại bỏ hoàn toàn rủi ro cho các nhà cung cấp thanh khoản, loại bỏ các vectơ tấn công và đồng thời duy trì mức hiệu quả sử dụng vốn cao nhất không?

Có thể có chính xác điều đó trong tương lai gần. Tại deBridge, chúng tôi đang nghiên cứu một định tuyến thanh khoản xuyên chuỗi mới có thể giải quyết tất cả những vấn đề này. Giữ nguyên.