Định hình các giao thức Cross-Chain Messaging

Nội dung chính

• Các giao thức truyền thông điệp cross-chain (cross-chain messaging protocol) tổng quát sẵn sàng tạo nên bước ngoặt có hệ thống về cách chúng ta thiết kế các ứng dụng multichain. Thay vì xuất (export) token, các mạng smart contract sẽ nhập (import) các hướng dẫn thực thi để chạy trên tài sản bảo đảm của mạng.
• Inter-Blockchain Communication (IBC) Protocol, Axelar, Nomad, LayerZero và Chainlink CCIP chứng minh nhiều giả định tin cậy (trust assumption) mà các giao thức truyền thông điệp cross-chain có.
• Vì các giả định tin cậy vốn đã được đưa vào trong thiết kế cross-chain, các nhà phát triển phải hiểu các rủi ro đặc biệt mà mỗi giao thức chứa đựng.

“Tôi cực kỳ ghét những cầu nối bị hỏng. Tôi chỉ đơn giản là không thể chấp nhập được điều đó. ” – bất kỳ người dùng crypto multichain nào từ trước đến nay đều như vậy.

Bối cảnh multichain của crypto vẫn đang là một mớ hỗn độn. Việc thiếu công cụ và các tiêu chuẩn hoạt động cơ bản đã không khuyến khích các nỗ lực của nhà phát triển trong khi thanh khoản bị phân mảnh và giao diện người dùng lộn xộn gây đau đầu cho người dùng cuối. Chưa kể hầu hết mọi thành phần trong cơ sở hạ tầng dường như được xây dựng dựa trên các giả định tin cậy mỏng manh bị che khuất khỏi ​​người dùng cuối.

Được tài trợ

Chúng ta thậm chí không thể trải qua một tháng trọn vẹn mà không chứng kiến một cầu nối (bridge) trở thành nạn nhân của một vụ khai thác lỗ hổng gây tổn thất hàng triệu USD.

Bất chấp tất cả các cách mà những vấn đề này hình thành, chúng có chung một nguyên nhân gốc rễ đó là các blockchain không cần cấp phép không có khả năng tham gia vào các giao tiếp cross-chain ngoài mạng. Đây là hệ quả của bản chất không cần tin cậy; để xử lý bất kỳ thông điệp (message) nào, một blockchain cần có cách để xác minh tính xác thực.

Điều này dễ dàng trong một hệ sinh thái đồng nhất như Polkadot, nơi mỗi chain riêng được kết nối với trung tâm chia sẻ về an ninh kinh tế (economic security). Nhưng đối với các blockchain không đồng nhất (heterogenous) với các bộ quy tắc và đảm bảo bảo mật khác nhau, điều này khó hơn nhiều. Trên thực tế, không thể thực hiện điều này mà không liên quan đến bên thứ ba đáng tin cậy hoặc trực tiếp xác minh lịch sử mạng bên ngoài.

Đây là lúc các giao thức truyền thông điệp cross-chain phát huy tác dụng. Một số thiết lập khuôn khổ cho các thỏa thuận giao tiếp hai chiều trong khi những bên khác đóng vai trò thông dịch viên của bên thứ ba cho các chain khác nhau. Bất kể cấu trúc như thế nào, thì tất cả đều có chung một mục đích là cho phép truyền các thông điệp cross-chain tùy ý giữa các chain với các giả định tin cậy khác nhau.

Như chúng ta sẽ thấy, những giả định tin cậy này sẽ quyết định cách rủi ro biểu hiện qua các mô hình cross-chain khác nhau.

Hiểu về Cross-Chain Messaging

Cho đến nay, các nỗ lực cross-chain trong crypto chủ yếu tập trung vào việc chuyển một cấu trúc thông điệp cross-chain cụ thể: token. Nhưng cũng như nhiều tiến bộ tích lũy trong crypto, tiềm năng lâu dài cho giao tiếp cross-chain không chỉ đóng vai trò là công cụ giúp những người nghiện cờ bạc có quyền truy cập vào sòng bạc kỹ thuật số hấp dẫn nhất.

Quay trở lại các nguyên tắc đầu tiên, ngày càng có nhiều giao thức cross-chain tổng quát xuất hiện cho phép chuyển bất kỳ dạng dữ liệu tùy ý nào giữa các chain với nhau. Những cầu nối sẽ tiếp tục tồn tại và sẽ dễ dàng được cấu trúc lại trên những hạ tầng giao tiếp mới này. Tuy nhiên, điều này có thể thay đổi đáng kể cách chúng ta tiếp cận khả năng tương tác của blockchain.

