In the agoric model
of computation [II], market mechanisms-prices and
negotiations-coordinate the activity of objects. As in existing markets, these
mechanisms will allocate resources in a decentralized fashion, guided by local
knowledge and decisions rather than by central planning and direction. Through
selective rewards, markets will encourage the evolution of useful and efficient
objects.

This model raises questions at several levels, ranging from
foundations (how can hardware and software support secure market mechanisms?)
to high-level emergent properties (how will evolved computational markets
behave?). Here we focus on a question at an intermediate level, asking how the
basic computational resources of processor capacity and data storage can be
managed in a market-compatible fashion, given suitable foundations. We first
examine objectives and constraints for decentralized resource management, and
then describe a promising set of initial market strategies. These are
algorithms that can help seed a system with a workable initial set of objects.
Initial market strategies (or initial strategies, for short), must be
compatible with current programming practice and (when widely used) must
provide an environment in which resources typically have prices that reflect
costs-that is, an environment in which other objects can make economic
decisions that make sense.

1.1. The role of initial market
strategies Agoric systems will evolve from lesser to greater complexity. To
begin evolving, they will need a comparatively simple structure from which to
build. The role of initial market strategies is to serve as a sort of
scaffolding: they must support the right things and have the right general
shape, but they must also be replaceable as construction proceeds. Though they
must embody sound engineering principles, they need not themselves be
architectural wonders.

For computation to occur, storage and processing power must be
allocated and managed-functions that existing algorithms handle [1,2]. To get a
computational market started, we will need initial strategies that also enable
market-based decision making. To enable conventional computation, the use of an
initial strategy by a set of objects must ensure the reliable sched- uling of
processes and allocation and deallocation of storage. To enable
globally-sensible, market-based decision making, the use of an initial strategy
by a set of objects must provide an environment in which the price of using an
object reflects the real cost of that use.

These initial market strategies, however, cannot use price
information to guide their own actions. To behave reliably in a conventional
computational sense, they must pursue their goals regardless of cost. If
resource prices are to make economic sense, however, objects at some level
(perhaps contracting with systems of initial-strategy objects) must be willing
to forgo or delay actions which will cost more than their estimated worth.
Initial market strategies exist to provide an environment in which more
advanced market strategies can function and evolve (even evolving to replace
the initial strategies themselves).

Initial programming environments can provide initial market
strategies as default parts of object definitions. Though initial strategies
will perform functions ordinarily handled by an operating system or language
environment, they need not be foundational or uniform across a system. The
foundational mechanisms of agoric systems will delegate decisions regarding
processor scheduling and storage management to unprivileged objects, enabling
them to follow diverse policies. Initial strategies will simply provide
policies that work, until better policies emerge.

The initial market strategies described here are intended to
serve two purposes: first, to provide a proof-of-concept (or at least
evidence-of-concept) for the feasibility of decentralized resource management
meeting the constraints we describe; and second, to provide a point of
departure for further work-a set of ideas to criticize and improve upon. For
several of our choices, straightforward alternatives can likely be found. Many
will prove superior.

Throughout the present discussion, "object" should be considered
a scale-independent notion: an object should frequently be regarded as a large,
running program, such as an expert system or on-line database. Large objects
may or may not be themselves composed of objects, and objects in general need
not incorporate any notion of class hierarchy or inheritance. Some of the
following algorithms have relatively high overhead and are not proposed for use
with small objects; large objects might use conventional algorithms for
fine-grained internal resource management.

1.2. Auction-based processor scheduling
Most objects will need only a fraction of the service of a processor, hence we
expect rental to emerge as a major means of acquiring processor time. Since
objects will frequently be able to trade off processor use against storage
requirements, communications use, or service quality, processor time will have
a price relative to these other resources. This price will vary from processor
to processor and from moment to moment. If an agoric system is open,
extensible, and uses real currency, and if machine owners are alert, then the
long-term average price of processor time in the system will reflect the
external market price of adding more processors to the system-if it were much
higher, the owners could profit by adding processors; if it were much lower,
they could profit by removing and selling them.

Since the demand for processor time is apt to fluctuate rapidly,
proper incentives will require rapidly fluctuating prices. This can be arranged
by auctioning each slice of processor time to the highest-bidding process. The
urgency of a task can be reflected in the size of its bid. Auctions can also be
used to schedule other resources allocated on a time-slice by time-slice basis,
such as communication channels. Again, fluctuating prices can provide
incentives for delaying less urgent tasks, leveling loads, and so forth.

In discussing the allocation of processing resources, we describe
the allocation of raw processor time. Some objects in an agoric system might
not purchase time this way, but might instead purchase interpretation services
on a similar (or very different) basis. A system that can provide a market in
raw processor time can serve as a foundation for more sophisticated services of
this sort.

1.3. Rent-based storage management
Because storage needs will frequently be transient, we expect that rental from
owners will emerge as a major means of holding storage. As with processor time,
storage will have a price relative to other resources, and this price will vary
across different media, locations, and times. As with processors, the long-term
average price of storage in the system will reflect the external market price
of adding more storage to the system, if owners are alert to opportunities for
profit. We discuss allocation of raw storage space here, but a system that can
provide a market in raw space can serve as a foundation for more sophisticated
storage services.

The basic idea of our initial strategy and the emergent garbage
collection algorithm is as follows:

Landlords own storage space.

They charge other objects rents at a rate determined through
auction.

Referenced objects (consultants) charge referencing objects
(clients) retainer fees, using these to pay their rent (and the retainer fees
charged by their consultants).

When objects fail to pay rent they are evicted (that is,
garbage collected).

These arrangements provide a natural way to free storage from
unproductive uses. If an object cannot or will not pay its rent, then some
other object must be bidding more for the available space (if no object was
bidding for the space, its price would be zero). Since an object's income (and
hence rent-paying ability) reflects the value placed on the object by its
users, eviction of non-paying objects will typically improve the overall
usefulness of the contents of storage.

Frequently-used consultants will be able to pay their rent out of
their usage fees. Rarely-used (but referenced) consultants can charge their
clients retainer fees adequate to cover their rent (and that of any consultants
they themselves retain). In these relationships, pointers are bi-directional: a
consultant also knows its clients. Unreferenced objects will be unable to earn
usage fees or charge retainer fees; they will be unable to pay, and will be
evicted, thereby accomplishing garbage collection (or forcing migration to a
fixed-entry-price archive). This is the basis of the market sweep
approach to garbage collection.

Rent-based storage management also allows a generalization of
pointer types. Some systems distinguish between the traditional strong
pointers and weak pointers [3]. A
strong pointer retains a referenced object regardless of the cost: it
represents an unbounded commitment to maintaining access. A weak pointer
maintains access as long as the object has not been garbage collected, but does
not itself cause the object to be retained. Weak pointers are an existing step
toward economic storage management: they represent a small value placed on
access-in effect, an infinitesimal value. This suggests a generalization in
which an object will pay only a bounded amount for continued access to an
object. This may be termed a threshold pointer. Thresholds may be set in
various ways, for example, by limiting the total retainer fee that will be
paid, or the total fee that will be paid in a given time period. When multiple
threshold pointers reference an object, their strengths add; thus, they
integrate information about the demand for retaining the object in a given
region of storage. (As we will see, however, any situation in which a
consultant asks retainer fees from multiple clients presents a challenge in
incentive engineering-why should a client pay, if others will do so
instead?)

Differing rents in differing media give objects an incentive to
migrate to the most cost-effective locations. If clients offer a premium for
fast service and demand service frequently, a consultant might best be located
in RAM; if slow service is adequate and demand is low, a consultant might best
be located on disk, or on a remote server. Caching decisions can thus be
treated as a business location problem.

