Add a batched PreCommitSectors method about fips

[anorth]

Economies of scale are real. We can't pretend they don't exist just because that's "unfair" to parties that don't have the scale to enjoy them. This is a very minor one in the big picture of Filecoin mining. Economies of scale is the very premise behind Filecoin's vision of abundant cheap storage. We should lean into them and get as much as possible!

As @nicola says, this will make no difference to the high growth rate of the network. High-growth miners are much more likely to be limited by cost of sealing hardware than the gas cost of pre-commits, so reducing that gas cost won't change anything except making the whole network's consensus more efficient and freeing up bandwidth for other messages.

[anorth]

The FIP draft for this has landed (#27), but the team is generally agreed that we should postpone implementation until after first addressing Window PoSt affordability.

[ZenGround0]

@stuberman this is an implementation concern so your question will be best addressed by filing an issue with the implementation you are using (sounds like https://github.com/filecoin-project/lotus is the right place)

[jennijuju]

It is not clear to me whether the pre commit batch affects sealing. While precommit commit messages are waiting for release (expiration of "PreCommitBatchWait") are those sectors held from further processing/sealing? As an example is PreCommitBatchWait = 8 hours will PC2 sectors queue up on sealing disks until the timer expires? If so, miners will need to be advised to set the wait timer low enough to not run out of disk capacity and cause worker to idle waiting for timer to expire.

Also can be a great question for next weeks deep dive AMA!

[anorth]

ProveCommitSector could also be batched, but that's a separate discussion. There is already a complex set-up around batching the proof verifications until the end of each epoch, and that discussion should start there.

[nicola]

I approve the spirit of this change.

One thing to note is that in the future (may not belong to this FIP), a PreCommitBatched could contain PreCommits from other miners and the batched method would be verifying the signature on those PreCommits (similarly to what we do for deals).

In this way, smaller miners could get together to jointly submit PreCommits.

[zixuanzh]

I mentioned during all dev that batched precommits may give miners with high sealing throughput an advantage over miners who are smaller in scale. It is unclear if the cost saving is worth the tradeoff. On second thought, the number of sectors that we are batching is probably small enough that it wouldn't make much of a difference. Can we quantify the difference? Of course allowing different miners' PreCommits to batch will be great but that's also extra work and hurdle that presents challenges to smaller miners.

[nicola]

This FIP ensures that a miner can organize their PreCommits so that they can amortize their gas costs. The gas saving is pretty substantial. For example if you submit 32 sectors instead of 1, you may end up paying ~32x less gas (likely less than that).

This is a good concern, but since this is a "one-off" cost, I dont think this will have major impact in the total cost of mining of a small miner vs larger miner.

Extending this FIP in the future to support PreCommit from multiple miners will only benefit the miners.

[zixuanzh]

It's a "one-off" cost that can be incurred repeatedly and the cost savings can add up, e.g. a miner who can submit 32 sectors at a time has a cost advantage over miners who can't. This is a structural force that can advantage larger miners more than smaller ones. However, I can be convinced if most miners can comfortably submit 32 sectors at a time.

[nicola]

Let me put it differently, the goal here is to reduce gas spent and not cost.

1. We can make the batched operation to cost the same amount of $, but to consume less gas
2. We can show that this fee does benefit large miners, but really little. For example, if this is a 1% cost reduction is that too much to favor large miners?

[zixuanzh]

Thinking about this more, I think introducing this FIP at this moment will do more harm to the network than the potential cost savings it brings. The network is onboarding more than 15 PiB per day but most of that storage is not useful and it takes time to build applications on the network. In addition, FIP5 is already making PreCommit cheaper so committing storage is not too expensive or too slow per se. We can revisit this FIP in a few months once demand for storage on Filecoin has picked up (Filecoin Plus is operating successfully) and more applications are built on Filecoin. If teams want to push for this FIP, we should push harder on the other fronts first. We should however make it cheaper to do SubmitWindowPoSt and PublishStorageDeals.

[nicola]

The fact that the network is on-boarding 15PiB per day (of which most of it is not useful) won't change with this fix; this FIPs makes sure that even if the network onboards 15PiB, ~1/3 (IIRC) of the block is freer than currently. If we don't do this, fees could increase for everyone.

What would be the list of questions that we should answer to gain confidence on this?

As I said before, having a node that aggregates PreCommit from multiple miners could also be done - although more complex.

[nicola]

We should land this at the same time or after we land ProveCommitBatched. The reason is that the decreased cost in PreCommitBatched could lead miners to think that they could submit many times more PreCommits, and this will lead to a more congested chain.

[nicola]

We finally have a more affordable WindowPoSt.

PreCommit is currently 23% of the gas used. This FIP would be great in combination with FIP0013!

[stuberman]

It is not clear to me whether the pre commit batch affects sealing. While precommit commit messages are waiting for release (expiration of "PreCommitBatchWait") are those sectors held from further processing/sealing? As an example is PreCommitBatchWait = 8 hours will PC2 sectors queue up on sealing disks until the timer expires? If so, miners will need to be advised to set the wait timer low enough to not run out of disk capacity and cause worker to idle waiting for timer to expire.

[kaitlin-beegle]

Tagged inactive due to the passage of FIP0008.