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
During epoch transition, all operators are iterated over, even though we have short-circuit optimization to skip further processing for operators who have no deposit/withdraw/reward within this epoch, we still need to read the operator state first to determine if we can safely skip such operator.
Thus currently a database read is required for every operator during the epoch transition and because the total number of operators of a specific domain is unbounded, the weight of the epoch transition is also unbounded.
One way to fix this is to manually track operators who have deposit/withdraw/reward happened within the current epoch, and during epoch transition we only need to process these operators and leave the rest of the operators untouched.
The text was updated successfully, but these errors were encountered:
During epoch transition, all operators are iterated over, even though we have short-circuit optimization to skip further processing for operators who have no deposit/withdraw/reward within this epoch, we still need to read the operator state first to determine if we can safely skip such operator.
Thus currently a database read is required for every operator during the epoch transition and because the total number of operators of a specific domain is unbounded, the weight of the epoch transition is also unbounded.
One way to fix this is to manually track operators who have deposit/withdraw/reward happened within the current epoch, and during epoch transition we only need to process these operators and leave the rest of the operators untouched.
The text was updated successfully, but these errors were encountered: