Support ROFL apps

[ptrus]

After #806 add ROFL analyzer to keep track of ROFL state:

• all registered ROFL apps
  • these are created via rofl.Create
  • updated via rofl.Update
  • possibly removed via rofl.Remove
  • each ROFL app has the following state:
    • id, policy, (optional) admin and stake
• instances of a specific ROFL app
  • instances register via rofl.Register
  • each instance has the following state:
    • endorsed capability tee, expiration, extra_keys

For now, we don't need any history for these, just track the latest state in a table and expose it via an API call.

Would likey be good to have some FE designs first so we don't miss things on the backend.

[kostko]

For the endorsed TEE capability we should probably nicely decode it and display some details about the quote. Probably more part of the frontend though?

[csillag]

The frontend is happy to display the data, but we need to know what data is currently available, in which fields, and what encoding?

[kostko]

Ideally Nexus should decode the relevant fields from the quote into some nicer format so the frontend doesn't need to do any parsing (quote parsing is already implemented in Go/Rust).

[csillag]

Are we talking about these and these fields?

[kostko]

It is the body of the rofl.Register call.

[ptrus]

Ideally Nexus should decode the relevant fields from the quote into some nicer format so the frontend doesn't need to do any parsing (quote parsing is already implemented in Go/Rust).

For transactions we currently only store the raw bodies in the DB for all transaction types, and let frontend handle the presentation. But I guess TEE capabilities specifically are not the most straightforward to parse/interpret, so maybe we could do it on Nexus - but since we already have it on both rust and go, it wouldn't hurt (and might be generally useful?) to also have a JS/TS version of it.

I think that In any case, the first next step would be to prepare a small frotnend-end design, specifying exactly what we want to display and how. Then we can decide on the implementation details and where things would be parsed.

[ptrus]

Actually, I see, it's because attestation is stored as a byte vector so it's not further parsed when serializing the struct as json
https://github.com/oasisprotocol/oasis-core/blob/4aa7157000acee07e499dbd7071d6dc5d3425c9f/go/common/node/node.go#L564

It's a bit unfortunate that it's like that in oasis-core.

A somewhat simple hack might be parsing that in Nexus, and if it parses, storing the parsed version in the DB as the tx body. That should be simple to implement and it would instantly improve the "Raw Body" that is displayed on the frontend, without any changes to the frontend. (minor downside is that the "tx body" stored in Nexus DB won't exactly match the actual tx body, but that's fine)