Spec 6s slot times (EIP-7782) #4484
Conversation
|
are we putting the change to rewards in another PR or are we looking at that in this PR too? |
I think it's already covered by adjusting |
| # Calculate the time when EIP-7782 fork occurs | ||
| if EIP7782_FORK_EPOCH == FAR_FUTURE_EPOCH: | ||
| # If EIP-7782 is not scheduled, use standard slot duration | ||
| return (store_time_ms - genesis_time_ms) // SLOT_DURATION_MS |
There was a problem hiding this comment.
I don't believe this will actually work here. In our test framework, genesis starts with EIP-7782 even if EIP7782_FORK_EPOCH is still FAR_FUTURE_EPOCH. So this wouldn't work properly until we schedule the fork (ie assign a real epoch) which won't happen until a couple months before. The way the testing framework was designed doesn't handle this situation well.
Ok great - had missed that but yes. |
| """ | ||
| churn = max( | ||
| MIN_PER_EPOCH_CHURN_LIMIT_EIP7782, | ||
| get_total_active_balance(state) // CHURN_LIMIT_QUOTIENT, |
There was a problem hiding this comment.
Do we need to double CHURN_LIMIT_QUOTIENT?
There was a problem hiding this comment.
Weak subjectivity is epoch based so this is possibly ok, but may ask @mkalinin
There was a problem hiding this comment.
I think it should be doubled as well, as we want to keep all other things equal, will add.
|
I think |
| MIN_PER_EPOCH_CHURN_LIMIT_EIP7782: 64000000000 | ||
| # 2**7 * 10**9 (= 128,000,000,000) Gwei | ||
| MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT_EIP7782: 128000000000 | ||
|
|
There was a problem hiding this comment.
might also need to double MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS, otherwise the data availability window goes down from ~18 days to just ~9 days
There was a problem hiding this comment.
i was just thinking about this one :)
|
where do we stand on sync committee period? there was a desire originally to have it fairly stable, so it only rotated once a day... Is that still desirable? if so we should probably double that too.. |
Yes, agreed, I think sync periods should stay the same, missed that one. Thanks! |
|
probably also worth considering halving the |
|
On top of |
| ```python | ||
| def get_attestation_due_ms(epoch: Epoch) -> uint64: | ||
| """ | ||
| Return the attestation due time in milliseconds for the given epoch. | ||
| """ | ||
| if epoch >= EIP7782_FORK_EPOCH: | ||
| return ATTESTATION_DUE_BPS_EIP7782 * SLOT_DURATION_MS_EIP7782 // BASIS_POINTS | ||
| else: | ||
| return ATTESTATION_DUE_BPS * SLOT_DURATION_MS // BASIS_POINTS | ||
| ``` |
There was a problem hiding this comment.
Hey @dankrad these modifications don't match the way we do this elsewhere. Like:
consensus-specs/specs/gloas/fork-choice.md
Lines 440 to 444 in f0b3bca
For this function, it should be:
def get_attestation_due_ms(epoch: Epoch) -> uint64:
# [New in EIP7782]
if epoch >= EIP7782_FORK_EPOCH:
get_slot_component_duration_ms(ATTESTATION_DUE_BPS_EIP7782)
return get_slot_component_duration_ms(ATTESTATION_DUE_BPS)And we need to update get_slot_component_duration_ms to be:
def get_slot_component_duration_ms(basis_points: uint64) -> uint64:
"""
Calculate the duration of a slot component in milliseconds.
"""
return basis_points * SLOT_DURATION_MS_EIP7782 // BASIS_POINTSAt the fork, the updated get_slot_component_duration_ms will be used. It doesn't need to know the epoch.
Co-authored-by: JihoonSong <[email protected]>
|
one potential interesting thing - what if some chains don't want to change slot time? is this a consideration? changing rewards etc gets complicated potentially... Minimal i probably don't care much if issuance gets changed, but there may be chains like gnosis which can't easily halve their durations? If theres constants etc they can just configure to avoid it... we should just make sure its configuration and not baked in... |
5 participants
Spec for 6s slot times. Based on #4476 .
TODOs:
get_forkchoice_storeon_tickget_slots_since_genesislogicFailing tests