- The Stellar project team introduced Project Thruput, an experimental execution model designed to remove performance bottlenecks when transactions access the same blockchain data simultaneously.
- In early tests, payment execution increased from 1.18 million per second on one machine to 7.02 million per second on eight machines.
- Project Thruput is available on the FutureNet test network with open-source code, technical documentation and reproducible benchmarks.
The Stellar project team introduced Project Thruput, an experimental transaction execution model intended to allow parallel processing even when operations modify the same blockchain state. The model matters because developers say it can scale computing capacity by adding hardware without sharding the blockchain.
In early tests, payment execution on a single validator rose from 1.18 million per second using one machine to 7.02 million per second using eight machines. Project Thruput is already available on FutureNet, alongside its open-source code, technical documentation and reproducible benchmarks.
How Project Thruput works
Stellar said many blockchains execute transactions in a single order or process them in parallel only when there are no data-access conflicts. Operations that try to modify the same balance or liquidity pool consequently may have to wait for one another.
Under Project Thruput, transactions within one block begin from the same ledger snapshot and can run in parallel even if they modify the same state. The system merges compatible changes when it commits the block.
For example, rather than writing a new balance value, a transaction can specify an operation that subtracts a particular amount. The system can merge such changes in different orders as long as they comply with defined constraints, while preventing two payments from spending the same funds simultaneously.
Developers can also define rules for groups of transactions, including a limit on the total amount withdrawn during a block. Storage types determine which changes can be combined and which limits the system must enforce.
Tests involving high data contention, with transfers limited to 100 accounts, showed performance increasing as the number of processor cores and machines grew. The best reported result was 7.02 million payments per second on eight machines, nearly six times the 1.18 million recorded on one machine.
The benchmarks covered RV32 ERC-20 transfers, transaction execution, signature verification and the full process from opening a block to finalizing it in Project Thruput’s core engine. They did not measure end-to-end network throughput.
Transaction fees and capacity limits
Project Thruput does not charge fees for individual transactions, a design intended to support free micropayments and complex computations such as portfolio risk calculations.
The model does not permit unlimited computation. Gas continues to measure and cap execution for each transaction. When demand exceeds available capacity, an account’s share of the scheduling queue depends on its unlocked balance of native tokens.
The tokens are not spent during scheduling, and transactions cannot gain priority by paying higher fees. A similar mechanism applies to data storage: part of an account’s balance is locked while the data remains stored and released after deletion.
Bermuda previously said it would move government payments on-chain using Stellar.
Source: Incrypted
