Redesign Transaction Details page

[frol]

Currently, the page is full of ad-hoc data, so it is hard to reason about the information that is on the page.

The goal I want to reach there is to answer the common questions users may have about a given transaction:

1. What happened?

   The transaction itself tells only the initial intent, e.g. "I want to call a function X on contract Y" or "I want to transfer tokens", but especially with the function calls, it may do things that could be considered as something that is completely different from the initial call. Refer to the docs if you want to learn more about transactions, actions, and receipts.

   For example, here is a transaction which starts as a function call from an account yin123y.near to itself calling a method confirm, but it is just an entry-point of a multisig (2-factor-authentication) flow, which in its turn calls a lockup contract (another account), which in its turn calls a staking pool contract (yet another contract) to delegate

2. When happened?

   A transaction is recorded and converted to a receipt in block X, but the changes that the transaction initiates spread across the next blocks through the receipts execution happening there.

3. What is the result?

   This part has been completely neglected. We should display the state changes that were triggered by the given transaction/receipts. (Note, state changes are liquid and staked balance changes, new and removed keys, contract code updates, contract storage edits)

To answer "What happened?" part, I want to present us with the problem space:

We currently display the receipts in a nested tree view (and it works mostly fine), but in the essence of NEAR Protocol, it could be an acyclic graph, for example, a single receipt may produce 4 receipts, where the third will be awaiting for the first two, and the forth is a refund to the original receipt. Currently, it is going to look like this:

- Receipt 1 (executed in a block at height 1)
|- Receipt 2 (executed in a block at height 2)
|- Receipt 3 (executed in a block at height 2)
|- Receipt 4 (awaited for Receipt 2 and Receipt 3 executed in a block at height 3)
|- Receipt 5 [refund] (executed in a block at height 2)

Receipt 4 was created by Receipt 1, that is correct, but we could also represent it as:

 Block #1  |      Block #2     |  Block #3
++++++++++ | +++++++++++++++++ | ++++++++++
            ---- Receipt 2 ----
           /                    \
Receipt 1    ------------------   Receipt 4
           \                    /
            ---- Receipt 3 ----
           \
            ---- Receipt 5

I would prefer to have this funnel-like representation, but It is going to be quite challenging from the design point of view, and implementation point of view as well.

Also, currently, we display all the receipts the same way, and receipts are all equal, but from a user point of view, there are some special receipts which cost 0 gas and sent to them back from system (non-existing) account, which is a refund system in NEAR Protocol (each execution leaf ends with a refund).

Some complex transactions for future reference:

• multisig -> lockup -> stacking-pool: https://explorer.near.org/transactions/BnQcHwyvP9EfdaLEErA8CsL2yVVNGs3Lfds8o4MMPPDL
• many receipts:
  • https://explorer.near.org/transactions/FBxPnRgJ7mDbv9nycV7TVgDwhSMLMSALecArs9sb52Em
  • https://explorer.near.org/transactions/FJNg2yQKrkXbUp23pys3Beid4aAAKf9ZfEAMJziUz85i
• big list of args: https://explorer.near.org/transactions/4H2SUehL5q6kDKZs3EvqxiqF4JBQ7QP7VgAQrkbCZJjn
• failing: https://explorer.near.org/transactions/HpHfTgaQsy1AwaKMUQsUH2Eh6UhUuyVf55sfVwqoJiCd
• small: https://explorer.near.org/transactions/BFXM5b3N6UhMt2eD1dMH8N2F3AaCTipK85cwJQp3wbvd
• just a transfer (with a refund receipt): https://explorer.near.org/transactions/48GAZXFuumPAHsMpqVMsorVhYv2M5mxw3EF3YTLUfC4r
• bridge uses binary format instead of JSON, so the args are presented in hex (not really readable as of now :confused:): https://explorer.near.org/transactions/8GNYK2KTXZWnV12jqjzQcYPgVAHoY28kcNP8GkwnsXiL