-
Notifications
You must be signed in to change notification settings - Fork 1k
Description
It is apparent that the bottleneck for an optimized Stellar-core setup is the number of operations that a single threaded CPU can handle.
Current state of things
Currently, there is a default configured limit of 50 transactions per ledger. This limit is useless at preventing operations from flooding the network stay afloat because someone who wants to attempt to slow down the network can send 50 transactions with 20 operations each for a total of 1000 operations.
Instead, the limit should be on the number of operations per ledger so that regular use cases (1 op/tx) can take up as much space as flooding use cases can (20 op/tx).
Stellar-Core operators ramifications
The network operators should coordinate to set a safe limit that all the nodes can sustain. Then, together, they can raise the limits.
New default proposal (with numbers)
On a standalone stellar-core instance, I observed that number of operations is strongly correlated to the time between getting consensus and closing the ledger.
If we aim to reserve 3-4 out of 5 seconds for consensus to happen, that leaves us with 1-2 seconds to apply ledgers. We can easily do 500-1000 operations per ledger on modern CPUs using the worse case number from my test above.
I suggest setting the number to 1000 operations per ledger. This 1000 operations per ledger number is similar to the current 50 transactions per ledger number since 50 transactions/ledger * 20 operations/transactions = 1000 transactions/ledger
. This number means we can safely do 200 operations/s.
Note: This test was run on a Payment operation which only involves 2 affected accounts. With a Path Payment transaction, I believe one can have 5 intermediate paths, a start, and an end. Meaning with maxed out Path Payment tx can have 7 affected accounts, which may be enough to crash the network at 50 tx/ledger meaning 7000 affected accounts per ledger