Expose consensus events to runtimes
Fixes: https://github.com/oasisprotocol/oasis-core/issues/3862
Moves runtime block history indexer from the roothash service into the consensus service. Extends the indexer to also index runtime relevant events (currently only staking, should also include others).
Roothash service:
- with the removal of the runtime block indexer from the service, the overhead of "tracking" all runtime events is probably not considerable, so in current version of the PR roothash tracks all events (instead of explicitly tracking and subscribing to "Watched/Tracked" runtime events). This change can be reverted.
Runtime event indexing:
-
CommitPendingConsensusEvents(height, events)method is added to the runtime block indexer. For each consensus height the relevant events are indexed and stored in the history as pending events. On runtime blockCommitpending events are moved and stored as the consensus events for the round. Pending events queue is cleared. - Executor node gets consensus events for the round by querying consensus events for all rounds since last successfully processed runtime round. (see:
executor/committee/node.go)
TODO:
- [x] before, the runtime round blocks (via
roothash.WatchBlocks) were emitted only after the round was indexed. Now this is not the case, so the history might not be up-to-date immediately after seeing the event. Should add aWatchBlocksmethod to the runtime history indexer?- could remove the
roothash.WatchBlocksmethod now (in favor ofHistory().WatchBlocks()). The only issue is the keymanager, as it also needs to watch runtime blocks, but is not compatible withRuntimeRegistry(uses same file for localstorage, runtme registry currently assumes compute runtimes)
- could remove the
- [ ] other relevant events (e.g. registry runtime events)
- [ ] runtime history unit tests
- [ ] e2e tests
- [ ] finish runtime side
could remove the roothash.WatchBlocks method now (in favor of History().WatchBlocks()). The only issue is the keymanager, as it also needs to watch runtime blocks, but is not compatible with RuntimeRegistry (uses same file for localstorage, runtme registry currently assumes compute runtimes)
So the keymanager runtimes don't have any roothash blocks of their own, but you probably mean the clientRuntimeWatcher? That is mainly needed for handling epoch transitions and node updates. Maybe we could avoid using those "unmanaged" nodes and watch for those explicitly?
Hm, the common committee node (go/worker/common/committee/node.go) doesn't seem to be invoking the new history-backed WatchBlocks? This could cause problems as now it doesn't wait for any history reindexing?
Yeah currently due to the clientRuntimeWatcher using that and not having any runtime supported there (so no history).
So the keymanager runtimes don't have any roothash blocks of their own, but you probably mean the clientRuntimeWatcher?
Hm another option would be to handle the "no history" case in common/committee/node.go (don't watch for runtime blocks and mark as initialized)