币安链(BC)与币安智能链(BSC)简介

本文主要介绍的是中心化交易所币安(binance.com)在区块链上的一些工作,主要是介绍币安链(BC)和币安智能链(BSC),除了综述官方文档之外,也会加入一些个人的看法。

出发点

总所周知,币安基于Cosmos-SDk 搭建了币安链(Binance Chain,下称 BC),并于 2019 年上线了主网。那为什么还要有另外一个智能链(Binance Smart Chain,下称 BSC)呢。白皮书解释和言外之意都描述下:

1
2
3
1)实际应用要求有更强的可编程性(要有智能合约)
2)保证现有的 dex 的高性能(基于 cosmos-sdk的链交易并发是有瓶颈的)
3)开发者的学习曲线(以太坊的 DApp 生态最完善)

有了以上的需求,采用下面的技术路线和架构几乎是水到渠成。

设计目标

设计目标

1
2
1)BC 为主链,新链是一个独立区块链,对BC的依赖少
2)兼容以太坊生态,保留跟随以太坊升级的可能性(改动越少,越好升级)

分工和职责

为了旧链和新链的合理性,设计了下面的职责和结构。

BC核心职责:

1
2
1)原有的 dex 功能
2)平行链信息, staking 与治理

平行staking 放在 BC 上,也可能是考虑以后还会有别的新链出现~

BSC 核心职责:

1
2
1)运行区块链,输出 staking 和治理依据
2)运行复杂的 DApp

由于两个链是相对独立的,所以称为是平行链

BSC 共识协议

BSC 采用了 所谓的 PoSA(Proof of Staked Authority),你可以认为是以太坊代码中的 Clique 的一个小改动,综合了 PoA 和 DPoS 的思路。大致流程是:

1
2
3
1)验证者或者代理人在 BC 上抵押
2)BC 每24 小时重选合法验证者列表(21 个),通过跨链消息传递给 BSC
3)BSC 根据验证者列表,选择节点轮流产块

PoA这个协议只能实现秒级的产块,但是无法实现秒级的确认(finality)。不确定做这个选择是为什么?可能是为了简单?个人认为有点偷懒了,采用基于 BFT 的快速确认的共识协议可能会更好。

简单而言,实现了基于 PoS 治理,PoA 产块。

从区块浏览器观察来看,BC 的区块周期大约1秒 2 个区块( sub-second),BSC 的区块周期是大约 5 秒。

因为 BC 使用的 tendermint 共识,所以交易确认时间也就是区块周期,BSC 使用了是 PoA 共识,如果等待 21 个节点中的 +1/2确认,需要大约 1 分钟。

Token

设计了在 BC 和 BSC 双向映射和转账的机制。

Token 定义

1
2
3
4
BC:
BEP2
BNB
...
1
2
3
BSC:
BEP2E
BNB

BNB 是两个平行链的 native token,交易手续费、抵押、奖励等都使用 BNB。

BEP2 是 BC 上类似于 ERC20 的 Token。

BEP2E 是 BSC 上类似于 ERC20 的 Token,多了几个方法:

1
2
3
symbol()
decimals()
onwer() //比较重要,声明拥有者地址,后面只有这个地址可以发起绑定操作

那核心问题就是Token映射和转账,即:

1
BEP2 of BC <--?-->BEP2E of BSC

Token 绑定

1
2
3
4
5
6
7
8
9
10
11
1)确定 BC 上的BEP2和 BSC 上的 BEP2E 存在
2)确定和锁定发行量
假如总发行量 S,
BC 初始流通 K
BSC 初始流通 S-K
token 发行者应该在对应的链上把未流通的量 lock 到系统合约或者账户,使得两个链上的发行总量是 S。
3)BEP2 token 的发行者在 BC 上发起绑定交易
完成检查之后,绑定请求发送到 relayers
4)BSC relayer 将跨链绑定信息转发给 TokenHub 合约
5)BEP2E 的 owner 调用 TokenHub 合约的方法,后者确认 1.未被绑定 2.symbol 发行量和最小数量位 3。锁定正常
6)BC 通过 Oracle 收到返回信息,将 contract address 和 decimal 信息写入 BC

注意,以上流程,需要 BC 上的系统托管账户,和 BSC 上的系统合约作为基础设施。

链互操作

平行链结构

官方这张图很不错。 para-chain

注意 BSC Relayer 和 Oracle Relayer,分别负责把信息转发到 BSC 和 BC。

下面先介绍这两个角色,再介绍具体的跨链操作方式。

值得一提的是,币安在设计这两个角色的时候,已经考虑到了去中心化环境可能带来的问题和采取了一定的对策。

但是,这两个角色本身的合法性和提供的信息的验证问题,是不够清晰的。

BSC replayer

BSC relayer 负责将信息从 BC传递到BSC。

需要存入一定量的 BNB 到BSC链上进行「注册」,BSC 只会接受注册的 relayers。

  • 激励机制

1)用户操作,由用户买单

2)系统同步,由 BSC 系统买单

  • 为了避免 relayers 垄断的情况

1)奖励是批量分配

2)在批量中,奖励不是线性分配

Oracle Relayers

负责将信息从 BSC 传递到BC,消息本身需要经过BC 验证者的共识。

在提交之前,Oracle 需要等待足够的 BSC 区块确认(PoA 确认需要 1 分钟)。

跨链奖励会成为区块奖励的一部分,分配给验证者。

将来也会引入对 Oracle 的 slashing

BC->BSC

依赖BSC Replayers,消息将会进入到预编译的系统智能合约。

消息类型:

1
2
3
4
5
Token绑定
转账
错误处理
验证者信息更新
...

BSC ->BC

如果是通过交易产生的跨链事件,其流程是这样的:

1
tx -> EVM -> event -> oracle

每个BC 链验证者需要运行 oracle 进程作为 oracle relayer。

跨链消息包,也会被 BC 中的 validator 进行投票,签名超过2/3即为合法。

超时和错误处理

这个在跨链协议中很重要,涉及到回滚等。

当某个 sequence 的 tx 卡主,超时之后,将会有一个 skipsequence 交易出现,对卡主的 sequence 做出不可执行的标记。

社区决定如何处理。

链上无法解决的问题,最终还是推到社区||-_-

Staking 和治理

BC 和 BSC 的Staking 的基本概念与其他基于 POS的链没有大不一样,要点如下:

1
2
3
4
5
6
7
8
9
1)抵押,代理

2)按照 token 排名,top n 作为验证者

3)validator 分享收益给 delegator

4)validator 会有被 slashing 的危险,delegator 需要分担

5)token 有赎回期

具体到 BC 和 BSC 的配合:

1
2
3
4
5
6
7
1)BC 上抵押和代理 BNB

2)BSC 的 validator 由 BC 上的 staking 模块决定,UTC 00:00:00 发出跨链通讯

3)BSC 将验证者工作的信息,通过跨链通讯回传到 BC

4)在 BC 上进行 reward 分配

罚没

基于 PoS 的公链,其活性需要全体 validator 的诚实、如实工作保证的。

为了从经济学上推动这类行为,引入了罚没机制。

双签

所谓的双签,是对于同一高度+同一个parent 的区块进行多与一次的签名。任何第三方都可以,以 slash request 的方式发到 BC 上。

1)从 validator 中移除——发出 update 事件

2)罚没一定量

3)一部分给提交者

4)另外的给验证者监管账户

不稳定

一个内部合约,统计工作情况。

1)如果超过不工作阈值,其已得收益,将不会发给 BC,而是分2给其他的 validators。

驱使运营不好的节点,delegator 将会离开

2)如果工作情况低于另外一个阈值,将会通知 BC,发生另外一个 slashing

总结

总的来讲,其技术结构和治理方式参考了一众跨链项目 (例如 cosmos 和 polkadot),也参考了 DPoS 的一众项目(例如 EOS 和 TRON)。机制设计上也留出了后续扩展的空间。在本文写作之时(2020-09),BSC 上已运行了若干 DeFi 应用,这也是 BSC 的实现最初目标(承接 DApp)的佐证。

在文章中,笔者也提出了一些疑问,例如 PoA 的区块确认时间过长,Relayer 和 Oracle 本身的信息正确性问题等。

在单链技术还没有实质性突破的情况下(以太坊 2.0 可能还需要若干年才能成熟,或者不会成功),这类平行扩展的思路,也不失为快速开展业务尝试的一种实干派做法。

参考

BC 官网

BSC白皮书

BC 浏览器

BSC 浏览器

相关文章推荐