Proposed Changes To Transaction Submission

We’re proposing an update to stellar-core to allow 1 transaction per source account per ledger. This means that if a Stellar node is currently processing a transaction from account A, any new transaction from A will be rejected, and will need to be re-submitted later. “Processing” refers to the time period between a transaction entering the transaction queue and being applied to the ledger or dropped. Core will accept new subsequent transactions as soon as the previous transaction is either confirmed or dropped due to surge pricing.

Fee bumps

Users should not see any impact to fee bump functionality. That is, if a fee-bump transaction arrives with the same or different fee source and the inner transaction is already present in the transaction queue, the new transaction will not be rejected, and instead will replace the previous transaction (assuming that fee bump is valid, of course). In addition, the same account is allowed to pay for multiple fee bumps per ledger (assuming that bumped transactions have different source accounts).

Channel accounts

Users utilizing channel accounts are unaffected, assuming the same channel account does not submit multiple transactions per ledger. Furthermore, using channel accounts is our recommended solution for transaction scaling (more on this below).

This change would introduce some restrictions to the Stellar network, but we believe that this is a positive change that will improve the experience of interacting with the network because:

• It reduces ambiguity and confusion about when transactions are accepted to the network
• It can improve the transaction submission contract and make implementations easier. The current functionality is “best effort,” meaning that depending on the network conditions/infrastructure setup, users may not be able to achieve the desired throughput and have to implement complicated error-handling/retry mechanisms.

Several examples below illustrate the challenges around scaling transaction throughput with multiple-transactions-per-account mechanism.

Out-of-order transactions

Stellar-core drops transactions that arrive out of order (with “bad sequence number” error). Horizon tries to protect against that by reordering transactions in-memory, but there are caveats:

• The re-ordering has no effect if multiple Horizon instances are used.
• For this reason, the reordering does not work on SDF Horizon
• For single-threaded Horizon instances with a single server, submitting 1 or multiple transactions per source account has no effect because Horizon transaction submission endpoint blocks until the transaction makes it into the ledger or gets dropped*

‍*This isn’t always true, as sometimes Horizon reports timeouts on transactions that aren’t _actually_ dropped by the network.

Surge pricing

The current behavior makes transaction submission results quite unpredictable when the network is experiencing surge pricing* (which occurs frequently on the network). Specifically, if account A submits T1..TN to the queue, while the network is in surge pricing, all new transactions will be stuck until T1 is included in the ledger (even if T2…TN have very high fees). Even worse, if T1 is dropped, all subsequent transactions have to be dropped and re-submitted. If the user wants to fee-bump some transactions, they’ll need to fee-bump all transactions ahead for fee bumps to have any effect.

*surge pricing is an event when there are more transactions wanting to get into the block than the network allows, causing the network to prioritize transactions with highest fees

In addition to the reasons above, this change is necessary to safely support Soroban. Soroban transactions are quite different from current transactions: they are potentially much bigger in size, and use a multi-dimensional fee model. Stellar-core has various built-in security features, and SDF works with the broader ecosystem to suggest improvements that help ensure the network is robust and resilient. Switching to 1 transaction/account limit allows propagating Soroban transactions in a way that protects against denial of service attacks.

Because the same source accounts pay fees for both Stellar and Soroban transactions, and due to limitations/complexity of the stellar-core implementation, this solution applies to all transactions submitted to stellar-core.

Before suggesting this change, we took a look at historical data which suggests that the number of accounts with multiple transactions per ledger is very low. For impacted users, channel accounts are the recommended solution for submitting transactions to the network at a high rate because:

• Channel accounts remove the dependency on sequence numbers that cause transactions to get “stuck” behind others if the network is under heavy load. They allow users to fee-bump or re-submit the desired transactions individually.
• Channel accounts remove the need to handle complicated failure scenarios where “chains of transactions” are dropped or banned on the network and need to be re-submitted.

The new limit is needed for Protocol 20, which introduces Soroban support, to function correctly. That is, the limit needs to be enforced network-wide before nodes vote to upgrade to Protocol 20. The proposed timeline is as follows:

• Now: collect feedback from the community about the proposed change
• July 12: SDF Horizon forces 1 transaction/account limit.
  Option to disable: Impacted users may still run their own Horizon instance and disable the flag.
• July 25: Core version 19.13.0 is released which sets the limit by default.
  Users can manually disable the limit. However, as other nodes upgrade to 19.13.0, users that disable it may see transaction submission issues as the rest of the network won’t accept multiple transactions per account.
• August 22: Core version 20.0.0 is released which forces the limit and does not allow users to disable it.
  As nodes/Horizons upgrade to 20.0.0, users that still disable the limit may see transaction submission issues as the rest of the network won’t accept multiple transactions per account.
• Fall 2023: Protocol 20 vote, limit is enforced network-wide.
  Any node not running v20.0.0 won’t be able to sync with the network

Is your experience different from what’s described above? Do you think this isn’t the right change? Let us know! We want to understand your use case, and help you find the best solution.