-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: modify verifier to not require eth archive node #241
chore: modify verifier to not require eth archive node #241
Conversation
We panic in the flag's action, as well as in the verifier's constructor when this condition is not respected. This will make sure that an archival node is not required.
…ization This removes the need for running with an eth archive node.
@@ -118,6 +118,7 @@ func CLIFlags(envPrefix, category string) []cli.Flag { | |||
Category: category, | |||
}, | |||
&cli.BoolFlag{ | |||
// This flag is DEPRECATED. Use ConfirmationDepthFlagName, which accept "finalization" or a number <64. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
knit - this comment is redundant with the error action message below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but I prefer to keep it there. An action typically is not meant for deprecation, so on a first reading without the comment one would read through this entire flag and it would take some brain processing to figure out its deprecated. Typically some redundancy is always good in programming. Also helps catch errors.
// from the EigenDAServiceManager contract at the latest block. | ||
// We then cache these parameters and use them in the Verifier to verify the certificates. | ||
// | ||
// Note: this strategy (fetching once and caching) only works because these parameters are immutable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
immutable per the implementation contract right? IIUC we could technically still upgrade the source proxy contract with a new implementation with alternative bytecode defining different immutable values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but you're the one asking me to reduce comment cognitive overload :P
Do you think I should add that explanation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nah not necessary for an explanation - more just calling out a potential risk. i.e if the service manager were to be upgraded arbitrarily to use a different quorum then proxy would have no conception? maybe lets callout in a small issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep agree. Thanks for raising this. Will go ahead and merge as is, but let's keep in mind the entire space of interaction with the smart contracts as we go forward, especially for V2 as we try to make the SecurityThresholds upgradeable again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
// ethConfirmationDepth is using to verify that a blob's batch has been bridged to the EigenDAServiceManager contract at least | ||
// this many blocks in the past. To do so we make an eth_call to the contract at the current block_number - ethConfirmationDepth. | ||
// Hence in order to not require an archive node, this value should be kept low. We force it to be < 64. | ||
// waitForFinalization should be used instead of ethConfirmationDepth if the user wants to wait for finality (typically 64 blocks in happy case). | ||
ethConfirmationDepth uint64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks to me this variable is the upper bound for the punctuality gap.
In v2 we don't have to worry about it.
Tangential question, how to ensure all proxy set the same parameters, and upgrades.
flags/eigendaflags/cli.go
Outdated
@@ -210,7 +210,12 @@ func validateConfirmationFlag(val string) error { | |||
} | |||
|
|||
if depth >= 64 { | |||
log.Printf("Warning: confirmation depth set to %d, which is > 2 epochs (64). Consider using 'finalized' instead.\n", depth) | |||
// We keep this low (<128) to avoid requiring an archive node (see how this is used in CertVerifier). | |||
// Note: assuming here that no sane person would ever need to set this to a number to something >64. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why this is insane to set > 64. Is it reasonable assumption
Fixes Issue
Fixes #230
Changes proposed
Contains 2 main changes needed to remove archive node requirements:
Also updated the README with this information in cc3538f
Copying the comment on the
getQuorumParametersAtLatestBlock
function here to highlight the solution proposed in this PR:Screenshots (Optional)
Note to reviewers