Initialize the Creation Block
The first step in building a blockchain service is to initialize the Creation Block and create an ledger. There are two ways to generate dchain to initialize the Genesis block. One is to operate initialization on the page through the official blockchain deployment tool, and the other is to create it through the initialization script. At present, the deployment tool initializes ledger function is limited, and only supports node initialization of the btfsmart consensus algorithm. If you want to support mq consensus, you can only use the script to initialize the ledger to create
Step 1: Generate a public and private key
Use the deployment tool to generate public and private keys. Although the deployment tool does not support the initialization of the ledger of mq consensus, you can still use the deployment tool to help us create and maintain public and private keys. This method is much more convenient than using script creation.
Step 2: Prepare the configuration
jdchain initializes the ledger three configurations, ledger configuration, local node configuration: , consensus service configuration: or, which is the configuration unique to each consensus node, the ledger and consensus service configuration need to be synchronized to each node.
For more configuration details, please refer to:/blockchain-jd-com/jdchain
Step 3: Execute the initialization script
After the configuration is ready, find the script first, then modify the -i and -l parameters, and specify the configuration address configured in the second step. Then execute it in turn. If the configuration is correct, it will prompt that the initialization service is ready. Press any key to start initializing the ledger. At this time, just press Enter. After the initialization is successful, a file will be generated in the config/init directory. This configuration file is required to start the node service
Creation block creation process
Assuming there are four consensus nodes, node0, node1, node2, node3, and participate in consensus creation blocks, then the behavior of node0 when executing the initialized script is as follows, and the behavior of other nodes is consistent:
1. Load the configuration according to the -i and -l parameters
2. Create an initial configuration instance
3. Verify whether the public and private keys of the current node match (using the private key to generate a signature, and using the public key to verify the signature)
4. Initialize the ledger, instantiate the local transaction context, and generate the world-creation transaction
5. For the initial transaction signature, generate the ledger initialization license for the current node (using the hash of the current transaction context object and the private key of the current node to generate the signature);
6. Confirm the first stage among all participants, request the ledger creation permission of all other participants, and request the /legerinit/permission/interfaces of node1, node2, and node3 in turn. The other party's interface will perform signature verification, which is consistent with the method of process 3.
7. Use the current node transaction transaction context as hash to verify the access permission signature returned by other nodes. If this process fails, it will be retryed 16 times.
8. Link the database to generate the initial ledger of the current node
9. Conduct a second phase of consensus among all participants and start requesting the ledger creation decision of all members. If all return to the resolution creation, submit the ledger, otherwise roll back. This process will also be retryed 16 times
The above consensus interface for the two stages of the Creation Block is defined as follows:
public interface LedgerInitConsensusService {
/**
* Request an initialization permission for the ledger;
*
* @param requesterId
* Participant id who initiated the request;
* @param signature
* The signature made by the requester's private key pair "id" + "ledger seed"; only if the signature is legal and the participant is a participant in the initialization configuration can obtain a valid return, otherwise it will be rejected;
*/
@HttpAction(path = "/legerinit/permission/{requesterId}", method = , contentType = LedgerInitMessageConverter.CONTENT_TYPE_VALUE, responseConverter = )
LedgerInitProposal requestPermission(@PathParam(name = "requesterId") int requesterId,
@RequestBody(converter = ) SignatureDigest signature);
/**
* Synchronize the account initialization resolution;
*
* @param initDecision
* The caller's account initialization resolution;
* @return The ledger initialization resolution of the target participant; if the target participant is not ready, return null;
*/
@HttpAction(path = "/legerinit/decision", method = , contentType = LedgerInitMessageConverter.CONTENT_TYPE_VALUE, responseConverter = )
LedgerInitDecision synchronizeDecision(@RequestBody(converter = ) LedgerInitDecision initDecision);
}Problem encountered: When requesting permission to create a ledger from other participants, the following exception is output:
Invalid permission from participant! --[Id=LdeNn8bWuc2DaqAbx3XCQPUf7bdb94PTKFT2E][name=] Invalid permission from participant! --[Id=LdeNezcG3rhs31u8UBSwvfMf2BKr1ZkaLKJAG][name=] Invalid permission from participant! --[Id=LdeNqxGmBdmEZK6hVeLcnXppW2qnLLKMMiQhN][name=]
Seeing this output means that the problem of public and private keys can be ruled out. Because this is the last step of licensing, the transaction hash license signature verification failed to output. The transaction hash is created based on the current ledger context, which is loaded based on the initial ledger configuration, so the final problem lies in the initial ledger configuration. I misunderstood the following configuration:
# Current ledger transaction sending queue theme (different ledgers require different topics)=node3-topic
Conclusion
The various components of jdchain are designed more flexible, such as the consensus implementation can use bftsmart, RabbitMQ, etc., and the underlying storage can also use local rocksdb or redis.
If you have special needs, you can also implement the defined API interface yourself. The blogger used the default provider implementation on the first day, and the installation and deployment were relatively smooth. Today, I encountered several problems when trying to use RabbitMQ consensus. First, the above transaction license verification problem, and then the official RabbitMQ consensus based on RabbitMQ, the RabbitMQ linker does not support the configuration of mq with user authentication. However, the problems have been solved, and the configuration code that supports amqp has been submitted to the official warehouse, which is considered to have officially entered the path of blockchain research.
The above is the detailed content of the initialization of the jdchain service for Java open source blockchain. For more information about the initialization of the jdchain block of Java open source zone, please pay attention to my other related articles!