-
Notifications
You must be signed in to change notification settings - Fork 101
feat(l2): privileged transaction inclusion deadline #3427
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
Conversation
Lines of code reportTotal lines added: Detailed view
|
crates/l2/sequencer/l1_committer.rs
Outdated
@@ -359,7 +361,7 @@ async fn prepare_batch_from_block( | |||
|
|||
// Accumulate block data with the rest of the batch. | |||
acc_messages.extend(messages.clone()); | |||
acc_deposits.extend(deposits.clone()); | |||
acc_privileged_txs.extend(privileged_transactions.clone()); |
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.
Can we avoid this clone?
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.
acc_X needs to have an owned version. .iter().cloned()
could also work though.
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.
Just one small comment
eb057fa
to
848a2d5
Compare
uint256 public constant PRIVILEGED_TX_MAX_WAIT_BEFORE_INCLUSION = 300; | ||
/// @notice Minimum of privileged transactions that must be included to reset the deadline | ||
/// @dev If there aren't that many pending, pendingTxHashes.length is used | ||
uint16 public constant MIN_INCLUDED_PRIVILEGED_TX = 10; |
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 do we use an uint16 here? What's the benefit vs simply using uint256?
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.
To avoid having to downcast it later. State diffs only support u16::MAX
privileged transactions.
@@ -390,6 +403,17 @@ contract OnChainProposer is | |||
emit BatchVerified(lastVerifiedBatch); | |||
} | |||
|
|||
function _checkAndUpdateInclusionQuota(uint16 privileged_transaction_count) private { | |||
uint256 pending_count = ICommonBridge(BRIDGE).getPendingTransactionHashes().length; | |||
uint16 mimimum_to_include = MIN_INCLUDED_PRIVILEGED_TX > pending_count ? uint16(pending_count) : MIN_INCLUDED_PRIVILEGED_TX; |
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.
This is a bit strange, pending_count is uint256, and we then cast it to uint 16. Why is that?
I'm not saying this is wrong, but I don't see the benefit vs simply setting the type to uint256 and avoid potential issues.
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.
Of the types:
privileged_transaction_count
is necessarily an u16, because of a limitation in statediffsMIN_INCLUDED_PRIVILEGED_TX
should be an u16, to avoid accidentally setting impossible valuespending_count
is necessarily an u256, becauseX.length
returns one. If it's less than MIN_INCLUDED_PRIVILEGED_TX, then it can be safely downcasted.
This way minimizes the number of casts and also prevents user error.
uint256 public constant PRIVILEGED_TX_MAX_WAIT_BEFORE_INCLUSION = 300; | ||
/// @notice Minimum of privileged transactions that must be included to reset the deadline | ||
/// @dev If there aren't that many pending, pendingTxHashes.length is used | ||
uint16 public constant MIN_INCLUDED_PRIVILEGED_TX = 10; |
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.
Ditto
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.
Looks good, left some comments though.
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.
I think our committer, as it is now, can easily get stuck with these changes.
Let's suppose a scenario where the deadline is reached, but when the committer builds the batch, only two deposits have been made. The committer then builds the transaction, and before it is included, one more deposit is made. The transaction will revert because privileged_transaction_count < minimum_to_include
, but our committer will retry forever with the same batch.
uint256 public constant PRIVILEGED_TX_MAX_WAIT_BEFORE_INCLUSION = 300; | ||
/// @notice Minimum of privileged transactions that must be included to reset the deadline | ||
/// @dev If there aren't that many pending, pendingTxHashes.length is used | ||
uint16 public constant MIN_INCLUDED_PRIVILEGED_TX = 10; |
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.
Does defining these constants like this force us to recompile the binaries each time we want to update them?
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.
Moved to the initializer in 7ebe8c0 to avoid that.
docs/l2/deposits.md
Outdated
CommonBridge ->> Sequencer: OK | ||
Sequencer ->> CommonBridge: Sends batch of only privileged transactions | ||
CommonBridge ->> Sequencer: OK | ||
Note: Sequencer catches up |
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.
GitHub is giving me errors when parsing this line:
Unable to render rich display
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.
Fixed in 25e6a46.
uint256 nonPrivilegedTransactions = uint256(bytes32(publicData[160:192])); | ||
require( | ||
ICommonBridge(BRIDGE).withinProcessingDeadline() || nonPrivilegedTransactions == 0, | ||
"OnChainProposer: exceeded privileged transaction inclusion deadline, can't include non-privileged transactions" | ||
); |
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.
Isn't nonPrivilegedTransactions == 0
equivalent to enforcing privileged_transaction_count > 0
? I think we should also file an issue to prioritize deposits in the 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.
Technically, it's not the same. But isn't it better?
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.
No, that would only ensure at least one is being processed. We want normal ones to not advance.
Otherwise the sequencer could just send 10000 privileged transactions, include a single one per batch and stall user-made ones forever.
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.
Just a few comments on docs
**Motivation** To prevent the sequencer from censoring transactions, we want to force it to include at least some of them. **Description** This PR introduces a deadline after which either `INCLUSION_BATCH_SIZE` (or all pending transactions, if there are less) privileged transactions are included, or the batch is rejected. Closes lambdaclass#3230
Motivation
To prevent the sequencer from censoring transactions, we want to force it to include at least some of them.
Description
This PR introduces a deadline after which either
INCLUSION_BATCH_SIZE
(or all pending transactions, if there are less) privileged transactions are included, or the batch is rejected.Closes #3230