Web3JS vs EthersJS vs Wagmi vs Viem (and Web3JS upgrading)

[timolegros]

Description

In the codebase we use both EthersJS and Web3JS. Both of these packages have essentially the same capabilities but both have their pros and cons. We should make a decision on which package we want to use and then use that accross the entire repo so we have a set standard (we can also consider Viem/Wagmi in the long-run).

If there are significant advantages to use one package over the other on the client we could consider using a different package on the client vs the server (e.g. lightweight web3 on client vs full EthersJS type-safety on the server). The main idea so to at least have a pattern of use so we don't use the same functionality from 2 different pacakges in adjacent files e.g. checkSum from Web3JS and checkSum from EthersJS.

If we settle on using Web3JS, we need to upgrade this package to v4. v1 is now considered legacy.

The estimated points for the ticket depends on which package we choose.

[timolegros]

Per the protocol office hours (4/4/2024), we would like to use Wagmi on the client side and Web3JS on the platform side. Timelines for transitioning have not been set but we don't expect to act on this decision for at least another month.

Reasoning:

• Wagmi's integration with React would simplify and improve our user flows (e.g. sign-in).
• Web3JS is lighter than EthersJS /Viem in terms of coupling with types. Since on the platform side, we interact with a lot of different contracts, it doesn't make much sense to use a package that is tightly integrated with types (requires additional type generation/parsing). While EtherJS can be used without types as well that is generally where it shines (e-to-e types). That said, we need to upgrade Web3JS to v4 before proceeding.

Edit:

• Viem should not have been part of the 'types' reasoning above. We ultimately chose not to move forward with Viem because it would be a much larger lift in our codebase than moving to Web3 or EtherJS (since we have implementations in both already).

[jxom]

Happy to answer any Viem related questions if it's considered!

Web3JS is lighter than EthersJS/Viem in terms of coupling with types

How so? You don't have to lock yourself into strict types with Viem.

[tmm]

requires additional type generation/parsing

also worth noting that viem does not require type generation. all types are static at compile time.

[timolegros]

@ianrowan @dillchen @Rotorsoft @kurtisassad @rbennettcw given recent platform discussions about simplifying handling of chain-events I think it may benefit us to use Viem instead of Web3.js despite the somewhat larger lift it would require.

We can replace the existing usage of Ethers.js with Viem (so we are still only dependent on 2 libraries - we need to remove Ether.js anyways) and incrementally replace Web3 usage elsewhere. Viem uses native BigInt as well so it should be fairly straightforward to mix and match Web3 with Viem (easier than Web3 and Ethers.js).

The main reason to use Viem is to eliminate the need for chain-event-specific Zod schemas (per the new system discussed in platform OO) and tie all event types to the ABIs as @kurtisassad suggested.

With Viem we can get a fully typed result just by providing the ABI + event name:

  const data = '0x...'
  const event = decodeEventLog<
    typeof namespaceFactoryAbi,
    'DeployedNamespace',
    Hex[],
    Hex
  >({
    abi: namespaceFactoryAbi,
    data,
    topics: [
      EvmEventSignatures.NamespaceFactory.NamespaceDeployed, // would be provided by the raw event
    ],
  });
  
  // event is fully typed
  console.log(event.args.name);

Whereas with Web3.js we always need to coerce the types:

  const web3 = new Web3();
  const res = web3.eth.abi.decodeLog(
    namespaceFactoryAbi.find(f => f.name === 'DeployedNamespace').inputs,
    data,
    [
      EvmEventSignatures.NamespaceFactory.NamespaceDeployed,
    ]
  ) as unknown as {
    name: string,
    _feeManager: string,
    _signature: string,
    _namespaceDeployed: string,
  }
  console.log(res.name)

[Rotorsoft]

viem seems to address a lot of our typing concerns 👍