# Topics for researching and presenting

Guidelines for how to research and present: (click to expand)
• What is expected from “researching a topic”?
• Research here does not mean “original scientific research”. It rather means - consuming a large amount of resources (blog posts, papers, documentations, videos, etc) - understanding and digesting well those resources - synthesizing all this into a complete picture, solid understanding of the area, from different angles. By different angles I mean: motivation, technical background, various implementations (including technical architecture), current progress, future directions, etc. (Details for each separate project will vary; I will help guide you through your research)

I strongly suggest taking notes in the process of doing research. These notes will help you compose the presentation in the future.

• What is expected from “presenting a topic”?
• Well-composed 45 minute presentation, rehearsed and delivered by both teammates (⇒ need to divide the content between the two), based on the detailed research.

## DeFi primitives:

(more economics here; intro 1)

How to DeFi Beginner.PDF.pdf9114.4KB
note from Lecture 2 on generalities of DeFi

Traction of DeFi:

Key gamechangers for why DeFi >> TradFi:

• 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

Spectrum of DeFi:

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

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

### AMMs (automated market makers)

resources

[1, 2, 3, 4 ] intro

Chapter 7 in the book above (how-to-defi)

[12] two good lectures

[456] links for impermanent loss (or "divergence loss")

LVR: video, paper

notes from Lecture 2
• Centralized exchanges use the “order book” design for trading
• Decentralized exchanges, restricted by blockchain constraints, predominantly use the AMM 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 $\cdot$ 1 = 1599 $\cdot$ 0.938

• Order book design becomes feasible again on L2 (see scaling discussion below)

### Oracles

notes from Lecture 2

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

### Money Markets (lending protocols)

resources

intro 1

Chapter 6 in the book above

[12] two excellent youtube lectures on generalities of lending protocols

[3] aave whitepaper (can ignore flashloans and stable rates)

[4] aave docs (can ignore flashloans and stable rates)

Key concepts to understand:

• [intro] General idea of a lending protocol (money market): participants deposit tokens, and then borrow tokens for an annual interest, respecting the collateralization factor / ratio
• [intro] Understand use cases: earning yield on stablecoin, leveraging position on ETH
• [deeper] understand well what liquidations are and when do they occur
• [deeper] understand well the actual architecture of AAVE v1:
• smart contract architecture (see figure 4 in [3])
• how the interests on borrowing are calculated
• all functionalities on the user's side: deposit, borrow, repay, redeem
• role of AAVE token
• stability module
notes from Lecture 2

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.

### Stablecoins

resources

Intro:

• 1
• Chapter 5 in the book above

Resources on how crypto-backed stablecoins work, via the example of MakerDAO and its stablecoin DAI:

Key concepts and things to understand:

• What is the core mechanism by which DAI is minted?
• What are the use cases to mint DAI?[essentially (1) to take a leverage position on ETH or (2) start using you assets (ETH) without selling them, but instead borrowing DAI for them]
• How is the price of DAI pegged to 1 usd?
• what happens if 1 DAI > 1USD ?
• what happens if 1 DAI < 1 USD ?
• What happens if the collateral ration in a vault(cdp) is too low? What are liquidations precisely? What incentive do liquadtors have to execute liquidations?
• What is the overall smart contract architecture of makerDAO system
• Why at some point USDC was introduced as another type of collateral in makerDAO?

Resources on deleveraging spiral (or death spiral) = cause of luna/ust collapse

[make sure to understand that the key reason for this is the endogenous nature of the collateral, as opposed to ETH which is exogenous]

UST Death Spiral Recap _ Blockworks Research.pdf2237.4KB
notes from Lecture 2

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) […]

## Scaling / privacy solutions:

(more technology here)

### Scaling Bitcoin: payment channels and lightning network

resources

intro 1

47:34 time in this video

bi-directional channels 1, 2

notes from Lecture 2
• 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! 3. (“distribute funds: 95$ → Alice, 5$→ Bob”, $sig_{Alice}$) 4. Alice pays another 5$ to Bob by signing the following tx, offchain again:
5. (“distribute funds: 90$→ Alice, 10$ → Bob”, $sig_{Alice}$)

