read The Filecoin Virtual Machine: Everything You Need to Know
watch Space Warp Summit 🛸 Understanding the FVM - Raul Kripalani
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
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
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
Filecoin plus and verified clients
Storage on-ramps
Basic retrieval & Saturn
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)
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: 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.
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
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.
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
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?
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.
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
Does PoSt uses data availability sampling to prove the data?
In FVM, is the state storage and transaction history persistent? are there any mechanisms for state expiry and old data pruning?
It seems that there aren't any orders for the blocks inside one tipset. Then how to enforce transaction orders inside those parallel blocks?
What's the maximum allowed number of blocks in a tipset? What's the block size limit and the implies TPS?
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?
How to prove the stored/retrieved data is the original one and not tampered, if the owner does not keep a copy?
How to determine the assigned weight to a tipset?