bitml
play

BitML Stefano Lande Nicola Atzei Roberto Zunino Massimo - PowerPoint PPT Presentation

Jan 16, 2024 •270 likes •626 views

Design and verification of Bitcoin smart contracts with BitML Stefano Lande Nicola Atzei Roberto Zunino Massimo Bartoletti University of Cagliari University of Trento Why smart contracts on Bitcoin? well-understood security of the

  1. Design and verification of Bitcoin smart contracts with BitML Stefano Lande Nicola Atzei Roberto Zunino Massimo Bartoletti University of Cagliari University of Trento

  2. Why smart contracts on Bitcoin? ■ well-understood security of the blockchain ▫ Garay, Kiayias, Leonardos, EUROCRYPT’15 ▫ Kosba, Miller, et al. , IEEE S&P’16 ▫ ... ■ simpler model of computation ▫ Bitcoin: transactions (with minimal scripting) ▫ Ethereum: EVM/Solidity ( ⇒ subtle bugs) ■ basis for other blockchains (e.g. Litecoin) 2

  3. Bitcoin in a nutshell Alice Bob T1 T1 Alice owns 1 BTC Satoshi 3

  4. Bitcoin in a nutshell Alice Bob T1 T2 T1 T2 Alice owns 1 BTC Bob owns 1 BTC Satoshi Alice 4

  5. Bitcoin transactions T1 T2 T in: (T1,1); (T2,3) 5

  6. Bitcoin transactions k x e + e T1 T2 e - e e < e e = e H(e) |e| T versig k ( e ) in: (T1,1); (T2,3) if e then e else e out: 1 BTC: fun(x) . e1 absAfter t:e 2 BTC: fun(y) . e2 relAfter t:e 6

  7. Bitcoin transactions k x e + e T1 T2 e - e e < e e = e H(e) |e| T versig k ( e ) in: (T1,1); (T2,3) if e then e else e out: 1 BTC: fun(x) . e1 absAfter t:e 2 BTC: fun(y) . e2 relAfter t:e absLock: after 2018.12.17 relLock: 2 days after T1 7

  8. Bitcoin scripts: limitations ■ no loops ■ versig ○ only verify signature of the redeeming tx ○ no signatures on arbitrary messages! ■ arithmetic ○ no multiplication / shift (!?) ○ no ops on long numbers (only equality check) ■ no concatenation of bitstrings ■ no checks on the redeeming tx (only versig) 8

  9. Smart contracts in Bitcoin ◎ Smart contracts allow to specify “programmable” rules to transfer currency ◎ They are implemented in Bitcoin cond as cryptographic protocols, exploiting the advanced features of transactions 9

  10. A sample of Bitcoin contracts ■ Oracles ■ Escrow and arbitration ■ Fair multi-player lotteries ■ Gambling games (Poker, ...) ■ Crowdfunding ■ Micropayments channels (“Lighting network”) ■ Contingent payments (via ZK proofs) ■ … 10

  11. Example: timed commitment Problem : when playing a game, if A makes public her move first, then B can choose a countermove which makes him always win ◎ A wants to commit a secret s , but reveal it some time later ◎ B wants to be assured that he will either: ○ learn A’s secret within time t ○ or be economically compensated [Andrychowicz et al . 2014] 11

  12. Example: timed commitment Commit ◎ A chooses secret out: 1 BTC: fun x σ . s and broadcasts ( H(x)= h and ver A ( σ ) ) or afterAbs t: ver B ( σ ) h =H( s ) 12

  13. Example: timed commitment Commit ◎ A chooses secret out: 1 BTC: fun x σ . s and broadcasts ( H(x)=h and ver A ( σ ) ) or afterAbs t: ver B ( σ ) h =H( s ) ◎ A can get 1 BTC by revealing s Reveal before time t wit: s sig A ( Reveal ) 13

  14. Example: timed commitment Commit ◎ A chooses secret out: 1 BTC: fun x σ . s and broadcasts ( H(x)=h and ver A ( σ ) ) or afterAbs t: ver B ( σ ) h =H( s ) ◎ A can get 1 BTC by revealing s Timeout before time t wit: * sig B ( Timeout ) ◎ B can get 1BTC if absLock: t A does not reveal s by time t 14 14

  15. Problems ■ writing Bitcoin contracts is hard ▫ no programming language ▫ contracts usually described as “endpoint” protocols: ▫ send / receive messages ▫ scan blockchain / append transactions ▫ low-level & poorly documented features ▫ scripts, SegWit, signature modifiers, ... ■ no formal specification ⇒ no automatic verification 15

  16. 16

  17. Bitcoin contracts in prose 17

  18. BitML: Bitcoin Modelling Language [B. & Zunino, ACM CCS’18] ■ contracts are programs ○ high-level specification of global behaviour ○ abstract from low-level details (e.g. transactions) ■ 3-phases workflow: ○ advertisement : someone broadcasts the contract and the required preconditions (deposits, secrets) ○ stipulation : participants decide whether to accept the contract, by satisfying its preconditions ○ execution : participants perform actions, which must respect the contract logic ■ compiler : BitML → standard Bitcoin transactions 18

  19. BitML syntax contract C ::= D 1 + ⋯ + D n D ::= guarded contract withdraw A transfer bal to A split v 1 → C 1 | ⋯ |v n → C n split balance A : D wait for A’s auth after t : D wait until time t put x . C collect deposits x reveal a if p . C reveal secrets a 19

  20. A basic example Precondition: A must put a 1 ฿ : {A:!1 ฿ } Contract: PayOrRefund = A:withdraw B + B:withdraw A Problem: if neither A nor B give their authorization, the 1 ฿ deposit is frozen 20

  21. Mediating disputes (with oracles) Resolve disputes via a mediator M (paid 0.2 ฿ ) Escrow = PayOrRefund + A:Resolve + B:Resolve Resolve = split 0.2 ฿ → withdraw M 0.8 ฿ → M:withdraw A + M:withdraw B | 21

  22. Timed commitment {A:!1 ฿ | A:secret a} TimedC = reveal a. withdraw A + after t : withdraw B 22

  23. A 2-players lottery (wrong version) {A:!1 ฿ | A:secret a | B:!1 ฿ | B:secret b} reveal a b if |a|=|b|. withdraw A + reveal a b if |a|≠|b|. withdraw B 23

  24. A 2-players lottery (almost there…) {A:! 3 ฿ | A:secret a | B:! 3 ฿ | B:secret b} split 2 ฿ → reveal b . withdraw B + after t : withdraw A |2 ฿ → reveal a . withdraw A + after t : withdraw B |2 ฿ → reveal a b if |a|=|b|. withdraw A + reveal a b if |a|≠|b|. withdraw B 24

  25. A 2-players lottery (fair version) {A:!3 ฿ | A:secret a | B:!3 ฿ | B:secret b} split 2 ฿ → reveal b if 0≤|b|≤1 . withdraw B + after t : withdraw A |2 ฿ → reveal a . withdraw A + after t : withdraw B |2 ฿ → reveal a b if |a|=|b|. withdraw A + reveal a b if |a|≠|b|. withdraw B 25

  26. Symbolic vs computational model Symbolic BitML smart contracts Computational Bitcoin smart contracts 26

  27. Preserving security upon compilation Theorem (Computational soundness) : For each computational run, there exists a corresponding symbolic run (with overwhelming probability) ◎ Computational attacks are also observable at the symbolic level. ◎ A tool can be used to verify security properties at the symbolic level 27

  28. Liquidity of contracts A:B:withdraw C + A:B:withdraw D Problem: A and B must agree on the recipient of the donation, otherwise the funds are frozen ⇒ not liquid 28

  29. Liquidity of contracts {A:!1 ฿ | A:secret a} reveal a. withdraw A + after t : withdraw B ◎ A can reveal her secret ⇒ liquid ◎ B can delay until time t ⇒ liquid 29

  30. Verifying liquidity for all finite runs R1 (conforming to A’s strategy) there exists some extension R2 of R1 (conforming to A’s strategy) such that R2 : 1. has no authorizations/reveals of any B ≠ A 2. has no active contracts Th : liquidity is decidable in BitML 30

  31. WIP: A toolchain for design and verification Contract Contract + Strategy model BitML Model Liquidity compiler checker Bitcoin transactions + Strategy Execution client 31

  32. Thank you 32

  33. A formal ecosystem for Bitcoin smart contracts Symbolic BitML BitML verification BitML compiler [Submitted] [CCS18] Contracts as Formal model of Computational Balzac endpoint protocols Bitcoin transactions [POST18] [FC18] 33

  34. Timed commitment (output of the BitML compiler) 34

Recommend

More recommend