前言

搭建区块链服务第一步就是初始化创世区块，创建账本。生成dchain初始化创世区块有两种方式，一种是通过官方提供的区块链部署工具，在页面上操作初始化，一种是通过初始化脚本创建。目前，部署工具初始化账本功能有限，只支持btfsmart共识算法的节点初始化，如果要支持mq的共识，只能使用初始化账本的脚本创建，

第一步、生成公私钥

使用部署工具生成公私钥，虽然部署工具不支持mq共识的账本初始化，但是还是可以用部署工具帮我们创建并维护公私钥，这种方式比使用脚本创建要方便很多。

第二步、准备配置

jdchain初始化账本需要三个配置，账本配置 ledger.init，本地节点配置：local.conf ，共识服务配置:bftsmart.config 或mq.config，其中local.conf是每个共识节点特有的配置，账本和共识服务配置需要同步到每个节点。

更多配置详情参考：http://ledger.jd.com/setup.html

第三步、执行初始化脚本

配置准备好后，先找到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

误以为每个节点的交易队列需要不同主题，导致了每个节点加载的账本不一致，从而导致了上面的交易签名验证失败

解决问题

初始化账本时一般包含三个配置文件，账本配置 ledger.init，本地节点配置：local.conf ，共识服务配置:bftsmart.config 或mq.config ,其中共识服务配置是包含在账本配置ledger.init里被加载的，所以初始化一个区块链账本需要保证 每个节点的【账本配置 + 共识服务配置 】一模一样。才能保证交易签名哈希一致

结语

jdchain的各组件设计的比较灵活，如共识实现可以使用bftsmart、RabbitMQ等，底层存储也可以使用本地的rocksdb也可以使用redis等。如果有特殊的需求也可以自己实现定义的api接口。博主第一天使用的都是默认的的提供者实现，安装部署都比较顺利，今天尝试使用RabbitMQ的共识时遇到了好几个问题，首先是上面的交易许可验签的问题，然后目前官方的基于RabbitMQ的共识，RabbitMQ的链接器不支持带用户认证的mq的配置。不过问题都已解决了，支持amqp的配置代码也已给官方仓库提交pr了，算正式踏入区块链研究之路了