feat(state): validate state content by anchoring it to the state root

[morph-dev]

What was wrong?

We currently don't anchor state content to the chain. We did this in the past as history network (and fetching block header) wasn't reliable, but we should start doing it.

Related issue: #1305

How was it fixed?

Fetch the block header from the network and validate the content based on the state_root.

To-Do

• Clean up commit history and use conventional commits.

[morph-dev]

Ideally, this should be merged after ethereum/hive#1152 and ethereum/portal-spec-tests#23 (otherwise, state hive tests will start failing).

[KolbyML]

I don't think we should enable this validation until we have live history having 100% coverage

[KolbyML]

One concern is what if the user isn't running the history network, there doesn't appear to be any measures in place to prevent against this error case

[KolbyML]

If we did want to enable it, we should enable it by block ranges over time

[morph-dev]

Considering that in short/mid term we only plan to gossip only first 1'000'000 blocks and the most recent ones (head state), we are already covered with history network (4444 + latest). And for anything else, having history at 100% should be higher priority than having state at 100% (and also much easier).

In addition, I would say it makes sense for state bridge to first gossip block header to history network, then process that block (execute + gossip), and we avoid this problem altogether.

While I think I gave good arguments, I'm also fine with having a startup flag that can disable this check (or at least attempt it, and if we can't fine the header consider that proof is anchored). But I would leave the check enabled by default (at least for now).

---

One concern is what if the user isn't running the history network, there doesn't appear to be any measures in place to prevent against this error case

This is good argument, but we will always have this issue (now or later). There are few simple ways around it:

• my preference: print error message at startup and shut down
• run history network but without storage.

[KolbyML]

One concern is what if the user isn't running the history network, there doesn't appear to be any measures in place to prevent against this error case

This is good argument, but we will always have this issue (now or later). There are few simple ways around it:

• my preference: print error message at startup and shut down
• run history network but without storage.

History requires beacon for validating all post capella content

So we also need to run beacon also

[KolbyML]

Considering that in short/mid term we only plan to gossip only first 1'000'000 blocks and the most recent ones (head state), we are already covered with history network (4444 + latest). And for anything else, having history at 100% should be higher priority than having state at 100% (and also much easier).

In addition, I would say it makes sense for state bridge to first gossip block header to history network, then process that block (execute + gossip), and we avoid this problem altogether.

While I think I gave good arguments, I'm also fine with having a startup flag that can disable this check (or at least attempt it, and if we can't fine the header consider that proof is anchored). But I would leave the check enabled by default (at least for now).

In like 4 months when history requires beacon for post capella blocks and latest for validation of headers, if we ever want to test state we would then need to have the beacon and history network running.

Maybe this won't be a issue I guess we will see, def a lot more requirements but I that is by design

In addition, I would say it makes sense for state bridge to first gossip block header to history network, then process that block (execute + gossip), and we avoid this problem altogether.

We can do this

[KolbyML]

One concern is what if the user isn't running the history network, there doesn't appear to be any measures in place to prevent against this error case

This is good argument, but we will always have this issue (now or later). There are few simple ways around it:

• my preference: print error message at startup and shut down
• run history network but without storage.

I think the first option should be included in this PR in that case

[KolbyML]

[ogenev]

LGTM 👍 .

[morph-dev]

I noticed that bridge was one more place where I needed to handle flags correctly.

The "portal_subnetworks" flag was used both for selecting which bridges to run (HistoryBridge, BeaconBridge, StateBridge) and which subnetworks to enable on portal client (trin or fluffy).

With the latest PR, the subnetworks enabled on the portal client would be calculated based on the needs of such bridge (i.e. StateBridge would enable both history and state subnetwork).

[morph-dev]

Final comment. This pr should be merged only after:

• feat: use weight for setting storage capacity per network #1388 is merged
• cluster repo is updated such that state nodes have both history and state subnetworks enabled
  • I have branch ready, but it should be sent for review and only after PR from above

[morph-dev]

Rebased to head and cleaned up commit history.

Will most likely merge it tomorrow morning, so I can react if something goes wrong (e.g. hive starts failing).