[WIP] Spending Condition - New Design Proposal

[pinkiebell]

[WIP] Spending Condition - New Design Proposal

Why

The current design of a Spending Condition Transaction is kind of
annoying to work with. The reason is the UTXO model the user has
to gather/compute and integrate into the transaction itself.
In more complex Spending Conditions who have a set of conditionals,
this task leads to a lot of problems especially computing the first
input for paying gas.

What

I propose a new Spending Condition Design with mimics the design
of the Ethereum root-chain, but still using the UTXO model internally
to be compatible with the existing Plasma chain.

Noteworthy things are:

• Keeps the hassle from the dApp developer site computing UTXO's.
• Existing dApp developers can get started much faster with the Plasma chain,
  as they don't have to wrap around their heads about the UTXO model too deeply.

How

Transaction Design

For the RPC.

[ Standard RLP encoded ethereum transaction - signed ]

Yes, it's the same as on the Ethereum root-chain,
the node can detect if it's a RLP encoded transaction and handle it as the new Spending Condition type.

For the Plasma chain (the real transaction format we pass to tendermint):

[ *maybe* tx type ? ]
[ Standard RLP encoded ethereum transaction - signed ]
[ UTXO Inputs ]
[ UTXO Outputs ]

Gotcha's:

• Signing of the transaction is the same as on Ethereum,
  we use the nonce & network id bytes to guard against replay attacks.
• The to-address is still the same ripemd160(keccak256(bytecode))) as we have now.
• We get a msg.sender we can use in the Spending Condition Runtime.
• Spending Condition needs to be deployed now, but it doesn't becomes a UTXO of any kind.
  It's just for data availability.

Thinks like setting allowance for ERC20 or approval for ERC721, ERC1948, ERC1949 is the same as on
the Ethereum root-chain, but this means we have additional bytes to keep track of in the UTXO outputs.

Tx.Nonce

The Nonce is the total sum of the sender's UTXO's.

Tx.Value

The Ethereum tx-format has a value field. We can use that to implement advanced logic like:

• Only include this tx before block N, drop it after.

Calculating Inputs / Outputs

From the node's point of view, it will execute the Spending Condition and while it executes:

• Intercepts all the calls and validates them.
  Reference: https://github.com/leapdao/solEVM-enforcer/blob/hofmann/test/utils/SpendingConditionRuntime.js#L14
• The source of the data is the BridgeState including all UTXO's.
• The node tries to computes the most efficient Input / Output combination.
  If it fails because the UTXO set is too fragmented or too big, then this transaction will fail.

Notes

The Input & Outputs don't have to be unique as long they are valid.
Assuming a transaction is not included in the next block and going to be queued for upcoming inclusion,
it may be possible that the Inputs & Outputs are not valid anymore at that point in time.
If so, the node can re-calculate that transaction and re-queue it.

Questions

Do we want to store reverted/failed transaction receipts?

View from the node's side of view

The new Spending Condition Runtime will intercept ERC20, ERC721, ERC1948 and ERC1949 calls
and gives the correct results back (TBD).
All UTXO's are accessible to the Spending Condition and can be lazily fetched/computed by the node.

Although all UTXO's are accessible to the Spending Condition, the current limitations of input and output size
still applies, let's call them state changes. The node is responsible to keep track of state changes and
to choose the correct number of inputs and computing the outputs and to deduct the gas fee.
This allows for efficient use of UTXO's and consolidation,

The user -/ developer side of view

The user can now use the same tooling without the need of any extra helper libraries and
basically does not have to worry about the UTXO model.

[MaxStalker]

Please, implement this! ^__^