Document Purpose and Properties of `messages` Table

[adamkrellenstein]

The key is that Counterparty is a deterministic state machine.

Uses

• detect discrepancies between state of multiple nodes and across versions (balance this with hiding implementation details and having stable hashes across upgrades)
• use for building e.g. a secondary block explorer DB (note! no guarantee of backwards-compatibility!)
• manage the mempool (?)
• integrate with logging of deterministic events

[jotapea]

Good but I'm curious if this will be describing the table as it was pre v10 or after...

[jotapea]

Some initial feedback, as I have been thinking about this for a long time, as I really like the message abstraction you came up with initially and how it is implemented in <v10.

detect discrepancies between node state (balance with hiding implementation details)

Agree. I would add something like (maybe as a separate point?): "hash content not directly tied to the ledger (like broadcasts and asset long_names and descriptions)"

be able to rebuild a database to do an explorer for example with Counterblock

Agree, BUT blocks and transactions tables would also be needed... (why explained below)

manage the mempool (?)

Agree only in that the CNTRPRTY transaction message is the only data that should be in the mempool table, because the final validity of this message will only be known after included in a block.

integrate with standardized logs of all updates in the database

Disagree with the "all updates", but there is also some validity here. As @ouziel-slama is thinking, one could consider this table as a place to store "all updates" as events.

After some time digesting it, I think this could be done ONLY for debug purposes. In production (and for hash calculation), then only include the minimum (but complete) required messages, based on the CNTRPRTY transaction (+ related non messaged like dispenses) and the block state messages.

For production hash calculation I would not include anything before the CNTRPRTY transaction message, like the block and transactions. I would also not include duplicate messages like asset and balances. This is how it is done in v9, where messages can be simply described as: "an invalid transaction message doesn't trigger more messages, but a valid one does".

I find this design VERY ELEGANT, and is something I believe should be kept.