This document describes how to integrate lotus into any sealing service architecture

The sealing process

The process of sealing a sector consists from a number of relatively simple steps:

• (non-cc) Gather deal data
• Assign a sector number
• Get seal randomness (Ticket)
• Perform PreCommit1 (TreeD + Generating SDR Labels)
• Perform PreCommit2 (Encode Sealed/TreeRLast + TreeC)
• Send a PreCommit message to the on-chain miner actor
• Wait for PreCommitChallengeDelay epochs (150 on mainnet)
• Generate interactive challenge seed (Seed)
• Perform Commit1 (Read vanilla PoRep proof)
• Perform Commit2 (Generate PoRep snark of the generated vanilla proof)
• Send a Commit message to the on-chain miner actor

Gathering deal data

In this step the unsealed sector file is created. This file contains fr32 padded data to be sealed

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 preserved 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.