java開源區塊鏈初始化創世區塊jdchain服務搭建

Posted on by

初始化創世區塊

搭建區塊鏈服務第一步就是初始化創世區塊，創建賬本。生成dchain初始化創世區塊有兩種方式，一種是通過官方提供的區塊鏈部署工具，在頁面上操作初始化，一種是通過初始化腳本創建。目前，部署工具初始化賬本功能有限，隻支持btfsmart共識算法的節點初始化，如果要支持mq的共識，隻能使用初始化賬本的腳本創建

第一步、生成公私鑰

使用部署工具生成公私鑰，雖然部署工具不支持mq共識的賬本初始化，但是還是可以用部署工具幫我們創建並維護公私鑰，這種方式比使用腳本創建要方便很多。

第二步、準備配置

jdchain初始化賬本需要三個配置，賬本配置 ledger.init，本地節點配置：local.conf ，共識服務配置:bftsmart.config 或mq.config，其中local.conf是每個共識節點特有的配置，賬本和共識服務配置需要同步到每個節點。

更多配置詳情參考：https://github.com/blockchain-jd-com/jdchain

第三步、執行初始化腳本

配置準備好後，先找到ledger-init.sh腳本，然後修改其中-i 和-l參數，指定第二步配置好的配置地址。然後依次執行。如果配置正確無誤，會提示初始化服務已準備好，按任意鍵開始初始化賬本。這時回車即可，初始化成功後，會在config/init目錄下生成ledger-binding.conf文件。啟動節點服務就需要這個配置文件

創世區塊創建過程

假設有四個共識節點node0、node1、node2、node3、參與共識創建區塊，那麼node0執行初始化的腳本時的行為如下，其他節點行為是一致的：

1、根據-i和-l參數加載配置

2、創建初始化配置實例

3、校驗當前節點公私鑰是否匹配（使用私鑰生成簽名，用公鑰驗簽）

4、初始化賬本，實例化本地事務上下文，生成創世交易

5、對初始交易簽名，生成當前節點的賬本初始化許可(使用當前事務上下文對象的哈希和當前節點私鑰生成簽名)；

6、在所有參與者之間進行第一階段的共識，請求所有其它參與方的賬本創建許可,依次請求node1、node2、node3的/legerinit/permission/接口，對方接口會進行簽名校驗，和過程3的方式一致

7、使用當前節點事務交易上下文作為哈希校驗其他節點返回的接入許可簽名，此過程如果失敗，會重試16次

8、鏈接數據庫，生成當前節點初始賬本

9、在所有參與者之間進行第二階段的共識，開始請求所有成員的賬本創建決定，如果都返回決議創建就提交賬本，否則就回滾。此過程也會重試16次

上面創世區塊兩階段的共識接口定義如下：

public interface LedgerInitConsensusService {
	/**
	 * 請求賬本的初始化許可；
	 * 
	 * @param requesterId
	 *            發起請求的參與者 id；
	 * @param signature
	 *            請求者的私鑰對 “id” + “賬本種子” 做出的簽名；隻有簽名合法且參與者是初始化配置中的參與方才能獲得有效返回，否則將被拒絕；
	 */
	@HttpAction(path = "/legerinit/permission/{requesterId}", method = HttpMethod.POST, contentType = LedgerInitMessageConverter.CONTENT_TYPE_VALUE, responseConverter = PermissionResponseConverter.class)
	LedgerInitProposal requestPermission(@PathParam(name = "requesterId") int requesterId,
			@RequestBody(converter = SignatureDigestRequestBodyConverter.class) SignatureDigest signature);
	/**
	 * 同步賬本初始化決議；
	 * 
	 * @param initDecision
	 *            調用者的賬本初始化決議；
	 * @return 目標參與方的賬本初始化決議；如果目標參與者尚未準備就緒, 則返回 null；
	 */
	@HttpAction(path = "/legerinit/decision", method = HttpMethod.POST, contentType = LedgerInitMessageConverter.CONTENT_TYPE_VALUE, responseConverter = DecisionResponseConverter.class)
	LedgerInitDecision synchronizeDecision(@RequestBody(converter = DecisionRequestBodyConverter.class) LedgerInitDecision initDecision);

}

遇到的問題：在請求其它參與方的賬本創建許可時，輸出如下異常：

Invalid permission from participant! --[Id=LdeNn8bWuc2DaqAbx3XCQPUf7bdb94PTKFT2E][name=node1.com]
Invalid permission from participant! --[Id=LdeNezcG3rhs31u8UBSwvfMf2BKr1ZkaLKJAG][name=node2.com]
Invalid permission from participant! --[Id=LdeNqxGmBdmEZK6hVeLcnXppW2qnLLKMMiQhN][name=node3.com]

看到這個輸出，就代表可以排除公私鑰的問題的。因為這個是最後一步許可，交易哈希許可簽名驗證失敗輸出的。而交易哈希是根據當前賬本上下文創建的，當前賬本上下文是根據初始化賬本配置裝載的，所以最後的問題出在初始化賬本的配置上面。我是因為理解錯瞭下面的配置：

# 當前賬本交易發送隊列主題（不同賬本需不同主題）
system.msg.queue.topic.tx=node3-topic

結語

jdchain的各組件設計的比較靈活，如共識實現可以使用bftsmart、RabbitMQ等，底層存儲也可以使用本地的rocksdb也可以使用redis等。

如果有特殊的需求也可以自己實現定義的api接口。博主第一天使用的都是默認的的提供者實現，安裝部署都比較順利，今天嘗試使用RabbitMQ的共識時遇到瞭好幾個問題，首先是上面的交易許可驗簽的問題，然後目前官方的基於RabbitMQ的共識，RabbitMQ的鏈接器不支持帶用戶認證的mq的配置。不過問題都已解決瞭，支持amqp的配置代碼也已給官方倉庫提交pr瞭，算正式踏入區塊鏈研究之路瞭

以上就是java開源區塊鏈初始化創世區塊jdchain服務搭建的詳細內容，更多關於java開源區快聯初始化創世區塊jdchain的資料請關註WalkonNet其它相關文章！

推薦閱讀：