refactor(connector-besu): migrate to viem from web3js
We've had plans for a while to upgrade to Web3 4.x from the current 1.6.x that the Besu connector uses, but it has recently been announced that the entire Web3JS project is being sunset so instead of upgrading, we have to outright migrate away from it.
The plan is to migrate endpoints one by one until nothing is using Web3JS anymore. Hopefully this will be possible to be done in a way that there are no breaking changes but this is very much up in the air. A we should release a new major release (v3.0.0) in the coming 1 or 2 quarters to be able to make breaking changes because that way it will be much lower effort to perform the migration.
Sources:
- https://github.com/web3/web3.js
- https://blog.chainsafe.io/web3-js-sunset/
The repo was archived in early March of 2025
That's an interesting news. We should create an epic to migrate all packages that use web3js to viem, since it affects all of them (I''ll be happy to do that later this week), also we should confirm that everyone is OK with migrating to viem instead of ethers. I think the latter have some issues in V6 so I also prefer viem, but it's better to get a full approval
That's an interesting news. We should create an epic to migrate all packages that use web3js to viem, since it affects all of them (I''ll be happy to do that later this week), also we should confirm that everyone is OK with migrating to viem instead of ethers. I think the latter have some issues in V6 so I also prefer viem, but it's better to get a full approval
@outSH Agreed on all of those points. In addition I'll suggest that the connector could have both viem and web3js (and maybe even ethers for good measure) since they all take the same input parameters anyway. This would enable us to gradually migrate instead of having to do it all in one go for a given package. The PR that I'm almost ready to submit will do exactly that for the besu connector with one new endpoint using viem and the rest of them still using web3js for now.
I totally agree with this. We can start with both of them in place and then remove the web3 methods once we have the alternate viewm methods for the same. Because I am working on web3 4.x upgrade (will stop that now) and we wouldn't be able to upgrade all at once for a specific package (minimum 5-6 other packages will be affected and wont work if we totally replace web3 by viewm for just one package).
This issue will be considered if the depending package remains, as part of the cleanup initiative: https://github.com/hyperledger-cacti/cacti/issues/4037