Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to OVM

F7a2d3914b17486005a931ca3054b8a2?s=47 sgtn
August 30, 2019

Introduction to OVM

Optimistic Rollup and Hybrid L2s are not included.



August 30, 2019

More Decks by sgtn

Other Decks in Technology


  1. Credit: Translate/Edit: Shogo Ochiai

  2. Background L1 and L2 Plasma, State Channel, and Optimistic Rollup

    Fraud Proof and Validity Proof Problems What matters when we build L2 application ҙঊ Concept ه๏ Syntax Ұ֊ᬓा First-order Logic ᰖࣔ State Channel తࣔྫ Show an example of State Channel Սߏ Architecture Cryptoeconomics Lab References Agenda
  3. Introduction ༬ظతᩇऀ/ड䱾 Expected Reader/Audience You don't need to be a

    master of L2. But it's better if you've tried smart contract development. Person who concerns the scaling issue, but has not convinced to use L2 yet. Person who hesitates to learn Plasma and State Channel. ໨ඪ Goal To somehow understand what is the development on L2 To somehow understand OVM paradigm, and if any, motivated to build L2 DApps զ㘸ॄኄ, ෆ㘸࿩ What I talk and don't talk Talk: The OVM overview which generalize several L2 solutions Eg. Plasma, Stata Channel Talk: How the L2 development would be. Don't: Precise tutorial to build L2 DApps. Deep inside of the implementation.
  4. OVM is a concept which abstract "Fraud Proof" oriented L2

    solutions It includes Plasma, State Channel, and "Optimistic" Rollup . ᒜ᧺ ෆਖ਼ᨽ໌ ந৅
  5. എܠ Background

  6. L1 and L2 L2 is L2 is all about off-loading.

    . There're Optimistic L2 and Pessimistic L2 Optimistic L2: Plasma, State Channel, Optimistic Rollup Pessimistic L2: zk-Rollup Ref[0] ᒜ᧺ ൵᧺ ൵᧺ ᒜ᧺
  7. Common structure of optimistic L2s

  8. A set of users locks coins. Off-chain message passing simply

    represents "State Update" They can claim exiting for any message. But for all NOT(latest and unanimously signed) message is counterclaim-able. State Channel Ұ֊ᬓा First Order Logic ࠷৽ Ұகឆॺ ཁٻ ୀग़ ൓ૌ 㐫ଶߋ৽ message has to have nonce(blockheight) equivalent Ref[4,5]
  9. Plasma Aggregator(Operator) gathers messages(StateUpdates) in the form of blockchain. Aggregator

    sends blockhash(Merkle root of the messages) to the L1. Ref[1,2,3] Clients have to have Merkle proof data to claim. ू໿ऀ մతᄒر Merkleᨽ໌ ཁٻ
  10. ᗠٞ Dispute Optimistic L2 solutions have to be able to

    dispute against invalid claims For example, when a Plasma Operator maliciously tries to claim exiting Alice's coin, Alice has to be able to dispute the claim. ᗠٞ ू໿ऀ ཁٻ ᗠٞ ෆਖ਼ ྫࢠ ᒜ᧺
  11. Fraud Proof and Validity Proof Fraud Proof: "You don't go

    to court to cash a check. You go to court when the check bounces." - Ben Jones Validity Proof: With a bunch of off-loaded state updates, submit a proof of correct execution. No exit game. Optimistic Rollup is a Fraud Proof system Pessimistic Rollup is a Validity Proof system . . ᒜ᧺ ൵᧺ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌
  12. ՝୊ Problems

  13. Challenge of building L2 Client implementations which specialized to Plasma,

    State Channel, and Optimistic Rollup is required. Design and implementation of Exit game Difficulty of confirming security Smart Contract Language, Frontend, Devtools, etc.
 (With highly abstract and modular way of design)
  14. OVM

  15. ҙঊ Concept ҙঊ Concept Optimistic Virtual Machine (OVM): Proposed by

    Plasma Group on July 2019 Ref[8,9] Why "Optimistic"?: Common implementation of all Fraud Proof system Correctness of a Property(Statement) has to be assumed/ guaranteed only by local information. Without touching L1. Each L2 Disputation consist of several assertions (Let's see inside Plasma contract!). And this assertion can be written by Property. We had better use some Logical Syntax. ᏠᏈੑᨽ໌ ᒜ᧺ ᒜ᧺ڏ୅ص PG ໋୊ ଐੑ ਖ਼䉯ੑ Բஅ อᨽ ہ෦త৘ใ એݴ ଐੑ ࿦ཧه๏
  16. "Quantity Concept" added Statement Ұ֊ᬓा First-order Logic (FOL) ྔ ֓೦

    ໋୊ Property has to be written in FOL in OVM. Property would be used as assertions in claim and counterclaim FOL can use statements such that "For all x, it is y.", "There exists x, it is y.", and so on. Ref[15] ଐੑ ଐੑ એݴ ཁٻ ໋୊
  17. Claim: For all cat, they are cute. Counterclaim: Submit a

    non-cute cat. 
 . . Approximately non-cute cat. Ұ֊ᬓा First-order Logic (FOL) New Concept: Universal Quantifier New Concept: Existential Quantifier The cat which has wings ༗ᠯ᡺త䤕 䤕༗ᴍ೉؃ʢୠနવ኷ՄѪʣ Counterclaim: Submit a cat with wings. 
 . . Claim: NOT(There exist a cat with wings.) ৽֓೦ ৽֓೦ ௨༻ྔࢺ ଘࡏྔࢺ
  18. How to write Property for State Channel Exit. 1. Alice

    and Bob open a channel with 10ETH collateral for each. 2. Alice builds a message which sends 2ETH to Bob, signs it, then sends it. 3. Bob confirms the message, signs it, and return it. Now the message has signs of both parties. Bob has to keep the message. 4. Both parties repeat process 2 and 3, then they've satisfied with the result. 5. One of them submits the latest message to contract, then claim exit from the channel. 6. During dispute period, anyone can submit real latest message with all parties' signatures to challenge. The freshness of the message is represented by nonce. ఍ԡ(ਓ࣭) ཁٻ ୀग़ ৽઱ ᬋػᏐ 1/3
  19. How to write Property for State Channel Exit. 2/3 Exit

    Claim consists of a property. ୀग़ཁٻ ଐੑ Where "n" is the nonce of exiting message, n has to be the maximal number among the messages which has signatures of both parties. In Natural Language ༻ࣗવޠݴ Translate to property below via Negation and Existential Quantifier ຋ᩄ ൱ఆ ଘࡏྔࢺ Where "n" is the nonce of exiting message, NOT(There exists a message such that (a nonce is more than n AND has signatures of both parties)) We can translate this property by using universal quantifier. ௨༻ྔࢺ Where "n" is the nonce of exiting message, (For all messages such that nonce more than n) doesn't have signatures of both parties Tips: SQL or Prolog
  20. How to write Property for State Channel Exit. 3/3 Where

    "n" is the nonce of exiting message, (For all messages such that nonce more than n) doesn't have signatures of both parties When this property validated/proven, one can withdrawal a state with nonce n Alice or Bob can reject the property by submitting a message with AND(nonce=n+1, sigs=[SigA, SigB]) ڋ㘺
  21. https://github.com/plasma-group/ovm/issues/4 Checkpoint Claim Spec (Draft)

  22. https://github.com/plasma-group/ovm/issues/4 Exit Claim Spec (Draft)

  23. Building app on OVM is... Designing Properties. L2 Clients (Childchain,

    Channel) are the workbench for proving/rejecting properties. ޻࡞୆ BUT, Plasma's Predicate is different topic. It is an abstraction of the Plasma transaction. OVM is an abstraction of L2 Solutions.
  24. None
  25. Tips: Decider is used in Property. Property builder is shared

    in L1 and L2. If Plasma, Predicate added
  26. For frontend devs, multi language SDK would be provided.

  27. Everything for production OVM What we are building Dev UX

    considered Framework (Discussing) A language for property design (Doing) L1 agnostic Plasma client (Doing) Frontend SDK (Designing)
  28. Making DApps with ignoring scalability wouldn't go mass adoption OVM

    first design enables industorial/international mass adoption
  29. None
  30. None