The PDP explorer architecture has a history/liveness requirement
The explorer gets data about the network from an indexer process. The indexer looks for all blockchain blocks and listens for events from the PDPVerifier and PDPSimpleService contracts. It then takes this event data and constructs a local database.
If the indexer is offline it has a nice builtin recovery process that will go back through the history of the chain and apply historical events to the data model.
The issue is that lotus nodes have an expiration date for historical data typically. Splitstore discard nodes drop this data after a few days. Popular RPC providers impose limits where requests for transactions at ~16 hours into the past are not answered.
In order to be able to handle normal outages robustly (i.e. machine went down over the weekend without anyone noticing) we’ll need to put some thought into deploying PDP explorer indexers
I don’t know if these are available but if this service can be leveraged it solves our problems
Turns out this can be bought from GLIF so lets do that: https://api.node.glif.io/. They might subsidize us!
This is a brute force approach. If we take the hit of storing ~5Gib extra every day or ~2TiB a year then we can run this thing without any trouble. This is expensive
The “right” way to do things is to just fix up the data model so that we can sync directly from the latest state of the PDP explorer. The downside is that this is engineering work that probably isn’t going to fit inside the PDP launch. And if we want to just use what we have and try to get another organization to run explorer then this is likely wasted work.
This can’t really be done without changing the fundamentals of UX as the transaction log is an important part of the UI
We can run 2-3 indexer nodes (zen, tippy, phi) and if one of them crashes we can just pg_dump and pg_restore. This takes more maintenance but is a good stop gap if we are trying to pass off running the explorer to others in a few months.