ADR 0001: Multiple Roots Under the Tendermint Application Hash

[kostko]

Currently the Tendermint ABCI application hash is equal to the consensus state
root for a specific height. In order to allow additional uses, like proving to
light clients that specific events have been emitted in a block, we should make
the application hash be derivable from potentially different kinds of roots.

[bennetyee]

Just to verify / make clear: from a crypto/security viewpoint, the Root_i values -- inputs to H -- are all public values, and we are not concerned that a replacement/tweaked AppHash value could be created by an adversary, since the messages that will contain the legitimate AppHash value will be separatedly signed/verified etc, correct? This is to cryptographically compress many root values into a single hash value-sized field.

[kostko]

Just to verify / make clear: from a crypto/security viewpoint, the Root_i values -- inputs to H -- are all public values, and we are not concerned that a replacement/tweaked AppHash value could be created by an adversary, since the messages that will contain the legitimate AppHash value will be separatedly signed/verified etc, correct? This is to cryptographically compress many root values into a single hash value-sized field.

That's right, so the full trust chain goes like this:

• Light client verification ensures we have a trusted Tendermint header by checking the validator signatures from some known-trusted point in time.
• The (verified) Tendermint header contains an AppHash.
• The (verified) AppHash can be used to verify that UntrustedStateRoot (and other roots) provided by the node are valid.
• Merkle tree proofs are then used to prove that specific items/keys are contained under the given (verified) root.

So yeah, it's just to compress many root values into a single hash as that is what Tendermint ABCI expects. If we had control over that, we could also just put all the different roots directly in the Tendermint block header.