The Electronic Rights
Transfer Protocol
Contract Host #1
$ Issuer
Stock
Issuer
ns
io r
pt e
O ssu
I
Alice
Bob
Mark S. Miller
Open Source Coordinator, ERights.org
CTO, Combex Inc.
PhD. student, Johns Hopkins University
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
Layering Failure
Expedia
Custom ACLs
--disconnect-Unix or NT ACLs
The “single sign-on problem”
is just a symptom
Composition Failure
vs.
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.
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
A Simple Exchange Game
Separation of Duties
$ Issuer
Stock Issuer
Contract Host
Alice
Bob
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
A Covered Call Option
Contract Composition
Creates Virtual Property
Contract Host #1
Stock
Issuer
$ Issuer
ns
io r
pt e
O I ssu
Alice
Bob
nt
Co
ra
ct
t
os
H
#2
$
Is
su
er
Fr
ed
What Are Object-Capabilities?
By Introduction
●
ref to Carol
•
ref to Bob
•
decides to share
Alice says:
bob.foo(carol)
•
By Parenthood
●By Construction
●By Initial Conditions
●
Absolute Encapsulation
● Only source of authority
●
CapTP: Capability Transport Protocol
Object
Capability
Message
Vat
Process /
Machine
Solving Both
Impostor Problems
A false Carol doesn't know
the Vat private key.
A false Bob doesn't know
the SwissNumber.
From Capabilities to trading erights
Bob
Bob
Carol
Alice
Alice
Shared
● One-way asynch
● Opaque
● Specific
●
Often exclusive
● 2-way all-or-nothing
rd party assayable
● 3
● Often fungible
●
Distributed Cap Example: Money
Almost erights,
but not 3rd party assayable.
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
}
}
}
}
}
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 {}
Mutual Acceptability by “Equality”
Contract Host says:
def issuerB := E.join(bAccordingToAlice,
bAccordingToBob)
Mutual Acceptability by “Equality”
Contract Host says:
def issuerB := E.join(bAccordingToAlice,
bAccordingToBob)
Putting a Piece on the Board
Bob says:
host.place(argPurse, argAssay)
Putting a Piece on the Board
Contract Host says:
def assayB :=
issuerB.vouchForAssay(argAssay)
purseB := issuerB.makeEmptyPurse()
assayB.transfer(argPurse, purseB)
Putting a Piece on the Board
Alice asks “What's that piece?”
Contract Host responds: assayB
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.
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.
The Analog Analogy
Messy Computer Hardware
Unlimited need for
new logic
Abstraction Funnel
Messy Analog
Analog circuit design is hard
Abstraction Funnels
Example: 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
Why CapTP?
Messy Commerce
Unlimited need for
new contracts
Crypto Object-Capabilities
Messy Crypto
Crypto protocol design is hard
A Simple, Highly Reusable
Crypto 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
Other Capability Paradigms
Capabilities as Rows
Capabilities as Keys/Tickets
“Capability Myths Demolished”
Equivalence? Revocability? Confinement?
http://zesty.ca/capmyths/usenix.pdf