- What is expected from “researching a topic”?
- What is expected from “presenting 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.
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)
Traction of DeFi:
- Users: single millions https://dune.com/rchen8/defi-users-over-time
- Total Value Locked (TVL): tens of billions https://www.defipulse.com/
Rmk: not everyone will be a power user.
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]
- Open access for scrutiny
- Decentralization (this is a spectrum! Some protocols are more decentralized than others)
- 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
⇒ rent-extracting intermediaries removed ⇒ systems are much more efficient
⇒ systems are much more secure than TradFi
⇒ 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.
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
AMMs (automated market makers)
- Centralized exchanges use the “order book” design for trading
- Decentralized exchanges, restricted by blockchain constraints, predominantly use the AMM design:
- Order book design becomes feasible again on L2 (see scaling discussion below)
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
Oracles
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)
intro 1
Chapter 6 in the book above
[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
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
Intro:
- 1
- Chapter 5 in the book above
Resources on how crypto-backed stablecoins work, via the example of MakerDAO and its stablecoin DAI:
- brief intro
- whitepaper (main resource for you)
- smart contract architecture (another main resource)
- detailed docs (too technical and probably useless, but good to know about this page)
- youtube lecture - this is good to watch AFTER you understood makerDAO. This youtube lecture might help you to compose nice presentation.
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]
- video starting from 59 minute
- https://vitalik.ca/general/2022/05/25/stable.html (ignore the RAI description there, only read about luna/terra)
Scaling / privacy solutions:
(more technology here)
Scaling Bitcoin: payment channels and lightning network
- Uni-directional payment channel description: [Alice] ———[PAYMENT CHANNEL 100$]———> [Bob]
- Alice sets up a payment channel with 100$, onchain. HTLC (Hashed TimeLock Contract) logic of the payment channel:
- Money can be withdrawn with Alice’s sig, but only 30 days after deployment of the channel
- Money can be withdrawn with Alice’s sig AND Bob’s sig at any moment
- Alice pays 5$ to Bob for coffee by signing the following tx, offchain!
- Alice pays another 5$ to Bob by signing the following tx, offchain again:
- …
- 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
(“distribute funds: 95$ → Alice, 5$ → Bob”, )
(“distribute funds: 90$ → Alice, 10$ → Bob”, )
Scaling Ethereum: optimistic rollups
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
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)
How zk-SNARKs work:
- https://decentralizedthoughts.github.io/2020-12-08-a-simple-and-succinct-zero-knowledge-proof/
- https://zkhack.dev/whiteboard/ (first 3 modules)
- https://vitalik.ca/general/2021/01/26/snarks.html (general + FRI intro)
- https://vitalik.ca/general/2017/11/22/starks_part_2.html (more FRI)
- https://vitalik.ca/general/2019/09/22/plonk.html
- https://a16zcrypto.com/zero-knowledge-canon/ (vast meta-resource)
Privacy applications:
Tornado cash:
[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)
[4] https://www.youtube.com/watch?v=z_cRicXX1jI&t=363s&ab_channel=SmartContractProgrammer (random video I found, might be helpful)
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
- zk technology allows to process txs while keeping them secret
- 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
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:
- EVM in Ethereum - this is a prerequisite info to understand what actually one wants to generate proof for
- what is zkEVM
- quick general overview of different approaches
- the final boss: try to understand the architecture of polygon hermez and its zkEVM (this is a particular zk rollup)
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:
Use SNARKs (or STARKS) to compress computation
- 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]
- 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
- Nodes simply verify the SNARK
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
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 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)
issues with token voting https://vitalik.ca/general/2021/08/16/voting3.html
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”)
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.
- Tokens carry governance rights (this benefits holders AND the protocol)
- Sometimes have value accrual mechanisms (e.g. fees directed to holders)
- Have a speculative premium (⇒ ability to “invest into projects”; this matters a lot)
- 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
- links in “notes from Lecture 2” below
smart-contracts
Here are the links that might help you to understand ERC-721 (the NFT smart-contract):
- https://ethereum.org/en/developers/docs/standards/tokens/erc-721/
- https://eips.ethereum.org/EIPS/eip-721
- http://erc721.org/
- https://www.quicknode.com/guides/smart-contract-development/how-to-create-and-deploy-an-erc-721-nft
- Also, make sure to read about metaData starting on page 20 of the book.
gen-art
- Make sure to understand that the the point of generative art (in particular, projects that are listed in artblocks.io) on the blockchain is that the artist provides the algorithm, while the user who mints the NFT provides the random parameter, and this way both artist and the minter are creators of the NFT.
- might be a good video to get the general feel for gen art: https://www.youtube.com/watch?v=vsQQWjaqnBA&ab_channel=DeFi%2CNFT%26Web3Insights-TheDefiant
pfp collectibles
- here google by yourself the story of cryptopunks
- video on bored apes: https://www.youtube.com/watch?v=JXJoqQi7r5E&t=636s&ab_channel=DeFi%2CNFT%26Web3Insights-TheDefiant
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.
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:
- “classical” digital art (xcopy, beeple)
- generative art (artblocks)
- physical/digital mix (damien hurst)
- 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)
intro links
- 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:
- types of MEV: liquidations, arbitrage, sandwich trading
- mechanics of MEV:
- eip1559
- if nothing else is introduced, MEV is done via priority fee, and MEV leads to centralization of validators)
- how flashbots tackles the problem of validator ccentralization [https://docs.flashbots.net/flashbots-auction/overview]
- MEV boost mechanics (how the aucction works on the agent level) [https://docs.flashbots.net/flashbots-mev-boost/introduction]
- how MEV-boost leaded Ethereum to weak censorship
- how censorship will be faught by Ethereum long-term
- [https://www.youtube.com/watch?v=azjpYTB7PVE&ab_channel=BanklessShows]
- proposer-builder separation
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]
- 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