[e-cvs] cvs commit: e/doc/talks/pisa/paper index.html
markm@eros.cs.jhu.edu
markm@eros.cs.jhu.edu
Fri, 28 Dec 2001 11:59:20 -0500
markm 01/12/28 11:59:20
Modified: doc/talks/pisa/paper index.html
Log:
more
Revision Changes Path
1.17 +57 -39 e/doc/talks/pisa/paper/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/talks/pisa/paper/index.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- index.html 2001/12/28 16:15:56 1.16
+++ index.html 2001/12/28 16:59:20 1.17
@@ -390,6 +390,10 @@
at that point [<font color="#000000"><a href="#Miller00">Miller00</a>]</font>.
The terms of the contract are enforced by the contract itself -- by the
behavior of the contract when executed as a program.</p>
+ <p><font color="#000000">(The vending machine is partially and asymmetrically
+ trusted, as both parties know that it is ultimately an agent only of the
+ drink manufacturer. Other smart contract scenarios involve more symmetric
+ mutually trusted third parties.)</font></p>
<p>Although conventional coercive recourse is still often possible on the
Net, for more and more Net commerce these costs are too great, and the
jurisdictional issues potentially too messy. Instead, Net businesses have
@@ -401,14 +405,14 @@
with the value of their reputation capital. Such arragements are messier
and less amenable to automation than escrow, but they do substantially
reduce capital costs. Both kinds of arrangements have their place and
- will compete in the market. Here, I will explore escrow-based smart contracts,
- not because I expect this form to dominate, but because their logic is
- vastly easier to explain; because they're easier to build, and so will
- occur sooner; and because they apply to participants with no prior reputation,
- which helps for bootstrapping the transition. Likewise, for the electronic
- systems of title (or <i>issuers</i> below), in this paper I assume systems
- that provide for instant settlement [<a href="#e-gold">e-gold</a>]. Although
- delayed settlement may substantially reduce capital costs [<a href="#Selgin01" target="_top">Selgin01</a>],
+ will compete in the market. In this paper we explore escrow-based smart
+ contracts, not because we expect this form to dominate, but because their
+ logic is vastly easier to explain; because they are easier to build, and
+ so will occur sooner; and because they apply to participants with no prior
+ reputation, which helps for bootstrapping the transition. Likewise, for
+ the electronic systems of title (called <i>issuers</i> below), in this
+ paper we assume systems that provide for instant settlement [<a href="#e-gold">e-gold</a>].
+ Although delayed settlement may substantially reduce capital costs [<a href="#Selgin01" target="_top">Selgin01</a>],
they turn smart contracts into explosions of complexity.</p>
<h3><font color="#000000"><img src="images/4-exchange.gif" width="390" height="266" align="right"></font>Contracts
as Games</h3>
@@ -452,41 +456,55 @@
in Figure 5. The two players of course, Alice and Bob. The contract host
serves the same role as our vending machine -- it is the third party mutually
trusted to execute the contract/program faithfully. The contract can be
- any program Alice and Bob mutually agree on, written in a safe language
- suitable for writing smart contracts, that functions as the <i>board manager</i>
- for the game they have agreed to play. (A <i>board manager</i> for, for
- example, chess, is a program that enables two people to play with each
- other, maintains the board state, and only allows legal moves. A board
- manager does not itself play the game.)</font></p>
+ any program Alice and Bob mutually agree on, written in a capability language
+ (a secure programming language suitable for writing smart contracts),
+ that functions as the <i>board manager</i> for the game they have agreed
+ to play. (A <i>board manager</i> for, for example, chess, is a program
+ that enables two people to play with each other, maintains the board state,
+ and only allows legal moves. A board manager does not itself play the
+ game.)</font></p>
<p><font color="#000000">Unlike the vending machine, the contract host need
not have any prior knowledge of the contract.</font> Once Alice and Bob
agree on the text of a board manager and on a mutually trusted contract
host, they upload the board manager to the contract host, which then verifies
for them that they've agreed on the same contract, and dispenses to each
- the right to play their respective sides of the game, shown as the arrows
- pointing at the respective chairs. The contract can embody the knowledge
- of acceptable arrangements local to Alice and Bob, local custom, prior
- handshakes, etc... If the contract host can be trusted at all, it can
- be trusted to run this contract faithfully, despite its ignorance of the
- local knowledge that gives this contract meaning. The tension between
- local knowledge and widespread trust is partially resolved.</p>
- <p>(In the vast majority of cases, one would expect Alice and Bob to select
+ the right to play their respective sides of the game. These rights are
+ shown as the arrows pointing at the respective chairs. The contract can
+ embody the knowledge of acceptable arrangements local to Alice and Bob,
+ local custom, prior handshakes, etc., limited only by what Alice and Bob
+ can agree on, and what they can manage to express in this new medium.
+ If the contract host can be trusted at all, it can be trusted to run this
+ contract faithfully, despite its ignorance of the local knowledge that
+ gives this contract meaning. This is the first step in resolving the conflict
+ between local knowledge and global transferability.</p>
+ <p>(Telling the tale this way hides a further division of labor. Most players
+ will not program up their own custom contract, but will instead select
a "boilerplate" contract/program off the shelf and fill in the
- blanks, rather than write a contract/program from scratch. However, the
- story of the custom contract better shows the logic by which the system
- operates, and may explain how these shelves will come to be stocked.)</p>
- <p>The "$-Issuer" and the "Stock-Issuer" turns the movement
- of the pieces into a transfer of erights. A $-Issuer, or more conventionally
- a bank, is effectively a title company for money. For money on record
- at the bank, the rights to the money changes hands by the transfer of
- quantity between accounts -- shown above as <i>purses</i> within the issuers.
- When Alice places the gold bar on the board, her computer, the $-Issuer,
- and the contract host engage in a three-way cryptographic transaction
- that bring about the transfer of title, at the $-Issuer, of that much
- money from Alice to the contract host. An honest contract host would consider
- this money to be only a piece on the board, which can be picked up (transfered
- to the possession of a player) according to whatever may be the rules
- of the game. We refer to this as <i>oblivious escrow</i>.</p>
+ blanks. These customizable contracts may have been contributed by earlier
+ players who did write their own contract, or they may be created by specialists,
+ either speculatively or under contract. Or perhaps they will use a simplified
+ contract construction kit, whose user interface might resemble a drawing
+ package specialized for drawing our board-state-transition diagrams. Such
+ an interface may even enable some players to overcome hurdles of language
+ and literacy. In any case, the simplified story of the custom contract
+ still shows well the logic by which the system operates, without needing
+ to speculate on the possible organization of the market for smart contract
+ creation.)</p>
+ <p>The "$-Issuer" and the "Stock-Issuer" transforms
+ the movement of the pieces into a transfer of erights. A $-Issuer, or
+ more conventionally a bank, is effectively a title company for money.
+ For money on record at the bank, the rights to the money changes hands
+ by the transfer of quantity between accounts -- shown above as <i>purses</i>
+ within the issuers. When Alice places the gold bar on the board, her computer,
+ the $-Issuer, and the contract host engage in a three-way cryptographic
+ transaction that bring about the transfer of title, at the $-Issuer, of
+ that much money from Alice to the contract host. An honest contract host
+ would consider this money to be only a piece on the board, which can be
+ picked up (transfered to the possession of a player) according to whatever
+ may be the rules of the game. We refer to this as <i>oblivious escrow</i>
+ -- the contract host, merely by running the contract, esures that goods
+ in escrow can only be release under the agreed conditions, without needing
+ to understand what those conditions mean.</p>
<p>A dishonest contract host could abscond with the money instead, which
is why contract hosts needs to be widely trusted. A widely trusted contract
host presumably has a valuable reputation at stake, and this risk helps
@@ -520,8 +538,8 @@
<p>We may visualize this as the game shown in Figure 6. In the initial board
state A, the stock is already on the board. While in this state, neither
Alice nor Bob may pick up the stock. An new element in the game is the
- game clock, attached to a transition arrow, that only permits this transition
- after its deadline has expired. Should the deadline expire while the game
+ game clock, attached to a transition arrow, that only permits that transition
+ after a deadline has expired. Should the deadline expire while the game
is still in state A, Bob could then pick up his stock and go home, leaving
the game in terminal state B.</p>
<p>Or, before the deadline expires, Alice may decide to <i>exercise</i>