Non-volatile hardware-backed counters would be a great way of handling crashes. In SGX, not only was the non-volatile counter slow, but it had such a short lifetime it could be burned out. The best reference by far is the ROTE paper:
To summarize, we found out that counter updates take 80-250 ms and reads 60-140 ms. The non-volatile memory used to implement the counter wears out after approximately one million writes, making the counter functionality unusable after a couple of days of continuous use. Thus, SGX counters are unsuitable for systems where state updates are frequent and continuous.
The ROTE paper of course also proposes instantiating a non-volatile counter service from of a distributed network of redundant volatile counters. This is closest to what we do in Sirrah for the auction example, where the on-chain is used as the source of truth for sequencing all commands.
The Kettle Cash proposal is the extreme, presented as the optimistic best-performance baseline, that only uses a volatile monotonic counter implemented using Suave.volatileGet/Set` on one machine at a time. You wouldn’t use this for buying coffee, and I think to go further it will take a specific application. I think this would be relevant for high frequency settling when you’re already OK gambling on the uptime of a particular machine.
Also if we had a really fast and virtualizable non-volatile hardware counter, even if it were provided as an external module, that could do the trick. My favorite papers on this is TrInc which proposes a dedicated module for a “Trusted Incrementer” and how you can build distributed systems on it. This is a good application goal for the OpenTEE stuff :]