Rent-based storage management solves a standing problem of
distributed garbage collection. Consider a loop of objects, each pointing to
the next, each on a different company's machine, and all, collectively,
garbage. Garbage collection could be accomplished by migrating objects to
collapse the loop onto one machine, thus making its unreferenced nature locally
visible [4]. But what if the companies don't fully
trust one another? By sending the representation of an object to an untrusted
machine, the algorithm would allow encapsulation to be violated, giving away
access to critical objects and resources. With rent-based storage management,
however, migration is unnecessary: since unreferenced loops have no net income
but still must pay rent, they go broke and are evicted.

The problem of unreferenced loops crossing trust boundaries
highlights the lack of a notion of payment-for-service in traditional
approaches to storage management. Introducing this notion seems essential when
hardware and data are separately owned. In its absence, distributed systems
will be subject to problems in which one person (or entity) forces the
retention of another's storage but has no incentive to free it.

As suggested earlier, we do not expect explicit rental
arrangements to be economical for very small objects. The appropriate minimum
scale is an open question; the ultimate test of answers to this question will
be market success.

1.4. Design constraints As we have noted,
initial market strategies must satisfy various constraints, which fall into two
classes. First, they must result in a programmable system; this can most easily
be guaranteed by ensuring that they meet the familiar constraints that have
evolved in systems programming practice. Second, they must result in a system
with market incentives, making possible the evolution of the new programming
practices expected in agoric open systems.

Systems programming constraints often guarantee some property
regardless of cost-for example, guaranteeing that referenced objects will be
retained. Sound market incentives require that all resources used be paid for,
since to do otherwise in an evolving system would foster parasitism. These two
constraints would seem to be in conflict. To resolve this, we introduce the
notion of the well-funded object. An object is well-funded if it has
immediate access to ample funds to pay for the computations it spawns. A
well-funded object might typically represent a human user and fund some
computations serving that user. These computations are required to satisfy
traditional systems programming constraints only so long as the well-funded
object remains solvent, that is, so long as the user is willing to pay their
cost.

The chief systems-programming constraint in processor scheduling
is that processes be scheduled-that is, that there be a way to arrange bidding
such that a well-funded process can be guaranteed non-starvation and hence
eventual execution. The chief market-compatibility constraints in processor
scheduling are that processor prices fluctuate to adjust demand to the
available supply, that objects be able to make scheduling decisions based on
price information, and that opportunities for malicious strategies be
limited-for example, that a process not be able to force a high price on a
competing process while avoiding that high price itself.

Several systems-programming constraints are important in storage
management. First, non-garbage-everything reachable by a chain of strong
pointers leading from a well-funded object-must not be collected. Second,
garbage-everything that is unreferenced and cannot induce other objects to
reference or pay it-should eventually be collected. Finally, overhead costs
should be reasonable: bookkeeping storage per object should be bounded and the
computational burden of the algorithms should scale roughly linearly (at most)
with the number of objects.

Market-compatibility constraints are also important in storage
management. Objects should manage retainer-fee relationships such that there is
an incentive for clients to pay retainers, lest there be an incentive to shirk.
A consultant's total retainer fees (which amount to a price for its
availability) should reflect real storage costs, to provide
non-initial-strategy clients with a reasonable basis for decisions. Finally,
objects should not require unbounded cash reserves to avoid improper garbage
collection.

Non-initial-strategy objects need not themselves meet
system-programming constraints, since they are free to act in any manner that
furthers their market success. They will still typically require reasonable
computational costs, smooth interaction with other strategies, and bounded cash
reserves. A complex market-level object, however, will be unlikely to point
strongly at an object having unpredictable or uncontrollable costs. It must
therefore be prepared for such consultants to go away. It may also spawn
low-priority processes; some of these may never run.

How can a complex object be prepared for loss of access? Current
practice already provides many examples of objects able to deal with the
unexpected unavailability of objects they use. Programs are frequently prepared
for the breaking of inter-machine or inter-process connections, or for the
inability to open an expected file. Files are commonly updated so that they are
in a recoverable state even if they should suffer the sudden loss of the
updater. Argus provides abortable transactions and exception handling [III]. Additional recovery mechanisms can be
expected among complex objects in a market environment.