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 |
There was a problem hiding this comment.
@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.
is backend in this case defaultSource or a different concept?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
do you mean to make the default 'batched' here instead of 'l1'?
There was a problem hiding this comment.
Good catch, this is the bug that is causing CI to fail
There was a problem hiding this comment.
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.
if we anticipate adding more sources
['batched', 'sequenced'].includes(val)There was a problem hiding this comment.
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
There was a problem hiding this comment.
is backend in this case defaultSource or a different concept?
.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.
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.
* 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
Closes op-rs/op-reth#467 - Adds `initialize-op-proofs` command to book - Adds new op proofs flags for op-reth node command to book --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com>
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 optionshowUnconfirmedTransactionsbeing 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.