Nathan F Yospe

Consider supporting using ethers-middleware's TimeLag rather than ad-hoc solutions

1

See e.g. `latest_confirmed_block_number` https://github.com/EspressoSystems/cape/blob/main/eqs/src/configuration.rs#L27 It would be better to explicitly make the connection's Middleware assume the correct lag, and make optimistic calls against that connection explicit.

See [batch submit](https://github.com/EspressoSystems/hotshot-builder-core/issues/114) and [no write locking](https://github.com/EspressoSystems/hotshot-builder-core/issues/115)

Validators (with HotShotQueryService) should be able to restore everything needed for the query service from persistence upon restart.

1

HotShotQueryService::new is called whether or not --reset-store-state is passed, but HotShotQueryService::new resets the FullPersistence and initializes some fields of FullState to their initial states.

Most of the changes needed will happen organically in the process of transitioning to the API modules + DataSource pattern

We currently keep both nullifier set snapshots and deltas for each block commitment. This is currently populated in `validator/src/full_node_mem_data_source.rs`, `impl UpdateMetaStateData for QueryData` `append_block_nullifiers` We can use the deltas to...

Using https://github.com/EspressoSystems/stts looks like a good candidate solution, with a few tweaks.

Implement persistence and in-memory cache of accepted events log, with additional indexing to block id and hash

1

Data back-end for query API requires sequential storage of events, retrieval of events and blocks with associated elaboration

Indexed by sequential block id, with additional map from hash to index (in-memory) in order to support `getblock/hash` endpoint Also include additional data like commitment, state, and possibly accumulated statistics...