Giải thích 20 cây cầu chuỗi chéo và 4 mô hình công nghệ chuỗi chéo

Tiêu đề gốc: "Báo cáo nghiên cứu chuỗi chéo của Paka Labs (3/4) | Kết nối các hòn đảo thành một lục địa: Giải thích 20 cây cầu chuỗi chéo và 4 mô hình công nghệ chuỗi chéo"

Bản gốc Tác giả: MIDDLE .X, Paka Labs

Báo cáo nghiên cứu chuỗi chéo của Paka Labs (1/4) xem: "Toàn cảnh về công nghệ chuỗi chéo và các hình thức ứng dụng》

Paka Labs Để biết báo cáo nghiên cứu chuỗi chéo (2/4), vui lòng xem: "BTC- tài sản cố định và làn đường nhanh xuyên lớp Ethereum 》

5.3 Kích thước phân loại của chuỗi chéo

Theo chuỗi chéo Các loại thông báo được cầu nối hỗ trợ có thể được chia thành:

· Bất kỳ cầu nối tin nhắn nào: thường được gọi là AMB, Arbitrary-Message-Briage hỗ trợ truyền xuyên chuỗi bất kỳ loại tin nhắn nào và trên cơ sở này, các chức năng phức tạp như lệnh gọi hợp đồng chuỗi chéo và tính toán chuỗi chéo có thể được thực hiện nhận ra.

· Cầu tài sản: bao gồm cầu Wrap và cầu Swap. Cái trước đề cập đến cầu lập bản đồ tài sản và hỗ trợ chuỗi chéo chuyển giao tài sản.Cái sau đề cập đến cầu nối hoán đổi thanh khoản, hỗ trợ trao đổi tài sản xuyên chuỗi.

Bất kỳ cầu nối tin nhắn nào cũng có thể được sử dụng làm nền tảng cơ bản, được trang bị cầu nối tài sản. Theo nghĩa này, cầu nối tài sản là một trong những ứng dụng được xây dựng trên bất kỳ cầu nối tin nhắn nào. Trên thực tế, sau khi LayerZero ra mắt Stargate, ngày càng nhiều dự án cầu nối AMB chọn tách cầu nối tài sản làm lớp ứng dụng thay vì xây dựng chức năng cầu nối tài sản vào đó.

Đối với cầu Wrap sẽ có thêm các phân khu theo kế hoạch lưu ký tài sản:

· Lock-Mint (bao gồm quyền giám hộ nhân chứng và quyền giám hộ theo hợp đồng)

·  Burn- Mint (không lưu trữ)

Xem hình bên dưới để biết phân loại chi tiết hơn:

Tài sản khác nhau giải pháp lưu ký, chúng tôi đã ra mắt Phần 5.1 Điều này được thảo luận đầy đủ trong phần tài sản cố định BTC.

Theo mục tiêu xây dựng cầu xuyên chuỗi, chúng ta có thể chia thành:

· Cầu nối toàn cầu: nhằm mục đích kết nối càng nhiều chuỗi càng tốt

·  Cầu chuyên dụng: dành cho các chuỗi công cộng cụ thể, tài sản cụ thể hoặc ứng dụng cụ thể cung cấp chức năng chuỗi chéo

Trong số nhiều dự án cầu chung, một số dự án cầu chung đã đề xuất một cách đầy tham vọng. Khái niệm OmniChain (chuỗi đầy đủ) hy vọng có thể kết nối hầu hết tất cả các chuỗi công cộng chính thống và thậm chí cả chuỗi liên minh. Ưu điểm của cầu thông thường là nó có thể đáp ứng nhu cầu liên kết chéo giữa nhiều chuỗi trong một điểm dừng, trong khi ưu điểm của cầu chuyên dụng nằm ở ý nghĩa xác nhận chính thức nhất định. các bên dự án chuỗi, tổ chức phát hành tài sản, Hoặc cam kết bảo mật của bên dự án ứng dụng.

Theo chuỗi công khai được kết nối bằng cầu, chúng ta có thể chia thành:

· Cầu nối chuỗi không đồng nhất: được thiết kế để kết nối các chuỗi công cộng có kiến trúc khác nhau

·  ;Cầu nối chuỗi chéo tương tự: được thiết kế để kết nối các chuỗi công cộng có cùng kiến trúc

Trong số đó, các cầu nối chuỗi chéo đẳng hình thường được bổ sung bởi một bộ chuỗi- xây dựng các giao thức để đạt được khả năng tương thích thụ động của chuỗi công khai của giao thức xây dựng chuỗi. Tuy nhiên, các dự án cầu nối chuỗi chéo hiện tại thường phải đối mặt với các chuỗi chéo không đồng nhất. Những đổi mới về chuỗi khối trong cơ chế đồng thuận và thông số kỹ thuật truyền thông là vô tận, dẫn đến sự xuất hiện liên tục của các loại chuỗi khối mới. Ý tưởng giải quyết một lần và mãi mãi là đúng, nhưng không có dự án nào sẵn sàng giới hạn mình trong một hệ sinh thái khép kín, do đó, ngay cả các dự án có chuỗi chéo đẳng hình làm cốt lõi như Polkadot và Cosmos cũng đang tích cực thúc đẩy hợp tác với các hệ sinh thái không đồng nhất khác. Cầu nối chuỗi chéo sinh thái.

Ba khía cạnh phân loại trên đều có giá trị riêng nhưng không có khía cạnh nào tập trung vào bản chất kỹ thuật của cầu nối chuỗi. Chúng tôi tin rằng khía cạnh phân loại quan trọng nhất đối với các cầu nối chuỗi chéo phải là cơ chế xây dựng lớp tin cậy. Vấn đề cốt lõi của chuỗi chéo là giải quyết: làm thế nào một chuỗi nhận thức được chuỗi khác. Cách tốt hơn để đặt câu hỏi này là: làm thế nào để cảm nhận được một chuỗi khác một cách đáng tin cậy. Không khó để truyền tin nhắn từ chuỗi này sang chuỗi khác, nhưng cốt lõi là làm thế nào để tin tưởng nó, hay nói cách khác là làm thế nào để xác minh nó!

Người gửi tin nhắn chuỗi chéo có thể là bất kỳ ai, bao gồm cả ứng dụng đã khởi tạo giao dịch chuỗi chéo hoặc chính người dùng, nhưng làm thế nào để xác minh tin nhắn, chúng ta phải có một cơ chế để đảm bảo nó đáng tin cậy.

5.4 Phân loại các phương pháp xác minh chuỗi chéo

Chúng tôi giới thiệu Khung phân tích chuỗi chéo do người sáng lập Connext Arjun Bhuptani đề xuất là một trong những thành tựu lý thuyết quan trọng nhất trong lĩnh vực nghiên cứu chuỗi chéo kể từ năm ngoái. Sau khi khuôn khổ này được đề xuất, nó nhanh chóng được nhiều bài báo liên quan đến chuỗi chéo trích dẫn.

Arjun Bhuptani chia các cầu nối chuỗi thành ba loại dựa trên các phương pháp xác minh tin nhắn, cụ thể là xác minh gốc, xác minh bên ngoài và xác minh cục bộ.

5.4.1 Xác minh gốc

Xác minh gốc đề cập đến việc triển khai chuỗi nguồn trên mục tiêu chuỗi Nút nhẹ xác minh thông báo từ chuỗi nguồn. So với các nút đầy đủ, các nút nhẹ là các nút nhẹ không lưu trữ chuỗi các khối hoàn chỉnh mà chỉ lưu trữ chuỗi các tiêu đề khối. Mặc dù tiêu đề khối nhỏ nhưng nó chứa bản tóm tắt bằng mật mã của dữ liệu hoàn chỉnh trong khối, cho phép xác minh SPV các giao dịch trong khối. Để duy trì các nút ánh sáng của chuỗi nguồn được triển khai trên chuỗi mục tiêu, Head Relayer cần chuyển tiếp tiêu đề khối của chuỗi nguồn đến chuỗi mục tiêu.

Mặc dù Head Releyer đóng vai trò không thể thiếu với vai trò ngoài chuỗi, nhưng việc xác minh gốc không có giả định về độ tin cậy đối với Relayer vì rơle ánh sáng được triển khai trên chuỗi mục tiêu Nút chương trình sẽ xác minh tiêu đề khối do Head Relayer cung cấp và Head Relayer không thể đánh lừa các nút ánh sáng.

Việc xác minh tiêu đề khối sẽ được chia thành hai phần, đó là xác minh tính hợp lệ và xác minh tính cuối cùng.

Logic xác minh tính hợp lệ của khối phụ thuộc vào cơ chế đồng thuận.

Đối với hệ thống PoW, ngoài việc xác minh định dạng cơ bản của khối, logic xác minh cốt lõi là xác minh bằng chứng công việc có trong khối:

(Hình ảnh từ Tài liệu tài chính có thể kết hợp)

Như đã trình bày ở trên, việc tìm một giá trị thỏa mãn phương trình này đòi hỏi rất nhiều tính toán vì hàm băm không thể bị ép buộc, nhưng việc xác minh bằng chứng đồng thuận này tương đối rẻ và nhanh chóng.

Trong hệ thống PoS, logic xác minh cốt lõi thường là xác minh đầu ra hàm ngẫu nhiên:

(Ảnh từ Tài liệu tài chính có thể kết hợp)

Nói cách khác: Xác minh rằng khối được tạo bởi người xác thực hợp pháp được chọn ngẫu nhiên.

Tuy nhiên, tính hợp lệ của một khối không bằng tính hữu hạn.

Trong sự đồng thuận của Satoshi Nakamoto, tính hữu hạn mang tính xác suất, vì vậy cách để xác minh tính hữu hạn là đợi các khối hợp lệ hơn sau khi khối được thêm vào. Trong BTC, người ta thường tin rằng việc bổ sung 6 khối có thể khiến một khối gần như không thể đảo ngược, mất khoảng 1 giờ. Đây là lý do tại sao hầu hết các công cụ phái sinh chuỗi chéo BTC cần đợi khoảng 1 giờ khi đúc; trong Ethereum thì đúng như vậy người ta thường tin rằng việc bổ sung 25 khối có thể khiến một khối gần như không thể đảo ngược, quá trình này mất khoảng 5 phút.

Trong cơ chế đồng thuận BFT, tính hữu hạn của một khối được xác nhận bằng cách xác minh rằng nó đã được người xác thực ký với trọng số 2/3. Do đó, cơ chế đồng thuận BFT , với kết quả cuối cùng ngay lập tức.

Cho dù đó là xác minh tính hợp lệ hay xác minh tính hữu hạn, logic xác minh tiêu đề khối của máy khách nhẹ hoàn toàn giống với logic xác minh khối của máy khách khác các loại nút giống hệt nhau. Do đó, tiêu đề khối được Head Relayer chuyển đến hợp đồng nút nhẹ hoàn toàn không thể bị giả mạo và xác minh gốc không có giả định tin cậy nào đối với Head Relayer.

5.4.2 Xác minh bên ngoài

Xác minh bên ngoài đề cập đến việc giới thiệu một bộ thông tin bên ngoài Các nhân chứng có trách nhiệm xác minh các tin nhắn xuyên chuỗi. Người dùng phải tin rằng những nhân chứng này đáng tin cậy. Có thể có một số cơ chế trong các nhân chứng để đạt được sự đồng thuận. Trình xác thực bên ngoài sẽ có nhiều dạng, bao gồm mạng MPC, mạng PoS/PoA, mạng TEE, nhóm đa chữ ký và Oracles, về cơ bản là giống nhau.

Chúng ta cần nhận ra rằng khi giới thiệu trình xác nhận bên ngoài, các giả định bảo mật mới sẽ được đưa ra. Giả sử độ bảo mật của chuỗi A là x, độ bảo mật của chuỗi B là y và độ bảo mật của bộ trình xác thực bên ngoài là z, khi đó độ bảo mật của các thông báo chuỗi chéo được truyền giữa chuỗi A và chuỗi B là s = min (x , y , z), trong hầu hết các trường hợp, z là liên kết yếu của nó, nghĩa là s = z. Đây là thiếu sót bị chỉ trích nhiều nhất của chế độ xác minh bên ngoài.

5.4.2.1 Xác minh được chia sẻ

Chúng tôi Hai trường hợp ngoại lệ đối với việc xác minh bên ngoài cần được xem xét:

Đầu tiên, trong việc xác minh xuyên biên giới do một số bên dự án chuỗi công cộng trực tiếp khởi xướng Trong một cầu nối chuỗi, bộ xác minh của chuỗi có thể trực tiếp trở thành bộ xác minh của cầu nối chuỗi. Trong trường hợp này, độ bảo mật của xác minh bên ngoài được tăng lên min(x, y), tương đương với xác minh gốc.

Các đại diện tiêu biểu của cấu trúc này là:

· Chuỗi bên BTC RootStock sử dụng tất cả các trình xác thực của riêng nó làm trình xác thực của cầu nối RootStack-BTC

· Cổng chuỗi dựa trên cơ chất được phát triển và duy trì bởi Hợp chất tái sử dụng tất cả trình xác thực Cổng làm trình xác thực của cầu nối Cổng-Ethereum;

· Gravity Bridge, cam kết kết nối hệ sinh thái Cosmos và hệ sinh thái Ethereum, sử dụng tất cả trình xác thực của Gravity Chain làm trình xác thực của Gravity Bridge.

Thứ hai, chúng tôi sẽ mở rộng tình trạng trên. Tổng hợp các bộ xác minh của chuỗi A và chuỗi B thành một liên kết, thiết lập chuỗi R chuỗi chuyển tiếp và sử dụng liên kết này làm bộ xác minh, chúng ta sẽ có được cấu trúc có thể mở rộng hơn.

Đại diện tiêu biểu của cấu trúc này là Avalanche và Polkadot. Chuỗi chuyển tiếp của Polkadot chỉ định ngẫu nhiên các trình xác thực cho từng chuỗi song song để đạt được bảo mật chung, trong khi Avalanche yêu cầu các trình xác thực của tất cả các mạng con phải trở thành thành viên của ba mạng chính chính (chuỗi P, chuỗi C và chuỗi X) cùng một lúc. để yêu cầu bảo mật từ mạng con. Polkadot đã sử dụng cấu trúc này để phát triển giao thức nhắn tin xuyên chuỗi XCMP giữa các chuỗi song song, nhưng Aclanche dường như không sử dụng cấu trúc này để thực hiện truyền tin nhắn xuyên chuỗi.

Hai trường hợp ngoại lệ này vẫn là hình thức xác minh bên ngoài, nhưng đặc điểm cốt lõi và các kịch bản áp dụng của chúng đã trải qua những thay đổi đáng kể. Trong bài viết sau, chúng ta sẽ so sánh đặc điểm của các cơ chế xác minh khác nhau. , xác thực bên ngoài được đề cập sẽ không bao gồm hai ngoại lệ này. Đi xa hơn, chúng tôi tin rằng nó nên được đặt tên là một loại mới và được gọi là "xác minh được chia sẻ".

5.4.3 Xác minh cục bộ

Xác minh cục bộ còn được gọi là xác minh điểm-điểm , đề cập đến Đối tác xác minh giao dịch trực tiếp. Một mô hình điển hình là trao đổi nguyên tử dựa trên khóa thời gian băm. Trong một giao dịch như vậy, cả hai bên tham gia giao dịch đều xác minh rằng bên kia đã hoàn thành một hành vi nhất định. Vì lợi ích kinh tế của hai bên đối lập nên không có khả năng thông đồng. Trong hầu hết các thiết kế dự án chuỗi chéo sử dụng các phương pháp xác minh cục bộ, để tránh yêu cầu cả hai bên giao dịch phải trực tuyến cùng lúc, cần có một nhà cung cấp thanh khoản trung gian làm đối tác công khai.

5.4.4 Tam giác bất khả thi về khả năng tương tác chuỗi chéo

Trong số ba phương pháp xác minh , Giả định độ tin cậy của xác minh gốc là nhỏ nhất. Về lý thuyết, miễn là chuỗi nguồn và chuỗi mục tiêu không tổ chức lại thì nhắn tin xuyên chuỗi là an toàn, nhưng chi phí thích ứng đa chuỗi của xác minh gốc là cao nhất. Giải pháp nút nhẹ của hầu hết mọi chuỗi phải được thiết kế riêng biệt và phải được tối ưu hóa theo những hạn chế nhất định của môi trường triển khai (tức là tình huống của chuỗi mục tiêu) nếu bạn triển khai hợp đồng nút nhẹ của chuỗi B trên chuỗi A, nó sẽ chỉ triển khai Thông báo một chiều truyền từ BA. Nếu bạn muốn triển khai cầu nối hai chiều, bạn cũng cần triển khai hợp đồng nút nhẹ của chuỗi A trên chuỗi B. Hai nhiệm vụ này hoàn toàn độc lập và có không có khả năng tái sử dụng. Nếu bạn muốn thích ứng với nhiều chuỗi hơn, bạn sẽ phải trả nhiều chi phí hơn, mỗi khi kết nối với một chuỗi mới, bạn cần phát triển một cặp hợp đồng nút nhẹ. Do đó, chúng tôi thấy rằng hầu hết các dự án cầu nối chuỗi chéo sử dụng cơ chế xác minh gốc đều là cầu nối chuỗi chéo chuyên dụng và cầu nối chuỗi chéo đồng nhất, trong khi cầu nối chung không đồng nhất hiếm khi được sử dụng.

