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
Unlike other sysvars, the epoch schedule sysvar account is only ever updated during genesis. This is probably fine most of the time since the epoch schedule currently can't be changed. However, it seems that devnet was started with epochs that were only 8,192 slots long (reflected here: https://explorer.solana.com/address/SysvarEpochSchedu1e111111111111111111111111?cluster=devnet) which doesn't match the bank epoch schedule which states that epochs are the typical 432k slots long.
This means that devnet programs cannot get accurate epoch schedule data through the epoch schedule sysvar. Also, if the epoch schedule ever changes in the future (like perhaps the leader_schedule_slot_offset), those changes wouldn't be reflected in the sysvar.
Proposed Solution
Update the epoch schedule sysvar at the beginning of each epoch
The text was updated successfully, but these errors were encountered:
Problem
Unlike other sysvars, the epoch schedule sysvar account is only ever updated during genesis. This is probably fine most of the time since the epoch schedule currently can't be changed. However, it seems that devnet was started with epochs that were only 8,192 slots long (reflected here: https://explorer.solana.com/address/SysvarEpochSchedu1e111111111111111111111111?cluster=devnet) which doesn't match the bank epoch schedule which states that epochs are the typical 432k slots long.
This means that devnet programs cannot get accurate epoch schedule data through the epoch schedule sysvar. Also, if the epoch schedule ever changes in the future (like perhaps the
leader_schedule_slot_offset
), those changes wouldn't be reflected in the sysvar.Proposed Solution
Update the epoch schedule sysvar at the beginning of each epoch
The text was updated successfully, but these errors were encountered: