Certified HTTP Escrow

Note: This escrow service should not be confused with other forms of escrow, like the escrow used to conclude auctions or a home purchase. Though the escrow described here has a similar behavior pattern, the transactions it handles are very specific and limited.

Purpose

The escrow service is be a scalable distributed transaction coordinator for multi-host transactions. It is built on top of certified http, because reliability is a primary concern. The transactions that it implements are atomic (though not ACID), though this to some degree depends on the reliability of the participants.

Currently, the plan for the escrow is that all transactions will be modeled as a transfer of resources: an initiator supplies some parameters describing which resources will be transferred, then the escrow fetches resources, and once all resources are acquired, the escrow distributes them to their destination. If the escrow cannot gather all the resources for whatever reason, it returns the already-collected resources to their original owners. This is why it's not ACID -- the participants are not isolated from the effects of the larger transaction.

Linden Lab Usage

Linden's goals for the escrow are inspired by the real-world needs we have, but the design is a little forward-looking in that there are some things we'd like to do in the future that we should be ready to handle.

1. Increase scalability by being able to make L$ transfers across arbitrary numbers of agent data stores.
2. Increase reliability of transactions in general (e.g. buying objects, buying land, parcel passes, etc.)
3. Some sort of API for third parties to be participants to Second Life transactions.

Model

The escrow is a resource gatherer and distributor. Every transaction goes through two phases:

gathering phase

In this phase, the escrow retrieves a resource from every contributing party in the transaction. If the escrow is unable to get a resource from a party, it fails the transaction.

distribution phase

After all the resources required for the transaction is acquired, the escrow gives the resources it has acquired to a set of receiving parties. If this phase fails, then a human must become involved.

An escrow transaction involves multiple participants, all of whom are Reliable Hosts.

Initiator

is the host that initiates the transaction and specifies what is going to happen and when.

Participating party

is any host whose existence is required for the transaction to complete.

Initiators select an escrow host using a load-balancing process, then send the chosen host a reliable message describing the transaction by name, and the parties it is to be performed between. The escrow service contains a description of the logic involved in the named transaction. In the future the escrow could theoretically implement arbitrarily-described resource-exchange transactions for known resource types. When the transaction is complete, the escrow host responds to the initiator with the results of the transaction.

Here's a sequence diagram illustrating how we think buying an object will work using the escrow.

Resources

Everything, in this system, is representable as a resource. By 'resource', we mean a token that on its own can be idempotently redeemed for something. These are just examples off the top of my head, these may not even make sense.

L$

a certificate of deduction on the giving agent's account, or digital cash (tm)

Asset

the contents of the asset (alternatively, a uuid and type for an asset on the asset server, or on a simulator)

Parcel

a certificate that the simulator is willing to transfer ownership of the parcel, and that it is not currently owned

Reliability

The escrow software must be a Reliable Host, with fairly strong resumption guarantees. If the escrow service crashes, it must be able to restore the state of every transaction in its care to something that only trivially differs from its state at the time of crash.

Scalability

Each escrow server, being a host for transitory executions, is completely interchangeable with any other, so there is no limit to the number of escrow hosts we could put into operation. It will be important to load-balance across them so that no individual escrow server gets overloaded.

API

Getting/Delivering Resources

The escrow must know how to take and give each type of resource in the system.

• L$
• Objects
• Parcels
• Parcel Passes

Distribution Logic

Any transaction's logic can be described as a set of parties owning the required resources, and a set of parties who should own the resources when the transaction is ended.

The distribution logic can be encoded as a set of rules, with wildcards identifying the particular details of the transaction. The initiator specifies those details.

For example, the transaction of buying an object can be represented as (this is very hand-wavey here):

{ 'gather ' : {'name':'payment', 
               'owner':Wildcard('buyer'),  
               'description':{'type':'L$', 'amount':Wildcard } }
              {'name':'deliverable',
               'owner':Wildcard('seller'),
               'description':{'type':'object', 'region':Wildcard, 'task_id':Wildcard } } }
{ 'distribute' : {'owner' : 'buyer', 'name': 'deliverable'}
                 {'owner' : 'seller', 'name': 'payment'} }

Then when you want to perform this transaction, you provide:

{'transaction' : 'buy object', 'buyer' : <my_agent_id>, 'seller' : <seller_id>, 'amount' : 40, 'region' : 'Ahern', 'task_id' : 1234}

It's possible that  BPEL might be a better description language for this sort of thing, but resource-based transactions are a very limited subset of all possible transactions.

Trust

The cool thing about an escrow is that it enables multiple parties who don't trust each other to nevertheless engage in a transaction of arbitrary complexity, each party trusts the escrow, and the escrow, in turn, trusts each party individually. In the case where the escrow does not trust a party, it prevents the transaction from happening, or allows the participants to individually decide whether to continue. Implementing this is not an initial design goal, however.

Current Use Cases

Here's a (possibly incomplete) list of the transactions we currently perform, that we wish to do via the escrow.

Create Group

Creating a group for a nominal fee. (this is sort of questionable as a use case, but it's here for discussion purposes)

	A	Linden
Gather	L$	Group token
Distribute	Group token	L$

Friendship

Agent A and B agree to be friends. (this is sort of questionable as a use case, but it's here for discussion purposes)

	A	B
Gather	permissions_for_B	permissions_for_A
Distribute	permissions_for_A	permissions_for_B

L$ Gift

A gives B some L$.

Parties	A	B
Gather	L$
Distribute		L$

Buy Parcel

A buys a parcel from B

Parties	A	B
Gather	L$	Parcel
Distribute	Parcel	L$

Buy Parcel for Group

A buys a parcel from B for group G

Parties	A	B	G
Gather	L$	Parcel
Distribute		L$	Parcel

Buy Object Contents

A buys object contents from B's object

Parties	A	B	O
Gather	L$		Contents
Distribute	Contents	L$

Give Object Contents

Object O gives A its contents.

Parties	A	O
Gather		Contents
Distribute	Contents

Buy Original Object

A buys B's object.

Parties	A	B
Gather	L$	Object
Distribute	Object	L$

Buy Object Copy

A buys a copy of B's object.

Parties	A	B
Gather	L$	Object copy
Distribute	Object copy	L$

Join Group

A joins group G for a fee.

Parties	A	G
Gather	L$	Membership Pass
Distribute	Membership Pass	L$

Buy Parcel Pass

A buys a parcel pass to enter B's parcel

Parties	A	B
Gather	L$	Parcel Pass
Distribute	Parcel Pass	L$

Buy Parcel Pass from Group

A buys a parcel pass to enter group G's parcel

Parties	A	G
Gather	L$	Parcel Pass
Distribute	Parcel Pass	L$

Deed Parcel

A deeds a parcel to group G.

Parties	A	G
Gather	Parcel
Distribute		Parcel

Deed Parcel and Tier

A deeds a parcel and tier to group G.

Parties	A	G
Gather	Parcel, Tier
Distribute		Parcel, Tier