Client Dependency Reduction

[holgerd77]

As the client is somewhat naturally evolving into some more production-ready state by some main road blockers like snap sync and optimistic sync now being tackled, I guess it's time to start to think more strategically about security questions and eventual implications of a more serious client usage.

One major thing is reduction of overall client dependencies. I would give out the rough optimal goal, that the client (together with all the other lower-level EthereumJS libraries) shouldn't have more than 100-200 dependencies including all sub-dependencies. Not sure if this is realistic, we'll see and can independently give this a start.

I would say that for this to achieve is also worth to think about some more radical solutions, .e.g.:

• Eventually extract the libp2p functionality if the dependeny tree turns out to remain too large
• Remove functionality (let's say e.g. BLS precompiles/mcl-wasm) if dependency turns out to not get manageable
• ...

These are rather not concrete suggestions (might be though) but examples on the scale of thinking we might need here to get to results.

So single tasks are:

• Have a look at dependencies one-by-one, remove unnecessary ones, especially with larger sub-dependency trees
• It would also nice to somewhat document the remaining ones, maybe in some issue, separate md doc,... ( with some useful data like reason for existance, number of dependencies,...)
• Idendentify large strategic issues (might be e.g. the libp2p thing from above) and open dedicated issues

All this work will rather be a strategic effort for rather months then weeks, a rough target would be to have this settled towards Summer/June or so 2022.

[ScottyPoi]

Eventually extract the libp2p functionality

@holgerd77 can you clarify what is meant by extract here?

[holgerd77]

Eventually extract the libp2p functionality

@holgerd77 can you clarify what is meant by extract here?

That was a very loose first-round thought and I have no idea if realistic. So the base situation is that the libp2p dependencies are bringing in a large large sub dependency tree, at the same time this is rather "optional" functionality. So I wondered if it would eventually be possible to provide this as an extra client-libp2p additional package or something, to have greater security in the core package. Heavy heavy TBD here though.

I guess various simpler decisions on packages should be tackled in a first round - this is actually the most complicated and likely most controversial one. So for now we should focus on questions like "do we need this one package at all?", "could we replace with something where dependencies are more controlled/managed/limited?", optimally combined with a good analysis where the pain points (single dependencies with large subtrees) actually are.

[jochem-brouwer]

We can't really remove BLS if we depend upon VM right? Then we would also have to remove it there?

I do agree that we need to reduce our dependencies :+1:

[holgerd77]

We can't really remove BLS if we depend upon VM right? Then we would also have to remove it there?

If we would decide that it's not manageable in the current form and would decide that we need to do something about it, then it might even become an option to remove the VM dependency (since the EIP is not applied anyhow) and have people to manually install if they want it.

Not saying that we should do that, but on purpose wanted to phrase things more open here so that we take a lot of options in the ring since this is a big and important topic. Not sure myself yet where we'll land here though.

[holgerd77]

Happened a lot here, for the client maybe not completely there, will nevertheless close. Think the topic is enough on everyone’s minds now.