Extended UTxO in production: techniques, trade-offs and a search of better balance

Publishing an article prepared for Ergo meetup in Dubai where I analyze my experience of building DeFi (and not only) on eUTxO and trying to come up with a better framework as part of research for Spectrum Network.

  1. When you do State.Copy(), is the unchanged state data still included in the new TX or just the new data being changed, I was confused a bit by the wording? If the latter, then how does information get propagated over time/how do you access unchanged data?

  2. Is it correct to interpret Ref = Stable x Version as being the new box id or is that just Version? So there are now multiple ways to reference an eUTXO?

1 Like
  1. State (box) which is consumed by the transaction is already available in the ledger, thus transaction only contains instructions on how to modify it to produce new version of that piece of state.
  2. Yes, that’s the idea. Static and dynamic way of referencing utxo
1 Like

As inputs and outputs are already encoded in transaction differently (outputs are encoded as ergo box candidates, so boxes without transaction id and output number), maybe, it is enough to inject alternative encoding there, which would contain input index and only registers changed? The only issue is that input boxes are needed to get transaction hash, which would complicate clients, but bandwidth and storage would be optimized.