6. 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

### Scaling Ethereum: optimistic rollups

resources

[intro 1, 2]

Resources on fraud proofs:

Here is an article that gives a simple but yet somewhat technical description of fraud proofs: https://vitalik.ca/general/2021/01/05/rollup.html

notes from Lecture 2

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.

### Privacy solutions: zero knowledge technology

(math heavy)

resources

How zk-SNARKs work:

Privacy applications:

[1] https://www.youtube.com/watch?v=H3GmsxRU1Kw&ab_channel=DeFiMOOC (starting from 1:04:44, but recommend the whole lecture for background as well)

[1’] https://artofkot.xyz/blog/tornado-cash (my post that summmarizes the above video)

[2] https://vitalik.ca/general/2022/06/15/using_snarks.html (see sections "what does a zk-snark do" and "zk-snarks for coins")

[3] https://berkeley-defi.github.io/assets/material/Tornado%20Cash%20Whitepaper.pdf.  (this whitepaper is very dense and math heavy, so might be easier to start with other resources)

I recommend resources [1+1’] + [2] + [3], in this order. [4] might also be helpful. And here are the key concepts / things that you need to understand in order to make a good presentation:

• what does a zk-snark do on a high-level: the privacy application (zero-knowledge), and the the scaling application (succinctness) [best explained in the beginning of [2])
• what is the structure of tornado cash smart contract: variables and functions
• what are different ways users interact with tornado cash contract: depositing and withdrawing
• where in the functionality above happens the zk-snark: what is function f, statement x, witness w, where is the proof generation, proof verification, etc
• who are relayers and why are they needed
• how tornado cash allows users to deanonimize, and therefore comply with regulators
notes from Lecture 2
🔶
Problem 3. People like to have their financial privacy.
• zk technology allows to process txs while keeping them secret
zk SNARK high-level description: (extremely cool tech)
• 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 $\pi$]———> VERIFIER ⇒ VERIFIER is convinced C(x,w)=1, without knowing w and therefore without actually computing C(x,w)
• VERIFIER’s running time for checking $\pi$ is much less than running the program C
• 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)

### Scaling Ethereum: zk rollups

resources

Intro: 1

Starter resources:

• Incomplete guide to rollups - a nice semi-technical description of rollups, on the level of my lectures + a bit of details concerning how txs are organized into Merkle trees [rmk 1: here is a video where Vitalik goes through the above article] [rmk 2: I would say ignore the complete guide to rollups, since this article is too big and too much into the future of rollups]
• ethereum.org article - a bit dense since there are no diagrams there, but its still a nice resource.
• Barry Whitehat video a not-so-technical video on zk-rollups, might be helpful to watch and get a perspective from the person who invented zk-rollups
• most comprehensive article I was able to find (which doesn't go into low-level emv discussion)

After the above four resources you should have a solid understanding of how a zk-rollup works, provided the proof-generation is treated as a black box. Namely:

– what exactly is published in a smart contract (Merkle root of a state)

– what is the statement for which the proof is generated by a rollup sequencer (operator)

Further direction (1): diving deeper into the challenge of generating proofs. The idea is that if one wants to program smart contracts in solidity for the rollup, a compatible to Ethereum environment is needed, since one needs to be able to generate the proof for each of the EVM's opcodes: this is done by creating a "zkEVM" - this is the direction taken by teams zkSync, polygon hermez and scroll. Alternatively, one can try to support a different programming environment (this is the direction of StarkNet), and ditch the idea of zkEVM - though in this case programmers need to learn a new language (Cairo in case of starkNet). Here are articles I suggest you read:

Further direction (2): focusing on StarkWare (dont confuse with StarkNet) - starkware is a bespoke production-ready zk-rollup that supports only token transfers. The most famous app that uses it is "dydx" futures exchange. Essentially a thing here would be to talk about its architecture:

notes from Lecture 2

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 $\pi$]———> 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 $\pi$ 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], $sig_A$, 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)

## Social impact of blockchains:

(more behavioural economics here)

### DAOs

(decentralized autonomous organizations)

resourcces
• intro 1
• references in the article above

key directions:

theDAO, the hack, the fork

multi-sig wallets (gnosis SAFE)

tokens+delegation based voting (makerDAO, ensDAO, gitcoinDAO, yearnDAO)

snapshot vs on-chain voting: one is not sybil resistant, the other is, because on-chain voting locks the tokens

nft-based voting (nouns DAO)

molochDAO, rage quitting as an incentive alignment mechanism

how people get recognized and paid in a DAO (yearnDAO is leading the way here, google “coordinape”)

notes from Lecture 2

DAOs are:

• 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

(*) Many of projects / protocols on Ethereum have their own tokens.

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.

Rmk. It is important to acknowledge that cryptocurrencies / tokens are a good form of coordination when used as a reward / value accrual / coordination mechanism, but not as a means of voting power, because of bribery attacks.

Key reason for a token — decentralization of the protocol into a DAO. The mechanics of it are still very much evolving. (e.g. how uniswap retroactively rewarded users with tokens, as if uber would airdrop their stocks to all of their drivers and passengers, in order to achieve a shared ownership of the protocol. This is hard to repeat though, because of sybil attacks.)

### NFTs

(non-fungible tokens)

resources

intro

• 1 + book below
How to NFT_PDF.pdf9738.3KB
• links in “notes from Lecture 2” below

smart-contracts

gen-art

pfp collectibles

• here google by yourself the story of cryptopunks

value of NFTs

• Google and read more to understand several components of value of NFTs:
• 1) value through ownership of the original piece (applies more to digital art and gen art), in analogy with classical physical art

2) value through collecting things / being part of a community (applies more to 10k pfp projects), in analogy with collecting pokemon cards

3) value through social signaling / brand (applies more to pfps, but to art too), in analogy with how people buy rolexes and expensive cars to signal their wealth

4) value through the potential price-upside (applies to everything that is scarce, as opposed to rolexes that are not scarce), in analogy with how people invest in stocks. NFTs for the first time allowed people to invest into a brand / culture.

notes from Lecture 2

NFT = certificate on a blockchain asserting that someone posesses a certain unique digital asset

Key innovation: art is an uncopyable NFT ⇒ can sell art digitally ⇒ 1000x distribution for artists

Why NFTs have value? Counter-question: why do people buy physical art and display it in their houses? Its not because the piece itself has value — the real value is in showing other people that you “bought and have” this original piece. Same thing happens digitally.

Various types of NFTs: [sold/bought on special marketplaces: https://opensea.io/, https://x2y2.io/, https://sudoswap.xyz/, magice eden]

• on-chain art:
• 10k profile picture collections (cryptopunks, bored apes, nouns.wtf, 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)

## Blockchain specific aspects:

(arbitrage / market efficiency type of considerations here):

### MEV

(miner/maximal extractable value)

resources

• main article, contains excellent and are very good starting points, including the big picture links at the end ("further reading"), see them below. In particular I absolutely love the "ethereum is a dark forest" blogpost, it gives you a very good idea of what is going on in terms of bots in Ethereum.

key themes to focus on:

key concepts to understand:

(basiccally understand the flashbots on a detailed level)

• how the auction in flashbots works, on the economic/abstract level. The idea that the majority of MEV as a result goes to miners/validators, since searchers compete with each other.
• how the auction in flashbots works on a technical level, from agent to agent. The searcher's role, the builder's role, the relayer's role (and why one needs relayers at all).
• The step by step process of MEV extraction, from forming a bundle by a searcher to inclusion of that bundle into a block by validator [might be best desccribed as two “lifecycles of a transaction”, on is pre-flashbots and one is post-flashbots]

notes from Lecture 2
🔶
Problem 4. Financialization of blockchains means that certain transactions (arbitrage, liquidations, etc) are worth much more than the others.
• 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