Nick Szabo - Scarce Objects
Nick Szabo is one of the few people who can integrate contracts into financial cryptograpy. His work with smart contracts echoes around the net, and he last year he gave the keynote presentation at the Workshop on Electronic Contracts. In this paper he seeks to integrate scarcity and property constructs with the object oriented model of programming.
Scarce objects, a.k.a. conserved objects, provide a user and programmer friendly metaphor for distributed objects interacting across trust boundaries. (To simplify the language, I will use the present tense to describe architectures and hypothetical software). Scarce objects also give us the ability to translate user preferences into sophisticated contracts, via the market translator described below. These innovations will enable us for the first time to break through the mental transaction cost barrier to micropayments and a micromarket economy.
A scarce object is a software object (or one of its methods) which uses a finite and excludable resource -- be it disk space, network bandwidth, a costly information source such as a trade secret or a minimally delayed stock quotes, or a wide variety of other scarce resources used by online applications. Scarce objects constrain remote callers to invoke methods in ways that use only certain amounts of the resources and do not divulge the trade secrets. Furthermore, scarce object wrappers form the basis for an online economy of scarce objects that makes efficient use of the underlying scarce resources.
Scarce objects are also a new security model. No security model to date has been widely used for distributing objects across trust boundaries. This is due to their obscure consequences, their origins in single-TCB computing, or both. The security of scarce objects is much more readily understood, since it is based on duplicating in computational objects the essential security features of physical objects. This architecture is "affordable" in Donald Norman's sense, since human brains are designed to reason in much more sophisticated ways about physical objects than about computational objects. It is thus also "affordable" in terms of mental transaction costs, which are the main barrier to sophisticated small-scale commerce on the Net. Finally, it will solve for the first time denial of service attacks, at all layers above the primitive scarce object implementation.
Comments below please!
Posted by iang at June 26, 2005 07:39 PM
Nick, some comments! They are vsomewhat stream of consciousness, which may help or it may not....
I took the 1st three paras as the Abstract. That and an Intro needed, maybe.
These intro paras meander and jump around.
"Scarce objects are also a new security model. No security model to date has been widely used for distributing objects across trust boundaries.
From my pov, I'd be looking to see why/how SOs compare and exceed capabilities, that is, make that statement so! (OK, so I see this is actually
written about later on.
"This is due to THEIR ..."
'Their' refers to SOs or to every other security model?
At this point it seems to branch to a section of architectural import that starts with some odd references to physicists. There seems to be a missing header of some sort, something like "Architectural Summary" or somesuch.
It closes with a set of 3 requirements which is quite strong. Somehow this should be signalled. It's the closest it gets to definitions AFAICS.
"This architecture is "affordable" in Donald Norman's sense, since human brains are designed to reason in much more sophisticated ways about physical objects than about computational objects. ........... The intuitive physical metaphor of scarce objects is based, not on the complexities of the quantum world as understood by today's physicists, but on the intuitively clear, ideal world of the "atomists" from Democritus through Newton.
These references are obscure and look like hand waving. Unless they are explained - in the sense of the image that the names are supposed to convey, then they don't add anything, and potentially annoy the reader.
The leap from limitations and requirements (points 1,2,3) to a discussion of property rights, trust boundaries, etc, is too hard to follow. It needs a heading of its own, and/or some linkage description as to why the cross from disciplines is useful (physicists to lawyers in one paragraph...)
"With scarce objects, any computation across trust boundaries will have these properties of atomicity, conservation, composition, and the accompanying clear delineation of rights and responsibilities."
Isnt' that last thing 'property' ? Isn't that what you established in 3. above? So it would be ...
"these properties of atomicity, conservation,
composition, and property"
leaving for later text a tighter definition of each?
"Scarce objects are, in other words, online commodities. These commodities may represent, typically, rights (or expectations) to services the right to use an e-mail or news service......
A definition is needed. Scarce objects need to be defined. What are they? Here, they *MAY* represent rights or expectations or services... does this mean they *MAY* be something else as well?
"Such service rights will usually be limited by time or resource usage or number of invocations. When represented properly,..."
First off, get the basic definition down. Then list the caveats, limitations, etc...
"Such rights or codified expectations are enforced by reputation, by the physics of scarce objects, or both, in substitute for or in addition to expensive traditional legal means.
This seems to say:
Such rights or codified expectations may be enforced by a combination of
- the physics of scarce objects, and/or
- expensive traditional legal means.
In that the relationship between the three seems to be versatile and beyond the scope of the article.
- "not a complete model of computation" ...
if this statement has any relevance it possibly belongs in a conclusion. In order to achieve that, it seems that
a) SOs need to be clearly defined,
b) SCs need to be clearly defined,
c) the relationship between SOs and SCs needs to be clear
d) and what each can and can't do needs to be explained.
At this point, none of that is clear.
- Microeconomics - what's the point in mentioning transaction costs? Supply chains? Call graphs? Client-server ... Customer-supplier... none of this "relates" to the paper.
OK, now up to Usage Control vs. Access Control.
At this point I do not know what a scarce object is.
That is, I have no definate test, no definition, no difference from some other well known and assumed known other construct. As you know I'm quite a definitional guy, and after yonks on the capabilities group, I'm still not sure I can write down what a capability is. So this might appear overly harsh, or premature in that until I want to build one, I don't really need to know what it is.