-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
geth: implement sync service spec #477
Conversation
🦋 Changeset detectedLatest commit: d743630 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@tynes please add a changeset with a minor version bump by running "yarn changeset" and going through the interactive dialogue! |
e9a2245
to
d743630
Compare
I've added the changeset with a minor bump. This should be ready for review now |
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.
A few changes requested internally.
Also, as a process point, I think we should be more diligent in having explicit commits for each change being made inside geth and contracts, since they are critical components for the core protocol.
This PR does a lot of refactoring/renaming, when that should be saved for a separate PR which changes no functionality and simply moves code around.
As another example, this commit should have been split into a few commits:
refactor: use transaction instead of response when parsing dtl response
refactor: rename updateContext to updateEthContext
feat: allow reading and writing verified batch indexes to the db
feat: add backend parameter to DTL queries
Similarly, when removing stuff, e.g. confirmationDepth
, you can add a commit that says chore: remove unused confirmationDepth param
.
Finally, if the DTL "choose your own backend" changes are NOT needed to implement the basic functionality, then they should be split in a separate PR. It does not make sense to add things to client.go
in this PR if they are not present in the DTL as well.
OK if you don't want to do this for this PR, but it'll make reviewing such code changes much easier in the future.
Another tip would be that after you're doing with your PR, git reset master
, and then start re-doing the commits individually so that they're logically split with git add -p
, to stage the hunks that matter for each logical change.
"fix typos" and "fix broken tests" commits are not useful for the reviewer, since they are changes introduced in this PR. The commit message is not about things you've done related to your previous commits, it's related to the things you've done related to master!
return nil, nil | ||
} | ||
// The queue origin must be either sequencer of l1, otherwise | ||
// it is considered an unknown queue origin and will not be processed | ||
var queueOrigin types.QueueOrigin | ||
if res.Transaction.QueueOrigin == "sequencer" { | ||
if res.QueueOrigin == "sequencer" { |
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.
Not for this PR, but we should replace strings with enums.
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.
@@ -849,6 +849,12 @@ var ( | |||
Value: time.Minute * 15, | |||
EnvVar: "ROLLUP_TIMESTAMP_REFRESH", | |||
} | |||
RollupSyncTypeFlag = cli.StringFlag{ | |||
Name: "rollup.synctype", | |||
Usage: "Transaction sync source", |
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.
Usage: "Transaction sync source", | |
Usage: "Transaction sync source (\"batched\" or \"sequenced\")", |
t.Fatal("verification failed", err) | ||
} | ||
|
||
go service.syncTransactionsToTip(SyncTypeSequenced) |
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.
Same as above comment on goroutine
// Run an iteration of the eloop | ||
err = service.sequence() | ||
if err != nil { | ||
t.Fatal("sequencing failed", err) | ||
} | ||
go service.syncQueueToTip() |
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 was this changed? IMO it is super error prone to use go-routines which we don't know how many iterations they'll run for inside tests. Better to explicitly run a single iteration (or N iterations for N transactions) inside.
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.
syncQueueToTip
does less things than sequence
and calling it once is a single iteration. This starts a goroutine that runs until syncQueueToTip
returns. This was added because if it does not run in a goroutine, it blocks due to the addition of txCh
and waiting explicitly for transactions to be added to the blockchain after processing them
txs := types.Transactions{tx} | ||
s.txFeed.Send(core.NewTxsEvent{Txs: txs}) | ||
// Block until the transaction has been added to the chain | ||
log.Debug("Waiting for transaction to be added to chain", "hash", tx.Hash().Hex()) | ||
<-s.chainHeadCh |
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.
@gakonst The chainHeadCh
is used here. This blocks until the the tx
is added to the chain. Without this, events are sent over the txFeed
much faster than they can be processed and things start breaking due to the combination of Clique
and the miner being used
Closed in favor of #552 |
Description
Implements the
SyncService
spec, still WIPhttps://github.com/ethereum-optimism/specs/blob/main/l2-geth/transaction-ingestor.md
The spec was designed to prevent double ingestion or skipping of ingestion of transactions. The function names in the spec should match 1:1 the methods on the
SyncService
. The actual logic implemented differs slightly from the spec in how it implements its break conditions, but is functionally equivalent.Application level attempt to allow for 0 downtime rollovers of the sequencer. I think this should code should be deleted and moved to the infra layerAdditional context
This is the first step to reorgs based on L1 as well as 0 downtime rollovers
This PR builds on top of #479 but is backwards compatible enough for the integration tests to work without it. The verifier really only takes advantage of the query param based syncing currently