Nguồn: 0xpostman

Thay vì xuất token, các mạng smart contract sẽ nhập các hướng dẫn thực thi để chạy trên tài sản bảo đảm của mạng. Trọng tâm có thể chuyển từ việc đẩy giá trị ra khỏi mạng thay vào đó là kéo logic thực thi vào hệ thống.

Đây là một vấn đề lớn. Các cross-chain smart contract sẽ định hướng lại hiểu biết của chúng ta về hệ thống vận hành interchain. Kết nối quan trọng này cho phép các nhà phát triển phát triển thế mạnh vượt trội của mình: xây dựng các ứng dụng có thể kết hợp. Trong một tương lai không xa, người dùng có thể được hưởng những lợi ích sau:

• Hệ thống quản trị thống nhất trên nhiều chain (cross-chain DAOs)
• Các dịch vụ DeFi tổng hợp bao gồm (nhưng không giới hạn) yield farming và cho vay thế chấp cross-chain
• Super wallets: một địa chỉ có thể kiểm soát các tài khoản phụ trên nhiều chain khác nhau

Các lợi ích trên chưa đầy đủ. Cũng giống như khả năng tổng hợp của ứng dụng đã tạo ra một làn sóng đổi mới trong các blockchain đồng bộ, khả năng tổng hợp sẽ một lần nữa tạo ra sự đổi mới trên các mạng không đồng bộ.

Điều quan trọng cần lưu ý là có rất nhiều giao thức đang nghiên cứu về giao tiếp cross-chain. Do đó, các giao thức sau đây không bao gồm tất cả các mô hình cross-chain. Các định nghĩa sau đây sẽ hỗ trợ trong bài phân tích này.

• An ninh kinh tế đảm bảo rằng giá trị bị mất từ một cuộc tấn công hệ thống cao hơn giá trị có thể thu được. Điều này có thể được đo lường một cách định lượng.
• Sự an toàn là việc hệ thống hoạt động như dự định và không bị kẻ xấu lợi dụng. Sự an toàn bị đe dọa khi việc duy trì an ninh kinh tế thất bại.
• Liveness là trạng thái mà tất cả các thành phần của hệ thống đang chủ động thực hiện chức năng của mình. Liveness cũng có thể được coi là đối lập với downtime, được đo lường một cách xác định (đúng hoặc sai).

IBC

Inter-Blockchain Communication Protocol (IBC) là một framework cho phép các blockchain không đồng nhất thiết lập các kết nối cross-chain mà không cần thêm các giả định tin cậy từ bên thứ ba. Các chain tham gia đồng ý tin tưởng các mô hình bảo mật của nhau và sử dụng tiêu chuẩn truyền thông điệp cross-chain chia sẻ để liên lạc và xác minh các thay đổi trạng thái.

Điều này cho phép các thông điệp IBC kế thừa mức độ an toàn thấp nhất của các chain cơ sở.

Việc thiết lập kết nối an toàn này tiêu tốn nhiều tài nguyên cho cả hai chain. Khi một thông điệp cross-chain được khởi tạo trên chain nguồn, một relayer không cần cấp phép sẽ chuyển một bằng chứng light client về yêu cầu thông điệp cross-chain đến chain đích.

Để xác thực bằng chứng này, chain đích phải chạy một light client để đọc trạng thái của chain nguồn và tạo một bản ghi (record) trạng thái này trên sổ cái của mình. Quy trình xác thực trực tiếp này đảm bảo với chain đích rằng yêu cầu của chain nguồn thực sự hợp lệ trước khi thực thi yêu cầu ở trạng thái riêng của mình.

Bằng cách tối ưu hóa để đảm bảo an toàn, thiết kế của IBC tạo ra một số điểm đánh đổi đáng chú ý.

1. Chain đích phải giả định rằng yêu cầu giao dịch đã được hoàn tất trên chain gửi. Các fork và block reorg phổ biến trên các chain có tính cuối cùng (finality) theo xác suất (chẳng hạn như Ethereum) sẽ phá vỡ các đảm bảo bảo mật của IBC.
   • Vì lý do này, IBC chỉ tương thích với các cơ chế đồng thuận có đảm bảo tính cuối cùng mạnh mẽ như Tendermint. “Peg zones” có thể được sử dụng như một giải pháp thay thế để thiết lập ngưỡng cuối cùng khi kết nối với một chain có xác suất cuối cùng. Tuy nhiên, sự thích ứng này làm tăng độ phức tạp của hệ thống và do đó tạo ra thêm các cuộc tấn công attack vector.
2. Mô hình IBC tiết kiệm chi phí cho các blockchain có thông lượng thấp và block space đắt đỏ. Đây không phải là vấn đề trong hệ sinh thái Cosmos – IBC được thiết kế để hoạt động nguyên bản trong các chain được xây dựng trên Cosmos SDK nơi các mô-đun IBC chạy ở cấp độ mạng chứ không phải cấp độ smart contract. Hơn nữa, IBC cho phép các chain dựa trên Cosmos chuyển chi phí và trách nhiệm của việc duy trì trạng thái on-chain của các chain khác từ các ứng dụng sang validator của mạng.
3. Các relayer sẽ thay người dùng chịu phí giao dịch để chuyển thông điệp cross-chain. Tuy nhiên, sự đánh đổi này cho phép việc chuyển tiếp trở thành hàng hóa công cộng (public good) cho người dùng mạng. Các relayer thường được vận hành bởi các validator được khuyến khích để giữ cho cả hai mạng hoạt động. Tính kinh tế của IBC giúp relayer phối hợp xã hội một cách hợp lý và chỉ có một dịch vụ relayer trên mỗi kênh IBC cùng một lúc.
   • Nếu không có relayer nào đang phục vụ một kênh, các thông điệp cross-chain sẽ bị kẹt cho đến khi relayer gửi chúng. Mặc dù điều này không ảnh hưởng đến sự an toàn tổng thể của cả hai chain, nhưng liveness có thể tạm thời bị giảm đối với giao tiếp cross-chain. Để liveness thất bại, ⅓ trong số validator set của chain sẽ cần phải thông đồng với nhau hoặc chuyển sang offline để làm chain cơ sở tạm dừng hoạt động.

Nhìn chung, IBC cho phép các chain được kết nối hoạt động như read-oracle phi tập trung cho nhau. Các biện pháp an toàn sử dụng nhiều tài nguyên của mình cho phép IBC thực hiện truyền thông điệp cross-chain mà không cần dựa vào các bên thứ ba để sửa đổi các giả định tin cậy nhằm bảo đảm an toàn cho các chain cơ sở. Vì lý do này, IBC được chấp nhận rộng rãi như là tiêu chuẩn cho việc so sánh giao tiếp cross-chain.

Axelar

Axelar tạo điều kiện cho việc truyền thông điệp cross-chain bằng cách tạo ra một proof-of-stake (PoS) blockchain khác được xây dựng trên Cosmos SDK. Mạng được thiết kế bằng cách sử dụng mô hình hub-and-spoke cho phép từ một đến nhiều kết nối cross-chain.

Axelar hub kết nối với các chain không đồng nhất bằng cách sử dụng các “cổng hay gateway” chuyên biệt. Những spoke này có thể được thực hiện dưới dạng smart contract ở cấp ứng dụng hoặc có thể tương tác với các chức năng cấp mạng như IBC trong Cosmos hoặc hệ thống tính toán đa bên (multi-party computation system) trong Bitcoin.

Các yêu cầu truyền thông điệp cross-chain đến cổng Axelar được chuyển đến các validator trong Axelar hub. Cũng như với IBC, các relayer không cần cấp phép và mạng yêu cầu ít nhất một relayer để đảm bảo liveness cho kết nối liên quan.

Các validator của Axelar cần chạy một light client hoặc full node cho ít nhất một chain bên ngoài để cung cấp bản ghi cục bộ về các trạng thái. Nếu một ngưỡng tối thiểu của các node này không được đáp ứng, kết nối liên quan sẽ mất liveness vô thời hạn.

Các Axelar validator riêng lẻ sử dụng kiến thức của mình về các trạng thái mạng bên ngoài này để bỏ phiếu chung cho các yêu cầu truyền thông điệp cross-chain được chuyển tiếp và thực hiện chuyển đổi trạng thái để đưa các giao dịch đến chain đích.

Quá trình bỏ phiếu đồng thuận kết hợp cơ chế bonded PoS với threshold signature scheme (TSS). Tương tự như multisig, để yêu cầu được chấp thuận TSS cần đạt ngưỡng signing power tối thiểu.

Một điểm khác biệt chính của mô hình TSS là các private key được kết hợp trước khi ký để tạo thành một chữ ký duy nhất.  Điều này cho phép validator set mở rộng quy mô mà không làm tăng chi phí chung của việc xác minh chữ ký liên quan đến việc mở rộng một hệ thống tương tự mà thay vào đó là sử dụng multisig.

