andyYuanFZM issues

Results 8 issues of


                                            andyYuanFZM

在solidity合约中定义出错信息： only authorized owner can store files. EVM交易中打印的信息中会多出一些空格符号，有时间可以优化下： receipt": { "ty": 1, "tyName": "ExecPack", "logs": [ { "ty": 1, "tyName": "LogErr", "log": "evm: execution reverted,detail: \u0008\ufffdy\ufffd\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000 \u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0026only authorized owner can...

共识节点配置灵活性问题

**Describe the bug** 目前共识节点的配置通过配置文件设置 validatorNodes=["172.16.43.151:46656","172.16.43.152:46656","172.16.43.153:46656","172.16.43.154:46656"] ，共识节点ip变化或者用户配置不一致，影响链的运行。 **To Reproduce** 1. 配置文件 node1 validatorNodes=["172.16.43.151:46656","172.16.43.152:46656","172.16.43.153:46656"] 配置node2 validatorNodes=["172.16.43.151:46656","172.16.43.152:46656","172.16.43.154:46656"] 停掉node3 配置node4 validatorNodes=["172.16.43.152:46656","172.16.43.153:46656","172.16.43.154:46656"] 2 node1 node2 node4 启动，发转账交易区块没有产生 **Expected behavior** 可选方案: 每个共识节点已经有私钥和证书，可以通过共识节点的证书来识别，不用通过配置。共识节点的证书已经在 genesis.json 声明过。而且共识节点ip变化也不影响。

[raft共识] raft共识多机多容器部署出现panic

部署方式：三台主机，每台主机运行docker, 每个docker下运行chain33。问题: 出现panic, listen tcp 192.168.6.186:9021, bind: cannot assign requested address. @harrylee2015 这个问题，你帮忙看下。

联盟链及平行链上的数据备份方案

联盟链（以及联盟链下挂平行链）的情况下，数据都是全量保存，比较占用存储空间。需要提供一套数据备份方案，来释放存储空间。有以下两种可选方案: 1. 数据冷备份方案。（比如像物流的数据，可能1年前的数据就不会频繁去查询，可以考虑将历史区块数据冷备份存放） 2. 区块数据分片（适用于联盟主链） 3. 对接tidb，tidb数量越多，相对单个节点存储量越少。

联盟链共识中消息流程简化

联盟链采用了聚合签名的方案，简化共识过程中的消息交互。流程如下： 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。

[人民银行分布式账本安全规范增强] 实现一套账户管理的智能合约。

实现一套账户管理的智能合约，包括账户的生成，授权，冻结，解冻，锁定，恢复等功能。

借贷合约支持多资产类型抵押

目前抵押的资产只支持coins，需要增加token类型的资产抵押。这样合约能区分资产的来源（是来自BTY，还是BTC或是ETH），后续多资产的情况下，平仓和赎回的处理也能比较容易处理。

andyYuanFZM