Blockchain mechanism design

Barnabé Monnot & Davide Crapis

Robust Incentives Group (RIG), Ethereum Foundation

IMS “Games, Learning, and Networks” Tutorial

Morning tutorial

Part 1

Consensus and execution layers + full node and state�Scaling execution with proofs, towards rollups�Pricing of network resources

Part 2

Blockspace Market & Maximal Extractable Value (MEV)�MEV flows in Ethereum Supply Network�Economic Mechanisms for MEV-Resilience

Afternoon talks

Back to basics

What is a blockchain?

Blockchain = data structure, chain of blocks

Blocks contain:

• Transactions (<=> Data)
• Link to previous block� = Hash of the previous block, guarantees data integrity

A

B

C

hash(A)

hash(B)

What is a public blockchain?

• Blocks + txs are gossiped to all full nodes over a peer-to-peer network
• Anyone can participate in consensus formation ⇔ building the chain
• Anyone can send transactions for inclusion in the chain

Consensus-forming nodes

Full nodes

Users

What is a public programmable blockchain?

• Transactions contain executable instructions
• e.g., send payment, deploy smart contract, interact with contract, …
• Full nodes maintain a state (= storage/memory)
• Instructions modify the state => state transition
• e.g., update account balance, create a new asset, …

Blockchain stack

Two-layer model: consensus and execution

​

​

​

​

Consensus layer

Proof-of-Stake in Ethereum

To become a validator, you lock up 32 ETH in the deposit contract

After activation, validator is called upon to perform consensus duties:

• Block proposals: Make a block containing consensus and execution data
• Attestations: Provide their view of the consensus, finalise blocks

Execution Engine

Users

Consensus client

Txs

Validators

Attestations

Blocks

Validator

Economic finality in Proof-of-Stake

Finality: A block is final when the chain which contains it cannot be reverted.� => Ultimate guarantee that the chain has “settled”

​

​

​

​

Accountable finality: Two conflicting blocks cannot both be finalised (>⅔ quorum)� UNLESS at least ⅓ of the stake produced conflicting votes!

In Proof-of-Work, no such mechanism, probabilistic finality only.

Validators are protocol agents

There is a thing called the Ethereum protocol� A specification of rules by which participants of the network communicate

Validators run the protocol, but do they run it honestly?� System of rewards and penalties ensures compliance, but is it enough?

Protocol rewards

Protocol specifies rewards and penalties

• Rewards
• Block reward for block proposal/correct voting
• Transaction fees from execution payload
• Penalties: Inactivity penalty + Slashing for attributable consensus fault

Hopefully matches!

Ethereum protocol

Network of validators

Blockchain

Rewards

Penalties

Scaling the chain

Full node lifecycle

Full nodes receive pending transactions and valid blocks.

Full nodes maintain a large object called “state”�Account balances, deployed smart contracts, saved variables in contracts…

Transactions perform state updates�Bob sends 10 ETH to Alice, need to update Alice’s balance and Bob’s

Key question

Given some state s, how do I know that s is valid? Validity conditions:

1. State s obtained by correctly executing a sequence of user transactions,
2. The sequence of user txs is agreed upon by consensus.

Invalidity example:�{ Alice: 50, Bob: 20 } || <Bob sends 10 to Alice> ⇏ { Alice: 60, Bob: 20 }

As a full node, I can always convince myself that state s is valid� by replaying all transactions since a finalised checkpoint,� even if the validator set tries to convince me otherwise!

I can start verifying by receiving a finalised checkpoint from any node I trust.

Big blocks, big nodes

We want full nodes on our network, who verify validity of the chain.� => Guarantees that even if the validator set is lying, someone can alert,� + network can coordinate around a fallback.�But if the chain is “too fast”, running a full node gets expensive!

“Solutions”:�- Require bigger, high-performance nodes => Centralisation�- Smaller blocks => Bad throughput

Better solutions:�- Statelessness => Still under research�- Move execution off-chain => Sidechains, Plasma, rollups…

Intuitive idea of off-chain execution

General flow:

1. User deposits assets on Domain 1,�in a bridge contract.
2. User makes transactions ⚙️ on Domain 2
3. User withdraws back to Domain 1,�bridge unlocks assets on Domain 1

Domain 1

Domain 2

1)

3)

2)

⚙️

⚙️

⚙️

Intuitive idea of off-chain execution

Key question:�How does Domain 1 know that Domain 2 is reporting the correct state?

Example:

