This change set implements the most recent version of `FinalizeBlock`. # What does this change actually contain? * This change set is rather large but fear not! The majority of the files touched and changes are renaming `ResponseDeliverTx` to `ExecTxResult`. This should be a pretty inoffensive change since they're effectively the same type but with a different name. * The `execBlockOnProxyApp` was totally removed since it served as just a wrapper around the logic that is now mostly encapsulated within `FinalizeBlock` * The `updateState` helper function has been made a public method on `State`. It was being exposed as a shim through the testing infrastructure, so this seemed innocuous. * Tests already existed to ensure that the application received the `ByzantineValidators` and the `ValidatorUpdates`, but one was fixed up to ensure that `LastCommitInfo` was being sent across. * Tests were removed from the `psql` indexer that seemed to search for an event in the indexer that was not being created. # Questions for reviewers * We store this [ABCIResponses](5721a13ab1/proto/tendermint/state/types.pb.go (L37)) type in the data base as the block results. This type has changed since v0.35 to contain the `FinalizeBlock` response. I'm wondering if we need to do any shimming to keep the old data retrieveable? * Similarly, this change is exposed via the RPC through [ResultBlockResults](5721a13ab1/rpc/coretypes/responses.go (L69)) changing. Should we somehow shim or notify for this change? closes: #7658
order, parent
| order | parent | ||||
|---|---|---|---|---|---|
| 1 |
|
ABCI++
Introduction
ABCI++ is a major evolution of ABCI (Application Blockchain Interface).
Like its predecessor, ABCI++ is the interface between Tendermint (a state-machine
replication engine) and the actual state machine being replicated (i.e., the Application).
The API consists of a set of methods, each with a corresponding Request and Response
message type.
The methods are always initiated by Tendermint. The Application implements its logic
for handling all ABCI++ methods.
Thus, Tendermint always sends the Request* messages and receives the Response* messages
in return.
All ABCI++ messages and methods are defined in protocol buffers. This allows Tendermint to run with applications written in many programming languages.
This specification is split as follows:
- Basic concepts and definitions - definitions and descriptions of concepts that are needed to understand other parts of this sepcification.
- Methods - complete details on all ABCI++ methods and message types.
- Requirements for the Application - formal requirements on the Application's logic to ensure liveness of Tendermint. These requirements define what Tendermint expects from the Application.
- Tendermint's expected behavior - specification of how the different ABCI++ methods may be called by Tendermint. This explains what the Application is to expect from Tendermint.
TODO Re-read these and remove redundant info
- Applications - how to manage ABCI application state and other details about building ABCI applications
- Client and Server - for those looking to implement their own ABCI application servers