Skip to content

Conversation

ypatil12
Copy link
Collaborator

@ypatil12 ypatil12 commented Jul 11, 2025

Motivation:

We want to solve two problems:

  1. Currently, updateGenerator will not work in all cases because when we call updateOperatorTable, the bn254CertificateVerifier.isRootValidByTimestamp must be true. This only works if the latestReferenceTimestamp for the new generator is the same as what the previous generator was initialized to
  2. Have a clearer state machine for special casing the generator

Modifications:

  1. Get rid of setGenerator and only have updateGenerator
  2. Remove notion of a configurable referenceTimestamp from Generator. The Generator always has a reference timestamp of GENERATOR_REFERENCE_TIMESTAMP. Now, the reference timestamp is not set in initialization or in updateGenerator
  3. Require that updateGenerator can only be called for a new operatorSet.
  4. Require the updateOperatorTable cannot update the table for the Generator
  5. Prevent the GENERATOR_GLOBAL_TABLE_ROOT from being disabled
  6. Hard-code the operatorSetConfig for the generator
  7. Update deploy scripts to remove the referenceTimestamp and operatorSetConfig

Also, update documentation & zeus script for CrossChainRegistry.tableUpdateCadence

Result:

Clearer state machine

@eigenmikem eigenmikem merged commit 23c29ce into main Jul 14, 2025
20 checks passed
@eigenmikem eigenmikem deleted the fix/generator-update branch July 14, 2025 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants