Optimize gas usage for ExtendClaimTerms

[rjan90]

The ExtendClaimTerms message seems to consumes a significant amount of gas, and with enough claims, it seems like it can be the sole transaction in a block and reducing chain throughput.

Example of such a period: 2025-01-16T16:59-2025-01-16T18:27. As seen in the provided screenshot, most blocks in the epochs here consisted of just of a single message, which was large ExtendClaimTerms messages.

Example of one such messages extending 600 Claims: https://filscan.io/en/message/bafy2bzaced33vg7rtqc3rlhnyvsz5xxptd4d6obvunpd3nxwikx5rcqhfi4qk

Gas Used:
9,175,608,799

[rjan90]

Output of --gas-stats:

./lotus-shed msg --show-message=false --gas-stats bafy2bzaced33vg7rtqc3rlhnyvsz5xxptd4d6obvunpd3nxwikx5rcqhfi4qk
Message (f06) gas charges:
┌───────────────────────┬───────┬─────────────┬────────┬─────────────┬────────┬────────────┬────────┐
│ Type                  │ Count │ Storage Gas │     S% │ Compute Gas │     C% │  Total Gas │     T% │ 
├───────────────────────┼───────┼─────────────┼────────┼─────────────┼────────┼────────────┼────────┤
│ OnActorEvent          │   600 │     2053800 │   0.03 │    11386200 │   0.72 │   13440000 │   0.15 │ 
│ OnActorGetRoot        │     1 │           0 │   0.00 │         300 │   0.00 │        300 │   0.00 │ 
│ OnActorSetRoot        │     1 │           0 │   0.00 │         300 │   0.00 │        300 │   0.00 │ 
│ OnBlockCreate         │   811 │    14188038 │   0.19 │     6729456 │   0.43 │   20917494 │   0.23 │ 
│ OnBlockLink           │   810 │  7396077880 │  97.36 │    26180164 │   1.66 │ 7422258044 │  80.89 │ 
│ OnBlockOpen           │   810 │    19207720 │   0.25 │     1709100 │   0.11 │   20916820 │   0.23 │ 
│ OnBlockOpenBase       │   810 │   151826400 │   2.00 │      243000 │   0.02 │  152069400 │   1.66 │ 
│ OnBlockRead           │   811 │           0 │   0.00 │      840822 │   0.05 │     840822 │   0.01 │ 
│ OnBlockStat           │     1 │           0 │   0.00 │           0 │   0.00 │          0 │   0.00 │ 
│ OnChainMessage        │     1 │    13165600 │   0.17 │       38863 │   0.00 │   13204463 │   0.14 │ 
│ OnChainReturnValue    │     1 │        6500 │   0.00 │           0 │   0.00 │       6500 │   0.00 │ 
│ OnGetActorCodeCid     │     1 │           0 │   0.00 │           0 │   0.00 │          0 │   0.00 │ 
│ OnGetBuiltinActorType │     1 │           0 │   0.00 │           0 │   0.00 │          0 │   0.00 │ 
│ OnHashing             │  1202 │           0 │   0.00 │       25242 │   0.00 │      25242 │   0.00 │ 
│ OnMessageContext      │     1 │           0 │   0.00 │           0 │   0.00 │          0 │   0.00 │ 
│ OnMethodInvocation    │     1 │           0 │   0.00 │       75000 │   0.00 │      75000 │   0.00 │ 
│ OnScanIpldLinks       │  1621 │           0 │   0.00 │    38047690 │   2.41 │   38047690 │   0.41 │ 
│ OnSyscall             │  5051 │           0 │   0.00 │    70714000 │   4.48 │   70714000 │   0.77 │ 
│ wasm_exec             │  5053 │           0 │   0.00 │  1420343521 │  89.95 │ 1420343521 │  15.48 │ 
│ wasm_memory_grow      │    88 │           0 │   0.00 │     2306920 │   0.15 │    2306920 │   0.03 │ 
│ wasm_memory_init      │     1 │           0 │   0.00 │      445645 │   0.03 │     445645 │   0.00 │ 
│ Total                 │ 17677 │  7596525938 │ 100.00 │  1579086223 │ 100.00 │ 9175612161 │ 100.00 │ 
└───────────────────────┴───────┴─────────────┴────────┴─────────────┴────────┴────────────┴────────┘

[ZenGround0]

I don't think there is anything going wrong here. Someone wanted to pay for a full block's worth of gas for this message and an SP accepted the message. If we limited the batch size of the message the participant could instead pay for a collection of several messages to all take up the block. And big batches are globally good because they are more efficient. Splitting these extensions into multiple methods would have reduced the bandwidth of operations per gas.

Making FIL+ or the builtin market or the miner actor more efficient are always good things to do. And there are probably a number of ways we could do this at the cost of more complexity. But this message is not a good indication that we should focus on ExtendClaimTerms.