Lotus has a lot of advanced configurations you can tune to optimize your storage provider setup. This guide explains the advanced configuration options for lotus market
This section controls parameters for making storage and retrieval deals:
[Dealmaking] # When enabled, the miner can accept online deals ConsiderOnlineStorageDeals = true # When enabled, the miner can accept offline deals ConsiderOfflineStorageDeals = true # When enabled, the miner can accept retrieval deals ConsiderOnlineRetrievalDeals = true # When enabled, the miner can accept offline retrieval deals ConsiderOfflineRetrievalDeals = true # When enabled, the miner can accept verified deals ConsiderVerifiedStorageDeals = true # When enabled, the miner can accept unverified deals ConsiderUnverifiedStorageDeals = true # A list made of Data CIDs to reject when making deals PieceCidBlocklist =  # Maximum expected amount of time getting the deal into a sealed sector will take # This includes the time the deal will need to get transferred and published # before being assigned to a sector # for more info, see below. ExpectedSealDuration = "24h0m0s" # When a deal is ready to publish, the amount of time to wait for more # deals to be ready to publish before publishing them all as a batch PublishMsgPeriod = "1h0m0s" # The maximum number of deals to include in a single publish deals message MaxDealsPerPublishMsg = 8 # A command used for fine-grained evaluation of storage deals (see below) Filter = "/absolute/path/to/storage_filter_program" # A command used for fine-grained evaluation of retrieval deals (see below) RetrievalFilter = "/absolute/path/to/retrieval_filter_program"
ExpectedSealDuration is an estimate of how long sealing will take and is used to reject deals whose start epoch might be earlier than the expected completion of sealing. It can be estimated by benchmarking or by pledging a sector.
(TIME_TO_SEAL_A_SECTOR + WaitDealsDelay) * 1.5. This equation ensures that the miner does not commit to having the sector sealed too soon.
lotus-miner to seal a sector before a certain epoch. For example: if the current epoch is 1000 and a deal within a sector must start on epoch 1500, then
lotus-miner must wait until the current epoch is 1500 before it can start sealing that sector. However, if
StartEpochSealingBuffer to 500, the
lotus-miner can start sealing the sector at epoch 1000.
If there are multiple deals in a sector, the deal with a start time closest to the current epoch is what
StartEpochSealingBuffer will be based off. So, if the sector in our example has three deals that start on epoch 1000, 1200, and 1400, then we
lotus-miner will start sealing the sector at epoch 500.
Disabling new sector for deal
MakeNewSectorForDeals is set to
lotus-miner will create new sectors for incoming deals. This option can set to
false to ensure that all new deals are sealed as snap-deals into CC sectors. This can help reduce the sealing time for the new deals as long as CC sectors are ready for the snap-deals.
Make new CC sector available for snap-deal
MakeCCSectorsAvailable makes all the new CC sectors available to be upgraded with snap-deals. When this boolean is set to
true, all pledged “CC” sectors from that point onwards will be converted to “Available” state after sealing. This enables sealing the incoming storage deals more quickly into these “Available” sectors compared to creating a new sector for the deals.
Publishing several deals in one message
PublishStorageDeals message can publish multiple deals in a single message.
When a deal is ready to be published, Lotus will wait up to
for other deals to be ready before sending the
MaxDealsPerPublishMsg is ready, Lotus will immediately publish all the deals.
For example, if
PublishMsgPeriod is 1 hour:
- At 1:00 pm, deal 1 is ready to publish. Lotus will wait until 2:00 pm for other deals to be ready before sending
- At 1:30 pm, Deal 2 is ready to publish
- At 1:45 pm, Deal 3 is ready to publish
- At 2:00pm, lotus publishes Deals 1, 2, and 3 in a single
MaxDealsPerPublishMsg is 2, then in the above example, when deal 2 is ready to be published at 1:30, Lotus would immediately publish Deals 1 & 2 in a single
PublishStorageDeals message. Deal 3 would be published in a subsequent
PublishStorageDealsfails validation upon execution, or if the start epoch has passed, all deals will fail to be published.
Using filters for fine-grained storage and retrieval deal acceptance
Your use case might demand very precise and dynamic control over a combination of deal parameters.
Lotus provides two IPC hooks allowing you to name a command to execute for every deal before the miner accepts it:
Filterfor storage deals.
RetrievalFilterfor retrieval deals.
The executed command receives a JSON representation of the deal parameters on standard input, and upon completion, its exit code is interpreted as:
0: success, proceed with the deal.
non-0: failure, reject the deal.
The most trivial filter rejecting any retrieval deal would be something like:
RetrievalFilter = "/bin/false".
/bin/false is binary that immediately exits with a code of
This Perl script lets the miner deny specific clients and only accept deals that are set to start relatively soon.
You can also use a third party content policy framework like
bitscreen by Murmuration Labs:
# grab filter program go get -u -v github.com/Murmuration-Labs/bitscreen # add it to both filters Filter = "/path/to/go/bin/bitscreen" RetrievalFilter = "/path/to/go/bin/bitscreen"