Front running risks on Miden

[partylikeits1983]

During a discussion with pioneers, the concern regarding potential front running on Miden was raised. I wanted to open a discussion about the potential risk of front running on Miden.

Consider the following scenario involving a public "reward contract" on Miden:

The reward smart contract (account) has a single procedure send_all_assets that anyone can call. The send_all_assets procedure checks if the current timestamp is greater than t0 as specified in storage. If the timestamp is greater than t0, the procedure creates a P2ID note with the total amount of assets from the reward contract to the AccountId passed in to the procedure.

Reward Contract:

use.miden::account
# Input: [account_id_prefix, account_id_suffix]
# Output: []
export.send_all_assets
    # assert block.timestamp > t0
    # create P2ID note targeted to the AccountId passed in 
    # add all assets contained in the reward contract to created P2ID note
    exec.account::incr_nonce
end

At time t0 + 1, both Alice and Bob submit transactions to the Reward Contract calling the send_all_assets procedure:

• Alice creates a transaction script that calls the send_all_assets procedure.
• Bob creates a note at some time t0 - N that calls the send_all_assets procedure, but submits the transaction request for the Reward Contract to consume the note as a "network transaction" at t0—at the same time as Alice.

Given these two scenarios, and assuming both Alice and Bob have zero latency against the Miden node, who will receive the assets from the Reward Contract? I know network transactions are not possible yet; this is just an example.

This is a very simple scenario to help better understand the possibility of front running on Miden.

@Mirko-von-Leipzig, does the Miden node prioritize or deprioritize the inclusion order of certain transactions? Will this change with the fee mechanism? Is it possible to monitor the Miden mempool and potentially copy profitable public transactions and try to get them included in the block first? Most front running scenarios would likely be mitigated by using private transactions.

[bobbinth]

I'm not sure it would be possible to predict this with high degree of certainty because it would depend on a lot of other things that are happening at the same time - but to speculate a bit:

To generate her transaction, Alice would need to get the latest block hash from the node. This means, in a centralized setting, the node would have an advantage in how quickly it would learn of the new block. So, if the node starts building the network transaction as soon as the relevant block is built, and Bob should end up "winning" the race. This assumes quite a few things though. For example:

• It assumes that the node's transaction proving is nearly as efficient as what Alice can do. If Alice can prove transactions much faster, then she has a good chance of winning.
  • This is also influenced by how many network transactions the node has in its pipeline.
• It assumes that the node very actively monitors network notes directed toward this account, and starts building the transaction as soon as it can (vs., for example, a few blocks later).

The node could also employ a strategy of rejecting all transactions that may conflict with network transactions it is about to build, or even to reject transactions which try to update what it considers to be a "network account" (this is what we plan to do initially, I believe). In this case, Alice's transaction would not have a chance of getting through at all.

But overall, assuming such situations are allowed, it would be very difficult to predict whether a network transaction takes precedence over locally-proven transaction. Or at least, the situation may be similar if two users tried to submit conflicting transactions against the same account.

[Mirko-von-Leipzig]

@Mirko-von-Leipzig, does the Miden node prioritize or deprioritize the inclusion order of certain transactions? Will this change with the fee mechanism?

There is currently no prioritization, and note that in the decentralized future every node could do as it wishes so relying on that would likely be a poor idea long term. Once we are there we can only really rely on fees to guide behavior and anything we build into the base protocol.

At present the tx selection strategy is literally picking randomly from the valid tx set. We do want to improve this to consider transaction expiration, and maybe network txs once the feature lands. This would change again once fees land as then we would want at least something approaching a real strategy.

Is it possible to monitor the Miden mempool and potentially copy profitable public transactions and try to get them included in the block first? Most front running scenarios would likely be mitigated by using private transactions.

Currently only the node itself has access to the mempool, though we may want to open visibility a bit so that users can monitor their own transaction status. For public/network transactions this might mean full visibility for anyone..

[PhilippGackstatter]

Most front running scenarios would likely be mitigated by using private transactions.

At the transaction level, front running and MEV are only really a concern for network transactions, iiuc. So the main potential culprit can be the network transaction builder. If they see your note which swaps ETH for some XYZ token, they could include a note of their own buying XYZ first, letting your note get fewer XYZ tokens and drive up the price for XYZ. They might then sell those XYZ tokens with another note to complete the sandwich attack in the same transaction. In a centralized setting that may not be a concern, but once network transactions can be built by anyone (which I think is the goal?) then we may want to try to prevent some of that or think about out-of-protocol ways to avoid this.

I'm not very familiar with MEV prevention, but for a DeFi protocol like the above the protocol doesn't have to solve this problem I think. For example, instead of writing notes that say "buy XYZ tokens for 2 ETH" they could also say "buy XYZ tokens for 2 ETH and verify that I received at least 5 XYZ.", i.e. slippage protection which verifies that the executed note fulfilled the intent of the note creator. This should already be possible without needing any built-in support from the protocol.

Are there other scenarios raised by the pioneers with regards to frontrunning?