• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ]

Hi Mark,

The version of ferex.com that I showed at FC'00 was built using only a single Cistern/Vat. Lately, I've been trying to split it up into multiple Cistern/Vats. This has caused me some problems.

The situation is your "Escrow Exchange" agent (http://www.erights.org/smart-contracts/exchange.html), where the agent is in one Vat, and the two brands of erights being traded are each in their own separate Vat.

The list of problems

I can build a protocol on top of ERTP so solve problems 1, 3 and 4, but problem 2 is a real bummer. Also, using a wrapper protocol sort of defeats the purpose of ERTP.

The problems in greater detail

1. As far as I can tell, the Exchange Exchange using ERTP demands the following sequence of messages: Validation Stage: vouch # to validate the Assay before applying it EQ # to check that the returned Assay is the same as the given Assay. Secure Stage: makePurse # to make the tmp Purse. sturdyVouch # to get a sturdy ref to the tmp Purse transfer # to move erights from src Purse to tmp Purse. Complete Stage: receive # to move erights from tmp Purse to dst Purse.

I think this means that 6 messages have to be sent <em>in sequence</em>, on each side of the trade. Were you planning on doing some sort of under the hood piggybacking? Is so, I suspect this would require mobile code. Another big onus.

With a different protocol, I think this could be done in 3 messages. I'll explain this later in this email.

2. Since Assay objects have caps for the inner workings of a Purse, you have to do pass-by-reference. This means that clients in external Vats have to send a message for every 'compareTo' operation.

Making the Assay objects pass-by-copy would involve removing the 'transfer' method and accepting that Assay objects cannot be trusted to have a "valid" state, according to the rules of "valid" setup by the Issuer. A different protocol could accommodate the first criterion and I think I can live with the second. Having to validate the Assay before each erights transfer is much easier and cheaper than having to send a message for each 'compareTo' operation. Computation is free, messages are not.

3. I think a protocol that doesn't use temporaries is required.

4. If you crash after sending the 'transfer' operation, then you wake up in two possible states: the transfer occurred, the transfer didn't occur. Figuring out which state you're in requires 2 messages: 'assay' sent to the tmp Purse and 'compareTo' on the received Assay with an empty Assay (this assumes you already have an empty Assay, more messages if you don't). You can then pick the correct spot in the trade to resume from.

If a different ERTP was structured so that it was tolerant of receiving the same message twice, then recovery would be much easier. Assume that the transfer didn't take place and resume the trade from there.

A different ERTP

Issuer

            Payment offer,
            Recipient payee) throws UnacceptableIssuer,
                                    InvalidAssay

# secure all of the offer for the payee.
Assay secureAll(Payment offer,

                Recipient payee) throws UnacceptableIssuer

Assay

Payment

Recipient

                                   WrongRecipient

This protocol was arrived at by making the ERTP Assay pass-by-copy, compensating for this by modifying the Issuer and then splitting the ERTP Purse into 2 entities, one for each of its intended uses: Payment, Recipient.

How this addresses the problems

1. The sequence of messages for a trade is now: Validation Stage: approve # to validate the Issuer Secure Stage: secure # to certify that the erights are present. Complete Stage: receive # to turn over the erights.

Only 3 messages required on each side of the trade. Is this the logical minimum? (Assuming that a validation stage needs to occur at all. If the Exchange Agent was pre-configured for 2 Issuers, then submitting the trade would be tacit acceptance of the Issuer).

2. Assays now have no secret state and so can be pass-by-copy.

3. In my opinion, the way I solved this makes the protocol less 'beautiful', but I suspect that any scheme for eliminating temporaries will be less 'beautiful' than using temporaries.

Temporaries were eliminated by making it possible to secure a Payment for a particular Recipient. After a Payment is secured, only the subject Recipient can receive it. You must present the cap for the intended Recipient in order to unsecure a Payment.

4. If the Exchange agent crashes after sending out the 'secure' message, it can just send it again when it wakes up. Same with 'receive'.

Some other nice properties

1. The Recipient never needs to be validated by the Issuer. This means you can create new kinds of Recipients for pre-existing brands of erights. This is not possible with the current ERTP.
2. The protocol doesn't address how a Recipient removes erights from a Payment. This allows each brand of eright to create its own appropriate method.
3. ... (still thinking on it).

This 'different ERTP' is work of the last 24hrs, so it's quite possible I've overlooked something. I actually have a pressing need to use an ERTP, so it'd be nice if we could hash this thing out quickly. I look forward to your comments.

Tyler Close, Founder Waterken Inc.
tyler@waterken.com
A35E 0621 44AD B616 DE29 F8DF 7B4C E859 71AB 47C5

[ Next ]
• [ Previous ]