blockchain

币安链（BC）与币安智能链（BSC）简介

,

Modified:

本文主要介绍的是中心化交易所币安（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 的区块周期是大约 3 秒。

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

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 浏览器

相关文章推荐