Filecoin Docs
BasicsStorage providersNodesNetworksSmart contractsReference
  • Welcome to Filecoin Docs
  • Basics
    • What is Filecoin
      • Crypto-economics
      • Blockchain
      • Storage model
      • Storage market
      • Retrieval market
      • Programming on Filecoin
      • Networks
    • The blockchain
      • Actors
      • Addresses
      • Blocks and tipsets
      • Consensus
      • Drand
      • Proofs
    • Assets
      • The FIL token
      • Wallets
      • Metamask setup
      • Get FIL
      • Transfer FIL
    • Interplanetary consensus
    • How storage works
      • Filecoin plus
      • Storage onramps
      • Filecoin and IPFS
    • How retrieval works
      • Basic retrieval
      • Serving retrievals
      • Saturn
    • Project and community
      • Forums and FIPs
      • Filecoin compared to
      • Filecoin FAQs
      • Related projects
      • Social media
      • The Filecoin project
      • Ways to contribute
  • Storage providers
    • Basics
      • Quickstart guide
    • Filecoin economics
      • Storage proving
      • FIL collateral
      • Block rewards
      • Slashing
      • Committed capacity
    • Filecoin deals
      • Storage deals
      • Verified deals
      • Filecoin programs and tools
      • Snap deals
      • Charging for data
      • Auxiliary services
      • Return-on-investment
    • Architecture
      • Software components
      • Storage provider automation
      • Sealing pipeline
      • Sealing rate
      • Sealing-as-a-service
      • Network indexer
    • Infrastructure
      • Storage
      • Network
      • Backup and disaster recovery
      • Reference architectures
    • Skills
      • Linux
      • Network
      • Security
      • Storage
      • Sales
      • Industry
    • PDP
      • Prerequisites
      • Install & Run Lotus
      • Install & Run YugabyteDB
      • Install & Run Curio
      • Enable PDP
      • Use PDP
  • Nodes
    • Implementations
      • Lotus
      • Venus
    • Full-nodes
      • Pre-requisites
      • Basic setup
      • Node providers
    • Lite-nodes
      • Spin up a lite-node
  • Smart contracts
    • Fundamentals
      • The Filecoin Virtual Machine
      • Filecoin EVM runtime
      • ERC-20 quickstart
      • Roadmap
      • Support
      • FAQs
    • Filecoin EVM-runtime
      • Actor types
      • Address types
      • FILForwarder
      • Difference with Ethereum
      • How gas works
      • Precompiles
    • Programmatic storage
      • Aggregated deal-making
      • Direct deal-making
      • Cross-Chain Data Bridge(CCDB)
      • Data replication, renewal and repair (RaaS)
      • RaaS interfaces
    • Developing contracts
      • Get test tokens
      • Remix
      • Hardhat
      • Foundry
      • Solidity libraries
      • Call built-in actors
      • Filecoin.sol
      • Direct deal-making with Client contract
      • Using RaaS
      • Verify a contract
      • Best practices
    • Advanced
      • Wrapped FIL
      • Oracles
      • Multicall
      • Multisig
      • FEVM Indexers
      • Cross-chain bridges
      • Aggregated deal-making
      • Contract automation
      • Relay
  • Networks
    • Mainnet
      • Explorers
      • RPCs
      • Network performance
    • Calibration
      • Explorers
      • RPCs
    • Local testnet
      • Get test tokens
    • Deprecated networks
  • Reference
    • General
      • Glossary
      • Specifications
      • Tools
    • Exchanges
      • Exchange integration
    • Built-in actors
      • Protocol API
      • Filecoin.sol
    • JSON-RPC
      • Auth
      • Chain
      • Client
      • Create
      • Eth
      • Gas
      • I
      • Log
      • Market
      • Miner
      • Mpool
      • Msig
      • Net
      • Node
      • Paych
      • Raft
      • Start
      • State
      • Sync
      • Wallet
      • Web3
  • Builder Cookbook
    • Overview
    • Table of Contents
    • Data Storage
      • Store Data
      • Retrieve Data
      • Privacy & Access Control
    • dApps
      • Chain-Data Query
      • Oracles
      • Cross-Chain Bridges
      • Decentralized Database
Powered by GitBook
LogoLogo

Basics

  • Overview
  • Crypto-economics
  • Storage model
  • Reference

Developers

  • The FVM
  • EVM-runtime
  • Quickstart
  • Transfer FIL

Contact

  • GitHub
  • Slack
  • Twitter
On this page
  • Blockchain
  • Tipsets
  • Actors
  • Nodes
  • Addresses
  • Consensus
  • Proofs

Was this helpful?

Edit on GitHub
Export as PDF
  1. Basics
  2. What is Filecoin

Blockchain

A blockchain is a distributed database shared among nodes in a computer network. This page covers the design and functions of the Filecoin blockchain.

Blockchain

Tipsets

