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)
Last changed by 
 
Victor Suzdalev
11
108

Read more

How to check the evm script from Aragon vote

We've published a short replit from the script parts we're using for preparing the votes: https://replit.com/@VictorSuzdalev/EVMVoteScriptParser#main.py Checking the evm script Start replit. Open https://replit.com/@VictorSuzdalev/EVMVoteScriptParser#main.py Click big green RUN button at the top. The script will start installing dependencies — this takes couple minutes.

Dec 16, 2021
Untitled

StETH rebase design questions Q: Would stETH be considered a "supply elastic" token (like AMPL where supply might increase/decrease to maintain a target value)? Or do holder balances increment simply as a means of distributing staking rewards? A: StETH isn't "supply elastic" in a sense AMPL is, as it's total supply isn't tied to any specific target value. Total supply & holder balances represent the ETH staked with Lido (funds buffered on the Lido smart contract + funds in deposit queue + the amounts staked with Lido Beacon chain validators). The staking rewards are distributed via rebase of the holder balances. The supply and individual balances do change regularly, though. Total supply and individual balances change when: staking rewards are reported by oracles, changes upwards a bit (limited by 10% APR, so about 0,03% per day). Current settings can be checked on the Oracle interface here: https://mainnet.lido.fi/#/lido-dao/0x442af784a788a5bd6f42a01ebe9f287a871243fb/, and the design for the sanity checks is detailed in the proposal: https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-2.md#sanity-checks-the-oracles-reports-by-configurable-values slashing is reported by oracles, changes downwards, no more than 5% in one day. Never happened. (not implemented) After the merge, when priority fees and MEV earnings are accounted for

Dec 7, 2021
Anchor Vault + BridgeConnectorWormhole audit

Anchor Vault is a smart contract that allows to convert rebasing stETH token into a constant-balance bETH token and periodically send all accrued stETH rewards to the Terra blockchain through a bridge. The bETH token is used as a collateral in the Terra Anchor protocol. The Anchor Vault is deployed & functions already, and was audited by MixBytes() on July, 30th, 2021. The main reason for the audit request is the coming migration from the Shuttle bridge to the Wormhole. The Vault's bridge_connector would be set to BridgeConnectorWormhole contract (to be deployed). Scope of the audit Commit: https://github.com/lidofinance/anchor-collateral-steth/commit/8d52ce72cb42d48dff1851222e3b624c941ddb30 Contracts AnchorVault: https://github.com/lidofinance/anchor-collateral-steth/blob/8d52ce72cb42d48dff1851222e3b624c941ddb30/contracts/AnchorVault.vy (the main vault contract)

Dec 3, 2021
TWAP web interface

The project task is creating a web interface with time-weighted average prices of the specified crypto tokens. Problem Sometimes operations with crypto tokens require time-weighted average price, or TWAP. These numbers usually aren't available off-the-shelf on open APIs, so the custom scripts & calculations are required. Another part of the problem is, the TWAP has to be available & sharable for cross-checks by many different parties. Proposed solution The proposed solution is the web service providing the TWAP data. The raw price data may be acquired on the open sources (coingecko.com API or any other exchange, for instance). The page displaying the data should be sharable by the link. The TWAP params are:

Oct 15, 2021
Read more from Victor Suzdalev
Published on HackMD