Delivery层初始化配置

首先需要和bttc层一样准备一个genesis配置，如果是同步现有测试网或者主网，可以官方仓库拿到

主网：https://github.com/bttcprotocol/launch/blob/master/mainnet-v1/without-sentry/delivery/config/genesis.json

测试网：https://github.com/bttcprotocol/launch/blob/master/testnet-1029/without-sentry/delivery/config/genesis.json

如果是启动私链也可以自己创建，deliveryd程序也提供了初始化测试链的功能，比如需要创建一个私链，3个验证者2个同步节点

./deliveryd create-testnet --v 3 --n 2 --output-dir ./output --chain-id delivery-9528

执行完成后，会自动创建5个节点对应的配置文件，每份主要的配置如下

genesis.json

初始化链配置，主要关心以下字段

• chain_id 链id

• app_state->accounts 初始化账户资金等信息

• bor->spans->validator_set->validators 初始化验证者信息

• bor->spans->validator_set->proposer 初始化提案者信息

• bor->spans->selected_producers 初始化当前生产者信息

• bor->spans->bor_chain_id bttc层链id

• chainmanager->chain_params 链合约相关地址

• checkpoint 配置相关参数

• gov 治理相关参数

• slashing 惩罚相关参数

• staking 初始化相关地址抵押量

对于私链，在初始化数据基础上，主要关注chain_id和chain_params，其余地址相应数据使用默认即可

config.toml

链基础配置，主要关心参数如下

• fast_sync：是否开始快速同步

• db_dir: 数据的存放位置

• genesis_file：genesis.json存放位置

• priv_validator_key_file：验证者私钥文件位置

• priv_validator_state_file：验证者状态文件位置

• node_key_file：节点密钥存放位置

• persistent_peers：持久链接的peer地址，类同于eth的staticnode

• private_peer_ids: 私有的节点id, 用于隐私接入，比如哨兵节点

  • 登录验证人节点.
  • 运行 deliveryd tendermint show-node-id. 示例: private_peer_ids = "e2c6a611e449b61f2266f0054a315fad6ce607ba"

delivery-config.toml

RPC和 REST配置，主要关心参数如下

• eth_rpc_url：eth链RPC地址

• bsc_rpc_url：bsc链RPC地址

• bttc_rpc_url：bttc层RPC地址

• tron_rpc_url：tron链RPC地址

• 测试网：47.252.19.181:50051

• tron_grid_url：tron链grid地址

• 测试网：https://test-tronevent.bt.io

• amqp_url：AMQP地址，在bridge过程中会用于任务的消息队列

node_key.json

节点的密钥信息，可以使用工具自动生成

priv_validator_key.json

节点验证者的密钥信息，可以使用工具自动生成

对于单节点测试，也可以直接执行初始化

./deliveryd init --chain-id delivery-9528 --home ./

BTTC层初始化配置

创世块包含配置网络的所有基本信息。它基本上是 Bor 链的配置文件。要启动 Bor 链，用户需要将文件的位置作为参数传递。

Borgenesis.json用作创世块和参数。这是 Bor 创世纪的一个例子config：

"config": {
    "chainId": 15001,
    "homesteadBlock": 1,
    "eip150Block": 0,
    "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "bor": {
      "period": 1,
      "producerDelay": 4,
      "sprint": 64,
      "backupMultiplier": 2,
      "validatorContract": "0x0000000000000000000000000000000000001000",
      "stateReceiverContract": "0x0000000000000000000000000000000000001001"
    }
  }

bor配置参数解释

period：出块时间

producerDelay：两次sprint之间的时间

sprint：每次sprint的块数

backupMultiplier：确定摆动时间的备用乘数 「后加」

validatorContract：Bor验证者集创始合约地址

stateReceiverContract：状态接收者创世合约地址

bor初始验证者地址设置

bttc层bor共识第一个sprint周期内的验证者集合，是从初识化合约中硬编码的数据获取的，

对于genesis中alloc->0000000000000000000000000000000000001000->code

默认的验证者地址是在BorValidatorSet.sol合约中的getInitialValidators设置的（查看代码）

/// Get current validator set (last enacted or initial if no changes ever made) with current stake.
  function getInitialValidators() public view returns (address[] memory, uint256[] memory) {
    address[] memory addrs = new address[](3);
    addrs[0] = 0xfA841eAAcf03598bAadF0266eF6097C654DE5465;
    addrs[1] = 0x80CFb197Be875eE45294AC31406E6483e3eAb02E;
    addrs[2] = 0x0aB3ab4542ED5FA2A67B2B8DAbC82C42162853A6;
    uint256[] memory powers = new uint256[](3);
    powers[0] = 1;
    powers[1] = 1;
    powers[2] = 1;
    return (addrs, powers);
  }

对于私链的自定义可以通过提供的模版方式进行修改

首先clone https://github.com/bttcprotocol/genesis-contracts.git

然后修改初始化验证者列表，为自己需要的地址集合

https://github.com/bttcprotocol/genesis-contracts/blob/master/validators.json

然后就可以生成我们自己的初始合约

node generate-borvalidatorset.js --bttc-chain-id 9527 --delivery-chain-id delivery-9527
--bttc-chain-id：是对应bttc层的链id
--delivery-chain-id: 是设置delivery层的链id

重新创建后getInitialValidators中获取的就是我们自定义的初始话验证者地址集合了

使用genesis初始化bttc层启动后，第一个sprint周期内，会使用自定义的验证者集合进行出块，

查询此初始期间block的miner为0x0000000000000000000000000000000000000000

默认的话，下一周期开始与delivery层进行数据获取 // TODO

如果是为了单独测试bttc层，避免delivery层的干扰，可以禁用delivery层，也就是第一个sprint周期后，也不会向

delivery层获取验证者集合，一直消费合约初始化的验证者集合。

关闭delivery层链接的方式是，启动参数添加

--bor.withoutheimdall

需要注意，当前最新代码，该withoutheimdall参数目前只支持启动参数传入，config方式参数未支持。

如果添加参数后，将会执行WithoutHeimdall判断逻辑，相应的代码逻辑为

miner->commitNewWork->commit->FinalizeAndAssemble->(headerNumber%c.config.Sprint == 0)->checkAndCommitSpan->needToCommitSpan->fetchAndCommitSpan->WithoutHeimdall
getNextHeimdallSpanForTest / HeimdallClient.FetchWithRetry

周期验证者地址确认后，将和其他pos链一样，各个当前周期验证者进行依次出块，以及区块同步，这里就不多做解释了

bttc官方提供的脚本环境

主网：https://github.com/bttcprotocol/launch/tree/master/mainnet-v1/without-sentry/bttc

测试网：https://github.com/bttcprotocol/launch/tree/master/testnet-1029/without-sentry/bttc

