feat(tm2): store tx results and add endpoint to query them

[zivkovicmilos]

Description

This PR introduces saving transaction results (execution results) in the node's state DB, and serving them over the node's RPC endpoint (tx).

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 47.78%. Comparing base (229bf0e) to head (dd4e54e).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1546      +/-   ##
==========================================
+ Coverage   45.10%   47.78%   +2.67%     
==========================================
  Files         464      393      -71     
  Lines       68039    61608    -6431     
==========================================
- Hits        30689    29437    -1252     
+ Misses      34774    29701    -5073     
+ Partials     2576     2470     -106     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zivkovicmilos]

@dongwon8247

I've added tx result support for the Gno RPC in this PR, both for regular calls and for clients

[zivkovicmilos]

Ping @ajnavarro @gfanton @thehowl for visibility

[thehowl]

nits & q's, lgtm

[ajnavarro]

The changes LGTM, but I have one question:

Transactions and blocks are not stored using the same transaction, so we might have eventually inconsistencies between blocks and transactions stored. Is that a problem?

[zivkovicmilos]

The changes LGTM, but I have one question:

Transactions and blocks are not stored using the same transaction, so we might have eventually inconsistencies between blocks and transactions stored. Is that a problem?

I wish I could give you a better answer to this question, but in order for that to happen I'd need to untangle the mess that is our block building logic, something I'm tackling with @petar-dambovaliev in a separate effort.

We save ABCI results as part of ApplyBlock - these contain information about the transaction execution. I've placed the tx result saving just after it:
https://github.com/zivkovicmilos/gno/blob/d06ba58e5545478273f9a29f84d6c44472ee158d/tm2/pkg/bft/state/execution.go#L109-L124

I'm assuming (hoping, really) that blockExec.db is reverted if any funny business happens. We validate the block before we start hitting the DB with save requests, so this is about as safe as we're gonna get at this point in the codebase

[thehowl]

I think after addressing the %x I was talking about, seeing as it's been approved by both me and Antonio, you can go ahead and merge :)

[zivkovicmilos]

Pinging @ajnavarro and @gfanton for a second screen 🙏

[zivkovicmilos]

Update on this PR:

I've spoken internally with @ajnavarro and we agreed a much leaner option would be to store the tx hash -> block number / tx index mapping, rather than tx hash -> tx result, just because it keeps the DB footprint minimal, and we can always reconstruct the result from the state on the fly

I'll update this PR accordingly 🙏

[zivkovicmilos]

@ajnavarro @gfanton

I've updated the index:

9371399

Now, instead of

tx hash -> tx result

the mapping is:

tx hash -> (block number, tx index)

and the actual RPC endpoint digs this out of the DB and constructs the response type, so we're avoiding double saves

[gfanton]

LGTM 👍