For another thing, I’m personally not a big believer in the practical value of the asynchronous model anyway. I know I’m at odds here with most people with a theory/algorithms background; reasonable people may differ. :) Almost every practical distributed system that ever actually gets deployed has timeouts and such buried in it here, there, everywhere. User-experience expectations are synchronous, not asynchronous: even if the underlying protocol is in principle perfectly capable of tolerating arbitrarily-long adversary-controlled propagation delays among honest nodes, the real users relying on the system are going to start complaining rather soon after the expected/normal amount of transaction time elapses. And in environments where we’re truly exposed to hugely-varying latencies and actually need to adapt to them - such as delay-tolerant or interplanetary networking scenarios - then asynchronous consensus protocols and the like are never useful in practice there either because they slow everyone down to the least-common denominator: e.g., if 1/3 of the participants in an async BFT protocol are on Mars, then everyone’s transactions everywhere must necessarily slow down to account for the Mars-Earth latency, which no one doing transactions only on Earth (or only on Mars) will accept. The only real, practical solution to those kinds of problems are locality-preserving approaches such as Cristina’s Crux project (https://arxiv.org/abs/1405.0637), which of course is a whole different ball game.