Files
tendermint/spec/abci++
William Banfield 0b8a62c87b abci: Synchronize FinalizeBlock with the updated specification (#7983)
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
2022-03-04 22:32:37 +00:00
..
2022-03-02 22:12:01 +01:00

order, parent
order parent
1
title order
ABCI++ 3

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