html5-img
1 / 100

September 2019

The K Approach a nd Vision. Grigore Rosu Professor of CS, University of Illinois at Urbana President & CEO, Runtime Verification Inc. September 2019. Goals. Make K the best ever design, implementation and formal reasoning framework for programming languages!

jonco
Télécharger la présentation

September 2019

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The K Approach and Vision Grigore Rosu Professor of CS, University of Illinois at Urbana President & CEO, Runtime Verification Inc. September 2019

  2. Goals • Make K the best ever design, implementation and formal reasoning framework for programming languages! • To work with all programming languages • Aim for an ideal solution long term, but focus on and productize blockchain specific tools short term, via SaaS • Firefly: automated tool for Ethereum code analysis • KaaS: K (formal verification of smart contracts) as a service • Proof objects as 3rd-party checkable correctness certificates • K-powered blockchain: blockchain of truth • Smart contracts in any programming language formalized in K • Or better, smart contracts directly as executable K specifications • Computation = proof: builtin proof checker will ensure valid computations and correctness claims on the blockchain

  3. What is ?

  4. Ideal Language Framework Vision … Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Model checker Compiler Symbolic execution (semantic) Debugger

  5. Current State-of-the-Art- Sharp Contrast to Ideal Vision - Separate tools, by separate teams, little to no code shared C Interpreter Java Compiler Model Checker JavaScript Solidity Symbolic Execution Ethereum VM Deductive Verifier … …

  6. Current State-of-the-Art- Sharp Contrast to Ideal Vision - The story of the PL/FM community. Maintenance hell (L * T systems). Uneconomical. Wasted talent! T L C Interpreter Java Compiler Model Checker JavaScript Solidity Symbolic Execution Ethereum VM Deductive Verifier … …

  7. How It Should Be Ideal Language Framework C Interpreter Java Compiler Model Checker JavaScript Solidity Symbolic Execution Ethereum VM Deductive Verifier … …

  8. K Frameworkhttp://kframework.org • We tried various semantic styles, for >15y and >100 top-tier conference and journal papers: • Small-/big-step SOS; Evaluation contexts; Abstract machines (CC, CK, CEK, SECD, …); Chemical abstract machine; Axiomatic; Continuations; Denotational;… • But each of the above had limitations • Especially related to modularity, notation, verification • K framework initially engineered: keep advantages and avoid limitations of various semantic styles • Then theory came

  9. Complete K Definition of KernelC

  10. Complete K Definition of KernelC Syntax declared using annotated BNF …

  11. Complete K Definition of KernelC Configuration given as a nested cell structure. Leaves can be sets, multisets, lists, maps, or syntax

  12. Complete K Definition of KernelC Semantic rules given contextually Semantic rules given contextually rule <k> X = V => V …</k> <env>… X |-> (_ => V) …</env> rule k: X = V => V … env: … X |-> (_ => V) …

  13. K Scales Several large languages were recently defined in K: • JavaScript ES5: by Park etal[PLDI’15] • Passes existing conformance test suite (2872 programs) • Found (confirmed) bugs in Chrome, IE, Firefox, Safari • Java 1.4: by Bogdanasetal[POPL’15] • x86: by Dasgupta etal[PLDI’19] • C11: Ellison etal[POPL’12, PLDI’15] • 192 different types of undefined behavior • 10,000+ program tests (gcc torture tests, obfuscated C, …) • Commercialized by startup (Runtime Verification, Inc.) + EVM [CSF’18], Solidity, IELE [FM’19], WASM, Vyper, …

  14. K Configuration and Definition of C 120 Cells! … plus ~5000 rules …

  15. Ideal Language Framework Vision [K] … Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Model checker Compiler Symbolic execution (semantic) Debugger

  16. Concrete Execution Backend 1. Translate K def to OCAML/LLVM2. Compile OCAML/LLVM to x86 Code (6-int-overflow.c) • RV-Match: Commercial tool • Instance of K concrete execution with C lang • Automatic debugger for subtle bugs other tools can't find, with no false positives • Seamless integration with unit tests, build infrastructure, and continuous integration • Platform for analyzing programs, boosting standards compliance and assurance Conventional compilers do not detect problem RV-Match’s kcc tool precisely detects and reports error, and points to ISO C11 standard

  17. RV-Match on Toyota ITC Benchmark- Comparison with Static Analysis Tools - [CAV’16] DR: Percent of programs with defects where defects are reported FPR: Percent of programs without defects, with defects incorrectly reported; FPR = 100 - FPR PM: Productivity metric:

  18. RV-Match on Toyota ITC Benchmark- Comparison with Other Analysis Tools - DR: Percent of programs with defects where defects are reported FPR: Percent of programs without defects, with defects incorrectly reported; FPR = 100 - FPR PM: Productivity metric:

  19. From RV-Match to Blockchain • RV-Match currently commercialized within • The same technology, K, used for defining blockchain languages: EVM, IELE, WASM, …

  20. Ideal Language Framework Vision [K] … Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Model checker Compiler Symbolic execution (semantic) Debugger

  21. State-of-the-Art • Redefine the language using a different semantic approach (Hoare/separation/dynamic logic) • Language specific, non-executable, error-prone

  22. What We Want Deductive program verifier • Use directly the trusted language model/semantics! • Language-independent proof system • Takes operational semantics as axioms • Derives reachability properties • Sound and relatively complete for all languages! Formal Language Definition (Syntax and Semantics) Symbolic execution

  23. Matching Logic […, LICS’13, RTA’15, OOPSLA’16, FSCD’16, LMCS’17, LICS’19] Patterns (of each sort s) Structure Constraints Binders

  24. Matching Logic Models Patterns interpreted as sets (all elements that match them)  as complement,  as intersection,  as union over all x

  25. Matching Logic Proof System First-Order Logic Language-agnostic. Sound and complete C (1,…, i-1,□, i+1,…, n) Technical (completeness) Local reasoning

  26. Matching -Logic [ LICS’19 ] • Adding support for recursion / induction

  27. Matching -Logic [ LICS’19 ] 16 proof rules only! Simple proof checker (<200 LOC, vs Coq’s 8000)!

  28. Expressiveness • Important logics for program reasoning can be framed as matching logic theories / notations • First-order logic • Equality, membership, definedness, partial functions • Lambda / mu calculi (least/largest fixed points) • Dependent types (Coq) • Modal logics • Hoare logics • Dynamic logics • LTL, CTL, CTL* • Separation logic • Reachability logic • … x.e x.0(x,e) (x.e)e’ = e[e’/x]

  29. Expressiveness of Matching -Logic

  30. Reachability Logic (Semantics of K)[LICS’13, RTA’14, RTA’15,OOPLSA’16] • “Rewrite” rules over matching logic patterns: • Patterns generalize terms, so reachability rules capture rewriting, that is, operational semantics • Reachability rules capture Hoare triples • Sound & relative complete proof system • Now proved as matching -logic theorems Can be expressed in matching logic:   (’)  is “weak eventually” [FM’12] 

  31. K = (Best Effort) Implementation of RL • Reachability logic implemented in K, generically • Evaluated it with the existing semantics of C, Java, JavaScript, EVM, and several tricky programs • Morale: • Performance is comparablewith language-specific provers! EVM Solidity Vyper WASM …

  32. Sum 1+2+…+n in IMP: Main

  33. Sum 1+2+…+n in IMP: Invariant

  34. OK Performance Time (seconds) spent on applying semantic steps (symbolic execution) Time (seconds) spent on domain reasoning (matching logic + querying Z3) • [OOPLSA’16] • Properties very challenging to verify automatically. We only found one such prover for C, based on a separation logic extension of VCC • Which takes 260 sec to verify AVL insert (ours takes 280 sec; see above)

  35. for the Blockchain

  36. Goals • Make K the best ever design, implementation and formal reasoning framework for programming languages! • To work with all programming languages • Aim for an ideal solution long term, but focus on and productize blockchain specific tools short term, via SaaS • Firefly: automated tool for Ethereum code analysis • KaaS: K (formal verification of smart contracts) as a service • Proof objects as 3rd-party checkable correctness certificates • K-powered blockchain: blockchain of truth • Smart contracts in any programming language formalized in K • Or better, smart contracts directly as executable K specifications • Computation = proof: builtin proof checker will ensure valid computations and correctness claims on the blockchain

  37. K Framework Vision … Deductive program verifier Parser Interpreter Blockchain Language Definition Formal Language Definition (Syntax and Semantics) Model checker Compiler Symbolic execution (semantic) Debugger

  38. KEVM: Semantics of the Ethereum Virtual Machine (EVM) in K • [CSL’18] Complete semantics of EVM in K • https://github.com/kframework/evm-semantics • Passes 60,000+ tests of C++ reference implementation • Faster than ethereumjs; 5x (only!) slower than ethereum-cpp • Used as canonical EVM spec (replacing Yellow Paper)

  39. What Can We Do with KEVM? 1) Formal documentation: http://jellopaper.org

  40. What Can We Do with KEVM? 2) Generate and deploy correct-by-construction EVM client/simulator/emulator Firefly tool: KEVM to run, analyze and generate tests Cardanotestnet: mantis executing KEVM

  41. What Can We Do with KEVM? 3) Formally verify Ethereum smart contracts RV does that commercially. Won first Ethereum Security grant to verify Casper, then hired to formalize Beacon Chain (Serenity) and verify ETH1 -> ETH2 deposit contract [ FSE’18 ]

  42. Formalizing ERC20, ERC777, … in K • K is very expressive for modeling: languages, but also token specifications and protocols; executable • To formally verify smart contracts, we also formalized token specifications, multisigs, etc.: • ERC20, ERC777, many others • All our specs are language-independent! • i.e., not specific to Solidity, not even to EVM • We had the first verified ERC20 contracts! • Written both in Solidity and in Vyper, verified as EVM • Others use or integrate our framework and specs: • DappHub (KLab), ETHWorks (Waffle), Consensys, Gnosis

  43. Smart Contract Verification Workflow 1 ERC20 Informal Business Logic [transfer] callData: #abiCallData("transfer", #address(TO_ID), #uint256(VALUE)) gas: {GASCAP} => _ refund: _ => _ requires: andBool 0 <=Int TO_ID andBool TO_ID <Int (2 ^Int 160) andBool 0 <=Int VALUE andBool VALUE <Int (2 ^Int 256) andBool 0 <=Int BAL_FROM andBool BAL_FROM <Int (2 ^Int 256) andBool 0 <=Int BAL_TO andBool BAL_TO <Int (2 ^Int 256) [transfer-success] k: #execute => (RETURN RET_ADDR:Int 32 ~> _) localMem: .Map => ( .Map[ RET_ADDR := #asByteStackInWidth(1, 32) ] _:Map ) log: _:List ( .List => ListItem(#abiEventLog(ACCT_ID, "Transfer", #indexed(#address(CALLER_ID ………. ……… ……. ERC20-K formal executable high-level spec 2 • Formalize • Refine rule transfer(T, V) => true caller: F account: id: F balance: BF => BF - V account: id: T balance: BT => BT + V log: . => Transfer(F,T,V) requires 0 <= V /\ V <= BF /\ BT + V <= MAXVALUE ERC20-EVM formal executable low-level spec that contains all EVM details 3

  44. Notable Contracts We’ve Verified • ETH2.0 Deposit • GnosisSafe • Ethereum Casper FFG • Uniswap • DappSysDSToken ERC20 • Bihu KEY token

  45. Designing New (and Better) Blockchain Languages Using K

  46. EVM Not Human Readable(among other nuisences) If it must be low-level, then I prefer this: definepublic @sum(%n) { %result = 0 condition: %cond = cmple %n, 0 br %cond, after_loop %result = add %result, %n %n = sub %n, 1 brcondition after_loop: ret %result }

  47. A New Virtual Machine (and Language) for the Blockchain • Incorporates learnings from defining KEVM and from using it to verify smart contracts • Register-based machine, very similar to LLVM • IELE was designed and implemented using formal methods and semantics from scratch! • Until IELE, only existing or toy languages have been given formal semantics in K • Not as exciting as designing new languages • We should use semantics as an intrinsic, active language design principle, not post-mortem

  48. K Semantics of OtherBlockchain Languages • WASM (web assembly) – in progress, in collaboration with the Ethereum Foundation • Solidity – in progress, collaboration between RV and Sun Jun’s group in Singapore • Vyper – in progress, collaboration with the Ethereum Foundation • Plutus (functional) – collaboration with IOHK (2018) • Bamboo (linear types) – in progress, collaboration with DapperLabs (creators of CryptoKitties) …

  49. Modelling and Verification ofBlockchain Protocols • Matching logic, rewriting and K can also be used to formally specify and verify consensus protocols, random number generators, etc. • Done or ongoing: • Casper FFG (Ethereum Foundation) • RANDAO (Ethereum Foundation) • Algorand (Algorand) • Casper CBC (Coordination Technology) • Serenity / ETH 2.0 (Ethereum Foundation) • Several others planned or in discussions

  50. K Blockchain Products and Toolsin the Making. To be SaaS delivered Firefly – automated smart contract analysis KaaS – K formal verification as a service Proof objects – ultimate correctness certificates

More Related