Merge transition process with computed transition total difficulty#2462
Merge transition process with computed transition total difficulty#2462djrtwo merged 11 commits intoethereum:devfrom
Conversation
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
Great!
Slight preference for vitaliks calculation based on difficultly because what we choose >= 2 weeks prior is almost certainly less accurate. But just a slight preference
| } | ||
|
|
||
|
|
||
| def run_fork_test(post_spec, pre_state): |
There was a problem hiding this comment.
Might be worth abstracting this into a standard run_fork_test(post_spec, pre_state, stable_fields, modified fields, fork_specific_checks_fn=None) and have run_merge_fork_test call it. But... doesn't matter too much for this PR
| ) | ||
|
|
||
|
|
||
| @with_phases(phases=[PHASE0], other_phases=[MERGE]) |
There was a problem hiding this comment.
Bummer these are all copied over.. Good for now, but we might consider a more re-usable approach (cc: @ralexstokes, @protolambda )
| @with_phases(phases=[PHASE0], other_phases=[MERGE]) | ||
| @spec_test | ||
| @with_state | ||
| @with_meta_tags(MERGE_FORK_TEST_META_TAGS) |
There was a problem hiding this comment.
We can just define:
def composed(*decs):
def deco(f):
for dec in reversed(decs):
f = dec(f)
return f
return deco
merge_test = composed(
with_phases(phases=[PHASE0], other_phases=[MERGE]),
spec_test,
with_state,
with_meta_tags(MERGE_FORK_TEST_META_TAGS),
)
@merge_test
def test_something_fun(spec, phases, state):
...Lots of other places where we can combine decorators as well.
mkalinin
force-pushed
the
merge-transition-with-dynamic-ttd
branch
from
29a87d5 to
6350e27
Compare
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
excellent!
plenty of iteration to do but I'm going to get this merged and released for alpha.7
5 participants
Introduces the Merge fork (
upgrade_to_merge) with the version of transition process that uses dynamically computed transition total difficulty.The computation happens during the Merge fork, i.e. next to
upgrade_to_mergecall. Total difficulty is computed with the following formulatransition_total_difficulty = get_pow_block(state.eth1_data.block_hash).total_difficulty + TRANSITION_TOTAL_DIFFICULTY_OFFSET. And then it is stored to a specific storage slot inTransitionStore.Rationale
Dynamically computed total difficulty makes the transition process more predictable.
For example, we expect
MERGE_FORK_EPOCHtwo weeks after updated client software has been deployed and we also take a couple of extra days after the Merge fork to be able to react accordingly if something went wrong during the fork itself.OTOH, we can compute transition total difficulty at the time of the fork and remove period before the fork (2 weeks in our case) from our model. If we double total difficulty estimation to protect from difficulty fluctuations then we can reduce the time between software deployment and the actual transition by at least two weeks in our case. Which, in its turn, makes estimated time of the transition more accurate.
Implementation details
What if
state.eth1_datais too old?If
TRANSITION_TOTAL_DIFFICULTY_OFFSETis set to 1 week worth of difficulty then it will be enough time to handle this case properly. It's hard to imagine thatstate.eth1_datais older than 3 days (more than 10 voting periods failed in a row).What if
state.eth1_datais forked out?We may set
MERGE_FORK_EPOCHto the beginning of the voting period to reduce the possibility of changing eth1 data in state due to chain re-orgs. Also,TransitionStoreshould be initialized each time the fork happens in the client's code and seeded with correspondingstate.eth1_data.Why
TransitionStoreinstead ofStore.transition_total_difficulty?To keep implementation and testing simple and weaken dependency of the fork choice tests and transition process. We can opt for re-using
Storeto keeptransition_total_difficultyif we want.Testing
Merge fork tests are copied from Altair ones. There is no tests for the transition process itself, we better work on them in a separate PR once we settled down with particular approach to the transition.
Transition total difficulty announcement
We might want to communicate transition total difficulty offchain once it's computed. So, validators will be able to check it and act accordingly if computation went wrong on their end. This would require a corresponding change in beacon node API.