plugin
plugin copied to clipboard
33cn
chain33 官方插件系统
1. 平行链交易支持只在某个通道上打包，通道可以是对总通道的取余 2. 不同平行链在主链上使用通道来分割 3. 交易结构增加一个通道的参数，打包区块只打包符合通道的交易
联盟链（以及联盟链下挂平行链）的情况下，数据都是全量保存， 比较占用存储空间。 需要提供一套数据备份方案，来释放存储空间。有以下两种可选方案: 1. 数据冷备份方案。 （比如像物流的数据，可能1年前的数据就不会频繁去查询，可以考虑将历史区块数据冷备份存放） 2. 区块数据分片 （适用于联盟主链） 3. 对接tidb，tidb数量越多，相对单个节点存储量越少。
**描述错误** x2ethereum 合约 CI 偶发不通过。 [https://github.com/33cn/plugin/pull/905/checks?check_run_id=1240532860](https://github.com/33cn/plugin/pull/905/checks?check_run_id=1240532860) **错误发生场景** ETH2Chain33Erc20 4 个 relayer 暂停 C 和 D 两个 relayer， relayerA lock 100 Erc20 to Chain33， 重新启动 C 和 D 两个 relayer，但是 chain33...
两核4G的虚拟机运行 chain33，mempool 模块处理交易的速度大概为 每秒1000多笔 测试方案： 1. 使用 solo 共识，benchMode 设置为 true 2. 使用发交易工具向节点发送交易，统计从构造交易并发送到回显交易哈希的时间 3. 在不同于chain33运行的节点上（机器配置相同），启动一个进程发送交易，发送1万笔交易统计时间为 10 秒左右，solo 共识打包时间间隔也为 10 秒 4. 在两个节点上分别启动进程发交易，发送1万笔交易统计时间均为 20 秒左右，solo 共识打包时间间隔为 10 秒 5. 多个节点进行实验，结果也一致 交易处理速度跟...
https://github.com/33cn/plugin/blob/7e23d4936ffb2346d8dc3f523d87e3d49858e0bf/chain33.toml#L91 系统自动识别全节点和非全节点。并且在非全节点出问题的时候，去全节点获取数据，不需要我们去配置全节点。 全节点可以作为 dht 网络中的一些数据，用dht网络的路由规则，可以查找到对应的key。
我们目前已经支持了纯 go版本的 jsvm，实现的时候可以参考这个的实现。 虚拟机可以参考这个：https://github.com/zxh0/jvm.go 纯go 版本的虚拟机主要方便用户使用和调试，并且可以保证跨平台，可能会存在部分bug。
联盟链采用了聚合签名的方案，简化共识过程中的消息交互。 流程如下： 1. peer0发送proposal给peer1~peerN 2. peer1--peerN进入到prevote阶段，对区块签名，发prevote给peer0. 3. peer0收集prevote，聚合签名后回响应给peer1--peerN，这些节点验证签名通过后，再进入precommit阶段，发precommit消息给peer0 4. peer0收集precommit消息，将precommit聚合签名后，发给peer0--peerN。 peer0--peerN收到聚合消息，并验证通过后，进入commit阶段。 目前的实现，简化了消息的流程，但是步骤3和4都要等到打包节点的响应，才能进入下一阶段，在节点数比较少的情况下，性能提升并不明显（曹平做过验证）。 所以讨论，简化prevote阶段的等待如下： 1. peer0发送proposal给peer1~peerN 2. peer1--peerN进入到prevote阶段，对区块签名，发prevote给peer0. 同时不等peer0响应，直接进入precommit阶段,构造precommit消息给peer0. 3. peer0收集prevote，记录prevote的结果（是否满足2/3）。 4. peer0收集precommit消息，同时判断之前记录的prevote的结果，两者都满足2/3的条件，进入commit, 同时将precommit聚合签名后，发给peer0--peerN。 peer0--peerN验证签名后，进入commit。