feat: add flags to disable tx broadcast & receive

[yiweichi]

Reth counterpart of l2geth scroll-tech/go-ethereum#1194.
Related rollup-node PR: scroll-tech/rollup-node#181

Added two fields on NetworkConfig.
tx_gossip_broadcast_disabled: to disable transaction broadcasting to other peers.
tx_gossip_receive_disabled: to disable transaction receiving broadcasted from other peers.

[codspeed-hq]

CodSpeed Performance Report

Merging #266 will not alter performance

_{Comparing feat-disable-transaction-broadcast-receive (979204d) with scroll (766dd27)}

Summary

✅ 77 untouched benchmarks

[greged93]

Some small comments. I'm also wondering why the tx_gossip_disabled is not enough? Do we need more granularity in some cases?

[yiweichi]

Some small comments. I'm also wondering why the tx_gossip_disabled is not enough? Do we need more granularity in some cases?

Yeah, I think we will need this granularity. One of our side goal is to have a private transaction pool for sequencer. which means sequencer won't broadcast transactions it received, meanwhile we still need transaction receiving enabled.
So the granularity should be necessary.

[greged93]

meanwhile we still need transaction receiving enabled

Got it, I thought we would only use the SequencerClient you added in #265 but it makes sense to keep receive enable.

[greged93]

I think you're just missing a call to default for the network builder. Also need to fix the CI.

[frisitano]

We can achieve the same result without introducing any additional configuration flags in the codebase.

Objectives:

1. When the sequencer receives a transaction via the sequencer endpoint it should not gossip these transactions.
2. The sequencer can still receive transactions over the gossip network.

We can achieve these objectives by simply setting the configuration property propagate_local_transactions to false on the sequencer:

reth/crates/transaction-pool/src/config.rs

Lines 170 to 185 in 766dd27

	/// Configuration options for the locally received transactions:
	/// [`TransactionOrigin::Local`](TransactionOrigin)
	#[derive(Debug, Clone, Eq, PartialEq)]
	pub struct LocalTransactionConfig {
	/// Apply no exemptions to the locally received transactions.
	///
	/// This includes:
	/// - available slots are limited to the configured `max_account_slots` of [`PoolConfig`]
	/// - no price exemptions
	/// - no eviction exemptions
	pub no_exemptions: bool,
	/// Addresses that will be considered as local. Above exemptions apply.
	pub local_addresses: HashSet<Address>,
	/// Flag indicating whether local transactions should be propagated.
	pub propagate_local_transactions: bool,
	}

I question whether this PR is needed or if we can just use the configuration defined above to achieve our desired result.

[yiweichi]

We can achieve the same result without introducing any additional configuration flags in the codebase.

Objectives:

1. When the sequencer receives a transaction via the sequencer endpoint it should not gossip these transactions.
2. The sequencer can still receive transactions over the gossip network.

We can achieve these objectives by simply setting the configuration property propagate_local_transactions to false on the sequencer:

reth/crates/transaction-pool/src/config.rs

Lines 170 to 185 in 766dd27

	/// Configuration options for the locally received transactions:
	/// [`TransactionOrigin::Local`](TransactionOrigin)
	#[derive(Debug, Clone, Eq, PartialEq)]
	pub struct LocalTransactionConfig {
	/// Apply no exemptions to the locally received transactions.
	///
	/// This includes:
	/// - available slots are limited to the configured `max_account_slots` of [`PoolConfig`]
	/// - no price exemptions
	/// - no eviction exemptions
	pub no_exemptions: bool,
	/// Addresses that will be considered as local. Above exemptions apply.
	pub local_addresses: HashSet<Address>,
	/// Flag indicating whether local transactions should be propagated.
	pub propagate_local_transactions: bool,
	}

I question whether this PR is needed or if we can just use the configuration defined above to achieve our desired result.

I checked this out, yes it's obvious better to use propagate_local_transactions.
Nice catch, thanks!

Will close this PR after I tested propagate_local_transactions.

[yiweichi]

Close this PR since we can use propagate_local_transactions.