feat(miner): remove batch balancer-related functionality

[tediou5]

Related Issues

close #12902

Proposed Changes

Removed BatchPreCommitAboveBaseFee, AggregateAboveBaseFee, and the related checks.

The MinCommitBatch is actually constrained by the SNARK circuits, so it will remain at 4 without change:

• You need 4 or more sectors to ensure that the verification time for aggregated proofs is smaller than for batched proofs.

• You need 13 sectors or more to ensure that the aggregated proof size is smaller than the batched proof size.

The MaxCommitBatch limit comes from the original (FIP-0013), and it seems there's not much incentive to modify it, so these two parameters will remain unchanged.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[BigLep]

@tediou5 : no pressure, but is this ready for review? If so, lets move it out of draft to make it clear. Thanks.

[BigLep]

@tediou5 : thanks for working on this. We wanted to make sure you saw #12902 (comment)

[tediou5]

@tediou5 : thanks for working on this. We wanted to make sure you saw #12902 (comment)

@BigLep Got it, let me check the part of aggregation.

[tediou5]

@BigLep Yes, I think it's ready for review now. I'd like to get some feedback as well since I'm not very familiar with this part of the code, and I'm a bit worried I might have missed something.

[Stebalien]

Please run make gen and commit the results.

Also, this appears to now be submitting batches that are too large (See the failing tests):

batch of 1000 too large, max 256

I think this is the max batch size for precommit?

[rvagg]

Sorry for the delay in bringing up this important point: I think we're going to have to retain all of this functionality but gate it behind a network version check, at least until the feature is live (nv25?), then we can remove it. The problem is that if we roll out a version of lotus-miner with all of this removed, we're either going to throw users to the wolves of not having this functionality in place during a period where there is the batch balancer in operation (nv24), or advise them to upgrade just after the upgrade that activates FIP-0100.

So instead, we should:

• Retain the config settings but mark them clearly as DEPRECATED and note they will be removed in the next release
• Gate everything with a call to StateNetworkVersion and do a if nv < network.Version25 around everything that involves the batch balancer.

e.g.

• lotus/storage/wdpost/wdpost_run.go

  Lines 229 to 230 in a474d45

  	// TODO: Drop after nv19 comes and goes
  	if nv >= network.Version19 {

  for 1.1 proofs

• lotus/storage/pipeline/piece/piece_info.go

  Lines 81 to 84 in a474d45

  	if hasPieceActivationManifest {
  	if nv < network.Version22 {
  	return xerrors.Errorf("direct-data-onboarding pieces aren't accepted before network version 22")
  	}

  for PCS3

• lotus/storage/pipeline/states_sealing.go

  Line 41 in a474d45

  const MinDDONetworkVersion = network.Version22

  remnant of the DDO PCS3 pipeline that hasn't been removed

^ we should go through and remove all of these too, in a separate PR

[BigLep]

@tediou5 : do you think you'll be able to make the updates so we can get this merged by the end of the week (2025-03-14) so an RC can be cut at the beginning of next week (2025-03-17)?

[tediou5]

@tediou5 : do you think you'll be able to make the updates so we can get this merged by the end of the week (2025-03-14) so an RC can be cut at the beginning of next week (2025-03-17)?

@BigLep I think I can get it done. Let me give it a try.

[tediou5]

@Stebalien @rvagg @BigLep Restored the previous logic and now execute it conditionally based on the network version.

[tediou5]

Thank you for your review.

[BigLep]

@tediou5 : I'm trying to follow where this is at. Has all feedback been incorporated except for where you have questions?

[Stebalien]

LGTM. We're going to need to do this the right way without hard-coded constants, but this PR has the MVP for the upgrade.

[tediou5]

LGTM. We're going to need to do this the right way without hard-coded constants, but this PR has the MVP for the upgrade.

Yes, I agree. I prefer to estimate gas so that messages are only constrained by MaxBlockGasLimit rather than a fixed constant. But I think I'll submit this in a separate PR.