Atomic/Isolated/Synchronous transaction execution about neps HOT 1 OPEN

unlike what Near has - where transaction results in a tree of execution blocks = receipts, each receipt running atomically to success/failure but potentially concurrently with other receipts from different trees

not sure, though, if receipts from same tree (born from single transaction) can execute concurrently between themselves

I hope I got that ^ right because it isn't that obvious from just reading this doc (I suggest to rephrase/extend it somehow, maybe with my tree analogy).

On a similar note, I'm not sure "Wasm suspension" approach(which seems to be most preferable among those listed there) provides atomicity / isolation properties, imagine the following scenario:

contract A executes the following code:
...
-> (call to another contract) B.call_something => (success)
-> (call to another contract) C.call_something => (fail)
...

who rolls back the effects of B ? If it's up to A to negate the effects of B then it isn't really the desired out-of-the-box atomicity many have in mind. And there is no isolation, since we might read same data (in external contract) multiple times each time getting different result (since it might be updated concurrently with our transaction running) cause suspention and locking a particular contract call does not "freeze" global state.

Maybe I didn't fully understand "Wasm suspension" or Near execution model.

Update 1:

not sure, though, if receipts from same tree (born from single transaction) can execute concurrently between themselves

I hope I got that ^ right because it isn't that obvious from just reading this doc (I suggest to rephrase/extend it somehow, maybe with my tree analogy).

Based on some examples I found looks like receipts in the same tree (born from same transaction) can indeed execute concurrently with themselves. That doesn't change anything, just a clarification.

Update 2:

Added detailed, potentially promising two-phase commit approach to the list above.

from neps.