网络信息

注意

以上为测试链，代币无任何价值
当前为技术预览阶段，链数据可能重置

探索商业公链解决方案服务https://ethdpos.com/

对于Windows WSL的安装和对应镜像安装此片不做具体介绍，本篇文章只介绍Goland配置
首先Goland 打开相应代码项目后

通过菜单 File->Settings
打开Settings设置

Run Targets配置

打开Run Targets配置

然后添加 WSL

选择自己本地对应的WSL

根据自己WSL镜像中的go配置，选择对应的目录

然后修改编辑当前编译项目配置，选择前面设置的Targets

最后保存即可在WSL编译项目了

一、原理

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. 实现子代币合约
   1. 标准子代币（20,721）：继承项目代码中 的 ChildERC20，确保有deposit以及withdrawTo方法
   2. 自定义子代币：实现自己的子代币合约
2. 将子代币合约部署到 BTTC 网上
   1. 参考 deploy_child_chain_contracts.js进行部署；
   2. 部署时需要 BTTC 上的 ChildChainManager 合约地址；
3. 提交映射请求
   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。

二、跨链流程

前提

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

目前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 同步流程

1. 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]

1. 这些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()),
   ),
})

1. bridge 监听到该事件，proposer 将创建和广播 checkpoint tx 给对应的根链。
2. 给 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;
}

1. ETH、BSC 执行该 tx 后，会 emit NewHeaderBlock 事件
2. TRON 处理流程相同
3. 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转账

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

BSC给Ethereum转账

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

Ethereum给BSC转账

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

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 中继

https://www.toptal.com/ethereum/one-click-login-flows-a-metamask-tutorial
https://amaurym.com/login-with-metamask-demo/

一、介绍

有人把Tendermint当成一个共识，有人把它当成一个通信组件。这都是可以理解的。Tendermint融合了共识和网络通信部分。它类似于一个软件包，通过使用Tendermint可以很容易的开发一个和Cosmos相兼容的区块链（当然，如果使用Cosmos-sdk会更简单，但是会屏蔽更多的细节）。可以把它理解成Cosmos的一个底层架构，提供类似于基础服务的一个平台。Tendermint可以提供一个Cosmos标准的跨链的基础应用。

通过上面这个图可以看出Tendermint在整个Cosmos生态中的位置。Tendermint Core是所有Cosmos生态中区块链的核心（上图中的淡绿色部分），提供了DPOS+BFT的共识机制。Cosmos Hub提供了不同区块链的之间的交互和价值转移。各个区块链应用之间通过IBC接口进行通信。

二、整体架构

1、BFT

Tendermint使用的共识算法是拜占庭容错共识协议，它是来源于DLS共识算法。使用这种算法的目的是可以简单方便的解决区块链的分叉机制。这种BFT的机制要求有固定的一组验证人，然后他们会尝试在某个区块上达成共识。每个区块的共识轮流进行，每一轮都有一个提议者来发起区块，之后由验证人来决定是否接受区块或者进入下一轮投票。

Tendermint采用由绝对多数的选票（三分之二）待定的最优拜占庭算法。因此它可以确定的做到：

如果想做恶，必须要有三分之一以上的选票出现问题，并且提交了两个值。
如果任何验证组引起安全问题，就会被发现并对冲突进行投票，同时广播有问题的那些选票。
因为使用了BFT，所以其共识的速度在所有的共识中最相当快速的，很容易达到并维持每秒千笔交易的速度。

2、P2P

Tendermint中的网络底层通信，使用的是一种普通的反应器，它通过参数来查找需要连接的P2P节点，在Tendermint的节点连接中，维护着两组映射来管理连接自己和自己连接的对象，分别称做inbound,outbound.
outbound中，有两种连接，一种是连接时指定的seed,一种是在初始化时检测出来的节点。一般情况下，outbound的数量少于10个。而inbound控制在50个左右的连接。
既然是基于反应器的，那么编程的复杂性就大大降低了。只需要服务监听就可以了。这里不再细节赘述网络通信部分。
网络在启动时，会启动一个协程，定时轮询outbound的数量，来控制连接的稳定性。

3、架构

Tendermint的设计目的是为了创建一个统一的区块链开发的基础组件。通过将区块链中主要的P2P和共识抽象出来，实现区块链开发过程中的组件式管理。这样做的优势有以下几点：

一个是代码重用。对通用的网络通信和共识就不必再重复的造轮子。

二是解放了区块链编程的语言。比如以太坊用go,c++，但是通过Tendermint的抽象后，可以使用任何语言（觉得和当初JAVA才提出时一次编译的想法有些相似啊）。特别是对于智能合约，这个优点就更显得明显了。

4、Tendermint的共识过程

Tendermint共识机制中通过作验证人（Validators）来对区块达成共识，这个在前面已经介绍过，一组验证人负责对每一轮的新区块进行提议和投票。整个共识达成的过程如下图所示。

每一轮的开始（New Round），节点对新一轮的区块进行提议。之后，合格的提议区块首先经过一轮预投票（Prevote）。在提议区块获得2/3以上的投票后，进入下一轮的预认可（Precommit），同样是待获得2/3以上的验证人预认可后，被提议区块就正式获得了认可（Commit）。而得到认可的这个区块就被添加的到区块链中。

下面为详细的过程：

在Tendermint算法中，如果遇到对同一特定区块的同意及否决信息同时超过2/3的情况，需要启用外部的维护机制去核查是否存在超过1/3的验证节点伪造签名或者投出双重选票。

5、Tendermint的交易流程

当一个Tx进来时, Tmcore的mempool(MP)会通过mempool connection(一个socket连接，由abci-server提供)调用Application Logic(AL:也就是abci-app，我们自己用任何语言编写的APP逻辑)里的checkTx方法，AL向MP返回验证结果。MP根据验证结果通过或者拒绝该Tx。

Tendermint(TM)把tx暂存在内存池（mempool）里，并把这条Tx通过P2P网络复制给其它TM节点。TM发起了对这条Tx的拜占庭共识投票，所有Tendermint节点都参与了。投票过程分三轮，第一轮预投票（PreVote），超过2/3认可后进入第二轮预提交（PreCommit），超过2/3认可后进入最后一轮正式提交（Commit）

TM提交Tx时依次通过Consensus Connection(一个socket连接，由abci-server提供)向ABCI-APP发送指令BeginBlock-->多次DeliverTx-->EndBlock-->Commit，提交成功后会将StateRoot(application Merkle root hash)返回给TM,TM New出一个区块。

如下图所示的交易流程图：

三、总结

通过上面的分析可以看到，其实Tendermint的重点在于共识和P2P，将二者抽象出来的有利之处在于，可以让开发者忽略对网络通信和共识的复杂性。直接进行业务层面的开发，而SDK的封装，进一步减少了业务上对非相关的逻辑的考虑，大大减少了开发者生产一条区块链的复杂度，而这也恰恰是Tendermint和cosmos-sdk所想达到的目的。

转载自：https://zhuanlan.zhihu.com/p/295557240