ERTP: some initial comments

[Mark S. Miller]

At 01:23 PM 6/22/99 , Nick Szabo wrote:
>* I'd love to see an example that transfers erights
>which are the rights to use a particular service
>provide by an object (i.e. to invoke one or more of its
>methods a particular number of times), rather than just 
>changing a generic numerical balance.  The money example isn't 
>representative of how ERTP will usually be used.

We need to separate issues here.

1) A non-exclusive transfer of a right to invoke a particular object isn't 
particularly interesting, as capabilities already provide than primitively.

2) Given an object, one can create a derived object that provides a limited 
ability to invoke methods of the base object, but the new limited right is 
no more or less transferable than the original right.  This limitation can 
be done with simple object abstraction, as shown by the "once" abstraction 
in http://www.erights.org/elang/concurrency/race.html , and gains nothing 
from ERTP.

3) The remaining ERTP issue, which is indeed informatively different from 
money, is the exclusive transfer of the eright to invoke a single object.  
The underlying object may or may not be a limited-invocation wrapper (e.g., a 
"once") of a yet more primitive object, but this is orthogonal. 
http://www.erights.org/smart-contracts/exclusive-updoc.txt is an example 
implementation.  The last two paragraphs of the intro to ERTP on 
http://www.erights.org/smart-contracts/index.html now reads:


erights.updoc shows money re-implemented as a proper eright. Money is 
exclusive, fungible, and non-exercisable. Money transfers should be blinded, 
but this implementation provides only non-blinded transfer.

By contrast, exclusive.updoc implements, as an exclusively transferable 
eright, the ability to invoke (pass messages to) particular underlying 
objects that an Issuer decides to make accessible in this manner. These 
erights are exclusive, non-fungible, and exercisable. As Nick explains in 
"Contracts with Bearer", since these erights are non-fungible, nothing would 
be gained by blinding their transfer.


>* Some of the comments seem to treat "trust" in a party as all or 
>nothing.  However, we are only trusting the Issuer with certain particular 
>security properties for a particular set of rights.  Such narrowly 
>scoped and decentralized trust is critical for real world, 
>cross-organizational distributed systems.

I believe this is only an artifact of my writing.  I truly don't yet know a 
way to speak clearly while making all the trust distinctions I have in my 
head.  I suspect than new terminology and taxonomy will be required.

In any case, as you point out specific such errors, I will try to fix them.


>* What is the rationale for hiding the distinctions
>between exclusive vs. non-, fungible vs. non-,
>and unlinkable vs. non-?  Where will the programmer
>be able set and query these properties?

This is a very important question.  Market intermediaries -- escrow exchange 
agents, auction houses, etc... --- often won't care what erights are being 
moved around, or even what kinds of erights are being moved around.  What 
they will care about is that these erights, and the manner in which they are 
being transferred, is mutually acceptable to their customers.  The essence of 
being an intermediary is being able to calculate "mutual acceptability" 
under adversarial conditions.  By being neutral to the nature of the erights 
being traded, such intermediaries are more reusable and composable.

Often, the customers of such intermediaries will need to know the nature of 
the erights being traded.  erights.org expects to be growing standard 
subtypes of these base types over time to represent various useful taxonomic 
distinction.  But we need to get the universal supertypes correct first.