flowchart TD
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

subgraph users ["Users"]
direction TB
A("Alice")
B("Bob")
N33("Node 3")
end

subgraph state ["Ethereum state (abstractly)"]
ac1("... ...")
ac2("... ...")
s2{{"... ..."}}
s3{{... ...}}
sc{{"Smart contract with locked ETH. \n (7) locked ETH is slashed if \n nodes build conflicting forks \n\n"}}
end


subgraph nodes ["Validators (stakers)"]
	direction TB
	N1("Node 1")
	N2("Node 2")
	N3("Node 3 \n (2) is added to the validator set\n (4) chosen randomly, according \nto how much ETH Node 3 has staked\n\n")
end
subgraph blocks ["Ethereum blockchain"]
	direction RL
	B0("... ...")
	B1("Block N")
	B2("Block N+1")
	B3("Block N+2")
	B4("Block N+3"):::green
	B4 --> B3-->B2 --> B1 -->  B0
end

state:::blue
users:::white
blocks:::blue
nodes:::orange
N1  
N2  
N33  o-----o|"(1) ETH is locked \n(via tx*)\n\n"| sc

blocks -->|"(6) state updated according to new txs in Block N+3 "| state
A -->|"(3) txs"| nodes
B -->|"(3) txs"| nodes
N33 -->|"(0) tx* (to stake ETH)"| nodes
N3 -->|"(5) - build a valid Block N+3; \n - add it to the longest chain + broaddcast it; \n- receive block reward + tip + MEV fees; \n- burn the base fee. \n\n"| blocks

flowchart LR
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

subgraph O["Decentralized oracle"]
OP1("Oracle \n provider 1\n\n")
OP2("Oracle \n provider 2\n\n")
OP3("Oracle \n provider 3\n\n")
end
TradFi:::white -->|ETH price| O:::red -->|ETH price| A{{Aave}}:::blue

flowchart LR
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

TradFi:::white -->|ETH price| O(Oracle):::red -->|ETH price| A{{Aave}}:::blue

flowchart TD
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

A("<b>Alice</b>\n[seeks leverage]\n (0) assets: 10 ETH \n(9) assets: 18 ETH + debt: 12000 USDC\n\n")
aave{{"AAVE money market = lending platform \n - loan-to-value (LTV) ratio = 82.5% \n - ETH price = 15000 USDC% \n (3) balance: 10 ETH, 15000 USDC \n(4) Alice asked for 12000 USDC loan \n\n"}}:::blue
B("<b>Bob</b>\n[seeks yield on USDC]\n\n")
A -->|"(1) 10 ETH"| aave
B -->|"(2) 15000 USDC"| aave
aave -->|"(5)  since 12000 < 82.5%*15000,\nloan 12000 USDC, \nfor 2% APR!\n\n"| A
aave -->|"(6) pay 1% (half) of Alice's APR,\n giving Bob yield on his USDC\n\n"| B
aave -->|"(7) earn 1% (half) of Alice's APR\n\n"| aave
A-->|"(8) swap 12000 USDC for 8 ETH"|u{{"Uniswap"}}:::blue

flowchart LR
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

A(Alice) -->|tx| RO
B(Bob) -->|tx| RO
RO[["Rollup operator\n- proccesses all txs\n - produces short proof π\n\n"]]:::orange
RO -->|"txs summary \n proof π\n\n"| N("Ethereum nodes \n(miners/validtors) \n- verify the proof\n\n") -->|txs summary \n proof π\n\n|RSC{{Rollup smart contract}}:::orange
subgraph es[Ethereum state]
RSC
end
es:::blue

flowchart TD
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

A("<b>Alice</b>\n[trader]\n\n") -->|"(3) 100 USDC \ntrade starts\n\n"| liq_pool{{"<b>ETH-USDC liquidity pool, 1% fee</b>\n[smart contract] \n(0) balance: 0 \n (2) upd balance: 1500 USDC, 1 ETH \n (6) upd balance: 1599 USDC, 0.938 ETH \n• key point: 1500 x 1 = 1599 x 0.938 \n\n\n"}}
B("<b>Bob</b>\n[liquidity provider =\n= market maker]\n\n"):::orange -->|"(1) 1500 USDC + 1 ETH \n deposit\n\n"| liq_pool:::blue
liq_pool -->|"(4) 1 USDC \n as a fee\n\n"| B
liq_pool -->|"(5) 0.062 ETH \n trade finished \n\n"| A

flowchart LR
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px
classDef white fill:#ffffff,stroke:#000,stroke-width:2px
classDef orange fill:#FDDCBE,stroke:#000,stroke-width:2px

