chore: refactor hub, hub-nodejs to use viem instead of ethers

[varunsrin]

What is the feature you would like to implement?

Use viem instead of ethers.js for all blockchain and wallet interactions in hubble, hub-nodejs and hub-web. Using EthersEip712Signer should still be supported in hub-nodejs for consumers that use ethers.

Why is this feature important?

We've run into many issues with ethers v6 especially in React Native environments and viem seems like a promising alternative. We should at least prototype and go/no-go on this.

Will the protocol spec need to be updated??
No

[deodad]

This is a short-term no-go, at least for unlocking RN support.

Viem uses package exports which aren’t yet supported by Metro + React Native.

Experimental support should come with the upcoming RN 0.72 release and stable support with RN 0.73. See Road to 0.72.

I'd like to do a little more digging into:

• aside from package exports, which should soon be supported, what else is needed to get viem compatible with RN
• what else is preventing our libraries from being RN compatible and whats the shortest path to unblock

[varunsrin]

Could we at least move the apps/hubble codebase over to viem and keep hub-nodejs on ethers until this is resolved? or does that introduce a lot of complexity?

[jxom]

We were thinking of exporting everything from the viem entrypoint. package.json#exports is proving to be a pain with no significant benefit.

[deodad]

Could we at least move the apps/hubble codebase over to viem and keep hub-nodejs on ethers until this is resolved? or does that introduce a lot of complexity?

We could move apps/hubble over without introducing a lot of complexity. I did a small proof-of-concept and it seems like the move to viem would remove some complexity we've had to add to account for edge cases around RPC failures.