Discussion of The Evolution of Blockchain: from Lit to Dark

Paper by Agostino Capponi, Ruizhe Jia, Ye Wang
Discussion by Andreas Park


 

CUHK February 2022
 

By now everyone knows what Bitcoin is ...

What is Decentralized Finance?

decentralized finance =
provision of financial services without the necessary involvement of a traditional financial intermediary at extremely low costs

key ingredient =
blockchain technology =

a common infrastructure for decentralized code execution

  • for UniSwap: fees = transfers between LP and LD, $0 outsiders

How should one organize DEX trading?

How do you set the price?

Problem: MEMPOOL Frontrunning is intrinsically profitable

\(X-2x\)

\(Y+y'+y''\)

normal trade: buy \(x\) \(\to\) pay \(y'\)

\(Y+y'\)

\(X-x\)

front-running:

  1. front-runner: buys \(x\) \(\to\) pays \(y'\)
  2. front-run: buys \(x\) \(\to\) pays \(y''\)
  3. front-runner: sells \(x\) \(\to\) gets \(y''\) 

\(Y\)

\(X\)

\(y''>y'~\Rightarrow\)

front-running is intrinsically profitable

Problem: MEMPOOL Frontrunning is intrinsically profitable

\(X-2x\)

\(Y+y'+y''\)

\(Y+y'\)

\(X-x\)

\(Y\)

\(X\)

\(y'=y''~\Rightarrow\)

front-running is not intrinsically profitable

Mempool \(\Rightarrow\) Front-Running!

a

b

c

d

e

f

g

Dark side of DEx trading: Miner extractable value

Can value extraction be prevented?

  • conceptual defence:
    • use a better pricing function (may create other issues)
  • economic defence
    • pay higher mining fee (not useful when the miner extracts value)
    • specify limited price impact (may lead to unnecessary non-execution in fast markets and partial MEV still possible)
    • Gans and Holden (2022): use mechanism design (doesn't apply to "sandwich trades")
  • technological defence
    • 1Inch protocol (time delay of same-direction trades)
    • "trusted" mining \(\to\) this paper

Theoretical Framework: timeline

validators

users

arbitrageurs

validators

decide whether to monitor/adopt hidden processing

front-runnable decides whether to use hidden or public

may find front-runnable and then decide whether to use hidden or public

process according to fees
 

arbitrageurs

observe mempool again for trades by other arbitrageur
 

?

Theoretical Framework: users

users

hidden settlement

delay risk

hidden settlement

delay risk

open mem-pool

nada

open mem-pool

front-running risk

front-runnable

#:1

can't be front-run

#:B+1

Theoretical Framework: validators

validators

adopt private protocol

only use lit pool

Text

process hidden settlement

process lit settlement
(includes MEV)

process lit settlement
(includes MEV)

Theoretical Framework: arbitrageurs

arbitrageur

(always scans public mempool)

find first-order arb

find no arb

Text

hidden settlement

delay risk &

competing arb

open mem-pool

delay, competing arb & front-running risk

scan open mem-pool

perform front-running

Subgame perfect Equilibrium behavior: arbitrageurs

Text

0

1

fractions of validators that usage hidden

both arb use public & hidden

both arb use hidden only

one arb uses only hidden, the other both

Where do they post?

What fees do they bid?

hidden: both bid \(c\)
\(\Rightarrow\) validator gets all rents

public: both bid lowest amount to be included
(then English auction)

only hidden: bids \(c\) if observes public bid and lowest marginal otherwise

both: bids \(c\) in hidden and lowest in public

mixed strategy bid over interval from lowest to below \(c\)

Question: what does "observing bid" mean?
(Observing MEV opportunity?)

Subgame Perfect Equilibrium Behavior: users

0

1

fractions of validators that usage hidden

both arb use public & hidden

both arb use hidden only

one arb uses only hidden, the other both

Where do arbs post?

Where do front-runnable post?

Question: how much does the front-runnable bid?

public

hidden

public

hidden

public

hidden

Subgame Perfect Equilibrium Behavior: validators

0

1

fractions of validators that usage hidden

both arb use public & hidden

both arb use hidden only

one arb uses only hidden, the other both

Where do arbs post?

Where do front-runnable post?

public

hidden

public

hidden

public

hidden

Fraction of validators adopting hidden

Disclaimer: I am going with the description of Proposition 5

?

Case 1: MEV very high

Case 2: MEV not too high

Comment:

  • My intuition:  \(c\) increasing in \(v_{\text{front-runnable}}\)
     
  • Why? value to front-runnable means willing to trade large quantity
     
  • \(\to\) MEV usually increases in traded quantity

Observations

  • Assumption for valuations:
    • \(v_1>v_2>\ldots>v_{B+1}\) 
    • \(v_{\text{front-runnable}} >v_{B-2}\)
    • \( c>v_{B-2}\) 
  • \(B\) slots
    • \(\Rightarrow\) \(B+1\) non-front-runnable have to compete  
    • \(\Rightarrow\) validation fee cannot be zero
    • \(B+2\) transactions without front-running
    • \(B+4\) transactions with front-running (or is is \(B+3\)?)
  • \(v_{\text{front-runnable}} >v_{B-2}\) \(\Rightarrow\) front-runnable guy gets enough to wanting to be in the block
  • \( c>v_{B-2}\): arbitrageur gets enough value to be included in the block

Observations

  • Is it socially optimal to include a front-run user?

"Proposition 7 (Welfare of miners, user, and arbitrageur). The introduction of the dark venue leads to a strict increase in welfare for miners who adopt the dark venue, and a decrease in welfare for miners who do not adopt the dark venue"

My intuition: continuum of miners/mixed strategy \(\Rightarrow\) indifference condition must hold

Further Theory Observations

Welfare: maybe define it formally?

In microstructure:

  • lit = pre-trade transparency
  • dark = no pre-trade transparency
  • there is always post-trade transparency
  • never settlement uncertainty

@financeUTM

andreas.park@rotman.utoronto.ca

slides.com/ap248

sites.google.com/site/parkandreas/

youtube.com/user/andreaspark2812/

CUHK Discussion of Agostino's paper

By Andreas Park

CUHK Discussion of Agostino's paper

  • 479