浅析主流跨链机制

  • Rayer
  • 更新于 2024-07-11 18:56
  • 阅读 1270

该文章是作为视频笔记形式分享,视频来源于https://www.bilibili.com/video/BV18Y411i73M/?spm_id_from=333.999.0.0&vd_source=41fb3490732619982aa30dfbc1b5d64d。该文章涵盖了该视频讲到的内容。

跨链

随着各类公链以及Layer2越来越多,跨链将会成为区块链中的一个刚需,也会成为未来发展必须完善的技术之一。跨链要具备以下因素:

  • 对EVM以及异构链的兼容
  • 对”不可能三角问题“的解决,即通用性、可扩展性、去中心化不可能三角。
    • 但目前已经有一定的方案。比如在协议层更改,以预编译的形式集成各种协议算法。以及merkle树和zk的验证,可以降低链上验证成本。
  • 对预言机的弱依赖。
  • 更好的开发支持

跨链主流机制

  1. 公证人机制
  2. 哈希时间锁
  3. 中继链

公证人机制

公证人机制是技术上可实现的最简单的一种跨链机制,本质上是一种中介的方式。通过引入一个或多个可信第三方做信用背书,持续监听链上发生的实践,并根据获取到的事件信息负责在其他链上进行跨链消息的验证和转发。

image.png

单签名公证人机制

  • 公证人为独立的节点或者第三方机构
  • 公证人在整个跨链交互中进行数据收集、验证、交易确认等任务
  • 该方式兼容性高、交易速度快,但适用范围仅限于跨链资产交换等场景

例如: BINANCE,coinbase等中心化交易所

多签名公证人机制

  • 公证人为一群独立节点或者机构组成的联盟
  • 每个公证人都拥有一个密钥,只有一定比例的公证人在跨链交易上签名达成共识时,该交易才生效
  • 该方式弱化了单签名公证人机制的中心化风险,具有更高的安全性,即使有部分节点受到恶意攻击也不会影响整个跨链系统的运行。

例如:deBridge、Wormhole

分布式签名公证人机制

  • 采用多方计算MPC来确保密钥的安全性和隐私性
  • 密钥拆分为多个碎片并随机分发给公证人,但无法利用这些碎片得出完整的密钥,仅当一定比例的公证人同事完成签名后才能拼凑出完整的密钥
  • 该方式是在公证人机制中安全性最高的方案

例如: Multichain,Synapse

哈希时间锁定

哈希时间锁定方案利用哈希函数的单向性和低碰撞性,通过哈希锁和时间锁,迫使资产的接收方在deadline内确定收款并产生一种收款证明给打款人,否则资产会归还给打款人。

收款证明能够被付款人用来获取接收人区块链上等量价值的数量资产或触发其他事件。

即双方都在智能合约中锁定资产,如果在规定时间内能够在两边都输入hash的正确原值则解锁。最早在闪电网络中提出。目前主要是cBridge在使用。

image.png

  1. 发送方在源链上发起transferOut交易
  2. cBridge节点通过使用发送方设定的hashlock,在目的地链上发起transferIn交易
  3. 发送方在源链上确认交易
  4. cBridge节点在目的地链上确认交易

中继链(Relayer)

通过在两个链中加入一个通道,通道内创建一种特定的数据结构,使得两个链可以通过该通道内的数据结构进行跨链数据交互,这个加入的通道我们就称之为中继链。

例如Cosmos,Polkadot

Cosmos

  • Cosmos是一个独立并行区块链的去中心化网络,每个区块链都由TendermintBFT共识算法构建
  • Hub管理着多个被称为Zone的独立区块链,Hub来追踪记录各个Zone的状态
  • Zone有义务不停地把自身产出的新区块反向汇报给Hub。类似地,每个Zone也需要同步Hub的状态。

在Cosmos 的平行链中需要满足两个特性

  • 快速确定性
    • 由Cosmos的共识算法来保证,即它不支持PoW类似的概率确定模型的区块链
  • 具有强的监管性
    • 每个平行链都需要有验证者能够监管其出块

Cosmos主要是用了IBC

IBC

IBC(Inter-Blockchain Communication)是一种通用的互操作协议,它支持两个不同的区块链相互通信,而无需信任中间的任何人

  • 传输层
    • 提供必要的基础设施来建立安全连接和验证区块链之间的数据包
  • 应用层
    • 建立在传输层之上,它定义了数据包应该如何被发送链打包、以及如何被接收链解包。

IBC WorkFlow

image.png

  1. 链A的应用A,调用sendPacket,向链B中的应用B发送一个数据包,链A的核心IBC A提交数据包并更新自己的状态。
  2. 中继器1 监测到这个数据包并向链B的核心, IBC b 发送消息。
  3. 核心IBC b会进行各种验证,验证数据包确实是由链A发送的,数据包的顺序是否正确,数据包的消息证明是否有效等。
  4. 如果核心IBC验证成功,这个数据包到达APP B
  5. APP B 从核心IBC接收到数据包后,会将其按照预期结构解包,然后走相应的应用逻辑。
  6. 处理完数据包后,会给链A一个回执