Ưu điểm và nhược điểm của xác minh bên ngoài hoàn toàn trái ngược với xác minh gốc. Chi phí thích ứng đa chuỗi của xác minh bên ngoài thấp hơn. Nhược điểm của nó là đưa ra giả định tin cậy mới. Giả định Trình xác thực bên ngoài đạt được sự đồng thuận thông qua cơ chế bỏ phiếu m-of-n. Số lượng trình xác thực mà chúng tôi cần thông đồng với nhau một cách ác ý không thể vượt quá n-m. Nếu chúng tôi muốn hạ thấp giả định về độ tin cậy, chúng tôi cần những người xác nhận cam kết, điều này sẽ làm tăng chi phí chuỗi chéo.

Mặc dù xác minh cục bộ có ưu điểm kép là không cần giả định về độ tin cậy và dễ dàng thích ứng với nhiều chuỗi, nhưng phạm vi áp dụng của nó tương đối hẹp và chỉ có thể hỗ trợ cầu nối Swap chứ không thể hỗ trợ hỗ trợ cầu Wrap., chứ đừng nói đến cầu AMB.

Trong bài viết của mình, Arjun Bhuptani đã đề xuất tam giác bất khả thi nổi tiếng về khả năng tương tác xuyên chuỗi (The Interoperability Trilemma), tức là

Bất kỳ thiết kế giải pháp chuỗi chéo nào cũng chỉ có thể đáp ứng tối đa hai trong số ba điều sau:

· Có thể mở rộng: hỗ trợ mọi cách gửi tin nhắn

· Không cần sự tin cậy ( Trustless): không giới thiệu các giả định tin cậy mới

·  Có thể khái quát hóa: có thể dễ dàng thích ứng với nhiều Blockchain hơn

Nó có thể Có thể nói rằng các dự án cầu nối chuỗi khác nhau đang cố gắng tối ưu hóa hoặc thậm chí phá vỡ tam giác bất khả thi từ các góc độ khác nhau, cố gắng đạt được hiệu suất tổng thể cao nhất.

5.4.5 Xác minh lạc quan

Xác minh lạc quan nói chung là Nó được coi là sự tối ưu hóa của sơ đồ xác minh bên ngoài, nhưng do những thay đổi rõ ràng trong các giả định về độ tin cậy của nó, chúng tôi tin rằng nó nên được khám phá như một sơ đồ xác minh độc lập. Logic cơ bản của xác minh lạc quan là: trên cơ sở xác minh bên ngoài, thiết lập một nhóm người thách thức và khoảng thời gian thử thách để thách thức việc xác minh không chính xác. Người xác minh cần phải đóng góp. Khi hành xử không phù hợp, người thách thức sẽ thách thức. Và cung cấp bằng chứng của gian lận. Nếu thử thách thành công, tiền đặt cược của người xác nhận sẽ trở thành tiền thưởng của người thách thức.

Ứng dụng nổi tiếng của xác minh lạc quan là Optimistic Rollop, nhưng khi xác minh lạc quan được sử dụng cho chuỗi chéo ngang hàng và Op Rollup, tình huống sẽ xảy ra là hoàn toàn khác.khác. Trước hết, phải làm rõ rằng xác minh lạc quan không phải là cơ chế xác minh có thể được sử dụng một mình, vì vậy điều kiện tiên quyết để sử dụng bằng chứng gian lận là phải có cơ chế xác minh bằng chứng gian lận. Điều này có nghĩa là chúng ta phải có một nguồn "sự thật" đáng tin cậy. Thiết bị đầu cuối sự thật này đảm nhận chức năng phán xét cuối cùng.

Trong chuỗi chéo ngang hàng, sự thật nằm ở chuỗi nguồn và việc chuyển đổi trạng thái không chính xác có thể dễ dàng xung đột với "Câu trả lời đúng" được so sánh để xác minh bằng chứng gian lận. Op Rollups phức tạp hơn thế này, Rollup yêu cầu L2 kế thừa tính bảo mật của L1 nên sự thật trên L1 chỉ có thể dùng làm cơ sở cho quyết định cuối cùng. Tuy nhiên, nghịch lý là L1 không tự nhiên giữ lại thông tin chuyển trạng thái trên L2. Mọi thông tin từ L2 Thông tin gửi lên L1 đều phải trải qua quá trình chứng nhận khắt khe nên cần một thời gian đủ dài để những người bất đồng chính kiến có thể tham gia đầy đủ vào trò chơi.Hầu hết Op Rollups đều đặt thời gian này là 7 ngày trở lên.

Trong chuỗi chéo ngang hàng, việc xác minh lạc quan không cần kéo dài quá 7 ngày mà chỉ cần một khoảng thời gian đủ để người thách thức phản ứng. đến 30 phút. . Giả định về độ tin cậy của việc xác minh lạc quan là ít nhất một người thách thức trung thực và sẽ có động cơ tài chính để thực hiện nhiệm vụ của mình một cách trung thực. Đây là giả định về độ tin cậy nhỏ hơn so với xác minh bên ngoài.Theo giả định về độ tin cậy như vậy, cho dù kẻ tấn công có phải trả bao nhiêu chi phí kinh tế thì cũng không có gì đảm bảo rằng cuộc tấn công sẽ thành công.

So với xác minh bên ngoài, xác minh lạc quan sử dụng độ trễ hàng chục phút để đổi lấy các giả định tin cậy thoải mái. Cơ chế xác minh lạc quan cũng có thể được tích hợp vào xác minh gốc để giúp các máy khách nhẹ xác minh tiêu đề khối. Về các đặc điểm khác của xác minh lạc quan, chúng tôi sẽ giải thích chi tiết với các trường hợp sau.

5.5 Dự án Cầu xác minh gốc

5.5.1 Tổng quan về hợp đồng Light Node

Native Thành phần quan trọng nhất trong cầu xác minh là hợp đồng nút nhẹ. Để hiểu rõ hơn về cầu xác minh gốc, trước tiên chúng ta cần có hiểu biết cơ bản về hợp đồng nút nhẹ.

Các hợp đồng nút nhẹ, chúng ta cũng có thể gọi chúng là khách hàng nhẹ, phát sinh từ nỗ lực của mọi người nhằm cải thiện tính phân cấp của chuỗi khối. Dữ liệu chuỗi khối sẽ tiếp tục tích lũy, khiến kích thước của các nút đầy đủ tiếp tục tăng, điều này sẽ khiến ngưỡng thiết bị và ngưỡng chi phí để chạy các nút đầy đủ tiếp tục tăng, do đó sẽ loại bỏ người dùng thông thường và chỉ còn lại một số ít người dùng tổ chức. các nút thách thức tinh thần phân tán của blockchain.

5.5.1.1 Nút đèn SPV

Bitcoin là blockchain đầu tiên đối mặt với thách thức này, vì vậy Satoshi Nakamoto đã đề xuất khái niệm SPV (Xác minh thanh toán đơn giản). Các nút ánh sáng SPV không lưu trữ tất cả dữ liệu khối mà chỉ lưu trữ tiêu đề khối. Mặc dù nút ánh sáng SPV không có dữ liệu giao dịch trong thân khối, nhưng khi cần biết liệu một giao dịch có được đưa vào chuỗi hay không, nó có thể lấy đường dẫn Merkle của giao dịch từ nút đầy đủ, sau đó sử dụng Giao dịch gốc trong tiêu đề khối cho Giao dịch phải trải qua xác minh SPV.

(hình vuông màu xanh Bộ sưu tập là đường đi Merkel của hình vuông màu đen)

5.5.1.2 Nút Flyclient Super Light

Các nút siêu nhẹ là các nút nhẹ hơn các nút SPV. Các nút siêu nhẹ thường có thể đạt được sự đồng bộ hóa giống như bước nhảy của các tiêu đề khối mới hoặc cắt tỉa liên tục các tiêu đề khối cũ. Chúng tôi đã đề cập đến giải pháp nút siêu nhẹ trong bài viết đầu tiên của loạt bài này: nút siêu nhẹ MMR. Ở đây, chúng ta cần sửa lại: tên chính xác hơn cho các nút siêu nhẹ MMR nên được gọi là nút siêu nhẹ Flyclient. MMR là một cấu trúc cam kết do Flyclient đề xuất.

Flyclient là một giải pháp node siêu nhẹ cho PoW được đề xuất vào năm 2019. Giải pháp này triển khai cấu trúc chứng minh "một phương tiện cho tất cả" thông qua MMR, tạo ra tiêu đề khối mới nhất có thể chứa các cam kết của tất cả các tiêu đề khối lịch sử. Đồng thời, Flyclient sử dụng một bộ thuật toán kiểm tra điểm xác suất để xác minh tính hữu hạn của các tiêu đề khối mà không có lịch sử của các tiêu đề khối. Thật không may, Flyclient không phù hợp với các kịch bản chuỗi chéo và cho đến nay, không có ví dụ nào về việc áp dụng Flyclient vào việc xây dựng cầu chuỗi chéo.

Có hai lý do:

1.Flyclient The Cấu trúc cam kết MMR cho phép các light node chỉ giữ lại các tiêu đề khối mới nhất và liên tục lược bỏ các tiêu đề khối cũ.Mặc dù nó có thể giữ cho light client trên chuỗi nhỏ hơn nhưng vẫn tốn rất nhiều Gas để liên tục đồng bộ hóa các tiêu đề khối mới nhất. trên chuỗi, điều tốt nhất cần làm là đồng bộ hóa các tiêu đề khối ít nhất có thể, chẳng hạn như nhảy tiêu đề khối đồng bộ hóa hoặc thậm chí đồng bộ hóa các tiêu đề khối theo yêu cầu;

2.Thuật toán kiểm tra tại chỗ của Flyclient tương đối phức tạp, điều này không là gì đối với CPU cục bộ, nhưng đối với một môi trường có nguồn tài nguyên máy tính khan hiếm trên chuỗi thì nó có vẻ quá xa xỉ và không khả thi về mặt kinh tế. Máy khách nhẹ trên chuỗi phải tiết kiệm chi phí xác minh tiêu đề khối càng nhiều càng tốt.

Đối với các cầu nối xác minh gốc, hiệu suất của hợp đồng nút nhẹ sẽ trực tiếp xác định hiệu suất của cầu nối chuỗi chéo. Trong ví dụ về dự án cầu nối chuỗi chéo của phần này, chúng tôi sẽ đặc biệt chú ý đến phương pháp xây dựng hợp đồng nút nhẹ của dự án.

5.5.2 BTC Relay

BTC-Relay là hợp đồng light node sớm nhất và cũng Cầu nối chuỗi chéo xác minh bản địa sớm nhất. Nguyên tắc hoạt động của nó rất đơn giản, đó là triển khai light node BTC SPV trên Ethereum để thực hiện xác minh SPV các giao dịch trên chuỗi BTC.

(Ảnh từ trang web chính thức của BTC Relay)

Vai trò ngoài chuỗi "Relayer" "Chịu trách nhiệm liên tục chuyển tiêu đề khối của chuỗi BTC tới hợp đồng nút nhẹ. Hợp đồng nút nhẹ sẽ chính thức chấp nhận tiêu đề khối sau khi xác minh tính hợp lệ và tính hữu hạn của nó. Việc xác minh tính hợp lệ của tiêu đề khối dựa trên xác minh bằng chứng công việc, trong khi xác minh tính cuối cùng là chờ hơn 6 khối hợp lệ được thêm vào tiêu đề khối. Như chúng tôi đã nói trước đây, quá trình này không yêu cầu các giả định về độ tin cậy.

Relayer sẽ trả phí Gas cho Ethereum để lưu trữ và xác minh các tiêu đề khối. Đồng thời, Relayer nhận được phí như một khoản bồi thường từ những người dùng thực hiện các yêu cầu xuyên chuỗi. và thu được lợi nhuận phù hợp. Bất kỳ ai cũng có thể trở thành Relayer và đặt ra tiêu chuẩn tính phí cho mỗi cuộc gọi. Nếu người khác muốn trở thành Relayer, họ có thể trả một khoản phí nhỏ cho Relayer hiện tại và đặt tiêu chuẩn tính phí thấp hơn. Nếu người dùng lo lắng về việc bị tính phí quá nhiều , Cao, bạn cũng có thể tự mình chạy dịch vụ Relayer.

Cần lưu ý BTC Relay là cầu nối một chiều, chỉ hỗ trợ xác minh thông tin BTC trên Ethereum và không hỗ trợ xác minh thông tin theo chiều ngược lại. Do đó, BTC Relay không phát hành tài sản phái sinh chuỗi chéo của BTC và trường hợp sử dụng của nó chỉ giới hạn trong việc hỗ trợ người dùng sử dụng Bitcoin để thanh toán phí trên Ethereum.

Tất nhiên, BTC Relay có thể được sử dụng làm khối xây dựng và lớp tin cậy một chiều để cung cấp xác minh giao dịch theo hướng BTC và Ethereum cho các BTC khác các dẫn xuất chuỗi chéo.

Trang web chính thức của BTC Relay 

Tài liệu chuyển tiếp BTC

5.5.3 Cầu Waterloo

Cầu WaterLoo là cầu xuyên chuỗi được phát triển bởi Kyber Network Bridge cũng là cầu nối chuỗi chéo đầu tiên triển khai xác minh gốc hai chiều, triển khai chuỗi chéo hai chiều giữa Ethereum và EOS. Mặc dù WaterLoo Bridge ít nhận được sự chú ý do sự suy giảm của EOS nhưng giải pháp kỹ thuật của nó vẫn mang tính đại diện.

Waterloo Bridge triển khai ứng dụng khách nhẹ EOS thông qua hợp đồng thông minh Ethereum và cũng triển khai ứng dụng khách nhẹ Ethereum thông qua hợp đồng thông minh EOS.

Vì các khối Ethereum tương đối chậm và tài nguyên tính toán và lưu trữ trên EOS tương đối đầy đủ nên hợp đồng nút nhẹ Ethereum do WaterLoo thiết lập trên EOS là nút nhẹ SPV, phù hợp với nguyên tắc Chuyển tiếp BTC, sẽ đồng bộ hóa từng tiêu đề khối Ethereum với các hợp đồng nút nhẹ.

Tuy nhiên, các khối EOS được sản xuất rất nhanh và tài nguyên trên Ethereum rất eo hẹp, do đó hợp đồng nút nhẹ EOS trên Ethereum được thiết kế để chỉ đồng bộ hóa bộ BP. Có những khối bị thay đổi mà không đồng bộ hóa từng khối một và liên tục. Nhưng thiết kế như vậy cần phải giải quyết hai vấn đề:

1. Cách xác minh tiêu đề khối lịch sử: khi giao dịch được xác minh không còn được lưu trữ Khi nhập một khối, hợp đồng nút nhẹ trước tiên cần lấy tiêu đề khối tương ứng từ nút đầy đủ. Nhưng ở đây vẫn cần có một quy trình xác minh. Hợp đồng nút nhẹ xác minh các tiêu đề khối thu được này bằng cách nào?

2. Cách xác minh tiêu đề khối mới nhất: Cách xác minh tiêu đề khối được đồng bộ hóa mới nhất mà không cần nắm vững toàn bộ lịch sử của khối tiêu đề cuối cùng?

Cách xác minh các tiêu đề khối lịch sử

Nhẹ Hợp đồng nút cần có khả năng xác minh tiêu đề khối thu được từ nút đầy đủ dựa trên tiêu đề khối được lưu trữ. làm như thế nào? Chúng ta cần hiểu rằng giao thức đồng thuận của EOS là DPoS. Người đặt cược của $EOS bầu chọn 21 BP (Nhà sản xuất khối) thông qua bỏ phiếu. 21 BP này thay phiên nhau tạo các khối theo cách tuần hoàn. Mỗi khối được tạo ra sẽ được xử lý bởi 21 BP .. Chữ ký, khối được ký bởi hơn 15 BP được coi là cuối cùng và những chữ ký này sẽ được phản ánh trong tiêu đề khối. Mặc dù EOS tạo ra các khối nhanh hơn nhưng bộ BP không thay đổi thường xuyên, miễn là light client có danh sách các bộ BP (danh sách khóa công khai), nó có thể xác minh tất cả các tiêu đề khối trong thời hạn của bộ BP. Nói cách khác, nếu tiêu đề khối thu được từ nút đầy đủ đã được 15 BP ký trong điều khoản tương ứng thì nó sẽ được hợp đồng khách hàng nhẹ chấp nhận.

