Currently, the code of contract is implemented using the StandardClause class, which take (among other things) a CScript. That means that the entire Script of each spending condition is written by hand.
It would be great to experiment with a 'composable' version of a StandardClause, that semantically builds good-quality (ideally, optimal) Scripts from simpler components.
Most such scripts end up being just an AND of smaller spending conditions.
It is easy to compose two Scripts (and the code to generate the witness) if their witnesses are not overlapping: if Script1 is satisfied with witness W1 and Script2 with witness W2, then W2 | W1 is a valid witness for Script1 OP_VERIFY Script2 (where the OP_VERIFY might possibly be merged with the last opcode of Script1, e.g. OP_EQUAL OP_VERIFY => OP_EQUALVERIFY).
However, many scripts might check conditions on the same witness elements; that is, W1 and W2 might contain some of the same elements. Instead of duplicating such elements, the composed Script should be adapted to minimize the waste; that seems substantially harder, but it might simplify a lot the creation of a composable framework for contracts.
A framework for symbolic Script execution might perhaps be used to detect such witness duplication, and automatically transform the Scripts in a way that preserves the semantic meaning. It might also be useful for other Script optimization tricks.
Remark: Care needs to be taken to make sure that the stack limit (or other consensus and standardness limits) are respected in the composed Scripts.
Currently, the code of contract is implemented using the
StandardClauseclass, which take (among other things) aCScript. That means that the entire Script of each spending condition is written by hand.It would be great to experiment with a 'composable' version of a
StandardClause, that semantically builds good-quality (ideally, optimal) Scripts from simpler components.Most such scripts end up being just an
ANDof smaller spending conditions.It is easy to compose two Scripts (and the code to generate the witness) if their witnesses are not overlapping: if
Script1is satisfied with witnessW1andScript2with witnessW2, thenW2 | W1is a valid witness forScript1 OP_VERIFY Script2(where theOP_VERIFYmight possibly be merged with the last opcode ofScript1, e.g.OP_EQUAL OP_VERIFY => OP_EQUALVERIFY).However, many scripts might check conditions on the same witness elements; that is,
W1andW2might contain some of the same elements. Instead of duplicating such elements, the composed Script should be adapted to minimize the waste; that seems substantially harder, but it might simplify a lot the creation of a composable framework for contracts.A framework for symbolic Script execution might perhaps be used to detect such witness duplication, and automatically transform the Scripts in a way that preserves the semantic meaning. It might also be useful for other Script optimization tricks.
Remark: Care needs to be taken to make sure that the stack limit (or other consensus and standardness limits) are respected in the composed Scripts.