aelf Tech Talks — AEDPoS Contract Implementation Interpretation Pt 2
Generate Consensus Data — Get Consensus Extra Data & Generate Consensus Transactions
After the node obtains the Consensus Command, it will update the local consensus scheduler according to the ArrangedMiningTime information. Blocks are generated after the countdown. The consensus information in the block is located in two places. One is the extra data (a list of binary arrays, one of which is consensus data) in the Block Header, and the other is the consensus transaction as a system transaction, whose hash value is saved in the Block Header, and the transaction related data is saved in the Block Body.
The information in the block header is generated by invoking GetConsensusExtraData, and the consensus transaction is generated by invoking GenerateConsensusTransactions.
AEDPoS inevitably uses the following methods for both implementations:
Firstly, the input information of deserialization needs to be instantiated through aelf ConsensusTriggerInformation. Secondly, different consensus data can be updated according to the Consensus Behaviour.
This time, let’s look at the corresponding method of NextRound：
Generate the next round of information based on the consensus data updated in this round, and then update the production information of several blocks.
GetConsensusExtraDatajust just uses the return value of this method. GenerateConsensusTransactions needs to process the return value again to generate a consensus transaction（the bool type parameter of GetConsensusBlockExtraData is used to indicate to fill in more detailed information when generating a transaction):
Verify consensus information — ValidateConsensusBeforeExecution & ValidateConsensusAfterExecution
Block verification is still based on the production motivation of the current block — Consensus Behaviour. In the ValidateConsensusBeforeExecution，Different IHeaderInformationValidationProvider needs to be added according to different Consensus Behaviour. IHeaderInformationValidationProvider currently has the following types：
- ContinuousBlocksValidationProvider (Prevents nodes from continuously generating too many blocks)
- LibInformationValidationProvider (Verifies that the information for the irreversible block is correct)
- MiningPermissionValidationProvider (Verifies whether the node has block permission)
- NextRoundMiningOrderValidationProvider (Verifies that the order of block production in the next round is correct)
- RoundTerminateValidationProvider (Verifies whether the next round of basic information is correct)
- TimeSlotValidationProvider (Verifies whether the block is produced from the correct time slot)
- UpdateValueValidationProvider (Verifies whether the consensus information updated by each node is legal)
The implementation of ValidateConsensusAfterExecution only needs to check whether the consensus information (the important part) actually updated after the consensus transaction is consistent with the consensus information in Block Header Extra Data:
Because the consensus information in the block header extra information is simplified (such as not including the information related to Secret Share), ValidateConsensusAfterExecution needs to appropriately complete the simplified content. Finally, directly verifying whether the current round of information in StateDB is completely consistent with the completed information. Verification is also more concerned about the more important consensus data, and will do some tailoring for other redundant data. That’s why RecoverFromUpdateValue, RecoverFromTinyBlock and GetCheckableRound are invoked in GetHash.
— Join the Community:
· Get on our Telegram Discord Slack and Kakao channel
· Follow us on Twitter Reddit and Facebook
· Read weekly articles on the aelf blog
· Catch up with the develop progress on Github
· Telegram community in 한국 ,日本語 ,русский ,العربية ,Deutsch ,ItalianoandTiếng Việt,
· Instagram: aelfblockchain
· YouTube Channel: aelf
For more information, visit aelf.io
