[E-Lang] Hash Chaining & Capabilities, Proposal #1b: SimplifyingPluribus

[Mark S. Miller]

[Note: I did see the ">" below, but I deleted it without putting "..." in 
its place, since I'm quoting Tyler and not his email software.  My email 
software escapes a "From" at the beginning of a line by prefixing it with a 
space.  Much less annoying.  --MarkM]

At 03:44 AM 10/17/00, Tyler Close wrote:
>Markm wrote:
>> When Alice then sends resultC
>> to Bob, VatA would simply send <vatID(C),
>> swissNumber(resultC)> to VatB,
>> which would then send it to VatC to look up the result.
>
>What happens if Bob tries to use his resultC before Carol has gotten
>the request from Alice?
>
> From Carol's perspective, resultC from Bob is indistinguishable from a
>forged cap. If Carol responds to Bob that resultC is a forged cap, Bob
>thinks that Alice gave him a forged cap.
>
>If Alice and Bob are neighbours, and Carol is a remote resource, then
>this unfortunate message sequence will be the common case. Consider
>the scenario where Carol is hosting a brand of erights and Alice is
>transferring erights to neighbour Bob.

Your analysis is exactly correct.  The current Pluribus faces exactly the 
same issue, and solves it awkwardly.  The Pluribus I'm rebuilding must also 
solve this issue, and I'm planning on reusing the current awkward solution 
unless someone has a better idea.  The reason I didn't mention it in the 
previous note is that this race condition issue is orthogonal from the 
security issues that the previous note was about.

The awkward solution:

When VatB asks VatC to look up Carol's swiss number, VatB includes the 
information that it's lookup a reference that originated with VatA.  (It 
does this by including a remote reference to a Vine object, which also 
solves a race condition in 3-vat distributed garbage collection, but I'll 
leave that to other explanations.)  When VatC receives the lookup request, 
if it doesn't yet have an association for this swissNumber, it returns a 
promise for what the associated value will be.  It then also initiated a 
round trip to VatA.  

By the time this round trip completes, any delayed message from VatA sent to 
VatC before VatA sent the Carol reference to VatB, must have arrived.  
Therefore, if there's still no association for this swissNumber by the time 
the round trip completes, VatC breaks the promise -- resolves the reference 
to an answer to a broken reference.  Note that if the round trip between 
VatC and VatA reports a broken connection, we may correctly treat that as a 
completion of the round trip for these purposes.

Anyone have any better ideas?  Again, this is orthogonal to hash-based 
proposals for simplifying Pluribus.  The only difference between the above 
description and current Pluribus is that, in current Pluribus, VatB would 
ask VatC to look up the pair <VatID(X), swissNumber(Carol)> rather than 
swissNumber(Carol).  VatID(X) would be VatID(C) for the standard Granovetter 
case, and VatID(A) if Carol is the result of a pipelined message from VatA 
into VatC.

Note: I won't swear that current Pluribus correctly implements the above 
logic.  That's one of the reasons I'm excited about rebuilding it simpler.