Filecoin/FVM: Study Notes

Study Steps

  1. read

  2. read The Filecoin Virtual Machine: Everything You Need to Know

  3. read

  4. read How Filecoin storage and retrieval works

  5. watch Space Warp Summit 🛸 Understanding the FVM - Raul Kripalani

  6. watch Space Warp Summit 🛸 Programming on the FEVM - Zak Ayesh


  • Filecoin is built on top of the same software powering IPFS protocol but they are different networks

  • Filecoin is different from IPFS because it has an incentive layer on top to incentivize contents to be reliably stored and accessed

  • FVM has the additional ability to access verified proof of stored data within the virtual machine’s native environment

Key Concepts

  • The Filecoin blockchain

    • Tipsets, Blocks, Messages

    • Actors (smart contract): 11 built-in actors

    • Nodes: chain verifier nodes, client nodes, storage provider nodes, and retrieval provider nodes. Any node participating in the Filecoin network should provide the chain verification service as a minimum.

    • Consensus

      • like proof-of-stake, Filecoin uses proof-of-storage for the leader election

      • relies on DRAND for randomness

      • Block production process

        • 30 secs each epoch/round

        • finality: 900 epochs (~7.5hr)

    • Addresses: f410 represents Ethereum addresses

    • Proofs

      • Sealing: Proof of Replication (PoRep)

      • Proof of Spacetime (PoSt)

        • WinningPoSt & WindowPoSt: be aware of the subtle differences

        • every sector is audited at least once every 24 hours

      • Collateral and Slashing

  • Storage & Retrieval

    • Storage and Retrieval markets

    • Storage and Retrieval Providers

    • Deals

    • Sectors: basic units of provable storage

      • 32 GiB and 64 GiB sector sizes are supported.
  • Compute-over-data & Compute-over-state

    • FVM is computer-over-state (i.e. metadata of the stored data such as cids)

      • It manipulates the metadata of the stored data deal. It does not manipulate the data stored in that deal.
    • FVM is built on top of Filecoin’s network. There is no additional chain.

    • FVM is WASM native and virtual machine-agnostic

    • FEVM is virtualized as a runtime (i.e. an actor) on top of FVM

    • delayed execution: messages/transactions included in one epoch won’t be executed until the next epoch. So it takes about ~1min before you can see the state change.


  • Storage

    • The network doesn’t guarantee the data availability. If your SP (storage provide) loses your data, they will get slashed but your data is permanently lost. So it’s recommended to make deals with multiple SPs for redundancy. But again, there is no guarantee.

    • Right now, verifiers to verify clients and allocate DataCap are chosen in a centralized way.

    • Right now, the Filecoin network does not allow modifying the data once a deal is made.

  • Deals

    • Currently a deal in Filecoin has a minimum duration of 180 days

    • You might want to decide on a specific provider based on their reputation or power in the network. But reputation metrics for miners are not part of the Filecoin protocol yet.

    • to create a deal, it’s a non-trivial process (e.g. you need to download and install the Lotus client)

  • Retrieval

    • Similar as storage, to avoid extortion, always ensure you store your data with a fairly decentralized set of storage providers (and note: it’s pretty difficult for a storage provider to be sure they are the only person storing a particular piece of data, especially if you encrypt the data).

    • Basic retrieval is slow (i.e. the unsealing process is non-trivial) and can take hours. The core team is working on it this year to achieve sub-millisecond speed. Right now you can use Saturn which is a CDN layer built on top of Filecoin.

    • Retrieval deals, unlike storage deals, happen mostly off-chain facilitated by payment channels. Depending on whether the miner has the data in their block-store or not, they might need to first unseal it.

  • FVM & FEVM

    • No Ethereum gas accounting: metering and execution halt based on Filecoin rules


My goal of studying Filecoin/FVM is to figure out whether I can use Filecoin as the DA layer for a rollup using the OP stack. Specifically, I am looking for a decentralized, affordable, reliable and scalable DA layer. My conclusion is although it’s pretty decentralized and affordable, it’s not reliable in regards to usability and security.

The biggest issue is data(*) stored in the Filecoin network cannot be modified. But a DA layer for a rollup needs to constantly update the data (i.e. receive deposit transactions and transaction batches, update L2 Output Root).

Security is another major concern. The DA layer for a rollup can be much more valuable economically than the collateral from the SPs. So it’s hard to protect against extortions on retrieval. Given the nature of a rollup, it’s very likely the DA layer needs to be public which implies everyone will know the SPs that are storing the data. Thus, the encryption approach mentioned here won’t work and an extortion can still happen if the SPs collude together.

Slow native retrieval data is a less important concern. But it will influence the L2 chain derivation process. Saturn can be used to workaround the problem but that also means an additional trust dependency is added.

Note that the discussion is focused on using the Filecoin network’s storage as the DA layer, mainly for it’s cheap storage cost. However, the Filecoin blockchain itself can also be the DA layer but that does not give many advantages over other L1s. The 7.5-hour finality time and 30-sec epoch are just too slow even comparing to the benchmark Ethereum network.

*: “data” here does not include the data on the blockchain.


Appendix: Unanswered Questions

Note: I am not going to spend more time on the list as I have already figured out that Filecoin won’t be a good DA layer for what I need.


  1. Is the revenue of the Filecion ecosystem mainly from the storage/retrieval markets? What's the size of the revenue? Is there a dashboard for the data?

  2. For SP, how much is the required collateral? There are some formulas on the spec but I'd like to know some estimated dollar values.

  3. What's the current sector fault rate? Is there a dashboard to track? Where can I find any example of enforced slash transactions? Is the fault fee paid back to the sector data owner?


  1. Does PoSt uses data availability sampling to prove the data?

  2. In FVM, is the state storage and transaction history persistent? are there any mechanisms for state expiry and old data pruning?

  3. It seems that there aren't any orders for the blocks inside one tipset. Then how to enforce transaction orders inside those parallel blocks?

  4. What's the maximum allowed number of blocks in a tipset? What's the block size limit and the implies TPS?

  5. Does the FVM transactions (e.g. contract call) have the same priority as other types of messages (e.g. ProveCommitSector) from the miner's perspective?

  6. How to prove the stored/retrieved data is the original one and not tampered, if the owner does not keep a copy?

  7. How to determine the assigned weight to a tipset?

Subscribe to bap2pecs
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
This entry has been permanently stored onchain and signed by its creator.