Hi. Have you read https://tendermint.readthedocs.io/projects/tools/en/master/specification/block-structure.html?highlight=apphash#header?

Yes. I understand that there maybe some additional factors involved while updating state other than that transactions in the committed block.

My question is, is there any usecase when apphash is logically significantly different from the block hash?

Or is this just a double check that all app states across the network are consistent

mdyring (@mdyring:matrix.org)
apphash: hash of current application state, blockhash: "blockchain" part that links previous block with next block, including new app state, how validators voted etc.
is the question why the apphash is stored? if so, one use-case is to quickly allow tendermint to determine if a app that is replaying txs (say, due to restart) is behaving as expected
S
sherzodv
yes, thanks.
so this is mostly sanity check right, and in order to make it actually work I need to carefully understand what to hash.

mdyring (@mdyring:matrix.org)
well not just sanity, the basis if reaching consensus is that all app hashes on +2/3 of the nodes are identical
for instance, if one node runs with non-ECC memory, and a bit is flipped somewhere.. its apphash will differ and it will "drop out" of consensus
S
sherzodv
I mean, I just can take effectively hash of a committed block, or a blockchain signature and use it as app hash (and in simple applications like dummy persistent example) it is apphash, but it won't actually be what it meant to be

mdyring (@mdyring:matrix.org)
apphash is whatever you want to it be.. you can potentially return the same apphash all the time

Quiark
if you're not adding any functionality on top of tendermint then apphash could be 0

mdyring (@mdyring:matrix.org)
but that defeats the purpose of running tendermint.. ;-)
tendermint just things of apphash as a blob of bytes.. only thing it is concerned about is that apphash should be the same across nodes for consensus
so you need to make sure that any state change in your app results in a different apphash.. assuming the state change should be identical across nodes
S
sherzodv
yes, this is clear
what I'm trying to say, is for example in dummy example application, the state of the application is effectively the root of a merkle tree right? but a merkle tree is effectively what a blockchain is (I mean the same data, no less, no more)
But I think I got it, how to think about apphash.

mdyring (@mdyring:matrix.org)
merkle tree in the context of the app is your app state
the cosmos-sdk uses a merkle tree internally to store its state
but you could make an app, similar to the counter example, which just returns a hash dependent on some simple data structure.. integer value, string, containers etc
S
sherzodv
yes, and in real world app, there could be some more data in state, the data that will come not from dliver_tx

mdyring (@mdyring:matrix.org)
your app state should depend on DeliverTx, any "outside" interference would lead to different apphash across nodes
S
sherzodv
and that is the difference, apphash will take that outer data in account too

mdyring (@mdyring:matrix.org)
can you explain what your use case is?

Quiark
sherzodv, apphash should not contain anything from tendermint
S
sherzodv
oh.. ok
K
Quiark
sherzodv, tendermint blockchain contains some stuff *and* apphash
S
sherzodv
let me try to explain than, what I need to understand than...

mdyring (@mdyring:matrix.org)
"outside data" is a bad idea.. means nondeterminism.. tendermint ensures that all apps across nodes receive the same state changes (via develivertx) in the exact same order
hence.. if they are all behaving correctly, they will have same apphash all the time and thus there will be consensus on the global state
S
sherzodv
yes, but what is the difference from block hash than?
I mean if both block hash and app hash are determined by only and only delivertx data, than what is the difference?

mdyring (@mdyring:matrix.org)
blockhash contains information about consensus
apphash is only about your local node (app)
blockhash contains info about how each node voted and how consensus was reached
so they are very different

melekes (@melekes:matrix.org)
block hash represents a group of txs (block)
app hash changes with every state change (tx)

Quiark
in theory you don't need to keep state in apphash?
S
sherzodv
melekes: this isn't true according to docs. you need to recalc appstate on block commit

melekes (@melekes:matrix.org)
I meant commit, sorry, yeah. so ok. how about block hash is hash of data inside + header. app hash is hash of state change (but no necessary data)
S
sherzodv
mdyring: I appreciate your willing to help, but still can't understand.. let's take it more abstract
say we have some data

[ a, b, c, d ] and we calc hash on

blockhash = hash(a, b, c, d)
apphash = hash(a, b)

if we already have hash(a, b, c, d), how hash(a, b) would help?

melekes: that's what I'm trying to find out. what is a state change. if it's only a set of delivertx messages, than it's already included in blockhash
Currently I think that apphash is only needed to ensure that all applications across the network have applied a set of delivertxes in block in a consistent way

Quiark
yeah I think so
if your app data is current balance of accounts for example
S
sherzodv
so when starting the next block tendermint will check the app hash (included now in new block) and if it's inconsitent, then some apps applied previous blocks' transactions in some different way
So if I just hash up all the dlivertx's content it would not do. cause actually applying them to state maybe different

that's what bothers me. I need to somehow hash a state, not delivertx's that brought me to that state
S
12:56
right?))