What to do about (un)common params gotchas

[acolytec3]

In the course of working on #3545, we encountered a scenario where code was trying to read from common.params and was getting an "undefined" type result where the desired param could not be found. This stems from looking in a common instance where those params weren't available (like this where a test is trying to read a tx-specific parameter that wasn't available in the evm common instance. This all happens now because of #3537.

The basic issue is that before #3537, we could generally count on common parameters to be the same across all instance of common that existed in an application but that is no longer the case (with the goal of shrinking our bundle size) since each of our packages has it's own interior set of parameters that are specific to that package and won't be accessible from other packages now. Here again, not an issue per se but just requires us to change how we think about common.

One idea was to bring back in a topic concept that existed before #3537 but instead of having topics like gasConfig, the topic is the package that the parameters come from. So, a call might look something like:

common.params('tx', 'baseBlobFee')

And if this common didn't have the tx parameters, it would throw an error like tx params not initialized or something to that effect.

An alternative approach is to get rid of the entire naming common and replace it with something like ethjsConfig or something since this package isn't really a set of Resources common to all EthereumJS implementations (taken from the common README), but more a "chain configuration" for each object instantiated for a specific ethereumjs class type.

This is just for conversation at this point but we should consider if this is a real or imagined issue as we continue to get used to these API changes.

[holgerd77]

I think that's an imagined issue that won't bite us. I fixed dozens of these kind of cases in the first round, so this is literally "by design".

This only happens "from the outside" (so e.g. in the test scenario mentioned) where one wants to request a parameter from outside a specific library.

These cases are very much detectable just "on writing". So this would just directly throw (if one writes e.g. a new test case (rare!) in such a manner).

So, the semantics of Common just have changed and this need a redefinition: Common itself is not providing the paramters any more, but just provides a container mechanism "to provide parameters in whatever way". It is up to the packages to make sure that parameters used within are provided along the initialization.

[holgerd77]

(I also don't have any name issues, since this is still holding a common/shared configuration (chain/HF/crypto) throughout and across the libraries)

[acolytec3]

Fair enough. @jochem-brouwer does this address your concerns?

[holgerd77]

No follow-up will close for now, feel free to re-open

[jochem-brouwer]

Should have closed this myself, per the discussion we had regarding this issue 👍 😄