The lost resolution bug isn't
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 that we want all far refs to the same object to be ==, and we want == objects to be absolutely indistinguishable, 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.