一、原理

BTTC跨链

参考了Polygon，是基于侧链的公共区块链扩展解决方案；
主要是通过双向锚定的跨链桥来实现与主网的链接、以及互相操作
基本原理：
- 充值：通过锁定主链上的资产，并在侧链发行相关资产；
- 提币：如果想要回到主链，只需要销毁侧链上的资产，并在主链上解锁相关资产。
实现：
- 采用POS（Proof of Stake）机制
- 部署多节点验证
- 通过侧链进行智能合约的扩展
- 兼容Ethereum链架构的智能合约及其他功能

跨链桥

跨链桥提供了一条在侧链和主链之间的可信双向交易通道。

当代币通过跨链桥传递时，它的总流通量不会被影响

离开Ethereum的代币会被锁定，同时在Polygon网络上铸造与其等量的映射代币。
将代币从Polygon转回Ethereum时，Polygon上的代币将被销毁，同时将解锁Ethereum上的等量原始代币。

架构

BTTC是三层架构：

根链智能合约层：
- 由部署在各公链（Ethereum / TRON / BSC）上的，一系列去中心化的智能合约组成；
- 负责收集跨入/跨出 BTTC 的交易，validator的质押管理、委托管理，以及验证侧链状态的检查点/快照等功能；
Validator层：验证BitTorrent-Chain区块，定期发送Checkpoint至支持的TRON及其他区块链网络

Bridge：负责监听各链路事件，发送事件消息等。

Core：共识模块，包括Checkpoint(BitTorrent-Chain链的状态快照)的验证，Statesync事件&Staking事件的共识。

REST-Server：提供相关API服务。

实现：Delivery

BTTC层：区块生产者层，是一条与以太坊 (EVM) 完全兼容的，且由一组去中心化的验证人 (validators) 共同治理的 PoS 链。

Root Contracts

目前支持与BTTC跨链的根链有 TRON, Ethereum, BSC。BTTC设计的框架支持后续增加其它的公共区块链，仅需要在该公链上部署以下3类合约即可：

Staking管理：主要处理 BTTC 验证者节点的质押、slashing等
- StakeManagerExtension, StakingInfo, StakeManagerProxy, ValidatorShare, StakeManager, ValidatorShareFactory 等
代币映射：包括和子代币相映射的根代币所遵循的合约标准，mint权限委托的Predicate合约等
- DummyERC20, ERC20Predicate, ERC20PredicateProxy, MintableERC20Predicate, MintableERC20PredicateProxy 及 ERC721相关的合约等
资产转移及状态同步管理：deposit、withdraw tx 及状态同步所要调用的合约方法包含在里面
- RootChain, RootChainManager, EventsHub, StateSender 等

部署的合约列表查看

Child Contracts

BTTC子链上为支持跨链所部署的合约有：

ChildChainManager：处理代币映射、销毁等逻辑；
ChildToken 模板：支持跨链的代币类型是 20、721，并支持子代币Mintable；
状态同步相关：StateReceiver, ChildTunnel等。

代币映射

使用 BTTC 跨链桥需要先将 Root Token、Child Token 进行映射。

操作步骤：

实现子代币合约
1. 标准子代币（20,721）：继承项目代码中的 ChildERC20，确保有deposit以及withdrawTo方法
2. 自定义子代币：实现自己的子代币合约
将子代币合约部署到 BTTC 网上
1. 参考 deploy_child_chain_contracts.js进行部署；
2. 部署时需要 BTTC 上的 ChildChainManager 合约地址；
提交映射请求
1. 在这里提交映射请求，其中 The Token Contract Address on Ethereum/BSC/TRON 是根链上的根代币合约地址，The Token Contract Address on BTTC 是部署在BTTC上的子代币合约地址。
2. 审核时间是3~5个工作日

根链权限

deposit 需要根链锁币，withdraw 需要解锁相关资产。

代币映射时，会指定代币类型，每种类型有对应的 Predicate 合约。

锁币：交易发起者 Approve 对应的 Predicate 合约，批准合约Predicate消费代币，将 token 从发起者账户转给 Predicate 地址；

解锁：Predicate 地址给接收者账户转 token。

Token Type	Predicate
ERC20	ERC20Predicate
ERC721	ERC721Predicate
MintableERC20	MintableERC20Predicate
MintableERC721	MintableERC721Predicate

二、跨链流程

前提

进行充提币操作之前，需要先下载插件钱包并连接钱包中的账户地址。

