Block Producer

• State reliable
• Theory Audit wip
• Edit this section
• section-systems.filecoin_blockchain.struct.block_producer

Mining Blocks

• State reliable
• Theory Audit wip
• Edit this section
• section-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 Creation

• State reliable
• Theory Audit wip
• Edit this section
• section-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 Broadcast

• State reliable
• Theory Audit wip
• Edit this section
• section-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 Rewards

• State reliable
• Theory Audit wip
• Edit this section
• section-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.