Ripple CTO Emeritus Weighs Major XRP Ledger Transaction Change, but Sees Catch

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.