# Filecoin/FVM: Study Notes

By [bap2pecs](https://paragraph.com/@0xb2p) · 2023-01-30

---

Study Steps
-----------

1.  read [https://docs.filecoin.io/about/basics/introduction/](https://docs.filecoin.io/about/basics/introduction/)
    
2.  read [The Filecoin Virtual Machine: Everything You Need to Know](https://hackernoon.com/the-filecoin-virtual-machine-everything-you-need-to-know)
    
3.  read [https://docs.filecoin.io/about/basics/filecoin-faq/](https://docs.filecoin.io/about/basics/filecoin-faq/)
    
4.  read [How Filecoin storage and retrieval works](https://filecoin.io/blog/posts/how-storage-and-retrieval-deals-work-on-filecoin/)
    
5.  watch [Space Warp Summit 🛸 Understanding the FVM - Raul Kripalani](https://www.youtube.com/watch?v=9m3oSxtAivs)
    
6.  watch [Space Warp Summit 🛸 Programming on the FEVM - Zak Ayesh](https://www.youtube.com/watch?v=KcZbXSoUxz4)
    

High-level
----------

*   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](https://drand.love/) for randomness
            
        *   [Block production process](https://docs.filecoin.io/about/basics/introduction/#block-production-process)
            
            *   30 secs each epoch/round
                
            *   finality: 900 epochs (~7.5hr)
                
    *   Addresses: `f410` represents Ethereum addresses
        
    *   Proofs
        
        *   [Sealing](https://spec.filecoin.io/#section-glossary.seal): Proof of Replication (PoRep)
            
        *   Proof of Spacetime (PoSt)
            
            *   [WinningPoSt](https://spec.filecoin.io/#section-algorithms.pos.post.winningpost) & [WindowPoSt](https://spec.filecoin.io/#section-algorithms.pos.post.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
        
        *   Filecoin plus and [verified clients](https://spec.filecoin.io/#section-algorithms.verified_clients)
            
        *   Storage on-ramps
            
            *   [web3.storage](https://web3.storage/): automate data replication over multiple SPs
                
        *   Basic retrieval & [Saturn](https://strn.network/)
            
    *   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
        
        *   compatible with any EVM tools
            
        *   [Filecoin Solidity libraries](https://github.com/Zondax/filecoin-solidity): to interact with built-in actors
            
    *   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.
        

Caveats
-------

*   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](https://docs.filecoin.io/about/basics/filecoin-faq/#who-will-be-selected-to-be-verifiers-to-verify-clients-on-the-network).
        
    *   Right now, the Filecoin network [does not allow modifying the data](https://docs.filecoin.io/about/basics/filecoin-faq/#how-do-you-update-data-stored-on-filecoin) 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](https://docs.filecoin.io/about/basics/filecoin-faq/#even-though-filecoin-will-be-backed-up-to-our-normal-ipfs-pinning-layer-we-still-need-to-know-how-quickly-we-can-access-data-from-the-filecoin-network-how-fast-will-retrieval-be-from-the-filecoin-network). The core team is working on it this year to achieve sub-millisecond speed. Right now you can use [Saturn](https://strn.network/) 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
        

Discussions
-----------

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](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#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](https://docs.filecoin.io/about/basics/filecoin-faq/#how-do-i-know-that-my-storage-provider-will-not-charge-prohibitively-high-costs-for-data-retrieval) 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](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#L2-chain-derivation) process. [Saturn](https://strn.network/) 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._

References
----------

*   [Filecoin Spec](https://spec.filecoin.io/)
    
*   [FVM Space Warp ETHGlobal Hackathon Cheat Sheet](https://github.com/filecoin-project/community/discussions/585#top)
    
*   [Nodes geo-distribution](https://filscan.io/statistics/map)
    
*   [Token distribution](https://spec.filecoin.io/systems/filecoin_token/token_allocation/filtokenallocation.png)
    
*   [FVM roadmap](https://fvm.filecoin.io/#roadmap-4)
    

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._

General

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?
    

Technical

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?

---

*Originally published on [bap2pecs](https://paragraph.com/@0xb2p/filecoin-fvm-study-notes)*
