HomeNewsTransforming the Future: Stellar Network Proposes Change in Transaction Submission for Enhanced...

Transforming the Future: Stellar Network Proposes Change in Transaction Submission for Enhanced Scalability and Safety

- Advertisement -
  • Stellar Network proposes a change to allow only one transaction per source account per ledger, fostering scalability and ensuring safety.
  • The new system will not affect fee bumps and channel accounts, which remain the best practices for safe transaction throughput increase.

As a seasoned blockchain expert, I’m excited to shed light on Stellar’s proposed change to transaction submission. This alteration aims to support the network’s scalability and safety, a crucial step towards implementing Soroban. The focus here is to limit the option of submitting multiple transactions concurrently from the same source account.

In essence, each account will be able to submit no more than one transaction per block. Concurrent transaction submissions from the same source accounts are generally viewed as poor practice due to the potential failure edge cases, hence the necessity of this change.

The planned update to Stellar-core is structured to permit only one transaction per source account per ledger. This means that while a Stellar node is processing a transaction from a given account (let’s say account A), any new transaction from A will be declined and need to be re-submitted later. In this context, “Processing” signifies the interval from a transaction’s entry into the transaction queue to its application to the ledger or discarding.

Stellar-core will accept new subsequent transactions immediately after the previous transaction is either confirmed or dropped due to surge pricing.

No discernable impact on fee bump functionality should be expected from this change. For instance, if a fee-bump transaction lands with the same or a different fee source and the inner transaction is already in the transaction queue, the new transaction won’t be rejected. Instead, it will replace the previous transaction provided that the fee bump is valid. Additionally, the same account can pay for multiple fee bumps per ledger, provided that the bumped transactions originate from different source accounts.

For users utilizing channel accounts, they won’t be affected, assuming the same channel account does not submit multiple transactions per ledger. Channel accounts are our preferred solution for transaction scaling.

The proposed alteration may introduce some restrictions to the Stellar network. However, we believe it’s a positive shift that will enhance the experience of network interaction. It does this by reducing ambiguity and confusion around when transactions are accepted into the network, and can also enhance the transaction submission contract and simplify implementations.

This new method will also eradicate issues around out-of-order transactions. Presently, Stellar-core discards transactions that arrive out of sequence. This reformulation will also mitigate the unpredictability of transaction submission results during surge pricing, an event where more transactions vie to get into the block than the network permits, thereby prompting the network to prioritize transactions with the highest fees.

The introduction of this change is a necessary step to safely support Soroban transactions. These transactions, considerably larger in size than current ones, utilize a multi-dimensional fee model. With Stellar’s built-in security features, this new approach allows for the propagation of Soroban transactions in a way that safeguards against denial of service attacks.

As for those who may be affected by this change, data suggests that the number of accounts with multiple transactions per ledger is very low. For these impacted users, we recommend channel accounts as the solution for submitting transactions to the network at a high rate.

The timeline for this change includes a community feedback collection period, the enforcing of a 1 transaction/account limit by SDF Horizon by July 12, followed by the release of Core version 19.13.0 on July 25 which sets the limit by default. The final phase involves the release of Core version 20.0.0 on August 22, which strictly enforces the limit and disallows users to disable it, leading up to the Protocol 20 vote in the fall of 2023 when the limit will be enforced network-wide.

Disclaimer: ETHNews does not endorse and is not responsible for or liable for any content, accuracy, quality, advertising, products, or other materials on this page. Readers should do their own research before taking any actions related to cryptocurrencies. ETHNews is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods, or services mentioned.
Nikita Dmitrievich
Nikita Dmitrievichhttps://www.ethnews.com/
Nikita, a young and ambitious crypto investor who has been actively involved in the cryptocurrency world for the past 6 years. With a keen interest in blockchain technology, Nikita has been investing in various cryptocurrencies and has seen significant returns on his investments. He is passionate about educating others on the potential of cryptocurrencies and frequently shares his insights on social media platforms. Nikita believes that cryptocurrencies are the future of finance and is constantly researching new projects to invest in. With his dedication and knowledge, Nikita is quickly becoming a prominent figure in the crypto community. Business Email: info@ethnews.com Phone: +49 160 92211628