Disclaimer: The opinions expressed by our writers are their own and do not represent the views of U.Today. The financial and market information provided on U.Today is intended for informational purposes only. U.Today is not liable for any financial losses incurred while trading cryptocurrencies. Conduct your own research by contacting financial experts before making any investment decisions. We believe that all content is accurate as of the date of publication, but certain offers mentioned may no longer be available.
At the week's start, Ripple CTO emeritus David Schwartz addressed concerns about the possibility of front-running or transaction sandwich attacks on XRPL payments and offer crossing.
Schwartz proposed a fairly simple transaction reservation scheme that would eliminate such concerns by reserving transaction slots. The transaction reservation scheme will ensure that a transaction executes before any subsequent transactions created after it are disclosed.
This attracted reactions from various quarters of the XRP community, with some asking how the scheme could work for the XRP Ledger.
In one such instance, an X user asked if it will be possible to add a "time stamp down to the second, so that when transactions are ordered they would be ordered by time, that way if someone submitted a transaction after it would be at least a second after and would automatically get ordered after the first one."
Ripple software engineer Mayukha Vadari joined the conversation, answering this question in the negative, noting that different nodes may receive each transaction at slightly different times, as transactions have to propagate through the peer network.
Schwartz highlighted that the closest thing to this is consensus-based transaction ordering, with validators voting on it as part of the consensus process.
Transaction ordering: here's the catch
On the question of transaction ordering, Schwartz describes a likely scenario: one determined by consensus with validators voting on it as part of the consensus process.
The Ripple CTO Emeritus noted that there are a lot of disadvantages to this. The big one is that it would slow the consensus process significantly because the number of bits on which to reach consensus will increase.
Schwartz mentioned one option: having a flag to request sequencing set on a transaction, but this would cost an extra fee. Transactions with the flag set would be prioritized for relaying above transactions without the flag in the same ledger, and their ordering would be determined by consensus. He, however, sees a catch: it might enable front-running or sandwich attacks.
"I don't think it's worth it though, particularly because it makes it easier to front-run or sandwich transactions that don't set the flag," Schwartz said.
U.Today Editorial Team
Dan Burgin
