Need shortening of unsettled promise chains

Currently, unsettled promise chains that go through intermediate vats do not get shortened. This creates several problems, at least:

• intervat and interchain promise cycles never get collapsed into a local cycle, and thereby never become detectable. Thus, messages sent into such loops keep cycling forever, interleaved with productive events. Thus, this does not prevent actual progress, but becomes a form of resource exhaustion attack slowing down other progress.
• If an intermediate vat gets killed, the promise chain that should have been shortened instead breaks. Had the chain been shorted (and once we do implement shortening) the promise chain would survive the death of the intermediate vat, which will be an observable semantic difference.
• We continue to pay the cost of the intermediate hops. When distributed across multiple chains this can get very expensive.

To implement unsettled promise chain shortening, we need to implement something like E’s __whenMoreResolved protocol or what Midori did (@dtribble please fill in). To do so, we need to detect when a promise is forwarded to a handled promise. When a handled promise is forwarded to a handled promise, our shim can detect that, and could provide the necessary hooks to implement its part of a shortening protocol. However, without platform support, the shim cannot detected when a regular promise is forwarded to a handled promise. This happens implicitly surprisingly often, for example

const foo = async () => handledPromise
const hp = foo();

Here, the foo function looks like it is returning a handled promise. The foo function does not even have an await in it, so it looks like it returns the handledPromise immediately. However, the hp variable is bound to a regular promise that has been implicitly forwarded to the handled promise. A platform implementation of the eventual-send proposal would treat this correctly. The shim cannot. Thus, if a forwarding chain involves such a regular promise under the shim, this has two consequences, which kinda compensate for each other:

• If an intervat unsettled promise chain involves fp, under any plausible enhancement of the shim, it is still impossible to shorten this part of the chain.
• Any message eventually sent into this chain stalls at fp, breaking pipelining and changing message order (problems) but also preventing the message from infinitely cycling around the loop (a surprising silver lining).

Thanks to Informal Systems for focusing our attention on this. Attn @jessysaurusrex @warner @michaelfig @dtribble

[erights]

See https://github.com/Agoric/agoric-sdk/issues/3923 https://github.com/Agoric/agoric-sdk/issues/3702 attn @danwt https://github.com/Agoric/agoric-sdk/issues/1636 https://github.com/Agoric/agoric-sdk/issues/1354

@michaelfig Do we have a bug somewhere explaining why it is impossible for the shim to implement the full proposal? I recall that we did, including example code. But I can’t find it.

[mhofman]

I think it would be ok for vatB to cooperate with vatA on this ordering guarantee since vatB has been trusting vatA as the decider, but I’m not sure what that could look like. I dont think vatA and vatB can/should rely on vatC to respect any ordering A and B might have agreed upon.