Smart Contracting (cross post)

[Mark S. Miller]

[Something I recently posted to a private discussion.  Perhaps this is
something I should revise and post on the Smart Contracting page of our
website?  Maybe something along these lines should go into the book?
	--MarkM]


If the primary thing I were trying to achieve was money, distributed
capabilities would not be my starting point, for the reasons you and I have
enumerated.  Money merely happens to be a great small example of the issues
that arise in smart contracting.

What do I mean by smart contracting?  I believe all the following is
consistent with Nick's coinage of the term, but probably reflects my
particular passions.

The first smart contracting system was AMIX, the American Information
Exchange.  Here's only a slight idealization of how it worked.

---------------------------------------------------------------------------
When people contracted with each other through the AMIX system, they
expressed the contract in two parts: one that both human and the AMIX
software could understand, and that the AMIX software could enforce; and
the other as free form text only for humans to interpret, but unforgeably
attached to the first part.

For example, Alice and Bob may have committed to a mini-consulting contract
for Bob to deliver to Alice a document answering certain questions Alice
needs answered.  The automated part of the contract might say 

	Alice is to pay Bob $100 on delivery of the deliverable
	Alice is to pay Bob $500 on acceptance of the deliverable
	Alice has 30 days to evaluate the deliverable

The free form text expresses the question Bob is to answer, and that
answers to these questions constitute an acceptable deliverable.

Later, when Bob delivers a document as a deliverable, Bob is making a claim
that this deliverable meets the criteria described.  At this point, Bob is
assured by Amix of receiving the $100, whether or not Amix can collect the
corresponding $100 from Alice.  (Ideally, such a risk-bearing intermediary
would be a separate party from a contract-host, but AMIX bundled these
together.)

When Alice looks at the deliverable, she may hit an "approved" button, in
which case Bob likewise gets $500.  If 30 days go by without Alice taking
any action, then she has implicitly approved, and Bob still gets $500.
Alternatively, Alice may rejects by making a claim that the deliverable
does not meet the description.  This claim directly conflicts with the
claim Bob made by providing the deliverable.  The text of the agreement,
the text of the deliverable, and the two conflicting claims can now go to
human arbitration.
---------------------------------------------------------------------------

This systems lacks *many* of the attributes all of us are interested in
building.  However, it's power came from embodying a complex contractual
relationships in computational material.  This power does not follow just
from having a strongly secure untraceable payment system.

Current contracts are passive pieces of paper, only to be interpreted by
humans.  The phrase "possession is nine tenths of the law" means that who's
got it if the dispute isn't resolved is a huge bias in resolving a dispute,
since arbitration has such huge overheads.

In normal consulting, if Alice doesn't pay Bob, chances are Bob's screwed.
Alice's lack of payment is inaction, not action, and can not obviously be
treated as a factual claim that could be challenged.  Inspired by AMIX, one
might instead say

		Behavior will be nine tenths of the law

If one cannot turn the entire contract into computationally enforced
behavior, one can design a set of computational behaviors that bias the
outcomes, with the remaining non-computational part of the contract being
designed to work in the world produced by those biases.

On the down side, AMIX was a non-distributed insecure system that took a
conventional stance for living within the surrounding legal regimes.  In
particular, AMIX knew the true names of its customers.

AMIX was also non-extensible.  It had one extraordinarily well designed
smart contract, but if customers of AMIX wanted to write new code to embody
a new contractual relationship, AMIX couldn't help them.  (These aren't
criticisms -- AMIX did everything described above in late 80s/early 90s.
It was extraordinary.)

So what am I trying to enable with E?  A good approximation is a strongly
secure, completely decentralized, richly extensible AMIX.  E especially
shines as a language for clearly expressing complex contractual
relationships.  For example, at the Sun Labs Webmart project
http://www.sun.com/960201/cover/webmart.html (one of the ancestors of E) we
created and deployed a lightweight market institution to solve the scarcity
of a rooftop satellite receiver dish.  The dish was bought as a resource
for the lab as a whole.  

Starting with an object representing the ability to control the satellite,
a small amount of code was able to create derivative rights, in layers,
building up to tradable exclusive rights to command the dish during future
time slots.  These rights could be exchanged via reusable escrow exchange
agents and auctions, neither of which knew about futures, much less
satellite dishes.  I expect to be posting simple E code for
escrow-exchange, auctions, futures, etc on the erights site soon.  And I
should probably stop using the money example.

This is a good example for where capabilities simply shine, and we need not
worry about the lack of blinding.  There is only one satellite receiver
dish on the roof of Sun Labs.  There is only one 3pm-4pm on Thursday,
February 4, 1999.  There is no fungibility for blinding to hide behind.

See http://www.agorics.com/agorics/agorpapers.html for many ideas about use
of fine-grained markets in computation.  I believe there's a smooth
spectrum from these, through fully automated contracts with human decisions
-- like the Sun Labs futures market, to the partially automated contracts
of AMIX.

In the Agorics work, the Sun Labs work, and the AMIX work, we didn't pay
that much attention to money per se, and there was still a lot to do to
bring about a computational medium for markets.