A tipset is a set of blocks with the same height, allowing multiple storage providers to produce blocks in each epoch, increasing network throughput. The Filecoin blockchain consists of a chain of tipsets rather than individual blocks. Each tipset is assigned a weight, enabling the consensus protocol to guide nodes to build on the heaviest chain and preventing interference from nodes attempting to produce invalid blocks.

Actors

Actors are ‘objects’ within the Filecoin network, each with a state and a set of methods for interaction, that pass messages to each other and ensure the system operates appropiately.

Built-in actors

Several built-in system actors power the Filecoin network as a decentralized storage network:

  • Init actor: Initializes new actors and records the network name.

  • Cron actor: Scheduler that runs critical functions at every epoch.

  • Account actor: Manages user accounts (non-singleton).

  • Reward actor: Manages block rewards and token vesting (singleton).

  • Storage miner actor: Manages storage mining operations and validates storage proofs.

  • Storage power actor: Tracks storage power allocation for each provider.

  • Storage market actor: Manages storage deals.

  • Multisig actor: Handles Filecoin multi-signature wallet operations.

  • Payment channel actor: Sets up and settles payment channel funds.

  • Datacap actor: Manages datacap tokens.

  • Verified registry actor: Manages verified clients.

  • Ethereum Address Manager (EAM) actor: Assigns Ethereum-compatible addresses on Filecoin, including EVM smart contract addresses.

  • Ethereum Virtual Machine (EVM) account actor: Represents an external Ethereum identity backed by a secp256k1 key.

  • System actor: General system actor.

Nodes

Filecoin nodes are categorized by the services they provide to the storage network, including chain verifier nodes, client nodes, storage provider nodes, and retrieval provider nodes. All participating nodes must provide chain verification services.

Filecoin supports multiple protocol implementations to enhance security and resilience. Active implementations include:

Addresses

In the Filecoin network, addresses identify actors in the Filecoin state. Each address encodes information about the corresponding actor, making it easy to use and resistant to errors. Filecoin has five address types. Mainnet addresses start with f, and Testnet addresses start with t.

  • f0/t0: ID address for an actor in a human-readable format, such as f0123261 for a storage provider.

  • f1/t1: secp256k1 wallet address, generated from an encrypted secp256k1 public key.

  • f2/t2: Address assigned to an actor in a way that ensures stability across network forks.

  • f3/t3: BLS wallet address, generated from a BLS public key.

  • f4/t4: Address created and assigned to user-defined actors by customizable "address management" actors. This address can receive funds before an actor is deployed.

  • f410/t410: Address space managed by the Ethereum Address Manager (EAM) actor, allowing Ethereum-compatible addresses to interact seamlessly with the Filecoin network. Ethereum addresses can be cast as f410/t410 addresses and vice versa, enabling compatibility with existing Ethereum tools.

Consensus

Expected consensus

Expected Consensus (EC) is the probabilistic, Byzantine fault-tolerant consensus algorithm underlying Filecoin. EC conducts a leader election among storage providers each epoch to determine which provider submits a block. Similar to proof-of-stake, Filecoin’s leader election relies on proof-of-storage, meaning the probability of being elected depends on how much provable storage a miner contributes to the network --measured in something called "storage power".

Ultimately, the EC process ends by gathering all valid blocks produced in an epoch to a tipset, applying a weighting function to select the heaviest chain, and adding the tipset to the heaviest chain accordingly.

Block production process

The block production process for each epoch is as follows:

  • Elect leaders from eligible miners.

  • Miners check if they are elected.

  • Elected miners generate WinningPoSt using randomness.

  • Miners build and propagate a block.

  • Verify the winning miner and election.

  • Select the heaviest chain to add the tipset.

Finality

EC enforces soft finality, where miners at round N reject blocks forking off before round N - F (where F is set to 900). This ensures finality without compromising chain availability.

Proofs

Filecoin operates on proof-of-storage, where miners offer storage space and provide proofs to verify data storage.

Proof of replication

With proof-of-replication (PoRep), storage providers prove they have created a unique copy of the client’s data for the network.

Proof of spacetime

Storage providers must continuously prove that they are storing clients' data throughout the entire duration of the storage deal. The proof-of-spacetime (PoSt) process includes two types of challenges:

  • Winning PoSt: Verifies that a storage provider holds a copy of the data at a specific point in time.

  • Window PoSt: Confirms that the data has been consistently stored over a defined period.

Slashing

If storage providers fail to maintain reliable uptime or act maliciously, they face penalties through a process called slashing. Filecoin enforces two types of slashing:

  • Storage Fault Slashing: Penalizes providers who fail to maintain healthy and reliable storage sectors.

  • Consensus Fault Slashing: Penalizes providers attempting to disrupt the security or availability of the consensus process.

PreviousCrypto-economicsNextStorage model

Last updated 1 month ago

Was this helpful?

The consensus process uses as a randomness beacon for leader election, ensuring the leader election is secret, fair, and verifiable. Election participants and their storage power are drawn from a data structure called the "Power Table", which is continuously calculated and maintained by the storage power actor.

Lotus
Venus
Forest
Drand
Was this page helpful?