Move V2 wrapped providers to v3

[ChristopherDedominici]

Related Issues

See the NOTE section in this issue

Changes

The current PR implements:

• porting of the V2 gas providers
• porting of the chain validation V2 provider
• port of the V2 unit tests for gas and validation providers
• addition of e2e tests for gas and validation

All the code has been ported while maintaining most of the original structure in both the source code and the tests; therefore, there are no significant changes in the logic.

Additional work

While porting the accounts provider I discovered that there are quite a few missing functionalities that are not currently implemented in V3. For example:

• there are a lot of functions that in V2 are imported from @nomicfoundation/ethereumjs-util, @nomicfoundation/ethereumjs-tx, etc. Example: FeeMarketEIP1559Transaction.
  See here, search for @nomicfoundation/ to see all the imports
• there are quite a lot of RPC types leveraging t defined types that need to be defined because currently they are not available in V3, for example in this file (not all of them are needed).
• adding the account property in the network configuration is a straightforward task, but there are a lot of tests to port, like in this file

I think this should be split into multiple PRs since these side tasks, while related to moving the providers, are dependencies rather than the main focus.

How could the work be re-organized:

• split the accounts work from the current branch, then work it up to a PR with providers that don’t depend on accounts : both logic + tests (done in this PR)
• follow up PR with accounts property port + tests, and the simple FixedSenderProvider and AutomaticSenderProvider providers
• final follow up PR with missing types and util functions for accounts + LocalAccountsProvider and HDWalletProvider ported with logic + tests

Notes on the implementation

• A similar class structure from V2 will be retained in V3. While some previous functionalities could be converted into simple functions in V3, the majority need to remain as classes. To maintain code consistency, even those that could be converted to functions will be kept as classes. This approach ensures cleaner and more efficient access to values using this in various parts of the code, rather than passing the same variables multiple times.
• There are a few TODOs from the V2 code, I kept them as TODOs. I marked them as TODO: from V2 -

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
hardhat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 17, 2024 0:57am

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6472432

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ChristopherDedominici]

I need a double-check on this because, based on the V2 comment description above, I'm not entirely sure whether this "if condition" is correct. I'll update the V2 description as soon as I confirm the correct code.

Original implementation at this link

[schaable]

I think it's correct, but we can ask Pato or John if you want to be absolutely sure before merging.

[schaable]

Nice work! I left some comments, but I think most of them can be addressed later (we just need to create issues to track them). Also, I find using assertHardhatInvariant after each request a bit annoying. We could simplify things by adding type guards for the RPC methods and exposing them as utilities.