4337 Gas metering: Pimlico VerifyingPaymaster results, refactorings, groundwork for ERC20Paymaster

[remedcu]

This PR updates the Pimlico benchmarking code to use the new v0.7 entrypoint and the new paymaster from Pimlico. Partially fixes #294 (Partially because there are blockers related to the ERC20 Paymaster; I will describe them below)

Current Blockers For ERC20 Paymaster

• They use the official Circle's USDC deployments on testnets with no liquidity, and the faucet drips 10 USDC daily. One user op costs around 7.
• There are some problems with gas pricing. Currently, it wants roughly 7 USDC for a user operation on Base Sepolia (approximately 2x higher than the native token fee) and 537 USDC on Sepolia.

The Pimlico team have been informed regarding the same at the time of writing this issue. Slack Link.

Changes completed/in-progress

• Using base-sepolia as well (sepolia sometimes has a high gas cost)
• Using new signing struct with the latest 4337 Safe Module
• Update of dependencies used in the Pimlico benchmark
• Code refactors and type improvements
• NPM scripts now explicitly contain the paymaster they should use
• Addition of VERBOSE environment variable that outputs handy logging data to the console, which is very useful for debugging. Example

[coveralls]

Pull Request Test Coverage Report for Build 9098338109

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 9062559032:	0.0%
Covered Lines:	39
Relevant Lines:	39

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 9268898453

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 9250859802:	0.0%
Covered Lines:	39
Relevant Lines:	39

---

💛 - Coveralls

[mmv08]

Open question:
What do you think about removing this summary table? Reasons for doing so:

1. We duplicate the data in 3 places: summary table, individual table and logs in the individual benchmarks folders. It feels like an overhead
2. The table format makes it a nightmare to work with.
3. The cognitive overhead of comparing individual results is not crazy due to the low amount of entries.

[mmv08]

Alternatively, I'd remove the individual tables since the summary tables already contain a link to the detailed gas usage breakdown.

(Although I prefer the format of individual tables to this one)

[remedcu]

We went for both summary and individual table because the original requirement needed detailed information in each type (summary) and each part of the transaction (individual).

Though, we could remove the logs 👍🏾

[mmv08]

Fair enough, I'll remove them and update the summary table once I return next week. Or if you have capacity, I'd appreciate your help 👍

[nlordell]

Ideally, we would be able to do this programmatically instead of requiring multiple updates. Not in scope for this sprint, but some potential tech debt.

[remedcu]

Not sure if tenderly supports that, I have asked them in the channel.

[nlordell]

You should be able to do this without Tenderly. The entrypoint supports delegatecall simulations that could be used.

[mmv08]

New question related to the summary table @remedcu @nlordell:

The table uses the bundler’s ethereum transaction gas instead of the user operation gas used. Would it make sense to use the latter? Reason: To compare this number across the available bundlers, we’d require all bundlers to include only a single user op in a transaction, which can’t be guaranteed. Also, if the bundler decides to execute arbitrary logic (which affects the number, but we’re only paying for the user op) this would affect the comparison

Another example that highlights that transaction gas limit might not be what you're paying to the bundler:

ERC721 Minting User Op with Pimlico Verifying Paymaster:
Gas Used (Account or Paymaster): 170150
Gas Used (Transaction): 152766
The first number is the user operation, the second is the actual ethereum transaction

[remedcu]

With ERC20 Paymaster, using the user operation gas we paid for the user op makes sense. But with the gas policy one, using the former might be better as we are not paying the gas for that (at least directly in some cases, where the policy is sponsored by say a protocol or company) to make the sponsors aware if extra arbitrary logic is being executed with the transaction and which bundler's gas policy might be the right approach.

[mmv08]

I ran into some type issues after dependency updates and had to make this more specific

[mmv08]

I ran into some type issues after dependency updates and had to make this more specific

[mmv08]

I ran into some type issues after dependency updates and had to make this more specific

[mmv08]

I ran into some type issues after dependency updates and had to make this more specific

[mmv08]

I ran into some type issues after dependency updates and had to make this more specific

[mmv08]

Previously, it'd execute the module setup through a multisend, even if there was one transaction. I added a condition that it only does so if we need more than one setup transaction.

[mmv08]

Potential improvement: both getAccountInitCode and getAccountAddress compute the initializer, which is error-prone. If you mistakenly pass different data to one of them, they won't match.

[remedcu]

Suggested change

	VERBOSE = "True" # Set to "True" for verbose logging.
	VERBOSE = "true" # Set to "True" for verbose logging.

[remedcu]

Should we have a column specifying the Entrypoint version instead of in the name?

[mmv08]

I think the name is better because it is reusable for detailed runs and provides information about the entrypoint used. If we add a column and remove it from the name, then we'll have an open question about where to add it in the detailed breakdown

[remedcu]

Should we specify this is based on EntryPoint v0.7?

[mmv08]

I copied all the names to match 1:1