Cosmos-sdk: Add transaction time in gaia lite

[faboweb]

Summary

Transactions queried via /txs don't hold the time. They only hold the block height and then the client can query the block meta information to enrich the transaction. It would be nicer to push this enrichment into gaia lite as this is a procedure probably most of the clients will do.

Problem Definition

Proposal

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alexanderbez]

What you're asking for is to include metadata in each tx via this endpoint? Do we need to perform any additional queries for this data? If so, is it worth the overhead? If not, great!

[faboweb]

If we have the meta data for each block locally we don't need to query anything else I think.

[dogemos]

We (and likely a lot of third party wallet developers) will absolutely love this!

[alexanderbez]

Looking through Tendermint RPC, looks like this will require an additional query. The thing is, this endpoint queries a series of paginated txs by tags, correct? Thus, the included txs can have varying block times? If so, then we'd have to perform a block query for each unique block height.

[yangyanqing]

Looking through Tendermint RPC, looks like this will require an additional query. The thing is, this endpoint queries a series of paginated txs by tags, correct? Thus, the included txs can have varying block times? If so, then we'd have to perform a block query for each unique block height.

I think time should be left to the wallet (query by height and cache it) or browser (record time for each tx when scan block) to handle, the blockchain should be as simple as possible.

[faboweb]

the blockchain should be as simple as possible

This is not about adding it to chain but letting the REST interface handle the caching and tx enriching to prevent the caching to be duplicated by every wallet.

[alexanderbez]

@faboweb there is absolutely zero caching in the REST client right now. imho, this will a very unclean implementation and I second the suggestion by @yangyanqing.

[faboweb]

I disagree. And maybe I was miss understood when I said caching. The REST client should in comparison to RPC provide well formatted and enriched data. The REST client has access to the whole storage of the node which makes it a lot more suited to perform enriching tasks than a client which needs to do several calls to stitch the information.

[alexanderbez]

I get that. Thing is the REST client will be doing the exact same work you're client would have to do here -- make a block query for every unique tx height. If paginated results contain n txs, the worst case total # of requests will be O(n) + 1.

I don't mind doing this @faboweb just I want us to come to an agreement that the REST client will no longer be just a simple proxy between the app and the RPC, but rather data aggregation as well 👍