方案的具体讲解来自《智能合约安全审计入门篇 —— 访问私有数据》，本片文章将在QEasyWeb3测试链上进行数据验证

测试合约

contract Vault {
    uint256 public count = 123;
    address public owner = msg.sender;
    bool public isTrue = true;
    uint16 public u16 = 31;
    bytes32 private password;
    bytes32[3] public data;
    struct User {
        uint256 id;
        bytes32 password;
    }
    User[] private users;
    mapping(uint256 => User) private idToUser;

    constructor(bytes32 _password) {
        password = _password;
    }

    function addUser(bytes32 _password) public {
        User memory user = User({id: users.length, password: _password});
        users.push(user);
        idToUser[user.id] = user;
    }
}

部署合约

通过https://remix.ethereum.org/ 进行部署，具体操作不做详细讲解

网络配置

QEasyWeb3的网络配置，可以查看《QEasyChain 测试链信息》

chain id: 9528

合约操作

合约部署时，构造函数参数bytes32 _password，需要传入初始化参数，用于写入测试状态变量password
例如：0x4141414242424343430000000000000000000000000000000000000000000001

然后通过addUser再添加两个测试数据

• 0x4141414242424343430000000000000000000000000000000000000000000002
• 0x4141414242424343430000000000000000000000000000000000000000000003

执行完成后，开始slot的读取测试。

读取私有slot数据

为了简化操作，我们直接使用python3 + web3py进行测试脚本的编写, 也可以选用其他web3库，大同小异
我们上面合约部署完的合约地址是0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904

测试脚本

import time
from web3 import Web3

w3 = Web3(Web3.HTTPProvider('http://qeasyweb3.com'))

if __name__ == "__main__":
    for i in range(0,7):
        print("slot"+str(i)+" = " + w3.toHex(w3.eth.getStorageAt("0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904",hex(i))))

执行后返回数据如下

slot0 = 0x000000000000000000000000000000000000000000000000000000000000007b
slot1 = 0x000000000000000000001f016bc0e9c6a939f8f6d3413091738665ad1d7d2776
slot2 = 0x4141414242424343430000000000000000000000000000000000000000000001
slot3 = 0x0000000000000000000000000000000000000000000000000000000000000000
slot4 = 0x0000000000000000000000000000000000000000000000000000000000000000
slot5 = 0x0000000000000000000000000000000000000000000000000000000000000000
slot6 = 0x0000000000000000000000000000000000000000000000000000000000000002

• slot0
  存储的为状态变量count的值，等于123的十六进制
• slot1
  由于存储紧凑原则，当前slot存储了3部署数据，从右往左依次是
  • 状态变量owner的值，等于用于部署合约的msg.sender=0x6BC0E9C6a939f8f6d3413091738665aD1D7d2776
  • 状态变量isTrue = 01 = true
  • 状态变量u16 = 1f = 31
• slot2
  存储的为状态变量password
• slot3
  存储的为状态变量data第1个存储值 = data[0]
• slot4
  存储的为状态变量data第2个存储值 = data[1]
• slot5
  存储的为状态变量data第3个存储值 = data[2]
• slot6
  存储的为变长数组状态变量users的长度，当前已执行两次addUser

查看私有变长数组数据

上面我们从slot6中查询到了变长数组users的长度，下面我们继续查看users中存储的数据。

我们先再次回顾下变长数组的存储原则
对于变长数组，会先启用一个新的插槽 slotA 用来存储数组的长度，其数据存储在另外的编号为 slotV 的插槽中。slotA 表示变长数组声明的位置，用 length 表示变长数组的长度，用 slotV 表示变长数组数据存储的位置，用 value 表示变长数组某个数据的值

对应的代码逻辑

length = sload(slotA)
slotV = keccak256(slotA) + index// 索引下标
value = sload(slotV)

依据变长数组的存储以及紧凑打包的原则，所以对于前面两次addUser的数据存储槽位置为

• user1.id == keccak256(slotA) + 0
• user1.password == keccak256(slotA) + 1
• user2.id == keccak256(slotA) + 2
• user2.password == keccak256(slotA) + 3

我们继续使用python3 + web3py进行验证
先计算keccak256(slotA)

print("slot6-keccak = " +w3.toHex(Web3.keccak(hexstr="0x0000000000000000000000000000000000000000000000000000000000000006")))

得到

0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d3f

所以user1和user2的存储槽位置为

• user1.id == 0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d3f
• user1.password == 0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d40
• user2.id == 0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d41
• user2.password == 0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d42

通过测试脚本，获取上面存储槽位置的值

print("user1.id = " + w3.toHex(w3.eth.getStorageAt("0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904", "0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d3f")))
print("user1.password = " + w3.toHex(w3.eth.getStorageAt("0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904", "0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d40")))
print("user2.id = " + w3.toHex(w3.eth.getStorageAt("0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904", "0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d41")))
print("user2.password = " + w3.toHex(w3.eth.getStorageAt("0x4398BdBD9eF8bcACc2A41Abc671BF8f428BB4904", "0xf652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f377c0d42")))

得到数据如下

user1.id = 0x0000000000000000000000000000000000000000000000000000000000000000
user1.password = 0x4141414242424343430000000000000000000000000000000000000000000002
user2.id = 0x0000000000000000000000000000000000000000000000000000000000000001
user2.password = 0x4141414242424343430000000000000000000000000000000000000000000003

经测试与前面两次addUser的数据一致

总结

对于定长数组data，每个元素单独一个存储槽，所以data状态变量依次为slot3-5
对于变长数组users，会先启用一个新的插槽 slotA 用来存储数组的长度，其数据存储在另外的编号为 slotV 的插槽中。slotA 表示变长数组声明的位置，用 length 表示变长数组的长度，用 slotV 表示变长数组数据存储的位置，用 value 表示变长数组某个数据的值

启用optimizer （优化器）后， 优化器会尝试去优化代码，如简化复杂的表达式等，例如常量表达式可能直接优化出计算，以便减少代码大小和执行成本。

runs 很多人有误解，它不是指优化器运行多少次，而是指合约函数未来可能会调用多少次，例如某些锁仓合约只会调用一次，可以将runs值设置为1。 这样编译器会尽可能小的字节码， 减少部署成本（运行时可能会更费 gas）。
如果合约会大量运行，如 token 合约，就可以设为较大的数值，编译器会优化以便在运行时尽可能低 gas 消耗，不过部署时的字节码可能大一些。

EIP712 signatures can generated using the https://eth-account.readthedocs.io/en/stable/eth_account.html#eth_account.messages.encode_structured_data function to encode the EIP712 message, and use web3 to sign it.

msg = { "types": 
{ "EIP712Domain": [], "Type":  []},
  "domain":domain,
  "primaryType": 'Type',
  "message":message }

encoded_data=encode_structured_data(msg)
web3.eth.account.sign_message(encoded_data,privateKey)

https://ethereum.stackexchange.com/questions/114190/how-to-get-eth-signtypeddatav4-signature-in-web3-py

https://www.ethernodes.org/

一、原理

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