Polkadot

  • 主链被称为中继链,负责整个网络的共享,共识,互操作性等工作。
  • 侧链被称为平行链,每一个应用都由自己的链并且桥接在主链上
  • 桥允许平行链和以太坊等其他外部网络建立桥接
  • 网络中存在四种类型的参与者,包括Validator验证人,Collator收集人,Fisherman钓鱼人,Nominator提名人。

XCMP

  • Polkadot 的跨链消息传递(Cross-chain MessagePassing,XCMP),它主要用来定义除共享中继链安全之外,在没其他信任假设的情况下,消息如何得以在平行链之间传递。主要包括:消息队列机制,消息可用性,消息输入和输出等
  • XCMP特点:
    • 快速:消息可以快速发送到目的链
    • 顺序:消息可以按顺序到达目的链
    • 可验证:可以验证到达消息确实是由发送链发送的,以及该消息在接收链中已被处理
    • 无遗漏:接收链公平地接收每一条消息,发送链不会无限期地等待接收链接收和处理其他消息。

XCMP WorkFLow

image.png

  1. 用户在链A上调用部署在链A上的智能合约,从而初始化一条以链B为目的地的跨链消息M;
  2. 链A的收集人节点会将这条消息M放到A的出口队列中;
  3. 链B的收集人在正常情况下,当轮询到以自己为目的地的消息M时,会将其放到自己的入口队列中,以待在产生下一个区块的时候处理该消息;
  4. 链A和链B的验证人会通过读取出口队列从而知道这条消息;
  5. 当链B的收集人节点开始构建一个新区块的时候,它会处理当前入口队列的消息M;在处理过程中,消息M会执行链B中相应的智能合约以完成预期的跨链资产转移;
  6. 收集人将这个区块提交给验证人,验证人会验证消息M是否真的被处理了;如果这条消息被验证确实处理了,并且这个区块没有其他不合法的地方,验证者就会把该块确认进中继链中。

目前Polkadot没有完全实现XCMP,而是使用了HRMP的方案来替代XCMP,这个方案是在parachute之间做消息传输的过渡方案。它会把跨链的消息,从原本应该存在消息队列中,改为存在related chain 上面,它会严重占用related chain 的存储资源。目前该方案是个过渡方案。

LayerZero

  • LayerZero是一个全链互操作协议,能够向支持的任何链上的智能合约发送消息。
  • 端点Endpoint: 每条链上都需要具备LayerZero的端点,以进行信息传输。端点分为四个模块:通讯器、验证器、网络和库
  • 预言机Oracle: 预言机是第三方服务,从一个链中读取区块头并将其发送到另一个链,LayerZero在实践中用的预言机是chainlink
  • 中继器Relayer:中继器是一个链外的服务,功能类似于预言机,但并不是获取区块头的,而是获取制定交易的证明。

LayerZero Workflow

image.png

  • 当用户应用从A链到B链发送消息时,该消息通过A链上的端点进行路由
  • 然后端点通知预言机和中继器该消息,以及目的链
  • 预言机将区块头转发给B链的端点
  • 中继器提交交易证明
  • 该证明在目的链上被验证,消息被转发到目的地址。

当用户想要从A链到B链发送消息时,消息会从A链的端点开始路由,端点即A链上的端点合约。接着合约会通过两个独立的实体,即Relayer和Oracle 来确认这笔交易,从而保证跨链通信的有效性。除非Relayer和Oracle共同作恶,否则消息传输的机制就是安全的。但实际上其借助了两个中心化的实体,存在共同作恶的风险。

Map Protocol

在Map主要是用到relation+light client的方案。

map主要分成三个层

  • 协议层
    • map relation 即map的中继链
    • 各条链的light client
    • Maintainer,是一个链间程序,负责向各个客户端间提交区块头。
  • 全链服务层
    • 包含了一个messenger,用于提交跨链交易的链间程序。可以通过map的SDK来build自己项目的messenger。
    • 其中包括了一系列的toolkit,包括messenger的SDK,MOS合约,以及其他链相关合约。
  • 应用层
    • 最上层放各种应用,例如 butter swap,一个全链资产聚合的Swap

image.png

  • Proof of Stake
  • iBFT共识
  • 多链轻客户端支持
  • 预编译合约支持

Map Workflow

image.png

  • map上以预编译的形式集成了大量链的底层和共识算法。其他链与map中继链通信时,轻客户端的编写难度会大大降低,因为预编译合约的存在。
  • 在轻客户端方案上,如果需要两条链互联就需要在两条链上部署对方的轻客户端。如果多链互联则要部署其他链全部的轻客户端。在Map上,因为预编译合约的存在,不同链上的轻客户端可以开发并部署在map上,并只需要部署一个map客户端。 消息在跨链的时候可以在map客户端上进行验证。
点赞 1
收藏 1
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Rayer
Rayer
0x156c...41d0
希望能共同成长,有工作机会和技术交流沟通可以联系VX:cHenYuBiz