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
  • Address
  • Block
  • Blockchain
  • Block height
  • Capacity commitment
  • CommP
  • Content IDentifier (CID)
  • Collateral
  • Deal
  • Election
  • Epoch
  • FIL
  • Faucet
  • Fault
  • Filecoin
  • Finality
  • Gas
  • Mainnet
  • Message
  • Merkle Directed Acyclic Graph
  • Miner
  • Pledged storage
  • Proof-of-Storage
  • Proof-of-Replication (PoRep)
  • Proof-of-Spacetime (PoSt)
  • Quality-adjusted storage power
  • Retrieval provider
  • Seal
  • Sector
  • Slash
  • Storage provider
  • Storage power
  • Zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK)
  • Testnet
  • Tipset
  • Verified client
  • Window Proof-of-Spacetime (WindowPoSt)
  • Winning Proof-of-Spacetime (WinningPoSt)

Was this helpful?

Edit on GitHub
Export as PDF
  1. Reference
  2. General

Glossary

Authoritative definitions and proper usage for all Filecoin terminology, including sectors, storage providers, sealing, and blockchain concepts. The definitive reference for understanding Filecoin tec

PreviousGeneralNextSpecifications

Last updated 1 day ago

Was this helpful?

This comprehensive glossary provides definitions for all Filecoin terminology, including detailed explanations of sectors, storage mechanisms, and network roles. Use this as your definitive reference for understanding Filecoin technical concepts.

Address

In the Filecoin network, an address is a unique cryptographic value that serves to publicly identify a user. This value, a public key, is paired with a corresponding private key. The mathematical relationship between the two keys is such that access to the private key allows the creation of a signature that can be verified with the public key. Filecoin specifically employs the Boneh–Lynn–Shacham (BLS) signature scheme for this purpose.

Block

In a blockchain, a block is the fundamental unit of record. Each block is cryptographically linked to one or more previous blocks. Blocks typically contain relating changes to some state (for example, financial records) tracked by the blockchain.

Blockchain

Fundamentally, a blockchain is a system of record in which new records, or are cryptographically linked to preceding records. This construction is a foundational component of secure, verifiable, and distributed transaction ledgers.

Block height

The height of a corresponds to the number of elapsed before the block was added to the blockchain. The height of the Filecoin is defined to be the maximum height of any block in the blockchain.

Capacity commitment

If a storage provider doesn’t find any available deal proposals appealing, they can alternatively make a capacity commitment, filling a with arbitrary data, rather than with client data. Maintaining this sector allows the storage provider to provably demonstrate that they are reserving space on behalf of the network.

CommP

The commitment phase of the Proof-of-Replication (PoRep) process. PoRep is a mechanism used to verify that a storage provider is storing data on behalf of a client by requiring the provider to prove that they have replicated the client’s data to their storage space.

Content IDentifier (CID)

A self-describing format for referencing data in distributed information systems by it’s contents, rather than its location using cryptographic hashing and self-describing formats. It is a core component of IPFS and IPLD, which are in turn components of Filecoin.

Collateral

Deal

Two participants in the Filecoin network can enter into a deal in which one party contracts the services of the other. The Filecoin specification currently details storage deals (in which one party agrees to store data for the other for a specified length of time) and retrieval deals (in which one party agrees to transmit specified data to the other).

Election

Epoch

FIL

FIL is the name of the Filecoin unit of currency; it is alternatively denoted by the Unicode symbol for an integral with a double stroke (⨎).

Faucet

Fault

Filecoin

The term Filecoin is used generically to refer to the Filecoin project, protocol, and network.

Finality

Gas

Mainnet

A portmanteau of “main” and “network, mainnet is a term used to refer to the predominant public-facing network of the Filecoin project and community. The mainnet embodies an expectation of widespread adoption and permanence; changes to its protocol are subject to the adoption of the network participants.

If used as a proper noun, capitalize the term: “I am providing on Mainnet.”

Message

Merkle Directed Acyclic Graph

Abbreviated as Merkle DAG. A graph data structure where nodes:

  • Have a unique identifier that is the hash of the nodes contents

  • Are directionally related to other nodes

  • Never form a closed loop

Merkle DAGs are a fundamental component for the representation of relationships between content-addressed data in IPLD, which is in turn used by Filecoin.

Miner

Pledged storage

Proof-of-Storage

