[Reposted from FVM Forum] Filecoin Ethereum JSON-RPC: tipsets and blocks

[trruckerfling]

[OP @raulk, Sep 2022]

As of Jan 2022, the FVM Forum will be merging into the Filecoin Community Discussion here, as FVM and Filecoin often go hand-in-hand for builders

This is a small explainer post to describe how the Ethereum JSON-RPC endpoint reconciles Filecoin tipsets and blocks.

First of all, remember that the Filecoin network produces multiple blocks at every height/epoch. In simple terms, block producers (miners) run a local function that uses their Quality Adjusted power (as represented in the power table) and randomness from the Drand network to determine if they’re eligible to produce a block for the current epoch. This consensus protocol is called Expected Consensus.

These blocks are assembled in a tipset and execution of their messages is deferred to the next tipset. There can be 0 to infinite blocks in a tipset (theoretically). In practice, we see 5-10 blocks per tipset. And if I recall correctly, the maximum we’ve seen historically is 17 blocks in a tipset!

Wherever you see the term “block” in the Ethereum JSON-RPC, you should mentally read “tipset”. Before FEVM and the Filecoin Ethereum JSON-RPC, there was no single hash referring to a tipset. A tipset ID was the concatenation of block CIDs, which led to a variable length ID and a pretty poor experience.

With the Ethereum JSON-RPC, we introduced the concept of the tipset CID for the first time! It is calculated by hashing the former “tipset key” using a blake-256 hash. Therefore:

• wherever you see “block hash”, think “tipset hash” (blake-256 hash of the tipset key)
• wherever you see “block height”, think “tipset epoch”
• wherever you see “block messages”, think “messages in all blocks in a tipset, in their order of appearance, deduplicated and returned in canonical order of execution”