You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent update to process_slots induces consequences in other parts of the eth2.0 specs, which invoke the process_slots method - AssertError can be thrown, while it worked fine before the update, in the case state.slot == slot. In the update diff, one can see that process_slots is guarded with state.slot < slot to prevent such problems.
However, there are other cases when process_slots is called, but corresponding call site is not updated with such a guard.
One such example is store_target_checkpoint_state. That leads to problems. For example, one can create attestations during the first (i.e. zero) epoch, however, once an epoch is justified, i.e. there is a new checkpoint, store_target_checkpoint_state is called, which tries to invoke process_slots, which results in the AssertError, unless next epoch arrives.
Traceback (most recent call last):
File "testcase0.py", line 85, in <module>
do_step()
File "testcase0.py", line 78, in do_step
spec.on_attestation(store, a)
File "/mnt/c/Users/ericsson/IdeaProjects/tmp/eth2.0-specs_v0.11.3/venv/lib/python3.8/site-packages/eth2spec/phase0/spec.py", line 1519, in on_attestation
store_target_checkpoint_state(store, attestation.data.target)
File "/mnt/c/Users/ericsson/IdeaProjects/tmp/eth2.0-specs_v0.11.3/venv/lib/python3.8/site-packages/eth2spec/phase0/spec.py", line 1442, in store_target_checkpoint_state
process_slots(base_state, compute_start_slot_at_epoch(target.epoch))
File "/mnt/c/Users/ericsson/IdeaProjects/tmp/eth2.0-specs_v0.11.3/venv/lib/python3.8/site-packages/eth2spec/phase0/spec.py", line 836, in process_slots
assert state.slot < slot
AssertionError
One can wait until next epoch, then do_step() is successfull.
One possible solution is to add a guard around process_slots call in the store_target_checkpoint_state method
defstore_target_checkpoint_state(store: Store, target: Checkpoint) ->None:
# Store target checkpoint state if not yet seeniftargetnotinstore.checkpoint_states:
base_state=store.block_states[target.root].copy()
epoch_start_slot=compute_start_slot_at_epoch(target.epoch)
ifbase_state.slot<epoch_start_slot:
process_slots(base_state, epoch_start_slot)
store.checkpoint_states[target] =base_state
The text was updated successfully, but these errors were encountered:
Summary of issue: When a new attestation is received with target not in store.checkpoint_states, there can be a failure in assert state.slot < slot in the call on_attestation > store_target_checkpoint_state > process_slots.
Cause of issue: process_slots is called in store_target_checkpoint_state to adjust the checkpoint state for "pulled up" epoch boundary blocks (see image), which breaks after the new changes when target.root isn't a pulled up block.
One can wait until next epoch, then do_step() is successfull.
This is working because of the set_slot(spec.SLOTS_PER_EPOCH * 2) call, which skips all blocks until the next epoch, leading to a pulled-up epoch boundary block.
Solution: The suggested solution is the appropriate.
Recent update to
process_slots
induces consequences in other parts of the eth2.0 specs, which invoke theprocess_slots
method -AssertError
can be thrown, while it worked fine before the update, in the casestate.slot == slot
. In the update diff, one can see thatprocess_slots
is guarded withstate.slot < slot
to prevent such problems.However, there are other cases when
process_slots
is called, but corresponding call site is not updated with such a guard.One such example is
store_target_checkpoint_state
. That leads to problems. For example, one can create attestations during the first (i.e. zero) epoch, however, once an epoch is justified, i.e. there is a new checkpoint,store_target_checkpoint_state
is called, which tries to invokeprocess_slots
, which results in theAssertError
, unless next epoch arrives.Here is a snippet, illustrating the problem.
One can wait until next epoch, then
do_step()
is successfull.One possible solution is to add a guard around
process_slots
call in thestore_target_checkpoint_state
methodThe text was updated successfully, but these errors were encountered: