# IntroductionState reliableTheory Audit n/aEdit this sectionsection-intro

Filecoin is a distributed storage network based on a blockchain mechanism. Filecoin miners can elect to provide storage capacity for the network, and thereby earn units of the Filecoin cryptocurrency (FIL) by periodically producing cryptographic proofs that certify that they are providing the capacity specified. In addition, Filecoin enables parties to exchange FIL currency through transactions recorded in a shared ledger on the Filecoin blockchain. Rather than using Nakamoto-style proof of work to maintain consensus on the chain, however, Filecoin uses proof of storage itself: a miner’s power in the consensus protocol is proportional to the amount of storage it provides.

The Filecoin blockchain not only maintains the ledger for FIL transactions and accounts, but also implements the Filecoin VM, a replicated state machine which executes a variety of cryptographic contracts and market mechanisms among participants on the network. These contracts include storage deals, in which clients pay FIL currency to miners in exchange for storing the specific file data that the clients request. Via the distributed implementation of the Filecoin VM, storage deals and other contract mechanisms recorded on the chain continue to be processed over time, without requiring further interaction from the original parties (such as the clients who requested the data storage).

## Spec StatusState reliableTheory Audit n/aEdit this sectionsection-intro.spec-status

Each section of the spec must be stable and audited before it is considered done. The state of each section is tracked below.

• The State column indicates the stability as defined in the legend.
• The Theory Audit column shows the date of the last theory audit with a link to the report.

### Spec Status LegendState reliableTheory Audit n/aEdit this sectionsection-intro.spec-status-legend

Spec stateLabel
Unlikely to change in the foreseeable future.Stable
All content is correct. Important details are covered.Reliable
All content is correct. Details are being worked on.Draft/WIP
Do not follow. Important things have changed.Incorrect
No work has been done yet.Missing

### Spec Status OverviewState reliableTheory Audit n/aEdit this sectionsection-intro.spec-status-overview

SectionStateTheory Audit
1 IntroductionReliable
1.2 Architecture DiagramsReliable
1.3 Key ConceptsReliable
1.4 Filecoin VMReliable
1.5 System DecompositionReliable
1.5.1 What are Systems? How do they work?Reliable
1.5.2 Implementing SystemsReliable
2 SystemsDraft/WIP
2.1 Filecoin NodesReliable
2.1.1 Node TypesStable
2.1.2 Node RepositoryStable
2.1.2.1 Key StoreReliable
2.1.2.2 IPLD StoreStableDraft/WIP
2.1.3 Network InterfaceStable
2.1.4 ClockReliable
2.2 Files & DataReliable
2.2.1 FileReliable
2.2.1.1 FileStore - Local Storage for FilesReliable
2.2.2 The Filecoin PieceStable
2.2.3 Data Transfer in FilecoinStable
2.2.4 Data Formats and SerializationReliable
2.3 Virtual MachineReliable
2.3.1 VM Actor InterfaceReliableDraft/WIP
2.3.2 State TreeReliableDraft/WIP
2.3.3 VM Message - Actor Method InvocationReliableDraft/WIP
2.3.4 VM Runtime Environment (Inside the VM)Reliable
2.3.5 Gas FeesReliableReport Coming Soon
2.3.6 System ActorsReliableReports
2.3.7 VM Interpreter - Message Invocation (Outside VM)Draft/WIPDraft/WIP
2.4 BlockchainReliableDraft/WIP
2.4.1 BlocksReliable
2.4.1.1 BlockReliable
2.4.1.2 TipsetReliable
2.4.1.3 Chain ManagerReliable
2.4.1.4 Block ProducerReliableDraft/WIP
2.4.2 Message PoolStableDraft/WIP
2.4.2.1 Message PropagationStable
2.4.2.2 Message StorageStable
2.4.3 ChainSyncStable
2.4.4 Storage Power ConsensusReliableDraft/WIP
2.4.4.6 Storage Power ActorReliableDraft/WIP
2.5 TokenReliable
2.5.1 Minting ModelReliable
2.5.2 Block Reward MintingReliable
2.5.3 Token AllocationReliable
2.5.4 Payment ChannelsStableDraft/WIP
2.5.5 Multisig Wallet & ActorReliableReports
2.6 Storage MiningReliableDraft/WIP
2.6.1 SectorStable
2.6.1.1 Sector LifecycleStable
2.6.1.2 Sector QualityStable
2.6.1.3 Sector SealingStableDraft/WIP
2.6.1.4 Sector FaultsStableDraft/WIP
2.6.1.5 Sector RecoveryReliableDraft/WIP
2.6.2 Storage MinerReliableDraft/WIP
2.6.2.4 Storage Mining CycleReliableDraft/WIP
2.6.2.5 Storage Miner ActorDraft/WIPReports
2.6.3 Miner CollateralsReliable
2.6.4 Storage ProvingDraft/WIPDraft/WIP
2.6.4.2 Sector PosterDraft/WIPDraft/WIP
2.6.4.3 Sector SealerDraft/WIPDraft/WIP
2.7 MarketsStable
2.7.1 Storage Market in FilecoinStableDraft/WIP
2.7.2 Storage Market On-Chain ComponentsReliableDraft/WIP
2.7.2.3 Storage Market ActorReliableReports
2.7.2.4 Storage Deal FlowReliableDraft/WIP
2.7.2.5 Storage Deal StatesReliable
2.7.2.6 FaultsReliableDraft/WIP
2.7.3 Retrieval Market in FilecoinStable
2.7.3.5 Retrieval Peer ResolverStable
2.7.3.6 Retrieval ProtocolsStable
2.7.3.7 Retrieval ClientStable
2.7.3.8 Retrieval Provider (Miner)Stable
2.7.3.9 Retrieval Deal StatusStable
3 LibrariesReliable
3.1 DRANDStableReports
3.2 IPFSStableDraft/WIP
3.3 MultiformatsStable
3.4 IPLDStable
3.5 Libp2pStableDraft/WIP
4 AlgorithmsDraft/WIP
4.1 Expected ConsensusReliableDraft/WIP
4.2 Proof-of-StorageReliableDraft/WIP
4.2.2 Proof-of-Replication (PoRep)ReliableDraft/WIP
4.2.3 Proof-of-Spacetime (PoSt)ReliableDraft/WIP
4.3 Stacked DRG Proof of ReplicationStableReport Coming Soon
4.3.16 SDR Notation, Constants, and TypesStableReport Coming Soon
4.4 BlockSyncStable
4.5 GossipSubStableReports
4.6 Cryptographic PrimitivesDraft/WIP
4.6.1 SignaturesDraft/WIPReport Coming Soon
4.6.2 Verifiable Random FunctionIncorrect
4.6.3 RandomnessReliableDraft/WIP
4.7 Verified ClientsDraft/WIPDraft/WIP
4.8 Filecoin CryptoEconomicsReliableDraft/WIP
5 GlossaryReliable
6 AppendixDraft/WIP
6.2 Data StructuresReliable
6.3 Filecoin ParametersDraft/WIP
6.4 Audit ReportsReliable
7 Filecoin ImplementationsReliable
7.1 LotusReliable
7.2 VenusReliable
7.3 ForestReliable
7.4 Fuhon (cpp-filecoin)Reliable
8 Releases

### Spec Stabilization ProgressState reliableTheory Audit n/aEdit this sectionsection-intro.spec-stabilization-progress

This progress bar shows what percentage of the spec sections are considered stable.

WIP 11% Reliable 56% Stable 32%

### Implementations StatusState reliableTheory Audit n/aEdit this sectionsection-intro.implementations-status

Known implementations of the filecoin spec are tracked below, with their current CI build status, their test coverage as reported by codecov.io, and a link to their last security audit report where one exists.

RepoLanguageCITest CoverageSecurity Audit
lotusgoFailed35%Reports
go-fil-marketsgoPassed65%Reports
specs-actorsgoPassed71%Reports
rust-fil-proofsrustFailedUnknownReports
venusgoFailed46%Missing
forestrustFailedUnknownMissing
cpp-filecoinc++Passed30%Missing

## Architecture DiagramsState reliableTheory Audit n/aEdit this sectionsection-intro.arch

Actor State Diagram

## Key ConceptsState reliableTheory Audit n/aEdit this sectionsection-intro.concepts

For clarity, we refer the following types of entities to describe implementations of the Filecoin protocol:

• Data structures are collections of semantically-tagged data members (e.g., structs, interfaces, or enums).

• Functions are computational procedures that do not depend on external state (i.e., mathematical functions, or programming language functions that do not refer to global variables).

• Components are sets of functionality that are intended to be represented as single software units in the implementation structure. Depending on the choice of language and the particular component, this might correspond to a single software module, a thread or process running some main loop, a disk-backed database, or a variety of other design choices. For example, the ChainSync is a component: it could be implemented as a process or thread running a single specified main loop, which waits for network messages and responds accordingly by recording and/or forwarding block data.

• APIs are the interfaces for delivering messages to components. A client’s view of a given sub-protocol, such as a request to a miner node’s Storage Provider component to store files in the storage market, may require the execution of a series of API requests.

• Nodes are complete software and hardware systems that interact with the protocol. A node might be constantly running several of the above components, participating in several subsystems, and exposing APIs locally and/or over the network, depending on the node configuration. The term full node refers to a system that runs all of the above components and supports all of the APIs detailed in the spec.

• Subsystems are conceptual divisions of the entire Filecoin protocol, either in terms of complete protocols (such as the Storage Market or Retrieval Market), or in terms of functionality (such as the VM - Virtual Machine). They do not necessarily correspond to any particular node or software component.

• Actors are virtual entities embodied in the state of the Filecoin VM. Protocol actors are analogous to participants in smart contracts; an actor carries a FIL currency balance and can interact with other actors via the operations of the VM, but does not necessarily correspond to any particular node or software component.

## Filecoin VMState reliableTheory Audit n/aEdit this sectionsection-intro.filecoin_vm

The majority of Filecoin’s user facing functionality (payments, storage market, power table, etc) is managed through the Filecoin Virtual Machine (Filecoin VM). The network generates a series of blocks, and agrees which ‘chain’ of blocks is the correct one. Each block contains a series of state transitions called messages, and a checkpoint of the current global state after the application of those messages.

The global state here consists of a set of actors, each with their own private state.

An actor is the Filecoin equivalent of Ethereum’s smart contracts, it is essentially an ‘object’ in the filecoin network with state and a set of methods that can be used to interact with it. Every actor has a Filecoin balance attributed to it, a state pointer, a code CID which tells the system what type of actor it is, and a nonce which tracks the number of messages sent by this actor.

There are two routes to calling a method on an actor. First, to call a method as an external participant of the system (aka, a normal user with Filecoin) you must send a signed message to the network, and pay a fee to the miner that includes your message. The signature on the message must match the key associated with an account with sufficient Filecoin to pay for the message’s execution. The fee here is equivalent to transaction fees in Bitcoin and Ethereum, where it is proportional to the work that is done to process the message (Bitcoin prices messages per byte, Ethereum uses the concept of ‘gas’. We also use ‘gas’).

Second, an actor may call a method on another actor during the invocation of one of its methods. However, the only time this may happen is as a result of some actor being invoked by an external users message (note: an actor called by a user may call another actor that then calls another actor, as many layers deep as the execution can afford to run for).

For full implementation details, see the VM Subsystem.

## System DecompositionState reliableTheory Audit n/aEdit this sectionsection-intro.systems

### What are Systems? How do they work?State reliableTheory Audit n/aEdit this sectionsection-intro.systems.why_systems

Filecoin decouples and modularizes functionality into loosely-joined systems. Each system adds significant functionality, usually to achieve a set of important and tightly related goals.

For example, the Blockchain System provides structures like Block, Tipset, and Chain, and provides functionality like Block Sync, Block Propagation, Block Validation, Chain Selection, and Chain Access. This is separated from the Files, Pieces, Piece Preparation, and Data Transfer. Both of these systems are separated from the Markets, which provide Orders, Deals, Market Visibility, and Deal Settlement.

#### Why is System decoupling useful?State reliableTheory Audit n/aEdit this sectionsection-intro.systems.why_systems.why-is-system-decoupling-useful

This decoupling is useful for:

• Implementation Boundaries: it is possible to build implementations of Filecoin that only implement a subset of systems. This is especially useful for Implementation Diversity: we want many implementations of security critical systems (eg Blockchain), but do not need many implementations of Systems that can be decoupled.
• Runtime Decoupling: system decoupling makes it easier to build and run Filecoin Nodes that isolate Systems into separate programs, and even separate physical computers.
• Security Isolation: some systems require higher operational security than others. System decoupling allows implementations to meet their security and functionality needs. A good example of this is separating Blockchain processing from Data Transfer.
• Scalability: systems, and various use cases, may drive different performance requirements for different opertators. System decoupling makes it easier for operators to scale their deployments along system boundaries.

#### Filecoin Nodes don’t need all the systemsState reliableTheory Audit n/aEdit this sectionsection-intro.systems.why_systems.filecoin-nodes-dont-need-all-the-systems

Filecoin Nodes vary significantly, and do not need all the systems. Most systems are only needed for a subset of use cases.

For example, the Blockchain System is required for synchronizing the chain, participating in secure consensus, storage mining, and chain validation. Many Filecoin Nodes do not need the chain and can perform their work by just fetching content from the latest StateTree, from a node they trust.

Note: Filecoin does not use the “full node” or “light client” terminology, in wide use in Bitcoin and other blockchain networks. In filecoin, these terms are not well defined. It is best to define nodes in terms of their capabilities, and therefore, in terms of the Systems they run. For example:

• Chain Verifier Node: Runs the Blockchain system. Can sync and validate the chain. Cannot mine or produce blocks.
• Client Node: Runs the Blockchain, Market, and Data Transfer systems. Can sync and validate the chain. Cannot mine or produce blocks.
• Retrieval Miner Node: Runs the Market and Data Transfer systems. Does not need the chain. Can make Retrieval Deals (Retrieval Provider side). Can send Clients data, and get paid for it.
• Storage Miner Node: Runs the Blockchain, Storage Market, Storage Mining systems. Can sync and validate the chain. Can make Storage Deals (Storage Provider side). Can seal stored data into sectors. Can acquire storage consensus power. Can mine and produce blocks.

#### Separating SystemsState reliableTheory Audit n/aEdit this sectionsection-intro.systems.why_systems.separating-systems

How do we determine what functionality belongs in one system vs another?

Drawing boundaries between systems is the art of separating tightly related functionality from unrelated parts. In a sense, we seek to keep tightly integrated components in the same system, and away from other unrelated components. This is sometimes straightforward, the boundaries naturally spring from the data structures or functionality. For example, it is straightforward to observe that Clients and Miners negotiating a deal with each other is very unrelated to VM Execution.

Sometimes this is harder, and it requires detangling, adding, or removing abstractions. For example, the StoragePowerActor and the StorageMarketActor were a single Actor previously. This caused a large coupling of functionality across StorageDeal making, the StorageMarket, markets in general, with Storage Mining, Sector Sealing, PoSt Generation, and more. Detangling these two sets of related functionality requried breaking apart the one actor into two.

#### Decomposing within a SystemState reliableTheory Audit n/aEdit this sectionsection-intro.systems.why_systems.decomposing-within-a-system

Systems themselves decompose into smaller subunits. These are sometimes called “subsystems” to avoid confusion with the much larger, first-class Systems. Subsystems themselves may break down further. The naming here is not strictly enforced, as these subdivisions are more related to protocol and implementation engineering concerns than to user capabilities.

### Implementing SystemsState reliableTheory Audit n/aEdit this sectionsection-intro.systems.impl_systems

#### System RequirementsState reliableTheory Audit n/aEdit this sectionsection-intro.systems.impl_systems.system-requirements

In order to make it easier to decouple functionality into systems, the Filecoin Protocol assumes a set of functionality available to all systems. This functionality can be achieved by implementations in a variety of ways, and should take the guidance here as a recommendation (SHOULD).

All Systems, as defined in this document, require the following:

• Repository:
• Local IpldStore. Some amount of persistent local storage for data structures (small structured objects). Systems expect to be initialized with an IpldStore in which to store data structures they expect to persist across crashes.
• User Configuration Values. A small amount of user-editable configuration values. These should be easy for end-users to access, view, and edit.
• Local, Secure KeyStore. A facility to use to generate and use cryptographic keys, which MUST remain secret to the Filecoin Node. Systems SHOULD NOT access the keys directly, and should do so over an abstraction (ie the KeyStore) which provides the ability to Encrypt, Decrypt, Sign, SigVerify, and more.
• Local FileStore. Some amount of persistent local storage for files (large byte arrays). Systems expect to be initialized with a FileStore in which to store large files. Some systems (like Markets) may need to store and delete large volumes of smaller files (1MB - 10GB). Other systems (like Storage Mining) may need to store and delete large volumes of large files (1GB - 1TB).
• Network. Most systems need access to the network, to be able to connect to their counterparts in other Filecoin Nodes. Systems expect to be initialized with a libp2p.Node on which they can mount their own protocols.
• Clock. Some systems need access to current network time, some with low tolerance for drift. Systems expect to be initialized with a Clock from which to tell network time. Some systems (like Blockchain) require very little clock drift, and require secure time.

For this purpose, we use the FilecoinNode data structure, which is passed into all systems at initialization.

#### System LimitationsState reliableTheory Audit n/aEdit this sectionsection-intro.systems.impl_systems.system-limitations

Further, Systems MUST abide by the following limitations:

• Random crashes. A Filecoin Node may crash at any moment. Systems must be secure and consistent through crashes. This is primarily achived by limiting the use of persistent state, persisting such state through Ipld data structures, and through the use of initialization routines that check state, and perhaps correct errors.
• Isolation. Systems must communicate over well-defined, isolated interfaces. They must not build their critical functionality over a shared memory space. (Note: for performance, shared memory abstractions can be used to power IpldStore, FileStore, and libp2p, but the systems themselves should not require it.) This is not just an operational concern; it also significantly simplifies the protocol and makes it easier to understand, analyze, debug, and change.
• No direct access to host OS Filesystem or Disk. Systems cannot access disks directly – they do so over the FileStore and IpldStore abstractions. This is to provide a high degree of portability and flexibility for end-users, especially storage miners and clients of large amounts of data, which need to be able to easily replace how their Filecoin Nodes access local storage.
• No direct access to host OS Network stack or TCP/IP. Systems cannot access the network directly – they do so over the libp2p library. There must not be any other kind of network access. This provides a high degree of portability across platforms and network protocols, enabling Filecoin Nodes (and all their critical systems) to run in a wide variety of settings, using all kinds of protocols (eg Bluetooth, LANs, etc).

# SystemsState wipTheory Audit n/aEdit this sectionsection-systems

In this section we are detailing all the system components one by one in increasing level of complexity and/or interdependence to other system components. The interaction of the components between each other is only briefly discussed where appropriate, but the overall workflow is given in the Introduction section. In particular, in this section we discuss:

• Filecoin Nodes: the different types of nodes that participate in the Filecoin Network, as well as important parts and processes that these nodes run, such as the key store and IPLD store, as well as the network interface to libp2p.
• Files & Data: the data units of Filecoin, such as the Sectors and the Pieces.
• Virtual Machine: the subcomponents of the Filecoin VM, such as the actors, i.e., the smart contracts that run on the Filecoin Blockchain, and the State Tree.
• Blockchain: the main building blocks of the Filecoin blockchain, such as the structure of messages and blocks, the message pool, as well as how nodes synchronise the blockchain when they first join the network.
• Token: the components needed for a wallet.
• Storage Mining: the details of storage mining, storage power consensus, and how storage miners prove storage (without going into details of proofs, which are discussed later).
• Markets: the storage and retrieval markets, which are primarily processes that take place off-chain, but are very important for the smooth operation of the decentralised storage market.

## Filecoin NodesState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes

This section starts by discussing the concept of Filecoin Nodes. Although different node types in the Lotus implementation of Filecoin are less strictly defined than in other blockchain networks, there are different properties and features that different types of nodes should implement. In short, nodes are defined based on the set of services they provide.

In this section we also discuss issues related to storage of system files in Filecoin nodes. Note that by storage in this section we do not refer to the storage that a node commits for mining in the network, but rather the local storage repositories that it needs to have available for keys and IPLD data among other things.

In this section we are also discussing the network interface and how nodes find and connect with each other, how they interact and propagate messages using libp2p, as well as how to set the node’s clock.

### Node TypesState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types

Nodes in the Filecoin network are primarily identified in terms of the services they provide. The type of node, therefore, depends on which services a node provides. A basic set of services in the Filecoin network include:

• chain verification
• storage market client
• storage market provider
• retrieval market client
• retrieval market provider
• storage mining

Any node participating in the Filecoin network should provide the chain verification service as a minimum. Depending on which extra services a node provides on top of chain verification, it gets the corresponding functionality and Node Type “label”.

Nodes can be realized with a repository (directory) in the host in a one-to-one relationship - that is, one repo belongs to a single node. That said, one host can implement multiple Filecoin nodes by having the corresponding repositories.

A Filecoin implementation can support the following subsystems, or types of nodes:

• Chain Verifier Node: this is the minimum functionality that a node needs to have in order to participate in the Filecoin network. This type of node cannot play an active role in the network, unless it implements Client Node functionality, described below. A Chain Verifier Node must synchronise the chain (ChainSync) when it first joins the network to reach current consensus. From then on, the node must constantly be fetching any addition to the chain (i.e., receive the latest blocks) and validate them to reach consensus state.
• Client Node: this type of node builds on top of the Chain Verifier Node and must be implemented by any application that is building on the Filecoin network. This can be thought of as the main infrastructure node (at least as far as interaction with the blockchain is concerned) of applications such as exchanges or decentralised storage applications building on Filecoin. The node should implement the storage market and retrieval market client services. The client node should interact with the Storage and Retrieval Markets and be able to do Data Transfers through the Data Transfer Module.
• Retrieval Miner Node: this node type is extending the Chain Verifier Node to add retrieval miner functionality, that is, participate in the retrieval market. As such, this node type needs to implement the retrieval market provider service and be able to do Data Transfers through the Data Transfer Module.
• Storage Miner Node: this type of node must implement all of the required functionality for validating, creating and adding blocks to extend the blockchain. It should implement the chain verification, storage mining and storage market provider services and be able to do Data Transfers through the Data Transfer Module.

#### Node InterfaceState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.node-interface

The Lotus implementation of the Node Interface can be found here.

#### Chain Verifier NodeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.chain-verifier-node

type ChainVerifierNode interface {
FilecoinNode

systems.Blockchain
}


The Lotus implementation of the Chain Verifier Node can be found here.

#### Client NodeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.client-node

type ClientNode struct {
FilecoinNode

systems.Blockchain
markets.StorageMarketClient
markets.RetrievalMarketClient
markets.DataTransfers
}


The Lotus implementation of the Client Node can be found here.

#### Storage Miner NodeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.storage-miner-node

type StorageMinerNode interface {
FilecoinNode

systems.Blockchain
systems.Mining
markets.StorageMarketProvider
markets.DataTransfers
}


The Lotus implementation of the Storage Miner Node can be found here.

#### Retrieval Miner NodeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.retrieval-miner-node

type RetrievalMinerNode interface {
FilecoinNode

blockchain.Blockchain
markets.RetrievalMarketProvider
markets.DataTransfers
}


#### Relayer NodeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.relayer-node

type RelayerNode interface {
FilecoinNode

blockchain.MessagePool
}


#### Node ConfigurationState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.node_types.node-configuration

The Lotus implementation of Filecoin Node configuration values can be found here.

### Node RepositoryState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.repository

The Filecoin node repository is simply local storage for system and chain data. It is an abstraction of the data which any functional Filecoin node needs to store locally in order to run correctly.

The repository is accessible to the node’s systems and subsystems and can be compartmentalized from the node’s FileStore.

The repository stores the node’s keys, the IPLD data structures of stateful objects as well as the node configuration settings.

The Lotus implementation of the FileStore Repository can be found here.

#### Key StoreState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.repository.key_store

The Key Store is a fundamental abstraction in any full Filecoin node used to store the keypairs associated with a given miner’s address (see actual definition further down) and distinct workers (should the miner choose to run multiple workers).

Node security depends in large part on keeping these keys secure. To that end we strongly recommend: 1) keeping keys separate from all subsystems, 2) using a separate key store to sign requests as required by other subsystems, and 3) keeping those keys that are not used as part of mining in cold storage.

Filecoin storage miners rely on three main components:

• The storage miner actor address is uniquely assigned to a given storage miner actor upon calling registerMiner() in the Storage Power Consensus Subsystem. In effect, the storage miner does not have an address itself, but is rather identified by the address of the actor it is tied to. This is a unique identifier for a given storage miner to which its power and other keys will be associated. The actor value specifies the address of an already created miner actor.
• The owner keypair is provided by the miner ahead of registration and its public key associated with the miner address. The owner keypair can be used to administer a miner and withdraw funds.
• The worker keypair is the public key associated with the storage miner actor address. It can be chosen and changed by the miner. The worker keypair is used to sign blocks and may also be used to sign other messages. It must be a BLS keypair given its use as part of the Verifiable Random Function.

Multiple storage miner actors can share one owner public key or likewise a worker public key.

The process for changing the worker keypairs on-chain (i.e. the worker Key associated with a storage miner actor) is specified in Storage Miner Actor. Note that this is a two-step process. First, a miner stages a change by sending a message to the chain. Then, the miner confirms the key change after the randomness lookback time. Finally, the miner will begin signing blocks with the new key after an additional randomness lookback time. This delay exists to prevent adaptive key selection attacks.

Key security is of utmost importance in Filecoin, as is also the case with keys in every blockchain. Failure to securely store and use keys or exposure of private keys to adversaries can result in the adversary having access to the miner’s funds.

#### IPLD StoreState stableTheory Audit wipEdit this sectionsection-systems.filecoin_nodes.repository.ipldstore

InterPlanetary Linked Data (IPLD) is a set of libraries which allow for the interoperability of content-addressed data structures across different distributed systems and protocols. It provides a fundamental ‘common language’ to primitive cryptographic hashing, enabling data structures to be verifiably referenced and retrieved between two independent protocols. For example, a user can reference an IPFS directory in an Ethereum transaction or smart contract.

The IPLD Store of a Filecoin Node is local storage for hash-linked data.

IPLD is fundamentally comprised of three layers:

• the Block Layer, which focuses on block formats and addressing, how blocks can advertise or self-describe their codec
• the Data Model Layer, which defines a set of required types that need to be included in any implementation - discussed in more detail below.
• the Schema Layer, which allows for extension of the Data Model to interact with more complex structures without the need for custom translation abstractions.

Further details about IPLD can be found in its specification.

##### The Data ModelState stableTheory Audit wipEdit this sectionsection-systems.filecoin_nodes.repository.ipldstore.the-data-model

At its core, IPLD defines a Data Model for representing data. The Data Model is designed for practical implementation across a wide variety of programming languages, while maintaining usability for content-addressed data and a broad range of generalized tools that interact with that data.

The Data Model includes a range of standard primitive types (or “kinds”), such as booleans, integers, strings, nulls and byte arrays, as well as two recursive types: lists and maps. Because IPLD is designed for content-addressed data, it also includes a “link” primitive in its Data Model. In practice, links use the CID specification. IPLD data is organized into “blocks”, where a block is represented by the raw, encoded data and its content-address, or CID. Every content-addressable chunk of data can be represented as a block, and together, blocks can form a coherent graph, or Merkle DAG.

Applications interact with IPLD via the Data Model, and IPLD handles marshalling and unmarshalling via a suite of codecs. IPLD codecs may support the complete Data Model or part of the Data Model. Two codecs that support the complete Data Model are DAG-CBOR and DAG-JSON. These codecs are respectively based on the CBOR and JSON serialization formats but include formalizations that allow them to encapsulate the IPLD Data Model (including its link type) and additional rules that create a strict mapping between any set of data and it’s respective content address (or hash digest). These rules include the mandating of particular ordering of keys when encoding maps, or the sizing of integer types when stored.

##### IPLD in FilecoinState stableTheory Audit wipEdit this sectionsection-systems.filecoin_nodes.repository.ipldstore.ipld-in-filecoin

IPLD is used in two ways in the Filecoin network:

• All system datastructures are stored using DAG-CBOR (an IPLD codec). DAG-CBOR is a more strict subset of CBOR with a predefined tagging scheme, designed for storage, retrieval and traversal of hash-linked data DAGs. As compared to CBOR, DAG-CBOR can guarantee determinism.
• Files and data stored on the Filecoin network are also stored using various IPLD codecs (not necessarily DAG-CBOR).

IPLD provides a consistent and coherent abstraction above data that allows Filecoin to build and interact with complex, multi-block data structures, such as HAMT and AMT. Filecoin uses the DAG-CBOR codec for the serialization and deserialization of its data structures and interacts with that data using the IPLD Data Model, upon which various tools are built. IPLD Selectors can also be used to address specific nodes within a linked data structure.

###### IpldStoresState stableTheory Audit wipEdit this sectionsection-systems.filecoin_nodes.repository.ipldstore.ipldstores

The Filecoin network relies primarily on two distinct IPLD GraphStores:

• One ChainStore which stores the blockchain, including block headers, associated messages, etc.
• One StateStore which stores the payload state from a given blockchain, or the stateTree resulting from all block messages in a given chain being applied to the genesis state by the Filecoin VM.

The ChainStore is downloaded by a node from their peers during the bootstrapping phase of Chain Sync and is stored by the node thereafter. It is updated on every new block reception, or if the node syncs to a new best chain.

The StateStore is computed through the execution of all block messages in a given ChainStore and is stored by the node thereafter. It is updated with every new incoming block’s processing by the VM Interpreter, and referenced accordingly by new blocks produced atop it in the block header’s ParentState field.

### Network InterfaceState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.network

Filecoin nodes use several protocols of the libp2p networking stack for peer discovery, peer routing and block and message propagation. Libp2p is a modular networking stack for peer-to-peer networks. It includes several protocols and mechanisms to enable efficient, secure and resilient peer-to-peer communication. Libp2p nodes open connections with one another and mount different protocols or streams over the same connection. In the initial handshake, nodes exchange the protocols that each of them supports and all Filecoin related protocols will be mounted under /fil/... protocol identifiers.

The complete specification of libp2p can be found at https://github.com/libp2p/specs. Here is the list of libp2p protocols used by Filecoin.

• Graphsync: Graphsync is a protocol to synchronize graphs across peers. It is used to reference, address, request and transfer blockchain and user data between Filecoin nodes. The draft specification of GraphSync provides more details on the concepts, the interfaces and the network messages used by GraphSync. There are no Filecoin-specific modifications to the protocol id.

• Gossipsub: Block headers and messages are propagating through the Filecoin network using a gossip-based pubsub protocol acronymed GossipSub. As is traditionally the case with pubsub protocols, nodes subscribe to topics and receive messages published on those topics. When nodes receive messages from a topic they are subscribed to, they run a validation process and i) pass the message to the application, ii) forward the message further to nodes they know off being subscribed to the same topic. Furthermore, v1.1 version of GossipSub, which is the one used in Filecoin is enhanced with security mechanisms that make the protocol resilient against security attacks. The GossipSub Specification provides all the protocol details pertaining to its design and implementation, as well as specific settings for the protocols parameters. There have been no filecoin specific modifications to the protocol id. However the topic identifiers MUST be of the form fil/blocks/<network-name> and fil/msgs/<network-name>

• Kademlia DHT: The Kademlia DHT is a distributed hash table with a logarithmic bound on the maximum number of lookups for a particular node. In the Filecoin network, the Kademlia DHT is used primarily for peer discovery and peer routing. In particular, when a node wants to store data in the Filecoin network, they get a list of miners and their node information. This node information includes (among other things) the PeerID of the miner. In order to connect to the miner and exchange data, the node that wants to store data in the network has to find the Multiaddress of the miner, which they do by queering the DHT. The libp2p Kad DHT Specification provides implementation details of the DHT structure. For the Filecoin network, the protocol id must be of the form fil/<network-name>/kad/1.0.0.

• Bootstrap List: This is a list of nodes that a new node attempts to connect to upon joining the network. The list of bootstrap nodes and their addresses are defined by the users (i.e., applications).

• Peer Exchange: This protocol is the realisation of the peer discovery process discussed above at Kademlia DHT. It enables peers to find information and addresses of other peers in the network by interfacing with the DHT and create and issue queries for the peers they want to connect to.

### ClockState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.clock

Filecoin assumes weak clock synchrony amongst participants in the system. That is, the system relies on participants having access to a globally synchronized clock (tolerating some bounded offset).

Filecoin relies on this system clock in order to secure consensus. Specifically, the clock is necessary to support validation rules that prevent block producers from mining blocks with a future timestamp and running leader elections more frequently than the protocol allows.

#### Clock usesState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.clock.clock-uses

The Filecoin system clock is used:

• by syncing nodes to validate that incoming blocks were mined in the appropriate epoch given their timestamp (see Block Validation). This is possible because the system clock maps all times to a unique epoch number totally determined by the start time in the genesis block.
• by syncing nodes to drop blocks coming from a future epoch
• by mining nodes to maintain protocol liveness by allowing participants to try leader election in the next round if no one has produced a block in the current round (see Storage Power Consensus).

In order to allow miners to do the above, the system clock must:

1. Have low enough offset relative to other nodes so that blocks are not mined in epochs considered future epochs from the perspective of other nodes (those blocks should not be validated until the proper epoch/time as per validation rules).
2. Set epoch number on node initialization equal to epoch = Floor[(current_time - genesis_time) / epoch_time]

It is expected that other subsystems will register to a NewRound() event from the clock subsystem.

#### Clock RequirementsState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_nodes.clock.clock-requirements

Clocks used as part of the Filecoin protocol should be kept in sync, with offset less than 1 second so as to enable appropriate validation.

Computer-grade crystals can be expected to deviate by 1ppm (i.e. 1 microsecond every second, or 0.6 seconds per week). Therefore, in order to respect the requirement above:

• Nodes SHOULD run an NTP daemon (e.g. timesyncd, ntpd, chronyd) to keep their clocks synchronized to one or more reliable external references.
• We recommend the following sources:
• pool.ntp.org ( details)
• time.cloudflare.com:1234 ( details)
• time.google.com ( details)
• time.nist.gov ( details)
• Larger mining operations MAY consider using local NTP/PTP servers with GPS references and/or frequency-stable external clocks for improved timekeeping.

Mining operations have a strong incentive to prevent their clock skewing ahead more than one epoch to keep their block submissions from being rejected. Likewise they have an incentive to prevent their clocks skewing behind more than one epoch to avoid partitioning themselves off from the synchronized nodes in the network.

## Files & DataState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files

Filecoin’s primary aim is to store client’s Files and Data. This section details data structures and tooling related to working with files, chunking, encoding, graph representations, Pieces, storage abstractions, and more.

### FileState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.file

// Path is an opaque locator for a file (e.g. in a unix-style filesystem).
type Path string

// File is a variable length data container.
// The File interface is modeled after a unix-style file, but abstracts the
// underlying storage system.
type File interface {
Path()   Path
Size()   int
Close()  error

// Read reads from File into buf, starting at offset, and for size bytes.
Read(offset int, size int, buf Bytes) struct {size int, e error}

// Write writes from buf into File, starting at offset, and for size bytes.
Write(offset int, size int, buf Bytes) struct {size int, e error}
}


#### FileStore - Local Storage for FilesState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.file.filestore

The FileStore is an abstraction used to refer to any underlying system or device that Filecoin will store its data to. It is based on Unix filesystem semantics, and includes the notion of Paths. This abstraction is here in order to make sure Filecoin implementations make it easy for end-users to replace the underlying storage system with whatever suits their needs. The simplest version of FileStore is just the host operating system’s file system.

// FileStore is an object that can store and retrieve files by path.
type FileStore struct {
Open(p Path)           union {f File, e error}
Create(p Path)         union {f File, e error}
Store(p Path, f File)  error
Delete(p Path)         error

// Copy(SrcPath, DstPath)
}

##### Varying user needsState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.file.filestore.varying-user-needs

Filecoin user needs vary significantly, and many users – especially miners – will implement complex storage architectures underneath and around Filecoin. The FileStore abstraction is here to make it easy for these varying needs to be easy to satisfy. All file and sector local data storage in the Filecoin Protocol is defined in terms of this FileStore interface, which makes it easy for implementations to make swappable, and for end-users to swap out with their system of choice.

##### Implementation examplesState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.file.filestore.implementation-examples

The FileStore interface may be implemented by many kinds of backing data storage systems. For example:

• The host Operating System file system
• Any Unix/Posix file system
• RAID-backed file systems
• Networked of distributed file systems (NFS, HDFS, etc)
• IPFS
• Databases
• NAS systems
• Raw serial or block devices
• Raw hard drives (hdd sectors, etc)

Implementations SHOULD implement support for the host OS file system. Implementations MAY implement support for other storage systems.

### The Filecoin PieceState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.piece

The Filecoin Piece is the main unit of negotiation for data that users store on the Filecoin network. The Filecoin Piece is not a unit of storage, it is not of a specific size, but is upper-bounded by the size of the Sector. A Filecoin Piece can be of any size, but if a Piece is larger than the size of a Sector that the miner supports it has to be split into more Pieces so that each Piece fits into a Sector.

A Piece is an object that represents a whole or part of a File, and is used by Storage Clients and Storage Miners in Deals. Storage Clients hire Storage Miners to store Pieces.

The Piece data structure is designed for proving storage of arbitrary IPLD graphs and client data. This diagram shows the detailed composition of a Piece and its proving tree, including both full and bandwidth-optimized Piece data structures.

#### Data RepresentationState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.piece.data-representation

It is important to highlight that data submitted to the Filecoin network go through several transformations before they come to the format at which the StorageProvider stores it.

Below is the process followed from the point a user starts preparing a file to store in Filecoin to the point that the provider produces all the identifiers of Pieces stored in a Sector.

The first three steps take place on the client side.

1. When a client wants to store a file in the Filecoin network, they start by producing the IPLD DAG of the file. The hash that represents the root node of the DAG is an IPFS-style CID, called Payload CID.

2. In order to make a Filecoin Piece, the IPLD DAG is serialised into a “Content-Addressable aRchive” (.car) file, which is in raw bytes format. A CAR file is an opaque blob of data that packs together and transfers IPLD nodes. The Payload CID is common between the CAR’ed and un-CAR’ed constructions. This helps later during data retrieval, when data is transferred between the storage client and the storage provider as we discuss later.

3. The resulting .car file is padded with extra zero bits in order for the file to make a binary Merkle tree. To achieve a clean binary Merkle Tree the .car file size has to be in some power of two (^2) size. A padding process, called Fr32 padding, which adds two (2) zero bits to every 254 out of every 256 bits is applied to the input file. At the next step, the padding process takes the output of the Fr32 padding process and finds the size above it that makes for a power of two size. This gap between the result of the Fr32 padding and the next power of two size is padded with zeros.

In order to justify the reasoning behind these steps, it is important to understand the overall negotiation process between the StorageClient and a StorageProvider. The piece CID or CommP is what is included in the deal that the client negotiates and agrees with the storage provider. When the deal is agreed, the client sends the file to the provider (using GraphSync). The provider has to construct the CAR file out of the file received and derive the Piece CID on their side. In order to avoid the client sending a different file to the one agreed, the Piece CID that the provider generates has to be the same as the one included in the deal negotiated earlier.

The following steps take place on the StorageProvider side (apart from step 4 that can also take place at the client side).

1. Once the StorageProvider receives the file from the client, they calculate the Merkle root out of the hashes of the Piece (padded .car file). The resulting root of the clean binary Merkle tree is the Piece CID. This is also referred to as CommP or Piece Commitment and as mentioned earlier, has to be the same with the one included in the deal.

2. The Piece is included in a Sector together with data from other deals. The StorageProvider then calculates Merkle root for all the Pieces inside the Sector. The root of this tree is CommD (aka Commitment of Data or UnsealedSectorCID).

3. The StorageProvider is then sealing the sector and the root of the resulting Merkle root is the CommRLast.

4. Proof of Replication (PoRep), SDR in particular, generates another Merkle root hash called CommC, as an attestation that replication of the data whose commitment is CommD has been performed correctly.

5. Finally, CommR (or Commitment of Replication) is the hash of CommC || CommRLast.

IMPORTANT NOTES:

• Fr32 is a 32-bit representation of a field element (which, in our case, is the arithmetic field of BLS12-381). To be well-formed, a value of type Fr32 must actually fit within that field, but this is not enforced by the type system. It is an invariant which must be perserved by correct usage. In the case of so-called Fr32 padding, two zero bits are inserted ‘after’ a number requiring at most 254 bits to represent. This guarantees that the result will be Fr32, regardless of the value of the initial 254 bits. This is a ‘conservative’ technique, since for some initial values, only one bit of zero-padding would actually be required.
• Steps 2 and 3 above are specific to the Lotus implementation. The same outcome can be achieved in different ways, e.g., without using Fr32 bit-padding. However, any implementation has to make sure that the initial IPLD DAG is serialised and padded so that it gives a clean binary tree, and therefore, calculating the Merkle root out of the resulting blob of data gives the same Piece CID. As long as this is the case, implementations can deviate from the first three steps above.
• Finally, it is important to add a note related to the Payload CID (discussed in the first two steps above) and the data retrieval process. The retrieval deal is negotiated on the basis of the Payload CID. When the retrieval deal is agreed, the retrieval miner starts sending the unsealed and “un-CAR’ed” file to the client. The transfer starts from the root node of the IPLD Merkle Tree and in this way the client can validate the Payload CID from the beginning of the transfer and verify that the file they are receiving is the file they negotiated in the deal and not random bits.

#### PieceStoreState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.piece.piecestore

The PieceStore module allows for storage and retrieval of Pieces from some local storage. The piecestore’s main goal is to help the storage and retrieval market modules to find where sealed data lives inside of sectors. The storage market writes the data, and retrieval market reads it in order to send out to retrieval clients.

The implementation of the PieceStore module can be found here.

### Data Transfer in FilecoinState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer

The Data Transfer Protocol is a protocol for transferring all or part of a Piece across the network when a deal is made. The overall goal for the data transfer module is for it to be an abstraction of the underlying transport medium over which data is transferred between different parties in the Filecoin network. Currently, the underlying medium or protocol used to actually do the data transfer is GraphSync. As such, the Data Transfer Protocol can be thought of as a negotiation protocol.

The Data Transfer Protocol is used both for Storage and for Retrieval Deals. In both cases, the data transfer request is initiated by the client. The primary reason for this is that clients will more often than not be behind NATs and therefore, it is more convenient to start any data transfer from their side. In the case of Storage Deals the data transfer request is initiated as a push request to send data to the storage provider. In the case of Retrieval Deals the data transfer request is initiated as a pull request to retrieve data by the storage provider.

The request to initiate a data transfer includes a voucher or token (none to be confused with the Payment Channel voucher) that points to a specific deal that the two parties have agreed to before. This is so that the storage provider can identify and link the request to a deal it has agreed to and not disregard the request. As described below the case might be slightly different for retrieval deals, where both a deal proposal and a data transfer request can be sent at once.

#### ModulesState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.modules

This diagram shows how Data Transfer and its modules fit into the picture with the Storage and Retrieval Markets. In particular, note how the Data Transfer Request Validators from the markets are plugged into the Data Transfer module, but their code belongs in the Markets system.

#### TerminologyState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.terminology

• Push Request: A request to send data to the other party - normally initiated by the client and primarily in case of a Storage Deal.
• Pull Request: A request to have the other party send data - normally initiated by the client and primarily in case of a Retrieval Deal.
• Requestor: The party that initiates the data transfer request (whether Push or Pull) - normally the client, at least as currently implemented in Filecoin, to overcome NAT-traversal problems.
• Responder: The party that receives the data transfer request - normally the storage provider.
• Data Transfer Voucher or Token: A wrapper around storage- or retrieval-related data that can identify and validate the transfer request to the other party.
• Request Validator: The data transfer module only initiates a transfer when the responder can validate that the request is tied directly to either an existing storage or retrieval deal. Validation is not performed by the data transfer module itself. Instead, a request validator inspects the data transfer voucher to determine whether to respond to the request or disregard the request.
• Transporter: Once a request is negotiated and validated, the actual transfer is managed by a transporter on both sides. The transporter is part of the data transfer module but is isolated from the negotiation process. It has access to an underlying verifiable transport protocol and uses it to send data and track progress.
• Subscriber: An external component that monitors progress of a data transfer by subscribing to data transfer events, such as progress or completion.
• GraphSync: The default underlying transport protocol used by the Transporter. The full graphsync specification can be found here

#### Request PhasesState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.request-phases

There are two basic phases to any data transfer:

1. Negotiation: the requestor and responder agree to the transfer by validating it with the data transfer voucher.
2. Transfer: once the negotiation phase is complete, the data is actually transferred. The default protocol used to do the transfer is Graphsync.

Note that the Negotiation and Transfer stages can occur in separate round trips, or potentially the same round trip, where the requesting party implicitly agrees by sending the request, and the responding party can agree and immediately send or receive data. Whether the process is taking place in a single or multiple round-trips depends in part on whether the request is a push request (storage deal) or a pull request (retrieval deal), and on whether the data transfer negotiation process is able to piggy back on the underlying transport mechanism. In the case of GraphSync as transport mechanism, data transfer requests can piggy back as an extension to the GraphSync protocol using GraphSync’s built-in extensibility. So, only a single round trip is required for Pull Requests. However, because Graphsync is a request/response protocol with no direct support for push type requests, in the Push case, negotiation happens in a seperate request over data transfer’s own libp2p protocol /fil/datatransfer/1.0.0. Other future transport mechinisms might handle both Push and Pull, either, or neither as a single round trip. Upon receiving a data transfer request, the data transfer module does the decoding the voucher and delivers it to the request validators. In storage deals, the request validator checks if the deal included is one that the recipient has agreed to before. For retrieval deals the request includes the proposal for the retrieval deal itself. As long as request validator accepts the deal proposal, everything is done at once as a single round-trip.

It is worth noting that in the case of retrieval the provider can accept the deal and the data transfer request, but then pause the retrieval itself in order to carry out the unsealing process. The storage provider has to unseal all of the requested data before initiating the actual data transfer. Furthermore, the storage provider has the option of pausing the retrieval flow before starting the unsealing process in order to ask for an unsealing payment request. Storage providers have the option to request for this payment in order to cover unsealing computation costs and avoid falling victims of misbehaving clients.

#### Example FlowsState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.example-flows

##### Push FlowState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.push-flow

1. A requestor initiates a Push transfer when it wants to send data to another party.
2. The requestors' data transfer module will send a push request to the responder along with the data transfer voucher.
3. The responder’s data transfer module validates the data transfer request via the Validator provided as a dependency by the responder.
4. The responder’s data transfer module initiates the transfer by making a GraphSync request.
5. The requestor receives the GraphSync request, verifies that it recognises the data transfer and begins sending data.
6. The responder receives data and can produce an indication of progress.
7. The responder completes receiving data, and notifies any listeners.

The push flow is ideal for storage deals, where the client initiates the data transfer straightaway once the provider indicates their intent to accept and publish the client’s deal proposal.

#### Pull Flow - Single Round TripState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.pull-flow---single-round-trip

1. A requestor initiates a Pull transfer when it wants to receive data from another party.
2. The requestor’s data transfer module initiates the transfer by making a pull request embedded in the GraphSync request to the responder. The request includes the data transfer voucher.
3. The responder receives the GraphSync request, and forwards the data transfer request to the data transfer module.
4. The responder’s data transfer module validates the data transfer request via a PullValidator provided as a dependency by the responder.
5. The responder accepts the GraphSync request and sends the accepted response along with the data transfer level acceptance response.
6. The requestor receives data and can produce an indication of progress. This timing of this step comes later in time, after the storage provider has finished unsealing the data.
7. The requestor completes receiving data, and notifies any listeners.

#### ProtocolState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.protocol

A data transfer CAN be negotiated over the network via the Data Transfer Protocol, a libp2p protocol type.

Using the Data Transfer Protocol as an independent libp2p communciation mechanism is not a hard requirement – as long as both parties have an implementation of the Data Transfer Subsystem that can talk to the other, any transport mechanism (including offline mechanisms) is acceptable.

#### Data StructuresState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.data_transfer.data-structures

package datatransfer

import (
"fmt"

"github.com/ipfs/go-cid"
"github.com/ipld/go-ipld-prime"
"github.com/libp2p/go-libp2p-core/peer"

"github.com/filecoin-project/go-data-transfer/encoding"
)

//go:generate cbor-gen-for ChannelID

// TypeIdentifier is a unique string identifier for a type of encodable object in a
// registry
type TypeIdentifier string

// EmptyTypeIdentifier means there is no voucher present
const EmptyTypeIdentifier = TypeIdentifier("")

// Registerable is a type of object in a registry. It must be encodable and must
// have a single method that uniquely identifies its type
type Registerable interface {
encoding.Encodable
// Type is a unique string identifier for this voucher type
Type() TypeIdentifier
}

// Voucher is used to validate
// a data transfer request against the underlying storage or retrieval deal
// that precipitated it. The only requirement is a voucher can read and write
// from bytes, and has a string identifier type
type Voucher Registerable

// voucher being rejected or accepted
type VoucherResult Registerable

// TransferID is an identifier for a data transfer, shared between
// request/responder and unique to the requester
type TransferID uint64

// ChannelID is a unique identifier for a channel, distinct by both the other
// party's peer ID + the transfer ID
type ChannelID struct {
Initiator peer.ID
Responder peer.ID
ID        TransferID
}

func (c ChannelID) String() string {
return fmt.Sprintf("%s-%s-%d", c.Initiator, c.Responder, c.ID)
}

// OtherParty returns the peer on the other side of the request, depending
// on whether this peer is the initiator or responder
func (c ChannelID) OtherParty(thisPeer peer.ID) peer.ID {
if thisPeer == c.Initiator {
return c.Responder
}
return c.Initiator
}

// Channel represents all the parameters for a single data transfer
type Channel interface {
// TransferID returns the transfer id for this channel
TransferID() TransferID

// BaseCID returns the CID that is at the root of this data transfer
BaseCID() cid.Cid

// Selector returns the IPLD selector for this data transfer (represented as
// an IPLD node)
Selector() ipld.Node

// Voucher returns the voucher for this data transfer
Voucher() Voucher

// Sender returns the peer id for the node that is sending data
Sender() peer.ID

// Recipient returns the peer id for the node that is receiving data
Recipient() peer.ID

// TotalSize returns the total size for the data being transferred
TotalSize() uint64

// IsPull returns whether this is a pull request
IsPull() bool

// ChannelID returns the ChannelID for this request
ChannelID() ChannelID

// OtherPeer returns the counter party peer for this channel
OtherPeer() peer.ID
}

// ChannelState is channel parameters plus it's current state
type ChannelState interface {
Channel

// SelfPeer returns the peer this channel belongs to
SelfPeer() peer.ID

// Status is the current status of this channel
Status() Status

// Sent returns the number of bytes sent
Sent() uint64

Message() string

// Vouchers returns all vouchers sent on this channel
Vouchers() []Voucher

// VoucherResults are results of vouchers sent on the channel
VoucherResults() []VoucherResult

// LastVoucher returns the last voucher sent on the channel
LastVoucher() Voucher

// LastVoucherResult returns the last voucher result sent on the channel
LastVoucherResult() VoucherResult

// Queued returns the number of bytes read from the node and queued for sending
Queued() uint64
}

package datatransfer

// Status is the status of transfer for a given channel
type Status uint64

const (
// Requested means a data transfer was requested by has not yet been approved
Requested Status = iota

// Ongoing means the data transfer is in progress
Ongoing

// TransferFinished indicates the initiator is done sending/receiving
// data but is awaiting confirmation from the responder
TransferFinished

// ResponderCompleted indicates the initiator received a message from the
// responder that it's completed
ResponderCompleted

// Finalizing means the responder is awaiting a final message from the initator to
// consider the transfer done
Finalizing

// Completing just means we have some final cleanup for a completed request
Completing

// Completed means the data transfer is completed successfully
Completed

// Failing just means we have some final cleanup for a failed request
Failing

// Failed means the data transfer failed
Failed

// Cancelling just means we have some final cleanup for a cancelled request
Cancelling

// Cancelled means the data transfer ended prematurely
Cancelled

// InitiatorPaused means the data sender has paused the channel (only the sender can unpause this)
InitiatorPaused

// ResponderPaused means the data receiver has paused the channel (only the receiver can unpause this)
ResponderPaused

// BothPaused means both sender and receiver have paused the channel seperately (both must unpause)
BothPaused

// ResponderFinalizing is a unique state where the responder is awaiting a final voucher
ResponderFinalizing

// ResponderFinalizingTransferFinished is a unique state where the responder is awaiting a final voucher
// and we have received all data
ResponderFinalizingTransferFinished

// ChannelNotFoundError means the searched for data transfer does not exist
ChannelNotFoundError
)

// Statuses are human readable names for data transfer states
var Statuses = map[Status]string{
// Requested means a data transfer was requested by has not yet been approved
Requested:                           "Requested",
Ongoing:                             "Ongoing",
TransferFinished:                    "TransferFinished",
ResponderCompleted:                  "ResponderCompleted",
Finalizing:                          "Finalizing",
Completing:                          "Completing",
Completed:                           "Completed",
Failing:                             "Failing",
Failed:                              "Failed",
Cancelling:                          "Cancelling",
Cancelled:                           "Cancelled",
InitiatorPaused:                     "InitiatorPaused",
ResponderPaused:                     "ResponderPaused",
BothPaused:                          "BothPaused",
ResponderFinalizing:                 "ResponderFinalizing",
ResponderFinalizingTransferFinished: "ResponderFinalizingTransferFinished",
ChannelNotFoundError:                "ChannelNotFoundError",
}

Manager is the core interface presented by all implementations of of the data transfer sub system
type Manager interface {

// Start initializes data transfer processing
Start(ctx context.Context) error

// OnReady registers a listener for when the data transfer comes on line

// Stop terminates all data transfers and ends processing
Stop(ctx context.Context) error

// RegisterVoucherType registers a validator for the given voucher type
// will error if voucher type does not implement voucher
// or if there is a voucher type registered with an identical identifier
RegisterVoucherType(voucherType Voucher, validator RequestValidator) error

// RegisterRevalidator registers a revalidator for the given voucher type
// Note: this is the voucher type used to revalidate. It can share a name
// with the initial validator type and CAN be the same type, or a different type.
// The revalidator can simply be the sampe as the original request validator,
// or a different validator that satisfies the revalidator interface.
RegisterRevalidator(voucherType Voucher, revalidator Revalidator) error

// RegisterVoucherResultType allows deserialization of a voucher result,
RegisterVoucherResultType(resultType VoucherResult) error

// RegisterTransportConfigurer registers the given transport configurer to be run on requests with the given voucher
// type
RegisterTransportConfigurer(voucherType Voucher, configurer TransportConfigurer) error

// open a data transfer that will send data to the recipient peer and
// transfer parts of the piece that match the selector
OpenPushDataChannel(ctx context.Context, to peer.ID, voucher Voucher, baseCid cid.Cid, selector ipld.Node) (ChannelID, error)

// open a data transfer that will request data from the sending peer and
// transfer parts of the piece that match the selector
OpenPullDataChannel(ctx context.Context, to peer.ID, voucher Voucher, baseCid cid.Cid, selector ipld.Node) (ChannelID, error)

// send an intermediate voucher as needed when the receiver sends a request for revalidation
SendVoucher(ctx context.Context, chid ChannelID, voucher Voucher) error

// close an open channel (effectively a cancel)
CloseDataTransferChannel(ctx context.Context, chid ChannelID) error

// pause a data transfer channel (only allowed if transport supports it)
PauseDataTransferChannel(ctx context.Context, chid ChannelID) error

// resume a data transfer channel (only allowed if transport supports it)
ResumeDataTransferChannel(ctx context.Context, chid ChannelID) error

// get status of a transfer
TransferChannelStatus(ctx context.Context, x ChannelID) Status

// get notified when certain types of events happen
SubscribeToEvents(subscriber Subscriber) Unsubscribe

// get all in progress transfers
InProgressChannels(ctx context.Context) (map[ChannelID]ChannelState, error)

// RestartDataTransferChannel restarts an existing data transfer channel
RestartDataTransferChannel(ctx context.Context, chid ChannelID) error
}


### Data Formats and SerializationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.serialization

Filecoin seeks to make use of as few data formats as needed, with well-specced serialization rules to better protocol security through simplicity and enable interoperability amongst implementations of the Filecoin protocol.

Read more on design considerations here for CBOR-usage and here for int types in Filecoin.

#### Data FormatsState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.serialization.data-formats

Filecoin in-memory data types are mostly straightforward. Implementations should support two integer types: Int (meaning native 64-bit integer), and BigInt (meaning arbitrary length) and avoid dealing with floating-point numbers to minimize interoperability issues across programming languages and implementations.

You can also read more on data formats as part of randomness generation in the Filecoin protocol.

#### SerializationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_files.serialization.serialization

Data Serialization in Filecoin ensures a consistent format for serializing in-memory data for transfer in-flight and in-storage. Serialization is critical to protocol security and interoperability across implementations of the Filecoin protocol, enabling consistent state updates across Filecoin nodes.

All data structures in Filecoin are CBOR-tuple encoded. That is, any data structures used in the Filecoin system (structs in this spec) should be serialized as CBOR-arrays with items corresponding to the data structure fields in their order of declaration.

You can find the encoding structure for major data types in CBOR here.

For illustration, an in-memory map would be represented as a CBOR-array of the keys and values listed in some pre-determined order. A near-term update to the serialization format will involve tagging fields appropriately to ensure appropriate serialization/deserialization as the protocol evolves.

## Virtual MachineState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm

An Actor in the Filecoin Blockchain is the equivalent of the smart contract in the Ethereum Virtual Machine.

The Filecoin Virtual Machine (VM) is the system component that is in charge of execution of all actors code. Execution of actors on the Filecoin VM (i.e., on-chain executions) incur a gas cost.

Any operation applied (i.e., executed) on the Filecoin VM produces an output in the form of a State Tree (discussed below). The latest State Tree is the current source of truth in the Filecoin Blockchain. The State Tree is identified by a CID, which is stored in the IPLD store.

### VM Actor InterfaceState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_vm.actor

As mentioned above, Actors are the Filecoin equivalent of smart contracts in the Ethereum Virtual Machine. As such, Actors are very central components of the system. Any change to the current state of the Filecoin blockchain has to be triggered through an actor method invocation.

This sub-section describes the interface between Actors and the Filecoin Virtual Machine. This means that most of what is described below does not strictly belong to the VM. Instead it is logic that sits on the interface between the VM and Actors logic.

There are eleven (11) types of builtin Actors in total, not all of which interact with the VM. Some Actors do not invoke changes to the StateTree of the blockchain and therefore, do not need to have an interface to the VM. We discuss the details of all System Actors later on in the System Actors subsection.

The actor address is a stable address generated by hashing the sender’s public key and a creation nonce. It should be stable across chain re-organizations. The actor ID address on the other hand, is an auto-incrementing address that is compact but can change in case of chain re-organizations. That being said, after being created, actors should use an actor address.

package builtin

import (
)

// Addresses for singleton system actors.
var (
// Distinguished AccountActor that is the source of system implicit messages.
// Distinguished AccountActor that is the destination of all burnt funds.
)

const FirstNonSingletonActorId = 100

if err != nil {
panic(err)
}
}


The ActorState structure is composed of the actor’s balance, in terms of tokens held by this actor, as well as a group of state methods used to query, inspect and interact with chain state.

### State TreeState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_vm.state_tree

The State Tree is the output of the execution of any operation applied on the Filecoin Blockchain. The on-chain (i.e., VM) state data structure is a map (in the form of a Hash Array Mapped Trie - HAMT) that binds addresses to actor states. The current State Tree function is called by the VM upon every actor method invocation.

StateTree stores actors state by their ID.
type StateTree struct {
version     types.StateTreeVersion
info        cid.Cid
Store       cbor.IpldStore

snaps *stateSnaps
}


### VM Message - Actor Method InvocationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_vm.message

A message is the unit of communication between two actors, and thus the primitive cause of changes in state. A message combines:

• a token amount to be transferred from the sender to the receiver, and
• a method with parameters to be invoked on the receiver (optional/where applicable).

Actor code may send additional messages to other actors while processing a received message. Messages are processed synchronously, that is, an actor waits for a sent message to complete before resuming control.

The processing of a message consumes units of computation and storage, both of which are denominated in gas. A message’s gas limit provides an upper bound on the computation required to process it. The sender of a message pays for the gas units consumed by a message’s execution (including all nested messages) at a gas price they determine. A block producer chooses which messages to include in a block and is rewarded according to each message’s gas price and consumption, forming a market.

#### Message syntax validationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_vm.message.message-syntax-validation

A syntactically invalid message must not be transmitted, retained in a message pool, or included in a block. If an invalid message is received, it should be dropped and not propagated further.

When transmitted individually (before inclusion in a block), a message is packaged as SignedMessage, regardless of signature scheme used. A valid signed message has a total serialized size no greater than message.MessageMaxSize.

type SignedMessage struct {
Message   Message
Signature crypto.Signature
}


A syntactically valid UnsignedMessage:

• has a well-formed, non-empty To address,
• has a well-formed, non-empty From address,
• has Value no less than zero and no greater than the total token supply (2e9 * 1e18), and
• has non-negative GasPrice,
• has GasLimit that is at least equal to the gas consumption associated with the message’s serialized bytes,
• has GasLimit that is no greater than the block gas limit network parameter.
type Message struct {
// Version of this message (has to be non-negative)
Version uint64

// Address of the receiving actor.
// Address of the sending actor.

CallSeqNum uint64

// Value to transfer from sender's to receiver's balance.
Value BigInt

// GasPrice is a Gas-to-FIL cost
GasPrice BigInt
// Maximum Gas to be spent on the processing of this message
GasLimit int64

// Optional method to invoke on receiver, zero for a plain value transfer.
Method abi.MethodNum
//Serialized parameters to the method.
Params []byte
}


There should be several functions able to extract information from the Message struct, such as the sender and recipient addresses, the value to be transferred, the required funds to execute the message and the CID of the message.

Given that Messages should eventually be included in a Block and added to the blockchain, the validity of the message should be checked with regard to the sender and the receiver of the message, the value (which should be non-negative and always smaller than the circulating supply), the gas price (which again should be non-negative) and the BlockGasLimit which should not be greater than the block’s gas limit.

#### Message semantic validationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_vm.message.message-semantic-validation

Semantic validation refers to validation requiring information outside of the message itself.

A semantically valid SignedMessage must carry a signature that verifies the payload as having been signed with the public key of the account actor identified by the From address. Note that when the From address is an ID-address, the public key must be looked up in the state of the sending account actor in the parent state identified by the block.

Note: the sending actor must exist in the parent state identified by the block that includes the message. This means that it is not valid for a single block to include a message that creates a new account actor and a message from that same actor. The first message from that actor must wait until a subsequent epoch. Message pools may exclude messages from an actor that is not yet present in the chain state.

There is no further semantic validation of a message that can cause a block including the message to be invalid. Every syntactically valid and correctly signed message can be included in a block and will produce a receipt from execution. The MessageReceipt sturct includes the following:

type MessageReceipt struct {
ExitCode exitcode.ExitCode
Return   []byte
GasUsed  int64
}


However, a message may fail to execute to completion, in which case it will not trigger the desired state change.

The reason for this “no message semantic validation” policy is that the state that a message will be applied to cannot be known before the message is executed as part of a tipset. A block producer does not know whether another block will precede it in the tipset, thus altering the state to which the block’s messages will apply from the declared parent state.

package types

import (
"bytes"
"encoding/json"
"fmt"

"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/big"
"github.com/filecoin-project/lotus/build"
block "github.com/ipfs/go-block-format"
"github.com/ipfs/go-cid"
xerrors "golang.org/x/xerrors"

)

const MessageVersion = 0

type ChainMsg interface {
Cid() cid.Cid
VMMessage() *Message
ToStorageBlock() (block.Block, error)
// FIXME: This is the *message* length, this name is misleading.
ChainLength() int
}

type Message struct {
Version uint64

Nonce uint64

Value abi.TokenAmount

GasLimit   int64
GasFeeCap  abi.TokenAmount

Method abi.MethodNum
Params []byte
}

return m.From
}

return m.To
}

func (m *Message) ValueReceived() abi.TokenAmount {
return m.Value
}

func DecodeMessage(b []byte) (*Message, error) {
var msg Message
if err := msg.UnmarshalCBOR(bytes.NewReader(b)); err != nil {
return nil, err
}

if msg.Version != MessageVersion {
return nil, fmt.Errorf("decoded message had incorrect version (%d)", msg.Version)
}

return &msg, nil
}

func (m *Message) Serialize() ([]byte, error) {
buf := new(bytes.Buffer)
if err := m.MarshalCBOR(buf); err != nil {
return nil, err
}
return buf.Bytes(), nil
}

func (m *Message) ChainLength() int {
ser, err := m.Serialize()
if err != nil {
panic(err)
}
return len(ser)
}

func (m *Message) ToStorageBlock() (block.Block, error) {
data, err := m.Serialize()
if err != nil {
return nil, err
}

c, err := abi.CidBuilder.Sum(data)
if err != nil {
return nil, err
}

return block.NewBlockWithCid(data, c)
}

func (m *Message) Cid() cid.Cid {
b, err := m.ToStorageBlock()
if err != nil {
panic(fmt.Sprintf("failed to marshal message: %s", err)) // I think this is maybe sketchy, what happens if we try to serialize a message with an undefined address in it?
}

return b.Cid()
}

type mCid struct {
*RawMessage
CID cid.Cid
}

type RawMessage Message

func (m *Message) MarshalJSON() ([]byte, error) {
return json.Marshal(&mCid{
RawMessage: (*RawMessage)(m),
CID:        m.Cid(),
})
}

func (m *Message) RequiredFunds() BigInt {
return BigMul(m.GasFeeCap, NewInt(uint64(m.GasLimit)))
}

func (m *Message) VMMessage() *Message {
return m
}

func (m *Message) Equals(o *Message) bool {
return m.Cid() == o.Cid()
}

func (m *Message) EqualCall(o *Message) bool {
m1 := *m
m2 := *o

m1.GasLimit, m2.GasLimit = 0, 0
m1.GasFeeCap, m2.GasFeeCap = big.Zero(), big.Zero()

return (&m1).Equals(&m2)
}

func (m *Message) ValidForBlockInclusion(minGas int64) error {
if m.Version != 0 {
return xerrors.New("'Version' unsupported")
}

return xerrors.New("'To' address cannot be empty")
}

return xerrors.New("'From' address cannot be empty")
}

if m.Value.Int == nil {
return xerrors.New("'Value' cannot be nil")
}

if m.Value.LessThan(big.Zero()) {
return xerrors.New("'Value' field cannot be negative")
}

if m.Value.GreaterThan(TotalFilecoinInt) {
return xerrors.New("'Value' field cannot be greater than total filecoin supply")
}

if m.GasFeeCap.Int == nil {
return xerrors.New("'GasFeeCap' cannot be nil")
}

if m.GasFeeCap.LessThan(big.Zero()) {
return xerrors.New("'GasFeeCap' field cannot be negative")
}

}

return xerrors.New("'GasPremium' field cannot be negative")
}

}

if m.GasLimit > build.BlockGasLimit {
return xerrors.New("'GasLimit' field cannot be greater than a block's gas limit")
}

// since prices might vary with time, this is technically semantic validation
if m.GasLimit < minGas {
return xerrors.Errorf("'GasLimit' field cannot be less than the cost of storing a message on chain %d < %d", m.GasLimit, minGas)
}

return nil
}

const TestGasLimit = 100e6


### VM Runtime Environment (Inside the VM)State reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm.runtime

#### ReceiptsState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm.runtime.receipts

A MessageReceipt contains the result of a top-level message execution. Every syntactically valid and correctly signed message can be included in a block and will produce a receipt from execution.

A syntactically valid receipt has:

• a non-negative ExitCode,
• a non empty Return value only if the exit code is zero, and
• a non-negative GasUsed.
type MessageReceipt struct {
ExitCode exitcode.ExitCode
Return   []byte
GasUsed  int64
}


#### vm/runtime Actors InterfaceState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm.runtime.vmruntime-actors-interface

The Actors Interface implementation can be found here

#### vm/runtime VM ImplementationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm.runtime.vmruntime-vm-implementation

The Lotus implementation of the Filecoin Virtual Machine runtime can be found here

#### Exit CodesState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_vm.runtime.exit-codes

There are some common runtime exit codes that are shared by different actors. Their definition can be found here.

### Gas FeesState reliableTheory Audit comingEdit this sectionsection-systems.filecoin_vm.gas_fee

#### SummaryState reliableTheory Audit comingEdit this sectionsection-systems.filecoin_vm.gas_fee.summary

As is traditionally the case with many blockchains, Gas is a unit of measure of how much storage and/or compute resource an on-chain message operation consumes in order to be executed. At a high level, it works as follows: the message sender specifies the maximum amount they are willing to pay in order for their message to be executed and included in a block. This is specified both in terms of total number of units of gas (GasLimit), which is generally expected to be higher than the actual GasUsed and in terms of the price (or fee) per unit of gas (GasFeeCap).

Traditionally, GasUsed * GasFeeCap goes to the block producing miner as a reward. The result of this product is treated as the priority fee for message inclusion, that is, messages are ordered in decreasing sequence and those with the highest GasUsed * GasFeeCap are prioritised, given that they return more profit to the miner.

However, it has been observed that this tactic (of paying GasUsed * GasFee) is problematic for block producing miners for a few reasons. Firstly, a block producing miner may include a very expensive message (in terms of chain resources required) for free in which case the chain itself needs to bear the cost. Secondly, message senders can set arbitrarily high prices but for low-cost messages (again, in terms of chain resources), leading to a DoS vulnerability.

In order to overcome this situation, the Filecoin blockchain defines a BaseFee, which is burnt for every message. The rationale is that given that Gas is a measure of on-chain resource consumption, it makes sense for it to be burned, as compared to be rewarded to miners. This way, fee manipulation from miners is avoided. The BaseFee is dynamic, adjusted automatically according to network congestion. This fact, makes the network resilient against spam attacks. Given that the network load increases during SPAM attacks, maintaining full blocks of SPAM messages for an extended period of time is impossible for an attacker due to the increasing BaseFee.

Finally, GasPremium is the priority fee included by senders to incentivize miners to pick the most profitable messages. In other words, if a message sender wants its message to be included more quickly, they can set a higher GasPremium.

#### ParametersState reliableTheory Audit comingEdit this sectionsection-systems.filecoin_vm.gas_fee.parameters

• GasUsed is a measure of the amount of resources (or units of gas) consumed, in order to execute a message. Each unit of gas is measured in attoFIL and therefore, GasUsed is a number that represents the units of energy consumed. GasUsed is independent of whether a message was executed correctly or failed.
• BaseFee is the set price per unit of gas (measured in attoFIL/gas unit) to be burned (sent to an unrecoverable address) for every message execution. The value of the BaseFee is dynamic and adjusts according to current network congestion parameters. For example, when the network exceeds 5B gas limit usage, the BaseFee increases and the opposite happens when gas limit usage falls below 5B. The BaseFee applied to each block should be included in the block itself. It should be possible to get the value of the current BaseFee from the head of the chain. The BaseFee applies per unit of GasUsed and therefore, the total amount of gas burned for a message is BaseFee * GasUsed. Note that the BaseFee is incurred for every message, but its value is the same for all messages in the same block.
• GasLimit is measured in units of gas and set by the message sender. It imposes a hard limit on the amount of gas (i.e., number of units of gas) that a message’s execution should be allowed to consume on chain. A message consumes gas for every fundamental operation it triggers, and a message that runs out of gas fails. When a message fails, every modification to the state that happened as a result of this message’s execution is reverted back to its previous state. Independently of whether a message execution was successful or not, the miner will receive a reward for the resources they consumed to execute the message (see GasPremium below).
• GasFeeCap is the maximum price that the message sender is willing to pay per unit of gas (measured in attoFIL/gas unit). Together with the GasLimit, the GasFeeCap is setting the maximum amount of FIL that a sender will pay for a message: a sender is guaranteed that a message will never cost them more than GasLimit * GasFeeCap attoFIL (not including any Premium that the message includes for its recipient).
• GasPremium is the price per unit of gas (measured in attoFIL/gas) that the message sender is willing to pay (on top of the BaseFee) to “tip” the miner that will include this message in a block. A message typically earns its miner GasLimit * GasPremium attoFIL, where effectively GasPremium = GasFeeCap - BaseFee. Note that GasPremium is applied on GasLimit, as opposed to GasUsed, in order to make message selection for miners more straightforward.
ComputeGasOverestimationBurn computes amount of gas to be refunded and amount of gas to be burned Result is (refund, burn)
func ComputeGasOverestimationBurn(gasUsed, gasLimit int64) (int64, int64) {
if gasUsed == 0 {
return 0, gasLimit
}

// over = gasLimit/gasUsed - 1 - 0.1
// over = min(over, 1)
// gasToBurn = (gasLimit - gasUsed) * over

// so to factor out division from over
// over*gasUsed = min(gasLimit - (11*gasUsed)/10, gasUsed)
// gasToBurn = ((gasLimit - gasUsed)*over*gasUsed) / gasUsed
over := gasLimit - (gasOveruseNum*gasUsed)/gasOveruseDenom
if over < 0 {
return gasLimit - gasUsed, 0
}

// if we want sharper scaling it goes here:
// over *= 2

if over > gasUsed {
over = gasUsed
}

// needs bigint, as it overflows in pathological case gasLimit > 2^32 gasUsed = gasLimit / 2
gasToBurn := big.NewInt(gasLimit - gasUsed)
gasToBurn = big.Mul(gasToBurn, big.NewInt(over))
gasToBurn = big.Div(gasToBurn, big.NewInt(gasUsed))

return gasLimit - gasUsed - gasToBurn.Int64(), gasToBurn.Int64()
}

func ComputeNextBaseFee(baseFee types.BigInt, gasLimitUsed int64, noOfBlocks int, epoch abi.ChainEpoch) types.BigInt {
// deta := gasLimitUsed/noOfBlocks - build.BlockGasTarget
// change := baseFee * deta / BlockGasTarget
// nextBaseFee = baseFee + change
// nextBaseFee = max(nextBaseFee, build.MinimumBaseFee)

var delta int64
delta = gasLimitUsed / int64(noOfBlocks)
delta -= build.BlockGasTarget
} else {
delta = build.PackingEfficiencyDenom * gasLimitUsed / (int64(noOfBlocks) * build.PackingEfficiencyNum)
delta -= build.BlockGasTarget
}

// cap change at 12.5% (BaseFeeMaxChangeDenom) by capping delta
if delta > build.BlockGasTarget {
delta = build.BlockGasTarget
}
if delta < -build.BlockGasTarget {
delta = -build.BlockGasTarget
}

change := big.Mul(baseFee, big.NewInt(delta))
change = big.Div(change, big.NewInt(build.BlockGasTarget))
change = big.Div(change, big.NewInt(build.BaseFeeMaxChangeDenom))

if big.Cmp(nextBaseFee, big.NewInt(build.MinimumBaseFee)) < 0 {
nextBaseFee = big.NewInt(build.MinimumBaseFee)
}
return nextBaseFee
}


#### Notes & ImplicationsState reliableTheory Audit comingEdit this sectionsection-systems.filecoin_vm.gas_fee.notes--implications

• The GasFeeCap should always be higher than the network’s BaseFee. If a message’s GasFeeCap is lower than the BaseFee, then the remainder comes from the miner (as a penalty). This penalty is applied to the miner because they have selected a message that pays less than the network BaseFee (i.e., does not cover the network costs). However, a miner might want to choose a message whose GasFeeCap is smaller than the BaseFee if the same sender has another message in the message pool whose GasFeeCap is much bigger than the BaseFee. Recall, that a miner should pick all the messages of a sender from the message pool, if more than one exists. The justification is that the increased fee of the second message will pay off the loss from the first.

• If BaseFee + GasPremium > GasFeeCap, then the miner might not earn the entire GasLimit * GasPremium as their reward.

• A message is hard-constrained to spending no more than GasFeeCap * GasLimit. From this amount, the network BaseFee is paid (burnt) first. After that, up to GasLimit * GasPremium will be given to the miner as a reward.

• A message that runs out of gas fails with an “out of gas” exit code. GasUsed * BaseFee will still be burned (in this case GasUsed = GasLimit), and the miner will still be rewarded GasLimit * GasPremium. This assumes that GasFeeCap > BaseFee + GasPremium.

• A low value for the GasFeeCap will likely cause the message to be stuck in the message pool, as it will not be attractive-enough in terms of profit for any miner to pick it and include it in a block. When this happens, there is a procedure to update the GasFeeCap so that the message becomes more attractive to miners. The sender can push a new message into the message pool (which, by default, will propagate to other miners' message pool) where: i) the identifier of the old and new messages is the same (e.g., same Nonce) and ii) the GasPremium is updated and increased by at least 25% of the previous value.

### System ActorsState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_vm.sysactors

There are eleven (11) builtin System Actors in total, but not all of them interact with the VM. Each actor is identified by a Code ID (or CID).

There are two system actors required for VM processing:

• the InitActor, which initializes new actors and records the network name, and
• the CronActor, a scheduler actor that runs critical functions at every epoch. There are another two actors that interact with the VM:
• the AccountActor responsible for user accounts (non-singleton), and
• the RewardActor for block reward and token vesting (singleton).

The remaining seven (7) builtin System Actors that do not interact directly with the VM are the following:

• StorageMarketActor: responsible for managing storage and retrieval deals [ Market Actor Repo]
• StorageMinerActor: actor responsible to deal with storage mining operations and collect proofs [ Storage Miner Actor Repo]
• MultisigActor (or Multi-Signature Wallet Actor): responsible for dealing with operations involving the Filecoin wallet [ Multisig Actor Repo]
• PaymentChannelActor: responsible for setting up and settling funds related to payment channels [ Paych Actor Repo]
• StoragePowerActor: responsible for keeping track of the storage power allocated at each storage miner [ Storage Power Actor]
• VerifiedRegistryActor: responsible for managing verified clients [ Verifreg Actor Repo]
• SystemActor: general system actor [ System Actor Repo]

#### CronActorState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_vm.sysactors.cronactor

Built in to the genesis state, the CronActor’s dispatch table invokes the StoragePowerActor and StorageMarketActor for them to maintain internal state and process deferred events. It could in principle invoke other actors after a network upgrade.

package cron

import (
"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/cbor"
cron0 "github.com/filecoin-project/specs-actors/actors/builtin/cron"
"github.com/ipfs/go-cid"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
)

// The cron actor is a built-in singleton that sends messages to other registered actors at the end of each epoch.
type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2:                         a.EpochTick,
}
}

func (a Actor) Code() cid.Cid {
return builtin.CronActorCodeID
}

func (a Actor) IsSingleton() bool {
return true
}

func (a Actor) State() cbor.Er {
return new(State)
}

var _ runtime.VMActor = Actor{}

//type ConstructorParams struct {
//	Entries []Entry
//}
type ConstructorParams = cron0.ConstructorParams

type EntryParam = cron0.Entry

func (a Actor) Constructor(rt runtime.Runtime, params *ConstructorParams) *abi.EmptyValue {
entries := make([]Entry, len(params.Entries))
for i, e := range params.Entries {
entries[i] = Entry(e) // Identical
}
rt.StateCreate(ConstructState(entries))
return nil
}

// Invoked by the system after all other messages in the epoch have been processed.
func (a Actor) EpochTick(rt runtime.Runtime, _ *abi.EmptyValue) *abi.EmptyValue {

var st State
for _, entry := range st.Entries {
// Any error and return value are ignored.
}

return nil
}


#### InitActorState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_vm.sysactors.initactor

The InitActor has the power to create new actors, e.g., those that enter the system. It maintains a table resolving a public key and temporary actor addresses to their canonical ID-addresses. Invalid CIDs should not get committed to the state tree.

Note that the canonical ID address does not persist in case of chain re-organization. The actor address or public key survives chain re-organization.

package init

import (
"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/cbor"
"github.com/filecoin-project/go-state-types/exitcode"
init0 "github.com/filecoin-project/specs-actors/actors/builtin/init"
cid "github.com/ipfs/go-cid"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
autil "github.com/filecoin-project/specs-actors/v2/actors/util"
)

// The init actor uniquely has the power to create new actors.
// It maintains a table resolving pubkey and temporary actor addresses to the canonical ID-addresses.
type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2:                         a.Exec,
}
}

func (a Actor) Code() cid.Cid {
return builtin.InitActorCodeID
}

func (a Actor) IsSingleton() bool {
return true
}

func (a Actor) State() cbor.Er { return new(State) }

var _ runtime.VMActor = Actor{}

//type ConstructorParams struct {
//	NetworkName string
//}
type ConstructorParams = init0.ConstructorParams

func (a Actor) Constructor(rt runtime.Runtime, params *ConstructorParams) *abi.EmptyValue {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to construct state")

st := ConstructState(emptyMap, params.NetworkName)
rt.StateCreate(st)
return nil
}

//type ExecParams struct {
//	CodeCID           cid.Cid checked:"true" // invalid CIDs won't get committed to the state tree
//	ConstructorParams []byte
//}
type ExecParams = init0.ExecParams

//type ExecReturn struct {
//}
type ExecReturn = init0.ExecReturn

func (a Actor) Exec(rt runtime.Runtime, params *ExecParams) *ExecReturn {
rt.ValidateImmediateCallerAcceptAny()
callerCodeCID, ok := rt.GetActorCodeCID(rt.Caller())
autil.AssertMsg(ok, "no code for actor at %s", rt.Caller())
if !canExec(callerCodeCID, params.CodeCID) {
rt.Abortf(exitcode.ErrForbidden, "caller type %v cannot exec actor type %v", callerCodeCID, params.CodeCID)
}

// This address exists for use by messages coming from outside the system, in order to
// stably address the newly created actor even if a chain re-org causes it to end up with
// a different ID.

// Allocate an ID for this actor.
// Store mapping of pubkey or actor address to actor ID
var st State
rt.StateTransaction(&st, func() {
var err error
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to allocate ID address")
})

// Create an empty actor.

// Invoke constructor.
builtin.RequireSuccess(rt, code, "constructor failed")

}

func canExec(callerCodeID cid.Cid, execCodeID cid.Cid) bool {
switch execCodeID {
case builtin.StorageMinerActorCodeID:
if callerCodeID == builtin.StoragePowerActorCodeID {
return true
}
return false
case builtin.PaymentChannelActorCodeID, builtin.MultisigActorCodeID:
return true
default:
return false
}
}


#### RewardActorState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_vm.sysactors.rewardactor

The RewardActor is where unminted Filecoin tokens are kept. The actor distributes rewards directly to miner actors, where they are locked for vesting. The reward value used for the current epoch is updated at the end of an epoch through a cron tick.

package reward

import (
"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/big"
"github.com/filecoin-project/go-state-types/cbor"
"github.com/filecoin-project/go-state-types/exitcode"
rtt "github.com/filecoin-project/go-state-types/rt"
reward0 "github.com/filecoin-project/specs-actors/actors/builtin/reward"
"github.com/ipfs/go-cid"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
. "github.com/filecoin-project/specs-actors/v2/actors/util"
"github.com/filecoin-project/specs-actors/v2/actors/util/smoothing"
)

// PenaltyMultiplier is the factor miner penaltys are scaled up by
const PenaltyMultiplier = 3

type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2:                         a.AwardBlockReward,
3:                         a.ThisEpochReward,
4:                         a.UpdateNetworkKPI,
}
}

func (a Actor) Code() cid.Cid {
return builtin.RewardActorCodeID
}

func (a Actor) IsSingleton() bool {
return true
}

func (a Actor) State() cbor.Er {
return new(State)
}

var _ runtime.VMActor = Actor{}

func (a Actor) Constructor(rt runtime.Runtime, currRealizedPower *abi.StoragePower) *abi.EmptyValue {

if currRealizedPower == nil {
rt.Abortf(exitcode.ErrIllegalArgument, "argument should not be nil")
return nil // linter does not understand abort exiting
}
st := ConstructState(*currRealizedPower)
rt.StateCreate(st)
return nil
}

//type AwardBlockRewardParams struct {
//	Penalty   abi.TokenAmount // penalty for including bad messages in a block, >= 0
//	GasReward abi.TokenAmount // gas reward from all gas fees in a block, >= 0
//	WinCount  int64           // number of reward units won, > 0
//}
type AwardBlockRewardParams = reward0.AwardBlockRewardParams

// Awards a reward to a block producer.
// This method is called only by the system actor, implicitly, as the last message in the evaluation of a block.
// The system actor thus computes the parameters and attached value.
//
// The reward includes two components:
// - the epoch block reward, computed and paid from the reward actor's balance,
// - the block gas reward, expected to be transferred to the reward actor with this invocation.
//
// The reward is reduced before the residual is credited to the block producer, by:
// - a penalty amount, provided as a parameter, which is burnt,
func (a Actor) AwardBlockReward(rt runtime.Runtime, params *AwardBlockRewardParams) *abi.EmptyValue {
priorBalance := rt.CurrentBalance()
if params.Penalty.LessThan(big.Zero()) {
rt.Abortf(exitcode.ErrIllegalArgument, "negative penalty %v", params.Penalty)
}
if params.GasReward.LessThan(big.Zero()) {
rt.Abortf(exitcode.ErrIllegalArgument, "negative gas reward %v", params.GasReward)
}
if priorBalance.LessThan(params.GasReward) {
rt.Abortf(exitcode.ErrIllegalState, "actor current balance %v insufficient to pay gas reward %v",
priorBalance, params.GasReward)
}
if params.WinCount <= 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid win count %d", params.WinCount)
}

if !ok {
rt.Abortf(exitcode.ErrNotFound, "failed to resolve given owner address")
}
// The miner penalty is scaled up by a factor of PenaltyMultiplier
penalty := big.Mul(big.NewInt(PenaltyMultiplier), params.Penalty)
totalReward := big.Zero()
var st State
rt.StateTransaction(&st, func() {
blockReward := big.Mul(st.ThisEpochReward, big.NewInt(params.WinCount))
currBalance := rt.CurrentBalance()
if totalReward.GreaterThan(currBalance) {
rt.Log(rtt.WARN, "reward actor balance %d below totalReward expected %d, paying out rest of balance", currBalance, totalReward)
totalReward = currBalance

blockReward = big.Sub(totalReward, params.GasReward)
// Since we have already asserted the balance is greater than gas reward blockReward is >= 0
AssertMsg(blockReward.GreaterThanEqual(big.Zero()), "programming error, block reward is %v below zero", blockReward)
}
})

AssertMsg(totalReward.LessThanEqual(priorBalance), "reward %v exceeds balance %v", totalReward, priorBalance)

// if this fails, we can assume the miner is responsible and avoid failing here.
rewardParams := builtin.ApplyRewardParams{
Reward:  totalReward,
Penalty: penalty,
}
if !code.IsSuccess() {
rt.Log(rtt.ERROR, "failed to send ApplyRewards call to the miner actor with funds: %v, code: %v", totalReward, code)
if !code.IsSuccess() {
rt.Log(rtt.ERROR, "failed to send unsent reward to the burnt funds actor, code: %v", code)
}
}

return nil
}

// Changed since v0:
// - removed ThisEpochReward (unsmoothed)
type ThisEpochRewardReturn struct {
ThisEpochRewardSmoothed smoothing.FilterEstimate
ThisEpochBaselinePower  abi.StoragePower
}

// The award value used for the current epoch, updated at the end of an epoch
// through cron tick.  In the case previous epochs were null blocks this
// is the reward value as calculated at the last non-null epoch.
func (a Actor) ThisEpochReward(rt runtime.Runtime, _ *abi.EmptyValue) *ThisEpochRewardReturn {
rt.ValidateImmediateCallerAcceptAny()

var st State
return &ThisEpochRewardReturn{
ThisEpochRewardSmoothed: st.ThisEpochRewardSmoothed,
ThisEpochBaselinePower:  st.ThisEpochBaselinePower,
}
}

// Called at the end of each epoch by the power actor (in turn by its cron hook).
// This is only invoked for non-empty tipsets, but catches up any number of null
// epochs to compute the next epoch reward.
func (a Actor) UpdateNetworkKPI(rt runtime.Runtime, currRealizedPower *abi.StoragePower) *abi.EmptyValue {
if currRealizedPower == nil {
rt.Abortf(exitcode.ErrIllegalArgument, "arugment should not be nil")
}

var st State
rt.StateTransaction(&st, func() {
prev := st.Epoch
// if there were null runs catch up the computation until
// st.Epoch == rt.CurrEpoch()
for st.Epoch < rt.CurrEpoch() {
// Update to next epoch to process null rounds
st.updateToNextEpoch(*currRealizedPower)
}

st.updateToNextEpochWithReward(*currRealizedPower)
// only update smoothed estimates after updating reward and epoch
})
return nil
}


#### AccountActorState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_vm.sysactors.accountactor

The AccountActor is responsible for user accounts. Account actors are not created by the InitActor, but their constructor is called by the system. Account actors are created by sending a message to a public-key style address. The address must be BLS or SECP, or otherwise there should be an exit error. The account actor is updating the state tree with the new actor address.

package account

import (
"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/cbor"
"github.com/filecoin-project/go-state-types/exitcode"
"github.com/ipfs/go-cid"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
)

type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
1: a.Constructor,
}
}

func (a Actor) Code() cid.Cid {
return builtin.AccountActorCodeID
}

func (a Actor) State() cbor.Er {
return new(State)
}

var _ runtime.VMActor = Actor{}

type State struct {
}

// Account actors are created implicitly by sending a message to a pubkey-style address.
// This constructor is not invoked by the InitActor, but by the system.
break // ok
default:
}
rt.StateCreate(&st)
return nil
}

// Fetches the pubkey-type address from this actor.
rt.ValidateImmediateCallerAcceptAny()
var st State
}


### VM Interpreter - Message Invocation (Outside VM)State wipTheory Audit wipEdit this sectionsection-systems.filecoin_vm.interpreter

The VM interpreter orchestrates the execution of messages from a tipset on that tipset’s parent state, producing a new state and a sequence of message receipts. The CIDs of this new state and of the receipt collection are included in blocks from the subsequent epoch, which must agree about those CIDs in order to form a new tipset.

Every state change is driven by the execution of a message. The messages from all the blocks in a tipset must be executed in order to produce a next state. All messages from the first block are executed before those of second and subsequent blocks in the tipset. For each block, BLS-aggregated messages are executed first, then SECP signed messages.

#### Implicit messagesState wipTheory Audit wipEdit this sectionsection-systems.filecoin_vm.interpreter.implicit-messages

In addition to the messages explicitly included in each block, a few state changes at each epoch are made by implicit messages. Implicit messages are not transmitted between nodes, but constructed by the interpreter at evaluation time.

For each block in a tipset, an implicit message:

• invokes the block producer’s miner actor to process the (already-validated) election PoSt submission, as the first message in the block;
• invokes the reward actor to pay the block reward to the miner’s owner account, as the final message in the block;

For each tipset, an implicit message:

• invokes the cron actor to process automated checks and payments, as the final message in the tipset.

All implicit messages are constructed with a From address being the distinguished system account actor. They specify a gas price of zero, but must be included in the computation. They must succeed (have an exit code of zero) in order for the new state to be computed. Receipts for implicit messages are not included in the receipt list; only explicit messages have an explicit receipt.

#### Gas paymentsState wipTheory Audit wipEdit this sectionsection-systems.filecoin_vm.interpreter.gas-payments

In most cases, the sender of a message pays the miner which produced the block including that message a gas fee for its execution.

The gas payments for each message execution are paid to the miner owner account immediately after that message is executed. There are no encumbrances to either the block reward or gas fees earned: both may be spent immediately.

#### Duplicate messagesState wipTheory Audit wipEdit this sectionsection-systems.filecoin_vm.interpreter.duplicate-messages

Since different miners produce blocks in the same epoch, multiple blocks in a single tipset may include the same message (identified by the same CID). When this happens, the message is processed only the first time it is encountered in the tipset’s canonical order. Subsequent instances of the message are ignored and do not result in any state mutation, produce a receipt, or pay gas to the block producer.

The sequence of executions for a tipset is thus summarised:

• pay reward for first block
• process election post for first block
• messages for first block (BLS before SECP)
• pay reward for second block
• process election post for second block
• messages for second block (BLS before SECP, skipping any already encountered)
• [... subsequent blocks ...]
• cron tick

#### Message validity and failureState wipTheory Audit wipEdit this sectionsection-systems.filecoin_vm.interpreter.message-validity-and-failure

Every message in a valid block can be processed and produce a receipt (note that block validity implies all messages are syntactically valid – see Message Syntax – and correctly signed). However, execution may or may not succeed, depending on the state to which the message is applied. If the execution of a message fails, the corresponding receipt will carry a non-zero exit code.

If a message fails due to a reason that can reasonably be attributed to the miner including a message that could never have succeeded in the parent state, or because the sender lacks funds to cover the maximum message cost, then the miner pays a penalty by burning the gas fee (rather than the sender paying fees to the block miner).

The only state changes resulting from a message failure are either:

• incrementing of the sending actor’s CallSeqNum, and payment of gas fees from the sender to the owner of the miner of the block including the message; or
• a penalty equivalent to the gas fee for the failed message, burnt by the miner (sender’s CallSeqNum unchanged).

A message execution will fail if, in the immediately preceding state:

• the From actor does not exist in the state (miner penalized),
• the From actor is not an account actor (miner penalized),
• the CallSeqNum of the message does not match the CallSeqNum of the From actor (miner penalized),
• the From actor does not have sufficient balance to cover the sum of the message Value plus the maximum gas cost, GasLimit * GasPrice (miner penalized),
• the To actor does not exist in state and the To address is not a pubkey-style address,
• the To actor exists (or is implicitly created as an account) but does not have a method corresponding to the non-zero MethodNum,
• deserialized Params is not an array of length matching the arity of the To actor’s MethodNum method,
• deserialized Params are not valid for the types specified by the To actor’s MethodNum method,
• the invoked method consumes more gas than the GasLimit allows,
• the invoked method exits with a non-zero code (via Runtime.Abort()), or
• any inner message sent by the receiver fails for any of the above reasons.

Note that if the To actor does not exist in state and the address is a valid H(pubkey) address, it will be created as an account actor.

## BlockchainState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain

The Filecoin Blockchain is a distributed virtual machine that achieves consensus, processes messages, accounts for storage, and maintains security in the Filecoin Protocol. It is the main interface linking various actors in the Filecoin system.

The Filecoin blockchain system includes:

• A Message Pool subsystem that nodes use to track and propagate messages that miners have declared they want to include in the blockchain.
• A Virtual Machine subsystem used to interpret and execute messages in order to update system state.
• A State Tree subsystem which manages the creation and maintenance of state trees (the system state) deterministically generated by the vm from a given subchain.
• A Chain Synchronisation (ChainSync) susbystem that tracks and propagates validated message blocks, maintaining sets of candidate chains on which the miner may mine and running syntactic validation on incoming blocks.
• A Storage Power Consensus subsystem which tracks storage state (i.e., Storage Subystem) for a given chain and helps the blockchain system choose subchains to extend and blocks to include in them.

The blockchain system also includes:

• A Chain Manager, which maintains a given chain’s state, providing facilities to other blockchain subsystems which will query state about the latest chain in order to run, and ensuring incoming blocks are semantically validated before inclusion into the chain.
• A Block Producer which is called in the event of a successful leader election in order to produce a new block that will extend the current heaviest chain before forwarding it to the syncer for propagation.

At a high-level, the Filecoin blockchain grows through successive rounds of leader election in which a number of miners are elected to generate a block, whose inclusion in the chain will earn them block rewards. Filecoin’s blockchain runs on storage power. That is, its consensus algorithm by which miners agree on which subchain to mine is predicated on the amount of storage backing that subchain. At a high-level, the Storage Power Consensus subsystem maintains a Power Table that tracks the amount of storage that storage miner actors have contributed to the network through Sector commitments and Proofs of Spacetime.

### BlocksState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct

The Block is the main unit of the Filecoin blockchain, as is also the case with most other blockchains. Block messages are directly linked with Tipsets, which are groups of Block messages as detailed later on in this section. In the following we discuss the main structure of a Block message and the process of validating Block messages in the Filecoin blockchain.

#### BlockState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.block

The Block is the main unit of the Filecoin blockchain.

The Block structure in the Filecoin blockchain is composed of: i) the Block Header, ii) the list of messages inside the block, and iii) the signed messages. This is represented inside the FullBlock abstraction. The messages indicate the required set of changes to apply in order to arrive at a deterministic state of the chain.

The Lotus implementation of the block has the following struct:

type FullBlock struct {
BlsMessages   []*Message
SecpkMessages []*SignedMessage
}


Note
A block is functionally the same as a block header in the Filecoin protocol. While a block header contains Merkle links to the full system state, messages, and message receipts, a block can be thought of as the full set of this information (not just the Merkle roots, but rather the full data of the state tree, message tree, receipts tree, etc.). Because a full block is large in size, the Filecoin blockchain consists of block headers rather than full blocks. We often use the terms block and block header interchangeably.

A BlockHeader is a canonical representation of a block. BlockHeaders are propagated between miner nodes. From the blockcheader message, a miner has all the required information to apply the associated FullBlock’s state and update the chain. In order to be able to do this, the minimum set of information items that need to be included in the BlockHeader are shown below and include among others: the miner’s address, the Ticket, the Proof of SpaceTime, the CID of the parents where this block evolved from in the IPLD DAG, as well as the messages' own CIDs.

The Lotus implementation of the block header has the following structs:

type BlockHeader struct {

Ticket *Ticket // 1

ElectionProof *ElectionProof // 2

BeaconEntries []BeaconEntry // 3

WinPoStProof []proof2.PoStProof // 4

Parents []cid.Cid // 5

ParentWeight BigInt // 6

Height abi.ChainEpoch // 7

ParentStateRoot cid.Cid // 8

ParentMessageReceipts cid.Cid // 8

Messages cid.Cid // 10

BLSAggregate *crypto.Signature // 11

Timestamp uint64 // 12

BlockSig *crypto.Signature // 13

ForkSignaling uint64 // 14

// ParentBaseFee is the base fee after executing parent tipset
ParentBaseFee abi.TokenAmount // 15

// internal
validated bool // true if the signature has been validated
}

type Ticket struct {
VRFProof []byte
}

type ElectionProof struct {
WinCount int64
VRFProof []byte
}

type BeaconEntry struct {
Round uint64
Data  []byte
}


The BlockHeader structure has to refer to the TicketWinner of the current round which ensures the correct winner is passed to ChainSync.

func IsTicketWinner(vrfTicket []byte, mypow BigInt, totpow BigInt) bool


The Message structure has to include the source (From) and destination (To) addresses, a Nonce and the GasPrice.

The Lotus implementation of the message has the following structure:

type Message struct {
Version uint64

Nonce uint64

Value abi.TokenAmount

GasLimit   int64
GasFeeCap  abi.TokenAmount

Method abi.MethodNum
Params []byte
}


The message is also validated before it is passed to the chain synchronization logic:

func (m *Message) ValidForBlockInclusion(minGas int64) error {
if m.Version != 0 {
return xerrors.New("'Version' unsupported")
}

return xerrors.New("'To' address cannot be empty")
}

return xerrors.New("'From' address cannot be empty")
}

if m.Value.Int == nil {
return xerrors.New("'Value' cannot be nil")
}

if m.Value.LessThan(big.Zero()) {
return xerrors.New("'Value' field cannot be negative")
}

if m.Value.GreaterThan(TotalFilecoinInt) {
return xerrors.New("'Value' field cannot be greater than total filecoin supply")
}

if m.GasFeeCap.Int == nil {
return xerrors.New("'GasFeeCap' cannot be nil")
}

if m.GasFeeCap.LessThan(big.Zero()) {
return xerrors.New("'GasFeeCap' field cannot be negative")
}

}

return xerrors.New("'GasPremium' field cannot be negative")
}

}

if m.GasLimit > build.BlockGasLimit {
return xerrors.New("'GasLimit' field cannot be greater than a block's gas limit")
}

// since prices might vary with time, this is technically semantic validation
if m.GasLimit < minGas {
return xerrors.Errorf("'GasLimit' field cannot be less than the cost of storing a message on chain %d < %d", m.GasLimit, minGas)
}

return nil
}

##### Block syntax validationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.block.block-syntax-validation

Syntax validation refers to validation that should be performed on a block and its messages without reference to outside information such as the parent state tree. This type of validation is sometimes called static validation.

An invalid block must not be transmitted or referenced as a parent.

A syntactically valid block header must decode into fields matching the definitions below, must be a valid CBOR PubSub BlockMsg message and must have:

• between 1 and 5*ec.ExpectedLeaders Parents CIDs if Epoch is greater than zero (else empty Parents),
• a non-negative ParentWeight,
• less than or equal to BlockMessageLimit number of messages,
• aggregate message CIDs, encapsulated in the MsgMeta structure, serialized to the Messages CID in the block header,
• a Miner address which is an ID-address. The Miner Address in the block header should be present and correspond to a public-key address in the current chain state.
• Block signature (BlockSig) that belongs to the public-key address retrieved for the Miner
• a non-negative Epoch,
• a positive Timestamp,
• a Ticket with non-empty VRFResult,
• ElectionPoStOutput containing:
• a Candidates array with between 1 and EC.ExpectedLeaders values (inclusive),
• a non-empty PoStRandomness field,
• a non-empty Proof field,
• a non-empty ForkSignal field.

A syntactically valid full block must have:

• all referenced messages syntactically valid,
• all referenced parent receipts syntactically valid,
• the sum of the serialized sizes of the block header and included messages is no greater than block.BlockMaxSize,
• the sum of the gas limit of all explicit messages is no greater than block.BlockGasLimit.

Note that validation of the block signature requires access to the miner worker address and public key from the parent tipset state, so signature validation forms part of semantic validation. Similarly, message signature validation requires lookup of the public key associated with each message’s From account actor in the block’s parent state.

##### Block semantic validationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.block.block-semantic-validation

Semantic validation refers to validation that requires reference to information outside the block header and messages themselves. Semantic validation relates to the parent tipset and state on which the block is built.

In order to proceed to semantic validation the FullBlock must be assembled from the received block header retrieving its Filecoin messages. Block message CIDs can be retrieved from the network and be decoded into valid CBOR Message/SignedMessage.

In the Lotus implementation the semantic validation of a block is carried out by the Syncer module:

ValidateBlock should match up with ‘Semantical Validation’ in validation.md in the spec
func (syncer *Syncer) ValidateBlock(ctx context.Context, b *types.FullBlock, useCache bool) (err error) {
defer func() {
// b.Cid() could panic for empty blocks that are used in tests.
if rerr := recover(); rerr != nil {
err = xerrors.Errorf("validate block panic: %w", rerr)
return
}
}()

if useCache {
isValidated, err := syncer.store.IsBlockValidated(ctx, b.Cid())
if err != nil {
return xerrors.Errorf("check block validation cache %s: %w", b.Cid(), err)
}

if isValidated {
return nil
}
}

validationStart := build.Clock.Now()
defer func() {
stats.Record(ctx, metrics.BlockValidationDurationMilliseconds.M(metrics.SinceInMilliseconds(validationStart)))
}()

ctx, span := trace.StartSpan(ctx, "validateBlock")
defer span.End()

if err := blockSanityChecks(b.Header); err != nil {
return xerrors.Errorf("incoming header failed basic sanity checks: %w", err)
}

if err != nil {
return xerrors.Errorf("load parent tipset failed (%s): %w", h.Parents, err)
}

lbts, lbst, err := stmgr.GetLookbackTipSetForRound(ctx, syncer.sm, baseTs, h.Height)
if err != nil {
return xerrors.Errorf("failed to get lookback tipset for block: %w", err)
}

prevBeacon, err := syncer.store.GetLatestBeaconEntry(baseTs)
if err != nil {
return xerrors.Errorf("failed to get latest beacon entry: %w", err)
}

// fast checks first
nulls := h.Height - (baseTs.Height() + 1)
if tgtTs := baseTs.MinTimestamp() + build.BlockDelaySecs*uint64(nulls+1); h.Timestamp != tgtTs {
return xerrors.Errorf("block has wrong timestamp: %d != %d", h.Timestamp, tgtTs)
}

now := uint64(build.Clock.Now().Unix())
if h.Timestamp > now+build.AllowableClockDriftSecs {
return xerrors.Errorf("block was from the future (now=%d, blk=%d): %w", now, h.Timestamp, ErrTemporal)
}
if h.Timestamp > now {
log.Warn("Got block from the future, but within threshold", h.Timestamp, build.Clock.Now().Unix())
}

msgsCheck := async.Err(func() error {
if err := syncer.checkBlockMessages(ctx, b, baseTs); err != nil {
return xerrors.Errorf("block had invalid messages: %w", err)
}
return nil
})

minerCheck := async.Err(func() error {
if err := syncer.minerIsValid(ctx, h.Miner, baseTs); err != nil {
return xerrors.Errorf("minerIsValid failed: %w", err)
}
return nil
})

baseFeeCheck := async.Err(func() error {
baseFee, err := syncer.store.ComputeBaseFee(ctx, baseTs)
if err != nil {
return xerrors.Errorf("computing base fee: %w", err)
}
if types.BigCmp(baseFee, b.Header.ParentBaseFee) != 0 {
return xerrors.Errorf("base fee doesn't match: %s (header) != %s (computed)",
}
return nil
})
pweight, err := syncer.store.Weight(ctx, baseTs)
if err != nil {
return xerrors.Errorf("getting parent weight: %w", err)
}

if types.BigCmp(pweight, b.Header.ParentWeight) != 0 {
return xerrors.Errorf("parrent weight different: %s (header) != %s (computed)",
}

stateRootCheck := async.Err(func() error {
stateroot, precp, err := syncer.sm.TipSetState(ctx, baseTs)
if err != nil {
return xerrors.Errorf("get tipsetstate(%d, %s) failed: %w", h.Height, h.Parents, err)
}

if stateroot != h.ParentStateRoot {
msgs, err := syncer.store.MessagesForTipset(baseTs)
if err != nil {
log.Error("failed to load messages for tipset during tipset state mismatch error: ", err)
} else {
log.Warn("Messages for tipset with mismatching state:")
for i, m := range msgs {
mm := m.VMMessage()
log.Warnf("Message[%d]: from=%s to=%s method=%d params=%x", i, mm.From, mm.To, mm.Method, mm.Params)
}
}

return xerrors.Errorf("parent state root did not match computed state (%s != %s)", stateroot, h.ParentStateRoot)
}

if precp != h.ParentMessageReceipts {
return xerrors.Errorf("parent receipts root did not match computed value (%s != %s)", precp, h.ParentMessageReceipts)
}

return nil
})

// Stuff that needs worker address
waddr, err := stmgr.GetMinerWorkerRaw(ctx, syncer.sm, lbst, h.Miner)
if err != nil {
return xerrors.Errorf("GetMinerWorkerRaw failed: %w", err)
}

winnerCheck := async.Err(func() error {
if h.ElectionProof.WinCount < 1 {
return xerrors.Errorf("block is not claiming to be a winner")
}

eligible, err := stmgr.MinerEligibleToMine(ctx, syncer.sm, h.Miner, baseTs, lbts)
if err != nil {
return xerrors.Errorf("determining if miner has min power failed: %w", err)
}

if !eligible {
return xerrors.New("block's miner is ineligible to mine")
}

rBeacon := *prevBeacon
if len(h.BeaconEntries) != 0 {
rBeacon = h.BeaconEntries[len(h.BeaconEntries)-1]
}
buf := new(bytes.Buffer)
if err := h.Miner.MarshalCBOR(buf); err != nil {
return xerrors.Errorf("failed to marshal miner address to cbor: %w", err)
}

vrfBase, err := store.DrawRandomness(rBeacon.Data, crypto.DomainSeparationTag_ElectionProofProduction, h.Height, buf.Bytes())
if err != nil {
return xerrors.Errorf("could not draw randomness: %w", err)
}

if err := VerifyElectionPoStVRF(ctx, waddr, vrfBase, h.ElectionProof.VRFProof); err != nil {
return xerrors.Errorf("validating block election proof failed: %w", err)
}

slashed, err := stmgr.GetMinerSlashed(ctx, syncer.sm, baseTs, h.Miner)
if err != nil {
return xerrors.Errorf("failed to check if block miner was slashed: %w", err)
}

if slashed {
return xerrors.Errorf("received block was from slashed or invalid miner")
}

mpow, tpow, _, err := stmgr.GetPowerRaw(ctx, syncer.sm, lbst, h.Miner)
if err != nil {
return xerrors.Errorf("failed getting power: %w", err)
}

if h.ElectionProof.WinCount != j {
return xerrors.Errorf("miner claims wrong number of wins: miner: %d, computed: %d", h.ElectionProof.WinCount, j)
}

return nil
})

blockSigCheck := async.Err(func() error {
if err := sigs.CheckBlockSignature(ctx, h, waddr); err != nil {
return xerrors.Errorf("check block signature failed: %w", err)
}
return nil
})

beaconValuesCheck := async.Err(func() error {
if os.Getenv("LOTUS_IGNORE_DRAND") == "_yes_" {
return nil
}

if err := beacon.ValidateBlockValues(syncer.beacon, h, baseTs.Height(), *prevBeacon); err != nil {
return xerrors.Errorf("failed to validate blocks random beacon values: %w", err)
}
return nil
})

tktsCheck := async.Err(func() error {
buf := new(bytes.Buffer)
if err := h.Miner.MarshalCBOR(buf); err != nil {
return xerrors.Errorf("failed to marshal miner address to cbor: %w", err)
}

buf.Write(baseTs.MinTicket().VRFProof)
}

beaconBase := *prevBeacon
if len(h.BeaconEntries) != 0 {
beaconBase = h.BeaconEntries[len(h.BeaconEntries)-1]
}

vrfBase, err := store.DrawRandomness(beaconBase.Data, crypto.DomainSeparationTag_TicketProduction, h.Height-build.TicketRandomnessLookback, buf.Bytes())
if err != nil {
return xerrors.Errorf("failed to compute vrf base for ticket: %w", err)
}

err = VerifyElectionPoStVRF(ctx, waddr, vrfBase, h.Ticket.VRFProof)
if err != nil {
return xerrors.Errorf("validating block tickets failed: %w", err)
}
return nil
})

wproofCheck := async.Err(func() error {
if err := syncer.VerifyWinningPoStProof(ctx, h, *prevBeacon, lbst, waddr); err != nil {
return xerrors.Errorf("invalid election post: %w", err)
}
return nil
})

await := []async.ErrorFuture{
minerCheck,
tktsCheck,
blockSigCheck,
beaconValuesCheck,
wproofCheck,
winnerCheck,
msgsCheck,
baseFeeCheck,
stateRootCheck,
}

var merr error
for _, fut := range await {
if err := fut.AwaitContext(ctx); err != nil {
merr = multierror.Append(merr, err)
}
}
if merr != nil {
mulErr := merr.(*multierror.Error)
mulErr.ErrorFormat = func(es []error) string {
if len(es) == 1 {
return fmt.Sprintf("1 error occurred:\n\t* %+v\n\n", es[0])
}

points := make([]string, len(es))
for i, err := range es {
points[i] = fmt.Sprintf("* %+v", err)
}

return fmt.Sprintf(
"%d errors occurred:\n\t%s\n\n",
len(es), strings.Join(points, "\n\t"))
}
return mulErr
}

if useCache {
if err := syncer.store.MarkBlockAsValidated(ctx, b.Cid()); err != nil {
return xerrors.Errorf("caching block validation %s: %w", b.Cid(), err)
}
}

return nil
}


Messages are retrieved through the Syncer. There are the following two steps followed by the Syncer: 1- Assemble a FullTipSet populated with the single block received earlier. The Block’s ParentWeight is greater than the one from the (first block of the) heaviest tipset. 2- Retrieve all tipsets from the received Block down to our chain. Validation is expanded to every block inside these tipsets. The validation should ensure that: - Beacon entires are ordered by their round number. - The Tipset Parents CIDs match the fetched parent tipset through BlockSync.

A semantically valid block must meet all of the following requirements.

Parents-Related

• Parents listed in lexicographic order of their header’s Ticket.
• ParentStateRoot CID of the block matches the state CID computed from the parent Tipset.
• ParentState matches the state tree produced by executing the parent tipset’s messages (as defined by the VM interpreter) against that tipset’s parent state.
• ParentMessageReceipts identifying the receipt list produced by parent tipset execution, with one receipt for each unique message from the parent tipset. In other words, the Block’s ParentMessageReceipts CID matches the receipts CID computed from the parent tipset.
• ParentWeight matches the weight of the chain up to and including the parent tipset.

Time-Related

• Epoch is greater than that of its Parents, and
• not in the future according to the node’s local clock reading of the current epoch,
• blocks with future epochs should not be rejected, but should not be evaluated (validated or included in a tipset) until the appropriate epoch
• not farther in the past than the soft finality as defined by SPC Finality,
• this rule only applies when receiving new gossip blocks (i.e. from the current chain head), not when syncing to the chain for the first time.
• The Timestamp included is in seconds that:
• must not be bigger than current time plus ΑllowableClockDriftSecs
• must not be smaller than previous block’s Timestamp plus BlockDelay (including null blocks)
• is of the precise value implied by the genesis block’s timestamp, the network’s Βlock time and the Βlock’s Epoch.

Miner-Related

• The Miner is active in the storage power table in the parent tipset state. The Miner’s address is registered in the Claims HAMT of the Power Actor
• The TipSetState should be included for each tipset being validated.
• Every Block in the tipset should belong to different a miner.
• The Actor associated with the message’s From address exists, is an account actor and its Nonce matches the message Nonce.
• Valid proofs that the Miner proved access to sealed versions of the sectors it was challenged for are included. In order to achieve that:
• draw randomness for current epoch with WinningPoSt domain separation tag.
• get list of sectors challanged in this epoch for this miner, based on the randomness drawn.
• Miner is not slashed in StoragePowerActor.

Beacon- & Ticket-Related

• Valid BeaconEntries should be included:
• Check that every one of the BeaconEntries is a signature of a message: previousSignature || round signed using DRAND’s public key.
• All entries between MaxBeaconRoundForEpoch down to prevEntry (from previous tipset) should be included.
• A Ticket derived from the minimum ticket from the parent tipset’s block headers,
• Ticket.VRFResult validly signed by the Miner actor’s worker account public key,
• ElectionProof Ticket is computed correctly by checking BLS signature using miner’s key. The ElectionProof ticket should be a winning ticket.

Message- & Signature-Related

• secp256k1 messages are correctly signed by their sending actor’s (From) worker account key,
• A BLSAggregate signature is included that signs the array of CIDs of all the BLS messages referenced by the block with their sending actor’s key.
• A valid Signature over the block header’s fields from the block’s Miner actor’s worker account public key is included.
• For each message in ValidForBlockInclusion() the following hold:
• Message fields Version, To, From, Value, GasPrice, and GasLimit are correctly defined.
• Message GasLimit is under the message minimum gas cost (derived from chain height and message length).
• For each message in ApplyMessage (that is before a message is executed), the following hold:
• Basic gas and value checks in checkMessage():
• The Message GasLimit is bigger than zero.
• The Message GasPrice and Value are set.
• The Message’s storage gas cost is under the message’s GasLimit.
• The Message’s Nonce matches the nonce in the Actor retrieved from the message’s From address.
• The Message’s maximum gas cost (derived from its GasLimit, GasPrice, and Value) is under the balance of the Actor retrieved from message’s From address.
• The Message’s transfer Value is under the balance of the Actor retrieved from message’s From address.

There is no semantic validation of the messages included in a block beyond validation of their signatures. If all messages included in a block are syntactically valid then they may be executed and produce a receipt.

A chain sync system may perform syntactic and semantic validation in stages in order to minimize unnecessary resource expenditure.

If all of the above tests are successful, the block is marked as validated. Ultimately, an invalid block must not be propagated further or validated as a parent node.

#### TipsetState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.tipset

Expected Consensus probabilistically elects multiple leaders in each epoch meaning a Filecoin chain may contain zero or multiple blocks at each epoch (one per elected miner). Blocks from the same epoch are assembled into tipsets. The VM Interpreter modifies the Filecoin state tree by executing all messages in a tipset (after de-duplication of identical messages included in more than one block).

Each block references a parent tipset and validates that tipset’s state, while proposing messages to be included for the current epoch. The state to which a new block’s messages apply cannot be known until that block is incorporated into a tipset. It is thus not meaningful to execute the messages from a single block in isolation: a new state tree is only known once all messages in that block’s tipset are executed.

A valid tipset contains a non-empty collection of blocks that have distinct miners and all specify identical:

• Epoch
• Parents
• ParentWeight
• StateRoot
• ReceiptsRoot

The blocks in a tipset are canonically ordered by the lexicographic ordering of the bytes in each block’s ticket, breaking ties with the bytes of the CID of the block itself.

Due to network propagation delay, it is possible for a miner in epoch N+1 to omit valid blocks mined at epoch N from their parent tipset. This does not make the newly generated block invalid, it does however reduce its weight and chances of being part of the canonical chain in the protocol as defined by EC’s Chain Selection function.

Block producers are expected to coordinate how they select messages for inclusion in blocks in order to avoid duplicates and thus maximize their expected earnings from message fees (see Message Pool).

The main Tipset structure in the Lotus implementation includes the following:

type TipSet struct {
cids   []cid.Cid
height abi.ChainEpoch
}


Semantic validation of a Tipset includes the following checks.

Checks:

• A tipset is composed of at least one block. (Because of our variable number of blocks per tipset, determined by randomness, we do not impose an upper limit.)
• All blocks have the same height.
• All blocks have the same parents (same number of them and matching CIDs).
func NewTipSet(blks []*BlockHeader) (*TipSet, error) {
if len(blks) == 0 {
return nil, xerrors.Errorf("NewTipSet called with zero length array of blocks")
}

sort.Slice(blks, tipsetSortFunc(blks))

var ts TipSet
ts.cids = []cid.Cid{blks[0].Cid()}
ts.blks = blks
for _, b := range blks[1:] {
if b.Height != blks[0].Height {
return nil, fmt.Errorf("cannot create tipset with mismatching heights")
}

if len(blks[0].Parents) != len(b.Parents) {
return nil, fmt.Errorf("cannot create tipset with mismatching number of parents")
}

for i, cid := range b.Parents {
if cid != blks[0].Parents[i] {
return nil, fmt.Errorf("cannot create tipset with mismatching parents")
}
}

ts.cids = append(ts.cids, b.Cid())

}
ts.height = blks[0].Height

return &ts, nil
}


#### Chain ManagerState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.chain_manager

The Chain Manager is a central component in the blockchain system. It tracks and updates competing subchains received by a given node in order to select the appropriate blockchain head: the latest block of the heaviest subchain it is aware of in the system.

In so doing, the chain manager is the central subsystem that handles bookkeeping for numerous other systems in a Filecoin node and exposes convenience methods for use by those systems, enabling systems to sample randomness from the chain for instance, or to see which block has been finalized most recently.

##### Chain ExtensionState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.chain_manager.chain-extension
###### Incoming block receptionState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.chain_manager.incoming-block-reception

For every incoming block, even if the incoming block is not added to the current heaviest tipset, the chain manager should add it to the appropriate subchain it is tracking, or keep track of it independently until either:

• it is able to add to the current heaviest subchain, through the reception of another block in that subchain, or
• it is able to discard it, as the block was mined before finality.

It is important to note that ahead of finality, a given subchain may be abandoned for another, heavier one mined in a given round. In order to rapidly adapt to this, the chain manager must maintain and update all subchains being considered up to finality.

Chain selection is a crucial component of how the Filecoin blockchain works. In brief, every chain has an associated weight accounting for the number of blocks mined on it and so the power (storage) they track. The full details of how selection works are provided in the Chain Selection section.

Notes/Recommendations:

1. In order to make certain validation checks simpler, blocks should be indexed by height and by parent set. That way sets of blocks with a given height and common parents may be quickly queried.
2. It may also be useful to compute and cache the resultant aggregate state of blocks in these sets, this saves extra state computation when checking which state root to start a block at when it has multiple parents.
3. It is recommended that blocks are kept in the local datastore regardless of whether they are understood as the best tip at this point - this is to avoid having to refetch the same blocks in the future.
###### ChainTipsManagerState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.struct.chain_manager.chaintipsmanager

The Chain Tips Manager is a subcomponent of Filecoin consensus that is responsible for tracking all live tips of the Filecoin blockchain, and tracking what the current ‘best’ tipset is.

// Returns the ticket that is at round 'r' in the chain behind 'head'
func TicketFromRound(head Tipset, r Round) {}

// Returns the tipset that contains round r (Note: multiple rounds' worth of tickets may exist within a single block due to losing tickets being added to the eventually successfully generated block)
func TipsetFromRound(head Tipset, r Round) {}

// GetBestTipset returns the best known tipset. If the 'best' tipset hasn't changed, then this
// will return the previous best tipset.
func GetBestTipset()

// Adds the losing ticket to the chaintips manager so that blocks can be mined on top of it


#### Block ProducerState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.struct.block_producer

##### Mining BlocksState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.struct.block_producer.mining-blocks

A miner registered with the storage power actor may begin generating and checking election tickets if it has proven storage that meets the Minimum Miner Size threshold requirement.

In order to do so, the miner must be running chain validation, and be keeping track of the most recent blocks received. A miner’s new block will be based on parents from the previous epoch.

###### Block CreationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.struct.block_producer.block-creation

Producing a block for epoch H requires waiting for the beacon entry for that epoch and using it to run GenerateElectionProof. If WinCount ≥ 1 (i.e., when the miner is elected), the same beacon entry is used to run WinningPoSt. Armed by the ElectionProof ticket (output of GenerateElectionProof) and the WinningPoSt proof, the miner can produce an new block.

See VM Interpreter for details of parent tipset evaluation, and Block for constraints on valid block header values.

To create a block, the eligible miner must compute a few fields:

• Parents - the CIDs of the parent tipset’s blocks.
• ParentWeight - the parent chain’s weight (see Chain Selection).
• ParentState - the CID of the state root from the parent tipset state evaluation (see the VM Interpreter).
• ParentMessageReceipts - the CID of the root of an AMT containing receipts produced while computing ParentState.
• Epoch - the block’s epoch, derived from the Parents epoch and the number of epochs it took to generate this block.
• Timestamp - a Unix timestamp, in seconds, generated at block creation.
• BeaconEntries - a set of drand entries generated since the last block (see Beacon Entries).
• Ticket - a new ticket generated from that in the prior epoch (see Ticket Generation).
• Miner - the block producer’s miner actor address.
• Messages - The CID of a TxMeta object containing message proposed for inclusion in the new block:
• Select a set of messages from the mempool to include in the block, satisfying block size and gas limits
• Separate the messages into BLS signed messages and secpk signed messages
• TxMeta.BLSMessages: The CID of the root of an AMT comprising the bare UnsignedMessages
• TxMeta.SECPMessages: the CID of the root of an AMT comprising the SignedMessages
• BeaconEntries: a list of beacon entries to derive randomness from
• BLSAggregate - The aggregated signature of all messages in the block that used BLS signing.
• Signature - A signature with the miner’s worker account private key (must also match the ticket signature) over the block header’s serialized representation (with empty signature).
• ForkSignaling - A uint64 flag used as part of signaling forks. Should be set to 0 by default.

Note that the messages to be included in a block need not be evaluated in order to produce a valid block. A miner may wish to speculatively evaluate the messages anyway in order to optimize for including messages which will succeed in execution and pay the most gas.

The block reward is not evaluated when producing a block. It is paid when the block is included in a tipset in the following epoch.

The block’s signature ensures integrity of the block after propagation, since unlike many PoW blockchains, a winning ticket is found independently of block generation.

###### Block BroadcastState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.struct.block_producer.block-broadcast

An eligible miner propagates the completed block to the network using the GossipSub /fil/blocks topic and, assuming everything was done correctly, the network will accept it and other miners will mine on top of it, earning the miner a block reward.

Miners should output their valid block as soon as it is produced, otherwise they risk other miners receiving the block after the EPOCH_CUTOFF and not including them in the current epoch.

##### Block RewardsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.struct.block_producer.block-rewards

Block rewards are handled by the Reward Actor. Further details on the Block Reward are discussed in the Filecoin Token section and details about the Block Reward Collateral are discussed in the Miner Collaterals section.

### Message PoolState stableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.message_pool

The Message Pool, or mpool or mempool is a pool of messages in the Filecoin protocol. It acts as the interface between Filecoin nodes and the peer-to-peer network of other nodes used for off-chain message propagation. The message pool is used by nodes to maintain a set of messages they want to transmit to the Filecoin VM and add to the chain (i.e., add for “on-chain” execution).

In order for a message to end up in the blockchain it first has to be in the message pool. In reality, at least in the Lotus implementation of Filecoin, there is no central pool of messages stored somewhere. Instead, the message pool is an abstraction and is realised as a list of messages kept by every node in the network. Therefore, when a node puts a new message in the message pool, this message is propagated to the rest of the network using libp2p’s pubsub protocol, GossipSub. Nodes need to subscribe to the corresponding pubsub topic in order to receive messages.

Message propagation using GossipSub does not happen immediately and therefore, there is some lag before message pools at different nodes can be in sync. In practice, and given continuous streams of messages being added to the message pool and the delay to propagate messages, the message pool is never synchronised across all nodes in the network. This is not a deficiency of the system, as the message pool does not need to be synchronized across the network.

The message pool should have a maximum size defined to avoid DoS attacks, where nodes are spammed and run out of memory. The recommended size for the message pool is 5000 messages.

#### Message PropagationState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.message_pool.message_syncer

The message pool has to interface with the libp2p pubsub GossipSub protocol. This is because messages are propagated over GossipSub the corresponding /fil/msgs/ topic. Every Message is announced in the corresponding /fil/msgs/ topic by any node participating in the network.

There are two main pubsub topics related to messages and blocks: i) the /fil/msgs/ topic that carries messages and, ii) the /fil/blocks/ topic that carries blocks. The /fil/msgs/ topic is linked to the mpool. The process is as follows:

1. When a client wants to send a message in the Filecoin network, they publish the message to the /fil/msgs/ topic.
2. The message propagates to all other nodes in the network using GossipSub and eventually ends up in the mpool of all miners.
3. Depending on cryptoeconomic rules, some miner will eventually pick the message from the mpool (together with other messages) and include it in a block.
4. The miner publishes the newly-mined block in the /fil/blocks/ pubsub topic and the block propagates to all nodes in the network (including the nodes that published the messages included in this block).

Nodes must check that incoming messages are valid, that is, that they have a valid signature. If the message is not valid it should be dropped and must not be forwarded.

The updated, hardened version of the GossipSub protocol includes a number of attack mitigation strategies. For instance, when a node receives an invalid message it assigns a negative score to the sender peer. Peer scores are not shared with other nodes, but are rather kept locally by every peer for all other peers it is interacting with. If a peer’s score drops below a threshold it is excluded from the scoring peer’s mesh. We discuss more details on these settings in the GossipSub section. The full details can be found in the GossipSub Specification.

NOTES:

• Fund Checking: It is important to note that the mpool logic is not checking whether there are enough funds in the account of the message issuer. This is checked by the miner before including a message in a block.
• Message Sorting: Messages are sorted in the mpool of miners as they arrive according to cryptoeconomic rules followed by the miner and in order for the miner to compose the next block.

#### Message StorageState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.message_pool.message_storage

As mentioned earlier, there is no central pool where messages are included. Instead, every node must have allocated memory for incoming messages.

### ChainSyncState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync

Blockchain synchronization (“sync”) is a key part of a blockchain system. It handles retrieval and propagation of blocks and messages, and thus is in charge of distributed state replication. As such, this process is security critical – problems with state replication can have severe consequences to the operation of a blockchain.

When a node first joins the network it discovers peers (through the peer discovery discussed above) and joins the /fil/blocks and /fil/msgs GossipSub topics. It listens to new blocks being propagated by other nodes. It picks one block as the BestTargetHead and starts syncing the blockchain up to this height from the TrustedCheckpoint, which by default is the GenesisBlock or GenesisCheckpoint. In order to pick the BestTargetHead the peer is comparing a combination of height and weight - the higher these values the higher the chances of the block being on the main chain. If there are two blocks on the same height, the peer should choose the one with the higher weight. Once the peer chooses the BestTargetHead it uses the BlockSync protocol to fetch the blocks and get to the current height. From that point on it is in CHAIN_FOLLOW mode, where it uses GossipSub to receive new blocks, or Bitswap if it hears about a block that it has not received through GossipSub.

#### ChainSync OverviewState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.chainsync-overview

ChainSync is the protocol Filecoin uses to synchronize its blockchain. It is specific to Filecoin’s choices in state representation and consensus rules, but is general enough that it can serve other blockchains. ChainSync is a group of smaller protocols, which handle different parts of the sync process.

Chain synchronisation is generally needed in the following cases:

1. when a node first joins the network and needs to get to the current state before validating or extending the chain.
2. when a node has fell out of sync, e.g., due to a brief disconnection.
3. during normal operation in order to keep up with the latest messages and blocks.

There are three main protocols used to achieve synchronisation for these three cases.

• GossipSub is the libp2p pubsub protocol used to propagate messages and blocks. It is mainly used in the third process above when a node needs to stay in sync with new blocks being produced and propagated.
• BlockSync is used to synchronise specific parts of the chain, that is from and to a specific height.
• hello protocol, which is used when two peers first “meet” (i.e., first time they connect to each other). According to the protocol, they exchange their chain heads.

In addition, Bitswap is used to request and receive blocks, when a node is synchonized (“caught up”), but GossipSub has failed to deliver some blocks to a node. Finally, GraphSync can be used to fetch parts of the blockchain as a more efficient version of Bitswap.

Filecoin nodes are libp2p nodes, and therefore may run a variety of other protocols. As with anything else in Filecoin, nodes MAY opt to use additional protocols to achieve the results. That said, nodes MUST implement the version of ChainSync as described in this spec in order to be considered implementations of Filecoin.

#### Terms and ConceptsState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.terms-and-concepts

• LastCheckpoint the last hard social-consensus oriented checkpoint that ChainSync is aware of. This consensus checkpoint defines the minimum finality, and a minimum of history to build on. ChainSync takes LastCheckpoint on faith, and builds on it, never switching away from its history.
• TargetHeads a list of BlockCIDs that represent blocks at the fringe of block production. These are the newest and best blocks ChainSync knows about. They are “target” heads because ChainSync will try to sync to them. This list is sorted by “likelihood of being the best chain”. At this point this is simply realized through ChainWeight.
• BestTargetHead the single best chain head BlockCID to try to sync to. This is the first element of TargetHeads

#### ChainSync State MachineState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.chainsync-state-machine

At a high level, ChainSync does the following:

• Part 1: Verify internal state (INIT state below)
• SHOULD verify data structures and validate local chain
• Resource expensive verification MAY be skipped at nodes' own risk
• Part 2: Bootstrap to the network (BOOTSTRAP)
• Step 1. Bootstrap to the network, and acquire a “secure enough” set of peers (more details below)
• Step 2. Bootstrap to the GossipSub channels
• Part 3: Synchronize trusted checkpoint state (SYNC_CHECKPOINT)
• Step 1. Start with a TrustedCheckpoint (defaults to GenesisCheckpoint). The TrustedCheckpoint SHOULD NOT be verified in software, it SHOULD be verified by operators.
• Step 2. Get the block it points to, and that block’s parents
• Step 3. Fetch the StateTree
• Part 4: Catch up to the chain (CHAIN_CATCHUP)
• Step 1. Maintain a set of TargetHeads (BlockCIDs), and select the BestTargetHead from it
• Step 2. Synchronize to the latest heads observed, validating blocks towards them (requesting intermediate points)
• Step 3. As validation progresses, TargetHeads and BestTargetHead will likely change, as new blocks at the production fringe will arrive, and some target heads or paths to them may fail to validate.
• Step 4. Finish when node has “caught up” with BestTargetHead (retrieved all the state, linked to local chain, validated all the blocks, etc).
• Part 5: Stay in sync, and participate in block propagation (CHAIN_FOLLOW)
• Step 1. If security conditions change, go back to Part 4 (CHAIN_CATCHUP)
• Step 2. Receive, validate, and propagate received Blocks
• Step 3. Now with greater certainty of having the best chain, finalize Tipsets, and advance chain state.

ChainSync uses the following conceptual state machine. Since this is a conceptual state machine, implementations MAY deviate from implementing precisely these states, or dividing them strictly. Implementations MAY blur the lines between the states. If so, implementations MUST ensure security of the altered protocol.

#### Peer DiscoveryState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.peer-discovery

Peer discovery is a critical part of the overall architecture. Taking this wrong can have severe consequences for the operation of the protocol. The set of peers a new node initially connects to when joining the network may completely dominate the node’s awareness of other peers, and therefore the view of the state of the network that the node has.

Peer discovery can be driven by arbitrary external means and is pushed outside the core functionality of the protocols involved in ChainSync (i.e., GossipSub, Bitswap, BlockSync). This allows for orthogonal, application-driven development and no external dependencies for the protocol implementation. Nonetheless, the GossipSub protocol supports: i) Peer Exchange, and ii) Explicit Peering Agreements.

##### Peer ExchangeState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.peer-exchange

Peer Exchange allows applications to bootstrap from a known set of peers without an external peer discovery mechanism. This process can be realized either through bootstrap nodes or other normal peers. Bootstrap nodes must be maintained by system operators and must be configured correctly. They have to be stable and operate independently of protocol constructions, such as the GossipSub mesh construction, that is, bootstrap nodes do not maintain connections to the mesh.

For more details on Peer Exchange please refer to the GossipSub specification.

##### Explicit Peering AgreementsState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.explicit-peering-agreements

With explicit peering agreements, the operators must specify a list of peers which nodes should connect to when joining. The protocol must have options available for these to be specified. For every explicit peer, the router must establish and maintain a bidirectional (reciprocal) connection.

#### Progressive Block ValidationState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_blockchain.chainsync.progressive-block-validation

• Blocks may be validated in progressive stages, in order to minimize resource expenditure.

• Validation computation is considerable, and a serious DOS attack vector.

• Secure implementations must carefully schedule validation and minimize the work done by pruning blocks without validating them fully.

• ChainSync SHOULD keep a cache of unvalidated blocks (ideally sorted by likelihood of belonging to the chain), and delete unvalidated blocks when they are passed by FinalityTipset, or when ChainSync is under significant resource load.

• These stages can be used partially across many blocks in a candidate chain, in order to prune out clearly bad blocks long before actually doing the expensive validation work.

• Progressive Stages of Block Validation

• BV0 - Syntax: Serialization, typing, value ranges.
• BV1 - Plausible Consensus: Plausible miner, weight, and epoch values (e.g from chain state at b.ChainEpoch - consensus.LookbackParameter).
• BV2 - Block Signature
• BV3 - Beacon entries: Valid random beacon entries have been inserted in the block (see beacon entry validation).
• BV4 - ElectionProof: A valid election proof was generated.
• BV5 - WinningPoSt: Correct PoSt generated.
• BV6 - Chain ancestry and finality: Verify block links back to trusted chain, not prior to finality.
• BV7 - Message Signatures:
• BV8 - State tree: Parent tipset message execution produces the claimed state tree root and receipts.

### Storage Power ConsensusState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus

The Storage Power Consensus (SPC) subsystem is the main interface which enables Filecoin nodes to agree on the state of the system. Storage Power Consensus accounts for individual storage miners' effective power over consensus in given chains in its Power Table. It also runs Expected Consensus (the underlying consensus algorithm in use by Filecoin), enabling storage miners to run leader election and generate new blocks updating the state of the Filecoin system.

Succinctly, the SPC subsystem offers the following services:

#### Distinguishing between storage miners and block minersState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.distinguishing-between-storage-miners-and-block-miners

There are two ways to earn Filecoin tokens in the Filecoin network:

• By participating in the Storage Market as a storage provider and being paid by clients for file storage deals.
• By mining new blocks, extending the blockchain, securing the Filecoin consensus mechanism, and running smart contracts to perform state updates as a Storage Miner.

There are two types of “miners” (storage and block miners) to be distinguished. Leader Election in Filecoin is predicated on a miner’s storage power. Thus, while all block miners will be storage miners, the reverse is not necessarily true.

However, given Filecoin’s “useful Proof-of-Work” is achieved through file storage ( PoRep and PoSt), there is little overhead cost for storage miners to participate in leader election. Such a Storage Miner Actor need only register with the Storage Power Actor in order to participate in Expected Consensus and mine blocks.

#### On PowerState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.on-power

Quality-adjusted power is assigned to every sector as a static function of its Sector Quality which includes: i) the Sector Spacetime, which is the product of the sector size and the promised storage duration, ii) the Deal Weight that converts spacetime occupied by deals into consensus power, iii) the Deal Quality Multiplier that depends on the type of deal done over the sector (i.e., CC, Regular Deal or Verified Client Deal), and finally, iv) the Sector Quality Multiplier, which is an average of deal quality multipliers weighted by the amount of spacetime each type of deal occupies in the sector.

The Sector Quality is a measure that maps size, duration and the type of active deals in a sector during its lifetime to its impact on power and reward distribution.

The quality of a sector depends on the deals made over the data inside the sector. There are generally three types of deals: the Committed Capacity (CC), where there is effectively no deal and the miner is storing arbitrary data inside the sector, the Regular Deals, where a miner and a client agree on a price in the market and the Verified Client deals, which give more power to the sector. We refer the reader to the Sector and Sector Quality sections for details on Sector Types and Sector Quality, the Verified Clients section for more details on what a verified client is, and the CryptoEconomics section for specific parameter values on the Deal Weights and Quality Multipliers.

Quality-Adjusted Power is the number of votes a miner has in the Secret Leader Election and has been defined to increase linearly with the useful storage that a miner has committed to the network.

More precisely, we have the following definitions:

• Raw-byte power: the size of a sector in bytes.
• Quality-adjusted power: the consensus power of stored data on the network, equal to Raw-byte power multiplied by the Sector Quality Multiplier.

#### Beacon EntriesState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.beacon-entries

The Filecoin protocol uses randomness produced by a drand beacon to seed unbiasable randomness seeds for use in the chain (see randomness).

In turn these random seeds are used by:

• The sector_sealer as SealSeeds to bind sector commitments to a given subchain.
• The post_generator as PoStChallenges to prove sectors remain committed as of a given block.
• The Storage Power subsystem as randomness in Secret Leader Election to determine how often a miner is chosen to mine a new block.

This randomness may be drawn from various Filecoin chain epochs by the respective protocols that use them according to their security requirements.

It is important to note that a given Filecoin network and a given drand network need not have the same round time, i.e. blocks may be generated faster or slower by Filecoin than randomness is generated by drand. For instance, if the drand beacon is producing randomness twice as fast as Filecoin produces blocks, we might expect two random values to be produced in a Filecoin epoch, conversely if the Filecoin network is twice as fast as drand, we might expect a random value every other Filecoin epoch. Accordingly, depending on both networks' configurations, certain Filecoin blocks could contain multiple or no drand entries. Furthermore, it must be that any call to the drand network for a new randomness entry during an outage should be blocking, as noted with the drand.Public() calls below. In all cases, Filecoin blocks must include all drand beacon outputs generated since the last epoch in the BeaconEntries field of the block header. Any use of randomness from a given Filecoin epoch should use the last valid drand entry included in a Filecoin block. This is shown below.

##### Get drand randomness for VMState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.get-drand-randomness-for-vm

For operations such as PoRep creation, proof validations, or anything that requires randomness for the Filecoin VM, there should be a method that extracts the drand entry from the chain correctly. Note that the round may span multiple filecoin epochs if drand is slower; the lowest epoch number block will contain the requested beacon entry. Similarly, if there has been null rounds where the beacon should have been inserted, we need to iterate on the chain to find where the entry is inserted. Specifically, the next non-null block must contain the drand entry requested by definition.

##### Fetch randomness from drand networkState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.fetch-randomness-from-drand-network

When mining, a miner can fetch entries from the drand network to include them in the new block.

DrandBeacon connects Lotus with a drand network in order to provide randomness to the system in a way that’s aligned with Filecoin rounds/epochs.

We connect to drand peers via their public HTTP endpoints. The peers are enumerated in the drandServers variable.

The root trust for the Drand chain is configured from build.DrandChain.

type DrandBeacon struct {
client dclient.Client

pubkey kyber.Point

// seconds
interval time.Duration

drandGenTime uint64
filGenTime   uint64
filRoundTime uint64

cacheLk    sync.Mutex
localCache map[uint64]types.BeaconEntry
}

func BeaconEntriesForBlock(ctx context.Context, bSchedule Schedule, epoch abi.ChainEpoch, parentEpoch abi.ChainEpoch, prev types.BeaconEntry) ([]types.BeaconEntry, error) {
{
parentBeacon := bSchedule.BeaconForEpoch(parentEpoch)
currBeacon := bSchedule.BeaconForEpoch(epoch)
if parentBeacon != currBeacon {
// Fork logic
round := currBeacon.MaxBeaconRoundForEpoch(epoch)
out := make([]types.BeaconEntry, 2)
rch := currBeacon.Entry(ctx, round-1)
res := <-rch
if res.Err != nil {
return nil, xerrors.Errorf("getting entry %d returned error: %w", round-1, res.Err)
}
out[0] = res.Entry
rch = currBeacon.Entry(ctx, round)
res = <-rch
if res.Err != nil {
return nil, xerrors.Errorf("getting entry %d returned error: %w", round, res.Err)
}
out[1] = res.Entry
return out, nil
}
}

beacon := bSchedule.BeaconForEpoch(epoch)

start := build.Clock.Now()

maxRound := beacon.MaxBeaconRoundForEpoch(epoch)
if maxRound == prev.Round {
return nil, nil
}

// TODO: this is a sketchy way to handle the genesis block not having a beacon entry
if prev.Round == 0 {
prev.Round = maxRound - 1
}

cur := maxRound
var out []types.BeaconEntry
for cur > prev.Round {
rch := beacon.Entry(ctx, cur)
select {
case resp := <-rch:
if resp.Err != nil {
return nil, xerrors.Errorf("beacon entry request returned error: %w", resp.Err)
}

out = append(out, resp.Entry)
cur = resp.Entry.Round - 1
case <-ctx.Done():
return nil, xerrors.Errorf("context timed out waiting on beacon entry to come back for epoch %d: %w", epoch, ctx.Err())
}
}

log.Debugw("fetching beacon entries", "took", build.Clock.Since(start), "numEntries", len(out))
reverse(out)
return out, nil
}

func (db *DrandBeacon) MaxBeaconRoundForEpoch(filEpoch abi.ChainEpoch) uint64 {
// TODO: sometimes the genesis time for filecoin is zero and this goes negative
latestTs := ((uint64(filEpoch) * db.filRoundTime) + db.filGenTime) - db.filRoundTime
dround := (latestTs - db.drandGenTime) / uint64(db.interval.Seconds())
return dround
}

##### Validating Beacon Entries on block receptionState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.validating-beacon-entries-on-block-reception

A Filecoin chain will contain the entirety of the beacon’s output from the Filecoin genesis to the current block.

Given their role in leader election and other critical protocols in Filecoin, a block’s beacon entries must be validated for every block. See drand for details. This can be done by ensuring every beacon entry is a valid signature over the prior one in the chain, using drand’s Verify endpoint as follows:

func ValidateBlockValues(bSchedule Schedule, h *types.BlockHeader, parentEpoch abi.ChainEpoch,
prevEntry types.BeaconEntry) error {
{
parentBeacon := bSchedule.BeaconForEpoch(parentEpoch)
currBeacon := bSchedule.BeaconForEpoch(h.Height)
if parentBeacon != currBeacon {
if len(h.BeaconEntries) != 2 {
return xerrors.Errorf("expected two beacon entries at beacon fork, got %d", len(h.BeaconEntries))
}
err := currBeacon.VerifyEntry(h.BeaconEntries[1], h.BeaconEntries[0])
if err != nil {
return xerrors.Errorf("beacon at fork point invalid: (%v, %v): %w",
h.BeaconEntries[1], h.BeaconEntries[0], err)
}
return nil
}
}

// TODO: fork logic
b := bSchedule.BeaconForEpoch(h.Height)
maxRound := b.MaxBeaconRoundForEpoch(h.Height)
if maxRound == prevEntry.Round {
if len(h.BeaconEntries) != 0 {
return xerrors.Errorf("expected not to have any beacon entries in this block, got %d", len(h.BeaconEntries))
}
return nil
}

if len(h.BeaconEntries) == 0 {
return xerrors.Errorf("expected to have beacon entries in this block, but didn't find any")
}

last := h.BeaconEntries[len(h.BeaconEntries)-1]
if last.Round != maxRound {
return xerrors.Errorf("expected final beacon entry in block to be at round %d, got %d", maxRound, last.Round)
}

for i, e := range h.BeaconEntries {
if err := b.VerifyEntry(e, prevEntry); err != nil {
return xerrors.Errorf("beacon entry %d (%d - %x (%d)) was invalid: %w", i, e.Round, e.Data, len(e.Data), err)
}
prevEntry = e
}

return nil
}


#### TicketsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.tickets

Filecoin block headers also contain a single “ticket” generated from its epoch’s beacon entry. Tickets are used to break ties in the Fork Choice Rule, for forks of equal weight.

Whenever comparing tickets in Filecoin, the comparison is that of the ticket’s VRF Digest’s bytes.

##### Randomness Ticket generationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.randomness-ticket-generation

At a Filecoin epoch n, a new ticket is generated using the appropriate beacon entry for epoch n.

The miner runs the beacon entry through a Verifiable Random Function (VRF) to get a new unique ticket. The beacon entry is prepended with the ticket domain separation tag and concatenated with the miner actor address (to ensure miners using the same worker keys get different tickets).

To generate a ticket for a given epoch n:

randSeed = GetRandomnessFromBeacon(n)
newTicketRandomness = VRF_miner(H(TicketProdDST || index || Serialization(randSeed, minerActorAddress)))


Verifiable Random Functions are used for ticket generation.

##### Ticket ValidationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.ticket-validation

Each Ticket should be generated from the prior one in the VRF-chain and verified accordingly.

#### Minimum Miner SizeState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.minimum-miner-size

In order to secure Storage Power Consensus, the system defines a minimum miner size required to participate in consensus.

Specifically, miners must have either at least MIN_MINER_SIZE_STOR of power (i.e. storage power currently used in storage deals) in order to participate in leader election. If no miner has MIN_MINER_SIZE_STOR or more power, miners with at least as much power as the smallest miner in the top MIN_MINER_SIZE_TARG of miners (sorted by storage power) will be able to participate in leader election. In plain english, take MIN_MINER_SIZE_TARG = 3 for instance, this means that miners with at least as much power as the 3rd largest miner will be eligible to participate in consensus.

Miners smaller than this cannot mine blocks and earn block rewards in the network. Their power will still be counted in the total network (raw or claimed) storage power, even though their power will not be counted as votes for leader election. However, it is important to note that such miners can still have their power faulted and be penalized accordingly.

Accordingly, to bootstrap the network, the genesis block must include miners, potentially just CommittedCapacity sectors, to initiate the network.

The MIN_MINER_SIZE_TARG condition will not be used in a network in which any miner has more than MIN_MINER_SIZE_STOR power. It is nonetheless defined to ensure liveness in small networks (e.g. close to genesis or after large power drops).

#### Storage Power ActorState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor

##### StoragePowerActorState implementationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractorstate-implementation
type State struct {
TotalRawBytePower abi.StoragePower
// TotalBytesCommitted includes claims from miners below min power threshold
TotalBytesCommitted  abi.StoragePower
// TotalQABytesCommitted includes claims from miners below min power threshold
TotalQABytesCommitted abi.StoragePower
TotalPledgeCollateral abi.TokenAmount

// These fields are set once per epoch in the previous cron tick and used
// for consistent values across a single epoch's state transition.
ThisEpochRawBytePower     abi.StoragePower
ThisEpochPledgeCollateral abi.TokenAmount
ThisEpochQAPowerSmoothed  smoothing.FilterEstimate

MinerCount int64
// Number of miners having proven the minimum consensus power.
MinerAboveMinPowerCount int64

// A queue of events to be triggered by cron, indexed by epoch.
CronEventQueue cid.Cid // Multimap, (HAMT[ChainEpoch]AMT[CronEvent])

// First epoch in which a cron task may be stored.
// Cron will iterate every epoch between this and the current epoch inclusively to find tasks to execute.
FirstCronEpoch abi.ChainEpoch

// Claimed power for each miner.

}

##### StoragePowerActor implementationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractor-implementation
func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2:                         a.CreateMiner,
3:                         a.UpdateClaimedPower,
4:                         a.EnrollCronEvent,
5:                         a.OnEpochTickEnd,
6:                         a.UpdatePledgeTotal,
7:                         nil, // deprecated
8:                         a.SubmitPoRepForBulkVerify,
9:                         a.CurrentTotalPower,
}
}


Storage miner actor constructor params are defined here so the power actor can send them to the init actor to instantiate miners. Changed since v0:

type MinerConstructorParams struct {
SealProofType abi.RegisteredSealProof
PeerId        abi.PeerID
}

##### The Power TableState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.the-power-table

The portion of blocks a given miner generates through leader election in EC (and so the block rewards they earn) is proportional to their Quality-Adjusted Power Fraction over time. That is, a miner whose quality adjusted power represents 1% of total quality adjusted power on the network should mine 1% of blocks on expectation.

SPC provides a power table abstraction which tracks miner power (i.e. miner storage in relation to network storage) over time. The power table is updated for new sector commitments (incrementing miner power), for failed PoSts (decrementing miner power) or for other storage and consensus faults.

Sector ProveCommit is the first time power is proven to the network and hence power is first added upon successful sector ProveCommit. Power is also added when a sector is declared as recovered. Miners are expected to prove over all their sectors that contribute to their power.

Power is decremented when a sector expires, when a sector is declared or detected to be faulty, or when it is terminated through miner invocation. Miners can also extend the lifetime of a sector through ExtendSectorExpiration.

The Miner lifecycle in the power table should be roughly as follows:

• MinerRegistration: A new miner with an associated worker public key and address is registered on the power table by the storage mining subsystem, along with their associated sector size (there is only one per worker).
• UpdatePower: These power increments and decrements are called by various storage actors (and must thus be verified by every full node on the network). Specifically:
• Power is incremented at SectorProveCommit
• Power of a partition is decremented immediately after a missed WindowPoSt (DetectedFault).
• A particular sector’s power is decremented when it enters into a faulty state either through Declared Faults or Skipped Faults.
• A particular sector’s power is added back after recovery is declared and proven by PoSt.
• A particular sector’s power is removed when the sector is expired or terminated through miner invovation.

To summarize, only sectors in the Active state will command power. A Sector becomes Active when it is added upon ProveCommit. Power is immediately decremented when it enters into the faulty state. Power will be restored when its declared recovery is proven. A sector’s power is removed when it is expired or terminated through miner invocation.

##### Pledge CollateralState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.pledge-collateral

Pledge Collateral is slashed for any fault affecting storage-power consensus, these include:

• faults to expected consensus in particular (see Consensus Faults), which will be reported by a slasher to the StoragePowerActor in exchange for a reward.
• faults affecting consensus power more generally, specifically uncommitted power faults (i.e. Storage Faults), which will be reported by the CronActor automatically or when a miner terminates a sector earlier than its promised duration.

For a more detailed discussion on Pledge Collateral, please see the Miner Collaterals section.

## TokenState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token

### Minting ModelState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.minting_model

Many blockchains mint tokens based on a simple exponential decay model. Under this model, block rewards are highest in the beginning, and miner participation is often the lowest, so mining generates many tokens per unit of work early in the networkʼs life, then rapidly decreases.

Over many cryptoeconomic simulations, it became clear that the simple exponential decay model would encourage short-term behavior around network launch with an unhealthy effect on the Filecoin Economy. Specifically, it would incentivize storage miners to over-invest in hardware for the sealing stage of mining to onboard storage as quickly as possible. It would be profitable to exit the network after exhausting these early rewards, even if it resulted in losing client data. This would harm the network: clients would lose data and have less access to long-term storage, and miners would have little incentive to contribute more resources to the network. Additionally, this would result in the majority of network subsidies being paid based wholly on timing, rather than actual storage (and hence value) provided to the network.

To encourage consistent storage onboarding and investment in long-term storage, not just rapid sealing, Filecoin introduces the concept of a network baseline. Instead of minting tokens based purely on elapsed time, block rewards instead scale up as total storage power on the network increases. This preserves the shape of the original exponential decay model, but softens it in the earliest days of the network. Once the network reaches the baseline, the cumulative block reward issued is identical to a simple exponential decay model, but if the network does not pass the pre-established threshold, a portion of block rewards are deferred. The overall result is that Filecoin rewards to miners more closely match the utility they, and the network as a whole, provide to clients.

Specifically, a hybrid exponential minting mechanism is introduced with a proportion of the reward coming from simple exponential decay, “Simple Minting” and the other proportion from network baseline, “Baseline Minting”. The total reward per epoch will be the sum of the two rewards. Mining Filecoin should be even more profitable with this mechanism. Simple minting allocation disproportionately rewards early miners and provides counter pressure to shocks. Baseline minting allocation mints more tokens when more value for the network has been created. More tokens are minted to facilitate greater trade when the network can unlock a greater potential. This should lead to increased creation of value for the network and lower risk of minting filecoin too quickly.

The protocol allocates 30% of Storage Mining Allocation in Simple Minting and the remaining 70% in Baseline Minting. 30% of Simple Minting can provide counter forces in the event of shocks. Baseline capacity can start from a smaller percentage of worldʼs storage today, grow at a rapid rate, and catch up to a higher but still reasonable percentage of worldʼs storage in the future. As such, the network baseline will start from 1EiB (which is less than 0.01% of the worldʼs storage today) and grow at an annual rate of 200% (higher than the usual world storage annual growth rate at 40%). The community can come together to slow down the rate of growth when the network is providing 1-10% of the worldʼs storage.

There are many features that will make passing the baseline more efficient and economical and unleash a greater share of baseline minting. The community can come together to collectively achieve these goals:

• More performant Proof of Replication algorithms, with lower on chain footprint, faster verification time, cheaper hardware requirement, different security assumptions, resulting in sectors with longer lifetime and enabling sector upgrades without reseal.
• A more scalable consensus algorithm that can provide greater throughput and handle larger volume with shorter finality.
• More deal functionalities that allow sectors to last for longer.

Lastly, it is important to note that while the block reward incentivizes participation, it cannot be treated as a resource to be exploited. It is a common pool of subsidies that seeds and grows the network to benefit the economy and participants. An example of different stages of the economy and different sources of subsidies is illustrated in the following Figure.

### Block Reward MintingState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.block_reward_minting

In this section, we provide the mathematical specification for Simple Minting, Baseline Minting and Block Reward Issuance. We will provide the details and key mathematical properties for the above concepts.

#### Economic parametersState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.block_reward_minting.economic-parameters

• $M_\infty$ is the total asymptotic number of tokens to be emitted as storage-mining block rewards. Per the Token Allocation spec, $M_\infty := 55\% \cdot \texttt{FIL\_BASE} = 0.55 \cdot 2\times 10^9 FIL = 1.1 \times 10^9 FIL$. The dimension of the $M_\infty$ quantity is tokens.

• $\lambda$ is the “simple exponential decay” minting rate corresponding to a 6-year half-life. The meaning of “simple exponential decay” is that the total minted supply at time $t$ is $M_\infty \cdot (1 - e^{-\lambda t})$, so the specification of $\lambda$ in symbols becomes the equation $1 - e^{-\lambda \cdot 6yr} = \frac{1}{2}$. Note that a “year” is poorly defined. The simplified definition of $1yr := 365d$ was agreed upon for Filecoin. Of course, $1d = 86400s$, so $1yr = 31536000s$. We can solve this equation as

$\lambda = \frac{\ln 2}{6yr} = \frac{\ln 2}{189216000s} \approx 3.663258818 \times 10^{-9} Hz$

The dimension of the $\lambda$ quantity is time$^{-1}$.

• $\gamma$ is the mixture between baseline and simple minting. A $\gamma$ value of 1.0 corresponds to pure baseline minting, while a $\gamma$ value of 0.0 corresponds to pure simple minting. We currently use $\gamma := 0.7$. The $\gamma$ quantity is dimensionless.

• $b(t)$ is the baseline function, which was designed as an exponential

$$b(t) = b_0 \cdot e^{g t}$$

where

• $b_0$ is the “initial baseline”. The dimension of the $b_0$ quantity is information.
• $g$ is related to the baseline’s “annual growth rate” ($g_a$) by the equation $\exp(g \cdot 1yr) = 1 + g_a$, which has the solution
$$g = \frac{\ln\left(1 + g_a\right)}{31536000s}.$$

While $g_a$ is dimensionless, the dimension of the $g$ quantity is time$^{-1}$.

The dimension of the $b(t)$ quantity is information.

#### Simple MintingState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.block_reward_minting.simple-minting

• $M_{\infty B}$ is the total number of tokens to be emitted via baseline minting: $M_{\infty B} = M_\infty \cdot \gamma$. Correspondingly, $M_{\infty S}$ is the total asymptotic number of tokens to be emitted via simple minting: $M_{\infty S} = M_\infty \cdot (1 - \gamma)$. Of course, $M_{\infty B} + M_{\infty S} = M_\infty$.

• $M_S(t)$ is the total number of tokens that should ideally have been emitted by simple minting up until time $t$. It is defined as $M_S(t) = M_{\infty S} \cdot (1 - e^{-\lambda t})$. It is easy to verify that $\lim_{t\rightarrow\infty} M_S(t) = M_{\infty S}$.

Note that $M_S(t)$ is easy to calculate, and can be determined quite independently of the network’s state. (This justifies the name “simple minting”.)

#### Baseline MintingState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.block_reward_minting.baseline-minting

To define $M_B(t)$ (which is the number of tokens that should be emitted up until time $t$ by baseline minting), we must introduce a number of auxiliary variables, some of which depend on network state.

• $R(t)$ is the instantaneous network raw-byte power (the total amount of bytes among all active sectors) at time $t$. This quantity is state-dependent—it depends on the activities of miners on the network (specifically: commitment, expiration, faulting, and termination of sectors). The dimension of the $R(t)$ quantity is information.

• $\overline{R}(t)$ is the capped network raw-byte power, defined as $\overline{R}(t):= \min\{b(t), R(t)\}$. Its dimension is also information.

• $\overline{R}_\Sigma(t)$ is the cumulative capped raw-byte power, defined as $\overline{R}_\Sigma(t) := \int_0^t \overline{R}(x)\, \mathrm{d}x$. The dimension of $\overline{R_\Sigma}(t)$ is information$\cdot$time (a dimension often referred to as “spacetime”).

• $\theta(t)$ is the “effective network time”, and is defined as the solution to the equation

$$\int_0^{\theta(t)} b(x)\, \mathrm{d}x = \int_0^t \overline{R}(x)\, \mathrm{d}x = \overline{R}_\Sigma(t)$$

By plugging in the definition of $b(x)$ and evaluating the integral, we can solve for a closed form of $\theta(t)$ as follows:

$$\int_0^{\theta(t)} b(x)\, \mathrm{d}x = \frac{b_0}{g} \left( e^{g\theta(t)} - 1 \right) = \overline{R}_\Sigma(t)$$ $$\theta(t) = \frac{1}{g} \ln \left(\frac{g \overline{R}_\Sigma(t)}{b_0}+1\right)$$
• $M_B(t)$ is defined similarly to $M_S(t)$, just with $\theta(t)$ in place of $t$ and $M_{\infty B}$ in place of $M_{\infty S}$:
$$M_B(t) = M_{\infty B} \cdot \left(1 - e^{-\lambda \theta(t)}\right)$$

#### Block Reward IssuanceState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.block_reward_minting.block-reward-issuance

• $M(t)$, the total number of tokens to be emitted as expected block rewards up until time $t$, is defined as the sum of simple and baseline minting:
$$M(t) = M_S(t) + M_B(t)$$

Now we have defined a continuous target trajectory for cumulative minting. But minting actually occurs incrementally, and also in discrete increments. Periodically, a “tipset” is formed consisting of multiple winners, each of which receives an equal, finite amount of reward. A single miner may win multiple times, but may only submit one block and may still receive rewards as if they submitted multiple winning blocks. The mechanism by which multiple wins are rewarded is multiplication by a variable called WinCount, so we refer to the finite quantity minted and awarded for each win as “reward per WinCount” or “per win reward”.

• $\tau$ is the duration of an “epoch” or “round” (these are synonymous). Per the spec, $\tau = 30s$. The dimension of $\tau$ is time.
• $E$ is a parameter which determines the expected number of wins per round. While $E$ could be considered dimensionless, it useful to give it a dimension of “wins”. In Filecoin, the value of $E$ is 5.
• $W(n)$ is the total number of wins by all miners in the tipset during round $n$. This also has dimension “wins”. For each $n$, $W(n)$ is a random variable with the independent identical distribution $\mathrm{Poisson}(E)$.
• $w(n)$ is the “reward per WinCount” or “per win reward” for round $n$. It is defined by:
$$w(n) = \frac{\max\{M(n\tau+\tau) - M(n\tau),0\}}{E}$$

The dimension of $W(n)$ is tokens$\cdot$wins$^{-1}$.

• While $M(t)$ is a continuous target for minted supply, the discrete and random amount of tokens which have been minted as of time $t$ is
$$m(t) = \sum_{k=0}^{\left\lfloor t/\tau\right\rfloor-1} w(k) W(k)$$

$m(t)$ depends on past values of both $W(n)$ and $R(n\tau)$.

### Token AllocationState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_token.token_allocation

Filecoinʼs token distribution is broken down as follows. A maximum of 2,000,000,000 FIL will ever be created, referred to as FIL_BASE. Of the Filecoin genesis block allocation, 10% of FIL_BASE were allocated for fundraising, of which 7.5% were sold in the 2017 token sale, and the 2.5% remaining were allocated for ecosystem development and potential future fundraising. 15% of FIL_BASE were allocated to Protocol Labs (including 4.5% for the PL team & contributors), and 5% were allocated to the Filecoin Foundation. The other 70% of all tokens were allocated to miners, as mining rewards, “for providing data storage service, maintaining the blockchain, distributing data, running contracts, and more.” There are multiple types of mining that these rewards will support over time; therefore, this allocation has been subdivided to cover different mining activities. A pie chart reflecting the FIL token allocation is shown in the following Figure.

Storage Mining Allocation. At network launch, the only mining group with allocated incentives will be storage miners. This is the earliest group of miners, and the one responsible for maintaining the core functionality of the protocol. Therefore, this group has been allocated the largest amount of mining rewards. 55% of FIL_BASE (78.6% of mining rewards) is allocated to storage mining. This will cover primarily block rewards, which reward maintaining the blockchain, running actor code, and subsidizing reliable and useful storage. This amount will also cover early storage mining rewards, such as rewards in the SpaceRace competition and other potential types of storage miner initialization, such as faucets.

Mining Reserve. The Filecoin ecosystem must ensure incentives exist for all types of miners (e.g. retrieval miners, repair miners, and including future unknown types of miners) to support a robust economy. In order to ensure the network can provide incentives for these other types of miners, 15% of FIL_BASE (21.4% of mining rewards) have been set aside as a Mining Reserve. It will be up to the community to determine in the future how to distribute those tokens, through Filecoin improvement proposals (FIPs) or similar decentralized decision making processes. For example, the community might decide to create rewards for retrieval mining or other types of mining-related activities. The Filecoin Network, like all blockchain networks and open source projects, will continue to evolve, adapt, and overcome challenges for many years. Reserving these tokens provides future flexibility for miners and the ecosystem as a whole. Other types of mining, like retrieval mining, are not yet subsidized and yet are very important to the Filecoin Economy; Arguably, those uses may need a larger percentage of mining rewards. As years pass and the network evolves, it will be up to the community to decide whether this reserve is enough, or whether to make adjustments with unmined tokens.

Market Cap. Various communities estimate the size of cryptocurrency and token networks using different analogous measures of market capitalization. The most sensible token supply for such calculations is FIL_CirculatingSupply, because unmined, unvested, locked, and burnt funds are not circulating or tradeable in the economy. Any calculations using larger measures such as FIL_BASE are likely to be erroneously inflated and not to be believed.

Total Burnt Funds. Some filecoin are burned to fund on-chain computations and bandwidth as network message fees, in addition to those burned in penalties for storage faults and consensus faults, creating long-term deflationary pressure on the token. Accompanying the network message fees is the priority fee that is not burned, but goes to the block-producing miners for including a message.

ParameterValueDescription
FIL_BASE2,000,000,000 FILThe maximum amount of FIL that will ever be created.
FIL_MiningReserveAlloc300,000,000 FILTokens reserved for funding mining to support growth of the Filecoin Economy, whose future usage will be decided by the Filecoin community
FIL_StorageMiningAlloc1,100,000,000 FILThe amount of FIL allocated to storage miners through block rewards, network initialization
FIL_VestedSum of genesis MultisigActors.
AmountUnlocked
Total amount of FIL that is vested from genesis allocation.
FIL_StorageMinedRewardActor.
TotalStoragePowerReward
The amount of FIL that has been mined by storage miners
FIL_LockedTotalPledgeCollateral + TotalProviderDealCollateral + TotalClientDealCollateral + TotalPendingDealPayment + OtherLockedFundsThe amount of FIL locked as part of mining, deals, and other mechanisms.
FIL_CirculatingSupplyFIL_Vested + FIL_Mined - TotalBurntFunds - FIL_LockedThe amount of FIL circulating and tradeable in the economy. The basis for Market Cap calculations.
TotalBurntFundsBurntFundsActor.
Balance
Total FIL burned as part of penalties and on-chain computations.
TotalPledgeCollateralStoragePowerActor.
TotalPledgeCollateral
Total FIL locked as pledge collateral in all miners.
TotalProviderDealCollateralStorageMarketActor.
TotalProviderDealCollateral
Total FIL locked as provider deal collateral
TotalClientDealCollateralStorageMarketActor.
TotalClientDealColateral
Total FIL locked as client deal collateral
TotalPendingDealPaymentStorageMarketActor.
TotalPendingDealPayment
Total FIL locked as pending client deal payment

### Payment ChannelsState stableTheory Audit wipEdit this sectionsection-systems.filecoin_token.payment_channels

Payment channels are generally used as a mechanism to increase the scalability of blockchains and enable users to transact without involving (i.e., publishing their transactions on) the blockchain, which: i) increases the load of the system, and ii) incurs gas costs for the user. Payment channels generally use a smart contract as an agreement between the two participants. In the Filecoin blockchain Payment Channels are realised by the paychActor.

The goal of the Payment Channel Actor specified here is to enable a series of off-chain microtransactions for applications built on top of Filecoin to be reconciled on-chain at a later time with fewer messages that involve the blockchain. Payment channels are already used in the Retrieval Market of the Filecoin Network, but their applicability is not constrained within this use-case only. Hence, here, we provide a detailed description of Payment Channels in the Filecoin network and then describe how Payment Channels are used in the specific case of the Filecoin Retrieval Market.

The payment channel actor can be used to open long-lived, flexible payment channels between users. Filecoin payment channels are uni-directional and can be funded by adding to their balance. Given the context of uni-directional payment channels, we define the payment channel sender as the party that receives some service, creates the channel, deposits funds and sends payments (hence the term payment channel sender). The payment channel recipient, on the other hand is defined as the party that provides services and receives payment for the services delivered (hence the term payment channel recipient). The fact that payment channels are uni-directional means that only the payment channel sender can add funds and the recipient can receive funds. Payment channels are identified by a unique address, as is the case with all Filecoin actors.

The payment channel state structure looks like this:

// A given payment channel actor is established by From (the receipent of a service)
// to enable off-chain microtransactions to To (the provider of a service) to be reconciled
// and tallied on chain.
type State struct {
// Channel owner, who has created and funded the actor - the channel sender
// Recipient of payouts from channel

// Amount successfully redeemed through the payment channel, paid out on Collect()
ToSend abi.TokenAmount

// Height at which the channel can be Collected
SettlingAt abi.ChainEpoch
// Height before which the channel ToSend cannot be collected
MinSettleHeight abi.ChainEpoch

// Collections of lane states for the channel, maintained in ID order.
LaneStates []*LaneState
}


Before continuing with the details of the Payment Channel and its components and features, it is worth defining a few terms.

• Voucher: a signed message created by either of the two channel parties that updates the channel balance. To differentiate to the payment channel sender/recipient, we refer to the voucher parties as voucher sender/recipient, who might or might not be the same as the payment channel ones (i.e., the voucher sender might be either the payment channel recipient or the payment channel sender).
• Redeeming a voucher: the voucher MUST be submitted on-chain by the opposite party from the one that created it. Redeeming a voucher does not trigger movement of funds from the channel to the recipient’s account, but it does incur message/gas costs. Vouchers can be redeemed at any time up to Collect (see below), as long as it has got a higher Nonce than a previously submitted one.
• UpdateChannelState: this is the process by which a voucher is redeemed, i.e., a voucher is submitted (but not cashed-out) on-chain.
• Settle: this process starts closing the channel. It can be called by either the channel creator (sender) or the channel recipient.
• Collect: with this process funds are eventually transferred from the payment channel sender to the payment channel recipient. This process incurs message/gas costs.

#### VouchersState stableTheory Audit wipEdit this sectionsection-systems.filecoin_token.payment_channels.vouchers

Traditionally, in order to transact through a Payment Channel, the payment channel parties send to each other signed messages that update the balance of the channel. In Filecoin, these signed messages are called vouchers.

Throughout the interaction between the two parties, the channel sender (From address) is sending vouchers to the recipient (To address). The Value included in the voucher indicates the value available for the receiving party to redeem. The Value is based on the service that the payment channel recipient has provided to the payment channel sender. Either the payment channel recipient or the payment channel sender can Update the balance of the channel and the balance ToSend to the payment channel recipient (using a voucher), but the Update (i.e., the voucher) has to be accepted by the other party before funds can be collected. Furthermore, the voucher has to be redeemed by the opposite party from the one that issued the voucher. The payment channel recipient can choose to Collect this balance at any time incurring the corresponding gas cost.

Redeeming a voucher is not transferring funds from the payment channel to the recipient’s account. Instead, redeeming a voucher denotes the fact that some service worth of Value has been provided by the payment channel recipient to the payment channel sender. It is not until the whole payment channel is collected that the funds are dispatched to the provider’s account.

This is the structure of the voucher:

// A voucher can be created and sent by any of the two parties. The To payment channel address can redeem the voucher and then Collect the funds.
type SignedVoucher struct {
// ChannelAddr is the address of the payment channel this signed voucher is valid for
// TimeLockMin sets a min epoch before which the voucher cannot be redeemed
TimeLockMin abi.ChainEpoch
// TimeLockMax sets a max epoch beyond which the voucher cannot be redeemed
// TimeLockMax set to 0 means no timeout
TimeLockMax abi.ChainEpoch
// (optional) The SecretPreImage is used by To to validate
SecretPreimage []byte
// (optional) Extra can be specified by From to add a verification method to the voucher
Extra *ModVerifyParams
// Specifies which lane the Voucher is added to (will be created if does not exist)
Lane uint64
// Nonce is set by From to prevent redemption of stale vouchers on a lane
Nonce uint64
// Amount voucher can be redeemed for
Amount big.Int
// (optional) MinSettleHeight can extend channel MinSettleHeight if needed
MinSettleHeight abi.ChainEpoch

// (optional) Set of lanes to be merged into Lane
Merges []Merge

// Sender's signature over the voucher
Signature *crypto.Signature
}


Over the course of a transaction cycle, each participant in the payment channel can send Vouchers to the other participant.

For instance, if the payment channel sender (From address) has sent to the payment channel recipient (To address) the following three vouchers (voucher_val, voucher_nonce) for a lane with 100 FIL to be redeemed: (10, 1), (20, 2), (30, 3), then the recipient could choose to redeem (30, 3) bringing the lane’s value to 70 (100 - 30) and cancelling the preceding vouchers, i.e., they would not be able to redeem (10, 1) or (20, 2) anymore. However, they could redeem (20, 2), that is, 20 FIL, and then follow up with (30, 3) to redeem the remaining 10 FIL later.

It is worth highlighting that while the Nonce is a strictly increasing value to denote the sequence of vouchers issued within the remit of a payment channel, the Value is not a strictly increasing value. Decreasing Value (although expected rarely) can be realized in cases of refunds that need to flow in the direction from the payment channel recipient to the payment channel sender. This can be the case when some bits arrive corrupted in the case of file retrieval, for instance.

Vouchers are signed by the party that creates them and are authenticated using a (Secret, PreImage) pair provided by the paying party (channel sender). If the PreImage is indeed a pre-image of the Secret when used as input to some given algorithm (typically a one-way function like a hash), the Voucher is valid. The Voucher itself contains the PreImage but not the Secret (communicated separately to the receiving party). This enables multi-hop payments since an intermediary cannot redeem a voucher on their own. Vouchers can also be used to update the minimum height at which a channel will be settled (i.e., closed), or have TimeLocks to prevent voucher recipients from redeeming them too early. A channel can also have a MinCloseHeight to prevent it being closed prematurely (e.g. before the payment channel recipient has collected funds) by the payment channel creator/sender.

Once their transactions have completed, either party can choose to Settle (i.e., close) the channel. There is a 12hr period after Settle during which either party can submit any outstanding vouchers. Once the vouchers are submitted, either party can then call Collect. This will send the payment channel recipient the ToPay amount from the channel, and the channel sender (From address) will be refunded the remaining balance in the channel (if any).

#### LanesState stableTheory Audit wipEdit this sectionsection-systems.filecoin_token.payment_channels.lanes

In addition, payment channels in Filecoin can be split into lanes created as part of updating the channel state with a payment voucher. Each lane has an associated nonce and amount of tokens it can be redeemed for. Lanes can be thought of as transactions for several different services provided by the channel recipient to the channel sender. The nonce plays the role of a sequence number of vouchers within a given lane, where a voucher with a higher nonce replaces a voucher with a lower nonce.

Payment channel lanes allow for a lot of accounting between parties to be done off-chain and reconciled via single updates to the payment channel. The multiple lanes enable two parties to use a single payment channel to adjudicate multiple independent sets of payments.

One example of such accounting is merging of lanes. When a pair of channel sender-recipient nodes have a payment channel established between them with many lanes, the channel recipient will have to pay gas cost for each one of the lanes in order to Collect funds. Merging of lanes allow the channel recipient to send a “merge” request to the channel sender to request merging of (some of the) lanes and consolidate the funds. This way, the recipient can reduce the overall gas cost. As an incentive for the channel sender to accept the merge lane request, the channel recipient can ask for a lower total value to balance out the gas cost. For instance, if the recipient has collected vouchers worth of 10 FIL from two lanes, say 5 from each, and the gas cost of submitting the vouchers for these funds is 2, then it can ask for 9 from the creator if the latter accepts to merge the two lanes. This way, the channel sender pays less overall for the services it received and the channel recipient pays less gas cost to submit the voucher for the services they provided.

#### Lifecycle of a Payment ChannelState stableTheory Audit wipEdit this sectionsection-systems.filecoin_token.payment_channels.lifecycle-of-a-payment-channel

Summarising, we have the following sequence:

1. Two parties agree to a series of transactions (for instance as part of file retrieval) with one party paying the other party up to some total sum of Filecoin over time. This is part of the deal-phase, it takes place off-chain and does not (at this stage) involve payment channels.
2. The Payment Channel Actor is used, called the payment channel sender (who is the recipient of some service, e.g., file in case of file retrieval) to create the payment channel and deposit funds.
3. Any of the two parties can create vouchers to send to the other party.
4. The voucher recipient saves the voucher locally. Each voucher has to be submitted by the opposite party from the one that created the voucher.
5. Either immediately or later, the voucher recipient “redeems” the voucher by submitting it to the chain, calling UpdateChannelState
6. The channel sender or the channel recipient Settle the payment channel.
7. 12-hour period to close the channel begins.
8. If any of the two parties have outstanding (i.e., non-redeemed) vouchers, they should now submit the vouchers to the chain (there should be the option of this being done automatically). If the channel recipient so desires, they should send a “merge lanes” request to the sender.
9. 12-hour period ends.
10. Either the channel sender or the channel recipient calls Collect.
11. Funds are transferred to the channel recipient’s account and any unclaimed balance goes back to channel sender.

#### Payment Channels as part of the Filecoin RetrievalState stableTheory Audit wipEdit this sectionsection-systems.filecoin_token.payment_channels.payment-channels-as-part-of-the-filecoin-retrieval

Payment Channels are used in the Filecoin Retrieval Market to enable efficient off-chain payments and accounting between parties for what is expected to be a series of microtransactions, as these occur during data retrieval.

In particular, given that there is no proving method provided for the act of sending data from a provider (miner) to a client, there is no trust anchor between the two. Therefore, in order to avoid mis-behaviour, Filecoin is making use of payment channels in order to realise a step-wise “data transfer <-> payment” relationship between the data provider and the client (data receiver). Clients issue requests for data that miners are responding to. The miner is entitled to ask for interim payments, the volume-oriented interval for which is agreed in the Deal phase. In order to facilitate this process, the Filecoin client is creating a payment channel once the provider has agreed on the proposed deal. The client should also lock monetary value in the payment channel equal to the one needed for retrieval of the entire block of data requested. Every time a provider is completing transfer of the pre-specified amount of data, they can request a payment. The client is responding to this payment with a voucher which the provider can redeem (immediately or later), as per the process described earlier.

package paychmgr

import (
"context"
"fmt"

"github.com/ipfs/go-cid"
"golang.org/x/xerrors"

cborutil "github.com/filecoin-project/go-cbor-util"
"github.com/filecoin-project/go-state-types/big"

"github.com/filecoin-project/lotus/api"
"github.com/filecoin-project/lotus/chain/actors"
"github.com/filecoin-project/lotus/chain/actors/builtin/paych"
"github.com/filecoin-project/lotus/chain/types"
"github.com/filecoin-project/lotus/lib/sigs"
)

// insufficientFundsErr indicates that there are not enough funds in the
// channel to create a voucher
type insufficientFundsErr interface {
Shortfall() types.BigInt
}

type ErrInsufficientFunds struct {
shortfall types.BigInt
}

return &ErrInsufficientFunds{shortfall: shortfall}
}

func (e *ErrInsufficientFunds) Error() string {
return fmt.Sprintf("not enough funds in channel to cover voucher - shortfall: %d", e.shortfall)
}

func (e *ErrInsufficientFunds) Shortfall() types.BigInt {
return e.shortfall
}

type laneState struct {
redeemed big.Int
nonce    uint64
}

func (ls laneState) Redeemed() (big.Int, error) {
return ls.redeemed, nil
}

func (ls laneState) Nonce() (uint64, error) {
return ls.nonce, nil
}

// channelAccessor is used to simplify locking when accessing a channel
type channelAccessor struct {

// chctx is used by background processes (eg when waiting for things to be
// confirmed on chain)
chctx         context.Context
sa            *stateAccessor
api           managerAPI
store         *Store
lk            *channelLock
fundsReqQueue []*fundsReq
msgListeners  msgListeners
}

return &channelAccessor{
from:         from,
to:           to,
chctx:        pm.ctx,
sa:           pm.sa,
api:          pm.pchapi,
store:        pm.store,
lk:           &channelLock{globalLock: &pm.lk},
msgListeners: newMsgListeners(),
}
}

nwVersion, err := ca.api.StateNetworkVersion(ctx, types.EmptyTSK)
if err != nil {
return nil, err
}

return paych.Message(actors.VersionForNetwork(nwVersion), from), nil
}

ca.lk.Lock()
defer ca.lk.Unlock()

}

ca.lk.Lock()
defer ca.lk.Unlock()

return ca.store.OutboundActiveByFromTo(from, to)
}

// createVoucher creates a voucher with the given specification, setting its
// nonce, signing the voucher and storing it in the local datastore.
// If there are not enough funds in the channel to create the voucher, returns
// the shortfall in funds.
func (ca *channelAccessor) createVoucher(ctx context.Context, ch address.Address, voucher paych.SignedVoucher) (*api.VoucherCreateResult, error) {
ca.lk.Lock()
defer ca.lk.Unlock()

// Find the channel for the voucher
if err != nil {
return nil, xerrors.Errorf("failed to get channel info by address: %w", err)
}

// Set the voucher channel
sv := &voucher

// Get the next nonce on the given lane
sv.Nonce = ca.nextNonceForLane(ci, voucher.Lane)

// Sign the voucher
vb, err := sv.SigningBytes()
if err != nil {
return nil, xerrors.Errorf("failed to get voucher signing bytes: %w", err)
}

sig, err := ca.api.WalletSign(ctx, ci.Control, vb)
if err != nil {
return nil, xerrors.Errorf("failed to sign voucher: %w", err)
}
sv.Signature = sig

// Store the voucher
if _, err := ca.addVoucherUnlocked(ctx, ch, sv, types.NewInt(0)); err != nil {
// If there are not enough funds in the channel to cover the voucher,
// return a voucher create result with the shortfall
var ife insufficientFundsErr
if xerrors.As(err, &ife) {
return &api.VoucherCreateResult{
Shortfall: ife.Shortfall(),
}, nil
}

return nil, xerrors.Errorf("failed to persist voucher: %w", err)
}

return &api.VoucherCreateResult{Voucher: sv, Shortfall: types.NewInt(0)}, nil
}

func (ca *channelAccessor) nextNonceForLane(ci *ChannelInfo, lane uint64) uint64 {
var maxnonce uint64
for _, v := range ci.Vouchers {
if v.Voucher.Lane == lane {
if v.Voucher.Nonce > maxnonce {
maxnonce = v.Voucher.Nonce
}
}
}

return maxnonce + 1
}

func (ca *channelAccessor) checkVoucherValid(ctx context.Context, ch address.Address, sv *paych.SignedVoucher) (map[uint64]paych.LaneState, error) {
ca.lk.Lock()
defer ca.lk.Unlock()

return ca.checkVoucherValidUnlocked(ctx, ch, sv)
}

func (ca *channelAccessor) checkVoucherValidUnlocked(ctx context.Context, ch address.Address, sv *paych.SignedVoucher) (map[uint64]paych.LaneState, error) {
}

// Load payment channel actor state
act, pchState, err := ca.sa.loadPaychActorState(ctx, ch)
if err != nil {
return nil, err
}

// Load channel "From" account actor state
f, err := pchState.From()
if err != nil {
return nil, err
}

from, err := ca.api.ResolveToKeyAddress(ctx, f, nil)
if err != nil {
return nil, err
}

// verify voucher signature
vb, err := sv.SigningBytes()
if err != nil {
return nil, err
}

// TODO: technically, either party may create and sign a voucher.
// However, for now, we only accept them from the channel creator.
// More complex handling logic can be added later
if err := sigs.Verify(sv.Signature, from, vb); err != nil {
return nil, err
}

// Check the voucher against the highest known voucher nonce / value
laneStates, err := ca.laneState(pchState, ch)
if err != nil {
return nil, err
}

// If the new voucher nonce value is less than the highest known
// nonce for the lane
ls, lsExists := laneStates[sv.Lane]
if lsExists {
n, err := ls.Nonce()
if err != nil {
return nil, err
}

if sv.Nonce <= n {
return nil, fmt.Errorf("nonce too low")
}

// If the voucher amount is less than the highest known voucher amount
r, err := ls.Redeemed()
if err != nil {
return nil, err
}
if sv.Amount.LessThanEqual(r) {
return nil, fmt.Errorf("voucher amount is lower than amount for voucher with lower nonce")
}
}

// Total redeemed is the total redeemed amount for all lanes, including
// the new voucher
// eg
//
// lane 1 redeemed:            3
// lane 2 redeemed:            2
// voucher for lane 1:         5
//
// Voucher supersedes lane 1 redeemed, therefore
// effective lane 1 redeemed:  5
//
// lane 1:  5
// lane 2:  2
//          -
// total:   7
totalRedeemed, err := ca.totalRedeemedWithVoucher(laneStates, sv)
if err != nil {
return nil, err
}

// Total required balance must not exceed actor balance
if act.Balance.LessThan(totalRedeemed) {
}

if len(sv.Merges) != 0 {
return nil, fmt.Errorf("dont currently support paych lane merges")
}

return laneStates, nil
}

func (ca *channelAccessor) checkVoucherSpendable(ctx context.Context, ch address.Address, sv *paych.SignedVoucher, secret []byte) (bool, error) {
ca.lk.Lock()
defer ca.lk.Unlock()

recipient, err := ca.getPaychRecipient(ctx, ch)
if err != nil {
return false, err
}

if err != nil {
return false, err
}

// Check if voucher has already been submitted
submitted, err := ci.wasVoucherSubmitted(sv)
if err != nil {
return false, err
}
if submitted {
return false, nil
}

mb, err := ca.messageBuilder(ctx, recipient)
if err != nil {
return false, err
}

mes, err := mb.Update(ch, sv, secret)
if err != nil {
return false, err
}

ret, err := ca.api.Call(ctx, mes, nil)
if err != nil {
return false, err
}

if ret.MsgRct.ExitCode != 0 {
return false, nil
}

return true, nil
}

_, state, err := ca.api.GetPaychState(ctx, ch, nil)
if err != nil {
}

return state.To()
}

ca.lk.Lock()
defer ca.lk.Unlock()

}

if err != nil {
return types.BigInt{}, err
}

for _, v := range ci.Vouchers {
eq, err := cborutil.Equals(sv, v.Voucher)
if err != nil {
return types.BigInt{}, err
}
if eq {
// Ignore the duplicate voucher.
return types.NewInt(0), nil
}

}

// Check voucher validity
laneStates, err := ca.checkVoucherValidUnlocked(ctx, ch, sv)
if err != nil {
return types.NewInt(0), err
}

// The change in value is the delta between the voucher amount and
// the highest previous voucher amount for the lane
laneState, exists := laneStates[sv.Lane]
redeemed := big.NewInt(0)
if exists {
redeemed, err = laneState.Redeemed()
if err != nil {
return types.NewInt(0), err
}
}

delta := types.BigSub(sv.Amount, redeemed)
if minDelta.GreaterThan(delta) {
return delta, xerrors.Errorf("addVoucher: supplied token amount too low; minD=%s, D=%s; laneAmt=%s; v.Amt=%s", minDelta, delta, redeemed, sv.Amount)
}

ci.Vouchers = append(ci.Vouchers, &VoucherInfo{
Voucher: sv,
})

if ci.NextLane <= sv.Lane {
ci.NextLane = sv.Lane + 1
}

return delta, ca.store.putChannelInfo(ci)
}

func (ca *channelAccessor) submitVoucher(ctx context.Context, ch address.Address, sv *paych.SignedVoucher, secret []byte) (cid.Cid, error) {
ca.lk.Lock()
defer ca.lk.Unlock()

if err != nil {
return cid.Undef, err
}

has, err := ci.hasVoucher(sv)
if err != nil {
return cid.Undef, err
}

// If the channel has the voucher
if has {
// Check that the voucher hasn't already been submitted
submitted, err := ci.wasVoucherSubmitted(sv)
if err != nil {
return cid.Undef, err
}
if submitted {
return cid.Undef, xerrors.Errorf("cannot submit voucher that has already been submitted")
}
}

mb, err := ca.messageBuilder(ctx, ci.Control)
if err != nil {
return cid.Undef, err
}

msg, err := mb.Update(ch, sv, secret)
if err != nil {
return cid.Undef, err
}

smsg, err := ca.api.MpoolPushMessage(ctx, msg, nil)
if err != nil {
return cid.Undef, err
}

// If the channel didn't already have the voucher
if !has {
// Add the voucher to the channel
ci.Vouchers = append(ci.Vouchers, &VoucherInfo{
Voucher: sv,
})
}

// Mark the voucher and any lower-nonce vouchers as having been submitted
err = ca.store.MarkVoucherSubmitted(ci, sv)
if err != nil {
return cid.Undef, err
}

return smsg.Cid(), nil
}

ca.lk.Lock()
defer ca.lk.Unlock()

return ca.store.AllocateLane(ch)
}

ca.lk.Lock()
defer ca.lk.Unlock()

// TODO: just having a passthrough method like this feels odd. Seems like
// there should be some filtering we're doing here
return ca.store.VouchersForPaych(ch)
}

// laneState gets the LaneStates from chain, then applies all vouchers in
// the data store over the chain state
// TODO: we probably want to call UpdateChannelState with all vouchers to be fully correct
//  (but technically dont't need to)

laneCount, err := state.LaneCount()
if err != nil {
return nil, err
}

// Note: we use a map instead of an array to store laneStates because the
// client sets the lane ID (the index) and potentially they could use a
// very large index.
laneStates := make(map[uint64]paych.LaneState, laneCount)
err = state.ForEachLaneState(func(idx uint64, ls paych.LaneState) error {
laneStates[idx] = ls
return nil
})
if err != nil {
return nil, err
}

// Apply locally stored vouchers
vouchers, err := ca.store.VouchersForPaych(ch)
if err != nil && err != ErrChannelNotTracked {
return nil, err
}

for _, v := range vouchers {
for range v.Voucher.Merges {
return nil, xerrors.Errorf("paych merges not handled yet")
}

// Check if there is an existing laneState in the payment channel
// for this voucher's lane
ls, ok := laneStates[v.Voucher.Lane]

// If the voucher does not have a higher nonce than the existing
// laneState for this lane, ignore it
if ok {
n, err := ls.Nonce()
if err != nil {
return nil, err
}
if v.Voucher.Nonce < n {
continue
}
}

// Voucher has a higher nonce, so replace laneState with this voucher
laneStates[v.Voucher.Lane] = laneState{v.Voucher.Amount, v.Voucher.Nonce}
}

return laneStates, nil
}

// Get the total redeemed amount across all lanes, after applying the voucher
func (ca *channelAccessor) totalRedeemedWithVoucher(laneStates map[uint64]paych.LaneState, sv *paych.SignedVoucher) (big.Int, error) {
// TODO: merges
if len(sv.Merges) != 0 {
return big.Int{}, xerrors.Errorf("dont currently support paych lane merges")
}

total := big.NewInt(0)
for _, ls := range laneStates {
r, err := ls.Redeemed()
if err != nil {
return big.Int{}, err
}
}

lane, ok := laneStates[sv.Lane]
if ok {
// If the voucher is for an existing lane, and the voucher nonce
// is higher than the lane nonce
n, err := lane.Nonce()
if err != nil {
return big.Int{}, err
}

if sv.Nonce > n {
// Add the delta between the redeemed amount and the voucher
// amount to the total
r, err := lane.Redeemed()
if err != nil {
return big.Int{}, err
}

delta := big.Sub(sv.Amount, r)
}
} else {
// If the voucher is *not* for an existing lane, just add its
// value (implicitly a new lane will be created for the voucher)
}

}

ca.lk.Lock()
defer ca.lk.Unlock()

if err != nil {
return cid.Undef, err
}

mb, err := ca.messageBuilder(ctx, ci.Control)
if err != nil {
return cid.Undef, err
}
msg, err := mb.Settle(ch)
if err != nil {
return cid.Undef, err
}
smgs, err := ca.api.MpoolPushMessage(ctx, msg, nil)
if err != nil {
return cid.Undef, err
}

ci.Settling = true
err = ca.store.putChannelInfo(ci)
if err != nil {
log.Errorf("Error marking channel as settled: %s", err)
}

return smgs.Cid(), err
}

ca.lk.Lock()
defer ca.lk.Unlock()

if err != nil {
return cid.Undef, err
}

mb, err := ca.messageBuilder(ctx, ci.Control)
if err != nil {
return cid.Undef, err
}

msg, err := mb.Collect(ch)
if err != nil {
return cid.Undef, err
}

smsg, err := ca.api.MpoolPushMessage(ctx, msg, nil)
if err != nil {
return cid.Undef, err
}

return smsg.Cid(), nil
}

A voucher is sent by From to To off-chain in order to enable To to redeem payments on-chain in the future
type SignedVoucher struct {
// ChannelAddr is the address of the payment channel this signed voucher is valid for
// TimeLockMin sets a min epoch before which the voucher cannot be redeemed
TimeLockMin abi.ChainEpoch
// TimeLockMax sets a max epoch beyond which the voucher cannot be redeemed
// TimeLockMax set to 0 means no timeout
TimeLockMax abi.ChainEpoch
// (optional) The SecretPreImage is used by To to validate
SecretPreimage []byte
// (optional) Extra can be specified by From to add a verification method to the voucher
Extra *ModVerifyParams
// Specifies which lane the Voucher merges into (will be created if does not exist)
Lane uint64
// Nonce is set by From to prevent redemption of stale vouchers on a lane
Nonce uint64
// Amount voucher can be redeemed for
Amount big.Int
// (optional) MinSettleHeight can extend channel MinSettleHeight if needed
MinSettleHeight abi.ChainEpoch

// (optional) Set of lanes to be merged into Lane
Merges []Merge

// Sender's signature over the voucher
Signature *crypto.Signature
}

package paych

import (
"bytes"

"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/big"
"github.com/filecoin-project/go-state-types/cbor"
"github.com/filecoin-project/go-state-types/exitcode"
paych0 "github.com/filecoin-project/specs-actors/actors/builtin/paych"
"github.com/ipfs/go-cid"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
)

const (
ErrChannelStateUpdateAfterSettled = exitcode.FirstActorSpecificExitCode + iota
)

type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2:                         a.UpdateChannelState,
3:                         a.Settle,
4:                         a.Collect,
}
}

func (a Actor) Code() cid.Cid {
return builtin.PaymentChannelActorCodeID
}

func (a Actor) State() cbor.Er {
return new(State)
}

var _ runtime.VMActor = Actor{}

//type ConstructorParams struct {
//}
type ConstructorParams = paych0.ConstructorParams

// Constructor creates a payment channel actor. See State for meaning of params.
func (pca *Actor) Constructor(rt runtime.Runtime, params *ConstructorParams) *abi.EmptyValue {
// Only InitActor can create a payment channel actor. It creates the actor on
// behalf of the payer/payee.
rt.ValidateImmediateCallerType(builtin.InitActorCodeID)

// check that both parties are capable of signing vouchers
to, err := pca.resolveAccount(rt, params.To)
builtin.RequireNoErr(rt, err, exitcode.Unwrap(err, exitcode.ErrIllegalState), "failed to resolve to address: %s", params.To)
from, err := pca.resolveAccount(rt, params.From)
builtin.RequireNoErr(rt, err, exitcode.Unwrap(err, exitcode.ErrIllegalState), "failed to resolve from address: %s", params.From)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to create empty array")

st := ConstructState(from, to, emptyArrCid)
rt.StateCreate(st)

return nil
}

// Resolves an address to a canonical ID address and requires it to address an account actor.
if err != nil {
}

codeCID, ok := rt.GetActorCodeCID(resolved)
if !ok {
}
if codeCID != builtin.AccountActorCodeID {
return addr.Undef, exitcode.ErrForbidden.Wrapf("actor %v must be an account (%v), was %v", raw,
builtin.AccountActorCodeID, codeCID)
}

return resolved, nil
}

////////////////////////////////////////////////////////////////////////////////
// Payment Channel state operations
////////////////////////////////////////////////////////////////////////////////

// Changed since v0:
// - Proof []byte removed (unused)
type UpdateChannelStateParams struct {
Sv     SignedVoucher
Secret []byte
}

// A voucher is sent by From to To off-chain in order to enable
// To to redeem payments on-chain in the future
//type SignedVoucher struct {
//	// ChannelAddr is the address of the payment channel this signed voucher is valid for
//	// TimeLockMin sets a min epoch before which the voucher cannot be redeemed
//	TimeLockMin abi.ChainEpoch
//	// TimeLockMax sets a max epoch beyond which the voucher cannot be redeemed
//	// TimeLockMax set to 0 means no timeout
//	TimeLockMax abi.ChainEpoch
//	// (optional) The SecretPreImage is used by To to validate
//	SecretPreimage []byte
//	// (optional) Extra can be specified by From to add a verification method to the voucher.
//	Extra *ModVerifyParams
//	// Specifies which lane the Voucher merges into (will be created if does not exist)
//	Lane uint64
//	// Nonce is set by From to prevent redemption of stale vouchers on a lane
//	Nonce uint64
//	// Amount voucher can be redeemed for
//	Amount big.Int
//	// (optional) MinSettleHeight can extend channel MinSettleHeight if needed
//	MinSettleHeight abi.ChainEpoch
//
//	// (optional) Set of lanes to be merged into Lane
//	Merges []Merge
//
//	// Sender's signature over the voucher
//	Signature *crypto.Signature
//}
type SignedVoucher = paych0.SignedVoucher

// Modular Verification method
//type ModVerifyParams struct {
//	// Actor on which to invoke the method.
//	// Method to invoke.
//	Method abi.MethodNum
//	// Pre-serialized method parameters.
//	Params []byte
//}
type ModVerifyParams = paych0.ModVerifyParams

// Specifies which Lanes to be merged with what Nonce on channelUpdate
//type Merge struct {
//	Lane  uint64
//	Nonce uint64
//}
type Merge = paych0.Merge

func (pca Actor) UpdateChannelState(rt runtime.Runtime, params *UpdateChannelStateParams) *abi.EmptyValue {
var st State

// both parties must sign voucher: one who submits it, the other explicitly signs it
rt.ValidateImmediateCallerIs(st.From, st.To)
if rt.Caller() == st.From {
signer = st.To
} else {
signer = st.From
}
sv := params.Sv

if sv.Signature == nil {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher has no signature")
}

if st.SettlingAt != 0 && rt.CurrEpoch() >= st.SettlingAt {
rt.Abortf(ErrChannelStateUpdateAfterSettled, "no vouchers can be processed after SettlingAt epoch")
}

if len(params.Secret) > MaxSecretSize {
rt.Abortf(exitcode.ErrIllegalArgument, "secret must be at most 256 bytes long")
}

vb, err := sv.SigningBytes()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to serialize signedvoucher")

err = rt.VerifySignature(*sv.Signature, signer, vb)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "voucher signature invalid")

if !found {
}
}

if rt.CurrEpoch() < sv.TimeLockMin {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot use this voucher yet!")
}

if sv.TimeLockMax != 0 && rt.CurrEpoch() > sv.TimeLockMax {
rt.Abortf(exitcode.ErrIllegalArgument, "this voucher has expired!")
}

if sv.Amount.Sign() < 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher amount must be non-negative, was %v", sv.Amount)
}

if len(sv.SecretPreimage) > 0 {
hashedSecret := rt.HashBlake2b(params.Secret)
if !bytes.Equal(hashedSecret[:], sv.SecretPreimage) {
rt.Abortf(exitcode.ErrIllegalArgument, "incorrect secret!")
}
}

if sv.Extra != nil {

code := rt.Send(
sv.Extra.Actor,
sv.Extra.Method,
builtin.CBORBytes(sv.Extra.Data),
abi.NewTokenAmount(0),
)
builtin.RequireSuccess(rt, code, "spend voucher verification failed")
}

rt.StateTransaction(&st, func() {
laneFound := true

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load lanes")

// Find the voucher lane, creating if necessary.
laneId := sv.Lane
laneState := findLane(rt, lstates, sv.Lane)

if laneState == nil {
laneState = &LaneState{
Redeemed: big.Zero(),
Nonce:    0,
}
laneFound = false
}

if laneFound {
if laneState.Nonce >= sv.Nonce {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher has an outdated nonce, existing nonce: %d, voucher nonce: %d, cannot redeem",
laneState.Nonce, sv.Nonce)
}
}

// The next section actually calculates the payment amounts to update the payment channel state
// 1. (optional) sum already redeemed value of all merging lanes
redeemedFromOthers := big.Zero()
for _, merge := range sv.Merges {
if merge.Lane == sv.Lane {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher cannot merge lanes into its own lane")
}

otherls := findLane(rt, lstates, merge.Lane)
if otherls == nil {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher specifies invalid merge lane %v", merge.Lane)
return // makes linters happy
}

if otherls.Nonce >= merge.Nonce {
rt.Abortf(exitcode.ErrIllegalArgument, "merged lane in voucher has outdated nonce, cannot redeem")
}

otherls.Nonce = merge.Nonce
err = lstates.Set(merge.Lane, otherls)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to store lane %d", merge.Lane)
}

// 2. To prevent double counting, remove already redeemed amounts (from
// voucher or other lanes) from the voucher amount
laneState.Nonce = sv.Nonce
// 3. set new redeemed value for merged-into lane
laneState.Redeemed = sv.Amount

// 4. check operation validity
if newSendBalance.LessThan(big.Zero()) {
rt.Abortf(exitcode.ErrIllegalArgument, "voucher would leave channel balance negative")
}
if newSendBalance.GreaterThan(rt.CurrentBalance()) {
rt.Abortf(exitcode.ErrIllegalArgument, "not enough funds in channel to cover voucher")
}

// 5. add new redemption ToSend
st.ToSend = newSendBalance

// update channel settlingAt and MinSettleHeight if delayed by voucher
if sv.MinSettleHeight != 0 {
if st.SettlingAt != 0 && st.SettlingAt < sv.MinSettleHeight {
st.SettlingAt = sv.MinSettleHeight
}
if st.MinSettleHeight < sv.MinSettleHeight {
st.MinSettleHeight = sv.MinSettleHeight
}
}

err = lstates.Set(laneId, laneState)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to store lane", laneId)

st.LaneStates, err = lstates.Root()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save lanes")
})
return nil
}

func (pca Actor) Settle(rt runtime.Runtime, _ *abi.EmptyValue) *abi.EmptyValue {
var st State
rt.StateTransaction(&st, func() {
rt.ValidateImmediateCallerIs(st.From, st.To)

if st.SettlingAt != 0 {
}

st.SettlingAt = rt.CurrEpoch() + SettleDelay
if st.SettlingAt < st.MinSettleHeight {
st.SettlingAt = st.MinSettleHeight
}
})
return nil
}

func (pca Actor) Collect(rt runtime.Runtime, _ *abi.EmptyValue) *abi.EmptyValue {
var st State
rt.ValidateImmediateCallerIs(st.From, st.To)

if st.SettlingAt == 0 || rt.CurrEpoch() < st.SettlingAt {
rt.Abortf(exitcode.ErrForbidden, "payment channel not settling or settled")
}

// send ToSend to "To"
codeTo := rt.Send(
st.To,
builtin.MethodSend,
nil,
st.ToSend,
)
builtin.RequireSuccess(rt, codeTo, "Failed to send funds to To")

// the remaining balance will be returned to "From" upon deletion.
rt.DeleteActor(st.From)

return nil
}

// Returns the insertion index for a lane ID, with the matching lane state if found, or nil.
func findLane(rt runtime.Runtime, ls *adt.Array, id uint64) *LaneState {
if id > MaxLane {
rt.Abortf(exitcode.ErrIllegalArgument, "maximum lane ID is 2^63-1")
}

var out LaneState
found, err := ls.Get(id, &out)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load lane %d", id)

if !found {
return nil
}

return &out
}


### Multisig Wallet & ActorState reliableTheory Audit doneEdit this sectionsection-systems.filecoin_token.multisig

The Multisig actor is a single actor representing a group of Signers. Signers may be external users, other Multisigs, or even the Multisig itself. There should be a maximum of 256 signers in a multisig wallet. In case more signers are needed, then the multisigs should be combined into a tree.

The implementation of the Multisig Actor can be found here.

The Multisig Actor statuses can be found here.

## Storage MiningState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining

The Storage Mining System is the part of the Filecoin Protocol that deals with storing Client’s data and producing proof artifacts that demonstrate correct storage behavior.

Storage Mining is one of the most central parts of the Filecoin protocol overall, as it provides all the required consensus algorithms based on proven storage power in the network. Miners are selected to mine blocks and extend the blockchain based on the storage power that they have committed to the network. Storage is added in unit of sectors and sectors are promises to the network that some storage will remain for a promised duration. In order to participate in Storage Mining, the storage miners have to: i) Add storage to the system, and ii) Prove that they maintain a copy of the data they have agreed to throughout the sector’s lifetime.

Storing data and producing proofs is a complex, highly optimizable process, with lots of tunable choices. Miners should explore the design space to arrive at something that (a) satisfies protocol and network-wide constraints, (b) satisfies clients' requests and expectations (as expressed in Deals), and (c) gives them the most cost-effective operation. This part of the Filecoin Spec primarily describes in detail what MUST and SHOULD happen here, and leaves ample room for various optimizations for implementers, miners, and users to make. In some parts, we describe algorithms that could be replaced by other, more optimized versions, but in those cases it is important that the protocol constraints are satisfied. The protocol constraints are spelled out in clear detail. It is up to implementers who deviate from the algorithms presented here to ensure their modifications satisfy those constraints, especially those relating to protocol security.

### SectorState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.sector

Sectors are the basic units of storage on Filecoin. They have standard sizes, as well as well-defined time-increments for commitments. The size of a sector balances security concerns against usability. A sectorʼs lifetime is determined in the storage market, and sets the promised duration of the sector.

In the first iteration of the protocol, 32GiB and 64GiB sectors are supported. Maximum sector lifetime is determined by the proof algorithm. Maximum sector lifetime is initially 18 months. A sector naturally expires when it reaches the end of its lifetime. Additionally, the miner can extend the lifetime of their sectors. Rewards are earned and collaterals recovered when the miner fulfils their commitment.

Individual deals are formed when a storage miner and client are matched on Filecoinʼs storage market. The protocol does not distinguish miners matching with real clients from miners generating self-deals. However, committed capacity is a construction that is introduced to make self-dealing unnecessary and economically irrational. In earlier designs of the network, only sectors filled with deals increased the minerʼs likelihood of winning the block reward. This led to the expectation that miners would attack and exploit the network by playing the role of both storage provider and client, creating a malicious self-deal.

If a sector is only partially full of deals, the network considers the remainder to be committed capacity. Similarly, sectors with no deals are called committed capacity sectors; miners are rewarded for proving to the network that they are pledging storage capacity and are encouraged to find clients who need storage. When a miner finds storage demand, they can upgrade their committed capacity sectors to earn additional revenue in the form of a deal fee from paying clients. More details on how to add storage and upgrade sectors in Adding Storage.

Committed capacity sectors improve minersʼ incentives to store client data, but they donʼt solve the problem entirely. Storing real client files adds some operational overhead for storage miners. In certain circumstances – for example, if a miner values block rewards far more than deal fees – miners might still choose to ignore client data entirely and simply store committed capacity to increase their storage power as rapidly as possible in pursuit of block rewards. This would make Filecoin less useful and limit clientsʼ ability to store data on the network. Filecoin addresses this issue by introducing the concept of verified clients. Verified clients are certified by a decentralized network of verifiers. Once verified, they can post a predetermined amount of verified client deal data to the storage market, set by the size of their DataCap. Sectors with verified client deals are awarded more storage power – and therefore more block rewards – than sectors without. This provides storage miners with an additional incentive to store client data.

Verification is not intended to be scarce – it will be very easy to acquire for anyone with real data to store on Filecoin. Even though verifiers may allocate verified client DataCaps liberally (yet responsibly and transparently) to make onboarding easier, the overall effect should be a dramatic increase in the proportion of useful data stored on Filecoin.

Once a sector is full (either with client data or as committed capacity), the unsealed sector is combined by a proving tree into a single root UnsealedSectorCID. The sealing process then encodes (using CBOR) an unsealed sector into a sealed sector, with the root SealedSectorCID.

This diagram shows the composition of an unsealed sector and a sealed sector.

Sector Storage & Window PoSt

The Lotus implementation of the Window PoSt scheduler can be found here and the actual execution of Window PoSt on a sector can be found here.

The Lotus block store implementation for sectors can be found here.

#### Sector LifecycleState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.sector.lifecycle

Once the sector has been generated and the deal has been incorporated into the Filecoin blockchain, the storage miner begins generating Proofs-of-Spacetime (PoSt) on the sector, starting to potentially win block rewards and also earn storage fees. Parameters are set so that miners generate and capture more value if they guarantee that their sectors will be around for the duration of the original contract. However, some bounds are placed on a sectorʼs lifetime to improve the network performance.

In particular, as sectors of shorter lifetime are added, the networkʼs capacity can be bottlenecked. The reason is that the chainʼs bandwidth is consumed with new sectors only replacing expiring ones. As a result, a minimum sector lifetime of six months was introduced to more effectively utilize chain bandwidth and miners have the incentive to commit to sectors of longer lifetime. The maximum sector lifetime is limited by the security of the present proofs construction. For a given set of proofs and parameters, the security of Filecoinʼs Proof-of-Replication (PoRep) is expected to decrease as sector lifetimes increase.

It is reasonable to assume that miners enter the network by adding Committed Capacity sectors, that is, sectors that do not contain user data. Once miners agree storage deals with clients, they upgrade their sectors to Regular Sectors. Alternatively, if they find Verified Clients and agree a storage deal with them, they upgrade their sector accordingly. Depending on whether or not a sector includes a (verified) deal, the miner acquires the corresponding storage power in the network.

All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination can comes with a corresponding termination fee.

As with every system it is expected that sectors will present faults. Although this might degrade the quality offered by the network, the reaction of the miner to the fault drives system decisions on whether or not the miner should be penalized. If a fault is reported immediately after it is detected by the miner, then the penalty fee is much lower than if the system detects the defect through wrong (or non-existent) PoSt submission.

An adjacent concept to the sector fault is sector recovery, that is, how quickly and if the miner attempts to recover the sector and bring it back to normal operation. Therefore, in case of a faulty sector, a small penalty fee approximately equal to the block reward that the sector would win per day is applied. The fee is calculated per day of the sector being unavailable to the network.

Miners can extend the lifetime of a sector at any time, though the sector will be expected to remain live until it has reached the end of the new sector lifetime. This can be done by submitting a ExtendedSectorExpiration message to the chain.

A sector can be in one of the following states.

StateDescription
PrecommittedMiner seals sector and submits miner.PreCommitSector
CommittedMiner generates a Seal proof and submits miner.ProveCommitSector
ActiveMiner generate valid PoSt proofs and timely submits miner.SubmitWindowedPoSt
FaultyMiner fails to generate a proof (see Fault section)
RecoveringMiner declared a faulty sector via miner.DeclareFaultRecovered
TerminatedEither sector is expired, or early terminated by a miner via miner.TerminateSectors, or was failed to be proven for 14 consecutive proving periods.

#### Sector QualityState stableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.sector.sector-quality

Given different sector contents, not all sectors have the same usefulness to the network. The notion of Sector Quality distinguishes between sectors with heuristics indicating the presence of valuable data. That distinction is used to allocate more subsidies to higher-quality sectors. To quantify the contribution of a sector to the consensus power of the network, some relevant parameters are described here.

• Sector Spacetime: This measurement is the sector size multiplied by its promised duration in byte-epochs.
• Deal Weight: This weight converts spacetime occupied by deals into consensus power. Deal weight of verified client deals in a sector is called Verified Deal Weight and will be greater than the regular deal weight.
• Deal Quality Multiplier: This factor is assigned to different deal types (committed capacity, regular deals, and verified client deals) to reward different content.
• Sector Quality Multiplier: Sector quality is assigned on Activation (the epoch when the miner starts proving theyʼre storing the file). The sector quality multiplier is computed as an average of deal quality multipliers (committed capacity, regular deals, and verified client deals), weighted by the amount of spacetime each type of deal occupies in the sector.
$SectorQualityMultiplier = \frac{\sum\nolimits_{deals} DealWeight * DealQualityMultiplier}{SectorSpaceTime}$
• Raw Byte Power: This measurement is the size of a sector in bytes.
• Quality-Adjusted Power: This parameter measures the consensus power of stored data on the network, and is equal to Raw Byte Power multiplied by Sector Quality Multiplier.

The multipliers for committed capacity and regular deals are equal to make self dealing irrational in the current configuration of the protocol. In the future, it may make sense to pick different values, depending on other ways of preventing attacks becoming available.

The high quality multiplier and easy verification process for verified client deals facilitates decentralization of miner power. Unlike other proof-of-work-based protocols, like Bitcoin, central control of the network is not simply decided based on the resources that a new participant can bring. In Filecoin, accumulating control either requires significantly more resources or some amount of consent from verified clients, who must make deals with the centralized miners for them to increase their influence. Verified client mechanisms add a layer of social trust to a purely resource driven network. As long as the process is fair and transparent with accountability and bounded trust, abuse can be contained and minimized. A high sector quality multiplier is a very powerful leverage for clients to push storage providers to build features that will be useful to the network as a whole and increase the networkʼs long-term value. The verification process and DataCap allocation are meant to evolve over time as the community learns to automate and improve this process. An illustration of sectors with various contents and their respective sector qualities are shown in the following Figure.

Sector Quality Adjusted Power is a weighted average of the quality of its space and it is based on the size, duration and quality of its deals.

NameDescription
QualityBaseMultiplier (QBM)Multiplier for power for storage without deals.
DealWeightMultiplier (DWM)Multiplier for power for storage with deals.
VerifiedDealWeightMultiplier (VDWM)Multiplier for power for storage with verified deals.

The formula for calculating Sector Quality Adjusted Power (or QAp, often referred to as power) makes use of the following factors:

• dealSpaceTime: sum of the duration*size of each deal
• verifiedSpaceTime: sum of the duration*size of each verified deal
• baseSpaceTime (spacetime without deals): sectorSize*sectorDuration - dealSpaceTime - verifiedSpaceTime

Based on these the average quality of a sector is:

$avgQuality = \frac{baseSpaceTime*QBM + dealSpaceTime*DWM + verifiedSpaceTime*VDWM}{sectorSize*sectorDuration*QBM}$

The Sector Quality Adjusted Power is:

$sectorQuality = avgQuality*size$

During miner.PreCommitSector, the sector quality is calculated and stored in the sector information.

#### Sector SealingState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.sealing

Before a Sector can be used, the Miner must seal the Sector: encode the data in the Sector to prepare it for the proving process.

• Unsealed Sector: A Sector of raw data.
• UnsealedCID (CommD): The root hash of the Unsealed Sector’s merkle tree. Also called CommD, or “data commitment.”
• Sealed Sector: A Sector that has been encoded to prepare it for the proving process.
• SealedCID (CommR): The root hash of the Sealed Sector’s merkle tree. Also called CommR, or “replica commitment.”

Sealing a sector through Proof-of-Replication (PoRep) is a computation-intensive process that results in a unique encoding of the sector. Once data is sealed, storage miners: generate a proof; run a SNARK on the proof to compress it; and finally, submit the result of the compression to the blockchain as a certification of the storage commitment. Depending on the PoRep algorithm and protocol security parameters, cost profiles and performance characteristics vary and tradeoffs have to be made among sealing cost, security, onchain footprint, retrieval latency and so on. However, sectors can be sealed with commercial hardware and sealing cost is expected to decrease over time. The Filecoin Protocol will launch with Stacked Depth Robust (SDR) PoRep with a planned upgrade to Narrow Stacked Expander (NSE) PoRep with improvement in both cost and retrieval latency.

The Lotus-specific set of functions applied to the sealing of a sector can be found here.

##### RandomnessState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.sealing.randomness

Randomness is an important attribute that helps the network verify the integrity of Miners' stored data. Filecoin’s block creation process includes two types of randomness:

• DRAND: Values pulled from a distributed random beacon
• VRF: The output of a Verifiable Random Function (VRF), which takes the previous block’s VRF value and produces the current block’s VRF value.

Each block produced in Filecoin includes values pulled from these two sources of randomness.

When Miners submit proofs about their stored data, the proofs incorporate references to randomness added at specific epochs. Assuming these values were not able to be predicted ahead of time, this helps ensure that Miners generated proofs at a specific point in time.

There are two proof types. Each uses one of the two sources of randomness:

• Windowed PoSt: Uses Drand values
• Proof of Replication (PoRep): Uses VRF values
##### Drawing randomness for sector commitmentsState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.sealing.drawing-randomness-for-sector-commitments

Tickets are used as input to calculation of the ReplicaID in order to tie Proofs-of-Replication to a given chain, thereby preventing long-range attacks (from another miner in the future trying to reuse SEALs).

The ticket has to be drawn from a finalized block in order to prevent the miner from potential losing storage (in case of a chain reorg) even though their storage is intact.

Verification should ensure that the ticket was drawn no farther back than necessary by the miner. We note that tickets can uniquely be associated with a given round in the protocol (lest a hash collision be found), but that the round number is explicited by the miner in commitSector.

We present precisely how ticket selection and verification should work. In the below, we use the following notation:

• F– Finality (number of rounds)
• X– round in which SEALing starts
• Z– round in which the SEAL appears (in a block)
• Y– round announced in the SEAL commitSector (should be X, but a miner could use any Y <= X), denoted by the ticket selection
• T– estimated time for SEAL, dependent on sector size
• G = T + variance– necessary flexibility to account for network delay and SEAL-time variance.

We expect Filecoin will be able to produce estimates for sector commitment time based on sector sizes, e.g.: (estimate, variance) <--- SEALTime(sectors) G and T will be selected using these.

Picking a Ticket to Seal: When starting to prepare a SEAL in round X, the miner should draw a ticket from X-F with which to compute the SEAL.

Verifying a Seal’s ticket: When verifying a SEAL in round Z, a verifier should ensure that the ticket used to generate the SEAL is found in the range of rounds [Z-T-F-G, Z-T-F+G].

                               Prover
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│

▼
X-F ◀───────F────────▶ X ◀──────────T─────────▶ Z
-G   .  +G                 .                        .
───(┌───────┐)───────────────( )──────────────────────( )────────▶
└───────┘                 '                        '        time
[Z-T-F-G, Z-T-F+G]
▲

└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
Verifier


Note that the prover here is submitting a message on chain (i.e. the SEAL). Using an older ticket than necessary to generate the SEAL is something the miner may do to gain more confidence about finality (since we are in a probabilistically final system). However it has a cost in terms of securing the chain in the face of long-range attacks (specifically, by mixing in chain randomness here, we ensure that an attacker going back a month in time to try and create their own chain would have to completely regenerate any and all sectors drawing randomness since to use for their fork’s power).

We break this down as follows:

• The miner should draw from X-F.
• The verifier wants to find what X-F should have been (to ensure the miner is not drawing from farther back) even though Y (i.e. the round of the ticket actually used) is an unverifiable value.
• Thus, the verifier will need to make an inference about what X-F is likely to have been based on:
• (known) round in which the message is received (Z)
• (known) finality value (F)
• (approximate) SEAL time (T)
• Because T is an approximate value, and to account for network delay and variance in SEAL time across miners, the verifier allows for G offset from the assumed value of X-F: Z-T-F, hence verifying that the ticket is drawn from the range [Z-T-F-G, Z-T-F+G].

In Practice, the Filecoin protocol will include a MAX_SEAL_TIME for each sector size and proof type.

#### Sector FaultsState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.sector-faults

It is very important for storage providers to have a strong incentive to both report the failure to the chain and attempt recovery from the fault in order to uphold the storage guarantee for the networkʼs clients. Without this incentive, it is impossible to distinguish an honest minerʼs hardware failure from malicious behavior, which is necessary to treat miners fairly. The size of the fault fees depend on the severity of the failure and the rewards that the miner is expected to earn from the sector to make sure incentives are aligned. The three types of sector storage fault fees are:

• Sector fault fee: This fee is paid per sector per day while the sector is in a faulty state. The size of the fee is slightly more than the amount the sector is expected to earn per day in block rewards. If a sector remains faulty for more than 2 consecutive weeks, the sector will pay a termination fee and be removed from the chain state. As storage miner reliability increases above a reasonable threshold, the risk posed by these fees decreases rapidly.
• Sector fault detection fee: This is a one-time fee paid in the event of a failure if the miner does not report it honestly and instead the unreported failure is caught by the chain. Given the probabilistic nature of our PoSt checks, this is set to a few days worth of block reward that would be expected to be earned by a particular sector.
• Sector termination fee: A sector can be terminated before its expiration through automatic faults or miner decisions. A termination fee is charged that is, in principle, equivalent to how much a sector has earned so far, up to a limit in order to avoid discouraging long sector lifetimes. In an active termination, the miner decides to stop mining and they pay a fee to leave. In a fault termination, a sector is in a faulty state for too long, and the chain terminates the deal, returns unpaid deal fees to the client and penalizes the miner. Termination fee is currently capped at 90 days worth of block reward that a sector will earn. Miners are responsible for deciding to comply with local regulations, and may sometimes need to accept a termination fee for complying with content laws. Many of the concepts and parameters above make use of the notion of “how much a sector would have earned in a day” in order to understand and align incentives for participants. This concept is robustly tracked and extrapolated on chain.

#### Sector RecoveryState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.sector-recovery

Miners should try to recover faulty sectors in order to avoid paying the penalty, which is approximately equal to the block reward that the miner would receive from that sector. After fixing technical issues, the miner should call RecoveryDeclaration and produce the WindowPoSt challenge in order to regain the power from that sector.

Note that if a sector is in a faulty state for 14 consecutive days it will be terminated and the miner will receive a penalty. The miner can terminate the sector themselves by calling TerminationDeclaration, if they know that they cannot recover it, in which case they will receive a smaller penalty fee.

Both the RecoveryDeclaration and the TerminationDeclaration can be found in the miner actor implementation.

#### Adding StorageState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.adding_storage

A Miner adds more storage in the form of Sectors. Adding more storage is a two-step process:

1. PreCommitting a Sector: A Miner publishes a Sector’s SealedCID and makes a deposit. The Sector is now registered to the Miner, and the Miner must ProveCommit the Sector or lose their deposit.
2. ProveCommitting a Sector: The Miner provides a Proof of Replication (PoRep) for the Sector. This proof must be submitted AFTER a delay (the InteractiveEpoch), and BEFORE PreCommit expiration.

This two-step process provides assurance that the Miner’s PoRep actually proves that the Miner has replicated the Sector data and is generating proofs from it:

• ProveCommitments must happen AFTER the InteractiveEpoch (150 blocks after Sector PreCommit), as the randomness included at that epoch is used in the PoRep.
• ProveCommitments must happen BEFORE the PreCommit expiration, which is a boundary established to make sure Miners don’t have enough time to “fake” PoRep generation.

For each Sector successfully ProveCommitted, the Miner becomes responsible for continuously proving the existence of their Sectors' data. In return, the Miner is awarded storage power.

#### Upgrading SectorsState stableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.sector.adding_storage

Miners are granted storage power in exchange for the storage space they dedicate to Filecoin. Ideally, this storage space is used to store data on behalf of Clients, but there may not always be enough Clients to utilize all the space a Miner has to offer.

In order for a Miner to maximize storage power (and profit), they should take advantage of all available storage space immediately, even before they find enough Clients to use this space.

To facilitate this, there are two types of Sectors that may be sealed and ProveCommitted:

• Regular Sector: A Sector that contains Client data
• Committed Capacity (CC) Sector: A Sector with no data (all zeroes)

Miners are free to coose which types of Sectors to store. CC sectors, in particular, allow Miners to immediately make use of existing disk space: earning storage power and a higher chance at producing a block. Miners can decide if they should upgrade their CC sectors to take client deals or continue proving CC sectors. Currently, CC sectors store randomness by default in client implementation, but this does not preclude miners from storing any type of useful data that increase their private utility in CC sectors (as long as it is legal). The protocol expects that new use-cases and diversity will emerge out of such behaviour.

To incentivize Miners to hoard storage space and dedicate it to Filecoin, CC Sectors have a unique capability: they can be “upgraded” to Regular Sectors (also called “replacing a CC Sector”).

Miners upgrade their ProveCommitted CC Sectors by PreCommitting a Regular Sector, and specifying that it should replace an existing CC Sector. Once the Regular Sector is successfully ProveCommitted, it will replace the existing CC Sector. If the newly ProveCommitted Regular sector contains a Verified Client deal, i.e., a deal with higher Sector Quality, then the miner’s storage power will increase accordingly.

Upgrading capacity currently involves resealing, that is, creating a unique representation of the new data included in the Sector through a computationally intensive process. Looking ahead, committed capacity upgrades should eventually be possible without a reseal. A succinct and publicly verifiable proof that the committed capacity has been correctly replaced with replicated data should achieve this goal. However, this mechanism must be fully specified to preserve the security and incentives of the network before it can be implemented and is, therefore, left as a future improvement.

### Storage MinerState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining

#### Storage Mining SubsystemState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.storage-mining-subsystem

The Filecoin Storage Mining Subsystem ensures a storage miner can effectively commit storage to the Filecoin protocol in order to both:

• Participate in the Filecoin Storage Market by taking on client data and participating in storage deals.
• Participate in Filecoin Storage Power Consensus by verifying and generating blocks to grow the Filecoin blockchain and earning block rewards and fees for doing so.

The above involves a number of steps to putting on and maintaining online storage, such as:

#### Filecoin ProofsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.filecoin-proofs

##### Proof of ReplicationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.proof-of-replication

A Proof of Replication (PoRep) is a proof that a Miner has correctly generated a unique replica of some underlying data.

In practice, the underlying data is the raw data contained in an Unsealed Sector, and a PoRep is a SNARK proof that the sealing process was performed correctly to produce a Sealed Sector (See Sealing a Sector).

It is important to note that the replica should not only be unique to the miner, but also to the time when a miner has actually created the replica, i.e., sealed the sector. This means that if the same miner produces a sealed sector out of the same raw data twice, then this would count as a different replica.

When Miners commit to storing data, they must first produce a valid Proof of Replication.

##### Proof of SpacetimeState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.proof-of-spacetime

A Proof of Spacetime (aka PoSt) is a long-term assurance of a Miner’s continuous storage of their Sectors' data. This is not a single proof, but a collection of proofs the Miner has submitted over time. Periodically, a Miner must add to these proofs by submitting a WindowPoSt:

• Fundamentally, a WindowPoSt is a collection of merkle proofs over the underlying data in a Miner’s Sectors.
• WindowPoSts bundle proofs of various leaves across groups of Sectors (called Partitions).
• These proofs are submitted as a single SNARK.

The historical and ongoing submission of WindowPoSts creates assurance that the Miner has been storing, and continues to store the Sectors they agreed to store in the storage deal.

Once a Miner successfully adds and ProveCommits a Sector, the Sector is assigned to a Deadline: a specific window of time during which PoSts must be submitted. The day is broken up into 48 individual Deadlines of 30 minutes each, and ProveCommitted Sectors are assigned to one of these 48 Deadlines.

• PoSts may only be submitted for the currently-active Deadline. Deadlines are open for 30 minutes, starting from the Deadline’s “Open” epoch and ending at its “Close” epoch.
• PoSts must incorporate randomness pulled from a random beacon. This randomness becomes publicly available at the Deadline’s “Challenge” epoch, which is 20 epochs prior to its “Open” epoch.
• Deadlines also have a FaultCutoff epoch, 70 epochs prior to its “Open” epoch. After this epoch, Faults can no longer be declared for the Deadline’s Sectors.

#### Miner AccountingState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.miner-accounting

A Miner’s financial gain or loss is affected by the following three actions:

1. Miners deposit tokens to act as collateral for their PreCommitted and ProveCommitted Sectors
2. Miners earn tokens from block rewards, when they are elected to mine a new block and extend the blockchain.
3. Miners lose tokens if they fail to prove storage of a sector and are given penalties as a result.
##### Balance RequirementsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.balance-requirements

A Miner’s token balance MUST cover ALL of the following:

• PreCommit Deposits: When a Miner PreCommits a Sector, they must supply a “precommit deposit” for the Sector, which acts as collateral. If the Sector is not ProveCommitted on time, this deposit is removed and burned.
• Initial Pledge: When a Miner ProveCommits a Sector, they must supply an “initial pledge” for the Sector, which acts as collateral. If the Sector is terminated, this deposit is removed and burned along with rewards earned by this sector up to a limit.
• Locked Funds: When a Miner receives tokens from block rewards, the tokens are locked and added to the Miner’s vesting table to be unlocked linearly over some future epochs.
##### Faults, Penalties and Fee DebtState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.faults-penalties-and-fee-debt

Faults

A Sector’s PoSts must be submitted on time, or that Sector is marked “faulty.” There are three types of faults:

• Declared Fault: When the Miner explicitly declares a Sector “faulty” before its Deadline’s FaultCutoff. Recall that WindowPoSt proofs are submitted per partition for a specific ChallengeWindow. A miner has to declare the sector as faulty before the ChallengeWindow for the particular partition opens. Until the sectors are recovered they will be masked from proofs in subsequent proving periods.
• Detected Fault: Partitions of sectors without PoSt proof verification records, which have not been declared faulty before the FaultCutoff epoch’s deadline are marked as detected faults.
• Skipped Fault: If a sector is currently in active or recovering state and has not been declared faulty before, but the miner’s PoSt submission does not include a proof for this sector, then this is a “skipped fault” sector (also referred to as “skipped undeclared fault”). In other words, when a miner submits PoSt proofs for a partition but does not include proofs for some sectors in the partition, then these sectors are in “skipped fault” state. This is in contrast to the “detected fault” state, where the miner does not submit a PoSt proof for any section in the partition at all. The skipped fault is helpful in case a sector becomes faulty after the FaultCutoff epoch.

Note that the “skipped fault” allows for sector-wise fault penalties, as compared to partition-wide faults and penalties, as is the case with “detected faults”.

A deadline is a period of WPoStChallengeWindow epochs that divides a proving period. Sectors are assigned to a deadline on miner.ProveCommitSector and will remain assigned to it throughout their lifetime. Recall that Sectors are also assigned to a partition.

A miner must submit a miner.SubmitWindowedPoSt for each deadline.

There are four relevant epochs associated to a deadline:

NameDistance from OpenDescription
Open0Epoch from which a PoSt Proof for this deadline can be submitted.
CloseWPoStChallengeWindowEpoch after which a PoSt Proof for this deadline will be rejected.
FaultCutoff-FaultDeclarationCutoffEpoch after which a miner.DeclareFault and miner.DeclareFaultRecovered for sectors in the upcoming deadline are rejected.
Challenge-WPoStChallengeLookbackEpoch at which the randomness for the challenges is available.

Fault Recovery

Regardless of how a fault first becomes known (declared, skipped, detected), the sector stays faulty and is excluded from future proofs until the miner explicitly declares it recovered. The declaration of recovery restores the sector to the proving set at the start of the subsequent proving period. When a PoSt for a just-recovered sector is received, power for that sector is restored.

Penalties

A Miner may accrue penalties for many reasons:

• PreCommit Expiry Penalty: Occurs if a Miner fails to ProveCommit a PreCommitted Sector in time. This happens the first time that a miner declares that it proves a sector and falls into the PoRep consensus.
• Undeclared Fault Penalty: Occurs if a Miner fails to submit a PoSt for a Sector on time. Depending on whether the “Skipped Fault” option is implemented, this penalty applies to either a sector or a whole partition.
• Declared Fault Penalty: Occurs if a Miner fails to submit a PoSt for a Sector on time, but they declare the Sector faulty before the system finds out (in which case the fault falls in the “Undeclared Fault Penalty” above). This penalty fee should be lower than the undeclared fault penalty, in order to incentivize Miners to declare faults early.
• Ongoing Fault Penalty: Occurs every Proving Period a Miner fails to submit a PoSt for a Sector.
• Termination Penalty: Occurs if a Sector is terminated before its expiration.
• Consensus Fault Penalty: Occurs if a Miner commits a consensus fault and is reported.

When a Miner accrues penalties, the amount penalized is tracked as “Fee Debt.” If a Miner has Fee Debt, they are restricted from certain actions until the amount owed is paid off. Miners with Fee Debt may not:

• PreCommit new Sectors
• Declare faulty Sectors “recovered”
• Withdraw balance

Faults are implied to be “temporary” - that is, a Miner that temporarily loses internet connection may choose to declare some Sectors for their upcoming proving period as faulty, because the Miner knows they will eventually regain the ability to submit proofs for those Sectors. This declaration allows the Miner to still submit a valid proof for their Deadline (minus the faulty Sectors). This is very important for Miners, as missing a Deadline’s PoSt entirely incurs a high penalty.

#### Storage Mining CycleState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle

Block miners should constantly, on every epoch, be checking if they win the Secret Leader Election and in case they are elected, determine whether they can propose a block by running the Winning PoSt. Epochs are currently set to take 30 seconds, in order to account for Winning PoSt and network propagation around the world. The detailed steps for the above process can be found in the Secret Leader Election section.

Here we provide a detailed description of the mining cycle.

##### Active Miner Mining CycleState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.active-miner-mining-cycle

In order to mine blocks on the Filecoin blockchain a miner must be running Block Validation at all times, keeping track of recent blocks received and the heaviest current chain (based on Expected Consensus).

With every new tipset, the miner can use their committed power to attempt to craft a new block.

For additional details around how consensus works in Filecoin, see Expected Consensus. For the purposes of this section, there is a consensus protocol (Expected Consensus) that guarantees a fair process for determining what blocks have been generated in a round, whether a miner is eligible to mine a block, and other rules pertaining to the production of some artifacts required of valid blocks (e.g. Tickets, WinningPoSt).

###### Mining CycleState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.mining-cycle

After the chain has caught up to the current head using ChainSync, the mining process is as follows, (we go into more detail on epoch timing below):

• The node receives and transmits messages using the Message Syncer
• At the same time the node receives blocks through BlockSync.
• Each block has an associated timestamp and epoch (quantized time window in which it was crafted)
• Blocks are validated as they come in block validation
• After an epoch’s “cutoff”, the miner should take all the valid blocks received for this epoch and assemble them into tipsets according to Tipset validation rules
• The miner then attempts to mine atop the heaviest tipset (as calculated with EC’s weight function) using its smallest ticket to run leader election
• The miner runs Leader Election using the most recent random output by a drand beacon.
• if this yields a valid ElectionProof, the miner generates a new ticket and winning PoSt for inclusion in the block.
• the miner then assembles a new block (see “block creation” below) and waits until this epoch’s quantized timestamp to broadcast it

This process is repeated until either the Leader Election process yields a winning ticket (in EC) and the miner publishes a block or a new valid block comes in from the network.

At any height H, there are three possible situations:

• The miner is eligible to mine a block: they produce their block and propagate it. They then resume mining at the next height H+1.
• The miner is not eligible to mine a block but has received blocks: they form a Tipset with them and resume mining at the next height H+1.
• The miner is not eligible to mine a block and has received no blocks: prompted by their clock they run leader election again, incrementing the epoch number.

Anytime a miner receives new valid blocks, it should evaluate what is the heaviest Tipset it knows about and mine atop it.

###### Epoch TimingState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.epoch-timing

The timing diagram above describes the sequence of block creation “mining”, propagation and reception.

This sequence of events applies only when the node is in the CHAIN_FOLLOW syncing mode. Nodes in other syncing modes do not mine blocks.

The upper row represents the conceptual consumption channel consisting of successive receiving periods Rx during which nodes validate incoming blocks. The lower row is the conceptual production channel made up of a period of mining M followed by a period of transmission Tx (which lasts long enough for blocks to propagate throughout the network). The lengths of the periods are not to scale.

The above diagram represents the important events within an epoch:

• Epoch boundary: change of current epoch. New blocks mined are mined in new epoch, and timestamped accordingly.
• Epoch cutoff: blocks from the prior epoch propagated on the network are no longer accepted. Miners can form a new tipset to mine on.

In an epoch, blocks are received and validated during Rx up to the prior epoch’s cutoff. At the cutoff, the miner computes the heaviest tipset from the blocks received during Rx, and uses it as the head to build on during the next mining period M. If mining is successful, the miner sets the block’s timestamp to the epoch boundary and waits until the boundary to release the block. While some blocks could be submitted a bit later, blocks are all transmitted during Tx, the transmission period.

The timing validation rules are as follows:

• Blocks whose timestamps are not exactly on the epoch boundary are rejected.
• Blocks received with a timestamp in the future are rejected.
• Blocks received after the cutoff are rejected.
• Note that those blocks are not invalid, just not considered for the miner’s own tipset building. Tipsets received with such a block as a parent should be accepted.

In a fully synchronized network most of period Rx does not see any network traffic, only its beginning should. While there may be variance in operator mining time, most miners are expected to finish mining by the epoch boundary.

Let’s look at an example, both use a block-time of 30s, and a cutoff at 15s.

• T = 0: start of epoch n
• T in [0, 15]: miner A receives, validates and propagates incoming blocks. Valid blocks should have timestamp 0.
• T = 15: epoch cutoff for n-1, A assembles the heaviest tipset and starts mining atop it.
• T = 25: A successfully generates a block, sets its timestamp to 30, and waits until the epoch boundary (at 30) to release it.
• T = 30: start of epoch n + 1, A releases its block for epoch n.
• T in [30, 45]: A receives and validates incoming blocks, their timestamp is 30.
• T = 45: epoch cutoff for n, A forms tipsets and starts mining atop the heaviest.
• T = 60: start of epoch n + 2.
• T in [60, 75]: A receives and validates incoming blocks
• T = 67: A successfully generates a block, sets it timestamp to 60 and releases it.
• T = 75: epoch cutoff for n+1…

Above, in epoch n, A mines fast, in epoch n+1 A mines slow. So long as the miner’s block is between the epoch boundary and the cutoff, it will be accepted by other miners.

In practice miners should not be releasing blocks close to the epoch cutoff. Implementations may choose to locally randomize the exact time of the cutoff in order to prevent such behavior (while this means it may accept/reject blocks others do not, in practice this will not affect the miners submitting blocks on time).

##### Full Miner LifecycleState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.full-miner-lifecycle
###### Step 0: Registration and Market participationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.step-0-registration-and-market-participation

To initially become a miner, a miner first registers a new miner actor on-chain. This is done through the storage power actor’s CreateStorageMiner method. The call will then create a new miner actor instance and return its address.

The next step is to place one or more storage market asks on the market. This is done off-chain as part of storage market functions. A miner may create a single ask for their entire storage, or partition their storage up in some way with multiple asks (at potentially different prices).

After that, they need to make deals with clients and begin filling up sectors with data. For more information on making deals, see the Storage Market. The miner will need to put up storage deal collateral for the deals they have entered into.

When they have a full sector, they should seal it. This is done by invoking the Sector Sealer.

Owner/Worker distinction

The miner actor has two distinct ‘controller’ addresses. One is the worker, which is the address which will be responsible for doing all of the work, submitting proofs, committing new sectors, and all other day to day activities. The owner address is the address that created the miner, paid the collateral, and has block rewards paid out to it. The reason for the distinction is to allow different parties to fulfil the different roles. One example would be for the owner to be a multisig wallet, or a cold storage key, and the worker key to be a ‘hot wallet’ key.

Note that any change to worker keys after registration must be appropriately delayed in relation to randomness lookback for SEALing data (see this issue).

###### Step 1: Committing SectorsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.step-1-committing-sectors

When the miner has completed their first seal, they should post it on-chain using the Storage Miner Actor’s ProveCommitSector function. The miner will need to put up pledge collateral in proportion to the amount of storage they commit on chain. The miner will now gain power for this particular sector upon successful ProveCommitSector.

You can read more about sectors here and how sector relates to power here.

###### Step 2: Producing BlocksState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.step-2-producing-blocks

Once the miner has power on the network, they are randomly chosen by the “Secret Leader Election” algorithm to mine and submit blocks proportionally to the power they hold, i.e., if a miner holds 3% of the overall network power they will be chosen in 3% of the cases. The winning miner is chosen by the system and the miner can prove that they were chosen by submitting an Election Proof.

When a miner is chosen to produce a block, they must submit a WinningPoSt proof. This process is as follows: an elected miner gets the randomness value through the DRAND randomness generator based on the current epoch and uses it to generate WinningPoSt.

WinningPoSt uses the randomness to select a sector for which the miner must generate a proof. If the miner is not able to generate this proof within some predefined amount of time, then they will not be able to create a block.

###### FaultsState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.faults

If a miner detects Storage Faults among their sectors (any sort of storage failure that would prevent them from crafting a PoSt), they should declare these faults as discussed earlier.

The miner will be unable to craft valid PoSt proofs over faulty sectors, thereby reducing their chances of being able to create a valid block (i.e., adding a Winning PoSt). By declaring a fault, the miner will no longer be challenged on that sector, and will lose power accordingly.

###### Step 3: Deal/Sector ExpirationState reliableTheory Audit wipEdit this sectionsection-systems.filecoin_mining.storage_mining.mining_cycle.step-3-dealsector-expiration

In order to stop mining, a miner must complete all of its storage deals. Once all deals in a sector have expired, the sector itself will expire thereby enabling the miner to remove the associated collateral from their account.

#### Storage Miner ActorState wipTheory Audit doneEdit this sectionsection-systems.filecoin_mining.storage_mining.storage_miner_actor

Balance of Miner Actor should be greater than or equal to the sum of PreCommitDeposits and LockedFunds. It is possible for balance to fall below the sum of PCD, LF and InitialPledgeRequirements, and this is a bad state (IP Debt) that limits a miner actor’s behavior (i.e. no balance withdrawals) Excess balance as computed by st.GetAvailableBalance will be withdrawable or usable for pre-commit deposit or pledge lock-up.
type State struct {
// Information not related to sectors.
Info cid.Cid

PreCommitDeposits abi.TokenAmount // Total funds locked as PreCommitDeposits
LockedFunds       abi.TokenAmount // Total rewards and added funds locked in vesting table

VestingFunds cid.Cid // VestingFunds (Vesting Funds schedule for the miner).

FeeDebt abi.TokenAmount // Absolute value of debt this miner owes from unpaid fees

InitialPledge abi.TokenAmount // Sum of initial pledge requirements of all active sectors

// Sectors that have been pre-committed but not yet proven.
PreCommittedSectors cid.Cid // Map, HAMT[SectorNumber]SectorPreCommitOnChainInfo

// PreCommittedSectorsExpiry maintains the state required to expire PreCommittedSectors.
PreCommittedSectorsExpiry cid.Cid // BitFieldQueue (AMT[Epoch]*BitField)

// Allocated sector IDs. Sector IDs can never be reused once allocated.
AllocatedSectors cid.Cid // BitField

// Information for all proven and not-yet-garbage-collected sectors.
//
// Sectors are removed from this AMT when the partition to which the
// sector belongs is compacted.
Sectors cid.Cid // Array, AMT[SectorNumber]SectorOnChainInfo (sparse)

// The first epoch in this miner's current proving period. This is the first epoch in which a PoSt for a
// partition at the miner's first deadline may arrive. Alternatively, it is after the last epoch at which
// a PoSt for the previous window is valid.
// Always greater than zero, this may be greater than the current epoch for genesis miners in the first
// WPoStProvingPeriod epochs of the chain; the epochs before the first proving period starts are exempt from Window
// PoSt requirements.
// Updated at the end of every period by a cron callback.
ProvingPeriodStart abi.ChainEpoch

// Index of the deadline within the proving period beginning at ProvingPeriodStart that has not yet been
// finalized.
// Updated at the end of each deadline window by a cron callback.

// The sector numbers due for PoSt at each deadline in the current proving period, frozen at period start.
// New sectors are added and expired ones removed at proving period boundary.
// Faults are not subtracted from this in state, but on the fly.

// Deadlines with outstanding fees for early sector termination.
EarlyTerminations bitfield.BitField
}

package miner

import (
"bytes"
"encoding/binary"
"fmt"
"math"

"github.com/filecoin-project/go-bitfield"
"github.com/filecoin-project/go-state-types/abi"
"github.com/filecoin-project/go-state-types/big"
"github.com/filecoin-project/go-state-types/cbor"
"github.com/filecoin-project/go-state-types/crypto"
"github.com/filecoin-project/go-state-types/dline"
"github.com/filecoin-project/go-state-types/exitcode"
"github.com/filecoin-project/go-state-types/network"
rtt "github.com/filecoin-project/go-state-types/rt"
miner0 "github.com/filecoin-project/specs-actors/actors/builtin/miner"
cid "github.com/ipfs/go-cid"
cbg "github.com/whyrusleeping/cbor-gen"
"golang.org/x/xerrors"

"github.com/filecoin-project/specs-actors/v2/actors/builtin"
"github.com/filecoin-project/specs-actors/v2/actors/builtin/market"
"github.com/filecoin-project/specs-actors/v2/actors/builtin/power"
"github.com/filecoin-project/specs-actors/v2/actors/builtin/reward"
"github.com/filecoin-project/specs-actors/v2/actors/runtime"
"github.com/filecoin-project/specs-actors/v2/actors/runtime/proof"
. "github.com/filecoin-project/specs-actors/v2/actors/util"
"github.com/filecoin-project/specs-actors/v2/actors/util/smoothing"
)

type Runtime = runtime.Runtime

const (
// The first 1000 actor-specific codes are left open for user error, i.e. things that might
// actually happen without programming error in the actor code.
//ErrToBeDetermined = exitcode.FirstActorSpecificExitCode + iota

// The following errors are particular cases of illegal state.
// They're not expected to ever happen, but if they do, distinguished codes can help us
// diagnose the problem.
ErrBalanceInvariantBroken = 1000
)

type Actor struct{}

func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
4:                         a.ChangePeerID,
5:                         a.SubmitWindowedPoSt,
6:                         a.PreCommitSector,
7:                         a.ProveCommitSector,
8:                         a.ExtendSectorExpiration,
9:                         a.TerminateSectors,
10:                        a.DeclareFaults,
11:                        a.DeclareFaultsRecovered,
12:                        a.OnDeferredCronEvent,
13:                        a.CheckSectorProven,
14:                        a.ApplyRewards,
15:                        a.ReportConsensusFault,
16:                        a.WithdrawBalance,
17:                        a.ConfirmSectorProofsValid,
19:                        a.CompactPartitions,
20:                        a.CompactSectorNumbers,
21:                        a.ConfirmUpdateWorkerKey,
22:                        a.RepayDebt,
}
}

func (a Actor) Code() cid.Cid {
return builtin.StorageMinerActorCodeID
}

func (a Actor) State() cbor.Er {
return new(State)
}

var _ runtime.VMActor = Actor{}

/////////////////
// Constructor //
/////////////////

// Storage miner actors are created exclusively by the storage power actor. In order to break a circular dependency
// between the two, the construction parameters are defined in the power actor.
type ConstructorParams = power.MinerConstructorParams

func (a Actor) Constructor(rt Runtime, params *ConstructorParams) *abi.EmptyValue {

if !CanPreCommitSealProof(params.SealProofType, rt.NetworkVersion()) {
rt.Abortf(exitcode.ErrIllegalArgument, "proof type %d not allowed for new miner actors", params.SealProofType)
}

for _, ca := range params.ControlAddrs {
}

if err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to construct initial state: %v", err)
}

if err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to construct initial state: %v", err)
}

emptyBitfield := bitfield.NewFromSet(nil)
emptyBitfieldCid := rt.StorePut(emptyBitfield)

emptyVestingFunds := ConstructVestingFunds()
emptyVestingFundsCid := rt.StorePut(emptyVestingFunds)

currEpoch := rt.CurrEpoch()
offset, err := assignProvingPeriodOffset(rt.Receiver(), currEpoch, rt.HashBlake2b)
builtin.RequireNoErr(rt, err, exitcode.ErrSerialization, "failed to assign proving period offset")
periodStart := currentProvingPeriodStart(currEpoch, offset)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to construct initial miner info")
infoCid := rt.StorePut(info)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to construct state")
rt.StateCreate(state)

// Register first cron callback for epoch before the next deadline starts.
})
return nil
}

/////////////
// Control //
/////////////

// Changed since v0:
}

rt.ValidateImmediateCallerAcceptAny()
var st State
info := getMinerInfo(rt, &st)
Owner:        info.Owner,
Worker:       info.Worker,
}
}

//}

// ChangeWorkerAddress will ALWAYS overwrite the existing control addresses with the control addresses passed in the params.
// If a nil addresses slice is passed, the control addresses will be cleared.
// A worker change will be scheduled if the worker passed in the params is different from the existing worker.

for _, ca := range params.NewControlAddrs {
}

var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

// Only the Owner is allowed to change the newWorker and control addresses.
rt.ValidateImmediateCallerIs(info.Owner)

// save the new control addresses

// save newWorker addr key change request
if newWorker != info.Worker && info.PendingWorkerKey == nil {
info.PendingWorkerKey = &WorkerKeyChange{
NewWorker:   newWorker,
EffectiveAt: rt.CurrEpoch() + WorkerKeyChangeDelay,
}
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "could not save miner info")
})

return nil
}

// Triggers a worker address change if a change has been requested and its effective epoch has arrived.
func (a Actor) ConfirmUpdateWorkerKey(rt Runtime, params *abi.EmptyValue) *abi.EmptyValue {
var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

// Only the Owner is allowed to change the newWorker.
rt.ValidateImmediateCallerIs(info.Owner)

processPendingWorker(info, rt, &st)
})

return nil
}

// Proposes or confirms a change of owner address.
// If invoked by the current owner, proposes a new owner address for confirmation. If the proposed address is the
// current owner address, revokes any existing proposal.
// If invoked by the previously proposed address, with the same proposal, changes the current owner address to be
}
}
var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)
if rt.Caller() == info.Owner || info.PendingOwnerAddress == nil {
rt.ValidateImmediateCallerIs(info.Owner)
} else { // info.PendingOwnerAddress != nil
// Confirm the proposal.
// This validates that the operator can in fact use the proposed new address to sign messages.
rt.Abortf(exitcode.ErrIllegalArgument, "expected confirmation of %v, got %v",
}
}

// Clear any resulting no-op change.
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save miner info")
})
return nil
}

//type ChangePeerIDParams struct {
//	NewID abi.PeerID
//}
type ChangePeerIDParams = miner0.ChangePeerIDParams

func (a Actor) ChangePeerID(rt Runtime, params *ChangePeerIDParams) *abi.EmptyValue {
checkPeerInfo(rt, params.NewID, nil)

var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

info.PeerId = params.NewID
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "could not save miner info")
})
return nil
}

//}

var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "could not save miner info")
})
return nil
}

//////////////////
// WindowedPoSt //
//////////////////

//type PoStPartition struct {
//	// Partitions are numbered per-deadline, from zero.
//	Index uint64
//	// Sectors skipped while proving that weren't already declared faulty
//	Skipped bitfield.BitField
//}
type PoStPartition = miner0.PoStPartition

// Information submitted by a miner to provide a Window PoSt.
//type SubmitWindowedPoStParams struct {
//	// The deadline index which the submission targets.
//	// The partitions being proven.
//	Partitions []PoStPartition
//	// Array of proofs, one per distinct registered proof type present in the sectors being proven.
//	// In the usual case of a single proof type, this array will always have a single element (independent of number of partitions).
//	Proofs []proof.PoStProof
//	// The epoch at which these proofs is being committed to a particular chain.
//	// NOTE: This field should be removed in the future. See
//	// https://github.com/filecoin-project/specs-actors/issues/1094
//	ChainCommitEpoch abi.ChainEpoch
//	// The ticket randomness on the chain at the chain commit epoch.
//	ChainCommitRand abi.Randomness
//}
type SubmitWindowedPoStParams = miner0.SubmitWindowedPoStParams

// Invoked by miner's worker address to submit their fallback post
func (a Actor) SubmitWindowedPoSt(rt Runtime, params *SubmitWindowedPoStParams) *abi.EmptyValue {
currEpoch := rt.CurrEpoch()
nv := rt.NetworkVersion()
var st State

}
// Technically, ChainCommitRand should be _exactly_ 32 bytes. However:
// 1. It's convenient to allow smaller slices when testing.
// 2. Nothing bad will happen if the caller provides too little randomness.
if len(params.ChainCommitRand) > abi.RandomnessLength {
rt.Abortf(exitcode.ErrIllegalArgument, "expected at most %d bytes of randomness, got %d", abi.RandomnessLength, len(params.ChainCommitRand))
}

partitionIndexes := bitfield.New()
if nv >= network.Version7 {
for _, partition := range params.Partitions {
partitionIndexes.Set(partition.Index)
}
}

var postResult *PoStResult
var info *MinerInfo
rt.StateTransaction(&st, func() {
info = getMinerInfo(rt, &st)

// Verify that the miner has passed 0 or 1 proofs. If they've
// passed 1, verify that it's a good proof.
//
// This can be 0 if the miner isn't actually proving anything,
// just skipping all sectors.
windowPoStProofType, err := info.SealProofType.RegisteredWindowPoStProof()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to determine window PoSt type")
if len(params.Proofs) != 1 {
rt.Abortf(exitcode.ErrIllegalArgument, "expected exactly one proof, got %d", len(params.Proofs))
} else if params.Proofs[0].PoStProof != windowPoStProofType {
rt.Abortf(exitcode.ErrIllegalArgument, "expected proof of type %s, got proof of type %s", params.Proofs[0], windowPoStProofType)
}

// Validate that the miner didn't try to prove too many partitions at once.
if uint64(len(params.Partitions)) > submissionPartitionLimit {
rt.Abortf(exitcode.ErrIllegalArgument, "too many partitions %d, limit %d", len(params.Partitions), submissionPartitionLimit)
}

// Check that the miner state indicates that the current proving deadline has started.
// This should only fail if the cron actor wasn't invoked, and matters only in case that it hasn't been
// invoked for a whole proving period, and hence the missed PoSt submissions from the prior occurrence
// of this deadline haven't been processed yet.
rt.Abortf(exitcode.ErrIllegalState, "proving period %d not yet open at %d", currDeadline.PeriodStart, currEpoch)
}

// The miner may only submit a proof for the current deadline.
rt.Abortf(exitcode.ErrIllegalArgument, "invalid deadline %d at epoch %d, expected %d",
}

// Verify that the PoSt was committed to the chain at most WPoStChallengeLookback+WPoStChallengeWindow in the past.
rt.Abortf(exitcode.ErrIllegalArgument, "expected chain commit epoch %d to be after %d", params.ChainCommitEpoch, currDeadline.Challenge)
}
if params.ChainCommitEpoch >= currEpoch {
rt.Abortf(exitcode.ErrIllegalArgument, "chain commit epoch %d must be less than the current epoch %d", params.ChainCommitEpoch, currEpoch)
}
// Verify the chain commit randomness.
commRand := rt.GetRandomnessFromTickets(crypto.DomainSeparationTag_PoStChainCommit, params.ChainCommitEpoch, nil)
if !bytes.Equal(commRand, params.ChainCommitRand) {
rt.Abortf(exitcode.ErrIllegalArgument, "post commit randomness mismatched")
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors")

if nv >= network.Version7 {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to check proven partitions")
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to check proven intersection is empty")
if !empty {
}
}

// Record proven sectors/partitions, returning updates to power and the final set of sectors
// proven/skipped.
//
// NOTE: This function does not actually check the proofs but does assume that they'll be
// successfully validated. The actual proof verification is done below in verifyWindowedPost.
//
// If proof verification fails, the this deadline MUST NOT be saved and this function should
// be aborted.
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to process post submission for deadline %d", params.Deadline)

// Skipped sectors (including retracted recoveries) pay nothing at Window PoSt,
// but will incur the "ongoing" fault fee at deadline end.

// Validate proofs

// Load sector infos for proof, substituting a known-good sector for known-faulty sectors.
// Note: this is slightly sub-optimal, loading info for the recovering sectors again after they were already
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load proven sector info")

if len(sectorInfos) == 0 {
// Abort verification if all sectors are (now) faults. There's nothing to prove.
// It's not rational for a miner to submit a Window PoSt marking *all* non-faulty sectors as skipped,
// since that will just cause them to pay a penalty at deadline end that would otherwise be zero
// if they had *not* declared them.
rt.Abortf(exitcode.ErrIllegalArgument, "cannot prove partitions with no active sectors")
}

// Verify the proof.
// A failed verification doesn't immediately cause a penalty; the miner can try again.
//
// This function aborts on failure.

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})

// Restore power for recovered sectors. Remove power for new faults.
// NOTE: It would be permissible to delay the power loss until the deadline closes, but that would require
// https://github.com/filecoin-project/specs-actors/issues/414
requestUpdatePower(rt, postResult.PowerDelta)

err := st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

return nil
}

///////////////////////
// Sector Commitment //
///////////////////////

//type SectorPreCommitInfo struct {
//	SealProof       abi.RegisteredSealProof
//	SectorNumber    abi.SectorNumber
//	SealedCID       cid.Cid checked:"true" // CommR
//	SealRandEpoch   abi.ChainEpoch
//	DealIDs         []abi.DealID
//	Expiration      abi.ChainEpoch
//	ReplaceCapacity bool // Whether to replace a "committed capacity" no-deal sector (requires non-empty DealIDs)
//	// The committed capacity sector to replace, and it's deadline/partition location
//	ReplaceSectorPartition uint64
//	ReplaceSectorNumber    abi.SectorNumber
//}
type PreCommitSectorParams = miner0.SectorPreCommitInfo

// Proposals must be posted on chain via sma.PublishStorageDeals before PreCommitSector.
// Optimization: PreCommitSector could contain a list of deals that are not published yet.
func (a Actor) PreCommitSector(rt Runtime, params *PreCommitSectorParams) *abi.EmptyValue {
nv := rt.NetworkVersion()
if !CanPreCommitSealProof(params.SealProof, nv) {
rt.Abortf(exitcode.ErrIllegalArgument, "unsupported seal proof type %v at network version %v", params.SealProof, nv)
}
if params.SectorNumber > abi.MaxSectorNumber {
rt.Abortf(exitcode.ErrIllegalArgument, "sector number %d out of range 0..(2^63-1)", params.SectorNumber)
}
if !params.SealedCID.Defined() {
rt.Abortf(exitcode.ErrIllegalArgument, "sealed CID undefined")
}
if params.SealedCID.Prefix() != SealedCIDPrefix {
rt.Abortf(exitcode.ErrIllegalArgument, "sealed CID had wrong prefix")
}
if params.SealRandEpoch >= rt.CurrEpoch() {
rt.Abortf(exitcode.ErrIllegalArgument, "seal challenge epoch %v must be before now %v", params.SealRandEpoch, rt.CurrEpoch())
}

challengeEarliest := rt.CurrEpoch() - MaxPreCommitRandomnessLookback
if params.SealRandEpoch < challengeEarliest {
rt.Abortf(exitcode.ErrIllegalArgument, "seal challenge epoch %v too old, must be after %v", params.SealRandEpoch, challengeEarliest)
}

// Require sector lifetime meets minimum by assuming activation happens at last epoch permitted for seal proof.
// This could make sector maximum lifetime validation more lenient if the maximum sector limit isn't hit first.
maxActivation := rt.CurrEpoch() + MaxProveCommitDuration[params.SealProof]
validateExpiration(rt, maxActivation, params.Expiration, params.SealProof)

if params.ReplaceCapacity && len(params.DealIDs) == 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot replace sector without committing deals")
}
}
if params.ReplaceSectorNumber > abi.MaxSectorNumber {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid sector number %d", params.ReplaceSectorNumber)
}

// gather information from other actors

rewardStats := requestCurrentEpochBlockReward(rt)
pwrTotal := requestCurrentTotalPower(rt)
dealWeight := requestDealWeight(rt, params.DealIDs, rt.CurrEpoch(), params.Expiration)

var st State
var err error
newlyVested := big.Zero()
feeToBurn := abi.NewTokenAmount(0)
rt.StateTransaction(&st, func() {
// Stop vesting funds as of version 7. Its computationally expensive and unlikely to release any funds.
if rt.NetworkVersion() < network.Version7 {
newlyVested, err = st.UnlockVestedFunds(store, rt.CurrEpoch())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to vest funds")
}

// available balance already accounts for fee debt so it is correct to call
// this before RepayDebts. We would have to
// subtract fee debt explicitly if we called this after.
availableBalance, err := st.GetAvailableBalance(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to calculate available balance")
feeToBurn = RepayDebtsOrAbort(rt, &st)

info := getMinerInfo(rt, &st)

if ConsensusFaultActive(info, rt.CurrEpoch()) {
rt.Abortf(exitcode.ErrForbidden, "precommit not allowed during active consensus fault")
}

if nv < network.Version7 {
if params.SealProof != info.SealProofType {
rt.Abortf(exitcode.ErrIllegalArgument, "sector seal proof %v must match miner seal proof type %d", params.SealProof, info.SealProofType)
}
} else {
// From network version 7, the pre-commit seal type must have the same Window PoSt proof type as the miner's
// recorded seal type has, rather than be exactly the same seal type.
// This permits a transition window from V1 to V1_1 seal types (which share Window PoSt proof type).
minerWPoStProof, err := info.SealProofType.RegisteredWindowPoStProof()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to lookup Window PoSt proof type for miner seal proof %d", info.SealProofType)
sectorWPoStProof, err := params.SealProof.RegisteredWindowPoStProof()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to lookup Window PoSt proof type for sector seal proof %d", params.SealProof)
if sectorWPoStProof != minerWPoStProof {
rt.Abortf(exitcode.ErrIllegalArgument, "sector Window PoSt proof type %d must match miner Window PoSt proof type %d (seal proof type %d)",
sectorWPoStProof, minerWPoStProof, params.SealProof)
}
}

dealCountMax := SectorDealsMax(info.SectorSize)
if uint64(len(params.DealIDs)) > dealCountMax {
rt.Abortf(exitcode.ErrIllegalArgument, "too many deals for sector %d > %d", len(params.DealIDs), dealCountMax)
}

// Ensure total deal space does not exceed sector size.
if dealWeight.DealSpace > uint64(info.SectorSize) {
rt.Abortf(exitcode.ErrIllegalArgument, "deals too large to fit in sector %d > %d", dealWeight.DealSpace, info.SectorSize)
}

err = st.AllocateSectorNumber(store, params.SectorNumber)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to allocate sector id %d", params.SectorNumber)

// The following two checks shouldn't be necessary, but it can't
// hurt to double-check (unless it's really just too
// expensive?).
_, preCommitFound, err := st.GetPrecommittedSector(store, params.SectorNumber)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to check pre-commit %v", params.SectorNumber)
if preCommitFound {
rt.Abortf(exitcode.ErrIllegalState, "sector %v already pre-committed", params.SectorNumber)
}

sectorFound, err := st.HasSectorNo(store, params.SectorNumber)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to check sector %v", params.SectorNumber)
if sectorFound {
rt.Abortf(exitcode.ErrIllegalState, "sector %v already committed", params.SectorNumber)
}

if params.ReplaceCapacity {
validateReplaceSector(rt, &st, store, params)
}

duration := params.Expiration - rt.CurrEpoch()
sectorWeight := QAPowerForWeight(info.SectorSize, duration, dealWeight.DealWeight, dealWeight.VerifiedDealWeight)
if availableBalance.LessThan(depositReq) {
rt.Abortf(exitcode.ErrInsufficientFunds, "insufficient funds for pre-commit deposit: %v", depositReq)
}

if err := st.PutPrecommittedSector(store, &SectorPreCommitOnChainInfo{
Info:               SectorPreCommitInfo(*params),
PreCommitDeposit:   depositReq,
PreCommitEpoch:     rt.CurrEpoch(),
DealWeight:         dealWeight.DealWeight,
VerifiedDealWeight: dealWeight.VerifiedDealWeight,
}); err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to write pre-committed sector %v: %v", params.SectorNumber, err)
}
// add precommit expiry to the queue
msd, ok := MaxProveCommitDuration[params.SealProof]
if !ok {
rt.Abortf(exitcode.ErrIllegalArgument, "no max seal duration set for proof type: %d", params.SealProof)
}
// The +1 here is critical for the batch verification of proofs. Without it, if a proof arrived exactly on the
// due epoch, ProveCommitSector would accept it, then the expiry event would remove it, and then
// ConfirmSectorProofsValid would fail to find it.
expiryBound := rt.CurrEpoch() + msd + 1

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to add pre-commit expiry to queue")
})

burnFunds(rt, feeToBurn)
err = st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

notifyPledgeChanged(rt, newlyVested.Neg())

return nil
}

//type ProveCommitSectorParams struct {
//	SectorNumber abi.SectorNumber
//	Proof        []byte
//}
type ProveCommitSectorParams = miner0.ProveCommitSectorParams

// Checks state of the corresponding sector pre-commitment, then schedules the proof to be verified in bulk
// by the power actor.
// If valid, the power actor will call ConfirmSectorProofsValid at the end of the same epoch as this message.
func (a Actor) ProveCommitSector(rt Runtime, params *ProveCommitSectorParams) *abi.EmptyValue {
rt.ValidateImmediateCallerAcceptAny()
nv := rt.NetworkVersion()

if params.SectorNumber > abi.MaxSectorNumber {
rt.Abortf(exitcode.ErrIllegalArgument, "sector number greater than maximum")
}

maxProofSize := MaxProveCommitSizeV4
if nv >= network.Version5 {
maxProofSize = MaxProveCommitSizeV5
}
if len(params.Proof) > maxProofSize {
rt.Abortf(exitcode.ErrIllegalArgument, "sector prove-commit proof of size %d exceeds max size of %d",
len(params.Proof), maxProofSize)
}

var st State
var precommit *SectorPreCommitOnChainInfo
sectorNo := params.SectorNumber
rt.StateTransaction(&st, func() {
var found bool
var err error
precommit, found, err = st.GetPrecommittedSector(store, sectorNo)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load pre-committed sector %v", sectorNo)
if !found {
rt.Abortf(exitcode.ErrNotFound, "no pre-committed sector %v", sectorNo)
}
})

msd, ok := MaxProveCommitDuration[precommit.Info.SealProof]
if !ok {
rt.Abortf(exitcode.ErrIllegalState, "no max seal duration for proof type: %d", precommit.Info.SealProof)
}
proveCommitDue := precommit.PreCommitEpoch + msd
if rt.CurrEpoch() > proveCommitDue {
rt.Abortf(exitcode.ErrIllegalArgument, "commitment proof for %d too late at %d, due %d", sectorNo, rt.CurrEpoch(), proveCommitDue)
}

svi := getVerifyInfo(rt, &SealVerifyStuff{
SealedCID:           precommit.Info.SealedCID,
InteractiveEpoch:    precommit.PreCommitEpoch + PreCommitChallengeDelay,
SealRandEpoch:       precommit.Info.SealRandEpoch,
Proof:               params.Proof,
DealIDs:             precommit.Info.DealIDs,
SectorNumber:        precommit.Info.SectorNumber,
RegisteredSealProof: precommit.Info.SealProof,
})

code := rt.Send(
builtin.MethodsPower.SubmitPoRepForBulkVerify,
svi,
abi.NewTokenAmount(0),
)
builtin.RequireSuccess(rt, code, "failed to submit proof for bulk verification")
return nil
}

func (a Actor) ConfirmSectorProofsValid(rt Runtime, params *builtin.ConfirmSectorProofsParams) *abi.EmptyValue {

// This should be enforced by the power actor. We log here just in case
// something goes wrong.
if len(params.Sectors) > power.MaxMinerProveCommitsPerEpoch {
rt.Log(rtt.WARN, "confirmed more prove commits in an epoch than permitted: %d > %d",
len(params.Sectors), power.MaxMinerProveCommitsPerEpoch,
)
}

// get network stats from other actors
rewardStats := requestCurrentEpochBlockReward(rt)
pwrTotal := requestCurrentTotalPower(rt)
circulatingSupply := rt.TotalFilCircSupply()

// 1. Activate deals, skipping pre-commits with invalid deals.
//    - calls the market actor.
// 2. Reschedule replacement sector expiration.
//    - loads and saves sectors
//    - loads and saves sectors.
//
// Ideally, we'd combine some of these operations, but at least we have
// a constant number of them.

var st State
info := getMinerInfo(rt, &st)

//
// Activate storage deals.
//

// This skips missing pre-commits.
precommittedSectors, err := st.FindPrecommittedSectors(store, params.Sectors...)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load pre-committed sectors")

// Committed-capacity sectors licensed for early removal by new sectors being proven.
// Pre-commits for new sectors.
var preCommits []*SectorPreCommitOnChainInfo
for _, precommit := range precommittedSectors {
if len(precommit.Info.DealIDs) > 0 {
// Check (and activate) storage deals associated to sector. Abort if checks failed.
// TODO: we should batch these calls...
// https://github.com/filecoin-project/specs-actors/issues/474
code := rt.Send(
builtin.MethodsMarket.ActivateDeals,
&market.ActivateDealsParams{
DealIDs:      precommit.Info.DealIDs,
SectorExpiry: precommit.Info.Expiration,
},
abi.NewTokenAmount(0),
)

if code != exitcode.Ok {
rt.Log(rtt.INFO, "failed to activate deals on sector %d, dropping from prove commit set", precommit.Info.SectorNumber)
continue
}
}

preCommits = append(preCommits, precommit)

if precommit.Info.ReplaceCapacity {
precommit.Info.ReplaceSectorPartition,
uint64(precommit.Info.ReplaceSectorNumber),
)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to record sectors for replacement")
}
}

// When all prove commits have failed abort early
if len(preCommits) == 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "all prove commits failed to validate")
}

var newPower PowerPair
totalPledge := big.Zero()
depositToUnlock := big.Zero()
newSectors := make([]*SectorOnChainInfo, 0)
newlyVested := big.Zero()
rt.StateTransaction(&st, func() {
// Schedule expiration for replaced sectors to the end of their next deadline window.
// They can't be removed right now because we want to challenge them immediately before termination.
replaced, err := st.RescheduleSectorExpirations(store, rt.CurrEpoch(), info.SectorSize, replaceSectors)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to replace sector expirations")
replacedBySectorNumber := asMapBySectorNumber(replaced)

newSectorNos := make([]abi.SectorNumber, 0, len(preCommits))
for _, precommit := range preCommits {
// compute initial pledge
activation := rt.CurrEpoch()
duration := precommit.Info.Expiration - activation

// This should have been caught in precommit, but don't let other sectors fail because of it.
if duration < MinSectorExpiration {
rt.Log(rtt.WARN, "precommit %d has lifetime %d less than minimum. ignoring", precommit.Info.SectorNumber, duration, MinSectorExpiration)
continue
}

pwr := QAPowerForWeight(info.SectorSize, duration, precommit.DealWeight, precommit.VerifiedDealWeight)
dayReward := ExpectedRewardForPower(rewardStats.ThisEpochRewardSmoothed, pwrTotal.QualityAdjPowerSmoothed, pwr, builtin.EpochsInDay)
// The storage pledge is recorded for use in computing the penalty if this sector is terminated
// before its declared expiration.
// It's not capped to 1 FIL, so can exceed the actual initial pledge requirement.
storagePledge := ExpectedRewardForPower(rewardStats.ThisEpochRewardSmoothed, pwrTotal.QualityAdjPowerSmoothed, pwr, InitialPledgeProjectionPeriod)
initialPledge := InitialPledgeForPower(pwr, rewardStats.ThisEpochBaselinePower, rewardStats.ThisEpochRewardSmoothed,

// Lower-bound the pledge by that of the sector being replaced.
// Record the replaced age and reward rate for termination fee calculations.
replacedPledge, replacedAge, replacedDayReward := replacedSectorParameters(rt, precommit, replacedBySectorNumber)
initialPledge = big.Max(initialPledge, replacedPledge)

newSectorInfo := SectorOnChainInfo{
SectorNumber:          precommit.Info.SectorNumber,
SealProof:             precommit.Info.SealProof,
SealedCID:             precommit.Info.SealedCID,
DealIDs:               precommit.Info.DealIDs,
Expiration:            precommit.Info.Expiration,
Activation:            activation,
DealWeight:            precommit.DealWeight,
VerifiedDealWeight:    precommit.VerifiedDealWeight,
InitialPledge:         initialPledge,
ExpectedDayReward:     dayReward,
ExpectedStoragePledge: storagePledge,
ReplacedSectorAge:     replacedAge,
ReplacedDayReward:     replacedDayReward,
}

newSectors = append(newSectors, &newSectorInfo)
newSectorNos = append(newSectorNos, newSectorInfo.SectorNumber)
}

err = st.PutSectors(store, newSectors...)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to put new sectors")

err = st.DeletePrecommittedSectors(store, newSectorNos...)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to delete precommited sectors")

newPower, err = st.AssignSectorsToDeadlines(store, rt.CurrEpoch(), newSectors, info.WindowPoStPartitionSectors, info.SectorSize)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to assign new sectors to deadlines")

// Stop unlocking funds as of version 7. It's computationally expensive and unlikely to actually unlock anything.
if rt.NetworkVersion() < network.Version7 {
newlyVested, err = st.UnlockVestedFunds(store, rt.CurrEpoch())
if err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to vest new funds: %s", err)
}
}

// Unlock deposit for successful proofs, make it available for lock-up as initial pledge.

unlockedBalance, err := st.GetUnlockedBalance(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to calculate unlocked balance")
if unlockedBalance.LessThan(totalPledge) {
rt.Abortf(exitcode.ErrInsufficientFunds, "insufficient funds for aggregate initial pledge requirement %s, available: %s", totalPledge, unlockedBalance)
}

err = st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")
})

// Request power and pledge update for activated sector.
requestUpdatePower(rt, newPower)
notifyPledgeChanged(rt, big.Sub(totalPledge, newlyVested))

return nil
}

//type CheckSectorProvenParams struct {
//	SectorNumber abi.SectorNumber
//}
type CheckSectorProvenParams = miner0.CheckSectorProvenParams

func (a Actor) CheckSectorProven(rt Runtime, params *CheckSectorProvenParams) *abi.EmptyValue {
rt.ValidateImmediateCallerAcceptAny()

if params.SectorNumber > abi.MaxSectorNumber {
rt.Abortf(exitcode.ErrIllegalArgument, "sector number out of range")
}

var st State
sectorNo := params.SectorNumber

if _, found, err := st.GetSector(store, sectorNo); err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to load proven sector %v", sectorNo)
} else if !found {
rt.Abortf(exitcode.ErrNotFound, "sector %v not proven", sectorNo)
}
return nil
}

/////////////////////////
// Sector Modification //
/////////////////////////

//type ExtendSectorExpirationParams struct {
//	Extensions []ExpirationExtension
//}
type ExtendSectorExpirationParams = miner0.ExtendSectorExpirationParams

//type ExpirationExtension struct {
//	Partition     uint64
//	Sectors       bitfield.BitField
//	NewExpiration abi.ChainEpoch
//}
type ExpirationExtension = miner0.ExpirationExtension

// Changes the expiration epoch for a sector to a new, later one.
// The sector must not be terminated or faulty.
// The sector's power is recomputed for the new expiration.
func (a Actor) ExtendSectorExpiration(rt Runtime, params *ExtendSectorExpirationParams) *abi.EmptyValue {
nv := rt.NetworkVersion()
if uint64(len(params.Extensions)) > DeclarationsMax {
rt.Abortf(exitcode.ErrIllegalArgument, "too many declarations %d, max %d", len(params.Extensions), DeclarationsMax)
}

// limit the number of sectors declared at once
// https://github.com/filecoin-project/specs-actors/issues/416
var sectorCount uint64
for _, decl := range params.Extensions {
}
count, err := decl.Sectors.Count()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument,
"failed to count sectors for deadline %d, partition %d",
)
if sectorCount > math.MaxUint64-count {
rt.Abortf(exitcode.ErrIllegalArgument, "sector bitfield integer overflow")
}
sectorCount += count
}
rt.Abortf(exitcode.ErrIllegalArgument,
"too many sectors for declaration %d, max %d",
)
}

currEpoch := rt.CurrEpoch()

powerDelta := NewPowerPairZero()
pledgeDelta := big.Zero()
var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

// Group declarations by deadline, and remember iteration order.
// This should be merged with the iteration outside the state transaction.
for i := range params.Extensions {
// Take a pointer to the value inside the slice, don't
// take a reference to the temporary loop variable as it
// will be overwritten every iteration.
decl := &params.Extensions[i]
}
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors array")

// Group modified partitions by epoch to which they are extended. Duplicates are ok.
partitionsByNewEpoch := map[abi.ChainEpoch][]uint64{}
// Remember iteration order of epochs.
var epochsToReschedule []abi.ChainEpoch

for _, decl := range declsByDeadline[dlIdx] {
var partition Partition
found, err := partitions.Get(decl.Partition, &partition)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load deadline %v partition %v", dlIdx, decl.Partition)
if !found {
rt.Abortf(exitcode.ErrNotFound, "no such deadline %v partition %v", dlIdx, decl.Partition)
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors in deadline %v partition %v", dlIdx, decl.Partition)
newSectors := make([]*SectorOnChainInfo, len(oldSectors))
for i, sector := range oldSectors {
if !CanExtendSealProofType(sector.SealProof, nv) {
rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for sector %v with unsupported seal type %v",
sector.SectorNumber, sector.SealProof)
}
// This can happen if the sector should have already expired, but hasn't
// because the end of its deadline hasn't passed yet.
if sector.Expiration < currEpoch {
rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for expired sector %v, expired at %d, now %d",
sector.SectorNumber,
sector.Expiration,
currEpoch,
)
}
if decl.NewExpiration < sector.Expiration {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot reduce sector %v's expiration to %d from %d",
sector.SectorNumber, decl.NewExpiration, sector.Expiration)
}
validateExpiration(rt, sector.Activation, decl.NewExpiration, sector.SealProof)

newSector := *sector
newSector.Expiration = decl.NewExpiration

newSectors[i] = &newSector
}

// Overwrite sector infos.
err = sectors.Store(newSectors...)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to update sectors %v", decl.Sectors)

// Remove old sectors from partition and assign new sectors.
partitionPowerDelta, partitionPledgeDelta, err := partition.ReplaceSectors(store, oldSectors, newSectors, info.SectorSize, quant)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to replace sector expirations at deadline %v partition %v", dlIdx, decl.Partition)

pledgeDelta = big.Add(pledgeDelta, partitionPledgeDelta) // expected to be zero, see note below.

err = partitions.Set(decl.Partition, &partition)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadline %v partition %v", dlIdx, decl.Partition)

// Record the new partition expiration epoch for setting outside this loop over declarations.
if nv >= network.Version7 {
prevEpochPartitions, ok := partitionsByNewEpoch[decl.NewExpiration]
partitionsByNewEpoch[decl.NewExpiration] = append(prevEpochPartitions, decl.Partition)
if !ok {
epochsToReschedule = append(epochsToReschedule, decl.NewExpiration)
}
}
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save partitions for deadline %d", dlIdx)

// Record partitions in deadline expiration queue
if nv >= network.Version7 {
for _, epoch := range epochsToReschedule {
pIdxs := partitionsByNewEpoch[epoch]
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to add expiration partitions to deadline %v epoch %v: %v",
dlIdx, epoch, pIdxs)
}
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadline %d", dlIdx)
}

st.Sectors, err = sectors.Root()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save sectors")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})

requestUpdatePower(rt, powerDelta)
// Note: the pledge delta is expected to be zero, since pledge is not re-calculated for the extension.
// But in case that ever changes, we can do the right thing here.
notifyPledgeChanged(rt, pledgeDelta)
return nil
}

//type TerminateSectorsParams struct {
//	Terminations []TerminationDeclaration
//}
type TerminateSectorsParams = miner0.TerminateSectorsParams

//type TerminationDeclaration struct {
//	Partition uint64
//	Sectors   bitfield.BitField
//}
type TerminationDeclaration = miner0.TerminationDeclaration

//type TerminateSectorsReturn struct {
//	// Set to true if all early termination work has been completed. When
//	// false, the miner may choose to repeatedly invoke TerminateSectors
//	// with no new sectors to process the remainder of the pending
//	// terminations. While pending terminations are outstanding, the miner
//	// will not be able to withdraw funds.
//	Done bool
//}
type TerminateSectorsReturn = miner0.TerminateSectorsReturn

// Marks some sectors as terminated at the present epoch, earlier than their
// scheduled termination, and adds these sectors to the early termination queue.
// This method then processes up to AddressedSectorsMax sectors and
// AddressedPartitionsMax partitions from the early termination queue,
// terminating deals, paying fines, and returning pledge collateral. While
// sectors remain in this queue:
//
//  1. The miner will be unable to withdraw funds.
//  2. The chain will process up to AddressedSectorsMax sectors and
//     AddressedPartitionsMax per epoch until the queue is empty.
//
// The sectors are immediately ignored for Window PoSt proofs, and should be
// masked in the same way as faulty sectors. A miner terminating sectors in the
// current deadline must be careful to compute an appropriate Window PoSt proof
// for the sectors that will be active at the time the PoSt is submitted.
//
// This function may be invoked with no new sectors to explicitly process the
// next batch of sectors.
func (a Actor) TerminateSectors(rt Runtime, params *TerminateSectorsParams) *TerminateSectorsReturn {
// Note: this cannot terminate pre-committed but un-proven sectors.
// They must be allowed to expire (and deposit burnt).

if len(params.Terminations) > DeclarationsMax {
rt.Abortf(exitcode.ErrIllegalArgument,
"too many declarations when terminating sectors: %d > %d",
len(params.Terminations), DeclarationsMax,
)
}

for _, term := range params.Terminations {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument,
)
}
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "cannot process requested parameters")

var st State
currEpoch := rt.CurrEpoch()
powerDelta := NewPowerPairZero()
rt.StateTransaction(&st, func() {

info := getMinerInfo(rt, &st)

// We're only reading the sectors, so there's no need to save this back.
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors")

err = toProcess.ForEach(func(dlIdx uint64, partitionSectors PartitionSectorMap) error {

removedPower, err := deadline.TerminateSectors(store, sectors, currEpoch, partitionSectors, info.SectorSize, quant)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to terminate sectors in deadline %d", dlIdx)

st.EarlyTerminations.Set(dlIdx)

powerDelta = powerDelta.Sub(removedPower)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to update deadline %d", dlIdx)

return nil
})
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to walk sectors")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})

// Now, try to process these sectors.
more := processEarlyTerminations(rt)
// We have remaining terminations, and we didn't _previously_
// have early terminations to process, schedule a cron job.
// NOTE: This isn't quite correct. If we repeatedly fill, empty,
// fill, and empty, the queue, we'll keep scheduling new cron
// jobs. However, in practice, that shouldn't be all that bad.
scheduleEarlyTerminationWork(rt)
}

requestUpdatePower(rt, powerDelta)

return &TerminateSectorsReturn{Done: !more}
}

////////////
// Faults //
////////////

//type DeclareFaultsParams struct {
//	Faults []FaultDeclaration
//}
type DeclareFaultsParams = miner0.DeclareFaultsParams

//type FaultDeclaration struct {
//	// The deadline to which the faulty sectors are assigned, in range [0..WPoStPeriodDeadlines)
//	// Partition index within the deadline containing the faulty sectors.
//	Partition uint64
//	// Sectors in the partition being declared faulty.
//	Sectors bitfield.BitField
//}
type FaultDeclaration = miner0.FaultDeclaration

func (a Actor) DeclareFaults(rt Runtime, params *DeclareFaultsParams) *abi.EmptyValue {
if len(params.Faults) > DeclarationsMax {
rt.Abortf(exitcode.ErrIllegalArgument,
"too many fault declarations for a single message: %d > %d",
len(params.Faults), DeclarationsMax,
)
}

for _, term := range params.Faults {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument,
)
}
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "cannot process requested parameters")

var st State
powerDelta := NewPowerPairZero()
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors array")

err = toProcess.ForEach(func(dlIdx uint64, pm PartitionSectorMap) error {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "invalid fault declaration deadline %d", dlIdx)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed fault declaration at deadline %d", dlIdx)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to declare faults for deadline %d", dlIdx)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to store deadline %d partitions", dlIdx)

return nil
})
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to iterate deadlines")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})

// Remove power for new faulty sectors.
// NOTE: It would be permissible to delay the power loss until the deadline closes, but that would require
// https://github.com/filecoin-project/specs-actors/issues/414
requestUpdatePower(rt, powerDelta)

// Payment of penalty for declared faults is deferred to the deadline cron.
return nil
}

//type DeclareFaultsRecoveredParams struct {
//	Recoveries []RecoveryDeclaration
//}
type DeclareFaultsRecoveredParams = miner0.DeclareFaultsRecoveredParams

//type RecoveryDeclaration struct {
//	// The deadline to which the recovered sectors are assigned, in range [0..WPoStPeriodDeadlines)
//	// Partition index within the deadline containing the recovered sectors.
//	Partition uint64
//	// Sectors in the partition being declared recovered.
//	Sectors bitfield.BitField
//}
type RecoveryDeclaration = miner0.RecoveryDeclaration

func (a Actor) DeclareFaultsRecovered(rt Runtime, params *DeclareFaultsRecoveredParams) *abi.EmptyValue {
if len(params.Recoveries) > DeclarationsMax {
rt.Abortf(exitcode.ErrIllegalArgument,
"too many recovery declarations for a single message: %d > %d",
len(params.Recoveries), DeclarationsMax,
)
}

for _, term := range params.Recoveries {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument,
)
}
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "cannot process requested parameters")

var st State
feeToBurn := abi.NewTokenAmount(0)
rt.StateTransaction(&st, func() {
// Verify unlocked funds cover both InitialPledgeRequirement and FeeDebt
// and repay fee debt now.
feeToBurn = RepayDebtsOrAbort(rt, &st)

info := getMinerInfo(rt, &st)
if ConsensusFaultActive(info, rt.CurrEpoch()) {
rt.Abortf(exitcode.ErrForbidden, "recovery not allowed during active consensus fault")
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors array")

err = toProcess.ForEach(func(dlIdx uint64, pm PartitionSectorMap) error {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "invalid recovery declaration deadline %d", dlIdx)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed recovery declaration at deadline %d", dlIdx)

err = deadline.DeclareFaultsRecovered(store, sectors, info.SectorSize, pm)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to declare recoveries for deadline %d", dlIdx)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to store deadline %d", dlIdx)
return nil
})
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to walk sectors")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})

burnFunds(rt, feeToBurn)
err = st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

// Power is not restored yet, but when the recovered sectors are successfully PoSted.
return nil
}

/////////////////
// Maintenance //
/////////////////

//type CompactPartitionsParams struct {
//	Partitions bitfield.BitField
//}
type CompactPartitionsParams = miner0.CompactPartitionsParams

// Compacts a number of partitions at one deadline by removing terminated sectors, re-ordering the remaining sectors,
// and assigning them to new partitions so as to completely fill all but one partition with live sectors.
// The addressed partitions are removed from the deadline, and new ones appended.
// The final partition in the deadline is always included in the compaction, whether or not explicitly requested.
// Removed sectors are removed from state entirely.
// May not be invoked if the deadline has any un-processed early terminations.
func (a Actor) CompactPartitions(rt Runtime, params *CompactPartitionsParams) *abi.EmptyValue {
}

partitionCount, err := params.Partitions.Count()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to parse partitions bitfield")

var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

rt.Abortf(exitcode.ErrForbidden,
"cannot compact deadline %d during its challenge window or the prior challenge window", params.Deadline)
}

if partitionCount > submissionPartitionLimit {
rt.Abortf(exitcode.ErrIllegalArgument, "too many partitions %d, limit %d", partitionCount, submissionPartitionLimit)
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to delete dead sectors")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load moved sectors")

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to add back moved sectors")

if !removedPower.Equals(newPower) {
rt.Abortf(exitcode.ErrIllegalState, "power changed when compacting partitions: was %v, is now %v", removedPower, newPower)
}

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to save deadlines")
})
return nil
}

//type CompactSectorNumbersParams struct {
//}
type CompactSectorNumbersParams = miner0.CompactSectorNumbersParams

// Compacts sector number allocations to reduce the size of the allocated sector
// number bitfield.
//
// When allocating sector numbers sequentially, or in sequential groups, this
// bitfield should remain fairly small. However, if the bitfield grows large
// enough such that PreCommitSector fails (or becomes expensive), this method
// can be called to mask out (throw away) entire ranges of unused sector IDs.
// For example, if sectors 1-99 and 101-200 have been allocated, sector number
// 99 can be masked out to collapse these two ranges into one.
func (a Actor) CompactSectorNumbers(rt Runtime, params *CompactSectorNumbersParams) *abi.EmptyValue {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "invalid mask bitfield")
if lastSectorNo > abi.MaxSectorNumber {
rt.Abortf(exitcode.ErrIllegalArgument, "masked sector number %d exceeded max sector number", lastSectorNo)
}

var st State
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to mask sector numbers")
})
return nil
}

///////////////////////
// Pledge Collateral //
///////////////////////

// Locks up some amount of the miner's unlocked balance (including funds received alongside the invoking message).
func (a Actor) ApplyRewards(rt Runtime, params *builtin.ApplyRewardParams) *abi.EmptyValue {
if params.Reward.Sign() < 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot lock up a negative amount of funds")
}
if params.Penalty.Sign() < 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot penalize a negative amount of funds")
}
nv := rt.NetworkVersion()

var st State
pledgeDeltaTotal := big.Zero()
toBurn := big.Zero()
rt.StateTransaction(&st, func() {
var err error

rewardToLock, lockedRewardVestingSpec := LockedRewardFromReward(params.Reward, nv)

// This ensures the miner has sufficient funds to lock up amountToLock.
// This should always be true if reward actor sends reward funds with the message.
unlockedBalance, err := st.GetUnlockedBalance(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to calculate unlocked balance")
if unlockedBalance.LessThan(rewardToLock) {
rt.Abortf(exitcode.ErrInsufficientFunds, "insufficient funds to lock, available: %v, requested: %v", unlockedBalance, rewardToLock)
}

newlyVested, err := st.AddLockedFunds(store, rt.CurrEpoch(), rewardToLock, lockedRewardVestingSpec)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to lock funds in vesting table")
pledgeDeltaTotal = big.Sub(pledgeDeltaTotal, newlyVested)

// If the miner incurred block mining penalties charge these to miner's fee debt
err = st.ApplyPenalty(params.Penalty)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to apply penalty")
// Attempt to repay all fee debt in this call. In most cases the miner will have enough
// funds in the *reward alone* to cover the penalty. In the rare case a miner incurs more
// penalty than it can pay for with reward and existing funds, it will go into fee debt.
penaltyFromVesting, penaltyFromBalance, err := st.RepayPartialDebtInPriorityOrder(store, rt.CurrEpoch(), rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to repay penalty")
pledgeDeltaTotal = big.Sub(pledgeDeltaTotal, penaltyFromVesting)
})

notifyPledgeChanged(rt, pledgeDeltaTotal)
burnFunds(rt, toBurn)

return nil
}

//type ReportConsensusFaultParams struct {
//}
type ReportConsensusFaultParams = miner0.ReportConsensusFaultParams

func (a Actor) ReportConsensusFault(rt Runtime, params *ReportConsensusFaultParams) *abi.EmptyValue {
// Note: only the first reporter of any fault is rewarded.
// Subsequent invocations fail because the target miner has been removed.
rt.ValidateImmediateCallerType(builtin.CallerTypesSignable...)
reporter := rt.Caller()

if err != nil {
rt.Abortf(exitcode.ErrIllegalArgument, "fault not verified: %s", err)
}

// Elapsed since the fault (i.e. since the higher of the two blocks)
currEpoch := rt.CurrEpoch()
faultAge := currEpoch - fault.Epoch
if faultAge <= 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid fault epoch %v ahead of current %v", fault.Epoch, rt.CurrEpoch())
}

// Penalize miner consensus fault fee
// Give a portion of this to the reporter as reward
var st State
rewardStats := requestCurrentEpochBlockReward(rt)
// The policy amounts we should burn and send to reporter
// These may differ from actual funds send when miner goes into fee debt
faultPenalty := ConsensusFaultPenalty(rewardStats.ThisEpochRewardSmoothed.Estimate())
slasherReward := RewardForConsensusSlashReport(faultAge, faultPenalty)
pledgeDelta := big.Zero()

// The amounts actually sent to burnt funds and reporter
burnAmount := big.Zero()
rewardAmount := big.Zero()
rt.StateTransaction(&st, func() {
info := getMinerInfo(rt, &st)

// verify miner hasn't already been faulted
if fault.Epoch < info.ConsensusFaultElapsed {
rt.Abortf(exitcode.ErrForbidden, "fault epoch %d is too old, last exclusion period ended at %d", fault.Epoch, info.ConsensusFaultElapsed)
}

err := st.ApplyPenalty(faultPenalty)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to apply penalty")

// Pay penalty
penaltyFromVesting, penaltyFromBalance, err := st.RepayPartialDebtInPriorityOrder(adt.AsStore(rt), currEpoch, rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to pay fees")
// Burn the amount actually payable. Any difference in this and faultPenalty already recorded as FeeDebt

// clamp reward at funds burnt
rewardAmount = big.Min(burnAmount, slasherReward)
// reduce burnAmount by rewardAmount
burnAmount = big.Sub(burnAmount, rewardAmount)
info.ConsensusFaultElapsed = rt.CurrEpoch() + ConsensusFaultIneligibilityDuration
builtin.RequireNoErr(rt, err, exitcode.ErrSerialization, "failed to save miner info")
})
code := rt.Send(reporter, builtin.MethodSend, nil, rewardAmount, &builtin.Discard{})
if !code.IsSuccess() {
rt.Log(rtt.ERROR, "failed to send reward")
}
burnFunds(rt, burnAmount)
notifyPledgeChanged(rt, pledgeDelta)

err = st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

return nil
}

//type WithdrawBalanceParams struct {
//	AmountRequested abi.TokenAmount
//}
type WithdrawBalanceParams = miner0.WithdrawBalanceParams

func (a Actor) WithdrawBalance(rt Runtime, params *WithdrawBalanceParams) *abi.EmptyValue {
var st State
if params.AmountRequested.LessThan(big.Zero()) {
rt.Abortf(exitcode.ErrIllegalArgument, "negative fund requested for withdrawal: %s", params.AmountRequested)
}
var info *MinerInfo
newlyVested := big.Zero()
feeToBurn := big.Zero()
availableBalance := big.Zero()
rt.StateTransaction(&st, func() {
var err error
info = getMinerInfo(rt, &st)
// Only the owner is allowed to withdraw the balance as it belongs to/is controlled by the owner
// and not the worker.
rt.ValidateImmediateCallerIs(info.Owner)

// Ensure we don't have any pending terminations.
if count, err := st.EarlyTerminations.Count(); err != nil {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to count early terminations")
} else if count > 0 {
rt.Abortf(exitcode.ErrForbidden,
"cannot withdraw funds while %d deadlines have terminated sectors with outstanding fees",
count,
)
}

// Unlock vested funds so we can spend them.
if err != nil {
rt.Abortf(exitcode.ErrIllegalState, "failed to vest fund: %v", err)
}
// available balance already accounts for fee debt so it is correct to call
// this before RepayDebts. We would have to
// subtract fee debt explicitly if we called this after.
availableBalance, err = st.GetAvailableBalance(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to calculate available balance")

// Verify unlocked funds cover both InitialPledgeRequirement and FeeDebt
// and repay fee debt now.
feeToBurn = RepayDebtsOrAbort(rt, &st)
})

amountWithdrawn := big.Min(availableBalance, params.AmountRequested)
Assert(amountWithdrawn.GreaterThanEqual(big.Zero()))
Assert(amountWithdrawn.LessThanEqual(availableBalance))

if amountWithdrawn.GreaterThan(abi.NewTokenAmount(0)) {
code := rt.Send(info.Owner, builtin.MethodSend, nil, amountWithdrawn, &builtin.Discard{})
builtin.RequireSuccess(rt, code, "failed to withdraw balance")
}

burnFunds(rt, feeToBurn)

pledgeDelta := newlyVested.Neg()
notifyPledgeChanged(rt, pledgeDelta)

err := st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

return nil
}

func (a Actor) RepayDebt(rt Runtime, _ *abi.EmptyValue) *abi.EmptyValue {
var st State
var fromVesting, fromBalance abi.TokenAmount
rt.StateTransaction(&st, func() {
var err error
info := getMinerInfo(rt, &st)

// Repay as much fee debt as possible.
fromVesting, fromBalance, err = st.RepayPartialDebtInPriorityOrder(adt.AsStore(rt), rt.CurrEpoch(), rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to unlock fee debt")
})

notifyPledgeChanged(rt, fromVesting.Neg())
burnFunds(rt, big.Sum(fromVesting, fromBalance))
err := st.CheckBalanceInvariants(rt.CurrentBalance())
builtin.RequireNoErr(rt, err, ErrBalanceInvariantBroken, "balance invariants broken")

return nil
}

//////////
// Cron //
//////////

//	EventType CronEventType
//}

type CronEventType = miner0.CronEventType

const (
CronEventProcessEarlyTerminations = miner0.CronEventProcessEarlyTerminations
)

case CronEventProcessEarlyTerminations:
if processEarlyTerminations(rt) {
scheduleEarlyTerminationWork(rt)
}
}

return nil
}

////////////////////////////////////////////////////////////////////////////////
// Utility functions & helpers
////////////////////////////////////////////////////////////////////////////////

func processEarlyTerminations(rt Runtime) (more bool) {

// TODO: We're using the current power+epoch reward. Technically, we
// should use the power/reward at the time of termination.
// https://github.com/filecoin-project/specs-actors/v2/pull/648
rewardStats := requestCurrentEpochBlockReward(rt)
pwrTotal := requestCurrentTotalPower(rt)

var (
result           TerminationResult
dealsToTerminate []market.OnMinerSectorsTerminateParams
penalty          = big.Zero()
pledgeDelta      = big.Zero()
)

var st State
rt.StateTransaction(&st, func() {
var err error
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to pop early terminations")

// Nothing to do, don't waste any time.
// This can happen if we end up processing early terminations
// before the cron callback fires.
if result.IsEmpty() {
return
}

info := getMinerInfo(rt, &st)

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sectors array")

totalInitialPledge := big.Zero()
dealsToTerminate = make([]market.OnMinerSectorsTerminateParams, 0, len(result.Sectors))
err = result.ForEach(func(epoch abi.ChainEpoch, sectorNos bitfield.BitField) error {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sector infos")
params := market.OnMinerSectorsTerminateParams{
Epoch:   epoch,
DealIDs: make([]abi.DealID, 0, len(sectors)), // estimate ~one deal per sector.
}
for _, sector := range sectors {
params.DealIDs = append(params.DealIDs, sector.DealIDs...)
}
dealsToTerminate = append(dealsToTerminate, params)

return nil
})
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to process terminations")

// Pay penalty
err = st.ApplyPenalty(penalty)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to apply penalty")

// Remove pledge requirement.
pledgeDelta = big.Sub(pledgeDelta, totalInitialPledge)

// Use unlocked pledge to pay down outstanding fee debt
penaltyFromVesting, penaltyFromBalance, err := st.RepayPartialDebtInPriorityOrder(store, rt.CurrEpoch(), rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to pay penalty")
pledgeDelta = big.Sub(pledgeDelta, penaltyFromVesting)
})

// We didn't do anything, abort.
if result.IsEmpty() {
return more
}

// Burn penalty.
burnFunds(rt, penalty)

// Return pledge.
notifyPledgeChanged(rt, pledgeDelta)

// Terminate deals.
for _, params := range dealsToTerminate {
requestTerminateDeals(rt, params.Epoch, params.DealIDs)
}

// reschedule cron worker, if necessary.
return more
}

// Invoked at the end of the last epoch for each proving deadline.
currEpoch := rt.CurrEpoch()

epochReward := requestCurrentEpochBlockReward(rt)
pwrTotal := requestCurrentTotalPower(rt)

powerDeltaTotal := NewPowerPairZero()
penaltyTotal := abi.NewTokenAmount(0)
pledgeDeltaTotal := abi.NewTokenAmount(0)

var st State
rt.StateTransaction(&st, func() {
{
// Vest locked funds.
// This happens first so that any subsequent penalties are taken
// from locked vesting funds before funds free this epoch.
newlyVested, err := st.UnlockVestedFunds(store, rt.CurrEpoch())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to vest funds")
}

{
// Process pending worker change if any
info := getMinerInfo(rt, &st)
processPendingWorker(info, rt, &st)
}

{
depositToBurn, err := st.ExpirePreCommits(store, currEpoch)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to expire pre-committed sectors")

err = st.ApplyPenalty(depositToBurn)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to apply penalty")
}

// Record whether or not we _had_ early terminations in the queue before this method.
// That way, don't re-schedule a cron callback if one is already scheduled.

{

// Faults detected by this missed PoSt pay no penalty, but sectors that were already faulty
// and remain faulty through this deadline pay the fault fee.
penaltyTarget := PledgePenaltyForContinuedFault(
epochReward.ThisEpochRewardSmoothed,
result.PreviouslyFaultyPower.QA,
)

err = st.ApplyPenalty(penaltyTarget)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to apply penalty")

penaltyFromVesting, penaltyFromBalance, err := st.RepayPartialDebtInPriorityOrder(store, currEpoch, rt.CurrentBalance())
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to unlock penalty")
pledgeDeltaTotal = big.Sub(pledgeDeltaTotal, penaltyFromVesting)
}
})

// Remove power for new faults, and burn penalties.
requestUpdatePower(rt, powerDeltaTotal)
burnFunds(rt, penaltyTotal)
notifyPledgeChanged(rt, pledgeDeltaTotal)

// Schedule cron callback for next deadline's last epoch.
})

// Record whether or not we _have_ early terminations now.
hasEarlyTerminations := havePendingEarlyTerminations(rt, &st)

// If we didn't have pending early terminations before, but we do now,
// handle them at the next epoch.
// First, try to process some of these terminations.
if processEarlyTerminations(rt) {
// If that doesn't work, just defer till the next epoch.
scheduleEarlyTerminationWork(rt)
}
// Note: _don't_ process early terminations if we had a cron
// processed AddressedSectorsMax terminations this epoch.
}
}

// Check expiry is exactly *the epoch before* the start of a proving period.
func validateExpiration(rt Runtime, activation, expiration abi.ChainEpoch, sealProof abi.RegisteredSealProof) {
// Expiration must be after activation. Check this explicitly to avoid an underflow below.
if expiration <= activation {
rt.Abortf(exitcode.ErrIllegalArgument, "sector expiration %v must be after activation (%v)", expiration, activation)
}
// expiration cannot be less than minimum after activation
if expiration-activation < MinSectorExpiration {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid expiration %d, total sector lifetime (%d) must exceed %d after activation %d",
expiration, expiration-activation, MinSectorExpiration, activation)
}

// expiration cannot exceed MaxSectorExpirationExtension from now
if expiration > rt.CurrEpoch()+MaxSectorExpirationExtension {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid expiration %d, cannot be more than %d past current epoch %d",
expiration, MaxSectorExpirationExtension, rt.CurrEpoch())
}

// total sector lifetime cannot exceed SectorMaximumLifetime for the sector's seal proof
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "unrecognized seal proof type %d", sealProof)
rt.Abortf(exitcode.ErrIllegalArgument, "invalid expiration %d, total sector lifetime (%d) cannot exceed %d after activation %d",
}
}

func validateReplaceSector(rt Runtime, st *State, store adt.Store, params *PreCommitSectorParams) {
nv := rt.NetworkVersion()
replaceSector, found, err := st.GetSector(store, params.ReplaceSectorNumber)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to load sector %v", params.SectorNumber)
if !found {
rt.Abortf(exitcode.ErrNotFound, "no such sector %v to replace", params.ReplaceSectorNumber)
}

if len(replaceSector.DealIDs) > 0 {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot replace sector %v which has deals", params.ReplaceSectorNumber)
}
if nv < network.Version7 {
if params.SealProof != replaceSector.SealProof {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot replace sector %v seal proof %v with seal proof %v",
params.ReplaceSectorNumber, replaceSector.SealProof, params.SealProof)
}
} else {
// From network version 7, the new sector's seal type must have the same Window PoSt proof type as the one
// being replaced, rather than be exactly the same seal type.
// This permits replacing sectors with V1 seal types with V1_1 seal types.
replaceWPoStProof, err := replaceSector.SealProof.RegisteredWindowPoStProof()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to lookup Window PoSt proof type for sector seal proof %d", replaceSector.SealProof)
newWPoStProof, err := params.SealProof.RegisteredWindowPoStProof()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalArgument, "failed to lookup Window PoSt proof type for new seal proof %d", params.SealProof)
if newWPoStProof != replaceWPoStProof {
rt.Abortf(exitcode.ErrIllegalArgument, "new sector window PoSt proof type %d must match replaced proof type %d (seal proof type %d)",
newWPoStProof, replaceWPoStProof, params.SealProof)
}
}
if params.Expiration < replaceSector.Expiration {
rt.Abortf(exitcode.ErrIllegalArgument, "cannot replace sector %v expiration %v with sooner expiration %v",
params.ReplaceSectorNumber, replaceSector.Expiration, params.Expiration)
}

err = st.CheckSectorHealth(store, params.ReplaceSectorDeadline, params.ReplaceSectorPartition, params.ReplaceSectorNumber)
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to replace sector %v", params.ReplaceSectorNumber)
}

if err != nil {
rt.Abortf(exitcode.ErrIllegalArgument, "failed to serialize payload: %v", err)
}
code := rt.Send(
builtin.MethodsPower.EnrollCronEvent,
&power.EnrollCronEventParams{
EventEpoch: eventEpoch,
},
abi.NewTokenAmount(0),
)
builtin.RequireSuccess(rt, code, "failed to enroll cron event")
}

func requestUpdatePower(rt Runtime, delta PowerPair) {
if delta.IsZero() {
return
}
code := rt.Send(
builtin.MethodsPower.UpdateClaimedPower,
&power.UpdateClaimedPowerParams{
RawByteDelta:         delta.Raw,
},
abi.NewTokenAmount(0),
)
builtin.RequireSuccess(rt, code, "failed to update power with %v", delta)
}

func requestTerminateDeals(rt Runtime, epoch abi.ChainEpoch, dealIDs []abi.DealID) {
for len(dealIDs) > 0 {
size := min64(cbg.MaxLength, uint64(len(dealIDs)))
code := rt.Send(
builtin.MethodsMarket.OnMinerSectorsTerminate,
&market.OnMinerSectorsTerminateParams{
Epoch:   epoch,
DealIDs: dealIDs[:size],
},
abi.NewTokenAmount(0),
)
builtin.RequireSuccess(rt, code, "failed to terminate deals, exit code %v", code)
dealIDs = dealIDs[size:]
}
}

func scheduleEarlyTerminationWork(rt Runtime) {
EventType: CronEventProcessEarlyTerminations,
})
}

func havePendingEarlyTerminations(rt Runtime, st *State) bool {
// Record this up-front
noEarlyTerminations, err := st.EarlyTerminations.IsEmpty()
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to count early terminations")
return !noEarlyTerminations
}

func verifyWindowedPost(rt Runtime, challengeEpoch abi.ChainEpoch, sectors []*SectorOnChainInfo, proofs []proof.PoStProof) {
AssertNoError(err) // Runtime always provides ID-addresses

// Regenerate challenge randomness, which must match that generated for the proof.
builtin.RequireNoErr(rt, err, exitcode.ErrSerialization, "failed to marshal address for window post challenge")

sectorProofInfo := make([]proof.SectorInfo, len(sectors))
for i, s := range sectors {
sectorProofInfo[i] = proof.SectorInfo{
SealProof:    s.SealProof,
SectorNumber: s.SectorNumber,
SealedCID:    s.SealedCID,
}
}

// Get public inputs
pvInfo := proof.WindowPoStVerifyInfo{
Randomness:        abi.PoStRandomness(postRandomness),
Proofs:            proofs,
ChallengedSectors: sectorProofInfo,
Prover:            abi.ActorID(minerActorID),
}

// Verify the PoSt Proof
if err = rt.VerifyPoSt(pvInfo); err != nil {
rt.Abortf(exitcode.ErrIllegalArgument, "invalid PoSt %+v: %s", pvInfo, err)
}
}

// SealVerifyParams is the structure of information that must be sent with a
// message to commit a sector. Most of this information is not needed in the
// state tree but will be verified in sm.CommitSector. See SealCommitment for
// data stored on the state tree for each sector.
type SealVerifyStuff struct {
SealedCID        cid.Cid        // CommR
InteractiveEpoch abi.ChainEpoch // Used to derive the interactive PoRep challenge.
abi.RegisteredSealProof
Proof   []byte
DealIDs []abi.DealID
abi.SectorNumber
SealRandEpoch abi.ChainEpoch // Used to tie the seal to a chain.
}

func getVerifyInfo(rt Runtime, params *SealVerifyStuff) *proof.SealVerifyInfo {
if rt.CurrEpoch() <= params.InteractiveEpoch {
rt.Abortf(exitcode.ErrForbidden, "too early to prove sector")
}

commD := requestUnsealedSectorCID(rt, params.RegisteredSealProof, params.DealIDs)

AssertNoError(err) // Runtime always provides ID-addresses

buf := new(bytes.Buffer)
builtin.RequireNoErr(rt, err, exitcode.ErrSerialization, "failed to marshal address for seal verification challenge")

svInfoRandomness := rt.GetRandomnessFromTickets(crypto.DomainSeparationTag_SealRandomness, params.SealRandEpoch, buf.Bytes())
svInfoInteractiveRandomness := rt.GetRandomnessFromBeacon(crypto.DomainSeparationTag_InteractiveSealChallengeSeed, params.InteractiveEpoch, buf.Bytes())

return &proof.SealVerifyInfo{
SealProof: params.RegisteredSealProof,
SectorID: abi.SectorID{
Miner:  abi.ActorID(minerActorID),
Number: params.SectorNumber,
},
DealIDs:               params.DealIDs,
InteractiveRandomness: abi.InteractiveSealRandomness(svInfoInteractiveRandomness),
Proof:                 params.Proof,
Randomness:            abi.SealRandomness(svInfoRandomness),
SealedCID:             params.SealedCID,
UnsealedCID:           commD,
}
}

// Requests the storage market actor compute the unsealed sector CID from a sector's deals.
func requestUnsealedSectorCID(rt Runtime, proofType abi.RegisteredSealProof, dealIDs []abi.DealID) cid.Cid {
var unsealedCID cbg.CborCid
code := rt.Send(
builtin.MethodsMarket.ComputeDataCommitment,
&market.ComputeDataCommitmentParams{
SectorType: proofType,
DealIDs:    dealIDs,
},
abi.NewTokenAmount(0),
&unsealedCID,
)
builtin.RequireSuccess(rt, code, "failed request for unsealed sector CID for deals %v", dealIDs)
return cid.Cid(unsealedCID)
}

func requestDealWeight(rt Runtime, dealIDs []abi.DealID, sectorStart, sectorExpiry abi.ChainEpoch) market.VerifyDealsForActivationReturn {
if len(dealIDs) == 0 {
return market.VerifyDealsForActivationReturn{
DealWeight:         big.Zero(),
VerifiedDealWeight: big.Zero(),
}
}

var dealWeights market.VerifyDealsForActivationReturn

code := rt.Send(
builtin.MethodsMarket.VerifyDealsForActivation,
&market.VerifyDealsForActivationParams{
DealIDs:      dealIDs,
SectorStart:  sectorStart,
SectorExpiry: sectorExpiry,
},
abi.NewTokenAmount(0),
&dealWeights,
)
builtin.RequireSuccess(rt, code, "failed to verify deals and get deal weight")
return dealWeights
}

// Requests the current epoch target block reward from the reward actor.
// return value includes reward, smoothed estimate of reward, and baseline power
func requestCurrentEpochBlockReward(rt Runtime) reward.ThisEpochRewardReturn {
var ret reward.ThisEpochRewardReturn
code := rt.Send(builtin.RewardActorAddr, builtin.MethodsReward.ThisEpochReward, nil, big.Zero(), &ret)
builtin.RequireSuccess(rt, code, "failed to check epoch baseline power")
return ret
}

// Requests the current network total power and pledge from the power actor.
func requestCurrentTotalPower(rt Runtime) *power.CurrentTotalPowerReturn {
var pwr power.CurrentTotalPowerReturn
code := rt.Send(builtin.StoragePowerActorAddr, builtin.MethodsPower.CurrentTotalPower, nil, big.Zero(), &pwr)
builtin.RequireSuccess(rt, code, "failed to check current power")
return &pwr
}

// Resolves an address to an ID address and verifies that it is address of an account or multisig actor.
if !ok {
rt.Abortf(exitcode.ErrIllegalArgument, "unable to resolve address %v", raw)
}

ownerCode, ok := rt.GetActorCodeCID(resolved)
if !ok {
rt.Abortf(exitcode.ErrIllegalArgument, "no code for address %v", resolved)
}
if !builtin.IsPrincipal(ownerCode) {
rt.Abortf(exitcode.ErrIllegalArgument, "owner actor type must be a principal, was %v", ownerCode)
}
return resolved
}

// Resolves an address to an ID address and verifies that it is address of an account actor with an associated BLS key.
// The worker must be BLS since the worker key will be used alongside a BLS-VRF.
if !ok {
rt.Abortf(exitcode.ErrIllegalArgument, "unable to resolve address %v", raw)
}

workerCode, ok := rt.GetActorCodeCID(resolved)
if !ok {
rt.Abortf(exitcode.ErrIllegalArgument, "no code for address %v", resolved)
}
if workerCode != builtin.AccountActorCodeID {
rt.Abortf(exitcode.ErrIllegalArgument, "worker actor type must be an account, was %v", workerCode)
}

code := rt.Send(resolved, builtin.MethodsAccount.PubkeyAddress, nil, big.Zero(), &pubkey)
builtin.RequireSuccess(rt, code, "failed to fetch account pubkey from %v", resolved)
rt.Abortf(exitcode.ErrIllegalArgument, "worker account %v must have BLS pubkey, was %v", resolved, pubkey.Protocol())
}
}
return resolved
}

func burnFunds(rt Runtime, amt abi.TokenAmount) {
if amt.GreaterThan(big.Zero()) {
builtin.RequireSuccess(rt, code, "failed to burn funds")
}
}

func notifyPledgeChanged(rt Runtime, pledgeDelta abi.TokenAmount) {
if !pledgeDelta.IsZero() {
builtin.RequireSuccess(rt, code, "failed to update total pledge")
}
}

// Assigns proving period offset randomly in the range [0, WPoStProvingPeriod) by hashing
// the actor's address and current epoch.
offsetSeed := bytes.Buffer{}
if err != nil {
return 0, fmt.Errorf("failed to serialize address: %w", err)
}

err = binary.Write(&offsetSeed, binary.BigEndian, currEpoch)
if err != nil {
return 0, fmt.Errorf("failed to serialize epoch: %w", err)
}

digest := hash(offsetSeed.Bytes())
var offset uint64
if err != nil {
return 0, fmt.Errorf("failed to interpret digest: %w", err)
}

offset = offset % uint64(WPoStProvingPeriod)
return abi.ChainEpoch(offset), nil
}

// Computes the epoch at which a proving period should start such that it is greater than the current epoch, and
// has a defined offset from being an exact multiple of WPoStProvingPeriod.
// A miner is exempt from Winow PoSt until the first full proving period starts.
func currentProvingPeriodStart(currEpoch abi.ChainEpoch, offset abi.ChainEpoch) abi.ChainEpoch {
currModulus := currEpoch % WPoStProvingPeriod
var periodProgress abi.ChainEpoch // How far ahead is currEpoch from previous offset boundary.
if currModulus >= offset {
periodProgress = currModulus - offset
} else {
periodProgress = WPoStProvingPeriod - (offset - currModulus)
}

periodStart := currEpoch - periodProgress
Assert(periodStart <= currEpoch)
return periodStart
}

// Computes the deadline index for the current epoch for a given period start.
// currEpoch must be within the proving period that starts at provingPeriodStart to produce a valid index.
func currentDeadlineIndex(currEpoch abi.ChainEpoch, periodStart abi.ChainEpoch) uint64 {
Assert(currEpoch >= periodStart)
return uint64((currEpoch - periodStart) / WPoStChallengeWindow)
}

func asMapBySectorNumber(sectors []*SectorOnChainInfo) map[abi.SectorNumber]*SectorOnChainInfo {
m := make(map[abi.SectorNumber]*SectorOnChainInfo, len(sectors))
for _, s := range sectors {
m[s.SectorNumber] = s
}
return m
}

func replacedSectorParameters(rt Runtime, precommit *SectorPreCommitOnChainInfo,
replacedByNum map[abi.SectorNumber]*SectorOnChainInfo) (pledge abi.TokenAmount, age abi.ChainEpoch, dayReward big.Int) {
if !precommit.Info.ReplaceCapacity {
return big.Zero(), abi.ChainEpoch(0), big.Zero()
}
replaced, ok := replacedByNum[precommit.Info.ReplaceSectorNumber]
if !ok {
rt.Abortf(exitcode.ErrNotFound, "no such sector %v to replace", precommit.Info.ReplaceSectorNumber)
}
// The sector will actually be active for the period between activation and its next proving deadline,
// but this covers the period for which we will be looking to the old sector for termination fees.
return replaced.InitialPledge,
maxEpoch(0, rt.CurrEpoch()-replaced.Activation),
replaced.ExpectedDayReward
}

// Update worker address with pending worker key if exists and delay has passed
func processPendingWorker(info *MinerInfo, rt Runtime, st *State) {
if info.PendingWorkerKey == nil || rt.CurrEpoch() < info.PendingWorkerKey.EffectiveAt {
return
}

info.Worker = info.PendingWorkerKey.NewWorker
info.PendingWorkerKey = nil

builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "could not save miner info")
}

// Computes deadline information for a fault or recovery declaration.
// If the deadline has not yet elapsed, the declaration is taken as being for the current proving period.
// If the deadline has elapsed, it's instead taken as being for the next proving period after the current epoch.
}

}

// Checks that a fault or recovery declaration at a specific deadline is outside the exclusion window for the deadline.
return fmt.Errorf("late fault or recovery declaration at %v", deadline)
}
return nil
}

// Validates that a partition contains the given sectors.
func validatePartitionContainsSectors(partition *Partition, sectors bitfield.BitField) error {
// Check that the declared sectors are actually assigned to the partition.
contains, err := BitFieldContainsAll(partition.Sectors, sectors)
if err != nil {
return xerrors.Errorf("failed to check sectors: %w", err)
}
if !contains {
return xerrors.Errorf("not all sectors are assigned to the partition")
}
return nil
}

func terminationPenalty(sectorSize abi.SectorSize, currEpoch abi.ChainEpoch,
rewardEstimate, networkQAPowerEstimate smoothing.FilterEstimate, sectors []*SectorOnChainInfo) abi.TokenAmount {
totalFee := big.Zero()
for _, s := range sectors {
sectorPower := QAPowerForSector(sectorSize, s)
fee := PledgePenaltyForTermination(s.ExpectedDayReward, currEpoch-s.Activation, s.ExpectedStoragePledge,
networkQAPowerEstimate, sectorPower, rewardEstimate, s.ReplacedDayReward, s.ReplacedSectorAge)
}
}

func PowerForSector(sectorSize abi.SectorSize, sector *SectorOnChainInfo) PowerPair {
return PowerPair{
Raw: big.NewIntUnsigned(uint64(sectorSize)),
QA:  QAPowerForSector(sectorSize, sector),
}
}

// Returns the sum of the raw byte and quality-adjusted power for sectors.
func PowerForSectors(ssize abi.SectorSize, sectors []*SectorOnChainInfo) PowerPair {
qa := big.Zero()
for _, s := range sectors {
}

return PowerPair{
Raw: big.Mul(big.NewIntUnsigned(uint64(ssize)), big.NewIntUnsigned(uint64(len(sectors)))),
QA:  qa,
}
}

func ConsensusFaultActive(info *MinerInfo, currEpoch abi.ChainEpoch) bool {
// For penalization period to last for exactly finality epochs
// consensus faults are active until currEpoch exceeds ConsensusFaultElapsed
return currEpoch <= info.ConsensusFaultElapsed
}

func getMinerInfo(rt Runtime, st *State) *MinerInfo {
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "could not read miner info")
return info
}

func min64(a, b uint64) uint64 {
if a < b {
return a
}
return b
}

func max64(a, b uint64) uint64 {
if a > b {
return a
}
return b
}

func minEpoch(a, b abi.ChainEpoch) abi.ChainEpoch {
if a < b {
return a
}
return b
}

func maxEpoch(a, b abi.ChainEpoch) abi.ChainEpoch {
if a > b {
return a
}
return b
}

}
}

if len(peerID) > MaxPeerIDLength {
rt.Abortf(exitcode.ErrIllegalArgument, "peer ID size of %d exceeds maximum size of %d", peerID, MaxPeerIDLength)
}

totalSize := 0
for _, ma := range multiaddrs {
if len(ma) == 0 {
}
totalSize += len(ma)
}
}
}


### Miner CollateralsState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.miner_collaterals

Most permissionless blockchain networks require upfront investment in resources in order to participate in the consensus. The more power an entity has on the network, the greater the share of total resources it needs to own, both in terms of physical resources and/or staked tokens (collateral).

Filecoin must achieve security via the dedication of resources. By design, Filecoin mining requires commercial hardware only (as opposed to ASIC hardware) that is cheap in amortized cost and easy to repurpose, which means the protocol cannot solely rely on the hardware as the capital investment at stake for attackers. Filecoin also uses upfront token collaterals, as in proof-of-stake protocols, proportional to the storage hardware committed. This gets the best of both worlds: attacking the network requires both acquiring and running the hardware, but it also requires acquiring large quantities of the token.

To satisfy the multiple needs for collateral in a way that is minimally burdensome to miners, Filecoin includes three different collateral mechanisms: initial pledge collateral, block reward as collateral, and storage deal provider collateral. The first is an initial commitment of filecoin that a miner must provide with each sector. The second is a mechanism to reduce the initial token commitment by vesting block rewards over time. The third aligns incentives between miner and client, and can allow miners to differentiate themselves in the market. The remainder of this subsection describes each in more detail.

#### Initial Pledge CollateralState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.miner_collaterals.initial-pledge-collateral

Filecoin Miners must commit resources in order to participate in the economy; the protocol can use the minersʼ stake in the network to ensure that rational behavior benefits the network, rewarding the creation of value and penalizing malicious behavior via slashing. The pledge size is meant to adequately incentivize the fulfillment of a sectorʼs promised lifetime and provide sufficient consensus security.

Hence, the initial pledge function consists of two components: a storage pledge and a consensus pledge.

$SectorInitialPledge = SectorInitialStoragePledge + SectorInitialConsensusPledge$

The storage pledge protects the networkʼs quality-of-service for clients by providing starting collateral for the sector in the event of slashing. The storage pledge must be small enough to be feasible for miners joining the network, and large enough to collateralize storage against early faults, penalties, and fees. The vesting of block rewards and the use of unvested rewards as additional collateral reduces initial storage pledge without compromising the incentive alignment of the network. This is discussed in more depth in the following subsection. A balance is achieved by using an initial storage pledge amount approximately sufficient to cover 7 days worth of Sector fault fee and 1 Sector fault detection fee. This is denominated in the number of days of future rewards that a sector is expected to earn.

$SectorInitialStoragePledge = Estimated20DaysSectorBlockReward$

Since the storage pledge per sector is based on the expected block reward that sector will win, the storage pledge is independent of the networkʼs total storage. As a result, the total network storage pledge depends solely on future block reward. Thus, while the storage pledge provides a clean way to reason about the rationality of adding a sector, it does not provide sufficient long-term security guarantees to the network, making consensus takeovers less costly as the block reward decreases. As such, the second half of the initial pledge function, the consensus pledge, depends on both the amount of quality-adjusted power (QAP) added by the sector and the network circulating supply. The network targets approximately 30% of the network’s circulating supply locked up in initial consensus pledge when it is at or above the baseline. This is achieved with a small pledge share allocated to sectors based on their share of the networkʼs quality-adjusted power. Given an exponentially growing baseline, initial pledge per unit QAP should decrease over time, as should other mining costs.

$SectorInitialConsensusPledge = 30\% \times FILCirculatingSupply \times \frac{SectorQAP}{max(NetworkBaseline, NetworkQAP)}$

#### Block Reward CollateralState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.miner_collaterals.block-reward-collateral

Clients need reliable storage. Under certain circumstances, miners might agree to a storage deal, then want to abandon it later as a result of increased costs or other market dynamics. A system where storage miners can freely or cheaply abandon files would drive clients away from Filecoin as a result of serious data loss and low quality of service. To make sure all the incentives are correctly aligned, Filecoin penalizes miners that fail to store files for the promised duration. As such, high collateral could be used to incentivize good behavior and improve the networkʼs quality of service. On the other hand, however, high collateral creates barriers to miners joining the network. Filecoin’s constructions have been designed such that they hit the right balance.

In order to reduce the upfront collateral that a miner needs to provide, the block reward is used as collateral. This allows the protocol to require a smaller but still meaningful initial pledge. Block rewards earned by a sector are subject to slashing if a sector is terminated before its expiration. However, due to chain state limitations, the protocol is unable to do accounting on a per sector level, which would be the most fair and accurate. Instead, the chain performs a per-miner level approximation. Sublinear vesting provides a strong guarantee that miners will always have the incentive to keep data stored until the deal expires and not earlier. An extreme vesting schedule would release all tokens that a sector earns only when the sector promise is fulfilled.

However, the protocol should provide liquidity for miners to support their mining operations, and releasing rewards all at once creates supply impulses to the network. Moreover, there should not be a disincentive for longer sector lifetime if the vesting duration also depends on the lifetime of the sector. As a result, a fixed duration linear vesting for the rewards that a miner earns after a short delay creates the necessary sub-linearity. This sub-linearity has been introduced by the Initial Pledge.

In general, fault fees are slashed first from the soonest-to-vest unvested block rewards followed by the minerʼs account balance. When a minerʼs balance is insufficient to cover their minimum requirements, their ability to participate in consensus, win block rewards, and grow storage power will be restricted until their balance is restored. Overall, this reduces the initial pledge requirement and creates a sufficient economic deterrent for faults without slashing the miner’s balance for every penalty.

#### Storage Deal CollateralState reliableTheory Audit n/aEdit this sectionsection-systems.filecoin_mining.miner_collaterals.storage-deal-collateral

The third form of collateral is provided by the storage provider to collateralize deals. See the