Profile FVM Gas With Local Lotus

[wjmelements]

The current approach is to use forge script --broadcast.
Rationale
The profile script covers some of the basic Payment operations.
The scripts are run sequentially to ensure that time has passed.

Changes

• add Profile.s.sol and profile.sh
• make .gas-report with https://github.com/FilOzone/forge-script-gas-report
• eliminate gas variance
• TODO compare localnet to itest/ensemble approach
• TODO gas-profile GH Action

[wjmelements]

One gas variance I have seen is +1300 in the last settleRail. I do not yet know the cause. Dumping the receipts of that run here:

• createRail-latest.json
• settleRail-latest.json
• terminateRail-latest.json

[wjmelements]

Seen again, uploading receipts here

One gas variance I have seen is +1300 in the last settleRail. I do not yet know the cause. Dumping the receipts of that run here:

• createRail-latest.json
• settleRail-latest.json
• terminateRail-latest.json

[wjmelements]

A less-common gasUsed variation is much larger and impacts all of the transactions after the first modifyRailPayment.

-modifyRailLockup: 20489814
-modifyRailPayment: 23862826
-settleRail: 17961981
-withdraw: 21977789
-withdrawTo: 22062638
-settleRail: 27102987
-terminateRail: 19583955
+modifyRailLockup: 22141740
+modifyRailPayment: 25693249
+settleRail: 18552881
+withdraw: 22567509
+withdrawTo: 22652358
+settleRail: 33362475
+terminateRail: 20517410

• createRail-latest.json

• settleRail-latest.json

• terminateRail-latest.json

[wjmelements]

sleeping works around filecoin-project/lotus#13247 by advancing to the next block.

[wjmelements]

Another workaround might be vm.etch.

[wjmelements]

A less-common gasUsed variation is much larger and impacts all of the transactions after the first modifyRailPayment.

This happens when the blockNumber unexpectedly changes between transactions (in this case after the first modifyRailPayment). This can be detected fairly easily. I will want to verify that all of the transactions in a script happen in the same block.

[wjmelements]

One gas variance I have seen is +1300 in the last settleRail.

Looks like this happens deterministically now, so that's good.

[wjmelements]

The itest approach looks fairly simple and will probably startup and run faster.

    blockTime := 100 * time.Millisecond
    client, _, ens := kit.EnsembleMinimal(t, kit.MockProofs(), kit.ThroughRPC())
    ens.InterconnectAll().BeginMining(blockTime)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@           Coverage Diff           @@
##             main     #207   +/-   ##
=======================================
  Coverage        ?   75.83%           
=======================================
  Files           ?        5           
  Lines           ?      538           
  Branches        ?      107           
=======================================
  Hits            ?      408           
  Misses          ?      125           
  Partials        ?        5           

Flag	Coverage Δ
foundry	75.83% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wjmelements]

one problem with the -g 44000 approach is that the FVM penalizes you for overestimating gas. Really we should do our own eth_estimateGas without simulating EVM.

Maybe we should not use forge script. That would be too bad because it has a great framework; you can use solidity and it transforms the broadcasted calls into transactions.

[wjmelements]

A new constraint on forge script viability: because it requires --skip-simulation and therefore uses eth_estimateGas, it runs each transaction sequentially, one every two blocks. Reducing the block time will be essential.