Engine API: add engine_exchangeTransitionConfigurationV1#172
Engine API: add engine_exchangeTransitionConfigurationV1#172djrtwo merged 3 commits intoethereum:mainfrom
Conversation
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
Looks good! One minor question/suggestion
src/engine/specification.md
Outdated
| #### Request | ||
|
|
||
| * method: `engine_getTransitionConfigurationV1` | ||
| * params: *empty list* |
There was a problem hiding this comment.
The alternative is that it's more of a ping/pong where each send their configuration. Thus both can see a mismatch and both can surface an error.
Do you think this would help reduce chance of user failures by both logs having the error?
There was a problem hiding this comment.
+1 to this idea, basically params is the CL's configuration and response is the EL's, and both sides SHOULD log a warning if the other configuration doesn't match.
There was a problem hiding this comment.
I like this idea! 👍 I think we may re-use the same data structure. When TERMINAL_BLOCK_HASH is set CL client will send terminalBlockNumber: 0 as a block number is not a part of CL's configuration.
There was a problem hiding this comment.
Although, what if it's called not by CL but by a script that checks every EL client in a cluster and then matches values with what are expected to be? Do we want to design for this use case? If yes, then we should make the parameter optional.
There was a problem hiding this comment.
A cluster/advanced test could also add the config as a param. I think it's not worth the complxity of making this optional
|
I've updated the method to |
djrtwo
changed the title
3 participants
Proposal
Proposes to add
engine_exchangeTransitionConfigurationV1methodMotivation
This proposal introduces a method that is useful only before the merge transition with intention to deprecate it in a subsequent upgrade. Low implementation complexity should mitigate this downside.