Các private key mới kết hợp để tạo ra chữ ký TSS được tạo và phân bổ bất cứ khi nào có sự luân chuyển validator set xảy ra. Điều này tạo thêm một rào cản khác để hạn chế bị tấn công nhưng cũng làm tăng thêm rủi ro thực thi liên tục cho hệ thống. Ngưỡng tối thiểu để phê duyệt các yêu cầu truyền thông điệp cross-chain khác nhau tùy thuộc vào chain đích, cho phép kết nối của mỗi chain có các thông số bảo mật duy nhất.

Lưu ý cuối cùng về cấu trúc của Axelar là blockchain này chỉ lưu trữ thông tin được liên kết với các gateway contract và các giao dịch cross-chain. Nghĩa là trạng thái của mạng sẽ chỉ tăng với số lượng yêu cầu cross-chain mà mạng tạo điều kiện thay vì kích thước của tất cả các chain được kết nối.

Chi tiết hơn, mạng Axelar trông giống như một bộ não cho tất cả các mạng blockchain không đồng nhất. Gồm cả chức năng đọc và ghi, Axelar tổng hợp nhiều đầu vào không xác định và sử dụng chúng để tính toán một đầu ra xác định duy nhất biểu hiện dưới dạng các quyết định có/không đơn giản. Axelar tự hào có một tập hợp các dịch vụ ấn tượng sẽ hấp dẫn các nhà phát triển giúp họ tận dụng làm cơ sở cho các ứng dụng cross-chain.

• Hỗ trợ gốc IBC cung cấp một giải pháp khác cho hệ sinh thái Cosmos đang phát triển để tương tác với các chain thiếu cơ chế đồng thuận cuối cùng tức thời (immediate finality consensus mechanism).
• TSS sẽ cho phép hệ thống định cấu hình ngưỡng đồng thuận xác suất trên cơ sở từng chain.
• Mô hình hub-and-speak cho phép số lượng kết nối cần thiết mở rộng tuyến tính với số lượng chain được hỗ trợ. Trong một thế giới mà hiệu ứng mạng được sử dụng nhiều vô kể, đây sẽ là một lợi thế khác biệt so với các thiết kế dựa trên kết nối theo cặp (pairwise connection).

Mô hình của Axelar có một nhược điểm đáng chú ý trong ngắn hạn có thể làm mất đi tiềm năng mở rộng quy mô của mạng. Mô hình bonded PoS bảo vệ Axelar hub hạn chế khả năng mở rộng quy mô của mạng hơn từ góc độ an ninh kinh tế – nếu giá trị cổ phần của mạng thấp hơn giá trị của tài sản được bảo đảm bởi mạng, hệ thống sẽ dễ bị tấn công.

Tuy nhiên, thực tế Axelar được xây dựng trên Cosmos SDK cung cấp một giải pháp tiềm năng. Các kế hoạch của Cosmos để kích hoạt Interchain Security có thể cho phép Axelar thuê ngoài (outsource) một phần an ninh kinh tế của mình cho một hệ sinh thái của các chain Cosmos.

Điều này dẫn đến những rủi ro dài hạn mà thành công của Axelar có thể mang lại đối với nền kinh tế crypto nói chung. Cấu trúc toàn diện của Axelar khiến mạng trở thành điểm thất bại trong trung tâm của multichain universe. Không giống như các node riêng lẻ trong mạng phân tán, Axelar’s hub chỉ tồn tại dưới dạng một trường hợp duy nhất.

Nếu bảo mật của mạng bị xâm phạm bằng cách chiếm được ⅔ cổ phần của validator, thì các tác nhân độc hại sẽ có khả năng tấn công vào mọi chain được hỗ trợ. Vì cổ phần của mạng được tách biệt khỏi cả chain nguồn và chain đích, sẽ không có cách nào để thực thi việc tác động khi kẻ tấn công nắm quyền kiểm soát (kẻ tấn công sẽ cần phải cắt giảm giá trị cổ phần của chính mình).

Rủi ro về cấu trúc cũng ảnh hưởng đến liveness. Nếu ⅓ cổ phần của Axelar offline và mạng ngừng hoạt động, sự tồn tại của tất cả các kết nối của mạng sẽ không thành công.

Nếu chúng ta đã học được bất cứ bài học gì từ việc khai thác cross-chain trước đây và tác động dây chuyền gần đây từ các vụ sụp đổ của các dự án hàng đầu, thì rủi ro phân tán là một thành phần bắt buộc đối với các hệ thống kinh tế crypto có khả năng phục hồi.

Việc khôi phục chain là không khả thi trong một thế giới multichain. Nếu Axelar thành công trong việc áp dụng hàng loạt, thị trường crypto có thể buộc phải đối mặt với tình huống quá lớn để có thể sụp đổ (too-big-to-fail) của chính mình.

Nomad

Nomad là một hệ thống xử lý và mở rộng Optics Bridge của giao thức Celo. Trong khi cả hai đều sử dụng các mô hình gần giống nhau, nhưng chỉ có Nomad sẽ được đảm bảo do có mối quan hệ đối tác đặc biệt với Connext.

Nomad lật tẩy lý thuyết trò chơi về các giả định tin cậy cross-chain bằng cách sử dụng một optimistic model. Thay vì xác minh rằng mỗi yêu cầu truyền thông điệp cross-chain là hợp lệ theo cách chủ động, Nomad giả định rằng mọi yêu cầu truyền thông điệp là đúng trong khi outsourcing giao gánh nặng xác minh cho off-chain Watcher. Điều này cho phép Nomad hoạt động tương tự như các optimistic rollup.

Các thông điệp cross-chain khởi tạo từ chain nguồn được băm (hash) và chèn vào Merkle tree trong “Home” smart contract của chain. Một tác nhân bonded off-chain được gọi là “Updater” ký Merkle root này và chuyển bằng chứng cho relayer không cần cấp phép để chuyển sang “Replica” smart contract trên chain đích.

Sau khi xác minh chữ ký của updater, thông điệp cross-chain sẽ đi vào challenge period kéo dài khoảng 30 phút. Tại đây, off-chain Watcher sử dụng bằng chứng gian lận (fraud proof) để gửi các challenge đến Home của nguồn nếu họ chứng kiến các thông điệp gian lận có chữ ký của Updater.

Chỉ cần một Watcher gửi bằng chứng gian lận hợp lệ để cắt đảm bảo của của Updater, do đó làm tăng độ an toàn cho giao thức cross-chain. Nếu challenge period (thời gian thách thức) của thông điệp cross-chain trôi qua mà không có challenge, Replica sẽ thực thi truyền thông điệp trên chain đích.

Mô hình innocent-until-proven-guilty của Nomad đưa một biến mới vào phương trình cross-chain: độ trễ (latency). Mặc dù điều này có vẻ như là một bug, nhưng Nomad tin rằng nó thực sự có thể là một tính năng cần thiết cho giao tiếp cross-chain – challenge period 30 phút cung cấp một cách để hạn chế thiệt hại tài sản thế chấp cho các ứng dụng trong trường hợp có sự thôn tính thù địch (hostile takeover).

Như đã nhấn mạnh trong phần Axelar, rủi ro ảnh hưởng dây chuyền phải được xem xét trước khi lựa chọn giải pháp tương tác để tránh thảm họa xảy ra.

Khoảng thời gian chờ (latency period) cũng cho phép các giao thức khác xây dựng trên Nomad để đáp ứng nhu cầu của người dùng về tính hoàn thiện cross-chain nhanh hơn.

Vào tháng 1 năm 2022, Nomad đã hợp tác với Connext để kích hoạt “modular interoperability stack”. Connext hoạt động như một layer thanh khoản trên hệ thống truyền thông điệp cross-chain của Nomad. Connext cung cấp cho người dùng thanh khoản tức thì để chuyển tài sản và có khả năng thực thi một số lệnh gọi smart contract nhất định mà không cần đưa thêm các giả định tin cậy vào hệ thống.

Để đổi lấy rủi ro thông điệp cross-chain của ứng dụng bị chứng minh là gian lận, Connext thu một khoản phí nhỏ cho mỗi giao dịch. Điều quan trọng cần lưu ý là không phải tất cả các thông điệp đều có thể được hưởng lợi từ dịch vụ này. Các lệnh gọi được cấp phép hoặc các thông điệp cross-chain phải đến từ một thực thể cụ thể (chẳng hạn contract upgrade được DAO ủy quyền), buộc phải chờ qua giai đoạn optimistic challenge.

Ngoài độ trễ, các lựa chọn thiết kế của Nomad còn có một số điểm đánh đổi đáng chú ý khác.

