You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, the code of contract is implemented using the
StandardClause
class, 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
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 witnessW1
andScript2
with witnessW2
, thenW2 | W1
is a valid witness forScript1 OP_VERIFY Script2
(where theOP_VERIFY
might 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,
W1
andW2
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.
The text was updated successfully, but these errors were encountered: