Predictive transaction sorting in block to avoid arbitration spam without increasing transaction fees

Web3 Wallet
1

Current problem

Arbitration bots are spamming the network with very little value of the transaction. The logic behind this behavior is that they are splitting arbitration trades in multiple micro-transactions, to reduce the chance of being outpaced by another trader.

Currently, a bot that is not spamming has a big chance of seeing his transaction reverted due to a front-ran transaction done by another spammer bot, causing slippage.
As transaction order inside blocks are kept to the discretion of the validator, having hundred of micro-transactions increase the chance of having a good amount of those transactions completed,

while having one big transaction would eventually have a greater chance to fail, with zero profit created for the arbiter.

Short term solution from the Harmony team is to change the minimum gas-fees rate from 1 Gwei to 30 Gwei. This solution however comes with a cost of accessibility for our users.
Currently, Harmony’s key feature is low-gas fees transaction, which attracted thousands of users from third-world countries, and a lot of video-game projects like Defi Kingdoms or Crypto Royale.
Those games rely heavily upon daily transactions made by users, which can cost multi-millions gas each.

As an example, a “quest” transaction in Defi Kingdoms (6 heroes, end of quest, 5 runs) would cost approximately 5M gas, or ~0.15 one with a minimum Gwei per gas of 30 Gwei.

It is at the current One token price around 4cts/tx @ 30 Gwei, which seems affordable enough but might prove to be harmful in the long run, as One token price might raise in the future.

I do believe there is a better solution to this problem, and Harmony should keep an edge against competition in the transaction fee domain.

Solution

The solution I want to discuss here would be to:

  • Ensure predictive sorting of transaction in each block created, each transaction being sorted by hash of the transaction data contained into the transaction.
  • Add an optional parameter “customNonce” into the block to offer the possibility to the block signatory to forge a signature of small size, allowing the creator to “front-run” the block.

Given this solution is provided to the arbitration bots, their ability to take profit now will rely on their capability of quickly generating a nonce which allows them to have a hash with low value.

There won’t be any interest anymore into spamming each block with many transactions, as a big transaction with customNonce well-crafted to be prioritized into the block will outrun most of the remaining transactions.

The competition race between bots will be kept outside the blockchain, and they will need to invest in their own equipment to forge the best nonce in the limited amount of time of a block.

This system will also complicate the possibility for a “greedy” validator to inject front-run transactions into any block based on the current backlog of transactions, as they will need during the little time they have to perform a search for the best nonce to prioritize their transaction and outrun other transactions.

The field could remain optional, in which case the value of the customNonce would be “0”, allowing any existing client to continue working without any modification, while bot creators and specialized developers could update their client, take advantage of this feature to push their transaction on top of the block.

6 Likes
2

This sounds like a great proposal rather than increasing gas.

1 Like
3

Thanks for the suggestion @anykeyh
Tagging @rongjian.

4 Likes
4

that’s a clever idea. Hats off !

2 Likes
5

This sounds great, hope something like this can be implemented!

2 Likes
6

Thanks for the analysis and the proposal. A few questions:

  1. I don’t get it that spamming with micro-transactions will get better chance of front-running others. As far as I know, to get the txn in, it depends on 2 factors: 1) sending the txn earlier than others; 2) setting a higher gas price. Can you elaborate on what do you mean by micro-transactions and how it’s helping the arbitration bots to win?

  2. For the idea of “customNonce”, if I understand it correctly, it’s like a txn mining process? what txn with lower customNonce will be ordered higher in the block?

3 Likes
7

Hi and thanks for your answer,

First thing, let me tell you that my post is naive, in the sense that I wrote it with intuition, reactively to this announcement from the team and without proper documenting myself. Also, I’m not a blockchain developer, so I might overlook some things and have shallow knowledge on some subjects :slight_smile:.

Since I’ve spent few hours today getting deeper into the subject, I realized that I didn’t invented anything here, as the same kind of implementation was discussed for Ethereum back in 2020

Other ideas and solutions are provided into the very interesting thread above I would recommend you to read :blush:

The main issue with this FIFO implementation chosen by ETH team after closing this thread, and inherited to Harmony is that it’s not predictive, in the sense that a bot cannot have a grasp of whether it will be able to back-run a specific transaction, leading him to concurrently push hundreds of txs into the mempool, hoping that at least one of those transactions is going to be received and synchronized first prior to competitors.

Instead, using game theory mechanics should prevent those spam; you could try to forge a signature close enough yet treated as bigger to the transaction you try to backrun/frontrun:

// assuming both transaction cost the same gas, then are ordered by signature
sign(transactionYouWantToBackrun) = "0xce3b"
sign(transactionWithForgedSignature) = "0xce40" // close enough to be the first serve?

It won’t completely remove spam but should reduce it drastically.

There is mention in the thread of another solution that I love too and didn’t imagine: having a dependsOn field that describes which transaction must run before the current transaction. In which case we would sort transactions by gas price and this dependsOn value.
In this case, the one who bids the higher gas fee after a specific transaction wins the back run slot. Instead of spamming 500 transactions, a bot would instead charge 500x more gas fees to ensure his pristine first slot after a transaction.
This also has a positive effect on the network, by increasing the gas fees output without penalizing non-arbitration users.

// assuming both transaction cost the same gas, then are ordered by dependsOn field, which default to 0 (ignored)
sign(transactionYouWantToBackrun) = "0xce3b"
sign(transactionMadeToBackrun, dependsOn: "0xce3b", pricePerGas: "10000".Gwei) // I really want to backrun this previous transaction !

Anyway, I quote the authors of the thread above:

If I’ve summarized that correctly, I think FIFO makes more sense because it, or something very similar, was already implemented in Parity and we have a better idea of what to expect. I think both are short term fixes and in the long term these sorts of problems are solved with new transaction types, which again are completely of scope for this issue.

It is worth noting that Polygon and Avalanche implemented a 30Gwei/25Gwei minimum transaction cost for the same spamming reason. Which made them too expensive to serve billions, in my opinion.

3 Likes
8

And to reply to the two questions:

  1. Because it’s hard to predict whether there are other transactions currently synchronizing in the mempool. Between the moment you read mempool and add your transaction to it, you might face concurrent transactions synchronized before you. As far as I understand, you can’t atomically read and add a transaction into the mempool.
    Correct me if I’m wrong, I’m no expert on the subject at all, albeit I worked with highly distributed databases and know the compromises needed when dealing with concurrent race issues and atomic transactions.

So bots are doing multiple micro-transactions added simultaneously, to increase their chance to take profit and lower their chance of being front-run by another bot. In the end, at least some of those transactions are going to succeed, securing profit.

  1. Yeah, assuming the first sorting index remains the gasFee; transactions would be ordered by hash instead of an arbitrary made FIFO transaction index whenever the transaction gas cost is the same.
4 Likes
9

Arbitrations bots are so important to a network and it’s sad to see them getting a bad rap. On-Chain price discovery could disrupt the dominance of custodial exchanges.

I think we need to work with them to create a more efficient arbitrage environment and hope we can continue the conversation to strengthen Harmony.

2 Likes