初始化創(chuàng)世區(qū)塊

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

第一步、生成公私鑰

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

第二步、準備配置

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

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

第三步、執(zhí)行初始化腳本

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

創(chuàng)世區(qū)塊創(chuàng)建過程

假設有四個共識節(jié)點node0、node1、node2、node3、參與共識創(chuàng)建區(qū)塊，那么node0執(zhí)行初始化的腳本時的行為如下，其他節(jié)點行為是一致的：

1、根據(jù)-i和-l參數(shù)加載配置

2、創(chuàng)建初始化配置實例

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

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

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

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

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

8、鏈接數(shù)據(jù)庫，生成當前節(jié)點初始賬本

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

上面創(chuàng)世區(qū)塊兩階段的共識接口定義如下：

public interface LedgerInitConsensusService {
	/**
	 * 請求賬本的初始化許可；
	 * 
	 * @param requesterId
	 *            發(fā)起請求的參與者 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
	 *            調(diào)用者的賬本初始化決議；
	 * @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);

}

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

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]

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

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

結(jié)語

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

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

以上就是java開源區(qū)塊鏈初始化創(chuàng)世區(qū)塊jdchain服務搭建的詳細內(nèi)容，更多關(guān)于java開源區(qū)快聯(lián)初始化創(chuàng)世區(qū)塊jdchain的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論