Upon finishing last open transaction design, I’ve been receiving some feedbacks. One particularly interesting comment, is the open transaction design is far too complex, it also includes one minimal, quirky, custom designed language for writing small programs. This brings both onboarding and auditing issues. So the question comes down to: can we leverage the same smart contract knowledge we have now, in open transaction design?
Turns out with the coming exec spec, we can indeed build such an open transaction design.
We can leverage the same open transaction lock script design as previous one:
Code hash: composable open transaction script code hash
Hash type: composable open transaction script hash type
Args: <21 byte identity>
The trick actually lies in the witness part. Instead of the old weird hash array, we can have a witness data structure like following:
<32 byte code hash><1 byte hash type><n bytes argument><65 byte signature>
The signature included here, only covers the data preceeding signature, in the witness data structure, this means only the included code hash, hash type and argument are hashed and validated against in the signature. After signature validation, the open transaction lock script would first locate a cell in cell dep using specified code hash, and hash type, then invoke an exec syscall, using argument as the first argument in argv. This way the control is turned to a runtime determined script, to validate against the open transaction validation logic.
This way, we are reusing all existing knowledge we have to design an open transaction program, no weird small quirky language is used.
In case you are still wondering, this is now the end of the new open transaction design 