Mark S. Miller writes:
> [+Dean]
>
> This is an important question, and we need to continue examining the
> alternatives here. The criteria has to do with the models programmers form
> under various semantics, and then the mistakes they make even according to
> the semantics they tried to model. Existing comparable experiences, but
> without easily comparable data, from weakest to strongest orders:
>
> *Unorder:* The original Actors, the early Joule, Belay, and most cert
> systems all had no ordering guarantees at all. Just eventual delivery.
> * I am not aware of enough experience of people programming directly in
> original Actors to form any conclusions
> * From the early Joule experience, we concluded that unorder was a
> mistake, and we adopted the precursor of E-order, which we liked.
> * Belay programmers report being very happy with unorder, and never
> being confused by it.
> * SPKI/SDSI...capCert had no builtin ordering constraints on acting on
> certs. Does zcap-ld? I suspect not.
zcap-ld does not specify ordering constraints, but also does not specify
delivery mechanism, just processing and validation of invocations. In
general zcap-ld has been written from the per-invocation perspective.
FIFO could be layered on top, but isn't in any explicit way right now,
afaict.
> *FIFO: *Waterken did point-to-point FIFO. Waterken programmers would
> express any three-party ordering constraints by explicitly forcing a round
> trip, as in your example. I don't recall anyone being tripped up by this.
Good to know.
> *E-Order: *E of course adopts E-Order. I find it very pleasant. Agoric is
> currently proceeding with E-Order, but see...
>
> *Flow Order: *Midori started with E-Order and found they were using it
> incorrectly. Midori programmers would assume E-Order made things more
> predictable than it does. In reaction Dean (cc'ed) invented Flow Order,
> which does provide stronger ordering than E-Order. However, AFAICT, it does
> so at the price of making loss of progress vulnerabilities much harder to
> think about. Neither E nor Midori were ever subjected to actual adversaries
> that would have been interested in denying progress. But I think I know how
> to think about defensive progress in E-Order. I never got that far with
> Flow Order and I am skeptical.
Interesting (I had not heard of Flow Order before).
My gut feeling is that any ordering system that I can't play a
simulation of in my head or follow drawn out on paper (similar to the
"animations" on the e-order pages) is probably one that has some nasty
hidden corner cases that will probably bite the average, and even
not-so-average, developer.
> *Causal Order:*
> *Agreed Order:*
> In the conventional distributed systems literature, the sequence of
> recognized orders is Unorder, FIFO, Causal, Agreed. I invented E-Order
> because I felt FIFO was too weak for secure programming, and that Causal
> was too strong to be implemented by cryptographic means between mutually
> suspicious machines. However, I arrived at this conclusion before
> blockchains. A blockchain is all about implementing agreed order between
> mutually suspicious machines within that chain. Agreed would still be too
> much for an interchain protocol like CapTP on IBC. But do blockchains
> change the base assumptions enough that CapTP on IBC should examine Causal
> Order? Perhaps.
Blockchains are able to approach ordering by providing "decentralized
centralization" at enormous cost... but still per-ledger. Decentralized
centralization of decentralized centralizaiton across ledgers formed
like this, if possible, will probably work in after-commit safe
resolution of what the order is... but a-priori analysis probably will
be tantamount to speculative quakery.
If it were just one "machine", maybe. I don't think it's going to work
as a network of machines.
> The tension between E-Order and Flow Order does make me feel ever more
> tempted by the Waterken position. The issue is not stronger vs weaker, the
> issue is misalignment between what programmers tacitly expect from a given
> semantics vs what that semantics actually provides. If E-Order and Flow
> Order are both too confusing and Causal still too hard to implement
> securely, FIFO may indeed be the sweet spot.
This is exactly what I was trying to needle at, so I'm happy to hear
you say it. ;)
> Were we to adopt FIFO, there would be no need for general wormholing. We'd
> still need to wormhole the provideFor messages to avoid lost resolution.
> But if that's all we're wormholing we may well do it alone as a special
> case.
Honestly that seems like the right thing to me. However, Ian's comments
about promise pipelining getting goofy without e-order make me unsure.
But I haven't been able to fully digest Ian's example yet... will
probably do so while tossing and turning right before I fall asleep
tonight.
Thrilled that my advocacy-for-devils was not completely off-base!
- Chris