Can you use OpenZeppelin Network.js with Ethers?

Archive SDK
1

Thanks @ylv-io (OpenZeppelin Networkjs throws error with no provider)! I have a quick followup question- is it possible to use Ethersjs with Networkjs? We found a huge savings in bundle size by switching to Ethersjs, but wanted to see if it will work with Networkjs.

thanks!

2 Likes
2

Certainly you can use network.js with with ethers.js the problem is that network.js internally use web3.js so if you are looking to reduce bundle size it is not going to help.

On a side note. Given that network.js is for frontend development there size matters I am thinking to drop web3.js dependency all together. Would it make a big difference?

1 Like
3

On a side note. Given that network.js is for frontend development there size matters I am thinking to drop web3.js dependency all together. Would it make a big difference?

Please notify on a roadmap post for possible network.js breaking changes or general direction.

My 2 cents, as long as network.js returns a configured provider for injected / local with the option for GSN we are good.

We can init a web3.js instance elsewhere with it, since we already had that dependency.

2 Likes
4

Hey @ethicraul! No worries absolutely follow semver and keep a change log. Regarding change itself we would probably replace lib which is web3.js instance with provider instance so devs can use any web3 utility lib they want without having web3.js forced onto them as a dependency.,
Do it sounds reasonable?

1 Like
5

I’ll note in our code base we swapped out networkjs to test and went with an ethersjs solution via Web3-react and saved a really large amount of space on our bundle size. Correct me if I’m wrong but networkjs has the entire web3 library inside it?

Saving space would be extremely welcome. :slight_smile:

As a note:

Ethers: ~300kb https://bundlephobia.com/result?p=ethers@4.0.44
Web3: ~800kb https://bundlephobia.com/result?p=web3@1.2.5

Additional Irony? The Web3 package includes Ethers as a dependency.

3 Likes
6

Sounds good.
We can maintain 1 instance of web3 and switch providers instead of the whole thing.

Piggybacking on this, please add more info on the readme on how to configure a GSN relay client, we had to dig in the chat app example to get it running.

Thanks!

3 Likes
7

@ethicraul have you checked the documentation on the GSN provider and on the GSN with network.js? It'd be super helpful to know if there is a piece missing to understand how everything works together!

1 Like
8

Yep I checked the docs.

We could not make GSNProvider work by itself, we used network.js mainly because the chat app example worked out of the box.

the missing link may be:

let relay_client_config = {
    txfee: REACT_APP_TX_FEE,
    force_gasPrice: gasPrice, //override requested gas price
    gasPrice: gasPrice, //override requested gas price
    force_gasLimit: 500000, //override requested gas limit.
    gasLimit: 500000, //override requested gas limit.
    verbose: true
  };
// ...
web3Context = useWeb3Network("ws://127.0.0.1:8545", {
    gsn: { signKey, ...relay_client_config }
  });

The examples for GSNProvider in the docs:

were not working for us (they have no relay_client_config too), and if I recall correctly web3 complained about incorrect provider or provider not set and while there is API docs, some parameter names do not match with the example above (the docs have fixedGasPrice but no force_gasPrice)

Our config is

     let relay_client_config = {
        txfee: TX_FEE,
        force_gasLimit: 500000, // override requested gas limit.
        gasLimit: 500000, // override requested gas limit.
        verbose: VERBOSE
     }

What is the difference between gasLimit and force_gasLimit ?
The txfee is in GWei, but what is it exactly? gas price? fee for the relayer?

In the docs it says:

Forcefully use this transaction fee instead of the one advertised by the relayer (may lead to overpayment or rejections, defaults to empty)

How can we check the fee advertised by the relayer? a multiplier?

1 Like
9

The only settings valid for the GSNProvider should be the ones listed on the Reference. Keys not listed there, such as force_gasLimit, are no longer used since they come from an older implementation (the OpenZeppelin GSN provider is a fork of TabooKey's). It seems the ChatApp was not updated to remove those.

This should not be related to setting a relay_client_config, but to web3 complaining about the provider itself. Can you reliably reproduce it? Which version of web3 are you working with?

Each relayer advertises its txFee when it registers. You can check it manually on the registration events in the relay hub. The GSN provider picks them up automatically, and uses them to decide which relayer to work with.

IIRC, it's a percentage. By the way, you can see in the events how one relayer is advertising 0x46, while another is deliberately beating it by advertising 0x45 :stuck_out_tongue:

2 Likes
10

To be fair web3.js has more features than ethers.js. 500kb seems as not much by nowadays standards. I am not saying we shouldn’t optimize but what is the specific reason for your app? Running it over 3G?

2 Likes