Cách xác minh tiêu đề khối mới nhất

Bởi vì cuộc bỏ phiếu bầu cử cho bộ BP diễn ra trên chuỗi và kết quả bỏ phiếu sẽ được phản ánh trong tiêu đề khối của một khối nhất định Khối{i}. Tiêu đề khối của Khối{i} sẽ phản ánh danh sách bộ BP và các điều khoản của họ. Khi Khối{i} và bộ BP mới chứa trong nó được tạo, bộ BP mới vẫn chưa có hiệu lực và Khối{i} sẽ được ký bởi bộ BP cũ. Nói một cách đơn giản, chúng ta cũng có thể hiểu rằng bộ BP cũ đã phê duyệt bộ BP mới bằng cách ký một khối chứa kết quả bầu cử của bộ BP mới. Miễn là máy khách hạng nhẹ nắm bắt chính xác bộ BP ban đầu và nắm bắt các khối nơi bộ BP thay đổi mỗi lần, thông qua "chuỗi mối quan hệ phê duyệt" như vậy, nó có thể được truy nguyên từ đầu đến cuối. bộ BP mới nhất. . Bằng cách nắm vững bộ BP mới nhất, bạn có thể xác minh khối mới nhất.

Chúng tôi nhận thấy rằng có một giả định bảo mật ở đây, đó là máy khách hạng nhẹ cần nắm bắt chính xác tập BP ban đầu. Nếu điều kiện này không được đáp ứng, hợp đồng nút nhẹ sẽ Không hoạt động bình thường. Nhưng đối với những người triển khai hợp đồng nút nhẹ, điều này có thể được thực hiện dễ dàng.

Vì vậy, điều chúng tôi có thể làm rõ là khi có một thông báo trên EOS cần được chuyển qua chuỗi tới Ethereum, Waterloo Bridge sẽ:

1. Kiểm tra xem tiêu đề khối của khối chứa thông báo đã tồn tại trong light client chưa. Nếu nó không tồn tại, hãy tiếp tục các bước. Nếu nó tồn tại , hãy tiến hành các bước;

2. Relayer lấy tiêu đề khối của khối nơi đặt thông báo từ nút đầy đủ và gửi nó đến ứng dụng khách nhẹ. Máy khách nhẹ xác minh tiêu đề khối dựa trên bộ BP mới nhất mà nó có. Nói cách khác, máy khách nhẹ Xác định xem tiêu đề khối có hợp lệ hay không bằng cách kiểm tra xem nó có được ký bởi hơn 2/3 bộ BP hay không;

3. Sử dụng tiêu đề khối đã được xác minh để xác minh thông báo Thực hiện xác minh SPV.

Cơ chế đồng thuận của EOS thuộc cơ chế đồng thuận loại BFT và phương thức triển khai client nhẹ của EOS đã trở thành mô hình điển hình của chuỗi công khai loại BFT khách hàng nhẹ nhàng.

Giới thiệu về cầu WaterLoo (Phần 1)

Giới thiệu về cầu WaterLoo (Phần 2)

5.5.4 Rainbow Bridge

Cầu Rainbow là cầu xuyên chuỗi chính thức được Near phát triển để kết nối hệ sinh thái Near và hệ sinh thái Ethereum. Tài liệu của Rainbow bridge đề cập: Người thiết kế chính của cầu Rainbow là Anton Bukov, hiện là CTO của 1inch, tuy không còn làm việc toàn thời gian tại Near nhưng ông vẫn hướng dẫn phát triển cầu Rainbow.

Cấu trúc và nguyên tắc

Các thành phần cốt lõi của Rainbow Bridge là Hai hợp đồng trên chuỗi và ba đại lý ngoài chuỗi:

Hợp đồng trên chuỗi:

· EthOnNearClient: Nút ánh sáng Ethereum được triển khai dưới dạng hợp đồng Near trong Rust

·  ; NearOnEthClient: Near light node được triển khai dưới dạng hợp đồng Ethereum trong Solidity

Proxy ngoài chuỗi:

· Eth2NearRelay: Chịu trách nhiệm chuyển tiêu đề khối Ethereum tới EthOnNearClient

·  ;Near2EthRelay : Chịu trách nhiệm chuyển các tiêu đề khối Gần tới NearOnEthClient

· Watchdog: Chịu trách nhiệm thách thức Near2EthRelay gửi các tiêu đề khối không hợp lệ , thông tin chi tiết sau

EthOnNearClient cần theo dõi mọi tiêu đề khối trên Ethereum, NearOnEthClient chỉ cần theo dõi một tiêu đề khối cho mỗi Epoch và một Epoch là khoảng 43.000 khối, khoảng 4 giờ . Sẽ không thực tế nếu đồng bộ hóa tất cả chúng. May mắn thay, bộ trình xác thực của Near sẽ chỉ thay đổi một lần trong mỗi Kỷ nguyên và mỗi Kỷ nguyên sẽ chỉ có một tiêu đề khối chứa thông tin lựa chọn bộ trình xác thực. Thiết kế của NearOnEthClient dựa chủ yếu vào EosOnEthClient trong WaterLoo Bridge và thậm chí sử dụng lại một phần mã của WaterLoo Bridge.

Nhưng đối với NearOnEthClient vẫn còn một vấn đề kỹ thuật, đó là Ethereum không tương thích với định dạng chữ ký Ed25519 mà Near sử dụng, điều này khiến cho NearOnEthClient phải xác minh Near chặn tiêu đề Nó trở nên rất rắc rối. Vì vậy, Rainbow Bridge giới thiệu một sơ đồ xác minh lạc quan.

Khi Near2EthRelay gửi tiêu đề khối cho NearOnEthClient, nó cần thế chấp một số $NEAR trên chuỗi Near. Trong thời gian 4 giờ, nó được gọi là Watchdog thách thức. Cơ quan giám sát có thể đưa ra thách thức. Nếu tất cả các Cơ quan giám sát không đưa ra thách thức, tiêu đề khối sẽ được NearOnEthClient chính thức chấp nhận vào cuối giai đoạn cửa sổ. Nếu Cơ quan giám sát đưa ra thử thách và thử thách thành công, Near2EthRelay đã gửi tiêu đề khối không hợp lệ sẽ phải trả giá tài chính, một nửa số tài sản thế chấp của nó sẽ bị phá hủy và nửa còn lại sẽ trở thành tiền thưởng của Cơ quan giám sát đã đưa ra thử thách .

p>

Việc đưa ra phương pháp xác minh lạc quan mang đến một giả định mới về độ tin cậy: ít nhất một Cơ quan giám sát trung thành.

Trong BTC Relay, chỉ có một Relayer chạy cùng lúc, nhưng trong Rainbow Bridge, cả Eth2NearRelay và Near2EthRelay đều cho phép nhiều Relayer chạy cùng một lúc. Nhiều Người chuyển tiếp có thể cạnh tranh với nhau và cố gắng gửi cùng một khối cùng một lúc. Mỗi lần chỉ có một người thành công. Nhiều Người chuyển tiếp cũng có thể tạo bản sao lưu cho nhau. Nếu một Người chuyển tiếp không gửi một khối kịp thời, những Người chuyển tiếp khác vẫn sẽ gửi gửi nó, điều này làm giảm khả năng không có sẵn dịch vụ.

Các ưu đãi

Hiện tại Rainbow Bridge không có đã Cung cấp các ưu đãi kinh tế cho hai bộ dịch vụ Chuyển tiếp chuyển tiếp tiêu đề khối, vì Near kỳ vọng rằng các ứng dụng chính chạy trên Rainbow Bridge (ví dụ: $ETH Asset Bridge, $NEAR Asset Bridge, ERC20 Asset Bridge, NFT Bridge) sẽ chạy Relay các dịch vụ của riêng mình và ít nhất một cặp dịch vụ Relay được Near điều hành chính thức. Các phiên bản tương lai của Rainbow Bridge có thể tăng cường khuyến khích kinh tế cho các dịch vụ Relay và tăng cơ chế tính phí tương ứng cho người dùng/ứng dụng xuyên chuỗi.

Phát triển mới nhất

Sắp phát hành Tương thích với EVM Với môi trường Aurora, hiện tại Rainbow Bridge 2.0 hỗ trợ cross-chain giữa Ethereum và Aurora, nếu bạn cần cross-chain từ Ethereum đến Near thì cần phải thông qua Aurora transfer. Cần lưu ý rằng mặc dù Aurora duy trì một sổ cái độc lập và có trình duyệt blockchain độc lập, nhưng nó không phải là một blockchain độc lập mà là thời gian chạy trên Near. -chain bridge, nhưng là cầu nối giữa các thời gian chạy.

Chúng ta cũng cần lưu ý rằng tại thời điểm viết bài này, Ethereum vừa hoàn thành quá trình chuyển đổi PoS của mình. Do đó, các ứng dụng khách nhẹ Ethereum được thiết kế cho phiên bản PoW trong Rainbow Bridge và WaterLoo Bridge có thể được thiết kế lại trong tương lai gần.

Tài liệu gần giới thiệu

5.5.5 Snowbridge (Snowfork)

SnowBridge là bản chất chính thức của Polkadot The Cross - Dự án cầu chuỗi, được phát triển bởi nhóm Snowfork, nhằm mục đích tạo ra một cầu nối xác minh nguyên gốc giữa hệ sinh thái Polkadot và Ethereum.

Snowbridge là một dự án vẫn đang được phát triển và kiến thức của chúng tôi về dự án này bắt nguồn từ tài liệu hiện tại của SnowBridge, dường như vẫn chưa hoàn thành, với một số chỗ vẫn đang "đang chuẩn bị viết" sớm thôi", chúng tôi chỉ có thể phân tích cầu tuyết dựa trên các vật liệu hiện có.

Snowbridge sẽ có parachain riêng, hoạt động như một parachain phúc lợi công cộng trong tương lai, được gọi là SnowBridge Parachain, và parachain này sẽ chịu trách nhiệm thiết lập một cầu nối với Ethereum, các parachain khác sẽ được kết nối gián tiếp với Ethereum thông qua SnowBridge Parachain và XCMP. Điều này có nghĩa là Light node Pallet của Ethereum sẽ được chạy trên SnowBridge Parachain.

* Không có khái niệm về hợp đồng trong Substrate. Các nhà phát triển triển khai ứng dụng vào chuỗi bằng cách thêm Pallet, nhưng bản chất của chúng giống như hợp đồng và tất cả chúng đều là trên chuỗi.thời gian chạy.  

Snowbridge sẽ bao gồm các mô-đun sau

Các hợp đồng được triển khai trên Ethereum:

· Polkadot RPC: được sử dụng để xử lý các yêu cầu chuỗi chéo trên Ethereum

· POLKADOT VÀ PARACHAIN XÁC MINH KHÁCH HÀNG LIGHT

Pallet được triển khai trên Snowbridge Parachain:

· ETHEREUM RPC Được sử dụng để xử lý các yêu cầu chuỗi chéo trên Polkadot

· Trình xác minh ứng dụng khách ETHEREUM LIGHT

Ứng dụng khách Ethereum Light trên Snowbridge Parachain

Theo tài liệu hiện tại của Snowbridge (2022.10.14), ứng dụng khách nhẹ Ethereum được thiết kế dưới dạng nút nhẹ SPV. Relayer sẽ chịu trách nhiệm đồng bộ hóa từng block header của Ethereum, Light client Pallet sẽ kiểm tra bằng chứng công việc và đi theo fork nặng nhất. Nhưng để thích ứng với Ethereum sau khi chuyển đổi sang PoS, Snowbridge cần có những giải pháp mới.

Ứng dụng khách Polkadot nhẹ trên Ethereum

Nó cần lưu ý rằng do chuỗi chuyển tiếp chịu trách nhiệm về sự đồng thuận của SnowBridge Parachain nên ứng dụng khách nhẹ sẽ đồng bộ hóa tiêu đề khối của chuỗi chuyển tiếp thay vì tiêu đề khối của SnowBridge Parachain. Để theo dõi thông tin bộ trình xác thực mới nhất, tiêu đề khối chứa việc lựa chọn lại bộ trình xác thực phải được đồng bộ hóa, điều đó có nghĩa là ít nhất một tiêu đề khối cần được đồng bộ hóa mỗi Kỷ nguyên. Khi có một giao dịch cần được xác minh, tiêu đề khối SnowBridge Parachain sẽ được yêu cầu từ chuỗi chuyển tiếp nếu cần và tính hữu hạn của nó được xác minh bằng cách sử dụng tiêu đề khối chuỗi chuyển tiếp chứa nó.

So với WaterLoo, Snowfork phải đối mặt với một vấn đề mới: EOS chỉ có 21 trình xác nhận, nhưng Polkadot có khoảng 1.000 trình xác nhận, thậm chí có tới 2/3 những người xác thực đã ký một khối và mức tiêu thụ gas khi xác minh hơn 600 chữ ký trong Ethereum cũng rất cao. Rainbow Bridge khắc phục vấn đề này thông qua xác thực lạc quan, trong khi Snowfork chọn cách đối mặt trực tiếp với nó. Giải pháp của Snowbridge là áp dụng cơ chế lấy mẫu: khi lấy block header, light client chọn ngẫu nhiên một tập hợp con từ tập hợp các validator tương ứng với block header. Light client sẽ chỉ xác minh chữ ký của tập hợp con này mà không cần phải xác minh tất cả' chữ ký của. Theo nghiên cứu của Snowfork, số lượng trình xác thực trong tập hợp con này chỉ cần là ceil(log2(3*N)) (N là tổng số lần xác thực). Nếu N là 1000 thì chỉ cần trích xuất 12 chữ ký xác thực.

BEFY

Polkadot tốt hơn Nó hỗ trợ kết nối với các chuỗi công khai khác.Dựa trên sự đồng thuận của GRANDPA, một tiện ích cuối cùng có tên BEEFY đã được phát triển (tại thời điểm viết bài này, mã của BEEFY vẫn đang được cải tiến). Sau khi GRANDPA chấm dứt chuỗi chuyển tiếp Polkadot sẽ có liên kết chữ ký đồng thuận BEEFY. Trong liên kết này, người xác thực cần thêm quyền root MMR vào tiêu đề khối, sau đó tiến hành một vòng chữ ký đồng thuận riêng trên khối tiêu đề.

Với BEEFY, khách hàng đơn giản sẽ không cần hiểu sự phức tạp của GRANDPA mà chỉ cần xác minh chữ ký BEEFY. Điều quan trọng nhất là định dạng chữ ký BEEFY hoàn toàn tương thích với Ethereum, giúp việc xác minh từ phía Ethereum trở nên dễ dàng.

Khuyến khích

SnowBridge được chia thành hai Nó được phát hành thành hai giai đoạn. Giai đoạn đầu tiên là Cầu cơ bản. Giai đoạn này đã có các chức năng cơ bản của một cầu nối chuỗi chéo, nhưng không có lớp khuyến khích. Không có ưu đãi cho Head Relayer và Message Relayer. Nếu người dùng/ứng dụng muốn đảm bảo rằng tin nhắn của họ được chuyển tiếp thành công, họ cần phải tự chạy dịch vụ Relayer. Giai đoạn thứ hai sẽ chuyển sang Cầu khuyến khích, sẽ thiết lập các ưu đãi cho Người chuyển tiếp.

Lớp ứng dụng

Trong nhóm Snowfork Theo kế hoạch, sau khi SnowBridge lên mạng, ba cầu nối tài sản sẽ sớm được phát hành, cụ thể là

· DOT Asset Bridge: Hỗ trợ việc tạo ra snowDOT trên Ethereum

· ETH Asset Bridge: Hỗ trợ việc tạo ra snowETH ở phía Polkadot

· ERC20 Asset Bridge: Hỗ trợ tạo các phiên bản ánh xạ của nội dung ERC20 ở phía Polkadot. Định dạng đặt tên là: snow-[asset tên].

Tài liệu về Snowbridge

5.5.6 LCMP (Darwinia)

LCMP (Giao thức nhắn tin chuỗi chéo máy khách nhẹ) là Giao thức chuỗi chéo không đồng nhất do Darwinia phát triển là một giao thức truyền tải chuỗi chéo phổ biến và mở dựa trên giải pháp máy khách nhẹ. Giao thức hiện ở dạng SDK, cho phép Dapp được tích hợp tự do.

Trong cấu trúc sinh thái chuỗi chéo do Darwinia xây dựng có hai chuỗi là Chuỗi Darwinia và Darwinia Parachain. Darwinia Parachain là chuỗi song song của Polkadot, và cả hai có Canary Network, Crab Chain, Crab Parachain tương ứng, trong đó Crab Parachain là parachain của Kusama.

Darwinia Chain được triển khai với môi trường tương thích với EVM có tên là Darwinia Smart Chain. Nó được gọi là Chain vì Darwinia Smart Chain có một máy và trình duyệt trạng thái độc lập, nhưng nó không phải là một độc lập chuỗi khối. (Xem mối quan hệ giữa Aurora và Near)

