Considering the response to this ToB researcher, I’m very happy to see this change of perspective and calling convention coming to Tezos.
This brings a similar execution pattern to ETH, and while there will be issues around reentrancy they seem like a price worth paying in order to avoid the issues outlined in the original post from ToB. I can tell you that in Kolibri we tried as hard as we could to avoid calling between contracts due to fears of security issues and a lack of ease when it came to reasoning about them.
In that vein, are there any plans for reentrancy protections built into the protocol itself (possibly a reentrancy lock michelson verb)? Some mitigation controls built in IMO would go a long way towards ensuring that reentrancy issues don’t become systemic.
Replays of on-chain history indicate that this migration does not break the ordinary functionality of any existing live contracts. Because the BFS convention typically provides few useful guarantees, it appears that current contracts deployed on the chain are insensitive to calling order (we speculate that authors just found reasoning about BFS calling order too difficult, so avoided depending on it).
One thing I am concerned with, specifically to Kolibri, is that we have contracts that have functionality we’ve never executed on mainnet (like a global pause button) - have you run this same analysis against delphinet (or any other testnets)?
If not, how can we have any assurances that if (heaven forbid) we do need to hit that button it’ll actually work?
