type
status
date
slug
summary
tags
category
icon
password
 
今天我们来讲解链抽象生态全景图中 Settlement & Infra 中的传输层(Transport Layer),即跨链通信协议。本文尽量以通俗的话语和接地气的例子来阐述,致力于让 60 岁奶奶都能看懂跨链通信协议在做什么😜
在全景图中,传输层主要有 LayerZero、Hyperlane、Axelar、Union、Wormhole、SEDA、Polymer、IBC、Omni 九大项目。在翻阅它们文档的过程中,发现大家都使用了各种各样的复杂表达词汇,诸如安全堆栈(Security Stack)、Message Library (MessageLib) 、Mailbox 等。
这些词汇对于我们理解传输层的帮助不大,反而增加了用户的理解负担。我在阅览了上述项目之后,对传输层进行了归纳总结,让我们一起潜入进去👇🏻

链抽象传输层是跨链通信协议⛓️

首先,需要提前说明的是,传输层并不是一条区块链,它是一个跨链通信协议。这在 LayerZero、Wormhole 等项目文档中都进行了声明。
在知晓了传输层的定义之后,我们就能很清晰地知道传输层存在的目的 —— 传递交易消息到不同的链上并执行相应操作
它的具体执行过程可以用国际快递这一现实例子来说明,假设你想要从 A 国寄一个包裹给到在 B 国的朋友,会经历以下流程:
  • 打包包裹并填写相关信息:你打包好物品 📦,填写相关收件人的信息,准备寄给 B 国的朋友,并将包裹交给快递公司 🚚(消息发送方生成相关的交易消息)
  • 检查并记录包裹信息:A 国的快递中心扫描并记录包裹信息,确保正确的收件人和内容,准备发往 B 国(检查交易消息的格式是否正确)
  • 运输包裹:包裹通过航空 ✈️、陆路 🚗 等方式运输,经过海关或多个国家的中转,中间的运输过程存在以下两种情况(交易消息的传递)
    • 该快递公司采用数字网络的记录方式 🌐,用户可以知晓具体的运输过程(链上消息传递)
    • 该快递公司采用传统人工的记录方式 📝,具体的运输过程用户不可见(链下消息传递)
  • 海关检查:包裹到达 B 国,经过海关检 🛃,确保包裹合法、安全后允许进入 B 国的快递系统(验证消息)
  • 接收包裹并送至相应地址:B 国的快递公司接管包裹,派送到你朋友的家里并确认签收 ✍️(消息接收方执行相关操作)

跨链通信协议技术解析📚

本小节将结合上述的国际快递案例来具体阐述跨链通信协议中包含的主要角色和相关的通信过程。
声明:本小节采用的定义均属个人理解,可能与不同项目使用的定义词汇有所不同,但万变不离其宗,只为让读者能够更好地理解
整个跨链通信过程主要包含以下五大角色
  • 源链:即消息发送方 📤,负责发送相对应的跨链交易消息
  • 核心通信合约:该合约负责接收解析各种不同的跨链消息
  • 中继器(Relayer):负责传递消息的中间组件,即上述案例的快递公司的职责
  • 安全管理员:负责消息的安全可信验证
  • 目标链:即消息接收方 📥,负责接收验证过的跨链消息并执行相关操作
在这些角色中,不同项目之间的区别主要在中继器和安全管理员这两大角色的具体实现中。我们将在后续的项目盘点中进行对比。
而整个跨链通信的过程主要有以下四个步骤
  • 发送交易消息:跨链通信的起始步骤,用户在源链上发起跨链交易请求,通常包括资产转移、智能合约调用等操作。该交易由源链的合约或节点处理,将需要跨链的信息打包为消息,并准备发送给目标链。 核心任务:生成跨链消息,记录必要的交易数据,如目标链的地址、交易内容等。
  • 交易消息传递:消息通过跨链协议的中继器从源链传递到目标链。此过程可以是链下的(依赖中继器)或链上的(使用轻客户端或验证人网络),消息在此过程中会经过不同的中继节点或协议组件。 核心任务:确保消息从源链安全、准确地传递到目标链,保障数据完整性和可追踪性。
  • 验证交易消息:目标链接收到跨链消息后,目标链的安全管理员必须对消息进行安全可信验证。这一验证过程可以基于多种方式,如多签、轻客户端、Merkle 证明等,确保消息没有被篡改或恶意修改。 核心任务:通过验证源链状态和消息内容,确保跨链交易的安全性和有效性。
  • 接收并执行交易消息:在验证成功后,目标链执行跨链交易的相应操作。具体操作可能包括资产的转移、智能合约的调用等,完成跨链通信的最终目的。 核心任务:根据经过验证的跨链消息,执行对应的操作并更新目标链上的状态,完成跨链交易。

相关项目大盘点🔮

不想看文字的可直接跳到后面看对比表格和总结即可

