Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BeginBlock / EndBlock handlers in applications #248

Closed
UnitylChaos opened this issue Dec 2, 2020 · 1 comment
Closed

BeginBlock / EndBlock handlers in applications #248

UnitylChaos opened this issue Dec 2, 2020 · 1 comment

Comments

@UnitylChaos
Copy link
Contributor

Tendermint ABCI defines BeginBlock and EndBlock message types which are issued to the application before and after all DeliverTx messages. ie. BeginBlock -> [DeliverTx] -> EndBlock

The BeginBlock message contains information about the previously committed block, such as which validators signed it, how many rounds it took and any evidence of validator misbehavior. It also includes the block Header, which has information such as height, timestamp and various hashes such as previous block, last app state, etc. which are used to ensure consensus on all aspects of the chain state.
ABCI expects a response with any events which are emitted during the processing of the BeginBlock request, but the main purpose of the message is to provide information to the application. For example, applications might pay out staking rewards based on which validators signed, or slash validators for which evidence of misbehavior has been provided. They also might need to know what the current block height or real time is when processing transactions within the block.

The EndBlock message contains considerably less information, just the height of the block which is ending.
The expected response is the interesting part, it can contain updates to the validator set, in the form of a list of validator pubkeys and the new power they will be set to. This is also where changes can be made to ConsensusParams, which determines things such as what key types validators can use, maximum block size / maximum gas, and limitations on the age of evidence of misbehavior. The EndBlock response also includes a field for events emitted during handling of the message.

Kepler currently has dummy handlers for both these, returning a default response with no events and no changes to the validator set or consensus parameters. There should be some way for application (and module) developers to specify handlers for these messages.

For comparison, the Cosmos SDK does this by having modules implement "BeginBlocker" and "EndBlocker" functions, and applications specify an execution order for these individual handlers. Reference

@UnitylChaos
Copy link
Contributor Author

Closed by #247

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant