这篇文章说下使用百度链可能遇到的问题及解决办法html
cat data/config/xuper.json
java
我随便写了一个值 239位node
而后查询下余额能够查到算法
因此就认为没有最大值吧 设置为多少就是多少喽json
若要知道精确的 须要看下源码数组
./xchain-cli transfer --to XC1111111111111111@xuper --amount 2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
安全
有点震惊呐 这么大均可以转帐 哈哈网络
这个帐户我也没有建立 我直接往里面转帐 也是能够的?并发
在转帐的时候同时建立好了这个帐户,但不是合约帐户哦ide
普通帐户和合约帐户能够是同一个帐户名称
咱们再来测试下哈
一、先给一个不存在的帐户转帐
此时会建立这个普通帐户
二、在建立一个同名的合约帐户
印证了上述的猜想
我测试的时候是用的36288长的字符串 是能够的
若是是 36288*2 长度 java代码已经不支持了 超过了java 字符串常量的长度
这里科普下java的基本知识
`a、字符串变量:
String内部是以char数组的形式存储,数组的长度是int类型,那么String容许的最大长度就是Integer.MAX_VALUE = 2^zhi31 - 1 = 2147483647。又因为java中的字符是以16位存储的,所以大概须要4GB的内存才能存储最大长度的字符串。
b、字符串常量:
如“abc”、”1234”之类写在代码中的字符串str,那么容许的最大长度取决于字符串在常量池中的存储大小,也就是字符串在class格式文件中的存储格式:
CONSTANT_Utf8_info {
u1 tag;
u2 length;
u1 bytes[length];
}
u2是无符号的16位整数,所以理论上容许的string str的最大长度是2^16-1=65535。然而实际测试代表,容许的最大长度仅为65534,超过就编译错误。`
既然调用合约是经过java sdk调用 因此字符串最大不能超过java所支持的范围
测试环境
2个出块节点 1个同步节点
分别命名为 节点1 节点2 节点3
使用节点1帐户地址访问节点2
经过java sdk 链接节点1 建立合约帐户 XC1111111111116666@xuper
create account de1dc9e04a2d8b9bbf734f60431ab7eac5843f8711c3fe430c5df345dac272b8
使用节点1的帐户访问节点2
transfer 3d6023d4a1ba08506fdd1e0ee0cc234f6d93f639a708e32ebe8d1d51d8272349
节点1余额查询 1000000000
节点2余额查询 1000000000
节点3余额查询 1000000000
小结:在一个节点建立合约帐户并发起转帐交易 会同步给其余的节点
使用节点1的帐户访问节点3
./xchain-cli wasm deploy --account XC1111111111116666@xuper --cname hello_last_1 --fee 5574291 --runtime go /Users/mengfanxiao/Documents/project/company/XinPools_INFO/document/business/baidu/20200714-最新版本/xuperchain/core/contractsdk/go/example/eleccert_final/eleccert_final.wasm -a '{"creator":"mengfanxiao"}'
在节点1调用合约
`invoke txid: 60b4ee039415ed2e8880212cf182361143f314f988034a669aee5be2a9c6b02a
response:
gas: 100608`
在节点2调用合约
和节点1区别在于 key为 mac1(这个合约的key是惟一的)
`invoke txid: 127ad9ea3c0071dad560fb189b6be054e9fde06dc07d2202171aed5a32f49d3b
response:
gas: 100609`
在节点3调用合约
和节点1区别在于 key为 mac2
`invoke txid: 56cd4547e266423630b6db038692bb04f0730ea207b776f55654d7d0db705717
response:
gas: 100609`
小结:在一个节点部署合约 会同步给其余的全部节点
好比查询 60b4ee039415ed2e8880212cf182361143f314f988034a669aee5be2a9c6b02a
./xchain-cli tx query 60b4ee039415ed2e8880212cf182361143f314f988034a669aee5be2a9c6b02a
在节点一、节点二、节点3查询的交易详情内容一致
小结:在一个节点作的交易会同步给全部的节点
目前我是用的master分支 但不是最新的
当前的区块高度是605
那我想要升级到最新的master代码
一、现将全部节点停掉
二、建立新的文件夹用来存放最新的版本
三、下拉最新的代码并进行编译
四、替换可执行文件
`cp -r output/* lastv-20200729/pn1
cp -r output/* lastv-20200729/pn2
cp -r output/* lastv-20200729/pn3`
五、将上一版本下的data和conf目录替换到最新的
`cp -R pn1/data/ lastv-20200729/pn1/data
cp -R pn1/conf/ lastv-20200729/pn1/conf
cp -R pn2/data lastv-20200729/pn2/data
cp -R pn2/conf lastv-20200729/pn2/conf
cp -R pn3/data/ lastv-20200729/pn3/data
cp -R pn3/conf/ lastv-20200729/pn3/conf`
六、重启
nohup ./xchain --vm ixvm &
节点1能够启动,但节点2启动失败 说明这种升级的方式不对
查看升级文档 https://xuperchain.readthedoc..._guides.html#id2
我上面的思路是建立新的文件夹 将老版本数据复制到新文件夹中
官方文档的思路是 将新的“plugins文件夹, 二进制文件xchain,xchain-cli”这些文件将老版本的替换掉 而后重启便可
`cp -R output/plugins/ pn1/plugins/
cp -R output/xchain pn1/xchain
cp -R output/xchain-cli pn1/xchain-cli
cp -R output/plugins/ pn2/plugins/
cp -R output/xchain pn2/xchain
cp -R output/xchain-cli pn2/xchain-cli
cp -R output/plugins/ pn3/plugins/
cp -R output/xchain pn3/xchain
cp -R output/xchain-cli pn3/xchain-cli`
升级完成 保留了老数据
a、如果新增一个同步节点 不须要修改 创世块配置 不须要删除老数据 只须要修改 yaml文件便可 而后启动便可
https://xuperchain.readthedocs.io/zh/latest/advanced_usage/multi-nodes.html?highlight=%E5%A2%9E%E5%8A%A0%E8%8A%82%E7%82%B9#id1
b、如果新增一个出块节点 这个不只仅须要修改yaml文件还须要修改创世块配置 因此须要删除老数据
此时系统在选择出块节点的算法中会判断该节点是否已同步完成 若已同步完成才会选择该节点做为当前节点
查询的是当前同步到的状态
若是发起一笔上链交易 交易在出块前会在各个节点间转发,该节点挂掉其它节点能够继续打包
加上这个配置就是使用xpos,也就是(tdpos+chainedBFT)
不加就是tdpos,不能保证安全性
很是感谢百度链的技术大牛的支持 超哥
本文使用 mdnice 排版