api: Get all activity related to an account

[aefhm]

Independent endpoints for each ParaTime /consensus

1. Start with transactions related to an account
2. Later extend with events related to an account

[lukaw3d]

Wallet needs to show activity on an account; optionally including paratime activity

The closest thing in API right now is https://index.oasislabs.com/v1/consensus/transactions?sender= but:

• this isn't a nice place to include paratime transactions in the future
• wallet needs to show both sent and received transactions
• need extra fields receiver and amount on many transaction types

[aefhm]

We would need events as well.

[mitjat]

I would argue that largely, activity == events. This will include things not covered by txs, like end of debonding, or the payout of staking rewards at the end of an epoch.
Well, we'll also want to show failed txs, I guess? But events are the main star.

In spirit of our universal-search discussion, I suggest we keep it simple for now and let frontend make separate requests:

• one for failed txs
• one for consensus events (API in progress, see below)
• one for each paratime's events (API is still TODO)

#246 is the first step towards adding events in consensus; it covers just the openAPI. The remaining work is (copied from #246 description for visibility):

• "Just" piping through what we already have in the DB. Most of the fields fall in this category. Still quite a bit of work because of all of our boilerplate.
• Implementing the "related addresses" field for events will require a new DB table, modeled on oasis_3.emerald_related_transactions. It will create a many-to-many link between txs and adresses. To fill it, we'll need an extension to this large nested switch statement in the analyzer so that we'll extract whatever addresses are involved in the event, regardless of the event's type. The addresses mentioned in the event should then be written to the DB as being associated with the event's tx. Similarly, we should switch-analyze the tx itself to find any associated addresses.
  • Eventually, both related_transactions tables (consensus and emerald) should be extended with an extra column that is FK into events. This way, we can associate an address with an event, a tx, both, or neither (= just a height).

[pro-wh]

events related addresses might be nice to have. currently we have separate tables for different kinds of events, each with dedicated columns, so maybe we could get by with a great big union. although I think we currently lose the ordering due to events being in different tables

farther out idea: display non-transaction events among transactions. as a special non-transaction transaction/transactions per block. we do this in the rosetta gateway. and we'll possibly treating the consensus chain as the non-paratime paratime 😵‍💫 speaking from the explorer perspective, where a lot of existing explorers are focused on events. imo this does a better job of meeting users where they are 🤷

[Andrew7234]

I like the idea of having a related_events table in addition to the related_transactions table Mitja described. It should make the events query simpler(=faster), and it also nicely handles events that don't have a corresponding transaction.

switch-analyze the tx itself to find any associated addresses

I know we can extract the sender from the tx signature public key; are there any other addresses that can be extracted besides the ones from the tx.Results.Events?

Edit**: Warren mentioned that this is more for runtime(evm) transactions

[csillag]

Copying discussion from elsewhere:

@Andrew7234:

Closed by #277

[ptrus]

This was implemented.