Current Tendermint documentation and interpretation of concepts is block centric, i.e., concepts are explained with a relation to a corresponding block. This is a well known source of confusion and misunderstanding. We will list here just few examples from the current spec:

• https://github.com/tendermint/tendermint/blob/develop/docs/spec/abci/abci.md#query, check description of Height field in both request and response.
  "The block height from which data was derived. Note that this is the height of the block containing the application's Merkle root hash, which represents the state as it was after committing the block at Height-1"

• https://github.com/tendermint/tendermint/blob/develop/docs/spec/blockchain/blockchain.md#header, check description of LastCommitHash ("commit from validators from the last block") or AppHash ("state after txs from the previous block")

In this proposal the idea is to interpret concepts from the application perspective, i.e., make it app centric. Tendermint is BFT SMR (state machine replication) middleware which is used to replicate deterministic applications. An application that is being replicated is transitioning between versions (heights) where each version is committed by a block at the corresponding height. Block is also used to provide input (list of transactions) for a next version (height). Furthermore, block is decided by the currently committed validator set. As in Tendermint application is responsible for changes to the validator set, the application at height h defines validator set version h. The validator set version h is committed by the block at height h; therefore it is used to decide content of the next block, i.e., block h+1.

This idea is illustrated on the following diagram (Picture in better resolution can be found here:
App centric api.pdf)

With this approach the examples from above are now interpreted as follows:

• Query for height h returns the state at the height h committed by the block h.

• Given a Header for height h we have the following interpretation of fields:

   // prev block info
  

  LastBlockID BlockID

  // hashes from the app output at the height h; input committed by block h-1
  AppHash            []byte //  the (current) app state at height h 
  

  LastResultsHash []byte // root hash of all results from the txs that are executed by application
  at height h (txs are committed in block h-1)
  NextValidatorsHash []byte // the validator set at height h. It is used to commit block h+1.

  ValidatorsHash     []byte // the validator set that commits this block 
  Q: Do we need this field as it is present in the previous block as NextValidatorsHash?
  
   // hashes of block data
  

  LastCommitHash []byte // commit from validators at height h-1
  DataHash []byte // Merkle root of transactions (that are input for app at height h+1)