The lost resolution bug isn't
From Erights
(clarify "non-quirky sameness") |
Kevin Reid (Talk | contribs) |
||
| Line 5: | Line 5: | ||
Lost resolution: If VatA has a [[Far ref|far (resolved) reference]] to Carol in VatC, and sends a message to Bob in VatB containing that reference, then it will arrive as a [[remote promise]] (for the result of a nonce-lookup sent to VatC) rather than a [[far ref]]. | Lost resolution: If VatA has a [[Far ref|far (resolved) reference]] to Carol in VatC, and sends a message to Bob in VatB containing that reference, then it will arrive as a [[remote promise]] (for the result of a nonce-lookup sent to VatC) rather than a [[far ref]]. | ||
| - | The plan to fix this was to introduce the [[WormholeOp]], which would allow VatA to send to VatB the (encrypted) messages it wanted to arrive at VatC before the messages from Bob to Carol (preserving | + | The plan to fix this was to introduce the [[WormholeOp]], which would allow VatA to send to VatB the (encrypted) messages it wanted to arrive at VatC before the messages from Bob to Carol (preserving E-order). |
| - | However, given | + | However, given non-quirky sameness {{XXX|explain this}}, and that ''something'' in VatB has a reference to Carol, Bob would necessarily receive ''the existing far reference'' to Carol, and Bob, possibly with the collusion of VatB (not delivering the WormholeOp traffic, or delaying it), can then violate E-order by sending messages too soon. |
==Motivation and what to do instead== | ==Motivation and what to do instead== | ||
Revision as of 04:45, 29 August 2009
2009-08-29, User:Kevin Reid and User:Markm
The infamous lost resolution bug is not a bug.
Lost resolution: If VatA has a far (resolved) reference to Carol in VatC, and sends a message to Bob in VatB containing that reference, then it will arrive as a remote promise (for the result of a nonce-lookup sent to VatC) rather than a far ref.
The plan to fix this was to introduce the WormholeOp, which would allow VatA to send to VatB the (encrypted) messages it wanted to arrive at VatC before the messages from Bob to Carol (preserving E-order).
However, given non-quirky sameness XXX explain this, and that something in VatB has a reference to Carol, Bob would necessarily receive the existing far reference to Carol, and Bob, possibly with the collusion of VatB (not delivering the WormholeOp traffic, or delaying it), can then violate E-order by sending messages too soon.
Motivation and what to do instead
The obvious consequence of the lost resolution bug was that an object which requires settled components (e.g. a map's keys) could fail to unserialize. That is:
- Alice: bob <- foo([carol => 1, james => -1])
- Bob: receives [<Promise> => 1, <Promise> => 2] which dies in unserialization because keys must be settled.
Possible solution to this case: The portrayal used by maps when being sent over the network specifies a maker method which, if any of the keys are unsettled, returns a promise for the map, which resolves when the keys become settled (detected by whenResolved on the unresolved components). This effectively “promotes” the lost resolution to the containing map, hopefully allowing higher-level code to deal with it.
Simplifications resulting from giving up on lost resolution
Current implementations: NewFarDescs don't need to get 128 bits of entropy and pass them over the network. Swiss numbers are only used for sturdy refs.
If-we-had-done-the-planned-thing: WormholeOp goes away; Far3Desc goes away and Promise3Desc is always used instead (as current implementations do).
