Kiến trúc rủi ro bắc cầu L2

Tiêu đề gốc: "Kiến trúc rủi ro cầu nối L2"

Nguồn gốc: bartek.eth, ETH Chinese

Vaibhav Chellani từ Socket và tôi muốn đề xuất một kiến trúc rủi ro để đánh giá hồ sơ bảo mật của các kiến trúc cầu khác nhau.

Giống như các khung rủi ro L2 khác nhau, mục tiêu tổng thể của chúng tôi là nhanh chóng "phân loại" một giải pháp vào trong một nhóm giải pháp cụ thể có các giải pháp tương tự. các đặc điểm, đồng thời đủ chi tiết để trình bày cho người dùng các giả định về bảo mật mà họ cần chấp nhận khi sử dụng các cầu nối này.

Chúng tôi chủ yếu tập trung vào việc kết nối giữa Ethereum và các chuỗi khác, vì chúng tôi sẽ sớm giới thiệu những chuỗi này trên l2beat.com (ghi chú của người biên tập bản dịch : Cột bắc cầu hiện đang hoạt động), tuy nhiên, lý do cơ bản về tính bảo mật của các giải pháp này cũng áp dụng cho việc kết nối bất kỳ chuỗi nào với chuỗi khác. Tại thời điểm này, chúng tôi đang tìm kiếm phản hồi từ cộng đồng rộng lớn hơn về khuôn khổ được đề xuất này.

Loại cầu

Đối với người dùng cuối, việc bắc cầu tài sản đề cập đến chuỗi) nhận tiền gửi của một nội dung nhất định và gửi nội dung đó cho người dùng trên chuỗi đích.

Ví dụ: một quy trình bắc cầu điển hình là Alice chuyển tiền vào hợp đồng bắc cầu của chuỗi A, và sau đó Alice nhận được tiền trên chuỗi B. để tài trợ từ việc bắc cầu.

Nói chung, quá trình này xảy ra theo hai cách:

· Cầu nối mã thông báo dựa trên tin nhắn - Những cầu nối này cho phép thanh khoản chảy qua các chuỗi dưới dạng truyền tin nhắn. Nói chung, chúng cho phép khai thác một tài sản trên chuỗi mục tiêu sau khi nó bị khóa hoặc phá hủy trên chuỗi nguồn. Ví dụ: Cầu nối tổng hợp, cầu nối gốc Đa giác, Anyswap (anyCall) và mạng Axelar.

· Mạng thanh khoản - Ngoài ra còn có những cầu nối sẽ mua lại một số tài sản đúc được. Chúng cho phép người dùng chuyển tài sản sang các chuỗi khác, giả sử rằng những tài sản này đã được chuyển trước thông qua “Message Bridge” (Cầu thông báo). Ví dụ: Connecxt dựa trên Nomad Bridge, Hop dựa trên Hop Optimistic Bridge, một số HTLC khác (Hợp đồng khóa thời gian băm, hợp đồng khóa thời gian băm) và chuyển khoản có điều kiện (chẳng hạn như nova, v.v.).

An ninh của các cầu truyền tin nhắn

Trong phần này, chúng tôi sẽ cố gắng giải thích các cách khác nhau để xác thực thông báo chuỗi chéo được sử dụng bởi nhiều giao thức cầu nối. Như được minh họa trong hình trên, cầu nối Token tận dụng tính bảo mật của cầu nối truyền tin nhắn.

· Light client xác minh tính hợp lệ của trạng thái

Mô tả: Cầu nối xác minh tính hợp lệ của quá trình chuyển đổi trạng thái chuỗi nguồn trên chuỗi mục tiêu. Quá trình xác minh này được thực hiện thông qua bằng chứng không có kiến thức (quá trình chuyển đổi trạng thái đi kèm với việc tạo bằng chứng zk) hoặc hệ thống chống gian lận (cho phép người xác minh độc lập tranh chấp tính hợp lệ của gốc trạng thái mới).

Ví dụ: Tất cả các bản tổng hợp đều là ví dụ ở đây, L1 sẽ vượt qua FraudProof (bằng chứng gian lận) hoặc ValidityProof ( bằng chứng hợp lệ) xác minh sự chuyển đổi trạng thái của L2.

· Đồng thuận xác minh khách hàng nhẹ

Mô tả: Một cầu nối xác minh sự đồng thuận của chuỗi nguồn trên chuỗi mục tiêu. Điều này phụ thuộc vào cơ chế đồng thuận được chuỗi nguồn sử dụng và thường bao gồm việc kiểm tra chữ ký đại biểu của ủy ban xác thực hiện tại, nếu chuỗi nguồn sử dụng giao thức đồng thuận đề xuất và bỏ phiếu kiểu PBFT (chẳng hạn như Tendermint, HotStuff, Giao thức Casper FFG). Ngoài ra, nếu chuỗi nguồn sử dụng giao thức PoW hoặc giao thức PoS "chuỗi dài nhất" (chẳng hạn như Ouroboros, ETH 2.0 LMD Ghost, v.v.), hãy sử dụng các quy tắc phân nhánh có liên quan để kiểm tra chuỗi dài nhất.

Ví dụ: Cầu nối cầu vồng NEAR (bỏ qua Sự lạc quan liên quan đến sự phức tạp của việc xác minh cơ chế chữ ký NEAR các thành phần quy trình), cầu PoS của Polygon (kiểm tra sự đồng thuận của chuỗi Heimdall) và Cosmos IBC (xác minh chữ ký của chuỗi Cosmos khác).

· Bộ trình xác nhận bên ngoài