Tương ứng, có một môi trường tương thích EVM trên Crab Chain, được gọi là Crab Smart Chain.

5.5.6.1 Thiết kế máy khách nhẹ

Vào thời điểm viết bài này, LCMP đã được triển khai

· Cầu nối giữa Darwinia Chain và Ethereum

· Cầu nối giữa Crab Chain và Crab Parachain

Trong số đó, Crab Parachain sử dụng Giải pháp ứng dụng khách nhẹ cũng giống như Waterloo. Chúng tôi tập trung vào tập hợp các ứng dụng khách nhẹ được sử dụng để kết nối Chuỗi Darwinia và Ethereum.

Darwinia Chain Client trên Eth

Hạn chót đến Beefy vẫn chưa có sẵn và chữ ký tiêu đề khối dựa trên Chuỗi Darwinia do Substrate phát triển không tương thích với Ethereum. Darwinia hiện đang áp dụng kế hoạch chuyển tiếp và bầu ra một nhóm người ký thông qua sự quản lý của quốc hội, nhóm này chịu trách nhiệm ký tên khối của Chuỗi Darwinia. Light client sẽ xác minh xem tiêu đề khối có hợp pháp hay không bằng cách xác minh chữ ký của nhóm. Mặc dù có hơn 100 người xác thực trên Chuỗi Darwinia, nhưng nhóm người ký không vượt quá 10 người và chi phí kinh tế về phía Ethereum để xác minh những chữ ký này là có thể chấp nhận được.

Khách hàng Eth trên Chuỗi Darwinia 

Chuỗi đèn hiệu Ethereum được hợp nhất, dưới dạng chuỗi PoS, có hàng trăm nghìn trình xác thực và việc xác minh chữ ký của họ rõ ràng là không thực tế. Do đó, Ethereum đã thêm một liên kết đồng thuận mới trong bản nâng cấp có tên Altair. Sau khi nâng cấp Altair, một ủy ban gồm 512 người xác nhận sẽ được chọn từ những người xác nhận trên chuỗi Ethereum cứ sau 256 kỷ nguyên (khoảng 27 giờ). Họ sẽ chịu trách nhiệm ký vào tiêu đề khối cuối cùng. Máy khách nhẹ chỉ cần xác minh rằng 2/3 ủy ban đã ký để xác minh tiêu đề khối. Tuy nhiên, 512 vẫn hơi quá nhiều, vì vậy Ethereum cũng sử dụng công nghệ BLS để tổng hợp nhiều chữ ký của ủy ban thành một chữ ký, điều này giúp giảm hơn nữa chi phí xác minh của các khách hàng nhỏ. Darwinia đã được nâng cấp dựa trên Altair và triển khai ứng dụng khách nhẹ của Ethereum trên Chuỗi Darwinia. Ứng dụng khách nhẹ chỉ cần đồng bộ hóa tiêu đề khối sau mỗi 27 giờ. Đây sẽ là ứng dụng khách nhẹ trên chuỗi đầu tiên được triển khai trên Ethereum sau khi chuyển đổi PoS.

5.5.6.2 Cấu trúc của LCMP

Cấu trúc tổng thể của LCMP Thiết kế rất thanh lịch và rõ ràng.

Như hình trên, LCMP được chia thành lớp tin cậy (Truth Layer), lớp vận chuyển (Message Layer) và lớp ứng dụng (App Layer). Trong số đó, lớp tin cậy bao gồm các máy khách hạng nhẹ và Head Relayer trên chuỗi nguồn và chuỗi đích, còn lớp vận chuyển bao gồm một tập hợp các hợp đồng chịu trách nhiệm xử lý việc gửi và nhận tin nhắn, cũng như Message Relayer. Trong hình không có sự phân biệt giữa Head Relayer và Message Relayer, tuy nhiên trong hoạt động thực tế đây là 2 dịch vụ khác nhau.

Truyền tin nhắn LCMP 

Gửi tin nhắn LCMP theo sau Nguyên tắc "bắt tay ba bước" chắc hẳn đã quen thuộc với những người bạn đã quen với giao thức TCP. Điều này có nghĩa là việc gửi tin nhắn sẽ trải qua ba giai đoạn

· Tin nhắn được gửi từ chuỗi nguồn và đến nơi tại chuỗi mục tiêu

· Việc nhận được tin nhắn đến được trả lại từ chuỗi mục tiêu đến chuỗi nguồn

· Thông báo đến cùng với biên nhận sau đó sẽ được gửi từ chuỗi nguồn đến chuỗi đích

Sau khi hoàn thành ba liên kết này, có Hai điều kiện được đáp ứng

· Chuỗi nguồn biết rằng chuỗi mục tiêu đã nhận được thông báo

· Chuỗi mục tiêu cũng biết rằng chuỗi nguồn biết rằng chuỗi mục tiêu đã nhận được tin nhắn

Điều này rất quan trọng vì việc thiết kế lớp ứng dụng sẽ mang lại sự tiện lợi lớn.

Luồng thông báo

Sau khi hiểu điều này Sau một lớp, chúng ta hãy xem luồng tin nhắn LCMP (Vòng đời tin nhắn)

1. send_message 

Hợp đồng lớp ứng dụng gọi hàm send_message trong hợp đồng gửi đi và hợp đồng gửi đi sẽ lưu trữ thông báo và đưa ra sự kiện "MessageAccepted". Tin nhắn được đưa vào danh sách cần gửi, trạng thái ban đầu là: chưa gửi (sẽ được gửi)

2. chuyển tiếp

Trình chuyển tiếp hoạt động như một tác nhân ngoài chuỗi và truyền thông điệp đến hợp đồng gửi đến của chuỗi mục tiêu. , và tạo bằng chứng về việc gửi tin nhắn get_messages_proof(). Tin nhắn sẽ được gửi đến ứng dụng đích theo hợp đồng gửi đến và sự kiện "MessageDispathed" sẽ được phát ra. Tại thời điểm này, trạng thái tin nhắn được đánh dấu là đã gửi (đã gửi) ) trong hợp đồng gửi đến của chuỗi mục tiêu. .

· Các tác vụ được thực hiện bởi thông báo sẽ được ứng dụng đích thực hiện. Tại đây, nhà phát triển có thể cung cấp bộ lọc tùy chỉnh để lọc các tin nhắn không mong muốn.

3. xác nhận (chuỗi nguồn)

Người chuyển tiếp chuyển nhận_messages_proof trở lại chuỗi nguồn, và Tạo dữ liệu nhận_messages_delivery_proof, phát hành sự kiện MessageDelivered và tin nhắn được đánh dấu là Đã xác nhận (đã xác nhận) trong hợp đồng gửi đi của chuỗi nguồn.

· Ứng dụng nguồn nhận được sự kiện MessageDelivered và có thể thực hiện một loạt hành động do nhà phát triển tùy chỉnh.

4.phần thưởng 

Thông điệp trong hợp đồng gửi đi của chuỗi nguồn được đánh dấu khi được xác nhận sau đó, các khoản phí sẽ được thanh toán và tài khoản của Người chuyển tiếp trên chuỗi nguồn sẽ tự động được thanh toán.

5.comfirm (chuỗi mục tiêu)

Người chuyển tiếp đã xác nhận và khen thưởng tin nhắn trong nguồn chuỗi Thông tin được chuyển đến chuỗi mục tiêu và hợp đồng gửi đến chuỗi mục tiêu đánh dấu trạng thái thông báo là đã xác nhận.

· Relayer có thể xử lý hành động này theo đợt, nhưng nếu số tiền tích lũy được phân phối trong hợp đồng gửi đến của chuỗi mục tiêu (được phân phối nhưng Quá nhiều tin nhắn chưa được xác nhận) sẽ khiến nó ngừng nhận tin nhắn mới. Relayer phải thực hiện hành động này định kỳ để các tin nhắn không bị chặn.

Phí và ưu đãi

Người khởi tạo chuỗi chéo (có thể là người dùng hoặc Dapp) cần phải trả phí khi gửi tin nhắn chuỗi chéo và phí sẽ bao gồm ba phần:

1. Phí gas để thực hiện các giao dịch chuỗi nguồn.

2. Phí trả cho Relayer.

Giá cụ thể do thị trường quyết định và nhiều Người chuyển tiếp có thể cạnh tranh về giá.

Cần lưu ý rằng Người chuyển tiếp cần phải trả phí Gas trên chuỗi mục tiêu và Người chuyển tiếp sẽ phản ánh chi phí này trong giá cả. Nói cách khác, người khởi tạo chuỗi chéo Không cần phải trả phí gas riêng trên chuỗi mục tiêu.

3. Phí trả cho Treasure.

Một tỷ lệ nhất định phí chuỗi chéo được trả bởi những người khởi xướng chuỗi chéo sẽ được chuyển vào Kho báu Darwinia. Treasure sẽ sử dụng một phần quỹ của mình để trợ cấp cho Head Relayer.

Darwinia Documents 

Ngã ba Ethereum Altair

5.5.7 zkBridge

Tại thời điểm viết bài này, zkBridge là một dự án non trẻ chỉ mới hoàn thành một phần nhỏ quá trình phát triển. Nhưng dự án này là một trong số ít dự án cho đến nay sử dụng công nghệ chứng minh kiến thức bằng không để xây dựng các cây cầu xuyên chuỗi. zkBridge sử dụng bằng chứng ZK-SNARK để mở rộng các nút ánh sáng.

Hiện tại zkBridge đã triển khai một phiên bản Cosmos Client trên Ethereum bằng cách sử dụng Solidity. Theo thử nghiệm, tiêu đề khối ZK của Vùng Cosmos có thể được tạo trong vòng 2 phút. -SNARK proof, còn bên Ethereum chỉ tốn 220k gas để xác minh, so sánh nếu không sử dụng proof ZK-SNARK thì chi phí sẽ là 64 triệu Gas.

Những cải tiến chính của zkBridge là:

· deVirgo: Sử dụng Phân phối Một phương pháp mới được sử dụng để tạo bằng chứng ZK-SNARK, được gọi là deVirgo. Phương pháp này cải thiện đáng kể thời gian tạo bằng chứng ZK-SNARK ngoài chuỗi bằng cách chia nhỏ công việc tính toán và phân bổ nó cho nhiều thiết bị hơn.

· Bằng chứng đệ quy: Để giảm chi phí trên chuỗi, zkBridge sử dụng sơ đồ chứng minh đệ quy (bằng chứng được tạo ra về proof), thông qua hai lần đệ quy đã nén bằng chứng ZK-SNARK thành khoảng 131 byte

· Xử lý hàng loạt: zkBridge đã triển khai Khối A Hợp đồng cập nhật tiêu đề, lấy chiều cao khối làm đầu vào và trả về tiêu đề khối tương ứng. Tuy nhiên, zkBridge không gọi hợp đồng cập nhật khi mỗi khối mới được tạo. Trước tiên, người chứng minh có thể thu thập N tiêu đề khối để tạo ra một bằng chứng duy nhất. Giá trị N có thể được đặt. N càng lớn, thời gian chờ của người dùng càng lâu nhưng chi phí vận hành hệ thống càng thấp.

Phải nói rằng công nghệ zero-know-proof là công nghệ có thể tạo ra những điều kỳ diệu. Điểm nghẽn chính hạn chế việc áp dụng nó là ngưỡng kỹ thuật cao và khó khăn trong quá trình phát triển, tuy nhiên, trong quá trình phát triển công nghệ chứng minh không có kiến thức, phần thưởng và nỗ lực luôn tương xứng.

Giới thiệu về zkBridge, nhiều chi tiết kỹ thuật khác vẫn chưa được tiết lộ và chúng tôi sẽ tiếp tục theo dõi.

Tin nhắn dài trên Twitter của zkBridge

Bài báo zkbridge: zkBridge: Những cầu nối chuỗi chéo không đáng tin cậy được thực hiện thực tế (arxiv.org) 

5.5.8 Giao thức MAP

Giao thức MAP là giao thức chuỗi chéo không đồng nhất chung dựa trên các máy khách hạng nhẹ và chuỗi chuyển tiếp. Không giống như nhiều dự án nói trên, MAP đã chọn thiết lập chuỗi chuyển tiếp, Chuỗi MAP, làm trạm trung chuyển để truyền tin nhắn xuyên chuỗi. Các chuỗi truy cập không cần kết nối trực tiếp với nhau mà đều được kết nối với Chuỗi MAP, nghĩa là: mỗi chuỗi truy cập chỉ cần triển khai hợp đồng nút nhẹ của Chuỗi MAP và các nút nhẹ của mỗi chuỗi truy cập chuỗi được triển khai trên hợp đồng Chuỗi MAP.

Kiến trúc của Giao thức MAP được chia thành ba lớp, đó là lớp giao thức, lớp dịch vụ chuỗi chéo và lớp ứng dụng. Trong số đó:

· Lớp giao thức có thể hiểu là lớp tin cậy, bao gồm MAP Chain và từng client ánh sáng của chuỗi truy cập chương trình ;

· Lớp dịch vụ chuỗi chéo cung cấp một số mô-đun chung cho lớp ứng dụng để lớp ứng dụng thực hiện không cần phải "phát minh lại bánh xe." Ví dụ: một mô-đun Vault chung có thể khóa tiền cho một số ứng dụng cầu nối tài sản nhưng ứng dụng cũng có thể chọn xây dựng Vault của riêng mình mà không cần sử dụng mô-đun này.

· Lớp ứng dụng đề cập đến các ứng dụng sử dụng giao thức MAP làm phương tiện truyền thông điệp xuyên chuỗi.

Ngoài ra, Giao thức MAP bao gồm ba vai trò ngoài chuỗi

·

Mặc dù Layerzero gọi giải pháp kỹ thuật của mình là Ultra Light Node, nhưng giải pháp của nó không liên quan gì đến chuỗi chéo máy khách hạng nhẹ. LayerZero sẽ không triển khai bất kỳ nút nhẹ nào của chuỗi trên chuỗi được hỗ trợ. Về phương thức xác minh, LayerZero xác minh bằng chứng giao dịch do Relayer cung cấp thông qua tiêu đề khối do Oracle cung cấp. Quá trình xác minh xảy ra ở thiết bị đầu cuối của chuỗi mục tiêu và được một xác minh gốc. Tuy nhiên, việc xác minh tiêu đề khối được hoàn thành bởi mạng Oracle của bên thứ ba với tư cách là người xác minh bên ngoài. Quá trình xác minh diễn ra ngoài chuỗi. Về bản chất, giải pháp được LayerZero áp dụng vẫn thuộc về xác minh bên ngoài.

DApp Trách nhiệm giải trình 

LayerZero được định vị nhiều hơn như một tiêu chuẩn phân phối và xe buýt thông tin trung lập. dApp là chính cơ thể của các dịch vụ chuỗi chéo. dApps có toàn quyền tự chủ và có thể quyết định nên chọn Relayer nào và chọn oracle nào. Trong LayerZero, cả Relayer và Oracle đều có thể truy cập. Bất kỳ ai cũng có thể chạy Relayer và bất kỳ mạng Oracle của bên thứ ba nào cũng có thể tham gia (Oracle mặc định hiện tại là Chainlink). Nhưng trạng thái lý tưởng mà LayerZero mong đợi là mỗi dApp phải chạy Relayer độc quyền của riêng nó. Ở trạng thái này, nếu mạng oracle muốn thông đồng với Relayer để làm điều ác, xây dựng các giao dịch giả và xác minh nó thì phải thông đồng với cơ quan chính kiểm soát Relayer - bên dự án dApp, còn bên dự án dApp khó có thể làm được. làm bất cứ điều gì để tự hủy hoại chính nó.

Ngoài ra, ngay cả khi xảy ra tình huống xấu chung, rủi ro vẫn có thể được hạn chế trong dApp và sẽ không ảnh hưởng đến các dApp khác sử dụng các Rơle khác nhau. Đây là một biện pháp cách ly rủi ro.

Tuy nhiên, chúng tôi tin rằng sự thông đồng nêu trên không phải là hoàn toàn không thể xảy ra. Mặc dù các bên tham gia dự án dApp hầu hết sẽ không phản đối nhau nhưng điều này không loại trừ những trường hợp đó. người có ý định kéo thảm bên dự án dApp. Do đó, chúng ta cần nhận ra rằng LayerZero không hoàn toàn không đáng tin cậy như đã tuyên bố. Nhưng đồng thời, chúng ta cũng phải thấy rằng thiết kế riêng biệt của Oracle và Relayer cũng như ý tưởng về trách nhiệm giải trình của dApp, so với mạng trình xác thực bên ngoài đơn giản chịu trách nhiệm trực tiếp truyền tin nhắn, bảo mật vẫn có thể được cải thiện đáng kể. của LayerZero là dương.

Luồng tin nhắn 

Một tính năng chính khác của LayerZero là thiết bị đầu cuối mô-đun. hiểu cơ chế hoạt động của thiết bị đầu cuối, chúng ta hãy cùng tìm hiểu sâu về luồng thông tin chuỗi chéo của LayerZero.  

Chữ thập- chuỗi Việc truyền tải thông tin được chia thành 13 bước, để logic rõ ràng hơn chúng ta sẽ diễn đạt theo nhóm.

Bước 1-5: Khi một yêu cầu chuỗi chéo xảy ra trên chuỗi A, thiết bị đầu cuối của chuỗi A sẽ lần lượt thông báo cho Oracle và Relayer từ chuỗi A Lấy thông tin tương ứng như sau: 

1. Người dùng tạo giao dịch T trên chuỗi A thông qua dApp-X cần được chuyển xuyên chuỗi tới chuỗi B và gửi Communicator (sau đây gọi là Communicator ) đến thiết bị đầu cuối chuỗi A. A) Bắt đầu một yêu cầu chuỗi chéo, nội dung yêu cầu là [t, dst, payload, Relayer-args]

Lời nhắc nồng nhiệt: Nếu bạn không phải là dân kỹ thuật và cảm thấy lộn xộn khi nhìn thấy đoạn mã, bạn có thể tham khảo bài viết sau Thay thế toàn bộ nội dung trong ngoặc vuông bằng "tham số liên quan" rồi đọc.

2. Communicator A xử lý yêu cầu chuỗi chéo thành một gói dữ liệu, bao gồm [gói(dst,payload),t,relayer-args] và gửi nó tới Trình xác thực A; 

3. Trình xác thực A gửi [t,dst] đến Mạng A, thông báo cho Mạng A để lấy ID khối hiện tại; 

4. Trình xác thực A gửi [gói(dst,payload),t,relayer-args] tới Relayer, thông báo cho Relayer để lấy bằng chứng giao dịch; 

5.Network A gửi ID khối cho Oracle và thông báo cho Oracle để lấy tiêu đề khối;

Bước 6-9: Relayer và Oracle lần lượt lấy thông tin tương ứng và gửi đến thiết bị đầu cuối trên chuỗi B. Chi tiết như sau:

6. Oracle lấy tiêu đề khối từ chuỗi A; 

7. Relayer đọc giao dịch T và bằng chứng bằng chứng giao dịch của nó( t) từ chuỗi A, Lưu trữ cục bộ; 

8.Oracle gửi tiêu đề khối tới Mạng B; 

9.Mạng B gửi giá trị băm trong tiêu đề khối tới Trình xác thực B;

Bước 10-11: Ngoài yêu cầu chuỗi chéo hiện tại, trong Có thể có các yêu cầu chuỗi chéo khác trong cùng một khối, do đó, Relayer sẽ lấy tiêu đề khối, sau đó lấy tất cả nội dung yêu cầu chuỗi chéo liên quan đến khối. Chi tiết như sau:  

10.Validaor B gửi hàm băm tiêu đề khối tới Relayer; 

11.Relayer thu thập dòng điện Tất cả các yêu cầu chuỗi chéo và bằng chứng giao dịch liên quan [Gói(dst,payload),t,proof(t)] trong khối đều được trả về Trình xác thực B;

Bước 12-13: Thiết bị đầu cuối của chuỗi B sử dụng tiêu đề khối để xác minh các giao dịch liên quan này và gửi chúng đến ứng dụng đích dApp Y. Quá trình truyền tin nhắn xuyên chuỗi đã hoàn tất: 

12. Trình xác thực B sử dụng tiêu đề khối để xác minh tất cả các giao dịch đã nhận, các giao dịch không xác minh được sẽ bị loại bỏ. Giao dịch đã được xác minh [gói(dst,payload)] được gửi đến Communicator B; 

13. Communicator B gửi giao dịch đã được xác minh [gói( dst, payload)] được gửi đến dApp Y.

Chúng tôi nhận thấy rằng mỗi mô-đun của thiết bị đầu cuối hoạt động giống như một ngăn xếp mạng. Ở đầu gửi, tin nhắn sẽ đi từ Communicator đến Validator tới Network và ở đầu nhận kết thúc Chỉ là cách khác xung quanh. Thiết kế này rất linh hoạt. Khi LayerZero hỗ trợ chuỗi truy cập mới, ba mô-đun này không cần phải sửa đổi. Bạn chỉ cần thêm tham số về chuỗi mới trong Thư viện. Thiết kế này giúp LayerZero rất dễ dàng mở rộng. Blockchain mới.

Về mặt thiết kế luồng tin nhắn, LayerZero sẽ trực tiếp xử lý tất cả các yêu cầu chuỗi chéo trong cùng một khối cùng một lúc, do đó tránh được sự trùng lặp công việc không cần thiết.

Phí và ưu đãi

Oracle của bên thứ ba Dịch vụ này có mô hình kinh tế riêng, độc lập với chính LayerZero. Oracle bên thứ ba cũng sẽ tính phí các dApp sử dụng LayerZero.

LayerZero hy vọng rằng các dự án dApp sẽ tự chạy Relayer. Tất nhiên, các dự án dApp cũng có thể đặt ra tiêu chuẩn thanh toán và sau đó thuê ngoài cộng đồng. LayerZero có thể yêu cầu Người chuyển tiếp cầm cố tiền như một sự đảm bảo an ninh, nhưng hiện tại LayerZero chưa đưa ra yêu cầu như vậy. Dựa trên ý tưởng cốt lõi của LayerZero về “trách nhiệm dApp”, chúng tôi suy đoán rằng trong tương lai LayerZero sẽ cho phép các bên tham gia dự án dApp quyết định có nên cam kết hay không và cam kết bao nhiêu. Càng nhiều cam kết, tính bảo mật cho người dùng của chính dApp càng cao.

Tình trạng ứng dụng của LayerZero 

Sự phát triển sinh thái của LayerZero Sớm, các chuỗi công khai được hỗ trợ cho đến nay bao gồm Ethereum, Polygon, BSC, Avalanche, Fantom, DFK, Harmony, cũng như mạng lớp thứ hai Ethereum Arbitrum, Optimism, Swimmer Network chuỗi con Avalanche và Polkadot parachain Moonbeam.

Các ứng dụng sinh thái trên LayerZero cũng bắt đầu phát triển. Ngoài sản phẩm DEX chuỗi chéo Stargate do LayerZero tự xây dựng, các sản phẩm DEX chuỗi chéo Hashflow và Interswap đã được tạo của bên thứ ba cũng bắt đầu phát triển mạnh mẽ, lần lượt bắt đầu. Ngoài DEX chuỗi chéo, ứng dụng đầu tiên được phát triển trên LayerZero là các ứng dụng NFT, chẳng hạn như bộ sưu tập NFT Gh0stly Gh0sts, Tiny Dinos, Yakuza Pandas, cầu NFT chuỗi chéo parakeet.dao và trò chơi nuôi mèo NFT Catddle.

Ngoài ra, Clearpool, một dự án cho vay phi tập trung dành cho các tổ chức, cũng đã công bố quyền truy cập vào LayerZero để đạt được các chức năng liên quan đến chuỗi chéo.

Sách trắng LayerZero

Tài liệu LayerZero

5.6.7 CCIP (Chuỗi liên kết)

CCIP là một hệ thống chuỗi chéo được Chainlink công bố vào cuối năm 2021 và vẫn đang được phát triển.

Chainlink là công ty dẫn đầu trong lĩnh vực oracles và có tài nguyên nút rất phong phú, đủ để hình thành một ủy ban nút phân tán hơn hoặc bộ trình xác thực PoS. Việc Chainlink xây dựng cơ sở hạ tầng cầu nối chuỗi chéo là điều đương nhiên.

Logic chuỗi chéo của CCIP gần giống với logic của cầu PoS:

Ứng dụng từ chuỗi nguồn gọi Bộ định tuyến tin nhắn của Chainlink, Chainlink DON (Mạng Oracle phi tập trung) sẽ nghe tin nhắn và thực hiện chữ ký đồng thuận trên tin nhắn, sau đó chuyển tiếp nó đến chuỗi mục tiêu bởi Relayer. xác minh chữ ký của tin nhắn và gửi nó đến ứng dụng đích.

Nhưng ngoài điều này, CCIP còn giới thiệu hệ thống quản lý rủi ro "mạng lưới chống lừa đảo". Mạng chống gian lận độc lập với mạng oracle và đóng vai trò là lớp xác minh mới thường xuyên gửi kiểm tra nhịp tim khi hệ thống đang chạy. Nếu mạng chống gian lận ngừng gửi nhịp tim hoặc báo cáo hành vi độc hại, cơ chế tắt khẩn cấp sẽ tự động được kích hoạt.

Các thiết kế của CCIP và LayerZero có một điểm chung, đó là việc xây dựng hai lớp tin cậy độc lập.

Chainlink hiện chỉ phát hành một tài liệu CCIP rất sơ bộ và thông tin chi tiết hơn vẫn chưa được tiết lộ.

Giới thiệu về CCIP

5.6.8 pNetwork v2

pNetwork có những điều có thể chứng minh được Một cầu nối chuỗi chéo do nhóm phát triển, pNetwork V1 đã được ra mắt vào tháng 3 năm 2020. Đây là cầu nối Wrap và tài sản Wrap được gọi là pTokens. Vào tháng 10 năm 2021, pNetwork V2 đã được phát hành. Phiên bản này đã mở rộng pNetwork thành cầu nối AMB.

pNetwork V2 tiếp tục tính năng cốt lõi của V1, đó là sử dụng mạng MPC bao gồm các nút TEE để xác minh các tin nhắn xuyên chuỗi. TEE là viết tắt của Trusted Execution Environment, dịch sang tiếng Trung là Môi trường thực thi đáng tin cậy, không còn xa lạ trong cuộc sống hàng ngày của chúng ta. Việc xác minh dấu vân tay trên điện thoại di động chạy trong TEE.

TEE là một môi trường điện toán chạy trên một thiết bị nhất định và tách biệt khỏi hệ điều hành chính, giống như một vùng kín. Sự cô lập này được thực thi bởi phần cứng. Quá trình chạy các chương trình trong TEE được ẩn và thế giới bên ngoài không thể nhận ra, điều này làm giảm khả năng TEE bị tin tặc tấn công. Sau khi chương trình chạy trong TEE, kết quả tính toán đầu ra sẽ được đính kèm chữ ký do thiết bị tạo ra, chữ ký này sẽ được nhà cung cấp thiết bị xác minh từ xa và tạo chứng chỉ xác minh từ xa. Chứng chỉ xác minh từ xa có thể xác nhận với thế giới bên ngoài rằng chương trình đã được thực thi hoàn toàn trong TEE và không bị giả mạo hoặc can thiệp. Do đó, TEE có thể chạy các ứng dụng có yêu cầu bảo mật cao, chẳng hạn như quản lý khóa mã hóa, xác thực sinh trắc học, xử lý thanh toán an toàn, v.v.

Cấu trúc

pNetwork V2 chủ yếu bao gồm các phần sau

p>

· Mạng nút TEE: Bất kỳ đối tượng nào sở hữu thiết bị TEE đều có thể cam kết 200 $PNT (ít nhất 3 tháng) để trở thành nút TEE mạng. Mạng nút TEE trong pNetwork sẽ chịu trách nhiệm ký kết đồng thuận các thông báo chuỗi chéo. Trong quá trình khởi tạo, tập hợp nút TEE cần cùng tham gia tính toán khóa bí mật để tạo ra các đoạn khóa chung và khóa riêng. Chỉ có một khóa chung ở trạng thái công khai. Các đoạn khóa riêng được tạo cục bộ và được lưu trữ trong TEE.”

· Cổng thông tin: pNetwork là một tập hợp các hợp đồng trên chuỗi quản lý hàng đợi truyền tin nhắn xuyên chuỗi;

· Người đưa thư: tương tự như Relayer;

· pNetwork DAO: pNetwork áp dụng phương pháp DAO để quản trị. Người nắm giữ $PNT có thể cam kết $PNT, tham gia bỏ phiếu quản trị và quyết định các thông số chi phí cũng như hướng phát triển của pNetwork.

Luồng tin nhắn

1. Thẻ người dùng Ứng dụng nguồn gọi hợp đồng Cổng thông tin trên chuỗi nguồn và bắt đầu yêu cầu gửi tin nhắn xuyên chuỗi;

2. Nút TEE lắng nghe yêu cầu và đặt thông báo chuỗi chéo trên nút TEE Xác minh trung bình (nút nhẹ của chuỗi nguồn cần được chạy trong TEE) và được ký bằng các đoạn khóa riêng của chính nó. Khi số lượng đoạn khóa riêng đã ký đạt đến ngưỡng (2/3 ), một chữ ký hoàn chỉnh sẽ được tổng hợp (khóa riêng của văn bản gốc sẽ không bị lộ), nghĩa là tin nhắn đã được xác minh;

3. Người đưa thư gửi tin nhắn chuỗi chéo đã được xác minh đến hợp đồng Cổng thông tin của chuỗi mục tiêu và hợp đồng Cổng thông tin sẽ kiểm tra chữ ký, sau đó chuyển tiếp đến ứng dụng đích.

Tại sao nên sử dụng nút TEE

2022 Bật Ngày 23 tháng 3 năm 2019, cầu nối chuỗi chính thức của Axie Infinity, Ronin Bridge, đã bị hack, nguyên nhân là do khóa riêng của 5 trong số 9 nút đa chữ ký đã bị tin tặc đánh cắp. Trong sự cố này, chúng tôi thấy rằng ngay cả khi các nút đa chữ ký không tích cực thông đồng, những kẻ tấn công bên ngoài vẫn có thể đột nhập vào thiết bị của nút đa chữ ký, đánh cắp khóa riêng và sau đó tấn công cầu nối chuỗi chéo .

Vì các nút đa chữ ký cần sử dụng các chương trình để ký các tin nhắn xuyên chuỗi nên khóa riêng tư phải bị lộ trên mạng và có thể dễ dàng trở thành mục tiêu tấn công của hacker. Nếu các nút đa chữ ký sử dụng thiết bị TEE để lưu trữ khóa riêng, xác minh và ký giao dịch, vấn đề này có thể được khắc phục ở mức độ lớn và gây khó khăn cho kẻ tấn công.

pNetwork hỗ trợ các nút sử dụng thiết bị TEE của các nhà sản xuất khác nhau để truy cập mạng. Các giải pháp kỹ thuật cụ thể của thiết bị TEE của các nhà sản xuất khác nhau có thể khác nhau, nếu thiết bị TEE của nhiều nút đến từ các nhà sản xuất đa dạng thì các cuộc tấn công của hacker sẽ được ngăn chặn hơn nữa. Bởi vì hacker cần phải đột nhập vào các thiết bị TEE khác nhau mới có thể thực hiện được các cuộc tấn công.

Trạng thái đăng ký

Tính đến tháng 9 năm 2022 Vào tháng 1, pNetwork hỗ trợ mọi tin nhắn xuyên chuỗi từ 9 chuỗi, bao gồm Ethereum, Polygon, Gnosis Chain, Telos, Libre, EOS, BSC, Arbitrum và Algorand, đồng thời hỗ trợ truyền pBTC trên các chuỗi này.

Mặc dù pNetwork V2 đã được phát hành dưới dạng cầu nối tin nhắn tùy ý, nhưng hiện tại, "hoạt động kinh doanh chính" của pNetwork vẫn là cầu nối tài sản và hiện tại không có cầu nối thứ ba. party Các ứng dụng chuỗi chéo được xây dựng dựa trên pNetwork V2.

Giới thiệu pNetwork V2

5.6.9 Mạng Bool

Mạng Bool là một dự án cầu nối AMB khác sử dụng mạng nút TEE làm trình xác thực bên ngoài. Bool Network đã thực hiện những đổi mới hơn nữa trên cơ sở này - bổ sung cơ chế xoay vòng và ẩn danh cho các nút TEE. Điều này không chỉ làm cho các cuộc tấn công bên ngoài trở nên khó khăn hơn mà còn loại bỏ hầu như sự thông đồng nội bộ.

Bool Network đề cập đến Cosmos IBC và giới thiệu khái niệm về Kênh. Các kênh có thể được thiết lập giữa hai ứng dụng được triển khai trên các chuỗi khác nhau để đạt được việc gửi tin nhắn một cách có trật tự. Mỗi Kênh sẽ tương ứng với ít nhất một ủy ban MPC. Ủy ban chịu trách nhiệm ký kết đồng thuận các thông điệp chuỗi chéo trong Kênh trong thời đại hiện tại. Ủy ban MPC này đang luân phiên và chỉ tồn tại trong 1 epcoh, mỗi epcoh sẽ được bầu lại.

· Bool Network hiện chỉ định hai ủy ban cho mỗi Kênh để dự phòng cho nhau nhằm cải thiện tính khả dụng của dịch vụ.