1. Bob deposits 10 ETH in bridge
2. Bob sends 5 ETH to Alice on Domain 2
3. Bob tries to withdraw 10 ETH back to Domain 1

How does Domain 1 know that� Bob’s balance is 5 ETH and not 10?

Domain 1

Domain 2

1)

3)

2)

Intuitive idea of off-chain execution

How does Domain 1 know that� Bob’s balance is 5?�State s of Domain 2 must be correctly reported to Domain 1

• Rely on bridge: Bridge signs off on withdrawals based on their view of Domain 2
• Rely on Domain 2: Domain 2 exhibits a state which was finalised
• Rely on proofs of execution: Pessimistic or optimistic

Domain 1

Domain 2

1)

3)

2)

Rely on bridge

Bridge smart contract owner on Domains 1 and 2 signs off on any update.

Owner can be decentralised, e.g., multi-sig of nodes observing execution on Domain 2 signs off on Bob withdrawing 5 ETH, but doesn’t sign off invalid state transition.

Trust model: Trust bridge parties

Risk: Bridge hack signs off on arbitrary update, someone can get away with all of the asset in the bridge!

Domain 1

Domain 2

1)

3)

2)

✅

Rely on Domain 2

Domain 2’s validators finalise state s.�State s is fed along the bridge*

Trust model: Trust validator set of Domain 2.

Risk: Validators of Domain 2 can feed an invalid state of Domain 2!

Bridge is not a full node of Domain 2, can’t verify validity of the state…�Validator set can steal the assets locked�on Domain 1

Domain 1

Domain 2

1)

3)

2)

* State can also be recovered by running a light client of Domain 2 on Domain 1.

✅

Rely on proofs

We can convince ourselves of the (in)validity of a state s by receiving proofs

• Validity proofs: I can prove to you that s was obtained by a series of valid state transitions
• Fault proofs: I can challenge a state s and prove that it does not follow from valid state transitions

Is that it? Do we win?

Domain 1

Domain 2

1)

3)

2)

✅

✅

Towards rollups

Freeze funds

The operator of Domain 2 can still grief you, even if they give you a proof that s is valid.

You might not know s! Domain 2 can prove that their withdrawal is consistent with s, but you don’t know the entirety of s.

In this case, if the operator refuses to process your withdrawal, no one else can advance the state, they don’t know what it is!

We need two more guarantees:�Data availability and censorship resistance

Domain 1

Domain 2

1)

3)

2)

🙈

😈

Data availability

We need to ensure that the state can be advanced by anyone, so we must ensure that s is common knowledge.

We can do so by making sure that all transactions executed leading up to s were published once, by making 📜 available.

For optimistic proofs, this also ensures that anyone can challenge an invalid state s’.

Domain 1

Domain 2

1)

3)

2)

📜

Censorship resistance

We must also make sure that anyone can force a transaction to be executed on Domain 2.

Otherwise, the operator can prevent users from executing withdrawals from Domain 2.

Can be done in two (complementary) ways:

• Force include: Domain 1 is able to inject transactions in Domain 2’s record
• Decentralised operator: If an operator is offline, it is rotated out, another goes in

Domain 1

Domain 2

1)

3)

2)

📜

😈

😇

😇

Recap’

Transactions ⚙️ are executed on Domain 2, moving the state of Domain 2 to 📒.

⚙️ may be a withdrawal from Domain 2 to Domain 1!

Domain 1 wants to know, valid(⚙️, 📒) = ✅ ?

Data availability (DA): Domain 2 publishes 📜�Censorship resistance: Anyone can submit ⚙️

Now, who guarantees DA?

Domain 1

Domain 2

1)

3)

2)

📜

😈

😇

😇

✅

✅

Smart contract rollups

Domain 1 = Layer 1 (e.g., Ethereum)�Domain 2 = Layer 2, a rollup

Data 📜 executed on the rollup is published�on the Layer 1.� Unavailable data => Majority of L1 validators are malicious, 51% attack� => Security properties of L2 = L1!

Proofs ✅ are also published on the Layer 1,�to the bridge smart contracts.

Layer 1

Rollup

1)

3)

2)

📜

😈

😇

😇

✅

Smart contract rollups

Data 📜 executed on the rollup is published�on the Layer 1.

Proofs ✅ are also published on the Layer 1,�to the bridge smart contracts.

Layer 1 is both DA layer and settlement layer.

Layer 1

Rollup

1)

3)

2)

📜

😈

😇

😇

✅

Layer 1

Execution models

We’ve talked about how rollups work.�Let’s talk about what you can do with them.

Ethereum Layer 1’s execution layer uses�EVM, Ethereum Virtual Machine�General computability, can execute anything

Rollups may reuse EVM as execution engine,�if they can produce fraud or validity proofs of the EVM!

Reusing EVM => Deploy contract developed for L1 “as is” on L2

Validity proofs of EVM, or zkEVM

Validity proofs are mind-blowing tech.

You can give me a program to run with a set of inputs, and I can prove to you that I ran the program honestly, and give you the outputs.

I run prove(⚙️, 📒) = (✅, 📒’)�You run verify(⚙️, 📒, ✅, 📒’) = True / False

In particular, verify is much faster than prove!�=> Scaling!

Validity proofs of EVM, or zkEVM

Bad news, the EVM was not written with validity proof-friendly operations in mind…

Writing a circuit for prove is turning out to be really hard. This is known as zkEVM*

But people are hard at work on it.

You can also use a validity proof-friendly VM for your rollup instead.

* “zk” stands for “zero-knowledge”, which is not a property we care about here

Rollup economics

Users come to the rollup with transactions ⚙️�What should the rollup charge them?

Rollup expenses:

• Cost of publishing data 📜 to L1
• Cost of executors, who ⚙️ → 📒
• Cost of provers, who compute ✅

Rollups may also charge users a congestion fee.�It’s resource pricing all the way down!�

Layer 1

Rollup

1)

3)

2)

📜

😈

😇

😇

✅

Resource pricing

Validators as block producers

Protocol lets validators-as-block-producers consume resources� Protocol constrains supply to guarantee low verification costs

Validators produce blocks,� meeting demand for transactions with supply of resources

Ethereum protocol

Network of validators

Gas

Users

Txs

Blocks

Ethereum fee market: EIP-1559

We need to allocate space in the block, given block limits!�We’re looking for a DSIC mechanism for both users and block producers:

• Users need only declare their willingness to pay
• Block producers can’t bias the mechanism for free

This is (mostly!) obtained with EIP-1559 (Ethereum Improvement Proposal)

Three components:

1. Dynamic congestion pricing
2. Update rule based on block size control
3. Relative bidding language

In-protocol congestion pricing

Protocol mandates a minimum rate (“basefee”) to include a transaction

• When demand is high, basefee increases
• When demand is low, basefee decreases

Block producer does not receive basefee,�it is “burned” (removed from money supply)

*If you give it back to the BP,�BP can collude off-chain with the user and make basefee irrelevant

Block size control

How can we measure demand objectively?

Double the block size�… but target half-full blocks!

• If block producer fills up block above target, basefee increases
• If block producer fills up block below target, basefee decreases

Provides objective pricing� + BP cannot stuff block for free!

Relative bidding

​

​

User specifies:

1. Extra fee for the block producer� => priority fee
2. A maximum fee

When user is included, they pay�

Basefee + Priority fee

�Basefee is burned, priority fee goes to BP

Before 1559

After 1559

References will be added to the programme :)

blockchain network

B1

B2

B3

hash(B1)

hash(B2)

A p2p network of computers that are building an immutable blockchain ledger with singleton state

blockchain resource pricing

Slot operations (every 12s)

1. Gossip block to peers
2. Execute transactions
3. Update state tree

bandwidth

compute

memory

state access

tx tree

state tree

Data availability (weeks - ∞)

• Blockchain history
• Accounts state

blockchain resource pricing

Transactions demand resources in different proportions

​

Design process

• Decide hardware requirements
• Define resources
• Decide block limit
• Add sustainable target (< limit) if necessary
• Decide update rule (possibly add artificial targets)
• Set update rule params

blockchain resource pricing

Transactions demand resources in different proportions

​

Design process

• Decide hardware requirements
• Define resources
• Decide block limit
• Add sustainable target (< limit) if necessary
• Decide update rule (possibly add artificial targets)
• Set update rule params

blockchain resource pricing

blockchain resource demand

Demand for resources is bundled in transactions

​

• Generic transactions
• Variable amount of OP-RESOURCES
• Generally in similar proportions based on transaction type
• Token transfer
• Swap
• Mint

​

• Blob transactions
• Fixed amount of OP-RESOURCES (precompile ops)
• Variable amount of BLOB-DATA (specific execution & expiry policy)

​

Blockspace Market

a.k.a. “the metagame”

Blockspace market basics

transactions & blocks

mempool

tx1, $$

tx2, $$

tx3, $

tx4, $$$

block

building

Price-based ordering

​

• user submits tx & tx fee ($)

​

• tx ordered w/ decreasing $

Extractable Value Example 1 - Inclusion fee

​

​

​

The fee ($) has two components

​

1. base fee → burned! (read: allocated ETH Holders)

​

• priority fee → collected by block proposer

Extractable Value Example 2 - Reordering

mempool

tx1, $$

tx2, $$

tx3, $

tx4, $$$

block

building

tx4 is a buy order:

X USDC → Y ETH

at current rate

Extractable Value Example 2 - Reordering

mempool

tx1, $$

tx2, $$

tx3, $

tx4, $$$

block

building

tx4 is a buy order:

X USDC → Y ETH

at current rate

​

Extraction strategy (sandwich)

• tx5: send large ETH buy order

→ ETH/USDC rate goes up

• tx4: user gets Y’<Y ETH

→ ETH/USDC rate goes up

• tx6: send large ETH sell order

(close ETH position w/ profit)

Extractable Value Example 2 - Reordering

1

2

3

jaredfromsubway.eth

Extractable Value - Common Strategies

price-based transaction ordering

Price-based ordering

​

Pros:

• Large set of possible orderings
• Can be welfare optimal in theory

​

Cons:

• Sophisticated players can extract value

mempool

tx1, $$

tx2, $$

tx3, $

tx4, $$$

time-based transaction ordering

FIFO ordering alternative

​

• user submits tx & timestamp (t)

​

• tx ordered w/ increasing t

mempool

tx1, t1

tx2, t4

tx3, t2

tx4, t3

time-based transaction ordering

FIFO ordering alternative

​

Pros:

• Smaller set of orderings reduces value extraction
• DeFi markets more efficient?

​

Cons:

• No inclusion preference expression (lower welfare?)
• Faster players can still extract value from users

mempool

tx1, t1

tx2, t4

tx3, t2

tx4, t3

Block supply network

block supply network

wallet

wallet

wallet

wallet

users

block supply network

exclusive orders

wallet

transaction

mempool

wallet

wallet

wallet

users

block supply network

exclusive orders

wallet

bundle + fee

transaction

mempool

wallet

wallet

wallet

searcher builder

searcher

builder

searcher

builder

users

block supply network

exclusive orders

wallet

bundle + fee

transaction

block + bid

mempool

wallet

wallet

wallet

searcher builder

searcher

builder

searcher

builder

users

proposer

relay

relay

block supply network

exclusive orders

wallet

bundle + fee

transaction

block + bid

mempool

wallet

wallet

wallet

searcher builder

searcher

builder

searcher

builder

users

proposer

relay

relay

block supply network

exclusive orders

wallet

bundle + fee

transaction

block + bid

mempool

wallet

wallet

wallet

searcher builder

searcher

builder

searcher

builder

users

proposer

relay

relay

block supply network

block supply network

Economic Mechanisms

for

MEV Resiliency

MEV Resiliency

​

Ethereum needs to adapt to minimize MEV induced problems

​

1. [Security] MEV-robust incentives for validators

​

• [Equity] Honest users suffer minimal losses

​

• [Cost-efficiency] Unethical users extract minimal rents

​

​

MEV Resiliency

​

Ethereum needs to adapt to minimize MEV induced problems

​

• [Security] MEV-robust incentives for validators

​

• [Equity] Honest users suffer minimal losses

​

• [Cost-efficiency] Unethical users extract minimal rents

​

How? A trust minimized infrastructure of economic mechanisms to

reduce MEV → extract → capture → allocate

Transaction stage

Transaction auction (aka, OFA)

​

• user sends transaction to TTP

​

• N searchers extract value v(i) ~ F
• searchers bid in 1st price auction
• b(i) = v(i) - r(i)

​

• winning searcher can extract value*
• winning bid split between
• user ← 0.9*max{b(i)}
• proposer ← 0.1*max{b(i)}

tx auction

user / wallet

searcher

Bundle stage

Bundle “auction”

​

• searcher constructs bundle adding at least one tx; sends to builder for block inclusion together with a fee
• b(i) = v(i) - r(i)

​

• builder builds maximum value block
• V = maximize sum{fees}

subject to block_gas_limit

validity_constraints

​

• searcher profits if included & block wins

builder

searcher

bundle auction

Block stage

Block auction

​

• proposer procures block from builders via 1st price auction

​

• N builders send most profitable block w/ proposer payment to TTP

​

p(i) = V(i) - eps(i)

​

• proposer gets almost all the value; builder keeps a (small) profit

builder

proposer

block auction

Thank You!

​

Q&A