I would like to continue the discussion about concurrency/BFS vs DFS, as described
I understand that moving to message passing (all effects are final
before operations are executed) solves the problems of
control-flow in Ethereum. An alternative would be to have
call-return without effects (only fail/no-fail) or limited effects
after the return. This limited call-return enables useful patterns
like defensive programming using monitors/runtime-verification as
pointed out in https://forum.tezosagora.org/t/monitors/1982
In a nutshell, one can write “checkers” (even written by independent
developers as a wrapper) that inspect the effect of the whole smart
contract invocation and decide to accept or abort.
Is there any reason beyond sharding to prefer BFS over DFS? Again,
DFS is more natural to think about and it would another way to
I would like to suggest an alternative to sharding that can be used
both in DFS and in BFS (effectively making DFS efficient). Ideally,
if one knew the effects of all sub-operation generated by a
contract many call sequences (whose semantics are sequential) could
be run in parallel. However, Without formally proven contracts this
is not feasible.
But, inspired by optimistic concurrency control, one can just
assume that calls are independent and run them in parallel. Since
the effects are of course known after the execution, one can check
after the facto whether the parallelization was to optimistic, and
(if necessary) re-run the whole tree (this time with more knowledge).
By the way, this method of run-and-check can be used with
BFS+tickets. In my view, as discussed in
Contract signatures since
tickets have an immediate global effect (e.g PUNCH) this would
jeopardize sharding (as an operation can depend on whether a
previous operation PUNCHED a shared ticket).
What do you think?