Many blockchain networks are underpinned by the notion that participants supply something of value to the blockchain - a contribution that is hard to fake, but which, if actually made, can be trivially verified. Blockchains based in this approach are often said to require “Proof-of-X”, where X is the valued contribution. The Filecoin blockchain values contributions of storage capacity; it is predicated upon a novel Proof-of-Storage construction, distinguishing it from other blockchains that, as is most often the case, require a contribution of computing power.

As a term, Proof-of-Storage refers to the design elements of the Filecoin protocol that allow one to guarantee (to some very high tolerance) that participants that claim to be contributing a given amount of storage are indeed fulfilling that pledge. In fact, Filecoin’s Proof-of-Storage construction provides for a much stronger claim, allowing one to efficiently verify that a participant is storing a particular piece of data, without requiring that one have a copy of the file itself.

Note: “proof” here is used in an informal sense - typically, these proofs take the form of a probabilistic argument, rather than a concrete proof; that is, it might technically be possible to convince other participants that one is making a contribution one is not, but the possibility is so vanishingly slight as to border on impossibility.

Proof-of-Replication (PoRep)

Proof-of-Spacetime (PoSt)

Quality-adjusted storage power

Retrieval provider

Seal

Sector

Storage providers store data on behalf of the Filecoin network in fixed-size blocks of data called sectors.

Slash

Storage provider

Storage power

Zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK)

An argument of knowledge is a construction by which one party, called the prover, can convince another, the verifier, that the prover has access to some piece of information. There are several possible constraints on such constructions:

  • A non-interactive argument of knowledge has the requirement that just a single message, sent from the prover to the verifier, should serve as a sufficient argument.

  • A zero-knowledge argument of knowledge has the requirement that the verifier should not need access to the knowledge the prover has access to in order to verify the prover’s claim.

  • A succinct argument of knowledge is one that can be “quickly” verified, and which is “small”, for appropriate definitions of both of those terms.

Testnet

Note: if used as a proper noun, capitalize the term. For example, “I am providing on Testnet.”

Tipset

Each tipset is assigned a weight corresponding to the amount of storage the network is provided per the commitments encoded in the tipset’s blocks. The consensus protocol of the network directs nodes to build on top of the heaviest chain.

Verified client

Window Proof-of-Spacetime (WindowPoSt)

Winning Proof-of-Spacetime (WinningPoSt)

Storage providers who fail to do this in the necessary window will forfeit their opportunity to mine a block, but will not otherwise incur penalties for their failure to do so.

In order to enter into a , a is required to provide as collateral, to be paid out as compensation to a client in the event that the provider fails to uphold their storage commitment.

Every , a small subset of Filecoin are elected to mine a new for the Filecoin blockchain. A provider’s probability of being elected is roughly proportional to the share of the Filecoin network’s total storage capacity that they contribute.

Time in the Filecoin blockchain is discretized into epochs that are currently thirty seconds in length. Every epoch, a subset of storage providers are elected to each add a new block to the Filecoin blockchain via .

A faucet is a service that provides free . Typically, faucets are run for the benefit of new users in a network, providing them with the necessary seed capital to begin making transactions.

When a fails to complete for a given sector, the Filecoin network registers a fault for that sector, and the provider is . If a storage provider does not resolve the fault quickly, the network assumes they have abandoned their commitment.

Finality refers to the immutability of messages and state recorded to the Filecoin blockchain. As new blocks are added to the blockchain, it becomes more and more difficult for older blocks to be altered, until they become effectively impossible to modify. The finality period is the amount of time that must elapse before a block is considered completely immutable. In the current , this is configured as 900 .

Gas is a property of a , corresponding to the resources involved in including that message in a given . For each message included in a block, the block’s creator extracts a fee from the message’s sender; this fee is proportional to the message’s gas.

The term message is used to refer to data stored as part of a . A block can contain several messages.

The Filecoin project uses the term provider to refer to participants in the network who provide a service of value to a client. Other blockchains, like Ethereum and Bitcoin, use the term miner. At present, the Filecoin specification recognizes two provider types: and .

Storage capacity that a provider has promised to reserve for the Filecoin network via is termed pledged storage.

Proof-of-Replication is a procedure by which a can prove to the Filecoin network that they have created a unique copy of some piece of data on the network’s behalf.

Proof-of-Spacetime is a procedure by which a can prove to the Filecoin network they continue to store a unique copy of some data on behalf of the network. Proof-of-Spacetime manifests in two distinct varieties in the present Filecoin specification: and .

