aelf Tech Talks: AElf Consensus Contract Standard (ACS4)

[aelf Developer Community]

Episode 2

ACS: The AElf contract standard, as its name implies, is an interface that needs to be utilized when developing AElf smart contracts.

All ACSs are defined by the protobuf service. This article will look specifically at ACS4 which, as one of the ACS’s, needs to be utilized when implementing any kind of consensus contract. This article focuses on the feasibility of a consensus standard interface and other support tools provided by AElf for the implementation of a consensus contract.

Abstract consensus Thought

From the perspective of a successful blockchain consensus, we are mainly concerned with three aspects:

-Who can generate blocks. For example, PoW consensus allows everyone to participate in power competition, while PoS and DPoS consensus should impose certain restrictions

-If a node is eligible to generate a block, then when should it be generated, and should it be broadcast immediately;

-As a full blockchain node, how does one verify the legitimacy of a block.

For these three points, we can easily think of three types of interfaces:

-Enter the public key to determine whether the producer associated with the public key is eligible to generate a block. The PoW consensus will always returns true in this case. DPoS will return false to most users as eligible nodes are restricted.

-Enter the public key, return the timestamp of the next time the public key can generate a block, or return whether the public key can currently generate a block.

-After the full node gets the block header, input the consensus data extracted from it, and verify the above 2 related pieces of information of the block. This is what the PoW consensus needs to verify the legality of the nonce, and the DPoS consensus needs to verify the producer of the new block. The legality of the block will rely on whether the producer respected his time slot and the verification results.

In addition, in order to obtain the consensus data in the block header, as required by the full node for verification, a method for generating this data needs to be provided to the block producer.

Application in the AElf Ecosystem

First of all, the consensus of AElf’s mainchain is DPoS. Although this article discusses the general consensus interface, it will inevitably tend to discuss more on the (AE) DPoS environment.

Second, all interfaces on the consensus contract standard are read-only, because there is no need to change WorldState to simply obtain the data. (WorldState is a concept in Ethereum.)

Note: AElf refers to the database used to store the state of the contract as State DB; in addition to this, Chain DB is used to store the block itself, including transactions in the block.

Interface 1 and interface 2 are merged in ACS4 to get a new and combined interface

The value of NextBlockMiningLeftMilliseconds depends on the difference between ExpectedMiningTime and the current time (the time the interface was called).

LimitMillisecondsOfMiningBlock is the time that the system allocates to this block for packaging, which determines how many users can be packaged by this block (how long it takes for the packaged user to send the transaction).

The Hint field is used to pass some separate states. Depending on the chosen consensus protocol such as in PoW this field may not be necessary. AEDPoS defines some block types, such as Normal Block, Extra Block, and Tiny (only updates a small amount of consensus information) Block. These need to be reflected in Hint — the consensus contract not only needs to tell the block producer how long before it can start to generate the block, but also must tell them what type of block should be generated, and different blocks will be updated with different consensus information. In addition, the introduction of the Hint field can provide more possibilities for implementing other consensus protocols.

This interface will synchronize a new block on the local Best branch (whether or not the block is generated by itself) at the beginning of the chain, and the block producer will suddenly find that the current time has exceeded its own slot (i.e., call ValidateConsensus Be below) during the verification before executing its own block. The foreExecution interface is then called.

After the call, the Consensus Service will pass NextBlockMiningLeftMilliseconds into the consensus scheduler, and when the time is up, it triggers the logic of the production block.

Note that the time in the scheduler can be overwritten at any time. In fact, each time a new block is synchronized, the scheduler is reinitialized.

Regarding interface 3, ACS4 splits into two interfaces

In the aelf blockchain, before and after each block is executed, the implementation of the above two interfaces is called to verify the block header. The logic of validation is in the contract that implements ACS4, and the validated data has to be based on the State DB.

Note: Because you can’t verify the consensus information in the block headers out of thin air, you need to store the latest consensus information in the consensus contract to provide verification support for the recent consensus information.

Since the validated data is based on the State DB, and the ACS4 interfaces are read-only, you need to generate a separate transaction to update the State DB (blockchain features, updating the WorldState or State DB must be done by executing the transaction).

Thus, in addition to providing a method for generating block header information, ACS4 needs to be able to return a (set of) transactions that can update consensus information in the State DB. This transaction is generated as a system transaction and then added to the block first during the packaging process. System transactions are executed prior to ordinary transactions, so that ordinary transactions are executed with information provided by the recently updated system, such as random numbers under hash-commit-reveal strategy. In AElf, each block contains at least one consensus system transaction.

The last two interfaces of ACS4 are related to updating consensus information

In AElf’s kernel module code, GetInformationToUpdate Consensus is called during block header generation, and the data returned by this interface will be used as one of the Extra Data of the block header to verify consensus information for the recipient of the block. The Generate Consensus Transactions interface is called in the process of further generating system transactions after generating the block headers. Additionally, the Validate Consensus After Execution interface is essentially just to verify the consistency of consensus information in the blocks and consensus information in the State DB after executing consensus system transactions, and to prevent block producers from “backsliding”.

The complete code for ACS4 is here. Suggestions about this article or ACS4 or other AElf consensus components are welcome and will be taken seriously. Messages, private notes or even submissions in GitHub are welcome.

The above is a general introduction to the AElf blockchain consensus contract standard ACS4. The next article will introduce the implementation of the most complex GetConsensusCommand interface under the AEDPoS consensus.

— 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