Secure Delayed Transactions
Learn about front-running prevention and MEV extraction resistance on the ETF network
Introduction
Front-running in blockchains is difficult to detect, hard to prevent, and leads to negative consequences for the network. When successful, these types of attacks lead to financial gain for an adversary and potential loss for the victim. In the context of web3 gaming, front-running is synonymous with cheating. Often associated with front running is the idea of maximal extracted value, which uses front-running techniques to manipulate the order of transactions. Put simply, MEV is the maximum value that can be earned from a block. It is estimated that in 2023 MEV bots extracted over one billion USD from crypto markets. These type of attacks can be incredibly lucrative, but they have the potential to significantly harm a product. Front running has the potential to…
compromise blockchain transparency and fairness
introduce unpredictable market fluctuations,
is an attractive tools for deceitful activities
With secure delayed transactions on the ETF network, we aim to eliminate the ability to front-run, leading to a more fair and stable network. It leverages timelock encryption to ensure call data is encrypted until executed and offers a non-interactive mechanism to securely submit and delay transactions for future blocks. Along with front-running, delayed transactions have the potential to disrupt MEV capabilites as well. Continue reading to learn how to use delayed transaction on the ETF network. For more information on the ETF network, check out the docs at https://etf.idealabs.network.
Let’s start with some terminology
In blockchains, users interact with the blockchain by submitting (signed) transactions to the transaction pool. Each transaction contains call data, which corresponds to some action that the users wants to take. If you think of a blockchain as a finite state machine (whose state is agreed on by consensus), then the call data of a transaction is one of the valid state transition functions. The transaction pool contains a set of pending transactions that users have submitted for execution. Transaction priority refers to the priority of a transaction in the pool. Validators are network authorities who are responsible for authoring blocks in the blockchain. They are incentivized to include higher priority transactions over lower priority ones.
So what is front running?
There’s nothing more annoying than a line jumper. Imagine you are waiting in a long line to buy a ticket for a popular movie. You have been waiting patiently for a long time, and you are almost at the front of the line. Suddenly, someone cuts in front of you and buys the last ticket, leaving you empty-handed. That person is a line jumper, and they have just front-run your transaction.
Front-running is a type of attack where an adversary monitors the transaction pool of a blockchain and uses this knowledge to submit higher-priority transaction that is likely to be executed before the original one.
The diagram below shows a simplified model of front running. It is as follows:
A front-runner Frank is actively monitoring the transaction pool for specific types of transactions, for example, suppose there is a smart contract based trivia game and Frank is looking for the correct answer.
Alice submits a transaction containing the correct answer.
Frank sees the transaction before the validator does and builds a duplicate transaction. The transaction is submitted to the transaction pool with a higher fee (e.g. gas fee in Ethereum, or a large tip in substrate-based chains)
The validator executes Frank’s higher priority transaction before Alice’s.
Frank wins the round of trivia .
What is MEV extraction?
MEV, Maximal extractable value, works by reordering pending transactions to maximize the profit that a validator might receive. For a more in-depth look at how MEV extraction works and the consequences associated with it I refer you to:
https://www.tastycrypto.com/defi/mev-bots/
https://hacken.io/discover/front-running/
To summarize, we borrow from the first link above:
Secure Delayed Transactions
Secure delayed transaction work by:
Using the ETF network’s timelock encryption capabilities to encrypt call data offchain
Using a scheduler pallet to decrypt and execute valid transactions
If we consider the example from before, where Frank coordinated a front-running attack against Alice, we can see that this is no longer an efficient attack that Frank can execute when Alice uses secure delayed transactions. Observe that:
Since the call data is encrypted with timelock encryption, it can ONLY be decrypted at the specific block, and since Alice scheduled it for that block it cannot be executed at a different block. That is, either Alice’s transaction is executed at her specified block, or else it is discarded.
An adversary Frank who wants to front-run can derive no useful information about the future call data before it is included in a block. This prevents Frank from being able to front run at all.
Since validators must decrypt call data before execution, they cannot pick-and-choose transactions to maximize value. At worse, a validator could decrypt each ciphertext and then reorder transactions to maximize extractable value, however, this would ultimately be a costly and inefficient operation for the validator.
Examples
For an example of a delayed balance transfer, check out the react-delayed-txs demo on GitHub.
Our demo game TerraBit (try it, it’s free!) uses delayed transactions to allow players to ‘transmute’ their worlds via an asynchronous, non-interactive, trustless asset swap.
https://terrabit.idealabs.network/
https://github.com/ideal-lab5/terrabit
Usage
Delayed transactions can be constructed, signed, and submitted to the chain using the etf.js library, https://github.com/ideal-lab5/etf.js.
To get started, add the dependency to your (JavaScript) project:
npm i @ideallabs/etf.jsThen import the library and initialize the ETF class
import { Etf } from '@ideallabs/etf.js'
// e.g. within a useEffect() hook
let ws = 'wss://etf1.idealabs.network:443';
let etf = new Etf(ws)
await etf.init()The ETF.Delay API lets any runtime call be delayed for future blocks. It internally performs encryption of the call data for the specified block and returns a valid call to schedule the encrypted call.
// the call to delay
let innerCall = etf.api.tx.balances
.transferKeepAlive('5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty', 100);
// calculate a deadline (slot)
let latest = etf.getLatestSlot();
// 20 blocks from now
let deadline = latest + 20;
// prepare delayed call
let outerCall = etf.delay(innerCall, 127, deadline);
await outerCall.signAndSend(alice, result => {
if (result.status.isInBlock) {
console.log('in block')
}
});Conclusion
Now we’ve seen how secure delayed transactions is a powerful tool that can provide front-running resistance and MEV extraction protection and how to use it in front-end applications to construct and submit these types of transactions. This provides tremendous value, as these types of attacks have adverse effects on a network.
Explore our documentation and github to get started with delayed transactions on the ETF testnet!
The ETF network documentation: https://etf.idealabs.network
Check out the latest work on github: https://github.com/ideal-lab5
Beyond these benefits, delayed transactions can also serve as a basis for building asynchronous, non-interactive, atomic on-chain exchanges, where they can use delayed transactions in place of a commit-reveal scheme, reducing the number of transactions needed while also making the process more secure, as participants do not need to hold onto any extra data.
While this capability is currently only available for ink! smart contracts running on the ETF network, we are working on ways to make our features available in a cross-chain way, enabling delayed transaction capabilities in other blockchains. Stay tuned!
Join us on discord!
https://idealabs.network
hello@idealabs.network