The storage power a earns from a storage deal offered by a will be augmented by a multiplier. Power totals that take into account this multiplier are termed quality adjusted.

A retrieval provider is a Filecoin participant that enters retrieval with clients, agreeing to supply a client with a particular file in exchange for . Note that unlike , retrieval providers are not additionally rewarded with the ability to add blocks to the Filecoin blockchain; their only reward is the fee they extract from the client.

Sealing is one of the fundamental building blocks of the Filecoin protocol. It is a computation-intensive process performed over a that results in a unique representation of the sector. The properties of this new representation are essential to the and the procedures.

When a is registered for a , the Filecoin network will slash the that is supposed to be storing the sector; that is, it will assess penalties to the provider (to be paid out of the fronted by the provider) for their failure to uphold their pledge of storage. When slashing takes place, the power a provider earns for the associated sector is subtracted from the provider’s total power for the purposes of .

A storage provider is a Filecoin participant that stores data on behalf of the network. Storage providers are rewarded for this service through payments by clients that contract their services, as well as by periodic authorization to extend the Filecoin with of their own creation. When they create a block, storage providers are rewarded with newly minted , as well as the transaction fees they can levy on other participants seeking to include in the block.

A storage power is a value roughly proportional to the amount of storage capacity they make available on behalf of the network via or . Storage power is used to select storage providers for rewards in proportion to their contributions to the total network storage capacity.

A zero-knowledge, succinct non-interactive argument of knowledge (zk-SNARK) embodies all of these properties. Filecoin utilizes these constructions to enable its distributed network to efficiently verify that are storing files they pledged to store, without requiring the verifiers to maintain copies of these files themselves.

A portmanteau of “test” and “network, testnet is a term used to refer to one of the .

A is a set of that each have the same and parent tipset; the Filecoin is a chain of tipsets, rather than a chain of blocks.

By basing its blockchain on tipsets, Filecoin can allow multiple to create blocks in the same , increasing network throughput. By construction, this also provides network security: a node that attempts to intentionally prevent the valid blocks of a second node from making it onto the canonical chain runs up against the consensus preference for heavier chains.

To further incentivize the storage of “useful” data over simple , have the additional opportunity to compete for special offered by . Such clients are certified with respect to their intent to offer deals involving the storage of meaningful data, and the power a storage provider earns for these deals is augmented by a multiplier.

Window Proof-of-Spacetime (WindowPoSt) is the mechanism by which the commitments made by are audited. It sees each 24 hour period broken down into a series of windows. Correspondingly, each storage provider’s set of pledged is partitioned into subsets, one subset for each window. Within a given window, each storage provider must submit a for each sector in their respective subset. This requires ready access to each of the challenged sectors, and will result in a proof compressed via being published to the Filecoin as a in a . In this way, every sector of is audited at least once in any 24 hour period, and a permanent, verifiable, and public record attesting to each storage provider’s continued commitment is kept.

The Filecoin network expects constant availability of stored data. Failing to submit WindowPoSt for a sector will result in a , and the storage provider supplying the sector will be .

Winning Proof-of-Spacetime (WinningPoSt) is the mechanism by which are rewarded for their contributions to the Filecoin network. At the beginning of each , a small number of storage providers are to each mine a new . As a requirement for doing so, each provider is tasked with submitting a compressed for a specified . Each elected provider who successfully creates a block is granted , as well as the opportunity to charge other Filecoin participants fees to include in the block.

messages
blocks
block
epochs
blockchain
sector
storage deal
storage provider
FIL
epoch
storage providers
block
Winning Proof-of-Spacetime
FIL
storage provider
Window Proof-of-Spacetime
slashed
mainnet
epochs
message
block
block
storage providers
retrieval providers
Proof-of-Replication
storage provider
storage-provider
Window Proof-of-Spacetime
Winning Proof-of-Spacetime
storage provider
verified client
deals
FIL
storage providers
sector
Proof-of-Replication
Proof-of-Spacetime
fault
sector
storage provider
collateral
election
blockchain
blocks
FIL
messages
storage provider’s
capacity commitments
storage deals
storage providers
primary Filecoin testing networks
tipset
blocks
height
blockchain
storage providers
epoch
capacity commitments
storage providers
deals
verified clients
storage providers
sectors
Proof-of-Spacetime
zk-SNARK
blockchain
message
block
pledged storage
fault
slashed
storage providers
epoch
elected
block
Proof-of-Storage
sector
FIL
messages
Was this page helpful?