Skip to content
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

Merged
merged 15 commits into from
Jan 23, 2025

Conversation

samlaf
Copy link
Collaborator

@samlaf samlaf commented Jan 14, 2025

Fixes Issue

Fixes #230

Changes proposed

Contains 2 main changes needed to remove archive node requirements:

  1. 4d85d3b: force ethConfirmationDepth to be <64 (so we read at most 64 blocks in the past, while normal nodes store the latest 128 states): not strictly necessary as this was a flag which could have been set by teh validators anyways, but its a nice to have to make sure that the code works even without archival node dependency.
  2. c4e6c90: read the quorum parameters (required quorums and adversary thresholds) from the EigenDAServiceManager only once, at startup.

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:

// Note: this strategy (fetching once and caching) only works because these parameters are immutable.
// They might be different in different environments (for eg on a devnet or testnet), but they are fixed on a given network.
// We used to allow these parameters to change (via a setter function on the contract), but that then forced us here in the proxy
// to query for these parameters on every request, at the batch's reference block number (RBN).
// This in turn required rollup validators running this proxy to have an archive node, in case the RBN was >128 blocks in the past,
// which was not ideal. So we decided to make these parameters immutable, and cache them here.

Screenshots (Optional)

Note to reviewers

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.
@samlaf samlaf marked this pull request as draft January 14, 2025 00:51
@samlaf samlaf requested a review from EthenNotEthan January 14, 2025 00:51
@samlaf samlaf changed the title Chore modify verifier to not require eth archive node chore: modify verifier to not require eth archive node Jan 14, 2025
README.md Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
verify/cert.go Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
@samlaf samlaf marked this pull request as ready for review January 22, 2025 01:45
verify/cert.go Show resolved Hide resolved
verify/cert.go Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
verify/cert.go Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
verify/cert.go Outdated Show resolved Hide resolved
@samlaf samlaf requested a review from litt3 January 23, 2025 16:25
@@ -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.
Copy link
Collaborator

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

Copy link
Collaborator Author

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.

flags/eigendaflags/cli.go Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
common/consts/consts.go Outdated Show resolved Hide resolved
flags/eigendaflags/cli.go Outdated Show resolved Hide resolved
// 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.
Copy link
Collaborator

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

Copy link
Collaborator Author

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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.

verify/cert.go Outdated Show resolved Hide resolved
verify/cert.go Show resolved Hide resolved
@samlaf samlaf requested a review from EthenNotEthan January 23, 2025 17:44
Copy link
Collaborator

@EthenNotEthan EthenNotEthan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@samlaf samlaf merged commit deac7be into main Jan 23, 2025
9 checks passed
@samlaf samlaf deleted the chore--modify-verifier-to-not-require-eth-archive-node branch January 23, 2025 18:17
// 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
Copy link
Collaborator

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.

@@ -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.
Copy link
Collaborator

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

samlaf added a commit that referenced this pull request Jan 24, 2025
samlaf added a commit that referenced this pull request Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove archive node requirements
4 participants