1. LayerZero

  • 架构设计:LayerZero 使用轻节点设计,结合预言机和中继器的组合机制来实现跨链通信。预言机负责传递区块头信息,中继器负责传递跨链交易的消息数据,两者分工明确。
  • 消息传递方式:链下传递,依赖预言机和中继器的链下组合机制来进行消息传递,消息最终会在目标链上通过验证。
  • 安全模型:LayerZero 的安全模型依赖于预言机和中继器的双重验证机制。攻击者需要同时攻破预言机和中继器才能篡改消息,安全性高。
  • 去中心化程度:LayerZero 的预言机和中继器可以由不同的独立实体来提供服务,这为系统提供了更高的去中心化潜力。

2. Wormhole

  • 架构设计:Wormhole 架构基于守护者节点网络,这些节点通过多签机制负责跨链消息的传递和验证。
  • 消息传递方式:链下传递,守护者节点监听跨链交易事件,并负责将消息从源链传递到目标链。
  • 安全模型:Wormhole 的安全依赖于守护者网络的多签机制,守护者的数量和分布直接影响整个系统的安全性。如果守护者集中,可能会有更高的攻击风险。
  • 去中心化程度:守护者网络的规模和分布决定了 Wormhole 的去中心化程度,但目前守护者的数量相对有限,且守护者的选取和更换项目方仍然具有较大的话语权,本质上仍然存在较大的信任假设。因此去中心化程度低,可能存在单点集中风险。

3. Hyperlane

  • 架构设计:Hyperlane 依赖于链下中继器来传递跨链消息,链上合约负责验证中继器提交的消息。
  • 消息传递方式:链下传递,中继器负责跨链消息的传递,链上智能合约进行验证。
  • 安全模型:Hyperlane 的安全性依赖于中继器和链上合约的验证机制。虽然消息传递在链下进行,但验证是在链上完成的,增加了安全性。
  • 去中心化程度:Hyperlane 中继器网络具有扩展性,理论上可以提高去中心化程度,但依赖中继器的数量和分布。

4. Axelar

  • 架构设计:Axelar 是一个独立的跨链通信网络,基于轻客户端的设计,使用独立的 Axelar Chain 负责跨链消息和状态的传递。
  • 消息传递方式:链上传递,所有消息传递和验证都依赖于 Axelar 的独立区块链网络,消息通过链上共识进行确认。
  • 安全模型:Axelar 使用其独立区块链的共识机制来验证跨链消息,安全性高,依赖于其链上共识的健壮性。
  • 去中心化程度:Axelar 链本身具备去中心化的共识机制,消息验证依赖于 Axelar 网络,去中心化程度高。

5. Union

  • 架构设计:Union 主要依赖中继器进行跨链消息传递,链下传递消息,链上完成验证。
  • 消息传递方式:链下传递,消息通过中继器传递,链上合约负责验证消息的合法性。
  • 安全模型:Union 的安全依赖于中继器的可靠性和链上合约的验证,安全性高,但主要取决于中继器的设计和分布。
  • 去中心化程度:Union 的中继器可以去中心化,但需要依赖链上的多重验证机制才能确保消息安全,整体去中心化程度有限。

6. SEDA

  • 架构设计:SEDA 使用链上智能合约和轻客户端进行跨链通信,完全依赖链上机制来处理消息传递和验证。
  • 消息传递方式:链上传递,所有的跨链消息都通过链上智能合约和轻客户端进行传递和验证,保证了高透明性。
  • 安全模型:SEDA 的安全模型高度依赖链上合约和轻客户端的验证机制,安全性高,因其完全在链上进行验证,减少了外部信任假设。
  • 去中心化程度:由于完全依赖链上智能合约和轻客户端,SEDA 的去中心化程度非常高。

7. IBC(Inter-Blockchain Communication Protocol)

  • 架构设计:IBC 使用链上轻客户端验证跨链状态,通过跨链状态验证和区块头传递实现跨链通信。
  • 消息传递方式:链上传递,所有跨链消息都通过轻客户端机制在链上进行传递和验证。
  • 安全模型:IBC 基于轻客户端的验证机制,能够直接验证区块链的状态和区块头信息,安全性极高,且无需依赖中继器。
  • 去中心化程度:IBC 是高度去中心化的协议,因为所有跨链通信完全依赖链上验证,消除了对外部信任的依赖

8. Polymer

  • 架构设计:Polymer 基于 IBC,通过链上轻客户端进行跨链消息传递,继承了 IBC 的安全模型。
  • 消息传递方式:链上传递,所有跨链通信都在链上进行,轻客户端负责验证跨链状态。
  • 安全模型:使用 IBC 轻客户端验证机制,确保链上状态的完整性和安全性,所有验证都在链上完成,因此安全性非常高。
  • 去中心化程度:由于依赖 IBC 的链上轻客户端验证,Polymer 完全去中心化,消息传递和验证无需依赖第三方中继。

9. Omni

  • 架构设计:Omni 采用中继器和预言机设计,链下消息传递,链上负责验证跨链消息。
  • 消息传递方式:链下传递,中继器和预言机负责跨链消息的传递,链上合约负责验证和执行。
  • 安全模型:Omni 的安全性依赖于中继器和预言机的表现,链上合约完成最终验证,因此在一定程度上有外部信任假设。
  • 去中心化程度:中继器和预言机可以去中心化运行,但它们仍是 Omni 设计中的关键信任点,去中心化程度有限。

总结

  • 架构设计方面:链上传递的项目(如 IBC、SEDA、Axelar)侧重于轻客户端和链上验证,链下传递的项目(如 LayerZero、Wormhole、Hyperlane)则依赖于中继器、预言机或守护者节点。
  • 消息传递方式:链上传递提供更高的透明性和安全性,链下传递则能够提高通信效率,但引入了更多的外部信任假设。
  • 安全模型:链上传递的项目通常安全性更高,特别是基于轻客户端验证的 IBC 和 Polymer,链下项目的安全性则依赖于中继器或预言机的可靠性。
  • 去中心化程度:完全链上验证的项目如 IBC、SEDA 和 Polymer 具有更高的去中心化程度,而依赖外部节点或中继器的项目,如 Wormhole 和 Omni,去中心化程度低。
项目名称
架构设计
安全模型
消息传递方式
安全程度
去中心化程度
支持的区块链
LayerZero
轻节点设计,依赖预言机和中继器组合进行跨链通信
双参与方(预言机+中继器)安全模型,需同时攻破预言机和中继器才能成功攻击
链下传递
EVM 兼容公链
Wormhole
基于守护者节点的多签机制,依赖守护者网络进行跨链消息传递
基于守护者网络的多签验证机制,守护者的数量和分布影响安全性
链下传递
Solana、EVM 兼容公链
Hyperlane
依赖中继器的跨链方案
中继者负责传递消息,链上合约验证,安全性依赖中继者和链上验证
链下传递
EVM 兼容公链
Axelar
独立链架构,基于轻客户端机制,使用其独立区块链 Axelar Chain
链上共识机制,使用 Axelar 链的共识来验证消息安全
链上传递
EVM 兼容公链、Cosmos、Polkadot、Near 等
Union
依赖中继器的跨链方案
依赖中继器和链上合约的验证,安全性取决于中继者的可靠性
链下传递
EVM 兼容公链
SEDA
使用链上合约和轻客户端进行跨链通信
通过链上合约和轻客户端验证消息,安全性高,基于链上共识
链上传递
与 Cosmos SDK 兼容的公链
IBC
轻客户端机制,链上消息传递,通过中继链(Relay Chain)实现跨链通信
轻客户端验证链状态,链上直接验证,极大降低了信任假设
链上传递
与 Cosmos SDK 兼容的公链
Polymer
基于 IBC,使用链上轻客户端的跨链通信
轻客户端验证机制,链上验证所有消息,安全性高
链上传递
与 IBC 兼容的所有区块链
Omni
中继器和预言机设计
链下中继器和预言机传递消息,验证在链上完成,安全依赖中继和链上合约
链下传递
EVM 兼容公链、Solana

如何评价跨链通信协议✍️

在评价某一个跨链通信协议时,个人认为需要优先考虑其安全性与效率,其次才是该协议支持的区块链数量、相关应用场景氛围等

安全性:跨链协议的核心‼️

跨链通信涉及资产和数据的跨链转移,因此安全性是最为基础的考量。如果一个跨链协议不能保障安全性,那么无论其效率多高、兼容链数量多广,都难以获得用户和开发者的信任。虽然完全链上验证的协议,效率有所折扣,但由于安全性更高,适合需要强安全保证的场景。

效率:用户体验的关键🗣️

跨链通信协议在安全的基础上,还需要具备足够的效率。高效的跨链通信可以提高用户体验,减少交易确认时间,增强协议的可用性和实际应用场景中的竞争力。
高效通信对于 DeFi、支付和游戏等应用场景至关重要,这些场景通常对于协议的通信效率有高要求,需要能够在不同链之间快速传递资产或数据。如果跨链通信过于缓慢,将严重影响用户体验和应用的流畅度。

兼容链数量与扩展性:次要但重要的因素🪬

尽管安全性和效率是跨链协议的核心,兼容的链数量扩展性也影响协议的实际应用和用户覆盖面,但它们应该是在安全和效率得到保证后才考虑的因素。一个能够兼容多个链的跨链协议能够覆盖更多的生态系统和用户,但前提是安全和效率不能受到过多妥协。因此多链兼容与扩展性是跨链通信协议的长远目标
所以在评价跨链通信协议时,我们需要先根据该协议面向的应用场景对安全性与效率进行一定的平衡取舍。如面向游戏、支付的跨链通信协议时,我们可以容忍其牺牲一定的安全性以保障足够高效的通信效率。

以上,便是本文的所有内容,希望对你有所帮助!如果您觉得不错,记得点赞 / 转发支持,也可访问下方链接获取更多内容👇🏻
Howe
投研百宝箱🔮 — 主页👤 — 个人博客💻
学生思维到工作思维的转变【无需信用卡】推特蓝V丝滑开通教程
Howe
Howe
Web3 buidler and researcher | Everything is possible!
公告
type
status
date
slug
summary
tags
category
icon
password
🎉欢迎您的到来🎉
我是Howe,Web3爱好者与建设者,让我们一起交流学习
欢迎关注我的推特一起交流学习,DM Open: cryptoHowe.eth