Input-centric rollups explorer

[tuler]

📄 Context

We’ve been designing and implementing the explorer around DApps. Our home page lists DApps, and you go into one and list its inputs and outputs.

And for that we need a reader node of the application (and it’s GraphQL endpoint).

✔️ Solution

I think it makes much more sense, and will be much more user friendly, if we design the explorer around Inputs.

Inputs (sent to the InputBox) are the equivalent of Transactions on etherscan.

So the idea is to have a home page that presents a paginated list of inputs, in chronological reverse order by default. Of all DApps.

If you want to view the outputs of an input (notices, reports, vouchers) then you need a reader node.

Viewing inputs of a single DApp becomes only a filter. Or it can still have a exclusive page, which is the equivalent of the etherscan address page.

The presentation of an input is something that deserves a separate discussion. For start we know how to decode deposits, and official relay inputs, which is a nice start.

📈 Subtasks

• [x] Add Input to our subquid
• [x] Modify home page with focus on Inputs
• [x] Drill down to outputs of an input (requires a reader node URL)

🎯 Definition of Done

• [x] Home page with all inputs

[tuler]

Adding input to subquid.

[pedroargento]

I see how this makes thing easier and I think it makes sense. But we should think how to do this and still have the feel (and narrative) of DApp chains.

[tuler]

First version published at https://github.com/cartesi/rollups-explorer

[brunomenezes]

This issue was addressed in a separate repository. Below is the information;

Issue: https://github.com/cartesi/rollups-explorer/issues/4 PRs: [ https://github.com/cartesi/rollups-explorer/pull/25, https://github.com/cartesi/rollups-explorer/pull/41 ]