Skip to content

Conversation

iovoid
Copy link
Contributor

@iovoid iovoid commented Jul 1, 2025

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

@iovoid iovoid requested review from jrchatruc, ManuelBilbao and a team as code owners July 1, 2025 20:40
Copy link

github-actions bot commented Jul 1, 2025

Lines of code report

Total lines added: 21
Total lines removed: 0
Total lines changed: 21

Detailed view
+---------------------------------------------------------+-------+------+
| File                                                    | Lines | Diff |
+---------------------------------------------------------+-------+------+
| ethrex/crates/l2/contracts/bin/deployer/cli.rs          | 376   | +9   |
+---------------------------------------------------------+-------+------+
| ethrex/crates/l2/contracts/bin/deployer/main.rs         | 626   | +1   |
+---------------------------------------------------------+-------+------+
| ethrex/crates/l2/prover/zkvm/interface/src/execution.rs | 349   | +9   |
+---------------------------------------------------------+-------+------+
| ethrex/crates/l2/prover/zkvm/interface/src/io.rs        | 83    | +2   |
+---------------------------------------------------------+-------+------+

@@ -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());
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@tomip01 tomip01 left a 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

@iovoid iovoid added this to ethrex_l2 Jul 2, 2025
@iovoid iovoid added the L2 Rollup client label Jul 2, 2025
@iovoid iovoid self-assigned this Jul 2, 2025
@iovoid iovoid changed the base branch from main to refactor/simplify-privileged July 2, 2025 19:45
Base automatically changed from refactor/simplify-privileged to main July 2, 2025 20:09
@iovoid iovoid force-pushed the feat/inclusion-deadline branch from eb057fa to 848a2d5 Compare July 2, 2025 20:16
@iovoid iovoid moved this to In Review in ethrex_l2 Jul 2, 2025
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;
Copy link
Contributor

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?

Copy link
Contributor Author

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;
Copy link
Contributor

@fkrause98 fkrause98 Jul 3, 2025

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.

Copy link
Contributor Author

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 statediffs
  • MIN_INCLUDED_PRIVILEGED_TX should be an u16, to avoid accidentally setting impossible values
  • pending_count is necessarily an u256, because X.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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

Copy link
Contributor

@fkrause98 fkrause98 left a 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.

Copy link
Contributor

@avilagaston9 avilagaston9 left a 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.

Comment on lines 93 to 96
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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@github-project-automation github-project-automation bot moved this from In Review to Requires Changes in ethrex_l2 Jul 8, 2025
CommonBridge ->> Sequencer: OK
Sequencer ->> CommonBridge: Sends batch of only privileged transactions
CommonBridge ->> Sequencer: OK
Note: Sequencer catches up
Copy link
Collaborator

@MegaRedHand MegaRedHand Jul 14, 2025

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

Copy link
Contributor Author

@iovoid iovoid Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 25e6a46.

Comment on lines 477 to 481
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"
);
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@github-project-automation github-project-automation bot moved this from In Review to Requires Changes in ethrex_l2 Jul 17, 2025
Copy link
Contributor

@ManuelBilbao ManuelBilbao left a 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

@iovoid iovoid added this pull request to the merge queue Jul 18, 2025
Merged via the queue into main with commit 894ac49 Jul 18, 2025
41 checks passed
@iovoid iovoid deleted the feat/inclusion-deadline branch July 18, 2025 20:48
@github-project-automation github-project-automation bot moved this from Requires Changes to Done in ethrex_l2 Jul 18, 2025
pedrobergamini pushed a commit to pedrobergamini/ethrex that referenced this pull request Aug 24, 2025
**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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L2 Rollup client
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Parametrize force inclusion
7 participants