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
- Hi I'm Eugene from LoE
- Disclaimer: this is not "how to solidity securely" kind of talk — that's covered way better elsewhere; what should the team do above that?
- I'm from Lido on Ethereum: 7.5m ETH staked, 32% of the staked ETH so far
- 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
- 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)
- Smart contract zoo: multiple solidity versions (thank you Aragon), three access models ("owner", Aragon ACL & OZ ACL)
- How to upgrade? Voting based on EVM scripts + upgrade template contract
- Upgrade timeline
- Nov — start for real
- Feb — V2 Snapshot
- AUDITS
- Late March — April — testnet
- May — onchain upgrade
- 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
- Protocol Security Layered Cake (picture for inspiration The Paramount Importance of Data Protection: Pyramid Security)
- People
- Hiring
- Paranoia culture
- Security champion
- Ownership
- Key management & opsec
- Incident handling practices
- Protocol Design
- Sophisticated actor-resistant design
- Mindful of griefing
- Design is a balance between security & UX
- 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
- Testing
- Acceptance testing on the mainnet-fork
- Formal verification & fuzzing
- Testnet runs: for internal checks & for partners
- External security
- DAO Ops
- Transparency & verifiability
- Monitoring and safeguards
- Forta
- Emergency brakes & GateSeal
- On-call, incident policy & practices
- Radical transparency
- Postmortems
- Public everything
- Don't rely upon secrets being secret (no EOAs in the design, safety checks & self-expiring access)