有效的在基于以太坊EVM的链之间跨链(Efficiently Bridging EVM Blockchains)

中继网络是区块链跨链技术的重要流派之一。本文用来介绍一种有效的中继网络技术。

 

现有的中继网络

第一个例子就是BTC-Relay源码

  • 社区里的成员每10分钟转发连续的块头。块头和块的索引被存到了以太坊的智能合约
  • 用户在比特币网络做交易
  • 用户将交易数据发送到以太坊智能合约,交易数据包括相关的块和Merkle Proof所需的数据
  • 智能合约验证Merkle Proof并触发一个事件

示意图如下:

DAG

为了使用ETHash算法去验证难度,以太坊需要16GB DAG。 在EVM里创建DAG是相当昂贵的。

同步块机制

假设我们的侧链每2分钟同步一次,每次消耗4000gas, 存储消耗20000gas(STORAGEADD from this list),基本费要21000gas。存储块头需要消耗45000gas

我们需要分45000gas每2分钟。假设ETH价格是1000美元,和低价的GWei

  • $1.35/hour
  • $32.40/day
  • $972.00/month

目前为止,这个方法从未付诸实行。It is cost-prohibitive

Merkle Proof工作机理

Merkle树在验证方面是很有效率的。整个验证过程叫做merkle proof

  1. Hash C and D to produce S(C,D).
  2. Hash S(A,B) and S(C,D) to produce S(S(A,B),S(C,D)).
  3. Hash S(S(A,B),S(C,D)) and S(S(E,F),S(G,H)) to produce the root.
  4. Check that the root is the same as what has been stored previously.

简单Merkle中继

如果我们只是每隔2分钟把每块的块头的Merkle proof写入合约呢?需要考虑以下因素

  • 提取交易有多贵?成本核算
  • 交易多长时间能被承认

成本核算

一个提取交易需要证明:

  • 在其他链上你的入金被记录在在特定的交易集合中
  • 特定的交易集合存在特定的块上
  • 特定的块在Merkle树中存在。该Merkle树的根存储在智能合约里

这意味着要做2次Merkle Proof, 根据gas cost sheet, :

  • SHA3BASE = 30 gas    做SHA3哈希操作的成本
  • SHA3WORD = 6 gas

假设每个块中有256个交易,Merkle树的高度是9.一次Merkle Proof的成本是(9-1)×(30+6)=288gas

这个成本相当低,大概0.000288美元

交易达成

假定侧链有15个块,存储成本是45000gas。再假定ETH的价格是 $1000,一个 gas 的成本是1 GWei. 快速交易和低廉的存储会存在什么样的关系?

如果客户愿意等大概8.53小时,每月的发送块头的成本小于1美元

复杂Merkle中继

上面的算法工作在可信任的Layer. 如果是在一个Trustless的Layer呢?

主要有2种方法:

  • Vitalik’s sharding v1 proposal 使用了和BTC-Relay非常相似的设计, 由Validator Manager Contract (VMC)管理的n个分片。 详细看 this article

提议块头根

基于以前主链的块数据,确定一个提议者。 这个时刻也被标记为一个EPOCH(时代)的开始(此定义来自Casper).

这个提议者,在某个块号(2的幂), 从侧链取到一个块头根并送给一群验证者去签名画押。一旦足够的验证者在提议的块头根背书后,提议者就会调用在主链上的智能合约的一个函数,将新的块头根记录下来,并从赏金池中获取奖励。.

减少块内容

中继是一种加速跨连资产转移的机制. 这就意味着有2个重要的功能: deposits and withdrawals.

由于中继合约是独立于它连接的区块链运行的,提议者只需要打包足够的信息来证明某一用户在某一特定快,某一特定链,放置了某一特定资产. 以太坊中,从块头里我们必须使用其中的15个元素来做哈希操作

为了中继的目的,很多元数据可以不要了。可以精简为以下4个元素:

  1. 前块头
  2. 块号
  3. 时间戳
  4. 交易根哈希

验证块头根 Validate header root

一旦一个验证者收到了一个提议的块头根,它会检查在侧链里的块头根的集合。如果没有问题,就以如下形式签消息:

[
  sidechain_id,  
  sidechain_start_block_num,
  sidechain_end_block_num,
  header_root
]

验证者从智能合约指定数量的集合中以伪随机的方式被选出来。这个数量的限制很大程度是由于Gas成本; 由于当前以太坊没有集合签名(aggregate signature)机制,签名需要循环地被恢复recovered (ECRECOVER) . 由于gas的成本(3000 gas) 和每块gas上限 (~5M)的限制, 合理的上限是大概100 签名.

一旦一个Epoch的一组验证者被选定,这组验证者就会在一个独立的中继侧链上聆听被提议的块头. 如果一个块头根被提交,验证者就会获取侧链上的块头并计算其Merkle根。如果相等,这在这个根和元数据上签字.

这个过程要求验证者能访问:

  1. 在主链上的中继合约的状态 (知道何时合约在验证这个epoch)
  2. 侧链上这个Epoch的块
  3. 在中继网络上的其他参与者(为了广播签名)

验证者激励 Validator Incentive

在指定的Epoch,验证者只检查块头根,并没有在资产上受益。但是一旦块头被成功提交,从参与者的池子中挑选新提议者。因而,参与者也被激励只要P(being selected) * proposalReward 超过带宽和上线成本.

赏金池 Bounty Pool

因为中继网络是独立于侧链的,所有的激励都是来自中继网络。最容易的方法是以一定的频率(比如以年为单位)The easiest way to do this is with a bounty pool that is paid into by users of the system on a yearly basis or else subsidized by an organization bootstrapping the relay.

对特定的Epoch的激励是动态的,而且是随时间在成长。重要的后果是epoch time is dynamic (assuming the reward schedule is parameterized to be dynamic). 另一个后果是 赏金池可能干涸。所以取决于参与者,池子可能需要补贴而且能破产.

Parameterization and Community Voting

参数化可以用好多的办法。最简单的就是把中继网络的创建者赋予“admin”, 只能来设定参数(e.g. the reward curve). 如果Admin补贴中继网络,则一切OK。不过更成熟的方法是在参与者间投票在参数化。这开启了DAO和TCR 设计.

源码分析 

智能合约源码解析之Bridge Contract  -- https://github.com/GridPlus/cryptobridge-contracts

以太坊架构

enter image description here

enter image description here

https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture/757#757

参考这篇文章

猜你喜欢

转载自my.oschina.net/gavinzheng731/blog/1786305