"bor": {
      "period": 2,
      "producerDelay": 6,
      "sprint": 64,
      "backupMultiplier": 2,
      "validatorContract": "0x0000000000000000000000000000000000001000",
      "stateReceiverContract": "0x0000000000000000000000000000000000001001",
      "overrideStateSyncRecords": {
      },

问题已在以下issue中被讨论
https://github.com/ethereum/go-ethereum/issues/22308
目前先尝试bsc中的方案，验证后再做补充
https://github.com/bnb-chain/bsc/pull/570

侧链

优点

实现上相对简单易用

缺点

但需要在信任侧链的基础之上，如果侧链失败（意味着共识机制受到损害），您可能会损失所有资金。

相对解决

通常是只跨小额临时使用的代币，将风险人为控制降低。

plasma

优点

plasma在设计上比侧链更安全。（用户可以使用区块根来表明他们在 Plasma 链上收到了资金，如果 Plasma 链共识机制停止创建区块，用户可以使用区块根向以太坊提出索赔）

缺点

不能真正进行与侧链相同的复杂操作。不做信任假设来保证资金安全，所以我们总是不得不假设 Plasma 链共识机制随时可能失败，需要围绕它进行设计。这对 Plasma 链上可能发生的事情增加了额外的限制。主要缺点是你不能真正进行与侧链相同的复杂操作

参考

https://docs.plasma.group/en/latest/src/plasma/sidechains.html

部署仅在技术方案调研角度，客观测试，仅作记录
先草稿记录，后续再做整理

现有主网或者测试网

对于现有主网或者测试网节点的加入可参考
https://github.com/bttcprotocol/launch
环境进行运行，注意下脚本默认运行目录在home目录，可以通过执行--home 参数进行相应变更。

私链搭建

一方面为了技术调研，目前需要做的是搭建一个完整的BTTC私链
主要分为三部分进行测试部署

1. BTTC生产层

github: https://github.com/bttcprotocol/bttc.git
对于bttc，是从go-ethereum修改而来，简单来说这一层负责区块的生产
https://doc.bt.io/zh-Hans/docs/basics/bttc-basics/bttc-pos-architecture#bttc-%E5%8C%BA%E5%9D%97%E7%94%9F%E4%BA%A7%E8%80%85%E5%B1%82

2. Delivery层

github: https://github.com/bttcprotocol/delivery
负责区块验证、Bttc层区块生产者的选择、代表Bttc层状态检查点的验证和提交,以及其他各种责任。
https://doc.bt.io/zh-Hans/docs/basics/bttc-basics/bttc-pos-architecture#delivery-pos%E5%B1%82

3. 部署在TRON网络上的质押管理合约

Staking合约

从出块共识来说

简单来说，相对其他go-ethereum修改的pos链，Bittorrent-Chain的选举是在TRON网络上的质押管理合约中的，然后通过Delivery层进行数据的验证者的排名，然后bttc更新验证者排名时从Delivery层获取，作为下次出块周期的验证者列表。

测试私链

根据bttc的三层实现，计划私链的启动顺序如下

1. 仅bttc层，完成私链搭建
   来验证bttc层genesis参数，初始化周期验证者的选择逻辑，以及一些启动参数的测试
2. TRON测试网络部署相关合约
   来验证合约的编译和部署过程，为下一步与Delivery层结合做准备
3. bttc + Delivery层 + TRON网络上的质押管理合约
   整体测试

bttc层私链搭建

先使用官方的测试例子，测一下
https://github.com/bttcprotocol/contracts/tree/stake/test-blockchain
从中找到genesis模板
https://github.com/bttcprotocol/contracts/blob/stake/test-blockchain/genesis.json.template
https://github.com/bttcprotocol/bttc/blob/master/tests/bor/testdata/genesis.json

从确认初始化验证者加入方式，重点关注validatorContract合约，对应地址0x0000000000000000000000000000000000001000
常规的初始化验证者的加入，时添加到extraData或者其他数组数据设置，从demo没看到对用的数据，然后调试整体代码

调试整体代码

miner->commitNewWork->commit->FinalizeAndAssemble->(headerNumber%c.config.Sprint == 0)->checkAndCommitSpan->needToCommitSpan->fetchAndCommitSpan->WithoutHeimdall
getNextHeimdallSpanForTest / HeimdallClient.FetchWithRetry

发现bttc层溜了一个测试开关，

--bor.withoutheimdall

启动参数添加后，进入Test模式，也就是bttc下一周期（genesis配置的Sprint，默认64）的验证者列表会执行getNextHeimdallSpanForTest继续从合约中初始数据中获取

GetCurrentValidators->getBorValidators

修改初始化验证者地址

默认的验证者地址是在getInitialValidators设置的
https://github.com/bttcprotocol/genesis-contracts/blob/63b72f1ca9a20064d4e700b026ca631335717b4b/contracts/BorValidatorSet.sol#L216

  /// Get current validator set (last enacted or initial if no changes ever made) with current stake.
  function getInitialValidators() public view returns (address[] memory, uint256[] memory) {
    address[] memory addrs = new address[](3);
    addrs[0] = 0xfA841eAAcf03598bAadF0266eF6097C654DE5465;
    addrs[1] = 0x80CFb197Be875eE45294AC31406E6483e3eAb02E;
    addrs[2] = 0x0aB3ab4542ED5FA2A67B2B8DAbC82C42162853A6;
    uint256[] memory powers = new uint256[](3);
    powers[0] = 1;
    powers[1] = 1;
    powers[2] = 1;
    return (addrs, powers);
  }

需要修改成我们自己的私链初始化验证者地址

编译系统合约

1. Clone code

   git clone https://github.com/bttcprotocol/genesis-contracts.git

2. 修改我们私链的初始化验证者地址
   https://github.com/bttcprotocol/genesis-contracts/blob/master/validators.json

   [
   {
    "address": "0xfA841eAAcf03598bAadF0266eF6097C654DE5465",
    "stake": 1,
    "balance": 300000000
   },
   {
    "address": "0x80CFb197Be875eE45294AC31406E6483e3eAb02E",
    "stake": 1,
    "balance": 300000000
   },
   {
    "address": "0x0aB3ab4542ED5FA2A67B2B8DAbC82C42162853A6",
    "stake": 1,
    "balance": 300000000
   }
   ]

3. 生成我们私链的合约

   node generate-borvalidatorset.js --bttc-chain-id 9527 --delivery-chain-id delivery-9527

4. Install dependencies and submodules

   $ npm install
   $ git submodule init
   $ git submodule update

5. Compile Bttc contracts
   切记！！node需要v11版本！

   nvm install v11
   nvm use v11

   下面truffle:compile依赖docker
   https://desktop.docker.com/mac/main/amd64/Docker.dmg?utm_source=docker&utm_medium=webreferral&utm_campaign=docs-driven-download-mac-amd64

   $ cd bttc-contracts
   $ npm install
   $ node scripts/process-templates.js --bttc-chain-id <bttc-chain-id> // 9527
   $ npm run truffle:compile
   $ cd ..

附加

如果不加开关将会

--bor.heimdall "http://localhost:1317" 

第一轮（sprint 64）验证者 Signer 是从系统合约getBorValidators，获取的固定的信息，
查询此期间block的miner为
0x0000000000000000000000000000000000000000
下一周期开始与delivery层进行数据获取

参考：https://doc.bt.io/zh-Hans/docs/basics/bttc-basics/bttc-pos-architecture

参考

项目官网：https://bt.io/
github: https://github.com/bttcprotocol
官方文档：https://doc.bt.io/zh-Hans/