Actor Events

[raulk]

This is the discussion thread for the Actor Events FIP: #483.

---

(Copying from there)

This FIP adds the ability for actors to emit externally observable events during execution. It is proposed for nv18, and is necessary for the Filecoin EVM runtime. It relates to other FIPs that will be submitted in the next weeks.

Events are fire-and-forget, and can be thought of as a side effect from execution. The payloads of events are self-describing objects signalling that some important circumstance, action or transition has ocurred.

Actor events enable external agents to observe the activity on chain, and may eventually become the source of internal message triggers.

This FIP introduces a minimal design for actor events, including their schema, a new syscall, a new field in the MessageReceipt structure, and mechanics to commit these execution side effects on the chain. By minimal we mean that the protocol stays largely unopinionated and unprescriptive around higher level concerns like event indexing, traversal, and proofs (e.g. inclusion proofs for light clients), and other future higher-level features.

[anorth]

I think it's worth spending a bit more time up front to evaluate data structures that could be more useful to, e.g, light clients. Putting events in a vanilla merkle tree rather than an AMT could be an immediate win there. Since these are never transmitted, concerns about block size, branching factor etc are much smaller deals than for other structures.

[anorth]

Otherwise, the minimal design looks good.

[anorth]

Ping @raulk I really do think this is worth considering. I suspect that time pressure might have precluded this investigation. But regardless, please provide a justification for this structure in the FIP's design rationale.

[raulk]

Sorry, I missed this. My concern is that we do not have a good understanding of what a Filecoin light client truly is and how it operates (no reference architecture). And we can't adopt any existing frameworks from other chains because we're entirely IPLD based, so there is no precedent. Filecoin light clients are, IMO, an entirely bluesky project and I would like to avoid optimising for them as such optimisations would be entirely speculative.

[raulk]

(Added to FIP).

[anorth]

Regarding the events_root: Option<Cid>: I assume this has been made Optional, rather than a CID of an empty AMT, in an attempt to optimise something when there are no events. I don't think this will win anything though:

• The empty AMT block will already be in the blockstore
• The Receipt is never transmitted anywhere in core consensus operations, so there's no bandwidth cost.

If you still think it's worthwhile, could just write a justification into the design rationale?

[raulk]

Covered here: 9d88dcf

[raulk]

It looks like FIP-0049 (Actor Events) will presumably go live in nv18 together with FEVM. This will allow EVM smart contracts to emit events. However, on the other hand, built-in actors stay eventless, thus creating some disparity.

Developers of observability tools like Lily/Sentinel, and explorers, showed some excitement about emitting events on relevant state transitions or circumstances from built-in actors. They received this well because reading and processing events is a lot simpler than the analysis code they currently have, which is heavily dependent on StateCompute, diffing, and direct state parsing.

At some point we need to embark on the mission of adding events to built-in actors. However, we need to exercise caution. Events have a gas cost (formalized in FIP-0049). This gas for events is paid by users, but these events benefit observability tools by virtue of reducing their operational costs and latencies (which indirectly benefits users too!).

We can't be overzealous in what we expose because that could inflate gas costs. We can't underreach because the value we'd fail to ultimately harness the value.

It makes sense to create a Working Group bringing together the various stakeholders so we can identify and catalogue all possible event candidates, analyse which ones deliver a value/cost ratio, formulate various proposals, and ultimately land one.

[Stebalien]

Interactions With "Read-Only" Mode

FIP-0054 allows a caller to send a message in "read-only" mode, preventing side effects.

Events are currently silently discarded while in read-only mode, but there's an argument to be made that they should be rejected by returning an error.

Thoughts?

[anorth]

I think we should be consistent with the behaviour on attempted storage operations.

• If storage operations are allowed but later reverted, emitting an event may as well do the same (but be omitted from the eventual commitment)
• If storage operations are rejected, then emitting an event should be too. In this case I would expect it's necessary for a callee to be able to check if they're in read-only mode.