Bất kỳ ai cũng có thể trở thành nút TEE ứng cử viên bằng cách đặt cọc $BOL. Trước khi bắt đầu mỗi kỷ nguyên, Bool Network sẽ bầu ra một ủy ban MPC cho mỗi Kênh thông qua thuật toán Ring VRF. Các nút được chọn làm thành viên của ủy ban MPC sẽ có được danh tính tạm thời (cặp khóa công khai) được sử dụng để liên lạc với các nút TEE khác trong cùng ủy ban trong quá trình ký kết đồng thuận. Khi một kỷ nguyên kết thúc, tất cả danh tính tạm thời sẽ hết hạn và sau đó mạng sẽ bầu lại các nút, chọn một ủy ban MPC luân phiên mới và cung cấp cho họ danh tính tạm thời mới.

Mặc dù mỗi nút TEE ứng viên cần cung cấp thông tin nhận dạng vĩnh viễn (mã thiết bị) khi đăng ký, nhưng danh tính tạm thời được nút đó sử dụng trong quá trình liên lạc sẽ không. bị phơi bày, lộ ra. Nói cách khác, các nút ẩn danh với nhau khi giao tiếp. Nếu có 100 nút ứng cử viên thì bạn chỉ có thể biết rằng nút bạn đang liên lạc là 1 trong 100 nút đó chứ không biết đó là nút nào.

Số lượng nút TEE mà ủy ban MPC của mỗi Kênh yêu cầu và ngưỡng chữ ký được người tạo Kênh tùy chỉnh. Các giá trị ngưỡng thường được sử dụng là 15 trên 21, 13 trên 19 và 5 trên 9.

Trong cùng một Kỷ nguyên, các thành viên ủy ban MPC của các kênh khác nhau có thể trùng lặp và một số nút ứng cử viên có thể không được bầu vào bất kỳ ủy ban nào và trở thành trạng thái nhàn rỗi. Những tình huống này là bình thường.

Chúng tôi nhận thấy Bool Network đã xây dựng một hộp đen không thể phá vỡ thông qua sự kết hợp giữa TEE, cơ chế xoay vòng và cơ chế ẩn danh. Vì chương trình chữ ký chạy trong TEE của nút ẩn danh và nội dung liên lạc giữa chúng được mã hóa DH, miễn là nó không ở trạng thái rảnh, bản thân người điều hành nút TEE không có cách nào biết mình thuộc ủy ban MPC của Kênh nào được bầu vào và anh ấy đã tham gia vào nút nào. Sau khi giao tiếp đồng thuận, chúng tôi thậm chí không thể “biết chính mình” về các tin nhắn đã ký chứ đừng nói đến “biết người khác”. Về cơ bản, điều này khiến các nút không thể thông đồng với nhau.

Từ góc độ của kẻ tấn công bên ngoài, nếu bạn muốn tấn công một Kênh cụ thể, kẻ tấn công không có cách nào để biết thiết bị nào đứng sau ủy ban MPC hiện tại, Kẻ tấn công cũng không thể biết được thông tin này đã bị chặn từ thông tin liên lạc nào.

Dù là âm mưu nội bộ hay tấn công từ bên ngoài, cách duy nhất để thành công là vượt qua phần lớn tất cả các nút ứng cử viên, đây chắc chắn là một cái giá rất lớn.

Bool Network là một dự án vẫn đang được phát triển và một số chi tiết kỹ thuật vẫn chưa được xác định đầy đủ. Những gì chúng tôi mô tả trong phần này chỉ là phác thảo kỹ thuật của nó.

Bài phát biểu trong không gian mạng Bool

5.6.10 XCMP (Polkadot)

Chúng tôi đã đề cập trước đó rằng mô hình chuỗi chéo của Polkadot có thể được quy cho một loại xác minh bên ngoài đặc biệt: xác minh được chia sẻ. Mô hình cơ bản của Polkadot là sharding, đó là cách Polkadot đạt được bảo mật chung. Mỗi parachain là một phân đoạn. Parachains không có trình xác thực riêng. Thay vào đó, chuỗi chuyển tiếp phân bổ một tập hợp con các trình xác nhận làm tập hợp trình xác thực của parachain. Sự phân bổ này là ngẫu nhiên và linh hoạt trong mỗi kỷ nguyên. Sẽ được phân phối lại. Tại bất kỳ thời điểm nào, bộ trình xác thực của chuỗi chuyển tiếp là sự kết hợp của các bộ trình xác thực của tất cả các parachain, phù hợp với các đặc điểm của xác minh chung.

Nhưng để hiểu cơ chế truyền chuỗi chéo của Polkadot, chúng ta cũng cần hiểu chi tiết về XCMP. XCMP (Truyền tin nhắn chuỗi chéo) là một giao thức truyền tin nhắn xuyên chuỗi trên Polkadot. Nó được sử dụng để liên lạc xuyên chuỗi giữa các chuỗi song song/luồng song song. XCMP vẫn đang được phát triển. Hiện tại, HRMP (Tin nhắn định tuyến chuyển tiếp ngang) đã được triển khai. Đạt). Ngoài ra, Polkadot sử dụng VMP (bao gồm UMP\DMP) để triển khai truyền thông điệp giữa các parachains/luồng và chuỗi chuyển tiếp.

HRMP cung cấp các giao diện và chức năng tương tự như XCMP, nhưng các thông báo chuỗi chéo được lưu trữ trong chuỗi chuyển tiếp, điều này sẽ mang lại tải cho chuỗi chuyển tiếp. Do đó, điều này là giải pháp chuyển tiếp và sau này sẽ được thay thế bằng XCMP.

Chúng ta cần hiểu sự khác biệt giữa XCMP và XCM: Gawin đã đề cập trong một cuộc phỏng vấn rằng XCMP chỉ là một nửa giải pháp chuỗi chéo của Polkadot, còn nửa còn lại là XCM.XCM là một định dạng tin nhắn có sự đồng thuận chéo phổ quát được phát triển bởi Polkadot. Mục đích của nó là thể hiện những gì người nhận tin nhắn nên làm.

Trọng tâm của phần này là XCMP. Tiếp theo, chúng tôi sẽ tháo dỡ mô hình truyền dẫn chuỗi chéo của XCMP.

5.6.10.1 Các khái niệm chính 

Kênh

Với Cosmos IBC Tương tự XCMP cũng có khái niệm Channel nhưng kênh trong XCMP là một chiều, nếu muốn giao tiếp hai chiều giữa hai chuỗi song song (A và B) thì cần thiết lập hai kênh (Kênh AB, Kênh BA).

Đi ra và đi vào

Khi một parachain Khi A thiết lập Kênh AB với parachain B, một đầu ra (hàng đợi thoát) của parachain B sẽ được tạo trên parachain A và một đầu vào (hàng đợi vào) của parachain A sẽ được tạo trên parachain B.

MR (Gốc thư)

Mỗi Ngoài việc lưu trữ văn bản gốc của hàng đợi tin nhắn sẽ được gửi, hàng đợi đầu ra cũng cần duy trì hàng đợi MR (Chuỗi băm hàng đợi tin nhắn). XCMP cũng sử dụng cấu trúc cây thông báo ở đây. Tất cả các thông báo được gửi dưới dạng cây Merkel dưới dạng nút lá. Giá trị gốc của cây được gọi là MR (Massage Root). Mỗi lần một thông báo mới được chèn dưới dạng nút lá, Một thông báo mới MR sẽ được tạo ra.

5.6.10.2 Luồng tin nhắn

(Lấy Kênh AB làm ví dụ)

1. Người dùng trên Chuỗi A bắt đầu chuỗi chéo thông qua ứng dụng nguồn Yêu cầu, muốn gửi tin nhắn M đến Chuỗi B. Tin nhắn sẽ được đưa vào hàng đợi đầu ra được thiết kế đặc biệt cho Chuỗi B trên Chuỗi A (chúng tôi viết tắt là: Egress AB). Tin tức này sẽ được đưa vào MR mới nhất.

2. Khi người thu thập Chuỗi A đóng gói khối hiện tại, anh ta sẽ đặt MR mới nhất vào tiêu đề khối. Khi khối được xác minh bởi người xác nhận được gán cho Chuỗi A theo chuỗi chuyển tiếp, nó sẽ được gửi đến chuỗi chuyển tiếp và được đưa vào khối của chuỗi chuyển tiếp. Tại thời điểm này, chúng tôi coi MR đã được chuỗi chuyển tiếp xác minh.

3. Người thu thập Chuỗi B sẽ liên tục thăm dò các hàng đợi thoát được thiết lập cho Chuỗi B trên tất cả các chuỗi khác, bao gồm cả Đi ra A B. Người thu thập Chuỗi B sẽ Đi ra A B Bản gốc văn bản tin nhắn và hàng đợi MR được đưa vào hàng đợi nhập tương ứng của chúng: Ingress AB. (* Có một câu nói khác rằng quy trình này không phải do người thu thập hoàn thành mà là do người xác minh. Thiết kế của điểm này chưa được xác định đầy đủ trong XCMP, nhưng ai sẽ hoàn thành nó không phải là điểm mấu chốt trong thiết kế XCMP, bởi vì nhiệm vụ này là Không có sự tin tưởng, bất cứ ai cũng có thể hoàn thành nó).

4. Người xác minh của Chuỗi B lấy MR mới nhất của Kênh AB được chuỗi chuyển tiếp xác minh từ chuỗi chuyển tiếp và MR đã được chuỗi chuyển tiếp xác minh . chứng minh. Vì những người xác nhận của Chuỗi B được chỉ định ngẫu nhiên từ chuỗi chuyển tiếp nên không có vấn đề về độ tin cậy trong quy trình này.

5.Chain B sử dụng MR này để xác định những tin nhắn nào từ Ingress AB đã được đưa vào chuỗi chuyển tiếp, sau đó cập nhật trạng thái của những tin nhắn này để xác minh.

6. Thông báo được xác thực có thể được thực thi bởi ứng dụng đích.

Để thuận tiện cho việc diễn đạt, chúng tôi chỉ mô tả luồng thông báo của một Kênh. Trên thực tế, khi XCMP xử lý các thông báo trên chuỗi chéo, tất cả các Kênh đều được xử lý tại cùng một lúc. Chuỗi chuyển tiếp duy trì bảng CST (bảng Trạng thái kênh) để lưu trữ MR của tất cả các Kênh.

UMP và DMP gần giống như XCMP và sẽ không được mô tả lại.

Tài liệu XCMP

5.6.11 Tóm tắt cầu nối xác thực bên ngoài

Chúng tôi đã trích dẫn một số trường hợp về cầu nối xác thực bên ngoài ở trên, bao gồm:

Hai cầu nối PoA là AnyCall và Wormhole;

Năm cây cầu PoS, cụ thể là Axelar, Hyperlane, Gravity Bridge, pNetwork V2, Bool Network;

Hai cầu TEE, cụ thể là pNetwork V2 và Bool Network;

Một cầu sử dụng Oracle bên ngoài, LayerZero, ở đó cũng là một cầu nối CCIP được xây dựng bởi nhà cung cấp dịch vụ oracle;

Hai cầu nối xác minh dùng chung: Gravity Bridge và XCMP của Polkadot.

Bạn đọc có thể nhận thấy hai cây cầu PoA mà chúng tôi liệt kê đã hứng chịu những đợt tấn công rất nghiêm trọng của hacker. Mặc dù cầu nối xác minh bên ngoài có nguy cơ các trình xác thực hợp tác gây ra điều xấu về các giả định bảo mật, nhưng trên thực tế, nguyên nhân của cuộc tấn công không phải là các giả định bảo mật mà là các lỗ hổng trong việc triển khai mã. Cầu PoA có nhiều khả năng thu hút các cuộc tấn công của hacker hơn vì nó dễ triển khai, thâm nhập thị trường sớm và phát triển nhanh chóng, đồng thời có TVL cao khiến nó trở thành mục tiêu trong mắt tin tặc. Vì vậy, chúng tôi sẽ không phủ nhận thiết kế cấu trúc tổng thể của một dự án chỉ vì nó đã bị hack. Chúng tôi sẽ có một chương dành riêng về cách các cầu nối chuỗi chéo có thể cải thiện tính bảo mật và ngăn chặn các cuộc tấn công của hacker.

Việc triển khai cầu PoS không khó nhưng token bảo vệ cầu cần phải có giá trị thị trường lớn để bảo vệ hoàn toàn tính bảo mật của mạng. , tấn công vào cầu Chi phí kinh tế sẽ thấp. Do đó, việc phát triển cầu PoS có thể sử dụng giải pháp PoA làm giai đoạn chuyển tiếp, sau đó chuyển sang PoS sau khi TVL tăng và đẩy giá token lên cao. Một vấn đề mà các cầu nối PoS phải đối mặt là sự mất cân bằng của các trình xác thực. Ví dụ: Axelar có 50 trình xác nhận, nhưng nếu bạn muốn đạt ngưỡng chữ ký là 2/3 thì bạn chỉ cần khoảng 10 chữ ký của trình xác thực chính. Để giảm bớt điều này vấn đề, Axelar áp dụng sơ đồ bỏ phiếu bậc hai; Hyperlane áp dụng sơ đồ "bằng chứng gian lận có thể xác minh" và những người xác nhận cùng phạm tội sẽ bị phát hiện ngay lập tức và thực thi Slash; pNetwork và Bool Network trực tiếp yêu cầu tất cả các nút cam kết số tiền như nhau.

pNetwork và Bool Network yêu cầu người xác minh PoS sử dụng TEE để lưu trữ khóa riêng tư và thực hiện chữ ký nhằm ngăn chặn những kẻ tấn công bên ngoài đánh cắp khóa riêng tư và tấn công các cầu nối chuỗi chéo, Bool Mạng cũng gây khó khăn cho các nút nội bộ thông đồng thông qua cơ chế xoay vòng và cơ chế ẩn danh của các nút TEE. LayerZero xây dựng duy nhất hai lớp tin cậy, một lớp là mạng Oracle bên ngoài và lớp kia là Relayer chịu trách nhiệm gửi tin nhắn, miễn là cả hai không thông đồng với nhau thì có thể đảm bảo an ninh chuỗi chéo. LayerZero cũng triển khai cách ly rủi ro chuỗi chéo giữa các ứng dụng thông qua trách nhiệm giải trình của ứng dụng. CCIP cũng đã xây dựng hai lớp tin cậy, một là mạng oracle và lớp kia là mạng chống lừa đảo. Ngoài ra, tài nguyên nút phong phú của Chainlink sẽ trao quyền cho nó.

Gravity Bridge và XCMP của Polkadot đều là những trường hợp xác minh chung. Gravity Bridge vẫn có thể được hiểu theo mô hình của cầu PoS, nhưng tính bảo mật của cây cầu khác với bảo mật của Gravity Chain Theo thỏa thuận, Gravity Bridge đang có kế hoạch thuê bảo mật từ Cosmos Hub (đây là một tính năng mới của Cosmos 2.0) để cải thiện hơn nữa tính bảo mật của cây cầu. XCMP được tùy chỉnh sâu dựa trên Polkadot và cam kết hiện thực hóa các chuỗi chéo đẳng hình giữa các parachain Polkadot. Nó giống như phân đoạn chéo hơn là chuỗi chéo. Tốt nhất nên hiểu nó từ góc độ phân chia chéo.

5.7 Cầu xác thực cục bộ

Xác thực cục bộ chỉ hoạt động trên cầu nối Hoán đổi. Hiện tại, cầu nối sử dụng giải pháp xác minh cục bộ chủ yếu là cầu nối tài sản xuyên lớp Ethereum. Chúng tôi đã có Phần 2 của loạt bài này Phần 5.2.3 liệt kê ba trường hợp điển hình của cBridge, Connext và StarEx Bridge. Vì vậy, sẽ không có ví dụ nào được đưa ra trong phần này.

5.8 Cầu nối xác minh lạc quan 

5.8.1 Nomad (trước đây là Optics)

Giải pháp kỹ thuật của Nomad ra đời từ Celo Một số thành viên cốt lõi của dự án cầu nối chuỗi chéo của Nomad Optics cũng đến từ nhóm nghiên cứu chuỗi chéo Summa được cLabs mua lại. Nhưng Nomad đã phát triển độc lập ngay từ đầu như một dự án xuyên chuỗi chung và không còn sử dụng cơ sở hạ tầng của Optics nữa. Vào ngày 13 tháng 4 năm 2022, Nomad đã hoàn thành vòng tài trợ ban đầu trị giá 22 triệu đô la với mức định giá 225 triệu đô la, do Polychian Captical dẫn đầu.

