Slide 1

Slide 1 text

Credit: Translate/Edit: Shogo Ochiai

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

OVM is a concept which abstract "Fraud Proof" oriented L2 solutions It includes Plasma, State Channel, and "Optimistic" Rollup . ᒜ᧺ ෆਖ਼ᨽ໌ ந৅

Slide 5

Slide 5 text

എܠ Background

Slide 6

Slide 6 text

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] ᒜ᧺ ൵᧺ ൵᧺ ᒜ᧺

Slide 7

Slide 7 text

Common structure of optimistic L2s

Slide 8

Slide 8 text

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]

Slide 9

Slide 9 text

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ᨽ໌ ཁٻ

Slide 10

Slide 10 text

ᗠٞ 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. ᗠٞ ू໿ऀ ཁٻ ᗠٞ ෆਖ਼ ྫࢠ ᒜ᧺

Slide 11

Slide 11 text

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 . . ᒜ᧺ ൵᧺ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌ ᏠᏈੑᨽ໌ ߹๏ੑᨽ໌

Slide 12

Slide 12 text

՝୊ Problems

Slide 13

Slide 13 text

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)

Slide 14

Slide 14 text

OVM

Slide 15

Slide 15 text

ҙঊ 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 ໋୊ ଐੑ ਖ਼䉯ੑ Բஅ อᨽ ہ෦త৘ใ એݴ ଐੑ ࿦ཧه๏

Slide 16

Slide 16 text

"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] ଐੑ ଐੑ એݴ ཁٻ ໋୊

Slide 17

Slide 17 text

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.) ৽֓೦ ৽֓೦ ௨༻ྔࢺ ଘࡏྔࢺ

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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]) ڋ㘺

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Tips: Decider is used in Property. Property builder is shared in L1 and L2. If Plasma, Predicate added

Slide 26

Slide 26 text

For frontend devs, multi language SDK would be provided.

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

Making DApps with ignoring scalability wouldn't go mass adoption OVM first design enables industorial/international mass adoption

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content