1. Việc sử dụng một Updater đơn lẻ làm giảm các tài nguyên cần thiết để xác minh trạng thái. Nếu Updater gặp phải downtime, sẽ xảy ra lỗi liveness trên outbound channel. Nomad đã có kế hoạch giảm thiểu điều này bằng cách thêm downtime slashing cho các Updater cùng với mô hình Updater rotation cho phép các Updater dự phòng tham gia.
2. Vai trò của Watcher gồm cả yếu tố tin cậy và không tin cậy do cách Nomad xử lý gian lận. Về mặt lý thuyết, bất kỳ ai cũng có thể đóng vai Watcher và cắt giảm gian lận của Updater một cách không cần cấp phép trên chain nguồn. Điều này là do chain nguồn có kiến thức về yêu cầu truyền thông điệp ban đầu mà chain có thể sử dụng để xác minh bằng chứng gian lận.
   • Tuy nhiên, vì chain đích không có cách nào để xác minh yêu cầu truyền thông điệp ban đầu (vì thông điệp được tạo trên chain nguồn), nên chain đích phải tin tưởng rằng mọi bằng chứng gian lận mà mình nhận được là hợp lệ. Tác nhân độc hại có thể khai thác điều này để kiểm duyệt các thông điệp trên chain đích bằng cách gửi thông điệp rác vào chain đó với các bằng chứng gian lận không hợp lệ, do đó yêu cầu vai trò Watcher phải được thực hiện bởi một bên được cấp phép.
3. Vì lý do này, Nomad nhấn mạnh rằng một Watcher phải được khuyến khích phù hợp với các ứng dụng mà họ phục vụ. Giả sử Nomad hoặc bất kỳ giao thức nào được xây dựng trên Nomad sẵn sàng chạy một Watcher trung thực, thì điều này sẽ không thành vấn đề khi xem xét sự tồn tại của Watcher phụ thuộc vào việc các ứng dụng chuyển giao dịch thành công qua hệ thống.
   • Tuy nhiên, một watcher set giới hạn hiển nhiên sẽ giúp updater dễ dàng mua chuộc Watcher của mình để được thông qua. Cuối cùng, hệ thống sẽ cần ít nhất một Watcher trung thực (có thể là Nomad) trực tuyến và chống lại bất kỳ nỗ lực hối lộ nào như vậy.
4. Nomad tập trung hoàn toàn vào việc kết nối các chain dựa trên EVM và các giải pháp mở rộng quy mô Ethereum. Điều này giới hạn tổng thị trường có thể định địa chỉ của Nomad theo cách tương tự như IBC với các chain cuối cùng tức thời.
   • Các Home contract của Nomad được tổng quát hóa để các chain nguồn có thể gửi thông điệp đến bất kỳ Replica contract nào từ một outpost duy nhất. Tuy nhiên, các chain đích cần một Replica contract duy nhất để nhận thông điệp từ mọi chain nguồn được hỗ trợ. Như với IBC, điều này dẫn đến mối quan hệ theo cặp cho các kết nối mở rộng.

Nhìn chung, trọng tâm Ethereum-centric của Nomad là một sự đặt cược tập trung rằng mạng sẽ tiếp tục là trung tâm hàng đầu (Schelling point) để phát triển ứng dụng. Bằng cách cho phép các giao thức cross-chain khác đáp ứng nhu cầu về độ trễ của dịch vụ trên cơ sở hạ tầng optimistic messaging, Nomad có thể thiết lập một hào phòng vệ (moat) tương tự như hệ sinh thái rollup với các tích hợp ứng dụng đáng kể.

Khi các giải pháp mở rộng quy mô Ethereum mới tiếp tục ra đời, Nomad sẽ có vị thế hoàn hảo để tận dụng nhu cầu tự nhiên của các ứng dụng này để truyền thông điệp cross-rollup.

LayerZero và Chainlink CCIP

Do sự chồng chéo chặt chẽ, LayerZero và Cross-Chain Interoperability Protocol (CCIP) của Chainlink sẽ được thảo luận cùng nhau. 

LayerZero

LayerZero là modular framework cho khả năng tương tác tổng quát. Cho phép các ứng dụng lựa chọn các giả định về độ tin cậy trên cơ sở mỗi giao dịch và tận dụng một mô hình đơn giản chỉ bao gồm một off-chain oracle, một off-chain relayer và một tập hợp các on-chain Endpoint smart contract.

Giao thức chuyển trách nhiệm khai báo các nhà cung cấp oracle và chuyển tiếp cụ thể từ chính giao thức sang ứng dụng chạy trên framework của mình. Để hỗ trợ quá trình ra quyết định, LayerZero khuyến nghị các ứng dụng outsource trách nhiệm oracle cho Chainlink trong khi vận hành relayer của chính mình như một hàng hóa công cộng. Trong cách triển khai hiện tại, LayerZero dựa trên một oracle được vận hành bởi FTX, Polygon và Sequoia.

Các ứng dụng gửi các giao dịch đến Endpoint của chain để bắt đầu yêu cầu truyền thông điệp cross-chain. Sau đó, Endpoint yêu cầu nhà cung cấp oracle đã chọn lấy block header tương ứng từ chain nguồn và chuyển nó đến Endpoint trên chain đích.

