Raise max partitions proven in SubmitWindowedPoSt

[Stebalien]

Currently, at most 4 partitions can be proven at once because disputing this proof might need to touch each and every sector in the partitions.

We should consider raising this based on actual estimated gas usage:

1. Try raising this to 8, then maybe 16?
2. Determine gas savings for SubmitWindowedPoSt. This must be done with on-chain data (ideally from a large miner) to get reasonable results:
   1. Take an existing sequence of SubmitWindowedPoSt messages (likely from the largest miner).
   2. Combine them (and concatenate proofs).
   3. No-op the actual proof verification (won't work).
   4. Run a gas estimation and compare.
3. Make sure these proofs can still be disputed.
   1. Locally dispute a window post proof to determine the cost.
   2. Multiply by 2 (8 partitions) and 4 (16 partitions) to make sure that gas still fits within a block (comfortably).

Once we have results, we can consider raising the max. Actually making this change should be trivial.

[Stebalien]

For part 3:

This proof: https://www.filscout.com/en/message/bafy2bzaceamlv2yn7qdav2qnsuwpe26spq3aqi5l2j55nscvhakvoaqtwabjo

Was disputed in https://www.filscout.com/en/message/bafy2bzacedp562nybzbx2573ggx3ixawr7uuaoew3gzlyzl37hc5cil2zpx24.

It proved 3 partitions (I'm assuming one wasn't full) with a gas limit of 638605038. Assuming 2 full partitions to be safe, we can probably "safely" dispute:

2*(10_000_000_000/638_605_038) => 31 (ish) partitions.

Therefore, I wouldn't go over 16 partitions. Really, I'd prefer to stick with 8 for now.

[anorth]

Thanks for that. How about 10 partitions?

[anorth]

For part 2, while I concur that would be a good process to quantify the savings, I don't think we should block making a change like this on that quantification. It's obviously an efficiency gain. Even if small, let's just take it. The initial value for this was set arbitrarily (by me), not based on any quantitative reasoning.

[Stebalien]

Thanks for that. How about 10 partitions?

That should be fine. It's just not an even number :cry:.

For part 2, while I concur that would be a good process to quantify the savings, I don't think we should block making a change like this on that quantification. It's obviously an efficiency gain. Even if small, let's just take it. The initial value for this was set arbitrarily (by me), not based on any quantitative reasoning.

You're right. I mostly wanted that so we could calculate how much room this would give us. But we can also just "wait and see", then calculate. It's not like we're going to stop upgrading.