Does/can Aiken support suspension/resumption of contracts execution?

[abailly]

I am currently working in my spare time on hydra-chess, which is an experiment on using Cardano to run strategy games. I initially thought of using Hydra L2 because it allowed me to inflate execution budget which is needed to verify the validity of a play in the game¹, but this solution is somewhat unsatisfactory.

I am now thinking of a solution whereby players would exchange pre-signed transactions that could be posted on L1 but only if there's a contestation or one player becomes unresponsive. This still leaves the problem of ensuring a play is valid open, and that's how I came to think that a possible solution would be to split the computation across a chain of transactions, with the contract code being "suspended"/"resumed" until it reaches the desired end state. This is similar to how Marlowe works.

In general, have a way to split complex computations across transactions seems a useful pattern. Is this something Aiken devs thought about?

Footnotes

1. Side note: there could be ways to optimise the validation in such a way that it would fit under existing constraints in the particular case of Chess game which has relatively simple rules, but that's not the point as I ambition to put more games on-chain whose rules are far more complicated than Chess's, eg. [Diplomacy](https://en.wikipedia.org/wiki/Diplomacy_(game) ↩

[KtorZ]

That's not something that is readily available out-of-the-box; but Aiken provides various tools to implement something like Merkleized validators:

• A library to deal with Merkle Patricia Trie (https://github.com/aiken-lang/merkle-patricia-forestry)
• Parameterized validators (https://aiken-lang.org/language-tour/validators#parameters)
• Possibly also, environments and configurations (https://aiken-lang.org/language-tour/modules#conditional-modules)

[abailly]

Actually, I think what I want can be achieved in a relatively simple way, if I had a way to run a validator until some budget limit is reached, and have the interpreter return its "state". If a validator is a function from a datum and redeemer to a value, and it's valid if the computed value is unit, then given an execution budget target I can run the interpreter run and stop with a result either that it succeeded, or the current state. In the latter case, I can serialise the current state in a datum, create a transaction outputting this datum, and continue the computation with another transaction computing that datum.