feat(SIP-55): Infallible Programmable Transaction Blocks

[admin-aftermath]

No description provided.

[tnowacki]

We have discussed this within Mysten on and off, and we believe that there is something to be done in this space. But it will likely not look exactly like what is described here.
At a high level, you could imagine taking a transaction from being a list of commands Vec<Command> to a list of list of commands Vec<Vec<Command>>, where each inner "transaction" can succeed or fail independently.
And in the first version, you will not be able to share inputs between each inner list/transaction, though this should come eventually. Similarly there might be some gating where can say things like, "Only run this list of commands if the the previous list i failed". In other words, you can gate based on the success/failure status of a previous list/"transaction".

Overall, such a feature would be a large undertaking since it would require rewriting many parts of execution. And we do understand its importance in certain applications.

[tnowacki]

An aside on naming--we view transactions today as being "infallible" since they cannot fail. As such we have been referring to these inner lists of commands as "fallibility regions" or "fallible transactions" since they are allowed to be "wrong" and fail.
The infallibility/fallibility distinction is confusing though and we might just search for another name here.

[admin-aftermath]

This first version already seems like an improvement and definitely a step in the right direction to unlock the different use cases driving this SIP. I like the sound of "fallible regions" or "zones".

Few initial questions:

1. Have you thought about how transaction limits would be enforced? For example, would max_input_args be enforced across the sum of all regions (including potentially non-executed regions) or only across the set of reachable regions?

2. Would gas be charged for failure cases that are not reached? I imagine you would need to charge gas in these cases to alleviate DDoS potential for the objects referenced only in failure regions.

3. Would there be a depth limit for the amount of failure cases? I.e., can we specify a failure case if the failure case fails?

[tnowacki]

1. All limits would be shared across each region, think about it like gas... which takes us to
2. The regions are run sequentially, with the same gas meter being used for each. In the case of failure, we would simply charge the gas used thus far.
3. You could continue to nest these--though we haven't thought through how we want to handle gating in the case where the region was never run (due to its own gating failing)