Client browser support needs - Tracking Issue

[acolytec3]

The client has long supported a browser build that supports devp2p over libp2p to allow a client running in the browser to participate in a network. That said, there are a number of issues that need addressing

• [ ] Libp2p dependencies need to be upgraded. The core libp2p dependency is currently on v37 and the surrounding dependencies are all out of date and need to be upgraded if we want to continue browser support. This will resolve a number of deprecation warnings around a number of transitive dependencies in the libp2p stack that appear in our install process
• [x] Resolve the async_hooks build error that webpack/karma throws. This raw-body transitive dependency depends on the NodeJS async_hooks module. It may be as simple as setting a webpack fallback of false to resolve this but it's not obvious to me if this is the case. Converting the client to an es module may be the real solution here.

├─┬ @ethereumjs/[email protected] -> ./packages/client
│ └─┬ [email protected]
│   └── [email protected]
└─┬ [email protected]
  ├─┬ [email protected]
  │ └── [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └── [email protected]

• [x] Review the RPC implementation and see if there's anyway to expose the RPC endpoint in browser using something like this or else make sure the rpc is disabled by default in the browser build (if it's not already done so)
• [ ] Contemplate switching from webpack to rollup and implement tree-shaking to minimize the size of the different builds (if possible)
• [ ] Turn on browser build in npm run build script in client once other items are taken care of
• [ ] fullsync mode currently doesn't work because the evm package needs util.promisify from the NodeJS builtin and for some reason the webpack polyfill refuses to work in the evm package and throws a promisify is undefined error when you try to start the client
• [ ] The blockchain.validateConsensus method throws errors about missing signer states if you try to start the link client on goerli (or presumably any PoA network). Something is going awry in pulling in the genesis parameters when the blockchain object is instantiated

[acolytec3]

I'm sure there are probably more things here but this is a starting point for us to consider. My bigger question is, do we even want to continue supporting the browser build or just deprecate and remove it? I'm sure it adds considerable bulk to the bundle size and the browser-based client is really just an interesting thought experiment since the only way for a browser client to connect with other nodes is over libp2p and as far as I know, our client is the only one that supports devp2p over libp2p

[paulmillr]

I think it's amazing to have a client that can be ran in browser. Not everyone can launch terminal etc.

If you'll be reducing the QA of browser builds, I think it should not be called "deprecation". Instead, "alpha-quality unstable browser builds", or something like that, indicating the support may be improved in the future.

Of course, this is only relevant if other folks are on board with the builds.

[acolytec3]

I think it's amazing to have a client that can be ran in browser. Not everyone can launch terminal etc.

If you'll be reducing the QA of browser builds, I think it should not be called "deprecation". Instead, "alpha-quality unstable browser builds", or something like that, indicating the support may be improved in the future.

The browser tests won't even compile at present due to this async_hooks issue I noted and I'm not 100% sure the best way to go fixing it. It's certainly an interesting experiment but it unfortunately just doesn't work at present. I think I can probably get it going again with a few hours of work but I'm not 100% sure what's all involved so we'll put it on the back burner until we get the breaking releases out and probably also the ESM builds.

[paulmillr]

Ah, if it doesn't work yet, it makes sense to disable it, yes.

[acolytec3]

With #2091, we can now build and run the client in browser in light client mode on sepolia. We still have several issues that need resolving but I guess this is some manner of progress. I will update the issue tracker as such

[holgerd77]

Will copy over some information from @paulmillr from a related sub-issue #2198 on the libp2p update:

Client uses "libp2p": "^0.30.7", which is quite old, and has some security warnings related to outdated deps. Current version is 0.38, I think we should update it and all its peer/sub deps to the following versions:

    "libp2p": "^0.38.0",
    "@libp2p/bootstrap": "^2.0.0",
    "@libp2p/interfaces": "^3.0.3",
    "@libp2p/kad-dht": "^3.0.4",
    "@libp2p/mplex": "^5.0.0",
    "@libp2p/tcp": "^3.0.3",
    "@libp2p/websockets": "^3.0.2",
    "@libp2p/peer-id": "^1.1.8",
    "@chainsafe/libp2p-noise": "^8.0.1",

Note that old plugins were libp2p-x / peer-id, new ones are @libp2p/x