the shape of mana

posted on 7 Jan 2020

This 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.

picture comparing bitcoin vs manaflow transaction

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.).