Hiểu hơn về Connext - Phần 1

Bài đăng này là Phần 1 của loạt bài nhằm mục đích tạo nên một không gian về thiết kế Bridge an toàn và đưa ra lý do tại sao Connext chính là một sự tồn tại thiết yếu. Phần 2 và 3 sẽ được xuất bản trong vài tuần tới.

Trong vài năm qua, không gian crosschain bằng bridge này đã chứng kiến ​​một số vụ hack tồi tệ nhất do lỗi của các giao thức bắc cầu. Điều này, cùng với việc thiếu các thực tiễn tốt nhất cho kiến ​​trúc cầu và số lượng ngày càng tăng của các dự án cầu được xác minh bên ngoài , đã khiến hầu hết các nhà phát triển đặt câu hỏi:

Có thể phát triển crosschain một cách an toàn được hay không?

Trả lời câu hỏi này là trọng tâm cốt lõi của chúng tôi khi thiết kế bản nâng cấp Amarok của Connext vào năm ngoái. Điều chúng tôi nhận ra là chúng tôi cần suy nghĩ lại về việc Bridging từ các nguyên tắc đầu tiên để xác định cụ thể:

• Các thành phần khác nhau của Messaging Bridge là gì?

• Thành phần nào đóng góp nhiều nhất vào rủi ro tin cậy và bảo mật?

• Bằng cách nào chúng ta có thể bù đắp hoặc giảm bớt rủi ro của các thành phần đó?

Mục tiêu của chúng tôi với loạt bài đăng này là giải nén những điều trên và bằng cách đó, giải thích cách chúng tôi tin rằng chúng tôi (và cộng đồng rộng lớn hơn) có thể làm việc cùng nhau để khắc phục tình trạng về các vấn đề Bridge.

Bridge là gì?

Hãy bắt đầu với những điều cơ bản, thậm chí một Bridge là gì? Thuật ngữ Bridge khá over và có khá nhiều nghĩa để giải thích:

1. Giao diện người dùng ứng dụng cho phép bạn chuyển mã token giữa các chain.

2. Một giao thức cơ bản để gửi token xuyên các chain.

3. Một cơ chế truyền tin (tùy ý) từ chain này sang chain khác.

Để làm cho vấn đề trở nên khó hiểu hơn, (3) ở trên cũng thường được gọi là giao thức truyền tin chuỗi chéo (cross-chain), hệ thống chuyển message tổng quát hoặc giao thức có khả năng tương tác. Một số thậm chí còn lập luận rằng (3) rõ ràng không phải là bridge hoặc “nằm ngoài bridge”, mặc dù đây thường chỉ là một nỗ lực ngữ nghĩa của các dự án nhằm tách bản thân khỏi thuật ngữ này.

Đối với mục đích của bài đăng trên blog này, chúng tôi sẽ sử dụng thuật ngữ Messaging Bridge làm định nghĩa cho (3) ở trên (vì đây là nguyên mẫu làm cơ sở cho bất kỳ loại Bridge dành riêng cho bất kỳ ứng dụng nào). Chúng tôi cũng sẽ đánh giá các Bridge dành riêng cho từng ứng dụng theo trường hợp sử dụng của chúng — ví dụ: Bridge NFT hoặc Bridge Token.

Messaging Bridge Flow

Ngày nay có rất nhiều công trình Messaging Bridge khác nhau. Mặc dù vậy, tất cả các Messaging Bridge đều có cấu trúc lõi giống nhau, triển khai ba thành phần sau (được hiển thị tốt nhất dưới dạng các layer):

• Transport: Đăng dữ liệu message từ chuỗi này sang chuỗi khác.

• Verification: Chứng minh tính đúng đắn của dữ liệu trên.

• Execution: Làm điều gì đó với bridged data.

Hãy đi sâu vào cách hoạt động của từng Layer.

Transport

Transport là cách tải trọng dữ liệu (payload data) được đọc từ Domain này và chuyển tiếp sang Domain khác, không đưa ra giả định nào về tính chính xác của dữ liệu.

Việc Transport thường được thực hiện bởi một hoặc nhiều tác nhân offchain xem “outbox” trên hợp đồng Bridge chain gốc, sau đó đăng dữ liệu tương ứng vào “Inbox” trên hợp đồng Bridge chain đích. Khá đơn giản để xây dựng điều này bằng cách sử dụng các thành phần có sẵn để đọc và ghi vào các Blockchain.