Endpoint của chain nguồn sẽ đồng thời tạo ra bằng chứng giao dịch để relayer chuyển đến Endpoint của chain đích.  Sau đó, block header của oracle và bằng chứng của relayer được đối sánh và xác minh cùng với Endpoint của chain đích trước khi thông điệp được gửi on-chain. Cả oracle và relayer đều được chi trả trên cơ sở mỗi giao dịch bởi người truyền thông điệp trên chain nguồn.

LayerZero tự nhận là “giao thức tương tác không cần tin cậy hay trustless interoperability protocol” đầu tiên. Tuyên bố này được chứng minh trên cơ sở oracle và relayer không thông đồng để làm tổn hại đến sự an toàn trong thông điệp của người gửi.

Tuy nhiên, điều này có thể gây hiểu lầm vì kẻ tấn công xâm nhập thành công mạng oracle có thể chỉ cần chạy relayer của họ để “thông đồng”, thúc đẩy các giao dịch qua mạng và xâm phạm sự an toàn. Do đó, người gửi thông điệp cross-chain buộc phải tin tưởng vào nhà cung cấp oracle để đảm bảo an toàn.

Mặc dù ứng dụng có thể chạy relayer của riêng mình để đảm bảo việc truyền thông điệp diễn ra đúng, nhưng điều này phủ nhận lợi ích chi phí của việc sử dụng dịch vụ của bên thứ ba ngay từ đầu.

Chainlink Cross Chain Interoperability Protocol (CCIP)

Nguồn: Chainlink

CCIP của Chainlink được định vị để trở thành đối thủ cạnh tranh trực tiếp với LayerZero do sự phụ thuộc của LayerZero về sau vào các mạng oracle phi tập trung để bảo mật hệ thống (và khuyến nghị cụ thể của giao thức cho các ứng dụng sử dụng Chainlink làm nhà cung cấp mặc định của mình).

Mặc dù CCIP vẫn đang được phát triển và chi tiết công khai về kỹ thuật còn khá hạn chế, nhưng vẫn có đủ thông tin để rút ra một số so sánh cơ bản so với LayerZero.

CCIP là một mô hình cross-chain thậm chí còn đơn giản hơn LayerZero, chỉ bao gồm các mạng oracle phi tập trung (decentralized oracle network hay DON) hiện có của Chainlink và các messaging router smart contract (MSRC) có thể so sánh với các Endpoint của LayerZero.

Không giống như LayerZero, các chức năng của oracle và relayer của CCIP được kết hợp và xử lý bởi các DON của Chainlink. Như đã nêu rõ phía trên, quyết định thiết kế này không ảnh hưởng nhiều đến sự an toàn hoặc liveness của hệ thống trong thực tế.

Phân tích so sánh

Các mô hình tương tự của LayerZero và CCIP nên chuyển cơ sở cạnh tranh sang cơ sở hiệu ứng mạng hơn là đánh đổi các giả định tin cậy. Cả hai giao thức cross-chain đều có khả năng kết nối với bất kỳ mạng smart contract nào sử dụng Endpoint và MRSC.

Bất kỳ môi trường blockchain nào trong số những môi trường này hỗ trợ kết nối dễ dàng nhất để các nhà phát triển triển khai sẽ đạt được lợi thế đáng kể. LayerZero có bước khởi đầu thuận lợi trong việc triển khai, nhưng CCIP có thể khai thác các tích hợp chain hiện có của Chainlink ngay khi ra mắt.

Hơn nữa, CCIP có khả năng tận dụng việc cung cấp dịch vụ rộng lớn của mạng Chainlink tạo ra lợi thế cạnh tranh. Cụ thể, quyền truy cập vào Anti-Fraud Network rộng lớn của Chainlink sẽ cung cấp cho CCIP một lớp bảo mật dự phòng để theo dõi các hành động gian lận từ các DON chính của Chainlink.

Về lý thuyết, các ứng dụng chạy trên LayerZero cũng có thể tự tạo một lớp bảo mật thứ cấp tương tự. Ứng dụng sẽ cần khuyến khích các relayer bằng token gốc của mình để chống lại bất kỳ relayer độc hại nào thông đồng với oracle. Tuy nhiên, không giống như quyền truy cập tự nhiên của CCIP vào Chainlink Anti-Fraud Network, điều này sẽ phát sinh thêm chi phí vận hành cho ứng dụng sử dụng LayerZero.

