Description
The current implementation of events is flushing event AMTs through the buffered blockstore on every message execution. These AMTs are immediately visible in the client (CgoBlockstore in the case of Lotus). But this does not mean that the AMTs are committed to disk; instead, most clients use overlay blockstores which they throw away when estimating gas, or when validating blocks (without comitting a parent tipset). The event indexing system in Lotus loads events from the blockstore.
I argue this pattern is fine for now, at least for Lotus. Lotus still uses a single blockstore for state and chain data. Events land in the universal blockstore, as do receipts, and events are reachable from the receipts so it all checks in terms of traversability.
The reasons why we'd want to move to a different architecture include:
- If we want to introduce dedicated maintenance processes for events.
- If we want to unify the event indexing system (sqlite) with the event storage system (blockstore).
- If we want to change the pattern by which these events are written (we now do eager push, we may want to move towards a pull model, or something else).
In terms of regenerability, events fall in the same bucket as receipts. Receipts can be regenerated easily, but we still store them.