Nomad đang cố gắng giải quyết vấn đề tam giác bất khả thi xuyên chuỗi theo một cách hoàn toàn mới. Nomad nhận thức được những thiếu sót của giải pháp chuỗi chéo máy khách nút nhẹ về tính dễ thích ứng và cũng nhận thức được sự thỏa hiệp về bảo mật của giải pháp chuỗi chéo trình xác thực bên ngoài. Vì vậy, Nomad đã áp dụng phương pháp chống gian lận để xác minh thông tin chuỗi chéo. Ở Nomad, sau khi gửi thành công một tin nhắn xuyên chuỗi, sẽ có một khoảng thời gian tranh chấp (30 phút), nếu không có ai báo cáo gian lận trong khoảng thời gian tranh chấp thì tin nhắn sẽ được người nhận chính thức chấp nhận.

5.8.1.1 Các khái niệm và cấu trúc cốt lõi

Giao thức Nomad bao gồm hai phần cốt lõi: hợp đồng thông minh trên chuỗi và vai trò đại lý ngoài chuỗi:

Hợp đồng thông minh trên chuỗi hiện thực hóa thông điệp của Nomad gửi và nhận. Logic của hợp đồng thông minh trên chuỗi bao gồm Home và Replica. Trong số đó:

· Home is chịu trách nhiệm xử lý logic gửi tin nhắn. Nó có thể được hiểu là "hộp thư đi" của các tin nhắn xuyên chuỗi Nomad. Hợp đồng Home cũng chịu trách nhiệm quản lý tiền gửi (trái phiếu) của Người cập nhật);

· Replica chịu trách nhiệm xử lý logic của việc nhận tin nhắn và có thể hiểu là "hộp thư đến" của các tin nhắn xuyên chuỗi Nomad.

Cần lưu ý rằng trong blockchain được kết nối với Nomad, chỉ có một hợp đồng Home trên mỗi chuỗi, nhưng có thể có n-1 hợp đồng Bản sao. là số chuỗi truy cập. Thiết kế này trông quen thuộc với Hyperlane.

Tác nhân ngoài chuỗi chịu trách nhiệm gửi các thông điệp xuyên chuỗi một cách đáng tin cậy. Tác nhân ngoài chuỗi bao gồm Người cập nhật, Người theo dõi và Người chuyển tiếp. Có bốn vai trò: Người kế nhiệm) và Prosessor (Người thực thi). Trong số đó:

· Mỗi hợp đồng Trang chủ sẽ tương ứng với Người cập nhật và Người cập nhật chịu trách nhiệm ký [cập nhật], trong đó từ cập nhật Được sử dụng như một danh từ, nó là một danh từ đặc biệt trong ngữ cảnh của Nomad, biểu thị một cấu trúc dữ liệu cụ thể. Chúng tôi thêm một cách thống nhất các dấu ngoặc vuông để diễn tả nó. Một [update] chứa gốc _oldroot của cây thông báo trước đó và cây thông báo mới. Root _newRoot cũng sẽ chứa chữ ký số của Trình cập nhật sau khi được ký.

[ cập nhật] = [ _oldRoot , _newRoot]

[ cập nhật ] sau khi được Updater ký = [ _oldRoot , _newRoot, _signature

· Watcher chịu trách nhiệm quan sát và báo cáo gian lận;

· Relayer chịu trách nhiệm cung cấp [cập nhật] đã ký giữa các chuỗi ;

· Prosessor chịu trách nhiệm gửi văn bản gốc của tin nhắn xuyên chuỗi tương ứng (bao gồm cả đường dẫn Merkel) được chuyển tới chuỗi mục tiêu và kích hoạt hợp đồng Bản sao chuỗi mục tiêu để sử dụng [cập nhật] để xác minh thông báo chuỗi chéo, sau đó gửi thông báo đã xác minh đến ứng dụng mục tiêu cuối cùng để thực thi.

Kênh 

Trong Nomad, A Hợp đồng gia đình và hợp đồng Bản sao tương ứng với hợp đồng gia đình có thể tạo thành một Kênh. Kênh này là một chiều. Nếu việc truyền chuỗi chéo hai chiều được thực hiện thì cần phải có hai Kênh được ghép nối. Hợp đồng gia đình có thể tương ứng với nhiều Bản sao, do đó, bắt đầu từ chuỗi nguồn và đối mặt với nhiều chuỗi mục tiêu, sẽ có nhiều Kênh, điều này mang đến một trường hợp sử dụng mới cho Nomad: truyền tin nhắn một-nhiều.

5.8.1.2 Luồng tin nhắn

Chúng tôi Chúng ta hãy xem quy trình nhắn tin chuỗi chéo trong Nomad:

1. Ứng dụng gọi hợp đồng Home của chuỗi nguồn, hợp đồng này sẽ yêu cầu chuỗi chéo Tin nhắn T được xếp vào hàng đợi gửi;

2.Thư gốc mới nhất trước tin nhắn T trong Hợp đồng Home của chuỗi nguồn mà chúng ta đặt là _oldroot. Sau khi hoàn thành bước 1, hợp đồng Home định dạng thông báo T, chèn nó vào cây thông báo dưới dạng nút lá và tính toán gốc thông báo mới _newRoot. Sự khác biệt duy nhất giữa _newRoot và oldRoot là _newRoot chứa thông báo T;

3.Updater gọi hàm cập nhật trong hợp đồng Home, ký _oldRoot và _newRoot và sau đó trả lại vào hợp đồng Nhà. Hành vi này được gọi là cập nhật (ở đây là động từ, chúng tôi không thêm dấu ngoặc vuông). Mỗi khi tạo một thư gốc mới, nó có thể được cập nhật một lần. Tuy nhiên, để tiết kiệm chi phí, trình cập nhật cũng có thể thực hiện các thao tác hàng loạt sau đó. nhiều gốc thông điệp mới được tạo ra.update;

4. Relayer sẽ chuyển [update] được Người cập nhật ký vào chuỗi mục tiêu và gọi hợp đồng Bản sao của chuỗi mục tiêu để chuyển [ đến cập nhật] Đặt nó vào nhóm đang chờ xử lý và bắt đầu khoảng thời gian tranh chấp;

5.Trong khoảng thời gian tranh chấp, Wactcher kiểm tra gian lận, chủ yếu là Kiểm tra xem bản cập nhật được ký bởi Người cập nhật trong hợp đồng Home và bản cập nhật được Người chuyển tiếp chuyển đến chuỗi mục tiêu có nhất quán hay không để ngăn chặn thư gốc bị giả mạo;

6.Khi hết giờ và không có Watcher nào báo cáo gian lận, Prosessor sẽ nhận được thông báo T và đường đi Merkel của T từ chuỗi nguồn, chuyển nó đến chuỗi mục tiêu, gọi Hợp đồng bản sao trên chuỗi mục tiêu và xác minh việc bao gồm _newRoot cho thông báo T. Sau khi quá trình chứng minh hoàn tất, Prosessor sẽ xóa tin nhắn khỏi nhóm đang chờ xử lý và gửi nó đến ứng dụng đích.

Việc xác minh chỉ yêu cầu _newRoot và chức năng của _oldRoot phải được thực hiện theo trình tự.

Nomad, giống như Hyperlane, sử dụng cấu trúc cây thông báo để ngăn Trình cập nhật kiểm duyệt tin nhắn và giúp Watcher phát hiện gian lận dễ dàng hơn.

Quy trình xử lý gian lận

Quy trình trên trước tiên chúng ta hãy giả định rằng không có gian lận nào xảy ra. Nếu gian lận xảy ra:

· [update] trong chuỗi nguồn Hợp đồng nhà khác với [update] được Relayer chuyển tiếp đến chuỗi mục tiêu không nhất quán. _newRoot bị giả mạo có thể chứa một giao dịch chuyển một lượng lớn tiền đến Trình cập nhật.

Sau đó, Người theo dõi sẽ cần gửi chứng chỉ gian lận cho hợp đồng Bản sao trên chuỗi mục tiêu trong vòng 30 phút, đánh dấu [cập nhật] gian lận là không đáng tin cậy, sau đó Gửi bằng chứng gian lận cho hợp đồng Home trên chuỗi nguồn, khiến hợp đồng Home cắt giảm khoản tiền gửi của Người cập nhật không trung thực và ngừng xử lý các tin nhắn mới được gửi. Điều này có nghĩa là Kênh gửi tin nhắn từ chuỗi này đến chuỗi khác đã bị đóng. Cần lưu ý lúc này Kênh gửi tin nhắn từ chuỗi khác tới chuỗi này vẫn mở.

Trong tương lai, Nomad sẽ xóa [cập nhật] sai thông qua quản lý, thay đổi Trình cập nhật và khởi động lại Kênh.

Bạn có thể thắc mắc, tại sao Người cập nhật lại bị trừng phạt khi rõ ràng Người chuyển tiếp đã chuyển thư gốc giả mạo đến chuỗi mục tiêu? Lý do rất đơn giản: Relayer không thể giả mạo chữ ký của Trình cập nhật. Nếu Relayer chuyển một [cập nhật] bị giả mạo thì Trình cập nhật phải đã ký vào [cập nhật] bị giả mạo đó. Nguồn gốc của cái ác chỉ có thể là Updater, Updater độc ác có thể tự mình chạy dịch vụ Relayer hoặc âm mưu với Relayer để hoàn thành hành vi xấu xa.

5.8.1.3 Hiểu biết sâu sắc về 4 proxy ngoài chuỗi của Nomad

Chúng ta thấy rằng Nomad có 4 loại đại lý ngoài chuỗi, có vẻ hơi phức tạp nhưng bốn vai trò này đều không thể thiếu. phân tích sâu hơn về trách nhiệm của họ.

· Người cập nhật chỉ chịu trách nhiệm ký [cập nhật] và truyền nó trở lại chuỗi nguồn và không chịu trách nhiệm về việc gửi chính tin nhắn;

p>

· Relayer chỉ chịu trách nhiệm truyền [cập nhật ] giữa các chuỗi và văn bản tin nhắn gốc và đường dẫn Merkel được truyền bởi Prosessor Complete;

· Prosessor đã tắt - Vai trò đại lý chuỗi duy nhất của Nomad. Tại sao chúng ta nên thêm một vai trò riêng biệt như vậy? Điều này là do trước khi bằng chứng gian lận được hoàn thành, [update] được Relayer chuyển đến chuỗi mục tiêu đang ở trạng thái chờ xử lý và việc chuyển thông báo T vào lúc này là vô nghĩa. Prosessor chịu trách nhiệm kích hoạt thủ công chuỗi mục tiêu để kết thúc trạng thái chờ xử lý sau khi hoàn thành bằng chứng gian lận (sau khi hết thời gian tranh chấp). Tại thời điểm này, thông báo T được chuyển qua và hợp đồng Bản sao sử dụng [update] đã xác định để xác minh tin nhắn T. . Đối với các cầu nối chuỗi chéo xác minh bên ngoài thông thường thì không có quy trình như vậy. Các thông báo được gửi đến chuỗi mục tiêu có thể được xử lý trực tiếp, do đó không cần có vai trò như Prosessor.

· Cả Relayer và Prosessor đều là những vai trò không yêu cầu sự tin tưởng hay quyền truy cập nào cả, vì vậy Nomad không quan tâm. để làm điều đó, trên thực tế, đó có thể là bên dự án ứng dụng hoặc bất kỳ bên thứ ba nào.

· Nomad không có bất kỳ giả định tin cậy nào đối với Relayer, chỉ có giả định về tính sống động. Điều này là do Relayer không thể giả mạo chữ ký số của Updater (chữ ký công khai của Updater ). Khóa đã được đăng ký trong Bản sao của chuỗi mục tiêu) và chỉ có thể thực hiện nhiệm vụ của mình một cách trung thực. Tác hại lớn nhất mà Relayer có thể gây ra cho hệ thống là chuyển sang chế độ ngoại tuyến, khiến dịch vụ chuỗi chéo tạm thời không khả dụng. Như đã đề cập trước đó, nguồn lừa đảo chỉ có thể đến từ Updater chứ không phải Relayer.

· Vì cơ sở của sự tin tưởng là có ít nhất một người theo dõi trung thực, do đó, ở Nomad, không cần có Cấp độ cập nhật Phân quyền. Trên thực tế, mỗi hợp đồng Nhà chỉ cần tương ứng với một Trình cập nhật và không yêu cầu bộ trình xác thực đủ đa dạng như sơ đồ xác minh bên ngoài, giúp giảm chi phí. Nếu bên dự án ứng dụng hợp nhất một nhóm thực thể đa dạng hơn, thì lựa chọn tốt hơn là yêu cầu họ làm Người theo dõi. Nomad không có bộ Watcher cấp hệ thống và yêu cầu ứng dụng tùy chỉnh bộ Watcher của riêng nó.

5.8.1.4 Tính năng bảo mật của Nomad

Hãy xem xét tam giác bất khả thi về khả năng tương tác chuỗi chéo: trong ba điều sau, bạn chỉ có thể có được tối đa hai điều.

· Khả năng mở rộng: Hỗ trợ tính toán chuỗi chéo tổng quát

· Không tin cậy: không có giả định tin cậy mới nào được đưa ra

· Có thể khái quát hóa: có thể để dễ dàng thích ứng với nhiều blockchain hơn

Nomad đang phá vỡ khả năng tương tác chuỗi chéo theo cách độc đáo Tam giác bất khả thi, Nomad có hai ưu điểm chính của các giải pháp xác minh bên ngoài: khả năng mở rộng (Extensible ) và tính phổ quát (Generalizable). Trên cơ sở này, Nomad sử dụng cơ chế chống gian lận để làm cho mức độ Trustless của cầu nối chuỗi gần với xác minh gốc (Miễn là một Người theo dõi trung thực, hệ thống sẽ an toàn). Chúng tôi nhận thấy rằng ở Nomad, ba điều kiện của tam giác không thể có về khả năng tương tác chuỗi chéo đều được thỏa mãn cùng một lúc một cách kỳ diệu!

Tất nhiên, điều này không phải là không mất phí. Chi phí là sự chậm trễ hơn 30 phút, điều này có thể khiến một số loại ứng dụng nhất định không phù hợp để sử dụng Nomad để triển khai chức năng chuỗi chéo của chúng.

5.8.1.5 Ứng dụng Nomad

Nomad đã được tạo riêng Hoán đổi cầu nối và tích hợp với Connext trong cùng một giao diện. Người dùng có thể sử dụng giao diện này để tự do thực hiện trao đổi tài sản xuyên chuỗi. Nếu người dùng muốn liên kết chéo với số tiền nhỏ hơn, Connext có thể đạt được tốc độ nhanh hơn. Nếu người dùng muốn liên kết chéo với số tiền lớn hơn, Nomad có thể cung cấp mức giá thấp hơn. Cả hai bổ sung cho nhau. Chúng tôi có thể mong đợi rằng hầu hết người dùng sẽ sử dụng "kênh nhanh" - Connext, trong khi LP cung cấp thanh khoản cho "kênh nhanh" sẽ điều tiết thanh khoản trên các chuỗi khác nhau thông qua "kênh chậm" - Nomad. Điều này hoàn toàn giống với sự hợp tác giữa “kênh gốc” và “kênh nhanh” trong dự án xuyên lớp Ethereum.

Các tổ chức phát hành tài sản có thể vượt qua Nomad biến tài sản của bạn thành tài sản đa chuỗi. Ví dụ: Covalent đã di chuyển mã thông báo đặt cược mạng $CQT của họ từ Ethereum sang Moonbeam; Hummingbot đã di chuyển mã thông báo quản trị $HBOT của họ từ Ethereum sang Avalanche.

Các nhà phát triển ứng dụng có thể triển khai các ứng dụng đa chuỗi thông qua Nomad. Nomad gọi nó là xAPP (phát âm là Zap). xApp có thể gọi hợp đồng Home và hợp đồng Replica để thực hiện Gửi và nhận tin nhắn xuyên chuỗi. Các ví dụ về mã được cung cấp trong tài liệu dành cho nhà phát triển của Nomad.

Nomad cộng tác với Gnosis để phát triển Mô-đun Zodiac Nomad (ZNM), một mô-đun phổ quát tập trung vào quản trị chuỗi chéo. DAO có thể thực hiện đồng thời các quyết định quản trị trên nhiều chuỗi bằng cách triển khai ZNM trên các chuỗi được Nomad hỗ trợ.

Tính đến tháng 9 năm 2022, Nomad hỗ trợ sáu chuỗi: Ethereum, Moonbeam, Evmos, Milkomeda, Gnosis Chain và Avalanche, đồng thời chúng tôi tin rằng thiết kế chéo của Nomad cầu xích Nó mang tính đột phá. Thật không may, do lỗ hổng trong mã hợp đồng, số tiền trong hợp đồng lưu ký Nomad đã bị tin tặc cướp đi, dẫn đến thất thoát hơn 190 triệu đô la Mỹ. quỹ và chức năng cầu nối chuỗi chéo liên quan đã bị ngừng hoạt động. Chúng tôi hy vọng Nomad có thể sớm vượt qua khó khăn và đứng vững trở lại.

Cầu nối lạc quan: Một mô hình mới cho giao tiếp xuyên chuỗi

