Skip to content

Events: implement and integrate an event store #1108

Closed
@raulk

Description

@raulk

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:

  1. If we want to introduce dedicated maintenance processes for events.
  2. If we want to unify the event indexing system (sqlite) with the event storage system (blockstore).
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions