Hari Kailad

MEV, Cryptocurrency, and Verifiable Delay Functions


Time based cryptography such as VDFs and Time Lock Puzzles seem to have interesting applications. One major issue in cryptocurrency is MEV and frontrunning, where people lose money to bots scanning transactions to frontrun. Time based cryptographic primitives could theoretically offer some solutions.

MEV

One of the biggest issues with Ethereum is MEV, or maximal extractable value. When a user submits a transaction to the network, it is placed in the mempool. However, these MEV bots watch the transactions in the mempool and use these transactions to their advantage. This has led the mempool to be known as the dark forest due to these bots exploiting user transactions.

For example, say a user decides to buy a token through some Uniswap pool. A bot, seeing that transaction, can then create a bundle of transactions:

  • Bot buys the token, increasing the price of said token.
  • User buys the token, increasing the price of said token.
  • Bot then sells the token they bought initially, at a higher price.

This "sandwich" or bundle of transactions can then be sent to a miner directly, with some extra tip towards the miner. This allows these bots to frontrun user transactions and extract some value.

To prevent these attacks, we must hide the transaction somehow. However, just encrypting the transaction will not cut it, as users may submit invalid transactions and perform a DoS attack. Along with this, transactions cannot be verified if the user chooses not to decrypt it.

However, this can be solved through Verifiable Delay Functions.

Verifiable Delay Functions

Definition (VDF). A Verifiable Delay Function consists of 3 functions :

  • $\text{Setup}(\lambda, t) \to (ek, vk)$: A setup algorithm taking in a security parameter and desired time $t$ and returning an evaluation key $ek$ and a verification key $vk$.
  • $\text{Eval}(ek, x) \to (y, \pi)$: An evaluation algorithm that takes in an $x$ and returns a $y$, along with a proof $\pi$. This algorithm must run in parallel time $t$.
  • $\text{Verify}(vk, x, y, \pi) \to T/F$: A verification algorithm that takes in the input, output, and proof and outputs true or false, which runs in polynomial time.

Note here that the evaluation is quite slow, as it takes time $t$ even with parallelism. The verification function verifies if the evaluation was computer correctly.

A verifiable delay function allows you to provably show you took $t$ time to execute this evaluation. The $t$ here is not exact time but steps taken. Namely, the evaluation must be some kind of sequential function that cannot be parallelized, and executed for $t$ steps.

One simple VDF can be constructed by iterating a hash function such as $\text{SHA256}$. However, to verify one must repeat this computation, which takes a decent bit of time.

One other well known verifiable delay function is the computation of modular square roots. Computing $y = x^{(p - 1) / 4} \pmod{p}$ is slow, while verifying $y^2 = x \pmod{p}$ is fast. Sequentially repeating this process produces a VDF.

There have been a number of improvements to this VDF over the years, which include using SNARKs or permutation polynomials for sequential evaluation: see [BBBF18] for more details on constructions of VDFs.

Applications

MEV

VDFs see applications in a number of cryptocurrency and consensus related protocols. One application these VDFs can be used for is to prevent MEV to an extent.

Instead of a user publishing a transaction to the mempool, the user just commits to the transaction via the delay function.

Therefore, a miner looking at the transaction can only see the transaction after the set time $t$ has passed. If the time $t$ is less than the time it takes for a transaction to be added to the chain, then miners can still do frontrunning by decrypting the transaction still in the mempool. If the time $t$ is too large, then confirming the transaction will be delayed as the user must wait longer to open the transaction and for others to see the transaction has gone through.

One main problem with this approach is that computation scales up as more users participate in the chain to compute and verify these VDF proofs. One could also prove that encrypted transactions are not malformed and valid, as otherwise there could be issues with broken transactions.

Secure Lotteries

Another main application is to create a secure verifiable lottery on-chain.

To perform a lottery, one must have randomness on the blockchain. To do this verifiably, typically a user will query a randomness beacon, which publishes random values no user can predict or change.

To construct such a beacon on the chain, beacon values could be derived from the block hash of the next block, which is relatively inexpensive to compute. However, this means that miners can manipulate block hashes by placing specific transactions into the block, or not posting blocks with unfavorable randomness.

When appending a block to the blockchain, once a miner has computer a block, they have a small window of time to publish that block before a different block is added by another miner.

However, say we derive the randomness from a VDF instead of a block hash. Given a time delay $t$, we can first post $(ek, vk)$ to the chain. Then for a block $b$, the beacon value is $r, \pi = \text{Eval}(ek, b)$. Finally, anyone can verify the randomness is correct by checking $\text{Verify}(vk, b, r, \pi)$.

If the time delay is long enough, this construction should prevent miners from attacking the randomness beacon. Therefore, with the randomness, people can now perform a lottery, along with verify the results are correct.

Conclusion

Time based cryptography is an interesting primitive that has some cryptocurrency based applications. Many current issues with cryptocurrencies stem from time. MEV, arbitrage, and frontrunning all rely on time or the order of transactions, and such could require time based solutions. There are many other interesting time based primitives, such as time lock puzzles and delay encryption, which hopefully get explored further.

References

[BBBF18] Verifiable Delay Functions - Dan Boneh, Joseph Bonneau, Benedikt Bünz, Ben Fisch