Arjun Bhuptani

Tài liệu Nomad

5.8.2 Celer IM

Được Celer xuất bản vào tháng 3 năm 2022 Trong một blog, một khung kết hợp mới Celer IM đã được đề cập, kết hợp xác minh bên ngoài và xác minh lạc quan, cho phép các ứng dụng chọn mô hình bảo mật phù hợp. Cùng xem thiết kế cụ thể nhé:

Celer IM chủ yếu bao gồm các bộ phận sau

· State Guardian Network (SGN): Đây là chuỗi khối PoS được phát triển dựa trên Cosmos SDK, với một nhóm người xác thực đặt cược $CELR, chịu trách nhiệm xác minh và ký các tin nhắn xuyên chuỗi;

· Hợp đồng Message Bus: một tập hợp các hợp đồng được triển khai trên chuỗi truy cập, chịu trách nhiệm quản lý việc gửi và nhận tin nhắn xuyên chuỗi ;

· Người thực thi: Chịu trách nhiệm chuyển tiếp các thông điệp xuyên chuỗi đã được xác minh đến chuỗi mục tiêu.

Luồng tin nhắn

1. Thẻ người dùng Ứng dụng gửi tin nhắn chuỗi chéo mà nó cần gửi đến hợp đồng Message Bus trên chuỗi nguồn;

2. Trình xác minh trong SGN lắng nghe tin nhắn và đánh giá thông báo Thực hiện chữ ký đồng thuận;

3.Người thực thi chuyển tiếp các thông điệp chuỗi chéo tới hợp đồng Message Bus trên chuỗi mục tiêu;

4. Theo mặc định, hợp đồng Message Bus trên chuỗi mục tiêu sẽ ngay lập tức đẩy nó đến ứng dụng mục tiêu để thực thi sau khi xác nhận rằng chữ ký tin nhắn là hợp lệ.

Ứng dụng có thể chọn không xử lý ngay các tin nhắn nhận được trên chuỗi chéo và thay vào đó sử dụng chế độ xác nhận kép. Ở chế độ này, sau khi tin nhắn được xác nhận một lần bởi hợp đồng Message Bus trên chuỗi mục tiêu, nó sẽ được đưa vào "cách ly". Sau một khoảng thời gian nhất định, tin nhắn có thể được coi là đã được xác nhận hai lần và được đẩy lên ứng dụng mục tiêu.chương trình.

Trong thời gian cửa sổ, ứng dụng có thể chạy dịch vụ App Guardian để kiểm tra tính xác thực của tin nhắn trong khu cách ly, nếu thấy không nhất quán với tin nhắn được gửi bởi chuỗi nguồn, nó có thể chặn thông báo Được thực thi bởi ứng dụng mục tiêu và báo cáo gian lận trong chuỗi nguồn.

Không giống như Nomad, việc báo cáo gian lận không tự động kích hoạt Slash vì trình xác thực không được đặt trên chuỗi nguồn. Nếu gian lận xảy ra, tài liệu Celer IM không giải thích cách trừng phạt và thay thế người xác minh, tác giả cho rằng cần có sự can thiệp của quy trình quản trị.

Chúng tôi thấy rằng Celer IM cung cấp hai mô hình bảo mật: xác minh bên ngoài và xác minh lạc quan. Giả định về độ tin cậy của mô hình trước là những người xác minh trung thực trong mạng SGN kiểm soát nhiều hơn 2/3 quyền biểu quyết, giả định tin cậy của quyền sau là có ít nhất một dịch vụ App Guardian trung thực đang chạy.

Thiết kế mô hình kép mang lại sự lựa chọn linh hoạt cho các nhà phát triển ứng dụng. Ví dụ: ứng dụng cầu nối tài sản có thể kích hoạt các quy trình khác nhau và triển khai các mô hình bảo mật khác nhau dựa trên giá trị của tài sản xuyên chuỗi, để các chuỗi chéo tài sản có giá trị nhỏ có thể được duy trì nhanh chóng, trong khi các chuỗi chéo tài sản có giá trị lớn có thể được duy trì nhanh chóng. được bảo vệ đầy đủ.

Bài viết giới thiệu về Celer IM 

5.8. 3 Tóm tắt về Xác minh lạc quan

Là một mô hình mới, xác minh lạc quan vượt qua tam giác bất khả thi xuyên chuỗi và trở thành lựa chọn mới để xây dựng các lớp tin cậy trong chuỗi chéo cầu. Hạn chế lớn nhất của cầu xác minh lạc quan là độ trễ trong cửa sổ thử thách, điều này sẽ ảnh hưởng xấu đến trải nghiệm của người dùng. Nhưng cả Nomad và Celer IM đều đang cố gắng giải quyết vấn đề này:

· Nomad hợp tác với Connext để cung cấp cho người dùng Fast theo dõi;

· Celer IM kết hợp xác minh tích cực với xác minh bên ngoài, cho phép các ứng dụng có yêu cầu khác nhau cung cấp cho người dùng hai tùy chọn khác nhau: xác minh một bước và xác minh hai bước;

Chúng tôi thấy rằng kịch bản ứng dụng lớn nhất của xác minh lạc quan dường như được kết hợp với các phương pháp xác minh khác, khiến người dùng phải cân nhắc giữa tính bảo mật và hiệu quả. Việc xây dựng lớp tin cậy kết hợp này có thể là một trong những hướng phát triển trong tương lai của cầu nối chuỗi chéo.

5.9 Tính tổng quát của cầu nối chuỗi

Tại thời điểm này, đã đến lúc chúng ta tóm tắt bản chất chung của cầu nối chuỗi. Các cầu nối chuỗi khác nhau có thiết kế khác nhau, nhưng về cơ bản có một cấu trúc chung, chúng ta có thể chia thành ba lớp:

·  Lớp tin cậy

· Lớp truyền tải

· Lớp ứng dụng

5.9.1 Lớp tin cậy

Đối với bất kỳ cầu nối xuyên chuỗi nào, điều đầu tiên cần giải quyết là vấn đề tin cậy trong việc truyền tải thông điệp giữa các chuỗi khác nhau. Chúng tôi đã thực hiện phân loại cơ bản nhất các loại bridge dựa trên cách xây dựng lớp tin cậy và cấu trúc của bài viết này cũng dựa trên điều này.

Đối với các cầu nối xác minh gốc, lớp tin cậy là chương trình khách hàng nhẹ trên chuỗi và Người chuyển tiếp chính chịu trách nhiệm phân phối tiêu đề khối;

Đối với cầu nối xác thực bên ngoài, lớp tin cậy là mạng PoA/PoS hoặc mạng Oracle bên ngoài;

Đối với xác thực cục bộ Đối với bridge, lớp tin cậy là chính quá trình giao dịch;

Đối với bridge xác minh lạc quan, lớp tin cậy là người quan sát chịu trách nhiệm báo cáo gian lận.

5.9.2 Lớp vận chuyển

Sau khi xác định cách xây dựng lớp tin cậy, lớp vận chuyển layer Thiết kế đã trở thành điểm nhấn của cây cầu xuyên xích. Một số cầu nối chuỗi chéo đã xây dựng một lớp vận chuyển tương đối hoàn chỉnh, trong khi lớp vận chuyển của một số cầu nối chuỗi tương đối đơn giản và nhiều vấn đề về lớp vận chuyển được giao cho lớp ứng dụng thiết kế. Lớp vận chuyển tương đối hoàn chỉnh giúp các ứng dụng truy cập dễ dàng hơn.

Nhiệm vụ cơ bản của lớp vận chuyển là xây dựng thứ tự truyền tin nhắn, quản lý thời gian và trạng thái của tin nhắn và liệu nó có phải là một mạng đa chuỗi hay không. xuyên chuỗi, nó cũng phải quản lý địa chỉ của tin nhắn và định tuyến để phát triển một định dạng tin nhắn thống nhất. Lớp vận chuyển thường bao gồm một tập hợp các hợp đồng thông minh trên chuỗi chịu trách nhiệm quản lý hàng đợi tin nhắn và một tập hợp logic cập nhật trạng thái tin nhắn. Các cầu nối chuỗi khác nhau có tên khác nhau cho nhóm hợp đồng thông minh trên chuỗi này, nhưng chức năng của chúng giống nhau.

Cách hiểu các thông điệp chuỗi chéo

Các kịch bản ứng dụng chuỗi chéo có thể đa dạng, bao gồm

· Cuộc gọi hợp đồng chuỗi chéo: Một chuỗi gọi một hợp đồng trên chuỗi khác để thực hiện một chức năng nhất định và trả về kết quả thực hiện

· Tính toán chuỗi chéo: lấy tham số trên nhiều chuỗi làm đầu vào và tính toán một giá trị làm đầu vào của ứng dụng

· Thực thi quản trị chuỗi chéo: đồng bộ hóa kết quả biểu quyết quản trị của ứng dụng trên một chuỗi để thực thi trên nhiều chuỗi

· Ánh xạ nội dung chuỗi chéo: Truyền thông báo rằng nội dung bị khóa trên chuỗi này sang chuỗi khác, kích hoạt quá trình truyền nội dung được ánh xạ

Nhưng bản chất hoặc phương pháp thực hiện của tất cả các kịch bản là truyền tải các thông điệp xuyên chuỗi. Nghĩa là, nếu có thể đạt được việc truyền tải thông điệp đáng tin cậy giữa các chuỗi, ở trên Tất cả các kịch bản ứng dụng chuỗi chéo đều có thể được hiện thực hóa.

Bản chất của các thông điệp xuyên chuỗi là những gì xảy ra trên một chuỗi, được phản ánh trong một hoặc nhiều giao dịch. Tất nhiên, từ “giao dịch” không nhất thiết có nghĩa là Với việc chuyển giao tài sản, "giao dịch" trong blockchain thường đề cập đến bất kỳ hình thức chuyển đổi trạng thái nào. Cầu nối chuỗi chéo sẽ phát triển một định dạng thống nhất cho thông báo, định dạng này sẽ bao gồm siêu dữ liệu có liên quan của "giao dịch", thông tin nhận xét (tải trọng) được ứng dụng viết cho giao dịch, v.v. Đối với cầu nối chuỗi chéo gốc, hay cầu nối chuỗi chéo sử dụng cấu trúc cây thông điệp, Chain Bridge, tin tức cũng bao gồm cả con đường “giao dịch” của Merkel.

Luồng thông điệp

Thông điệp xuyên chuỗi Việc truyền tải thường trải qua quá trình này:

1. Ứng dụng gửi tin nhắn được định dạng tới hợp đồng quản lý hàng đợi gửi trên chuỗi nguồn;

2. Tin nhắn được gửi đến hợp đồng quản lý hàng đợi nhận trên chuỗi mục tiêu. Tất nhiên, tin nhắn phải được xác minh bởi lớp tin cậy, có thể là trước khi được gửi đến chuỗi mục tiêu hoặc trong quá trình phân phối. Sau khi đến chuỗi mục tiêu;

3. Hợp đồng quản lý hàng đợi nhận trên chuỗi mục tiêu sẽ chuyển tiếp tin nhắn đã được xác minh tới ứng dụng đích để thực thi

4. Việc nhận được thực thi tin nhắn thành công sẽ được trả về chuỗi nguồn và trạng thái của tin nhắn trong hàng đợi gửi được cập nhật để gửi hoặc xóa trực tiếp.

Cấu trúc hàng đợi tin nhắn

Hầu hết Hàng đợi tin nhắn của cầu chuỗi là hàng đợi của tin nhắn gốc. Một số cầu nối chuỗi chéo sẽ xây dựng cây thông báo dựa trên hàng đợi tin nhắn để tạo thành hàng đợi giá trị gốc, chẳng hạn như Hyperlane, Nomad và XCMP. Điều này có thể tách biệt truyền giá trị gốc và thông báo Truyền văn bản gốc để đạt được khả năng chống kiểm duyệt và chống giả mạo tin nhắn, đồng thời giảm tải cho lớp truyền giá trị gốc.

Kênh 

Trong một số chuỗi chéo đa chuỗi bridge , còn có khái niệm về Kênh. Khái niệm về Kênh là hư cấu và bản chất của nó là một cặp hàng đợi tin nhắn được xây dựng trên hai chuỗi. Ý nghĩa của sự tồn tại của khái niệm Kênh là

· Tổ chức thời gian gửi tin nhắn: các tin nhắn bên trong Kênh sẽ có mối quan hệ về thời gian. Các tin nhắn giữa nhau không có thuộc tính thời gian;

· Quản lý quyền gửi và nhận tin nhắn: Tin nhắn không thể được truyền giữa chuỗi không có Kênh. Nếu một chuỗi không muốn chấp nhận tin nhắn từ chuỗi khác, chuỗi đó có thể từ chối mở Kênh tương ứng.

Các cầu nối chuỗi chéo bao gồm khái niệm Kênh bao gồm Cosmos, XCMP và Nomad, nhưng thiết kế tương ứng của chúng khác nhau. Trong Comsos, các Kênh được thiết lập giữa các ứng dụng (Các kênh được thiết lập giữa các chuỗi được gọi là Kết nối) và mang tính hai chiều. Việc thiết lập Kênh giữa hai chuỗi có nghĩa là cả hai có thể truyền tin nhắn theo cả hai hướng. Nhưng trong XCMP và Nomad, Kênh là một chiều và việc truyền chuỗi chéo hai chiều yêu cầu một cặp hai Kênh. Trong XCMP, một Kênh tương ứng với một hàng đợi tin nhắn đầu ra Egress; nhưng trong Nomad, nhiều Kênh tương ứng với một hàng đợi tin nhắn đầu ra (Hợp đồng nhà), có nghĩa là hợp đồng Home của Nomad quản lý tất cả các tin nhắn được gửi từ chuỗi. Đích đến không được phân biệt ( trường đích nằm trong nội dung thư), cho phép Nomad hỗ trợ chế độ truyền tin nhắn một đến nhiều.

5.9.3 Lớp ứng dụng

Lớp ứng dụng thường chỉ có trong các cầu AMB. Cầu AMB thường cung cấp một tập hợp các thành phần cho ứng dụng. Các ứng dụng tích hợp các thành phần này và gọi các mô-đun có liên quan để gửi và nhận tin nhắn xuyên chuỗi. Nếu cầu nối chuỗi chéo được chạy như một ứng dụng độc lập thì nó không cần phải xem xét việc tạo điều kiện thuận lợi cho việc truy cập của các ứng dụng khác.

5.9.4 Lớp khuyến khích

Cho dù đó là lớp tin cậy hay lớp vận chuyển, nó có thể Các vấn đề liên quan đến ưu đãi. Chúng ta cũng có thể lấy nó ra và thảo luận về nó như một lớp mới.

· Khuyến khích lớp tin cậy: Đối với các cầu nối chuỗi chéo gốc, Relayer cần được khuyến khích gửi tiêu đề khối để duy trì ánh sáng khách hàng; đối với cầu nối xác minh bên ngoài (PoS), người xác thực cần được khuyến khích thực hiện nhiệm vụ của mình một cách trung thực; đối với cầu nối xác minh lạc quan, người quan sát cần được khuyến khích thực hiện nhiệm vụ của mình một cách trung thực; đối với cầu nối xác minh địa phương, đối tác công cần được khuyến khích để cung cấp đủ thanh khoản.

· Ưu đãi của lớp vận chuyển: Các nhân vật có liên quan cần được thúc đẩy để gửi thông điệp chuỗi chéo đến chuỗi mục tiêu và nâng cao thông điệp chuỗi chéo xác minh và thực thi trên chuỗi mục tiêu.

Các phương pháp khuyến khích có thể đa dạng, có thể là phí của người dùng được trả trực tiếp cho đối tượng khuyến khích hoặc bên dự án cầu nối chuỗi sử dụng kho bạc riêng của mình Hoặc phần thưởng lạm phát được sử dụng để trợ cấp cho các đối tượng khuyến khích, một tình huống khác là lớp ứng dụng xây dựng các quy tắc khuyến khích cho các đối tượng khuyến khích hoặc lớp ứng dụng trực tiếp nhận trách nhiệm của các đối tượng khuyến khích.

5.9.5 Tóm tắt

Ở trên, thông qua việc phân loại, ví dụ và phân tích các cầu nối chuỗi chéo, chúng ta hiểu sâu hơn về cách xây dựng các cầu nối chuỗi chéo. Đây là bài viết thứ ba trong loạt báo cáo nghiên cứu chuỗi chéo PAKA. Chúng tôi sẽ sớm xuất bản phần thứ tư và phần cuối cùng. Trong bài viết cuối cùng, chúng tôi sẽ tập trung vào việc triển khai một số lớp ứng dụng, đặc biệt là Cầu quấn, Cầu hoán đổi và các loại ứng dụng DeFi chuỗi chéo khác, sau đó thảo luận thêm về một số đề xuất quan trọng có nguồn gốc từ chuỗi chéo.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia