draft(optimism): sendRawTransactionConditional #13926
Conversation
emhane
added
A-block-building
| @@ -10,6 +10,10 @@ pub struct RollupArgs { | |||
| #[arg(long = "rollup.sequencer-http", value_name = "HTTP_URL")] | |||
| pub sequencer_http: Option<String>, | |||
|
|
|||
| /// Enable transaction conditional support on sequencer | |||
| #[arg(long = "rollup.sequencer-transaction-conditional-enabled", default_value = "false")] | |||
There was a problem hiding this comment.
let's rename this to enable-transaction-conditional
| /// Indiciator if this transaction has been marked as rejected | ||
| rejected: AtomicBool // (is AtomicBool appropriate here?) |
There was a problem hiding this comment.
we can remove this for now, because we'll handle eviction differently
|
|
||
| /// Optional conditional attached to this transaction. Is this | ||
| /// needed if this field is on OpTransactionSigned? | ||
| conditional: Option<TransactionConditional>, |
There was a problem hiding this comment.
yes we need this field here.
this option is also fine because this tx type is always wrapped in an Arc so it's always on the heap anyway
|
|
||
| /// Can we attach a conditional the moment a transaction is deserialized? | ||
| pub conditional: Option<TransactionConditional> |
There was a problem hiding this comment.
this we shouldn't do, because this is a representation fo the actual tx type and shouldn't be annotated with out of protocol data
| } | ||
|
|
||
| // TEMPORARY since TransactionConditional does not impl eq |
There was a problem hiding this comment.
mind submitting a pr on alloy for this?
There was a problem hiding this comment.
Looping back to these changes this week. Saw alloy-rs/alloy#1953. Thanks for adding that in there
|
hey @hamdiallam thanks a lot for your PR! we need to speed up the implementation of features that this PR touches, see this tracking issue for reference #14192 I've started extracting part of your work from here in this PR #14264, picked your commit as the base so that your work is accredited. will take care of rebasing this one and fixing any eventual conflicts as soon as it is merged |
Hey! I'm fine closing this since this was one to gather questions and I have an idea of how better implement this now. Now taking a more incremental approach and had #14086 open for a while. Do you mind looking at the latest comment I left in there? That one was in a state ready to merge in but the latest changes to main resulted a lot of conflicts |
ok sgtm thanks!
looks like the issue #14086 was meant to close is already fixed, not sure if more changes in that regard are required, probably @mattsse can confirm |
The interface for PayloadTransactions was updated. But that PR's main goal was to update the OpPayloadBuilder to operate on the OpPooled tx type which will hold reference to the conditional. I'm rebasing the PR right now so it can leverage the latest changes. The PR was tackling both since an update to PayloadTransactions was required #13901 |
Leaving a few comments in the different places that might require changes. Will flesh out an implementation after a soft approval/guidance in the right direction
OpTransactionSigned/OpPooledTransaction. References toconditionaland notion ofrejectedOpTransactionSigned. We need reference to the conditional to validate duringexecute_best_transactionsand a means to invalidate from the pool.L2EthApiExt&OpTransactionSigned: Can the conditional be attached as an optional field on the deserialized tx? This waypool::add_transactionis simply used. Or should a pool wrapper have a separate interface for submission.PoolWrapper -> If we wrap the
Poolinterface, should this filter out the rejected txs and in a background task remove them from the pool?validate_onewhich would duplicate the conditional checks