共计 2737 个字符，预计需要花费 7 分钟才能阅读完成。
前言
之前写过一篇文章，在百度超级链 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.readthedoc…
每次拜访这个文档都很慢 有没有快速访问的办法？`
- 如果减少一个出块节点
` 有动静增加节点的接口，所以不必重做数据
另外 节点刚退出的时候是先同步数据再出块的 `
- 批改其余配置
须要重做数据（这一点没有公司可能容忍吧，批改一个配置，就须要把之前的历史数据删除掉 而后从新整数据）
对于合约部署这块 呈现签名谬误的起因和解决办法
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.readthedoc…
acl 多签交易时应用的，如果不须要多签名，不须要关注这一块 `
操作日志 未同步这块
` 比方 下面的 部署合约的命令 如果执行报错 会有一个日志编号
拿着日志编号去对应的节点服务上面的日志文件中查看具体的错误信息
比方下面连贯的是 -H localhost:37101 是节点 1，那么只须要去节点 1
上面的日志去找下该日志编号对应的具体日志即可 `
定时出块的劣势和劣势
` 对于这一点 我说的也不够业余 并且我对百度超级链应用的工夫比拟短 钻研的还不太深刻 所以我只能说下 目前的想法 就当作抛砖引玉吧
先说下应用场景吧 而后针对应用场景外面的问题具体论述下
先来类比下比特币
首先比特币在公网有一条 root 链，全世界的交易都产生在该链上，本人在本地启动一个比特币的客户端，都会先同步下 root 链上的交易，而后本人发动的交易，也会上到 root 链上，而后在同步给其余的交易端
而后在看下搭建百度链的过程
A 公司在本人的服务器上搭建了 4 个节点，节点环境搭建好之后，咦？怎么在始终一直的在出块？我本人的服务器内网外面还没有交易上链，怎么始终一直的在出块呢？不是应该同步下公网联盟链上的节点数据嘛？而后才意识到百度超级链是定时出块的，每个 3 秒就会呈现一个块，无论有没有交易，都会出块
由此咱剖析下有哪些劣势
劣势：
1、仅仅是公司外部范畴内应用的数据 并没有其余公司的数据 应用的范畴比拟小，即先搭建一个 root 链，而后在退出的节点才会同步 root 链上的数据，而不是想其余的区块链一样 比方比特币 公网上曾经有一条蕴含全世界交易的 root 链了，而后本人启动一个客户端，会先同步所有的数据
2、无论有没有交易都在定时出块，那么就会累计到很高的高度，但在业务量比拟少的状况下 就会产生大量的空交易的块
3、既然产生大量的空交易的块 那么通过区块高度差值来做区块确认是否正当有待商讨
因为个别的话 确认链有 2 种形式
a、通过以后区块前面追加的区块的数据 如果追加了 6 个区块 即以后区块和最新区块之间的高度差 如果超过 6 个 就认为以后区块确认上链了
b、通过工夫戳 查问以后区块的交易工夫戳和以后时间差 超过肯定的数值也认为是确认上链了
4、一旦配置谬误 须要批改配置的话 那么之前积攒的数据都须要先清空 这一点也是任何公司都不可能容忍产生的事件，所以第一次配置须要很审慎 `
本文应用 mdnice 排版