Async vs sync interface

[s1na]

Sorry to be raising an old question again: I was wondering what are the biggest challenges in having an async-by-default interface? reading here it says:

After evaluating the trade-offs between the sync and async ewasm interfaces, we've decided to adopt the synchronous version. First, the synchronous interface better matches the EVM execution model, which synchronously executes contract calls. Secondly, although implementing the synchronous interface in Javascript requires inconvenient workarounds, in other programming languages (C++, Go, Rust, etc.) it is simpler than the async version. Lastly, adapting existing EVM higher-level languages such as Solidity to the async ewasm version would be much more complicated.

The main argument seems to center around the sync model resembling eth1 more closely. Considering that eth2 (as it currently seems like) would require asynchronous primitives anyway (e.g. for cross-shard communication, or yanking, even same-shard async calls as mentioned by Casey) , what would be the downsides of making some other methods, e.g. CALLs (except library or pure functions), CREATEs and the methods accessing the state, also async?

Of course, one could alternatively ask what would be the benefits of making them async, to which I have no good answer, but would be interested to investigate.

[poemm]

More generally, a model of concurrency may allow race conditions or deadlocks which could break consensus. For example, Primea uses an event-loop async model of concurrency with additional restrictions involving ownership of resources based on who requested them at a lower gas use. Eth2 async cross-shard calls are still be open to design.

I could mention other efforts which advertise concurrency, but you asked specifically about async models of concurrency.

[lrettig]

One thought is that you can build synchronicity on top of asynchronicity (e.g., await/async pattern), but not the other way around, so it may be nice to have some async at the base layer for maximum optionality.