百度區塊鏈所遇到的問題及處理彙總

時間 2021-02-15

標籤 html java node 算法 json 數組安全網絡併發 ide 欄目比特幣简体版

原文原文鏈接

前言

這篇文章說下使用百度鏈可能遇到的問題及解決辦法html

創世節點帳戶餘額最大值

cat data/config/xuper.json java

我隨便寫了一個值 239位node

而後查詢下餘額能夠查到算法

因此就認爲沒有最大值吧設置爲多少就是多少嘍json

若要知道精確的須要看下源碼數組

轉帳金額大小有限制嗎

./xchain-cli transfer --to XC1111111111111111@xuper --amount 2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 安全

有點震驚吶這麼大均可以轉帳哈哈網絡

這個帳戶我也沒有建立我直接往裏面轉帳也是能夠的？併發

在轉帳的時候同時建立好了這個帳戶，但不是合約帳戶哦ide

普通帳戶和合約帳戶能夠是同一個帳戶名稱

咱們再來測試下哈

一、先給一個不存在的帳戶轉帳

此時會建立這個普通帳戶

二、在建立一個同名的合約帳戶

印證了上述的猜想

調用合約保存K-V Key和Value長度有限制嗎

我測試的時候是用的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

建立一個合約帳戶並轉帳看在其餘的節點是否有同步過去

在節點2建立一個合約帳戶

使用節點1帳戶地址訪問節點2

經過java sdk 鏈接節點1 建立合約帳戶 XC1111111111116666@xuper

create account de1dc9e04a2d8b9bbf734f60431ab7eac5843f8711c3fe430c5df345dac272b8

給該合約帳戶轉點錢

使用節點1的帳戶訪問節點2

transfer 3d6023d4a1ba08506fdd1e0ee0cc234f6d93f639a708e32ebe8d1d51d8272349

分別查看節點一、節點二、節點3的該合約帳戶的餘額

節點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`

小結：在一個節點部署合約會同步給其餘的全部節點

到不一樣的節點查看一個hash值看是否都一致

好比查詢 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`