the shape of mana
posted on 7 Jan 2020This post gives a visual description of the UTXO architecture described in post which introduced manaflow. An important characteristic of the extra functionality is that it does not change the asymptotic validation complexity of a UTXO system - it is the same as Bitcoin.
Below are just a few starter examples of what an output script could accomplish. Note the duality between checking conditions at evaluation time, and “setting” at transaction build time.
- By checking that there is an output whose code is equal to the ‘current’ input code (the code being evaluated), an output could act as a persistent script.
- By checking that there is an output whose code is a prefix of the ‘current’ input code, that output could act as a stateful object.
- By checking that there is an output outside of the ‘current’ input code which matches some condition, the output could act as a factory object.
Note here that ‘persistent’ doesn’t mean that the identifier (the trxID + output number) remains the same. Maintaining a persistent identifier introduces synchronization concerns which would have to be managed by the script itself. In other words, object IDs would be an in-script L2 feature.
In theory, it would require only one additional opcode for Bitcoin to have the same functionality:
OP_PUSH_TX, which would simply put the entire transaction onto the evaluation stack.
More supportive opcodes would push the specific components of interest onto the stack, e.g. the N’th output.
(Note: This post was written one day prior to the author being shown a certain technique… But later we realized the limited utility of forwarding conditions when there is no globally unique identifiers to enable a global state space accessible in L1.).