目前BTTC网页支持2种钱包插件，分别为 TronLink与 MetaMask。

TronLink
- 不支持签名BTTC网络交易，所以仅支持使用TronLink将资产存入BTTC
MetaMask
- 支持Ethereum、BSC网络资产映射到BTTC
- 添加BTTC网络（即自定义RPC）后，可以发送或取出BTTC网络的资产

2.1 根链 <-> BTTC

deposit

状态转移数据格式：

/* StateSynced event内数据格式如下
{
  id: counter++,
  receiver: childChainManagerAddress,
  calldata: abi.encode(
    DEPOSIT,
    abi.encode(user, rootToken, CHAIN_ID, depositeData)
  )
}
*/

type MsgEventRecord struct {
   From            // 提交tx的Delivery节点地址
   TxHash          // deposit tx 的 tx hash
   LogIndex        // 日志的index
   BlockNumber     // 日志所在的block number
   ContractAddress // StateSynced 事件的 receiver，即 ChildChainManagerAddress
   Data            // StateSynced 事件的 data
   ID              // StateSynced 事件的 id, StateSender 合约维护一个counter，每次发出 StateSynced事件则加1
   ChainID         // 子链 ID
   RootChainType   // 根链类型，TRON? ETH? BSC?
}

checkpoint

Delivery层将BTTC层生产的区块聚合成一棵Merkle树，并定期将Merkle根发布到根链，这种定期发布称为检查点。

Checkpoint很重要：

在根链上提供侧链的最终确定性。
提供侧链提取资产到主链的燃烧证明。

checkpoint 同步流程

Delivery bridge 同步到最新的BTTC new header，验证header后发现该提交checkpoint，则当前的 proposer 为每条根链创建对应的 checkpoint tx，并发送给 BTTC 节点。该 tx.Msg 数据格式如下：

type MsgCheckpoint struct {
  Proposer        // checkpoint 的提议者
  StartBlock      // checkpoint 开始的区块number
  EndBlock        // checkpoint 结束的区块number
  RootHash        // Merkle root
  AccountRootHash 
  BorChainID      // 子链 ID
  Epoch           
  RootChainType   // 根链类型，TRON? ETH? BSC?
}

StartBlock：访问根链RootChain合约的CurrentHeaderBlock及GetHeaderInfo方法可以获取根链记录的最新checkpoint，该checkpoint.end+1即为下一个checkpoint的start；

假设正常的checkpoint [StartBlock, EndBlock] 如下：[1,128], [129, 256],...若第一个checkpoint（[1, 128]），由于各种原因导致根链没有接收并更新合约内存储的内容，则要发送给该根链的 checkpoint 是 [1, 256]

这些checkpoint tx被打包进block，执行后将生成 EventTypeCheckpoint 事件的日志；validator会对执行结果进行 Precommit 投票，收集到超过2/3的 Precommit 投票才有效。

// Emit event for checkpoint
ctx.EventManager().EmitEvents(sdk.Events{
   sdk.NewEvent(
      types.EventTypeCheckpoint,
      sdk.NewAttribute(sdk.AttributeKeyModule, types.AttributeValueCategory),
      sdk.NewAttribute(types.AttributeKeyProposer, msg.Proposer.String()),
      sdk.NewAttribute(types.AttributeKeyStartBlock, strconv.FormatUint(msg.StartBlock, 10)),
      sdk.NewAttribute(types.AttributeKeyEndBlock, strconv.FormatUint(msg.EndBlock, 10)),
      sdk.NewAttribute(types.AttributeKeyRootHash, msg.RootHash.String()),
      sdk.NewAttribute(types.AttributeKeyAccountHash, msg.AccountRootHash.String()),
   ),
})

bridge 监听到该事件，proposer 将创建和广播 checkpoint tx 给对应的根链。
给 ETH、BSC 发送 checkpoint tx：获取之前提交的、针对对应根链的 checkpoint tx，将其转换成 stdTx，再封装成 tx 的 SideTxMsg，提交一个新的tx，该tx调用 RootChain 合约的 submitCheckpoint 方法，其中 SideTxMsg 以及 checkpoint tx 的投票作为参数传递。
1. 调用 StakeManager.sol 的 checkSignatures 方法对投票进行验签
2. 根链的 RootChainStorage 合约保存 checkpoint；

// RootChainStorage.sol
mapping(uint256 => HeaderBlock) public headerBlocks

// RootChain.sol submitCheckpoint() 
function _buildHeaderBlock(
        address proposer,
        uint256 start,
        uint256 end,
        bytes32 rootHash
    ) private returns (bool) {
  ...
  HeaderBlock memory headerBlock = HeaderBlock({
     root: rootHash,
     start: nextChildBlock,
     end: end,
     createdAt: now,
     proposer: proposer
  });

  headerBlocks[_nextHeaderBlock] = headerBlock;
  ...
}

// RootChain.sol
function getLastChildBlock() external view returns (uint256) {
   return headerBlocks[currentHeaderBlock()].end;
}

ETH、BSC 执行该 tx 后，会 emit NewHeaderBlock 事件
TRON 处理流程相同
bridge 监听到来自根链的 NewHeaderBlock 事件后，proposer 给 BTTC 发布 checkpoint ack tx。

exit withdraw

调用RootChainManager合约的exit方法来解锁并从ERC20Predicate合约接收代币。这个方法接收一个参数：代币的销毁证明。

调用这个方法之前必须要等待包含销毁交易的checkpoint提交成功。销毁证明由RLP编码生成如下字段：

headerNumber：包含销毁交易的checkpoint起始块
blockProof：确保区块头是提交的默克尔根所在树中叶子的证明
blockNumber：包含销毁交易的区块号
blockTime：包含销毁交易的区块时间
txRoot：区块的交易根
receiptRoot：区块的receipt root
receipt：销毁交易的receipt
receiptProof：销毁交易receipt的默克尔根
branchMask：表示receipt在Merkle Patricia Tree中位置的一个32位参数
receiptLogIndex：用于从receipt中读取的日志索引

销毁证明可以自己生成，也可以调用 BTTC SDK 生成

2.2 根链 <-> 根链

TRON、Ethereum、BSC网络之间的跨链

资产先存入 BTTC 网络，再取出至目标链网络;
目前支持此跨链方式的代币有 BTT、TRX、JST、NFT、SUN、USDD、WIN；（均为原始代币是部署在 TRON 上的代币）

以 WIN 为例：原始代币 WIN 部署在 TRON 链上，其对应的子代币合约为 WIN_t ，Ethereum 链代币对应的子代币合约为 WIN_e，BSC链代币对应的子代币合约为 WIN_b。

子代币合约

WIN_e、WIN_b 两个合约与 WIN_t 所映射的子代币合约略有不同：

增加了 originToken 成员变量（部署时设置 WIN_t 为其 originToken）；
增加了两个方法：
- swapIn：用 originToken 换取子代币
  - 将 originToken 从交易发起者账户里转给子代币合约地址；
  - 为交易发起者账户 mint 子代币；（与deposit不同的是，交易发起者即可进行 mint，不需要 DEPOSITOR_ROLE 权限）
- swapOut：用子代币换取 originToken
  - 交易发起者账户 burn 子代币；
  - 将 originToken 从子代币合约地址转给交易发起者账户；

根链代币合约

原始代币：部署在 TRON 上

其它根链代币：非标准代币，继承自 IMintableERC20，部署时需要指定主链上的 MintableAssetPredicate(例如：MintableERC20Predicate。Asset表示资产类型，下同) 合约为铸币者

MintableERC20Predicate 与 ERC20Predicate 的 exit() 方法实现不同：

ERC20Predicate：直接从 Predicate 地址转账给 withdrawer；
MintableERC20Predicate：若 Predicate 地址没有足够的余额，可先给 Predicate mint 不足的余额，再转给 withdrawer；

TRON给其它根链转账

操作：TRON 的账户 Addr_t 签名发起交易，转 100 WIN 给 BSC 的账户 Addr_b;

步骤	TRON Addr_t	BTTC Addr_b	BTTC Addr(WIN_b)	BSC Addr_b
充值	-100 WIN	+100 WIN_t (mint)
提币1: swapIn		-100 WIN_t, +100 WIN_b (mint)	+100 WIN_t
提币2: withdrawTo		-100 WIN_b (burn)
收币				+100 WIN

其它根链给TRON转账

操作：从 BSC 的账户 Addr_b 转100 WIN给 TRON 的账户 Addr_t;

步骤	BSC Addr_b	BTTC Addr_b	BTTC Addr(WIN_b)	TRON Addr_t
充值	-100 WIN	+100 WIN_b (mint)
提币1: swapOut		-100 WIN_b (burn), +100 WIN_t	-100 WIN_t
提币2: withdrawTo		-100 WIN_t (burn)
收币				+100 WIN

