Try   HackMD

Goal: show off the Lido on Ethereum security practices; share insights & gotchas we've discovered / employed so far in the process of making scary changes and operation safe(-ish)

Outline

20m — tight timeline

  1. Hi I'm Eugene from LoE
  2. Disclaimer: this is not "how to solidity securely" kind of talk — that's covered way better elsewhere; what should the team do above that?
  3. I'm from Lido on Ethereum: 7.5m ETH staked, 32% of the staked ETH so far
  4. What is Lido v2? (v1 + staking router and withdrawals) (this slide gives the audience a helicopter view what is lido and quick intro about v1 -> v2 upgrade)
    • V2 features = 2* V1 features
    • V2 code = 3* V1 code
  5. The migration has to be single transaction (no way for a soft launch; proxies, ownership, DAO vote, whatnot) (AAVE decided not to do automatic V2->V3 liquidity migration; every Uniswap "upgrade" is new pools with no liquidity; we don't have that option)
  6. Smart contract zoo: multiple solidity versions (thank you Aragon), three access models ("owner", Aragon ACL & OZ ACL)
  7. How to upgrade? Voting based on EVM scripts + upgrade template contract
  8. Upgrade timeline
    • Nov — start for real
    • Feb — V2 Snapshot
    • AUDITS
    • Late March — April — testnet
    • May — onchain upgrade
  9. Stories from the trenches
    • How to spec safe protocol
      • Main "adversary" one's planning against — sophisticated actors (look at mempool design and the whole MEV industry)
      • 80% research / code goes towards edge-cases
    • On/off chain design: trust-minimized oracles
      • Not "well-checked and trusted", but have tight safety checks in onchain code (asymptotical bounds)
    • GateSeal
      • How to expect the unexpected (and not give outthe keys from town to strangers)
    • Surviving multiple audits
      • Cadence
      • Dedicated "audits manager" from our side
      • WOW it's way better to space things and not go this way
    • How to prepare the DAO motion (diffyscan & deployment play)
      • Dev team prepares the upgrade. How to spot their mistakes? How to prevent them from being approved & enacted by the DAO?
        • Dev team publishes upgrade plan in the open for the challenge (we ran yet-to-be-deployed code bounty with Immunefi)
        • Audit the deployment!
          • Check the template & all the hardcoded values: addresses & constants
          • Space to improve: the whole upgrade is in the template
        • Paranoia in the DAO Ops
          • show 'em minimal blockchain action checklist
          • org: two pilots & everything is transparent & explained beforehand
          • acceptance blcochain fork tests for the protocol before/after the vote(s)
          • test your upgrade as early as possible, it'll save you grey hair later (costed us some for sure)
    • Certora is awesome: formal verification, "invariant-based thinking" and deep digging
      • Very experient team; co-authors, and not just auditors
      • Invariants list helps to iterate on the code faster
      • Having to think in invariants improves the dev culture in the whole team
  10. Protocol Security Layered Cake (picture for inspiration The Paramount Importance of Data Protection: Pyramid Security)
    1. People
      • Hiring
      • Paranoia culture
      • Security champion
      • Ownership
      • Key management & opsec
      • Incident handling practices
    2. Protocol Design
      • Sophisticated actor-resistant design
      • Mindful of griefing
      • Design is a balance between security & UX
    3. Smart Contract Implementation incl. internal review
      • Use industry standarts
      • KISS all the way down
      • Optimize only after code AND the test suite is here
      • Have internal review culture
    4. Testing
      • Acceptance testing on the mainnet-fork
      • Formal verification & fuzzing
      • Testnet runs: for internal checks & for partners
    5. External security
      • Audits
      • Bug bounties
    6. DAO Ops
      • Transparency & verifiability
    7. Monitoring and safeguards
      • Forta
      • Emergency brakes & GateSeal
      • On-call, incident policy & practices
    8. Radical transparency
      • Postmortems
      • Public everything
      • Don't rely upon secrets being secret (no EOAs in the design, safety checks & self-expiring access)