Proxima: ledger explorer

The ledger explorer in Proxima woudl implement common functions of the equivalents in other blockchains. It will be implements as a Web browser which access endpoint of the node.

Functions

• retrieve and display transaction by its transaction ID. According to its syntactical structure. Transaction is implemented here
• highlight and/or provide links from elements of the transaction to other transactions in the UTXO tangle (this can be implemented gradually):
  • to transction level properties (timestamp, signature, sequencer tx properties, number of inputs, outputs etc)
  • to inputs (consumed output IDs) of the transaction. The hyperlinks must point to other transaction
  • to produced outputs as arrays of constraints
    • to constrains as their bytecode and decompiled source codes
    • chain and chainLock constraints could provide hyperlinks to chainIDs and addresses (advanced)
    • interpretation of stem and sequencer outputs (advanced)
    • in the future you could retrieve the EasyFL code from the database, but that will require modification of the multi-state database
  • to endorsed transactions (hyperlinks)
  • properties of sequencer and branch transactions
• transaction metadata if available
• Browse tree of branch transactions (essentially following the stem) (advanced)
• Search transactions by slot (it is a prefix in key/value store). Advanced

Parsing

Most of functions which allows to parse raw transaction and access each of the elements is in the transaction package. You use FromBytes function to parse raw bytes of the transaction to transaction.Transaction. It has number of options for validation. Only basic are needed for exporer.

How to convert transaction.Transaction to readable form one can take LinesShort function as an example. JSON could be formed similarly.

API

All the APIs are implemented in the api package. The browser would need to retrieve transaction as JSON by transaction ID with something like get_tx?id=ffff... It is not implemented.
Same with searching for transactions with specific slot (this is not a priority).

Transaction ID

Transaction ID is 32 bytes binary, see here
It consists of:

• first 5 bytes except bit 0 in byte 0 are timestamp:
  • 4 bytes slot number
  • 1 byte is number of ticks
• the bit 0 of byte 0 is 1 for sequencer transactions, 0 for the rest
• last 27 bytes is so called transaction hash

This way transaction ID contains information about timestamp and flag if it is a sequencer transaction. Plus hashed part. The transaction ID usually is displayed with timstamp ans sequencer flag as prefix to the hash. For binary exchanges in API it is just hex encoded.

Transaction store

All raw transactions are stored in the simple TxBytesStore interface.
TxBytesStore is separate database from the ledger state. So, API have to call this interface with the ID and get the raw transaction bytes and metadata (if available)

In the future it makes sense to implement it as separate server and the explorer would access transactions directly from the store, bypassing the node. This is advanced