前言
之前写过一篇文章，在百度超级链Xuper上部署智能合约并实现存证功能这里叙述了 搭建3个节点 将节点1作为出块节点，这篇文章 咱们配置下将 节点1和节点2作为出块节点，节点3作为同步节点 如何配置以及需要注意的几点，以免读者在操作实践的时候入坑或者由于理解不透彻导致耽误很多时间.
我对百度链使用时间不长，可能理解的比较片面，我写这篇浅文，就当抛砖引玉吧，希望大佬前辈们指出错误的地方或者有其他需要探讨的地方 欢迎发送到我的邮箱（pingfanrenbiji@163.com） 咱们交流下吧
配置多个出块节点
将节点1和节点2配置为出块节点
节点3作为同步节点修改节点1的配置
- 查看节点2的地址
cd pn2
cat data/keys/address
WJHuX9haAL7Sea6rUo8VBhhsQmMJbTopk- 配置到节点1的xuper.json中
- 删除配置项
将 init_proposer_neturl 配置项删除将节点1的配置复制到节点2和节点3
cp pn1/data/config/xuper.json pn2/data/config/xuper.json
cp pn1/data/config/xuper.json pn3/data/config/xuper.json启动每一个节点
先删除节点下面的 data/blockchain/xuper 文件夹
./xchain-cli createChain
nohup ./xchain --vm ixvm &确认下节点2是否在出块
cd pn2
tail -f logs/xchain.log|grep 'isCoreMiner=true'思考：每次修改配置都要删除数据吗
- 如果修改共识算法的话 可以动态配置
通过发起提案的方式
官方文档
https://xuperchain.readthedocs.io/zh/latest/advanced_usage/initiate_proposals.html
每次访问这个文档都很慢 有没有快速访问的方法？- 如果增加一个出块节点
有动态添加节点的接口，所以不用重做数据
另外 节点刚加入的时候是先同步数据再出块的- 修改其他配置
需要重做数据（这一点没有公司能够容忍吧，修改一个配置，就需要把之前的历史数据删除掉 然后重新整数据）关于合约部署这块 出现签名错误的原因和解决方法
javasdk关于连接节点环境
- 第一个圈红的地方是一个ip和port 这个地址可以是多节点环境中的任何一个节点 这里可以做负载均衡
比如有3个节点 通过nginx做负载均衡
所以这里配置的是nginx的ip和port(这一点我没有实践 猜想是可以的)- 关于第二个圈红的地方 keys 表示 读取的是 resources文件夹下面的keys文件夹下面的private.key私钥文件
关于这个私钥文件它是一个节点账户
这里咱结合实际使用过程来说明下这里的注意点a、连接节点环境并读取keys文件夹下面的私钥文件获取账户信息
b、部署合约
./xchain-cli wasm deploy --account XC1111111111112222@xuper --cname eleccertest1 -a '{"creator": "someone"}' -A data/acl/addrs -o tx.output --name xuper -H localhost:37101 /Users/mengfanxiao/Documents/project/company/XinPools_INFO/document/business/baidu/xuperchain/data/blockchain/xuper/wasm/eleccert --fee 5568187 --runtime=go -a '{"owner":"mengfanxiao"}'
此时如果报错
Failed to post tx:TX_SIGN_ERROR
这说明没有获取到当前账户的私钥文件，因为做交易的时候 需要获取操作账户的私钥信息进行签名 那么为什么没有获取到私钥文件呢？
首先看下执行当前命令所使用的客户端是哪个节点 比如 节点3
然后再看 当前连接的节点是哪个节点 -H localhost:37101 这个是节点1
使用节点3的客户端连接节点1的服务是可以的 关键节点3 data/keys/下面是否有XC1111111111112222@xuper 这个合约账户的
私钥文件 data/keys/ 目录下是否具有该合约账户的私钥文件
acl 多签这块
官方文档
https://xuperchain.readthedocs.io/zh/latest/advanced_usage/contract_accounts.html
acl多签交易时使用的，如果不需要多签名，不需要关注这一块
操作日志 未同步这块
比如 上面的 部署合约的命令 如果执行报错 会有一个日志编号
拿着日志编号去对应的节点服务下面的日志文件中查看具体的错误信息
比如上面连接的是 -H localhost:37101 是节点1 ，那么只需要去节点1
下面的日志去找下该日志编号对应的详细日志即可定时出块的优势和劣势
关于这一点 我说的也不够专业 并且我对百度超级链使用的时间比较短 研究的还不太深入 所以我只能说下 目前的想法 就当作抛砖引玉吧
先说下使用场景吧 然后针对使用场景里面的问题具体阐述下
先来类比下比特币
首先比特币在公网有一条root链，全世界的交易都发生在该链上，自己在本地启动一个比特币的客户端，都会先同步下root链上的交易，然后自己发起的交易，也会上到root链上，然后在同步给其他的交易端
然后在看下搭建百度链的过程
A公司在自己的服务器上搭建了4个节点，节点环境搭建好之后，咦？怎么在一直不断的在出块？我自己的服务器内网里面还没有交易上链，怎么一直不断的在出块呢？不是应该同步下公网联盟链上的节点数据嘛？然后才意识到百度超级链是定时出块的，每个3秒就会出现一个块，无论有没有交易，都会出块
由此咱分析下有哪些劣势
劣势：
1、仅仅是公司内部范围内使用的数据 并没有其他公司的数据 使用的范围比较小，即先搭建一个root链，然后在加入的节点才会同步root链上的数据，而不是想其他的区块链一样 比如比特币 公网上已经有一条包含全世界交易的root链了，然后自己启动一个客户端，会先同步所有的数据
2、无论有没有交易都在定时出块，那么就会累计到很高的高度，但在业务量比较少的情况下 就会产生大量的空交易的块
3、既然产生大量的空交易的块 那么通过区块高度差值来做区块确认是否合理有待商榷
因为一般的话 确认链有2种方式
a、通过当前区块后面追加的区块的数据 如果追加了6个区块 即当前区块和最新区块之间的高度差 如果超过6个 就认为当前区块确认上链了
b、通过时间戳 查询当前区块的交易时间戳和当前时间差 超过一定的数值也认为是确认上链了
4、一旦配置错误 需要修改配置的话 那么之前积累的数据都需要先清空 这一点也是任何公司都不能够容忍发生的事情 ，所以第一次配置需要很谨慎
