The Electronic Rights Transfer Protocol

1. Mark S. Miller Open Source Coordinator, ERights.org CTO, Combex Inc. PhD. student, Johns Hopkins University The Electronic RightsTransfer Protocol

2. Talk Overview • Our rights-handling systems are badly broken. Failures of layering and composition • What should a solution look like? Decentralized networks of contracts-as-games • What are adequate building blocks? CapTP: Distributed cryptographic capabilities • Capabilities vs. trade of erights exclusive, bilateral, 3rd party assayable, fungible

3. Layering Failure Expedia Custom ACLs --disconnect-- Unix or NT ACLs The “single sign-on problem” is just a symptom

4. Composition Failure vs.

5. Smart Contracts • Contract as Program Code • Terms partially enforced by program’s execution • Inescapable arrangement vs. punishment. • Contract host == trusted escrow & enforcer • Vending machine example • Nick Szabo’s http://szabo.best.vwh.net/ • Lessig’s “Code and other Laws of Cyberspace” • Our “Capability-based Financial Instruments” at FC’00,and “The Digital Path” at Austrian Perspectives on.. 2001.

6. Contracts as Board Games • Players make moves, but only “legal” ones • Move changes state of board • Board-state determines move “legality” • ERights are “pieces” placed on board • Game escrows pieces, • Pieces/ERights released only by play

7. A Simple Exchange Game

8. Separation of Duties

9. The Game Design Game • Contract Negotiation as Game Design • Framework as the Game of Game Design • Design rules for game all are willing to play • Write “board manager” for that game • Agree on a mutually trusted host • Pay host to run the board manager • Host verifies everyone agreed on same game

10. A Covered Call Option

11. Contract CompositionCreates Virtual Property

12. What Are Object-Capabilities? • By Introduction • ref to Carol • ref to Bob • decides to share • By Parenthood • By Construction • By Initial Conditions Alice says:bob.foo(carol) • Absolute Encapsulation • Only source of authority

13. Object Capability Message Vat Process / Machine CapTP: Capability Transport Protocol

14. Solving BothImpostor Problems A false Carol doesn't know the Vat private key. A false Bob doesn't knowthe SwissNumber.

15. From Capabilities to trading erights • Shared • One-way asynch • Opaque • Specific • Often exclusive • 2-way all-or-nothing • 3rd party assayable • Often fungible

16. Distributed Cap Example: Money def makeMint(name :String) :any { def [sealer, unsealer] := makeBrandPair(name) def mint { to makePurse(var balance :(int >= 0)) :any { def decr(amount :(0..balance)) { balance -= amount } def purse { to getBalance() :int { balance } to sprout() :any { mint.makePurse(0) } to getDecr() :any { sealer.seal(decr) } to deposit(amount :int, src) { unsealer.unseal(src.getDecr())(amount) balance += amount } } } } } Almost erights,but not 3rd party assayable.

17. The Essential ERTP • interface Issuer { • to vouchForAssay(candidate :Assay) :Assay • to makeEmptyPurse() :Purse • # subtypes will usually provide a • # to makeAssay(description...) :Assay • } • interface Assay { • to transfer(src :Purse, dest :Purse) • # subtypes will usually provide some form of • # to getDescription() :... • } • interface Purse {}

18. Mutual Acceptability by “Equality” Contract Host says: def issuerB := E.join(bAccordingToAlice, bAccordingToBob)

19. Mutual Acceptability by “Equality” Contract Host says: def issuerB := E.join(bAccordingToAlice, bAccordingToBob)

20. Putting a Piece on the Board Bob says: host.place(argPurse, argAssay)

21. Putting a Piece on the Board Contract Host says: def assayB := issuerB.vouchForAssay(argAssay) purseB := issuerB.makeEmptyPurse() assayB.transfer(argPurse, purseB)

22. Putting a Piece on the Board Alice asks “What's that piece?” Contract Host responds: assayB

23. ERTP Summary • Intermediaries manipulate erights they don't understand • No prior knowledge or trust in Issuers • Exclusive? Fungible? Perishable? Blinded Transfer? The Contract Host Needn't Care • 3rd party assayability enables mutual acceptability to Alice and Bob, who care about these specifics.

24. Conclusions • ERTP is but one example of the power of Object-Capability protocol design. • Patterns of Cooperation Without Vulnerability • Field is wide open with fresh opportunities.

26. The Analog Analogy Messy Computer Hardware Unlimited need fornew logic Abstraction Funnel Messy Analog Analog circuit design is hard

27. Abstraction FunnelsExample: digital logic as a simple, highly reusable set of analog circuit designs • Preserves source of much power universality, parallelism • Abstracts away distracting features AC analysis, sine waves, complex numbers, ... • In-model causality only on provided paths unidirectional bit-wires • Composability; signal interoperability A bit from an ALU is good as a bit to a register

28. Why CapTP? Messy Commerce Unlimited need fornew contracts Crypto Object-Capabilities Messy Crypto Crypto protocol design is hard

29. A Simple, Highly ReusableCrypto Protocol: CapTP • Preserves source of much power Cooperation without vulnerability • Abstracts away distracting features Cryptographic protocol design • In-model causality only on provided paths Encapsulation, message passing • Composability; signal interoperability Message passing, polymorphism

30. Other Capability Paradigms Capabilities as Rows Capabilities as Keys/Tickets • “Capability Myths Demolished” • Equivalence? Revocability? Confinement? • http://zesty.ca/capmyths/usenix.pdf