BSC给Ethereum转账

操作：从 BSC 的账户 Addr_b 转100 WIN给 Ethereum 的账户 Addr_e;

步骤	BSC Addr_b	BTTC Addr_b	BTTC Addr(WIN_b)	BTTC Addr(WIN_e)	Ethereum Addr_e
充值	-100 WIN	+100 WIN_b (mint)
提币1: swapOut		-100 WIN_b (burn), +100 WIN_t	-100 WIN_t
提币2: swapIn		-100 WIN_t (burn), +100 WIN_e		+100 WIN_t
提币3: withdrawTo		-100 WIN_e (burn)
收币					+100 WIN

Ethereum给BSC转账

操作：从 Ethereum 的账户 Addr_e 转100 WIN给 BSC 的账户 Addr_b;

步骤	Ethereum Addr_e	BTTC Addr_e	BTTC Addr(WIN_b)	BTTC Addr(WIN_e)	BSC Addr_b
充值	-100 WIN	+100 WIN_e (mint)
提币1: swapOut		-100 WIN_e (burn), +100 WIN_t	+100 WIN_t
提币2: swapIn		-100 WIN_t (burn), +100 WIN_b		-100 WIN_t
提币3: withdrawTo		-100 WIN_b (burn)
收币					+100 WIN

2.3 关于 BTT

BTT在各条链上的代币合约：

TRON：

继承自 TRC20 的代币，合约创建者初始有 9900 1e8 1e18 * 1e3；
BTTC上映射的子代币：原始代币，由 GENESIS 创建，对应的合约地址是 0x0000000000000000000000000000000000001010；

genesis-contracts/bttc-contracts/contracts/child/MRC20.sol

同其它子代币不一样的是，deposit 与 withdraw 方法并不调用 mint 或 burn，而是直接 transfer

Ethereum & BSC：

继承自 IMintableERC20 的代币；
BTTC上映射的子代币：继承自 ChildERC20 的代币，有 swapIn、swapOut；
- 其它子代币：
  - 需要与 originToken 进行兑换;
  - 同时要调用 mint、burn 方法，发送事件 Transfer(address(0), account, amount);
- BTT子代币：
  - 没有 originToken，不需要兑换；
  - 直接操作 msg.sender 的 balance 及 _totalSupply，达到 mint、burn 的效果，发送事件 Transfer(address(0x1), msg.sender, msg.value)；

三、总结

3.1 安全

使用侧链进行跨链的风险：

侧链自身的安全性：
- 一旦侧链出现故障，转移到侧链的资产便极有可能丢失；
- BTTC部署了多个节点进行验证和状态同步（StateSync, Checkpoint）
跨链过程的安全性：
- 公证人和侧链的运行节点一旦作恶，便可以从主链上转移用户的资产；
- BTTC侧链采用PoS共识机制，实现了一定程度上的去中心化；

每个侧链交易都会收集Precommit投票，只有超过2/3的节点进行了投票，交易结果才有效；

根链同步BTTC的staking情况，能验证针对侧链状态的Precommit投票。

3.2 vs Polygon

跨链桥
- Polygon 有 Plasma 桥、PoS 桥
  - Plasma 比 PoS 更安全，但资金退出流程复杂，有7天的挑战期；
- BTTC 只有 PoS 桥
支持跨链的公共区块链
- Polygon 目前仅支持 Ethereum；
- BTTC 支持 TRON/Ethereum/BSC；

3.3 侧链 vs 中继

	侧链	中继
从属关系	从属于主链	没有
作用	区块链的可扩展性	跨链数据的传输
实现	将主链上的资产转移到侧链上来处理	从各主链抽象分离出来的一个跨链操作层
代表	Polygon，BTTC	Cosmos，Polkadot

当前页面是本站的「Baidu MIP」版。发表评论请点击：完整版 »

BTTC跨链分享

一、原理

跨链桥

架构

Root Contracts

Child Contracts

代币映射

根链权限

二、跨链流程

2.1 根链 <-> BTTC

deposit

checkpoint

exit withdraw

2.2 根链 <-> 根链

子代币合约

根链代币合约

TRON给其它根链转账

其它根链给TRON转账

BSC给Ethereum转账

Ethereum给BSC转账

2.3 关于 BTT

三、总结

3.1 安全

3.2 vs Polygon

3.3 侧链 vs 中继