A("Alice")
B("Bob")
C("Carol")

A --> nodes
A --> RC[["Rollup Operator"]]:::orange
B --> nodes
C -->|txs \n usual fees \n MEV fees\n\n| nodes

nodes ==>|update| state

subgraph nodes ["Ethereum network"]
N1("Node 1")
N2("Node 2")
N3("Node 3")
end



subgraph state ["Ethereum State = dapps \n\n\n"]
RP("Rollup contract"):::orange
NFT("NFTs")
DAO("DAOs")
subgraph defi ["DeFi"]
DEX("DEXs")
MM("Lending protocols")
Stablecoins("Stablecoins")
end
defi:::red
end

RC -->|"txs summary \n zk proof \n (via eth nodes) \n\n"| RP
Oracles --> MM
Oracles --> Stablecoins
TradFi:::white --> Oracles

nodes:::green
state:::blue

flowchart LR

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:center
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px

S1(State 1) -->|"tx1"| S2(State 2) -->|"tx2"| S3(State 3) 

flowchart LR

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px

A(Alice) -->|2 ETH| R{{<u>Smart contract</u> <br> Code: if X ETH received, <br> send X/2 ETH to Bob and \n send X/2 ETH to Carol \n \n}} -->|1 ETH| C(Carol) & B(Bob)

flowchart LR

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px

EOA("<u>Regular account</u> (controlled by private key) \n(or Externally Owned Account = EOA)\n - Public address \n  - Private key \n - Balance  \n - Nonce (number of txs)\n\n\n") 
CA{{"<u>Contract account</u> (controlled by code) \n(or CA = internal account = smart contract = DAPP)\n - Public address \n - Code + storage \n - Balance \n  - Nonce (# of contracts created by the creator)\n\n\n"}}

flowchart TD
classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
A(Alice) -->|"(1) swap 1500 USDC to ETH"| SC1{{"Smart Contract 1: \n Exchange aggregator \n \n"}} 
subgraph  
SC2{{"Smart Contract 2: \n Exchange X \n \n"}} 
SC3{{"Smart Contract 3: \n Exchange Y \n \n"}} 
SC4{{"Smart Contract 4: \n Exchange Z \n \n"}} 
end
SC1 <-->|"(2a) swap 500 USDC \n to 0.5 ETH \n\n"| SC2
SC1 <-->|"(2b) swap 300 USDC \n to 0.32 ETH\n\n"| SC3
SC1 <-->|"(2c) swap 600 USDC \nto 0.6 ETH\n\n"| SC4
SC1 -->|"(3) send 1.42 ETH"| A

flowchart LR

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px

A(Alice) --->|"Transaction"| SC1{{"Smart contract"}} --->|"Internal transaction"| SC2{{"Smart contract 2"}}

flowchart TD

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:center
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px


n1(Alice):::blue --->|"gasLimit·gasPrice GWEI\n is locked to txEscrow\n\n"| n2(Tx initiation \n <b>remainingGas = gasLimit\n\n) --> n3(<b>remainingGas</b> = 0 or insufficient?)
n3 -->|yes| n4("Tx failed! \n But still included in the blockchain\n and gasLimit·gasPrice GWEI paid as fee\n\n"):::red
n3 -->|no| n5("Execute next operation \n <b>remainingGas = remainingGas - opCost \n\n") --> n6("Are there more operations?")
n6-->|yes| n3
n6-->|no| n7("Tx successful! State changes, and\n remainingGas·gasPrice GWEI is refunded to user\n\n"):::green
 

flowchart TD

classDef default fill:#F8ECFB, stroke:#000, stroke-width:2px, text-align:center
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef red fill:#FFA69D,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px

S1("Self-custody?") --->|no| N1((TradFi)):::red  
S1 -->|yes|S2(Transaction censoring possible?)-->|no|S3(Protocol execution censoring?)--->|no|N2((DeFi)):::green
S2 --->|yes|N3((TradFi intermediary, \n DeFi settlement\n\n)):::blue
S3 -->|yes|N4((DeFi with \nadmin keys\n\n)):::blue

flowchart LR

classDef default fill:#FAF2FF, stroke:#000, stroke-width:2px, text-align:left
classDef green fill:#C5F1AB,stroke:#000,stroke-width:2px
classDef blue fill:#DAF4FF,stroke:#000,stroke-width:2px

A(Alice) -->|send tx| R[[Rollup Coordinator</u> <br> - processes all txs <br> - produces short proof π    \n\n ]]:::blue
B(Bob) -->|send tx| R
C(Carol) -->|send tx| R
R:::red --->|txs summary + π| N1(Node 1 <br> - verifies π \n - records tx summary+π\n into rollup smart contract \n\n) & N2(Node 2 <br> - verifies π \n- records tx summary+π\n into rollup smart contract \n\n) & N3(Node 3 <br> - verifies π \n - records tx summary+π\n into rollup smart contract \n\n)

Blockchain, not Bitcoin

🔶

The key question: how to best implement the state transition model?

🔷

Stellar answer: use smart contracts = digital vending machines. Regular users can: (1) send txs to each other (as before); (2) deploy smart contracts (onto nodes’ hard drive) that are governed by code; (3) interact with smart contracts.

This idea was pioneered by Nick Szabo [1, 2], and implemented in Ethereum by Vitalik Buterin.

Quick intro to Ethereum

Transactions

• EOA to EOA (ETH transfer)
• EOA to 0 (contract deployment)
• EOA to CA (ETH transfer, contract execution = calling functions)

• ETH sent — changes balance of ETH
• Data — directs the contract deployment / execution

Gas

• Halting problem: In 1936, Alan Turing has shown that a (turing) machine cannot tell if a script will halt or run forever, before execution.

⇒ Infinite loops or resource intensive scripts are a potential attack vector

• Bitcoin and Ethereum deal with this problem in different ways:
• Bitcoin Script is a deliberately limited scripting language.
• Ethereum has a Turing complete instruction set. It charges a fee for each minimal computation step (gas).
• All EVM operation sconsumes a pre-defined amount of gas. (Addition → 3 gas units, Multiplication → 5 gas units, Store 256 bits → 20k gas units)
• Every transaction has a user-specified gas limit, i.e. the maximum number of gas units that can be triggered by this transaction.

Simple “send ETH” txs require 21000 gas units. More complicated contract executions vary.

• Every transaction has a certain gas price = “price of gwei-per-gas” that the sender is willing to pay.

Rmk: 10^9 gwei = eth; gwei = 10^9 wei.

• Execution of tx based on gasLimit and gasPrice is shown below. The upshot is that miners get paid for every operation they perform (even if the tx is invalid!)

Fees

• Protect Ethereum from DoS attacks and infinite loops in the code
• Give a great mechanism to determine which tx to prioritize
• [mechanics before eip1559] first-price auction, everything goes to miners
• [mechanics after eip1559] base fee (in gwei-per-gas) is dynamically quoted to you by Ethereum network = the gas price under which ethereum will include your tx. This fee is burnt. Miners/validators receive a small tip + MEV (see later)
‣
More details:
• priority fee (= tip) is set by the user to give the miner an incentive to include the transaction in the block. Miner receives the priority fees of all included transactions. It is usually equal to ~2 gwei.
• when blocks are full (30mil gas), the system reverts to first-price auction via priority fee & increases base fee exponentially. When blocks are empty (<15mil gas), the base fee decreases.
• max fee is set by the user and corresponds to the maximum gwei-per-gas price. Transaction remains pending if baseFee > maxFee.
• refund = max (0, maxFee − (baseFee + maxPriorityFee)) is refunded to the user after transaction execution.
• More in great video of Tim Roughgarden on eip1559
• Essential tools for dertermining fees (usually these are automatically set by your wallet though):
• https://www.blocknative.com/gas-estimator
• https://etherscan.io/gastracker

Ethereum ecosystem

Decentralized Finance (DeFi)

• DEXs (e.g. uniswap)
• Centralized exchanges use the “order book” design for trading
• Decentralized exchanges, restricted by blockchain constraints, predominantly use the AMM (automated market maker) design:


On the left you see (1)-(6) steps on how uniswap works.

Key point is that the product of two quantities doesn’t change after the trade: 1550 1 = 1599 0.938

• Order book design becomes feasible again on L2 (see scaling discussion below)
• Money markets (e.g. aave, compound)

See the diagram below for the step-by-step description.

VERY IMPORTANT addition to the diagram: if Alice’s LTV spikes to >85%, she get’s liquidated: her ETH is sold to liquidators (usually bots that monitor this stuff) for 5% discount, and the loan is cancelled.


• Oracles (e.g. chainlink)

How does AAVE know the price of ETH? It can look at uniswap, but in practice it uses an oracle.



The oracle problem: in this architeccture, the decentralized protocol (aave) relies on a centralized source coming from TradFi.

⇒ need to decentralized oracle. Most popular solution: chainlink


• Stablecoins

It is an ERC-20 token that is pegged to 1 dollar.

The pegging mechanism is the heart of the stablecoin. Three types:

1. Fiat-backed: USDC, USDT […]
2. Crypto-backed: DAI, LUSD, RAI (this one is free-floar, i.e. pegged only loosely) […]
3. Algorithmic: FRAX, UST (collapsed) […]

1. Tokens carry governance rights (this benefits holders AND the protocol)
2. Sometimes have value accrual mechanisms (e.g. fees directed to holders)
3. Have a speculative premium (⇒ ability to “invest into projects”; this matters a lot)
4. Are used to incentivize participants (e.g. COMP), supercharging network effects of Web 3 projects.

• multi-sigs
• bigger decentralized capital formations (e.g. molochDao)
• decentralized organizations that govern DeFi projects (makerdao, aave, etc), require token
• token/nft-gated communities
• etc

• Users: single millions https://dune.com/rchen8/defi-users-over-time

Rmk: not everyone will be a power user.

• Total Value Locked (TVL): tens of billions https://www.defipulse.com/

• Automation & programmability [logic of financial contracts is enforced by Ethereum EVM, as opposed to being enforced by the US laws in TradFi]

⇒ rent-extracting intermediaries removed ⇒ systems are much more efficient

• Open access for scrutiny

⇒ systems are much more secure than TradFi

• Decentralization (this is a spectrum! Some protocols are more decentralized than others)

⇒ no collusion

⇒ open access for usage (censorship resistance)

⇒ self-custody [this is good and bad; good because you own your assets ⇒ less collusion; bad because of security issues, this is currently being solved by things like social recovery of wallets]

Rmk: DeFi currently is not accessible to all due to high fees, but will be in 2 years — see scaling discussion below.

• Open-source code ⇒ insanely fast development
• Composability ⇒ systems interoperate smoothly. Decentralization (⇒no collusion) helps to remove the incentive to verticalize the system.
• Atomic composability: flash loans

‣

More info:

Spectrum of DeFi:

Comparison of TradFi vs DeFi:

TradFi

Permissioned

• Closed-source system, built on top of centralized databases
• Needs approval & agreement for third-party to use & build on

Custodial

• Assets are custodied by licensed third-parties

Centralized trust & governance

• Single entity responsible for upgrade decisions & admin privileges

Real identity

• Users register with real identity, e.g., for KYC/AML compliance

DeFi

Permissionless

• Open-source system; built on top of permissionless blockchains
• Anyone can use / scrutinize / build on top

Non-custodial

• Assets are not custodied by a single third-party

Decentralized trust & governance

• No single entity responsible for upgrade decisions & admin privileges (many exclusions! This is a spectrum)

Pseudonymous

• Users usually do not provide real identities

What else is interesting in blockchains? (overview of other special topics)

NFTs

• on-chain art:
• “classical” digital art (xcopy, beeple)
• generative art (artblocks)
• physical/digital mix (damien hurst)
• 10k profile picture collections (cryptopunks, bored apes, nouns, and many many more)
• kind of similar to physical collectibles
• enable investing into “brand” and “culture”
• ongoing progress on lisensing IP rights
• game items
• ENS
• music NFTs (example 1, 2)
• specific financial instruments (e.g. LP certificates in uniswap V3)

Scaling approaches

• Bitcoin: ~5 txs / sec Ethereum: ~20 txs / sec Visa: 24000 txs / sec
• Tx fees on Ethereum fluctuate from 0.5$ to 30$ for a simple transfer.
• Bottleneck for scalability = not the compute/consensus part, but rather the storage part, namely the growth of state size of Ethereum
• [Scaling<———>Decentralization] tradeoff (block size debate in Bitcoin)

Payment channels (a strategy for scaling)

• Uni-directional payment channel description: [Alice] ———[PAYMENT CHANNEL 100$]———> [Bob]
1. Alice sets up a payment channel with 100$, onchain. HTLC (Hashed TimeLock Contract) logic of the payment channel:
1. Money can be withdrawn with Alice’s sig, but only 30 days after deployment of the channel
2. Money can be withdrawn with Alice’s sig AND Bob’s sig at any moment
2. Alice pays 5$ to Bob for coffee by signing the following tx, offchain!

(“distribute funds: 95$ → Alice, 5$ → Bob”, )

3. Alice pays another 5$ to Bob by signing the following tx, offchain again:

(“distribute funds: 90$ → Alice, 10$ → Bob”, )

4. …
5. 29 days after the payment channel was initiated, Bob signs the last tx of Alice and gets all the payments by closing the payment channel onchain.
• Bi-directional payment channel: article, original paper
• Lightning network

Rollups (the scaling strategy now for Ethereum, 2nd strategy for scaling).

• zk rollups (e.g. zk-hermez, zk-sync, starknet)

Use SNARKs (or STARKS) to compress computation


‣
SNARK high-level description: (extremely cool)
• C: a program that always terminates in ≤B steps x: public input to C w: private input to C (witness)
• PROVER knows (C, x, w); VERIFIER knows (C, x)
• PROVER wants to prove to VERIFIER that he knows such w that C(x, w)=1, without sending w
• PROVER ———[short proof ]———> VERIFIER ⇒ VERIFIER is convinced C(x,w)=1, without knowing w and therefore without actually computing C(x,w) [⇒ this tech is useful for privacy]
• VERIFIER’s running time for checking is much less than running the program C [⇒ this tech is useful for scaling]
‣
zkRollup simplified details:
• Rollup operator (RO) stores balances of users in Merkle tree
• RO publishes the Merkle root on Layer 1
• When Alice sends her tx [A→B, 2ETH], , and others also send their txs, RO processes txs, updates balances, and publishes (new root + txs summary (without sigs ⇒ short!) + SNARK of the correct transition)
• Producing SNARK is the hard part ⇒ RO will collect some fees. RO’s SNARK proves [old root] ———(applying valid txs)———>[new root] is correct

In more detail: Public input to program C is x = old root + new root + txs summary Private input to program C is w = old account balances + updated account balances + signatures of users Program C(x, w) will process txs: will check signatures and balances, will process according to txs summary, and output 1 if all good or 0 if things don’t add up

• Nodes simply verify the SNARK
Remarks:
• Txs within rollups are easy, thanks to batch settlement on L1
• Moving funds L1 → L2 and back is more difficult: requires posting more data to L1 ⇒ higher tx fees. This is because tx of type [RC → Alice: 2 ETH] need to be processed directly on L1.
• Rollup → rollup can be done via L1 (expensive, more secure), or via a direct L2 ←→ L2 bridge (cheaper, less secure)
• optimistic rollups (e.g. arbitrum, optimism)

Rest on economic incentive design: similar to zk-rollups but proofs are not posted at all, but if there is a malicious behavior, fraud proofs are posted by “watchers” and rollup operator is slashed.

Sharding (long-term scaling strategy)

Proof of stake

• Another direction where Ethereum is innovating: transition from proof-of-work to to proof-of-stake (on Thursday night around 3am), see this intro video for more details).
• How PoS works, in three lines:
• miners are now called validators, and they stake eth = lock eth in a certain smart contract
• leader selection is done randomly (as opposed to according to mining), proportionally to how much validators have staked
• malicious behavour ⇒ stake is getting slashed

• Main idea: incentive to “not to waste your energy on the wrong fork” is getting substituted with incetive to “not to build on the wrong fork cause my ETH will be shashed
• The transition will reduce 99% energy consumption of Ethereum ⇒

⇒ no electricity bills for miners (now called validators) ⇒

⇒ no need to pay huge block rewards to validators ⇒

⇒ massive reduction in inflation (this is costs for a blockchain) ⇒

⇒ much more economic efficiency of the blockchain (more security for dollars spent)

(see 2:10 timestamp in this video for a quick breakdown of benefits of PoS)

• Ethereum actually becomes the first productive blockchain

Privacy

• zk technology allows to process txs while keeping them secret

• These are being implemented on the L1 level (e.g. zcash), on the L2 level (e.g. aztec), and on the app layer (e.g. tornado cash; use vpn for this)

MEV

• All user pay fees to get their txs included in blockchain.
• Certain users pay extra fees to order txs in a particular order (to be first to execute arbitrage, liquidations, frontrunning, etc) – these extra fees are called MEV (Maximal Extractable Value). It is bad because frequently sophisticated users take advantage of retail users [to be clear, there is “fair” MEV (like liquidations and arbitrage), and there is “parasitic” MEV (like frontrunning and sandwiching); these notions are loose though]
• Ethereum tackles the MEV problem by introducing a separate market for “searchers”: people who bundle transactions, and then participate in auction for these bundles to get included. Flashbots is the current short-term implementation of this = a certain program (”mev boost” to be precise) that validators run alongside their nodes, through which searchers can send their bundles.
• Proposer-builder separation is the mid-term (2 years) protocol level solution in Ethereum for MEV = essentially embedding this separate economic market into the Ethereum protocol