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
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
Payment offer, Recipient payee) throws UnacceptableIssuer, InvalidAssay
# secure all of the offer for the payee.
Assay secureAll(Payment offer,
Recipient payee) throws UnacceptableIssuer
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
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
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.
A35E 0621 44AD B616 DE29 F8DF 7B4C E859 71AB 47C5