So với các giao thức cross-chain khác buộc các ứng dụng phải tin tưởng vào các thực thể bên ngoài mới, LayerZero và CCIP đều có thể tận dụng các nhà cung cấp oracle hiện có mà các ứng dụng tin tưởng trong hệ thống. Vì giao tiếp cross-chain chỉ là một tập con của vấn đề oracle, điều này sẽ cho phép các ứng dụng “một mũi tên trúng hai đích”.

Tuy nhiên, một lần nữa, việc tăng hiệu quả cross-chain lại tạo ra các điểm rủi ro tập trung trong thế giới multichain. Tất cả các hình thức giao tiếp với bên ngoài, cả với thế giới thực và với các blockchain khác, sẽ có chung rủi ro an toàn mà các nhà phát triển phải biết trước khi xây dựng trên một trong hai giao thức.

Kết luận các giao thức Cross-Chain Messaging

Một vũ trụ multichain có khả năng truyền thông điệp tổng quát là tính năng còn thiếu mà các public blockchain cần để trở nên phổ biến như Internet.

Các mạng được quản trị bởi các hình thức bảo mật và bộ quy tắc khác nhau cần một framework cho giao tiếp trực tiếp hoặc thông qua hệ thống của bên thứ ba để xử lý thông điệp tùy ý. Các giao thức kết nối các chain đồng bộ riêng lẻ này với thế giới các chain không đồng bộ nói chung cung cấp cơ sở hạ tầng quan trọng cho làn sóng phát triển ứng dụng có thể kết hợp tiếp theo.

IBC, Axelar, Nomad, LayerZero và CCIP của Chainlink cung cấp một tập hợp các phương pháp tiếp cận độc đáo để giải quyết yêu cầu tin cậy vốn có trong các hệ thống giao tiếp cross-chain. Tương tự như hiểu biết quan trọng về các rủi ro cần thiết để chọn cơ sở hạ tầng cho bảo mật L1, các nhà phát triển phải cân nhắc cẩn thận các giả định và các đánh đổi khi sử dụng các giao thức này. Chúng có thể được tóm tắt như sau:

• IBC duy trì tính bảo mật của hệ thống cơ sở nhưng chi phí đắt đỏ và khả năng tương thích hạn chế.
• Sự kết hợp độc đáo của Axelar giữa tính toán đa bên và TSS cho hỗ trợ phạm vi tương thích chain rộng nhất. Tuy nhiên, thiết kế của Axelar có thể tạo ra một single point of failure (yếu tố hoặc một phần của một hệ thống mà không có phương án dự phòng tồn tại và sự thất bại trong số đó sẽ vô hiệu hóa toàn bộ hệ thống) trong môi trường multichain.
• Optimistic model của Nomad giả định sự hiện diện của ít nhất một tác nhân trung thực để tạo điều kiện kết nối an toàn giữa các chain dựa trên EVM. Bằng cách đưa độ trễ vào hệ thống, các ứng dụng có thể được bảo vệ khỏi nguy cơ ảnh hưởng dây chuyền nhưng sẽ buộc phải chờ qua các challenge period đối với một số loại giao dịch nhất định.
• LayerZero cung cấp cho các nhà phát triển một framework để khai báo các giả định tin cậy ở cấp độ giao dịch. Tuy nhiên, khuyến nghị sử dụng các DONs của Chainlink sẽ kéo LayerZero vào cuộc cạnh tranh trực tiếp với CCIP của chính Chainlink. Kết quả có thể xảy ra đối với việc cạnh tranh này là các ứng dụng sẽ kết hợp các giả định bảo mật cross-chain của mình với giả định của nhà cung cấp oracle mà ứng dụng đó hiện có.

Không giống như Tower of Babel, có thể đã bẻ gãy một ngôn ngữ của con người thành hàng triệu thứ tiếng khác nhau, các giao thức truyền thông điệp cross-chain sẽ hợp nhất các blockchains rời rạc thành một hệ thống không đồng bộ một cách có trật tự. Đây là tương lai multichain thực sự mà chúng ta đang chờ đợi.

Bài viết được Huyền Trang biên tập từ “Speaking in Tongues – Profiling Cross-Chain Messaging Protocols” của tác giả Chase Devens; với mục đích cung cấp thông tin và phi lợi nhuận. Chúng tôi không khuyến nghị đầu tư và không chịu trách nhiệm cho các quyết định đầu tư liên quan đến nội dung bài dịch.

—————————————————
👉 Theo dõi FXCE Ventures
Group Chat | Research Hub | FXCE Spotlight | Tổng hợp airdrop | FXCE Pool Coin