Topics for researching and presenting

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.

Topics: (with some links)

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
More info:

Spectrum of DeFi:

image

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
  • AMMs (automated market makers) [intro 1, 2, 3, 4 + Chapter 7 in the book above (how-to-defi) + lecture]
  • notes from Lecture 2
    • Centralized exchanges use the “order book” design for trading
    • Decentralized exchanges, restricted by blockchain constraints, predominantly use the AMM design:
    • image

      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)
  • Oracles [intro 1, 2 + lecture]
  • notes from Lecture 2

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

    image

    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

    image
  • Money Markets (lending protocols) [intro 1 + Chapter 6 in the book above + lecture]
  • 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.

    image
  • Stablecoins [intro 1, + Chapter 5 in the book above + lecture]
  • 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 [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”, )

      4. Alice pays another 5$ to Bob by signing the following tx, offchain again:
      5. (“distribute funds: 90$ → Alice, 10$ → Bob”, )

      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 [intro 1, 2]
  • 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) [intro 1, 2 + lecture]
  • 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 ]———> 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 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 [intro 1, 2]
  • notes from Lecture 2

    Use SNARKs (or STARKS) to compress computation

    image
    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)

Social impact of blockchains: (more behavioural economics here)

  • DAOs (decentralized autonomous organizations) [intro 1 + references in that article]
  • 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) [intro 1 + book below]
  • How to NFT_PDF.pdf9738.3KB
    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/]

    • 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):

  1. MEV (miner/maximal extractable value) [intro 1 + references in that article]
  2. 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