Adapt validator to post-Merge chains #7

New Issue

telackey · 2023-10-04T23:05:25Z

telackey commented

2023-10-04 23:05:25 +00:00

https://github.com/cerc-io/ipld-eth-db-validator/issues/31

New concerns arise when running the validator on post-Merge chains. We should adapt the validator to handle them:

Consensus algorithm transition

In a post-Merge chain, the CL defines the canonical chain, but this validator is currently ignorant of the CL, and therefore has no way to handle a transition of the consensus engine to PoS at the Merge block. The engine it uses is configured in advance, so if using Ethash, it will fail once it reaches a PoS block (due to reward distribution being off), and conversely, if run with no intrinsic consensus engine set, it fails to validate PoW blocks.

We can work around this for now by not running the same validator on block ranges spanning the Merge, but a better solution would be to have the service be aware of the CL and use the appropriate algorithm based on the state of the CL chain.

Non-canonical blocks

However, another aspect of post-Merge chains is EL blocks can be added (and statediff-indexed) but not proposed/attested for whatever reason, and so not included in a slot in the beacon state (this can reliably seen in the first few blocks on a stack-orchestrator test chain). For the validator's purposes this means (at the least) we waste some time checking non-canonical blocks, but it could potentially cause issues in code that determines canonicity based only on the heaviest branch in the current EL chain (as does ipld-eth-db).

We should look into this and try to grasp the full implications of it, but for this code the correct solution is to use the CL state to drive the validator (i.e. treat CL appropriately as the source of canonical truth).

https://github.com/cerc-io/ipld-eth-db-validator/issues/31 New concerns arise when running the validator on post-Merge chains. We should adapt the validator to handle them: ### Consensus algorithm transition In a post-Merge chain, the CL defines the canonical chain, but this validator is currently ignorant of the CL, and therefore has no way to handle a transition of the consensus engine to PoS at the Merge block. The engine it uses is configured in advance, so if using Ethash, it will fail once it reaches a PoS block (due to reward distribution being off), and conversely, if run with no intrinsic consensus engine set, it fails to validate PoW blocks. We can work around this for now by not running the same validator on block ranges spanning the Merge, but a better solution would be to have the service be aware of the CL and use the appropriate algorithm based on the state of the CL chain. ### Non-canonical blocks However, another aspect of post-Merge chains is EL blocks can be added (and statediff-indexed) but not proposed/attested for whatever reason, and so not included in a slot in the beacon state (this can reliably seen in the first few blocks on a `stack-orchestrator` test chain). For the validator's purposes this means (at the least) we waste some time checking non-canonical blocks, but it could potentially cause issues in code that determines canonicity based only on the heaviest branch in the current EL chain (as does `ipld-eth-db`). We should look into this and try to grasp the full implications of it, but for this code the correct solution is to use the CL state to drive the validator (i.e. treat CL appropriately as the source of canonical truth).

telackey added the

Copied from Github

label 2023-10-04 23:05:25 +00:00

dboreham was assigned by telackey

2023-10-04 23:05:26 +00:00

telackey commented

2023-10-04 23:06:31 +00:00

From @AFDudley:

@dboreham I suspect we will need to optimize the CL indexer before we can integrate it into the validator, am I correct about this? is there an issue that can be linked?

From @AFDudley: @dboreham I suspect we will need to optimize the CL indexer before we can integrate it into the validator, am I correct about this? is there an issue that can be linked?

Sign in to join this conversation.