-
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
dtl: add query param based querying for txs #479
Conversation
🦋 Changeset detectedLatest commit: e86ee09 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 |
@@ -156,8 +156,7 @@ export class L1TransportServer extends BaseService<L1TransportServerOptions> { | |||
* TODO: Link to our API spec. | |||
*/ | |||
private _registerAllRoutes(): void { | |||
// TODO: Maybe add doc-like comments to each of these routes? | |||
|
|||
// TODO: this needs a backend argument | |||
this._registerRoute( | |||
'get', |
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.
@smartcontracts Any thoughts on how to reduce complexity in this endpoint? We need to add the backend
query param to this so that it can determine whether or not its sync'd L1 or L2. Ideally we refactor the db handlers now that we are moving away from confirmed/not confirmed as concepts in this codebase
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.
is backend
in this case defaultSource
or a different concept?
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.
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.
what do you think is too complex here? This looks OK to me.
I'm talking about the crazy if/else nesting
https://github.com/ethereum-optimism/optimism/pull/479/files#diff-29a43f33722b902c31ee7224a372262d2b73f170ed0af5be6aca1b54aa505a72L183-L211
e2efd16
to
a129eeb
Compare
sentryDsn: config.str('sentryDsn'), | ||
defaultSource: config.str('defaultSource', 'l1'), |
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.
do you mean to make the default 'batched'
here instead of 'l1'
?
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.
Good catch, this is the bug that is causing CI to fail
defaultSource: { | ||
default: 'batched', | ||
validate: (val: string) => { | ||
return val === 'batched' || val === 'sequenced' |
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.
will we have more sources than batched
or sequenced
in the future? assuming no since it seems like they directly correspond to l1
and l2
right?
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.
if we anticipate adding more sources
['batched', 'sequenced'].includes(val)
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.
They don't necessarily correspond to L1 and L2 per say, really the abstraction is batched or batched + pre-batched. The batched transactions are currently batched to Ethereum L1 but will be batched to an Eth2 data shard in the future.
Working on unifying the language between the different codebases.
['batched', 'sequenced'].includes(val)
We only have 2 sources right now so I think its fine. I prefer writing JS using a subset of the language that is as C like as possible with Python sprinkled in, see https://github.com/handshake-org/hsd/blob/master/lib/blockchain/chain.js as an example
@@ -156,8 +156,7 @@ export class L1TransportServer extends BaseService<L1TransportServerOptions> { | |||
* TODO: Link to our API spec. | |||
*/ | |||
private _registerAllRoutes(): void { | |||
// TODO: Maybe add doc-like comments to each of these routes? | |||
|
|||
// TODO: this needs a backend argument | |||
this._registerRoute( | |||
'get', |
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.
is backend
in this case defaultSource
or a different concept?
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!
.changeset/calm-books-hope.md
Outdated
"@eth-optimism/data-transport-layer": patch | ||
--- | ||
|
||
Add backwards compatible query params to REST API |
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.
Nit: May want to make your message a bit clearer, I do not understand what you changed just by reading this.
Something like: Allow the DTL to provide data from either L1 or L2, configurable via a query param sent by the client.
@@ -156,8 +156,7 @@ export class L1TransportServer extends BaseService<L1TransportServerOptions> { | |||
* TODO: Link to our API spec. | |||
*/ | |||
private _registerAllRoutes(): void { | |||
// TODO: Maybe add doc-like comments to each of these routes? | |||
|
|||
// TODO: this needs a backend argument | |||
this._registerRoute( | |||
'get', |
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.
* dtl: remove stopL2SyncAtHeight config * dtl: implement query param based backend * dtl: remove dead comment * dtl: add changeset * dtl: standardize on backend query param * changeset: update comment
Description
The DTL currently prioritizes transactions sourced from L2 instead of transactions sourced from L1. This was a quick patch required for sequencer maintenance, the source of truth should generally be L1. This allows the client to specify a query param that says to source the transaction from L1 or from L2
Additional context
Related to #477
Previously query params had no impact on the DTL. The DTL has a backing index for both transactions ingested from the L1 contracts (CTC + SCC) and an index for transactions pulled from a sequencer (
eth_getBlockByNumber
). The DTL has preferred different data sources over time. Before this PR, the config optionshowUnconfirmedTransactions
being set to true would prefer the L2 sourced transactions but then fall back to L1 sourced transactions. After this PR, the client will specify the data source and then the server will only return that transaction sourced from that datasource.