[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.
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.