add support for geth 1.15.0 - 1.15.5

[pacrob]

What was wrong?

geth has new versions. So we add them!

Closes #250
Closes #252
Closes #253
Closes #256
Closes #258

This also introduced the blobSchedule genesis config item. Added it plus a test.

Todo:

• Clean up commit history
• Add or update documentation related to these changes
• Add entry to the release notes

Cute Animal Picture

[fselmo]

We should validate the blobSchedule as Geth does with a pydantic model and raise appropriate errors here. They need only be required if the fork it's pertaining to has a {fork}Time set but the blob schedule also needs to have int values for target, max, and baseFeeUpdateFraction if it is provided.

I think maybe adding a @field_validator("blobSchedule") can work well and checking against a BlobSchedule model if it is present.

[fselmo]

Updated the geth link to the actual values

[fselmo]

should this be using DEFAULT_CANCUN_BLOB_DONFIG.model_dump()?

[fselmo]

As we discussed, it's probably better to set the defaults in the genesis.json so it's easier for a reader to find the full config. I wouldn't want a user who doesn't pass in a blobSchedule to have it filled in for them silently and not know that their config is wrong. We should validate that the blobSchedule needs to be passed in if cancunTime is set, or let geth do it, but I don't think we should silently fill defaults in the code.

In fact, I think the whole pydantic flow is off here. Thankfully no bug reports have come in but I don't think anything before cancunTime would ever work with the dev process.

When we initialize the chain, we fill_default_genesis_data but this means it will fill in everything from this model so it will add cancunTime to any config that stopped at shanghaiTime (or anything else, this is just an example).

This is a completely separate bug that I just noticed but we should address as a bugfix before the next release.

Long story short, let's not do any default values on the code side and leave defaults up to the genesis.json. It will just cause more headaches like this one and make these errors hard to find.

We should probably add a test for initializing a chain x time before the current fork and make sure it works.

[fselmo]

Yes I tried this locally and that is indeed the case. Passing in genesis_data that goes up to shanghaiTime fills in cancunTime at that line I linked. We should only be validating the genesis data and not filling any defaults. When I get rid of filling in the defaults it works as expected.

[fselmo]

What used to exist there is if config is None ... set defaults. Perhaps we can still utilize this logic though this is only used to instantiate geth dev process and we already have that check in the DevGethProcess init so it would be redundant.

[fselmo]

PR here #255

[fselmo]

This looks good. I left one question that I haven't looked into but I'd like to steer away from filling in any defaults in the code if we can avoid it, leaving that to the genesis.json and only in one place to avoid any confusion or unclear filling in of default values.

Prague has been enabled in geth as of 1.15.0 as well. I think we should include the prague blob schedule in this PR, as well as adding pragueTime and checking that things work.

[fselmo]

Is this necessary? If we set the default values in the genesis.json and only validate that against the model here, do we need to re-construct the values here?

[pacrob]

Having it be a separate model is not necessary. It could just as easily be:

class GenesisDataConfig(BaseModel):
    chainId: int = 0
    ...
    cancunTime: int = 0
    # blobs
    blobSchedule: dict[str, Any] = {
        cancun: dict[str, Any] = {
            "target": 3,
            "max": 6,
            "baseFeeUpdateFraction": 3338477,
        },
        prague: dict[str, Any] = {
            "target": 6,
            "max": 9,
            "baseFeeUpdateFraction": whatever,
    }

It's just how I did it.

The default values here are just that, values that get filled if they are not present in the genesis.json provided by the user. What those values are, i.e. what constitutes a minimum viable GenesisData, should probably be clarified.

[pacrob]

If we are, as you mention in #255, overriding fields provided in genesis.json with default data from GenesisData or GenesisDataConfig, then yes, that is a problem.

[fselmo]

It's more about the fact that we already get these values from the genesis.json. So we are kind of doing double the "defaulting" by also setting them here in this class. I think validation of the genesis.json values is all that needs to be done here ideally. Am I missing something?

[fselmo]

lgtm, I think the default value removal should go in before the next release. I'll make sure to wrap that PR up after this one.