Implicit Messages in Block Receipts

[rvagg]

Problem Statement

Currently, Filecoin's system operations (cron and reward) execute via implicit messages during tipset execution, but these operations and their events are essentially invisible in the chain. This creates significant challenges for:

• Tracking sector lifecycle events, especially terminations
• Building comprehensive monitoring tools
• Providing complete API responses about chain operations
• Debugging system operations

Storage providers, developers, and indexers must resort to complex state diff analysis to understand what happened between epochs, making sector management unnecessarily difficult.

Proposed Solution

I'm drafting a FIP that would:

1. Formalize implicit messages (cron and reward) so they can be linked in the chain
2. Modify the MessageReceipt structure to include a reference to the executed message
3. Include receipts for implicit messages in block headers' ParentMessageReceipts array

This would enable proper event tracking for system operations without changing execution semantics or requiring complex block structure changes.

Benefits

• Complete sector lifecycle visibility: Track terminations, extensions and other events through standard mechanisms
• Simplified tooling: No more complex state diff analysis needed
• Enhanced observability: System operations become fully inspectable
• (Potentially) Better APIs: More comprehensive blockchain data available to applications

Technical Impact

• Storage impact is modest: ~12 MiB additional data per day plus blockstore overhead
• Backwards compatibility requires handling different receipt formats pre/post upgrade
• No impact on snapshot format
• No changes to execution semantics

Edit: Initial FIP text proposed @ #1150

[Stebalien]

Another benefit is that it becomes much easier to figure out which messages actually executed. Right now, you need to deduplicate all the messages from the parent tipset blocks.

[Stebalien]

I'd also like to take this as a chance to:

1. Add an IpldCodec field to the receipt. Actor return values technically have an IPLD codec attached to them but we have to drop this in the receipt because we don't have a place to store it.
2. Put every receipt in a separate IPLD object and store them in the AMT by-CID. The downside to this approach is that we get many more objects in the blockstore, although it's equal to the number of messages so it's not a big deal. The upside is that we can avoid large blocks in the receipt AMT. Given that we pack multiple receipts together into the same AMT, we can currently get up to 8MiB blocks, I think? Not many given the block gas limits, but we could still get a few really fat receipt nodes.
3. An alternative to both (1) and (2) is to keep the receipts where they are but store the actual return values in separate blocks (by-CID). I really like this approach because because it separates the metadata from the data but we'll have to think carefully about how we'd expose it in the API.

But I also don't want to add complexity for something that's mostly just a bit of a wart. I'd consider going with option one because it's simple, but 2/3 are probably too much for now.

[rvagg]

Regarding number 1:

That stripping happens here: https://github.com/filecoin-project/ref-fvm/blob/8b42938686aec562e1d472ce29cc19f08abeda37/fvm/src/executor/default.rs#L188-L193

So such a change is going to involve ref-fvm, we need to extend Result to have a codec field, then that has to travel through the ffi boundary for Lotus.

It's annoying to have to touch ref-fvm and filecoin-ffi for this, but that bit isn't network version dependent, we just discard it for versions prior to this FIP and encode it for versions afterward.

Regarding the other item: I'm concerned about the blockstore bloat here and I'd want to put some time into getting numbers before attempting to proceed with either externalising option. It would be annoying to have yet another receipt format in a future upgrade so bundling changes makes sense, it's just more risk.

@Stebalien I assume this is all because EVM actors can return very large blobs (gas limited of course); any idea what maximum sizes for these blobs is? Any idea how common this might be as a smart contract practice? I would have imagined events would be a more standard way of emitting data.

[Stebalien]

I assume this is all because EVM actors can return very large blobs (gas limited of course); any idea what maximum sizes for these blobs is? Any idea how common this might be as a smart contract practice? I would have imagined events would be a more standard way of emitting data.

Yes. 1MiB. Very uncommon and expensive. 1MiB would cost 1.4B gas, or a 5th of a block. On the other hand, not impossible when gas is inexpensive.

[rvagg]

Initial FIP text proposed @ #1150

[gitgavinzhao]

Given that this is not on the critical path for paid storage, it is recommended to lower the priority and focus on paid storage.

[rvagg]

Given that this is not on the critical path for paid storage

It kind of is and is one of the reasons we are pursuing this. The more visibility we can get in to sector lifecycles the more we can link it to deal payment mechanisms. What we want to enable is novel markets outside of f05 to properly unlock paid deals since it's the expense and inflexibility of f05 that gets in our way. Being able to report back to smart contracts that implement new forms of deal markets and payment mechanisms gives us new ways to attract different kinds of payments for storage. Without the full sector lifecycle being visible we only get part of the picture - a sector's activation is currently fairly easily visible, but the termination (early or otherwise) isn't and imposes so much friction that we basically have only 1 member of the ecosystem (Lily) figuring this out for us by using complex state diffing, but it's not suitable for plugging into deal flows.

[LesnyRumcajs]

So that we don't forget, the last paragraph at https://spec.filecoin.io/systems/filecoin_vm/interpreter/#section-systems.filecoin_vm.interpreter.implicit-messages will need to be changed. I don't know how rigorous we were in the past in keeping the spec up-to-date.

[LesnyRumcajs]

The spec says:

For each block in a tipset, an implicit message:

• invokes the block producer’s miner actor to process the (already-validated) election PoSt submission, as the first message in the block;
• invokes the reward actor to pay the block reward to the miner’s owner account, as the final message in the block;

For each tipset, an implicit message:

• invokes the cron actor to process automated checks and payments, as the final message in the tipset.

Is this change not going to include the miner messages? Or is the spec out-of-date?

[rvagg]

Looks out of date to me but I'm entirely lacking history here to understand what the delta is. From what I can see, we only do the two: reward as the final in the block, and cron as the final in the tipset. Plus the optional null round crons at the start of a tipset if there were any.

@Kubuxu @ZenGround0 one of you might know the history here to understand what's changed, or add a needed correction to the current understanding of implicits?

[Kubuxu]

invokes the block producer’s miner actor to process the (already-validated) election PoSt submission, as the first message in the block;

Probably never happened, these I think get validated as part of the sync process.

We started with pay for minting a block and post-tipset for cron, then we figured out we need null-block catchup, which happens at the start of the block, so that got added.

[ZenGround0]

This is a rare find that is 6 years out of date predating the actual construction we went with on mainnet launch. Most of the spec is merely 2-4 years out of date. We'd do better to remove the spec entirely since it is unmaintained and largely factually incorrect. At the very least there should be some warning

@lanzafame do you know if Stef at the foundation made any progress with an LLM rewrite of the filecoin spec?

[lanzafame]

We are moving towards a solution starting with FIPs and looking to update the spec. We are unfortunately not at a point yet to be of use in this regard.

[BigLep]

Capturing notes from a 2025-06-25 discussion between @rvagg and me: we agreed that a PR against FIP-0107.md should be opened that covers:

• Proposed answers for the "open questions". We're suggesting to take the approach of not changing existing APIs (i.e., ETH and non-ETH APIs would continue to not return implicit messages). APIs can be modified or added in the future if useful.
• Expected mechanism for a user to get implicit messages. (I forgot which API @rvagg was suggesting.)
  Doing this should make it even easier for Lotus and Forest devs to pick up the FIP and implement it completely.

[rvagg]

See #1173 for this.

[zixuanzh]

While we are at this topic, is it possible to add a receipt too for penalties (daily fault fee, termination penalty, etc) as they are incurred for better accounting visibility ? Those fees are currently charged as implicit transactions too which is a pain to extract.

[rvagg]

Why yes, we can. Here's my draft FIP, care to have a look over it and tell me what you think? https://hackmd.io/F_Wz6S87RNG9hIqMt8tG9g (Probably best to comment here for visibility).

I haven't progressed with this yet because I'm not entirely convinced the extra costs (mainly storage costs for nodes collecting events) were worth the outcome.