aelf Tech Talks — Consensus and Standard Interpretation Pt 2

Published in

aelf

6 min readMar 3, 2020

Get consensus command

Continue to take node A as an example. This is a node that has synchronized to aelf’s longest chain at 13:59:56 p.m. on January 1, 2020. A, an honest node without modifying the local main chain code, has just synchronized a block. That is to say, A receives the blocks from other nodes on the network, verifies them successfully, and modifies the local blockchain ledger information. The local Best Chain maintains a data structure of the local blockchain. Once updated, an event is loaded on the Event Bus. One of the functions of this event is to remind node A to ask the consensus service what it needs to do next through the relevant event subscription and processing mechanism. During this inquiry, “A” passed its public key to the consensus service.

The core logic of the consensus service exists as a smart contract, because it ensures that its code is consistent for every node in the blockchain world. If not, it means that the node is trying to become malicious or hard-forked. After several milliseconds of complex or simple calculations, the consensus intelligent contract feeds back a message to node A. The generation of this information varies with the consensus mechanism choices, but any consensus should have the following structure:

When can “A” generate blocks?
If “A” can produce blocks, then what pose should “A” use to make further requests: What blocks can “A” produce under the current consensus? Call this information an extra hint here.

What if “A” can not generate blocks? In theory, every node actually has the potential to create blocks in the blockchain world, but due to the different design of the consensus mechanism (for example, the POS consensus), some blockchains do not want most nodes to have the right to produce blocks. In this case, you only need to set the time to return to a to be 100 years later, which may be a bit of an exaggeration, but it will be OK after a few months. As long as “A” can hang on for a hundred years, and a new block is not created in that hundred years. (Any valid new block synchronization will cause node A to regain a block-out time.)

It’s not hard to imagine how easy it would be to implement a PoW based on this interface. As long as the time is set to “immediately” , the extra prompt is empty.

In the AELF main chain, the consensus service will update the consensus scheduler as soon as it learns the consensus feed-back time information. If the previous consensus scheduler is not empty, then it must first clear the unfinished scheduling information before being filled with a new time point. That is to say, there can only be one consensus task not executed in the consensus scheduler, and the consensus scheduler is a singleton object.

Next, there is the long countdown.

Let’s go back to the example of NODE A. Suppose A requested for the consensus order and got a time: January 1,2020,14:00 p.m., that is, four seconds later. Extra Hint: Nextround (this is a hint from the AEDPoS consensus, which means that A will terminate the outbound process of this round and update the outbound sequence of all proxy outbound nodes in the next round.) This means that the scheduler immediately updates to an event that executes a production block in four seconds. What do you do in these four seconds? If blocks sent by other nodes can be synchronized and validated, then use Best Chain to update the processor of this event and ask consensus service for consensus command constantly (this action is called a TriggerConsensus in the code). Accordingly, the consensus scheduler is constantly reset: 3.5 seconds, 3 seconds, 2.5 seconds, 2.5 seconds.

Finally, it’s 14:00:00. Node A is under the control of the consensus scheduler to start preparing the production block. At this point, according to our previous design, the only information it knows about how to produce a block, other than the block out time that has already worked, is the additional tips that the consensus service gave it.

At this point in the aelf blockchain, node A passes the additional prompt information to the consensus service. In addition to packaging the transaction, two other services are invoked:

Get the consensus block header information
Get a consensus system transaction

One of the functions of the interface for requesting consensus commands is to try to make the produced block pass the verification. In aelf, there are two consensus-related validations in a series of validation steps for a block: verify the block header before execution, and verify whether the modification information of consensus contract status is consistent with the information in the block header after execution.

To make a simple analogy, a .NET programmer goes to the DNT offline salon, and he takes out the invitation message to the salon organizer for inspection. This message is similar to the block header, that is, if he can’t take out the invitation message, the organizer won’t let him participate. Next, the sponsor will ask the .Net programmer to report the mobile phone number and look for it in the roster of attendees, which is similar to verifying a consensus transaction at a blockchain node. Only this step is also validated, .Net programmers can attend this salon smoothly.

In conclusion, we need three interfaces for services such as the get consensus command. Describe it in terms of Protobuf:

For the sake of chain security and stability, in ConsensusCommand, there are not only the next block generation time (arranged_mining_time) and Extra Hint (hint), but also the limit block generation time (limit_milliseconds_of_mining_block) and the latest broadcast time (mining_due_time). The latter two are used as reference for the block production service to realize that if a certain time limit is exceeded, the block produced does not need to be broadcast (or even if other nodes broadcast it, it cannot pass the verification, which is guaranteed in the specific implementation of the interface type to be discussed below). It is better to create a block in vain than to disturb the production order of the block.

Block Verification

If the request consensus command is worth discussing in detail, there is nothing to praise about the interface related to block verification. Actually, verification logic is completely different from consensus.

There is no new idea in the interface itself. One is to verify the block header before consensus transaction execution, and the other is to verify whether the status of consensus modification is consistent with the information promised in the block header after consensus transaction execution. The input parameters of the two verification interfaces are binary arrays, which means that the interface accepts any data and only needs the consensus implementer to deserialize in the specific implementation of verification.

aelf Tech Talks — Consensus and Standard Interpretation Pt 2

Get consensus command

Block Verification

Other Topics in aelf Tech Talks:

Written by aelf Developer