Optimistic Input
submission
#4
paluh
started this conversation in
Marlowe Improvements
Replies: 1 comment
-
Of course this approach can open up a can of worms like - possible "transaction size lock" attack. We should probably restrict this approach significantly and the policy should be parameterized by the restriction. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One of the limitations of the current execution flow of Marlowe contracts on chain is its inability to easily handle different orderings of
Inputs
which permutations (like deposits) preserve the same semantics. We solve this usually by introducing permutations to the contract itself and relying on the merkleization (this works fine but moves parts of theContract
handling offchain - users have to provide their own safe storage beside the ledger).This is a bit speculative but it seems that without singnificant changes to the main validator (we should allow
noop
tx) we should be able to implement optimisticInput
submission which can be reclaimed at any point or used at appropriate time during contract execution. The idea can be possibly implemented by using approach similar tovalidatorToken
which was described here:https://github.com/input-output-hk/MIPs/pull/1/files#r931122201
and its "stepper" extension which was shortly discussed here:
https://github.com/input-output-hk/MIPs/pull/1/files#r932891000
In principle "optimistic
Inputs
" could be handled through (possibly additional) "enhanced" minting policy script which optionally allows this and dedicated small spending validator forUTxO
carrying this futureInput
which allows application at an appropriate time (if valid) or reclaim of theInput
. Of course I'm not entirely sure how hard it is gonna be to implement.Do you find this idea interesting? Do we want to explore this area of design space?
Beta Was this translation helpful? Give feedback.
All reactions