Mô tả: Sử dụng trình xác thực bên ngoài làm cầu nối dẫn đến nguồn sự thật, tức là, những người xác thực thành lập một ủy ban độc lập, thay vì người xác thực trên chuỗi nguồn và chuỗi đích. Tùy thuộc vào cách triển khai được những người xác thực này sử dụng, họ có thể sử dụng MultiSig (đa chữ ký), chạy thuật toán đồng thuận (thường là một thuật toán từ lớp đề xuất và biểu quyết), sử dụng cơ chế Chữ ký ngưỡng (TSS, cơ chế chữ ký ngưỡng) hoặc SGX, v.v. ... bất kể họ sử dụng công nghệ nào, đều thuộc phương pháp xác minh này.

Ví dụ: Wormmhole, Multichain, Axelar, DeBridge, Synapse, Stargate.

· Xác minh lạc quan

Mô tả: Một cây cầu với giai đoạn thử thách.

Bên trung thực trong loại xác minh này sẽ tránh đưa thông tin gian lận vào trong giai đoạn này. Tuy nhiên, có một số thông số chính cần xem xét:

1. Độ dài giai đoạn thử thách: càng dài thì càng tốt

2.Kích thước bộ theo dõi: Không cần giấy phép>Yêu cầu giấy phép

Ví dụ:Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.

· Phương pháp xác minh hỗn hợp

Mô tả: Có cấu trúc kết hợp các phương pháp xác minh trên.

An ninh của mạng thanh khoản

Ngoài việc thực sự gửi tài sản qua các chuỗi, còn có một phương pháp khác: trao đổi chuỗi chéo (hoán đổi). Trao đổi chuỗi chéo chỉ có thể được thực hiện bằng cách đổi chủ mà không di chuyển tài sản qua các chuỗi. (Lưu ý của người dịch: Việc đổi chủ có nghĩa là tài sản của một bên trở thành tài sản của một bên khác, tức là chủ sở hữu tài sản thay đổi.)

Một ví dụ đơn giản Ví dụ: Alice ở chuỗi A muốn chuyển tài sản sang chuỗi B. Bob (nhà cung cấp thanh khoản, LP) đã có tài sản có cùng giá trị trên chuỗi B. Anh ta sử dụng tài sản của mình trên chuỗi B để cung cấp dịch vụ trao đổi cho số dư của Alice trên chuỗi A và thu phí dịch vụ. Cuối cùng, Alice sẽ nhận được tài sản trên chuỗi B và Bob sẽ nhận được tài sản + phí dịch vụ trên chuỗi A.

Phần này chỉ mô tả tính bảo mật của giao thức "trao đổi", nghĩa là sau khi LP chấp nhận tiền gửi của bạn trên chuỗi nguồn, khả năng anh ta sẽ bỏ trốn cùng số tiền là bao nhiêu. Những tài sản trao đổi này có sự bảo mật của cầu nối truyền tin nhắn giả mạo chúng.

Ngoài ra còn có các cách khác để trao đổi tài sản:

· HTLC: Còn được gọi là hợp đồng khóa thời gian băm, nó có thể được sử dụng để trao đổi tài sản nguyên tử giữa hai bên trong chuỗi. Thông thường người dùng chỉ cần thực hiện hai bước, một là khóa và hai là mở khóa. Một trường hợp thất bại có thể xảy ra là tiền của bạn sẽ bị khóa trong một khoảng thời gian "ngủ" cố định. Ví dụ:Connext NXTP, Liqualit.

· Chuyển có điều kiện: cho phép LP sử dụng thông báo lối tắt bắc cầu tới Điều này cho phép LP ngay lập tức cung cấp tiền cho người dùng cuối khi có bất kỳ khoản tiền nào được cầu nối và nhận tiền từ cầu nhắn tin. Trong trường hợp thất bại, nếu không có LP để cung cấp thanh khoản, đường dẫn chậm sẽ được kích hoạt. Ví dụ: Hop, Connext Amarok, MakerDAO Teleport.

· Trình xác thực bên ngoài: cho phép người dùng chuyển tiền đến nhà cung cấp cầu nối đáng tin cậy Tại thời điểm này , nhà cung cấp sẽ hứa sẽ giải phóng tiền cho một chuỗi khác. Một kịch bản thất bại có thể xảy ra ở đây là tiền của bạn sẽ bị mất. Ví dụ:Binance

Chống kiểm duyệt

Chúng tôi sẽ xem xét các giả định về bảo mật liên quan đến khả năng một tin nhắn được gửi bởi bridge sẽ bị kiểm duyệt. Thực tế hơn, chúng tôi cũng sẽ khám phá xem liệu một tin nhắn (chuyển mã thông báo) sẽ bị bridge kiểm duyệt hay bỏ qua hay không và nếu nó bị kiểm duyệt, hậu quả đối với tiền của người dùng sẽ là gì (tiền sẽ được trả lại cho người dùng hay liệu họ có bị kẹt trong quá trình "Chuyển" ở trạng thái "trung bình").

Giải pháp điển hình:

· Tận dụng khả năng chống kiểm duyệt của chuỗi cơ bản (ví dụ: một số Rollup)

·

· Dựa vào tính trung thực của bộ trình xác nhận

Lỗi về độ sống động nói chung

Về mặt suy giảm sức sống tổng thể, chúng ta sẽ xem xét hậu quả của việc "tắt" một cây cầu. Ví dụ: đối với một cây cầu sử dụng bộ trình xác thực bên ngoài, chúng tôi có thể xem xét tính bảo mật của tiền của người dùng trong trường hợp các trình xác thực này ngoại tuyến trong một khoảng thời gian dài, có thể là vô thời hạn. Các tình huống phổ biến có thể xảy ra bao gồm:

· Kích hoạt đường dẫn chậm: chế độ mặc định là đường dẫn chậm, không mất tiền