Nguy cơ bị hack hoặc các lỗi khác ở Layer Transport là khá nhỏ. Tệ nhất, chúng dẫn đến thời gian ngừng hoạt động của Bridge vì tin nhắn không còn có thể được gửi qua các chuỗi. Sử dụng các phụ thuộc từ decentralized/fault-tolerant hơn như Subgraph và relayer networks (Gelato , Keep3r , v.v.) có thể giảm rủi ro thời gian ngừng Transport.

Verification

Verification là cách giao tiếp xuyên chuỗi được bảo mật. Sau khi tải trọng của một số dữ liệu (payload data) được vận chuyển qua các chuỗi, Verification Layer sử dụng một số cơ chế để đảm bảo rằng dữ liệu được đăng lên chuỗi đích giống với dữ liệu ban đầu được đăng trên origin. 

Làm cách nào để bạn xác minh một Message đi qua các chuỗi? Có một số phương pháp, mỗi phương pháp có sự đánh đổi về độ tin cậy, độ trễ và độ phức tạp của riêng chúng.

“Chúng tôi đề cập đến một số phương pháp này trong các bài đăng trên blog Bộ ba bất khả thi về khả năng tương tác và Optimism Bridge của chúng tôi . Chúng tôi cũng sẽ đi sâu hơn vào các sắc thái của việc xác minh Messaging Bridge trong bài đăng blog tiếp theo trong loạt bài này.”

Đối với mục đích của bài đăng này, điều quan trọng nhất cần hiểu là xác minh Message là phần khó khăn trong việc xây dựng Bridge.

Các Verification Layer bảo mật dữ liệu tùy ý và không thể biết đến từ một nguồn không đáng tin cậy trên một chain khác, yêu cầu các phụ thuộc vào các tác nhân bên ngoài hoặc mật mã phức tạp. Ngay cả khi việc triển khai Verification Layer là an toàn, thì việc xác minh thông báo cũng có nguy cơ bị tấn công nếu nó không được giảm thiểu độ tin cậy, chẳng hạn như tấn công 51% lớp xác minh m-of-n .

Những thách thức này làm cho các lớp xác minh rất khó kiểm tra.

Mọi vụ hack Bridge lớn đều liên quan đến lỗi xác minh Messsage ở một số khả năng. Khi các Verification Layer bị tấn công, những kẻ tấn công sẽ có quyền truy cập “đặc quyền” vào mọi thứ được kiểm soát bởi Messaging Bridge, chẳng hạn như bất kỳ token bị khóa nào được Bridging qua các chain. Vì lý do này, chúng tôi (và nhiều người khác) thực sự khuyên các nhà phát triển ứng dụng không thực hiện xác minh thông báo của riêng họ. Hậu quả của việc phạm sai lầm ở Layer này có thể rất nghiêm trọng.

Execution

Execution Layer là một tập hợp các tác nhân Offchain chịu trách nhiệm đảm bảo rằng, sau khi một số dữ liệu được vận chuyển qua các chain và được xác minh là chính xác, thì dữ liệu đó có thể được thực thi theo target contract, kích hoạt một hoặc nhiều tương tác trên destination chain. Bridge execution layer là thứ mà các nhà phát triển xây dựng dựa trên , bằng cách trả phí/gửi calldata đến giao diện messaging bridge ở điểm gốc, để gọi một hợp đồng tại điểm đến (destination).

Trong nhiều trường hợp, các Execution Layer sẽ đóng gói dữ liệu vào các gốc merkle ở điểm destination (và sau đó giải nén dữ liệu đó bằng cách sử dụng bằng chứng merkle ở destination) hoặc chuyển tiếp block headers (và thực hiện storage proofs ở destination). Điều này là do việc vận chuyển và xác minh thường khá tốn kém (đặc biệt là các phương pháp giảm thiểu độ tin cậy như light client header verification) và do đó, chi phí cho mỗi giao dịch cần phải được giảm xuống bằng cách chia theo từng đợt.

Các Execution Layer hoàn toàn thừa hưởng rủi ro xác minh thông báo, nhưng bản thân chúng có hồ sơ rủi ro bảo mật và độ tin cậy thấp. Execution Layer sẽ xử lý các messages như một phần của việc gộp chúng và chuyển chúng đến/từ các Layer thấp hơn, nhưng những tương tác này thường khá tối thiểu và dễ kiểm tra. 

Vì các hợp đồng ở Execution Layer chịu trách nhiệm chính trong việc phân phối phí và thanh toán thanh khoản cho các tác nhân Offchain, nên một vụ hack ở layer này thường chỉ liên quan đến hành vi trộm cắp doanh thu phí hoặc mất tiền của các tác nhân offchain đang tích cực vận hành mạng — tất cả đều có tác động thấp hơn đáng kể so với hack verification layer.

Trường hợp đặc biệt: Fast Execution

Thú vị là khía cạnh thực thi được đánh giá thấp là hoàn toàn có thể (một cách an toàn và đáng tin cậy), thực hiện một số loại tương tác Crosschain trước khi message chứa tương tác đó được vận chuyển và xác minh.

Khái niệm này có lẽ được minh họa rõ nhất bằng cách xem xét cách thức hoạt động của các hệ thống “fast-liquidity” trên các Bridge Optimism Rollups. Nếu Alice gửi 100 USDC từ Optimism đến Ethereum, cô ấy thường phải đợi đủ 7 ngày để nhận được tiền của mình. Để rút ngắn thời gian chờ đợi này, Alice có thể trả cho Bob (người đã có 100 USDC trên Ethereum) một khoản phí để gửi tiền cho cô ấy ngay lập tức và Bob có thể yêu cầu 100 USDC đến từ Optimism Bridge. Trong ví dụ này, về cơ bản, Bob đã “gửi trước” tiền cho Alice, biết rằng anh ta làm như vậy là an toàn vì có một đảm bảo onchain rằng anh ta sẽ được hoàn trả sau thời hạn 7 ngày.

Nguyên tắc cốt lõi đằng sau tính Fast-liquidity có thể được khái quát hóa để thực hiện khớp lệnh nhanh . Thay vì chỉ chuyển 100 USDC qua các chain, Alice có thể yêu cầu Bob call contract này thay cho cô ấy, thanh toán tiền của chính anh ấy. Miễn là Bob có thể thấy rằng Alice đã bắt đầu call “slow path” trên các chain, anh ấy có một đảm bảo onchain rằng anh ấy sẽ được hoàn trả trong tương lai.

Cơ chế này có thể được áp dụng cho mọi trường hợp Alice muốn gọi một hàm (công khai) chưa được xác thực — tức là một hàm không hạn chế người gọi là ai. 

Ví dụ: nếu Alice là một DAO và hàm mục tiêu có một công cụ onlyDAO modifier, thì Bob sẽ không thể thực hiện nhanh giao dịch của Alice ngay từ đầu.

Tổng kết

Rõ ràng từ cuộc thảo luận ở trên rằng, nếu chúng ta muốn xây dựng Messaging Bridge toàn hơn, trước tiên chúng ta nên ưu tiên tập trung vào việc cải thiện cả tính bảo mật và giảm thiểu sự tin cậy của các verification layer.

Trong bài đăng tiếp theo của chúng tôi, chúng tôi sẽ đi sâu vào tìm hiểu lý do chính xác tại sao rất khó để xây dựng một secure crosschain message verification layer an toàn duy nhất ngay từ đầu. Sau đó, chúng tôi sẽ thiết lập kết quả tốt nhất có thể cho việc xác minh message và cách chúng tôi có thể tối ưu hóa bảo mật khi chúng tôi đạt được điều đó.

Giới thiệu về Connext

Connext là một mạng kết nối tốc độ cao, giảm thiểu sự tin cậy (Trustless) của bên thứ 3 giữa các Chain và Rollups. Đây là hệ thống tương tác duy nhất thực hiện điều này với chi phí rẻ và nhanh chóng mà không đưa ra bất kỳ một minh chứng tin cậy mới nào. Connext hướng đến các nhà phát triển đang tìm cách xây dựng cầu nối và các ứng dụng chuỗi chéo nguyên bản khác. Cho đến nay, hơn 1,5 tỷ đô la trong các giao dịch đã vượt qua mạng lưới

Website | Build | Twitter | Discord | Blog