【Web3技术分享系列专题】- 以太坊与跨链(1)
以太坊与跨链(总览+原生验证)
跨链及其分类
目标:实现相互独立的不同区块链间的信息传递,例如:使用1BTC换100ETH、通过 burn/lock 和 mint 进行资产映射、跨合约调用等
核心:实现区块链之间信息的可信传递以及验证
Connext 创始人 Arjun Bhuptani 提出的一个跨链分析框架,将跨链桥按照信息验证的方式分为三类:
- 原生验证,目标链拥有验证者 (最安全)
- 外部验证,第三方验证者 (最通用)
- 本地验证,只有交易参与者验证(最简单)
原生验证桥
概述:
具体的说,原生验证指在目标链部署源链的轻节点,然后使用轻节点对源链的交易信息进行验证。
验证分为:有效性验证和最终性验证(PoW,PoS)
典型原生跨链桥:BTC-Relay,Rainbow Bridge
举例1:BTC-Relay
BTC-Relay 是最早的轻节点合约,也是最早的原生验证跨链桥。其工作原理是在以太坊上部署一个 BTC 的 SPV 轻节点,用于对 BTC 链上的交易做 SPV 验证。
跨链流程:
链下 Relayer 负责不断的将 BTC 链的区块头传递到轻节点合约,轻节点合约在对区块头进行验证:
有效性验证是以验证工作量证明为核心
最终性验证则是等待该区块头后面被追加了 6 个以上的有效区块
链下的 Relayer 无需信任假设,任何人都成为 Relayer 传递 BTC 的区块。
举例2:Rainbow bridge
Rainbow bridge 是 Near 开发的连接 Near 生态与以太坊生态的官方跨链桥。Rainbow Bridge 的核心组成部分是两个链上合约和三个链下代理:
PS:彩虹桥这个例子主要关注典型PoS链的轻节点实现,以太坊(PoS)轻节点的实现目前较少,想要了解可以参考 Eth Client On Darwinia Chain
组件介绍:
一、下述组件1和2实现 ETH -> Near 跨链:
- 流程:Near 链上的以太坊(PoW)的轻节点合约跟踪以太坊每个区块头,实现对以太坊交易的验证,对中继者无信任假设,与BTC-Relay原理一致
EthOnNearClient:Near 链上部署的以太坊轻节点
Eth2NearRelay:负责将以太坊的区块头中继到 Near
二、上述组件3 4 5实现 Near->ETH 跨链:
- 流程:以太坊链上的Near(PoS)轻节点合约对Near的每个Epoch跟踪一个区块头,因为Near速度比ETH快很多,每个区块头都同步是不现实的,同时Near的验证人集合每个 Epoch 才会变一次,因此每个Epoch跟踪一次验证者改选的区块就可以使轻节点具备验证Near交易的能力。(PoS轻节点的典型实现)
NearOnEthClient:以太坊上部署的Near轻节点
Near2EthRelay: 负责将Near区块头中继到以太坊
Watchdog: 负责向提交无效区块头的 Near2EthRelay 提出挑战
特殊点说明:
以太坊不兼容 Near 所采用的 Ed25519 签名格式,以太坊验证Near较麻烦,因此引入乐观验证,留4小时给 Watchdog挑战Relay,挑战成功则没收Relay的质押;这种方式带来了新的信任假设:至少有一个 Watchdog 是忠实的。
小结:
原生验证桥小结:
PoW 和 PoS 类型的区块链都有其各自的典型范式;
可信程度最高,信任假设很弱,甚至可以做到无信任假设;
通用性较差,跨链双方都要实现对方的轻节点,随着链的增加边际成本不会下降;链的升级可能导致轻节点也要升级;
各原生验证桥与以太坊的对接过程中有不同的轻节点优化方案:乐观验证(RainbowBridge)、验证者集抽样(SnowBridge)、链下生成零知识证明(zkBridge)等;
以太坊 Altair 升级和 Polkadot 开发 Beefy 模块都是为了更好兼容原生验证;
值得注意的是:
- Cosmos IBC 是一套较为优秀的同构跨链协议,使用其 Cosmos SDK 构建的区块链天然支持同构链间的原生验证跨链;
- 点赞
- 收藏
- 关注作者
评论(0)