RFC: UTXO Model #11
RFC: UTXO Model #11
Conversation
| - the ``Inputs`` which defines a list of ``OutputIDs`` that reference the *consumed* ``Outputs`` from previous | ||
| transactions (or the genesis). | ||
| - the ``Outputs`` which defines where and how many of the consumed tokens are moved. | ||
| - the ``Unlock Section`` that contains data used to *unlock* the consumed inputs and *authorize* spends (usually just |
There was a problem hiding this comment.
Shouldn't we also have a lock section?
| To build a bridge between the worlds of *UTXO-* and *account-based* ledgers, we define our UTXO variant to use | ||
| addresses instead of output indexes as this additional identifier: | ||
|
|
||
| ``OutputID = Pair<Address, TransactionID>`` |
There was a problem hiding this comment.
Do you want to have 2 indexes for the output to be used internally by the node when it tracks utxos?
Or do you want this to be the actual id to be used inside the transaction that we create?
I understood that you want the latter. If so, I just don't understand the motivation. I think it just bloats up the transaction. If I understood correctly, then could you please elaborate on why it is useful?
|
|
||
| ``OutputID = Pair<Address, TransactionID>`` | ||
|
|
||
| All **colored balances** sent to the same address (by the same transaction) becomes part of the same output. |
There was a problem hiding this comment.
Clarification:
Colored balances include or don't include the base color?
I assume that no since you highlighted this, but then why should they behave differently?
| - ``COLOR_MINT = Array<byte>(255, 255, 255, ..., 255)`` represents a color which is being replaced by the | ||
| ``Transaction ID`` before being booked as an output. It is consequently used to "mint" new colored coins. |
There was a problem hiding this comment.
Transaction ID will become a color?
I think I need more clarifications here 😅
Didn't really understand this line
There was a problem hiding this comment.
This definitely needs a more explanation preferably in a separate RFC only talking about colored coins
| In contrast to bitcoin, we do not add a fully scriptable outputs (because that could result in long execution times), | ||
| but we offer predefined methods for different use cases. |
There was a problem hiding this comment.
What I understood is that by using OP + OPCodeMetadata instead of a script, you limit one op code use per output. We also don't have a stack.
Did I understand correctly?
About the long execution times, I guess that if we will use a script instead we can simply have a max length limit on it.
This would solve the problem no?
Even if it does, I don't know yet whether I am for scripts or not..
However, every time we would want a new functionality, people running old node version won't support it.
With scripting it will be more versatile, so we need to take this into account
|
|
||
| - A transaction is valid, if the sum of the moved funds is ``0`` and it only spends colors in the amounts that were | ||
| available in the used inputs. It is however possible to override the color of the consumed tokens using either the | ||
| ``MINT_COLOR`` color to create a new colored token or by using the ``IOTA_COLOR`` to remove the color. |
There was a problem hiding this comment.
I really don't understand the whole IOTA colored coins concept
So if I color a coin and then transfer it to you, then you could change the color or even remove it?
Don't understand the use-case here
There was a problem hiding this comment.
I really think a separate RFC would help here. There we should also motivate the whole idea behind this particular concept.
|
|
||
| Instead of having to walk through multiple transaction to eventually find the spent balance in the tangle, we can now | ||
| instantly load the corresponding funds by accessing the consumed outputs. A transaction that tries to spend non-existing | ||
| funds would never become solid. |
There was a problem hiding this comment.
you mean valid no?
Or has the definition for solid change to include validity and I didn't know about it :-P ?
There was a problem hiding this comment.
This has nothing to do with validity.
If I create a transaction that references an output Pair<AddressX, TransactionQ> but I haven't received TransactionQ, yet then this means that the outputs of TransactionQ are also not existing and it is not solid.
If I receive the TransactionQ later on then it becomes solid and can be booked. If it is however referencing an output that does not exist, then it will simply stay unsolid until it gets cleaned up.
There was a problem hiding this comment.
I stumbled over "solid" as well as an unfamiliar term.
Maybe add a note or footnote or something.
| # Unresolved questions | ||
|
|
||
| - We need to think about good unlock opcodes and options. | ||
| - We should define a PR that specifies the "branch based ledger state" as this is very closely related to the |
There was a problem hiding this comment.
a few words or a link on "branch based ledger state"?
There was a problem hiding this comment.
I think that concepts like reality/branch based ledgers is many layers away from plain UTXO transactions and relies on much more concepts. So, this should not be mentioned as an unresolved question for plain UTXO at all.
| The UTXO model uses a different form of record keeping which enables the validation of transactions in constant time | ||
| `O(1)` and vastly improves the "expressiveness" of the ledger state by enabling things like: |
There was a problem hiding this comment.
The time complexity depends on the implementation and not the model, so I would just remove it for the following reasons:
- There is no algorithm given.
- O(1) is technically not correct it could at most be O(#consumers) as the consumers are part of the input.
- There are also implementation of the account model that achieve the same time complexity albeit it requires prepossessing and much larger space complexity.
UTXO indeed gives you a much more "local" and "direct" view on the validity:
- Outputs can be used at most once
- Transactions consuming an output must consume it "entirely"
- When it is cashed whether a past transaction is valid, only #consumer lookups are needed to check validity of new transaction
| + regulatory compliant tokenized assets | ||
|
|
||
| + ... | ||
|
|
There was a problem hiding this comment.
Consider adding Replay Protection to this list. At least in our context that was another strong motivation for UTXO
| and spent individually. This allows to exactly specify which funds are getting moved even if multiple parties are | ||
| funding an address in parallel. | ||
|
|
||
| A transaction moving funds consists out of three building blocks: |
There was a problem hiding this comment.
This could be a bit misleading. In this section the fields of a transaction are only described "building blocks". As a motivation/introduction this is perfectly fine, but consider adding description of the transaction using the notation used below ({Field: value, ... })
|
|
||
| A transaction moving funds consists out of three building blocks: | ||
|
|
||
| - the ``Inputs`` which defines a list of ``OutputIDs`` that reference the *consumed* ``Outputs`` from previous |
There was a problem hiding this comment.
Having a list of OutputIDs implies a switch from bundles to atomic transactions. This is a huge step, maybe mention this explicitly here or in the motivation.
| To build a bridge between the worlds of *UTXO-* and *account-based* ledgers, we define our UTXO variant to use | ||
| addresses instead of output indexes as this additional identifier: | ||
|
|
||
| ``OutputID = Pair<Address, TransactionID>`` |
There was a problem hiding this comment.
OutputID is not well-defined:
- What exactly is
Pair? And why are we using aPairhere instead of e.g.{Address: ..., TransactionID:...} TransactionIDis never mentioned before. There should be at least one sentence introducing it, especially since it cannot depend on every field in a transaction (including the outputID) without causing circular dependencies.- What types do
AddressandTransactionIDhave? This is the only description with a type.
| # Drawbacks | ||
|
|
||
| - A UTXO-based ledger is much more complex in the implementation than just a dictionary of balances. | ||
| - A UTXO-based ledger stores more information and therefore requires "potentially" more disk space. |
There was a problem hiding this comment.
In this section we go from UTXO might require more space to UTXO might require less space. Can we be more precise here? Under which exact conditions does it require more under which less? If we are unsure about this consider remove this point completely.
| - Accordingly, a transaction is performing a double spend when there is already another transaction consuming the same | ||
| output. | ||
|
|
||
| # Drawbacks |
There was a problem hiding this comment.
Should we maybe refer to Ethereums rationale that UTXO introduces "states" even for one address/account making it more complicated in smart contracts?
| - Accordingly, a transaction is performing a double spend when there is already another transaction consuming the same | ||
| output. | ||
|
|
||
| # Drawbacks |
There was a problem hiding this comment.
Should we mention "fungibility" as a drawback, since with UTXO the origin of every coin can be derived?
| # Drawbacks | ||
|
|
||
| - A UTXO-based ledger is much more complex in the implementation than just a dictionary of balances. | ||
| - A UTXO-based ledger stores more information and therefore requires "potentially" more disk space. |
There was a problem hiding this comment.
Transaction will definitely get larger: everything that can expressed with one input in the account model needs at least one input in UTXO. Thus, UTXO tx size ≥ account tx size.
| # Unresolved questions | ||
|
|
||
| - We need to think about good unlock opcodes and options. | ||
| - We should define a PR that specifies the "branch based ledger state" as this is very closely related to the |
There was a problem hiding this comment.
I think that concepts like reality/branch based ledgers is many layers away from plain UTXO transactions and relies on much more concepts. So, this should not be mentioned as an unresolved question for plain UTXO at all.
|
superseded by #18 |
Rendered Version