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

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

第一步、生成公私鑰

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

第二步、準(zhǔn)備配置

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

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

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

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

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

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

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

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

3、校驗(yàn)當(dāng)前節(jié)點(diǎn)公私鑰是否匹配（使用私鑰生成簽名，用公鑰驗(yàn)簽）

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

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

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

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

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

9、在所有參與者之間進(jìn)行第二階段的共識，開始請求所有成員的賬本創(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 目標(biāo)參與方的賬本初始化決議；如果目標(biāo)參與者尚未準(zhǔn)備就緒, 則返回 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)建許可時(shí)，輸出如下異常：

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]

看到這個(gè)輸出，就代表可以排除公私鑰的問題的。因?yàn)檫@個(gè)是最后一步許可，交易哈希許可簽名驗(yàn)證失敗輸出的。而交易哈希是根據(jù)當(dāng)前賬本上下文創(chuàng)建的，當(dāng)前賬本上下文是根據(jù)初始化賬本配置裝載的，所以最后的問題出在初始化賬本的配置上面。我是因?yàn)槔斫忮e(cuò)了下面的配置：

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

結(jié)語

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

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

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

最新評論