The explorer should provide access to current and historical parameters in the ledger state from the update system / update proposals.
There's two approaches to this: track confirmed update proposals, or track the ledger state. The difficulty with the former is that it's not clear which update proposals are confirmed, or when, without replicating the complex logic of the update system. The latter involves the explorer using the ledger library's rules to maintain the ledger state, and then emitting the changes in the update system state into the DB.
The explorer should provide access to current and historical parameters in the ledger state from the update system / update proposals.
There's two approaches to this: track confirmed update proposals, or track the ledger state. The difficulty with the former is that it's not clear which update proposals are confirmed, or when, without replicating the complex logic of the update system. The latter involves the explorer using the ledger library's rules to maintain the ledger state, and then emitting the changes in the update system state into the DB.