Neo: Add attachable partial transactions

Created on 4 Nov 2018 · 3Comments · Source: neo-project/neo

One thing that could be very useful to build more decentralized applications is the capability to send multiple transactions simultaneously. This is easy to implement, we just attach a transaction after the other has finished, in deserialisation/serialisation steps. When executing, the Verify method will be called in all "parts" of the transaction, and if one fails, the whole process fails. This simple feature can creating amazing things, such as these examples below.

Example with UTXO trading:
Alice creates and signs the following transaction T1: (i) Inputs: take 100 NEO from address XYZ. (ii) Outputs: receive 900 GAS on address XYZ.
If this transaction T1 is executed independently, it fails (because there are missing NEO outputs and GAS inputs to fulfill transaction). So, here comes Bob...
Bob creates and signs the following transaction T2: (i) Inputs: take 900.1 GAS on address ABC (ii) Outputs: receive 100 NEO on address ABC (iii) attach network fee of: 0.1 GAS
If transaction T2 is executed independently, it fails, for the same reason as T1.
Now, Bob submits transaction T1 attached to transaction T2. When Verify is called, all inputs/outputs from all transactions are joined, and transaction is correct, giving 900 GAS to Alice on XYZ and 100 NEO to Bob on ABC (plus network fee of 0.1 GAS).

Example with NEP-5 trading:
This is similar to the previous example, but it depends on Alice having an empty temporary account WYK.
Alice creates and signs an invocation I1 transfer of 100 token Q1, from WYK to XYZ (she does not have tokens on WYK)
PUSH XYZ (to)
PUSH WYK (from)
PUSH 100
INVOKE Q1
Alice creates and signs an invocation I2 transfer of 900 token Q2, from XYZ (she did not include origin).
PUSH WYK (from)
PUSH 100
INVOKE Q1
Note that both I1 and I2 fail, because she does not have tokens, or because it's incomplete transaction. I2 also includes a mention (attribute) to scripthash of I1.

Here comes Bob:
His job is simple, he creates/signs an invocation I3 of 100 token Q1 from ABC to WYK (including scripthash I1 and I2). He also creates/signs an invocation I4 (mentioning scripthash I3):
PUSH ABC
He submits transaction in the following order: I3 + I1 + I4 + I2.
If scripts are executed in this order, both parts will be happy and exchange their NEP-5 tokens!

Obviously, there can be security implications on leting Bob chose the order of transactions, so probably Alice would include another script to finally sign or perform a multisig with Bob of the whole process (this would require another attribute like Shared Script). Note that this is slightly different process on how current DEX are proposed to work, and probably there are much better ways to do that, I'm just reinforcing how powerful Neo network can be :)

discussion

Source