Ion Onboarding Doc

This document is meant for developers looking to get an overview of smart contract development and how it relates to relevant products in the DeFi ecosystem. ## :white_check_mark: Checklist :::success A list of things to be completed in about a month's time. ::: ## :small_orange_diamond: DeFi: Stablecoins First and foremost, you need to become familar with the high level concepts surrounding perhaps the most important asset class in DeFi—stablecoins. (That's until you get to liquid staking, but that comes later). While its value proposition is simple—onboarding fiat dollars to the blockchain to be used as liquid currency—the singular goal of 'keeping the peg' against the dollar introduced many interesting mechanisms for designing a resistant stablecoin via arbitrage, overcollateralization, liquidations, etc. You'll see many parallels and differences between how these products make use of natural behavioral incentives to maintain solvency of the protocol. This section is about how the OG stablecoins came about. - [ ] MakerDAO - Overcollateralized USD-denominated stablecoin with diverse collateral types with an emphasis on decentralization with governance based parameter adjustments. - Concepts - [ ] [Collateralized Debt Positions](https://makerdao.com/en/whitepaper/#abstract) - [ ] This page will give you a full high level overview of MakerDAO. - [ ] [Liquidations](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) via dutch auctions - This page will have Maker-related jargon that might be hard to follow. Try to focus on explanations about the high-level economics of the auction system. - [ ] Programmatic [interest rate collection and savings rate emissions](https://docs.makerdao.com/smart-contract-modules/rates-module) - An interesting read that allows you to understand how economic maths are translated to code on Ethereum with certain optimizations and assumptions. Notably how interest rates are truly realized or lost in the system, how it depends on 'incentivized parties' aka keepers. - [ ] [Peg Stability Module](https://manual.makerdao.com/module-index/module-psm) - A [more detailed look](https://mips.makerdao.com/mips/details/MIP29#MIP29c2) at the motivations and implementation of the PSM - [ ] Liquity - Overcollateralzed USD-denominated stablecoin backed by a single collateral type—ETH. Similar to MakerDAO, but has different mechanisms of peg stabilization. - Concepts - [ ] [The whitepaper](https://docsend.com/view/bwiczmy) - If you read this and understand all of it, you can probably move on. - [ ] Redemptions - Read both [this](https://www.liquity.org/blog/understanding-liquitys-redemption-mechanism) and [this](https://docs.liquity.org/faq/lusd-redemptions). They are short and concise descriptions. - A unique way that Liquity establishes a hard lower bound on downward depeg. - [ ] [Stability Pools](https://github.com/liquity/beta/blob/main/README.md#liquidation-and-the-stability-pool) - Note how this serves the same exact function as Maker liquidations of paying off debt and closing down underwater positions, but it is a different implementation with tradeoffs such as less reliant on active keepers, exposure to liquidation profits for people with less capital, but requires lock up of funds. - Honorable mentions - There isn't enough time to go over every project, but other interesting concepts that deserve your attention: - [Frax](https://docs.frax.finance) and Automated Market Operations - Mimics a central-bank like mechanisms for keeping the peg, and is a product suite of multiple defi services on top of their stablecoin. - Seignorage Shares Algorithmic Stablecoins - Read [Vitalik's analysis all the way back in 2014](https://blog.ethereum.org/2014/11/11/search-stable-cryptocurrency) on the overall landscape - [Whitepaper on Seignorage Shares](https://github.com/rmsams/stablecoins/blob/master/paper.pdf) - This is what Terra/Luna was based off of. ## :small_orange_diamond: DeFi: Lending Markets Now that you're familiar with stablecoins, we move onto lending markets. There's a bit more math now, but the same exact concepts from stablecoins apply such as liquidations, collateralization ratios, and interest rates. - Fundamentals - [ ] Compound [Must Read] - [v1 whitepaper](https://compound.finance/documents/Compound.Whitepaper.pdf) - [ ] Aave [Must Read] - [v1 whitepaper](https://github.com/aave/aave-protocol/blob/master/docs/Aave_Protocol_Whitepaper_v1_0.pdf) - [v4 proposal] (https://governance.aave.com/t/temp-check-aave-protocol-v4-development-proposal/17541) - Current Protocols - [ ] Morpho Blue [Must Read] - [whitepaper](https://github.com/morpho-org/morpho-blue/blob/main/morpho-blue-whitepaper.pdf) - [ ] EVC/EVK/EulerV2 [Must Read] - [whitepaper](https://evc.wtf/docs/whitepaper) - [Links to all the codebases](https://cantina.xyz/competitions/41306bb9-2bb8-4da6-95c3-66b85e11639f) ## :small_orange_diamond: DeFi: Liquid Staking - [ ] Proof-of-Stake - Before thinking about 'liquid' staking, you first want to think about 'staking', or the proof-of-stake consensus mechanism. First, there's the consensus algorithm of Capser FFG + LMD GHOST, and there's the specific implementation details on how this algorithm is actually used on Ethereum. - [ ] [The ETH2 Book](https://eth2book.info/capella/): This explains how today's Ethereum have implemented Casper FFG and LMD GHOST using penalties, slashings, and rewards to align cryptoeconomic incentives. Some sections that are a must read are below. - [ ] [2.3 Consensus](https://eth2book.info/capella/part2/consensus/) This and subpages are a summary of the Casper/LMD paper. - [ ] [2.8 The Incentive Layer](https://eth2book.info/capella/part2/incentives/) and the subpages. Especially on rewards/penalties/slashings. - [ ] [Casper FFG and LMD Ghost Paper](https://arxiv.org/pdf/2003.03052.pdf): Explanation with proofs. This you can skim through, or maybe just read the high level introductory sections. - [ ] Casper FFG is defining how we view the distributed ledger as a growing tree of blocks, and LMD Ghost is a 'fork-choice-rule' aka how we know which chain—a path from the root block to a leaf block—is 'correct'. - [ ] [Client Softwares](https://ethereum.org/en/developers/docs/nodes-and-clients/) - [ ] Execution Layer Clients: [geth](https://github.com/ethereum/go-ethereum), reth - [ ] Consensus Layer Clients: [prysm](https://github.com/prysmaticlabs/prysm), lighthouse - [ ] Lido - [ ] Reading the [introduction page](https://docs.lido.fi) and its parts should be sufficient. The dominant liquid staking provider in the market. - [ ] Rocket Pool - A provider with a 'permissionless' node operator set. Any one can run a node without being whitelisted, put up collateral, and match with crowdfunded ETH to establish a validator. The rETH token can be redeemed at an exchange rate reported by the 'oDAO' that tracks the total amount of yield earned by Rocket Pool node operators. - [ ] How the oDAO reports rewards in a [merkelized format](https://github.com/rocket-pool/rocketpool-research/tree/master/Merkle%20Rewards%20System). - [ ] Puffer - An example of a new type of liquid staking provider with improved trust guarantees and economic security. An interesting case to learn about. - [ ] [Secure Signing](https://docs.puffer.fi/tech/securesigner) - Allows intel SGX-based [verifiable remote attestations](https://docs.puffer.fi/tech/rave) for proving that the validator is running secure signing programs. - [ ] DVT (Distributed Validator Technology) - So how can staking providers improve their security guarantees and operate robust validator sets? - DVT is one answer, with [Obol](https://docs.obol.tech/docs/int/Overview) being a good example. - [ ] [Eigenlayer](https://docs.eigenlayer.xyz/overview/readme) - Introduces restaking, the idea of using the same amount of capital as slashable security for multiple networks that require distributed validation. The whitepaper is a must read. - [ ] [Restaking whitepaper](https://2039955362-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPy2Kmkwju3mPSo9jrKKt%2Fuploads%2F9tExk4U2OdiRKGEsUWqW%2FEigenLayer_WhitePaper.pdf?alt=media&token=c20ac4bd-badd-4826-9fb6-492923741c9e) - [ ] Currently, liquid representations of restaked assets don't exist. Once deposits are put into Eigenlayer, there is no liquid format like stETH that is minted. - [ ] Here's a draft proposal for a [liquid-restaking provider](https://hackmd.io/@junkim012/rJgZW8e33) that we are currently discussing with the Eigenlabs team. - [ ] [Execution Layer Triggered Exits](https://eips.ethereum.org/EIPS/eip-7002) - A large problem in the liquid staking space is about who has the right to withdraw from the beaconchain. For Lido, it's the Lido DAO. For Rocket Pool, it's the node operators. - Lido can facilitate large redemptions of stETH into ETH by having the Lido DAO sign off on withdrawals, but this centralizes power into the 'DAO' which is not very distributed. - For Rocket Pool, if they do withdraw, the ETH will go to a smart contract to be distributed fairly. But the node operators can technically reject requests to redeem/withdraw, effectively holding the staked ETH 'hostage', making it so that noone gets access to the staked ETH. - This upgrade allows a smart contract to initiate withdrawals, which means node operators won't be able to hold assets hostage in the beaconchain. - [ ] Our own Risk Framework - [ZK Proof-of-Reserve](https://hackmd.io/K8crceycRDORaNJYMTnU1A) ## :small_orange_diamond: Dev: Solidity Finally, we've completed the DeFi section! You can now be employed at any crypto VC as a dev with DeFi knowledge. Congratulations. Now onto the easy part—learning Ethereum development. Solidity is a pretty simple OOP language, with the solc compiler. While the usage and syntax is simple, there's depth in optimizations and lots to learn in the wild west of smart contract security with billions of dollars at stake. - [ ] [Solidity by example](https://solidity-by-example.org) - If you go through every entry here and understand each example, you're set. - [ ] [Solidity data storage layouts](https://docs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html) - Useful information that explains more about contract storage layouts. - [ ] Upgradeability - Smart contract applications are by default difficult to upgrade since deployed bytecode is immutable onchain. There are however, frameworks such as [proxy patterns](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies) that allows you to implement upgradeability. - [ ] Dev Tools - Allows you to deploy and test smart contracts. I recommend foundry as that's the tooling that we use. It is faster and all scripts/tests can be done natively in solidity without context switching to javascript with Hardhat or python with Brownie. Also has a more active developer community. - [ ] Hardhat - [ ] Brownie - [ ] [Foundry](https://book.getfoundry.sh)*** - [ ] [Tutorial](https://jamesbachini.com/foundry-tutorial/) and overview on useful Foundry functionalities. ## :small_orange_diamond: Dev: Smart Contract Security While the usage and syntax for Solidity is kept simple, there's a lot of complexity in keeping the code secure from both software and economic attack vectors. - [ ] Testing - In order of simple to complex, there's static analysis, unit testing, fuzzing, symbolic execution, and formal verification with different tools for each method. Aside from static analysis, unit testing, and fuzzing, other methods are impractical for a small team, but is still great to know about. - [ ] Static Analysis using [slither](https://github.com/crytic/slither) - [ ] Unit Testing: basic tests with [foundry](https://book.getfoundry.sh/forge/writing-tests) - [ ] Fuzz Testing: [fuzzing in foundry](https://book.getfoundry.sh/forge/fuzz-testing), [fuzzing with echidna](https://github.com/crytic/echidna) - [ ] Symbolic Execution: Great [blogpost](https://hackmd.io/@SaferMaker/EVM-Sym-Exec) that gives an overview of the possibilities and tools. - [ ] Formal Verification: using [Certora's CVL](https://docs.certora.com/en/latest/docs/cvl/index.html). This is a more specialized form of verification with overhead and a lot of academic constraints. Not very practical for us to do ourselves but still worth knowing about. - [ ] [Secureum CTF]() - This is a capture-the-flag challenge with 8 common and relevant vulnerabilities. It is probably hard to figure all these out without previous experience working with different token standards, etc. but would totally recommend following along with the solutions and writing the exploits yourself to gain a complete understanding. - [ ] Challenges 1~8 - [ ] Link to the [Solutions](https://ventral.digital/posts/2023/7/16/secureum-a-maze-x-ctf-2023-at-defi-security-summit) ## :small_orange_diamond: Dev: Zero Knowledge - [ ] Small Brain ZK - [ ] When it was first discovered [NYT Article](https://www.nytimes.com/1987/02/17/science/a-new-approach-to-protecting-secrets-is-discovered.html) - [ ] [Zero Knowledge Proofs: An Illustrated Primer](https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/) - [ ] [Plonky2 Tutorial](https://polymerlabs.medium.com/a-tutorial-on-writing-zk-proofs-with-plonky2-part-i-be5812f6b798) - [ ] This really shows that when the math is abstracted away, writing zk programs are the same as writing normal code. - [ ] [Plonky2 Repo](https://github.com/mir-protocol/plonky2) Look at the simple examples here such as quadratic equations or Fibonacci numbers. - [ ] [Big Brain ZK](https://github.com/ventali/awesome-zk) - Compiled list of more academic/research oriented zk resources.