Paper on Chimeric Ledgers

this link is from a CH tweet:

an interesting read…

5 Likes

BTW: the author “Joachim Zahnentferner” is a pseudonym in respect of the upcoming double-blind peer review. So don’t worry if you can’t google him.

3 Likes

Interesting read indeed. Thanks for the link.

1 Like

As a German-speaker I found that name quite funny :smiley:

2 Likes

Hmmm … I understand the need of a mixed ledger caused by the different type of transaction … But still don’t get the chimera part … Maybe because I have no idea about advanced mathematics

Indeed “Zahnentferner” translates to “Toothremover”

So his name has strong relation to crypto…
Jackass 3 movie: tooth pull with a Lambo. direct to the moon :smiley:

3 Likes

Hello! I was writing a post about this paper for my local Cardano community and kinda stumbled across an idea that the same unification could be achieved with a single transaction type. When something like this happens, I immediately assume that I am not the first one to come up with it, and naturally either: a) I miss something critical in the idea; or b) There are advantages (tradeoffs) to not do it this way and I’m not aware of them.

I really want to find out why exactly such an approach impossible (if so) in order to better understand the subject. I didn’t know where exactly questions about papers should go, so I reckon forum is the best place for it =)

Will appreciate any ideas and clarifications!

UTxO transaction is defined like this:

UtxoTx = (
    inputs : Set[Input],
    outputs : List[Output],
    forge : Value,
    fee : Value)

Where:

Input = (id : Id, index : Int)
Output = (address : Address, value : Value)

Then for “Chimeric Ledgers” unifying transaction types are proposed like this:

DepTx = (
    inputs : Set[Input],
    depositor : Address,
    forge : Value,
    fee : Value)

WithTx = (
    withdrawer : Address,
    outputs : List[Output],
    forge : Value,
    fee : Value,
    nonce : Int)

I wonder, if it would be possible to unify different tx types like this:

A single universal tx type with the same definition as “UtxoTx”

UniversalTx = (
    inputs : Set[Input],
    outputs : List[Output],
    forge : Value,
    fee : Value)

But where inputs\outputs are redefined:

Input = UtxoIn(id : Id, index : Int)
      | AccIn(address : Address, value : Value)

Output = UtxoOut(address : Address, value : Value)
       | AccOut(address : Address, value : Value)

*Different types of outputs are required to differentiate spendable UTxO outputs from unspendable account ones.

Example:

Definitions:

Utxo(<id>#<index>) - UTxO based input
Utxo(<sum>@<address>) - UTxO based output
Acc(<sum>@<address>) - account based input or output

Then transactions could look like this:


Abstract coinbase

Id: 1
Inputs: []
Outputs: [ Utxo(50@1) ]
Forge: 50
Fee: 0

Id: 2
Inputs: [ Utxo(1#0) ]
Outputs: [ Utxo(10@2), Utxo(10@3), Acc(20@1), Utxo(9@1) ]
Forge: 0
Fee: 1

After this transaction there are:

  1. Three unspent outputs: [2#0, 2#1, 2#3] (2#2 cannot be used as input)
  2. One positive balance for account (@1 = 20)

Id: 3
Inputs: [ Utxo(2#3), Acc(7@1) ]
Outputs: [ Utxo(10@2), Acc(5@3) ]
Forge: 0
Fee: 1

After this transaction there are:

  1. Three unspent outputs: [2#0, 2#1, 3#0]
  2. Two positive balances: (@1 = 13) and (@3 = 5)

Validation

Transaction would be valid if:

  1. (∑ inputs) + Forge = (∑ outputs) + Fee
  2. Each Utxo was not previously spent
  3. Each Acc input points to an address with equal or greater balance

Where:

(∑ inputs) = sum([
    Ledger.getTx(inp.id).getOut(inp.idx).value if inp.type = 'UTXO'
        else inp.value for inp in tx.inputs ])

Conclusion

A universal Tx like this utilises even more the general idea that any UTxO-like transaction is kind of a “pool” of value - multiple sources of value are drawn into a single pool and then redistributed out into multiple targets. A tx type like this allows to:

  1. Make multiple account operations to be performed atomically. Like sending coins from a single account to multiple accounts.
  2. Mix UTxO and account operations in a single transaction. User could spend multiple UTxO and send change to his account. Or user could spend multiple UTxO and fill the rest of missing value from his account (like in example 3, where user spends his UTxO of 9 coins and adds 7 coins from account)
  3. Make account inputs and outputs more transparent, since the value to be withdrawn or deposited is directly specified. This allows for easy validation rule.
8 Likes

@vantuz-subhuman, thanks for sharing your universal transaction type. I like it. It deals with utxos and accounts at the level of inputs and outputs, instead of dealing with them at the level of transactions. As such, it is more “hybrid” than the hybrid transaction type presented in the chimeric ledgers paper, which is actually just a generalization of account-based transactions borrowing some ideas from utxo-based transactions.

Your universal transaction type is a super-flexible transaction type. There is one thing to keep in mind, though: sometimes we don’t want to be too flexible. In Cardano’s case, for instance, it is possible (though not decided yet) that only some transaction types will be allowed in some chains (e.g. only utxo in the “settlement layer”, only account-based in IELE’s “computation layer”, and deposit/withdrawal transactions to move funds from one chain to another).

Are you planning to write a paper about your universal transaction type?

3 Likes

Thank you for your reply, @chimeric!

Ok, that was my understanding, I’m glad to get it confirmed. So chimeric transaction are processed in a way that accounts are considered to be on another chain. Do I get it right when I assume then that DepositTx could only be executed on SL and then value would be considered to be removed from this chain, but CL would consider it as incoming value. And then WithdrawalTx could only be executed on CL, an SL would consider it as incoming value?

Ok, I now understand that UniversalTx is not suitable for this use case, cuz it does not consider that DepTx and WithTx are used to move value between chains, and thus does not add any convenience to it, while adding complexity. I agree.

I was mostly just thinking about the nature of both types, and what exactly makes them different. I very like the abstraction idea of UTxO-transactions being just a “redistribution pool”, and so I thought that it’s kinda sad to lose this flexibility when transitioning to accounts.

But I totally see how single-account transactions are more suitable for smart-contract coding. Even though, I must confess, I may have been wondering a few times how interesting it would be to generate UTxO-style transactions in Plutus :slight_smile:

Nooo, I would gladly leave it to Joachim Zahnentferner or some other field professionals to do this, if they ever decide to give it their attention =)

I give you full WTFPL on this idea :+1:

And if it ever proves to be useful for something and makes it into Cardano, I’d be like: https://i.imgur.com/eJ0gAo0.gif

1 Like

@chimeric, I continue to try to understand the full potential and use case for DepTx and WithTx chimeric tx types described in the paper. But could you (or maybe someone else) please clarify just a couple of questions:

Deposits with no change

Deposit transaction is defined like this

DepTx = (
  inputs : Set[Input],
  depositor : Address,
  forge : Value,
  fee : Value)

It means that I can combine multiple UTxO to deposit them into account (CL chain), but in the same time it does not allow to produce UTxO change. It means that if my wallet only have an output from a single transaction - I cannot deposit a partial amount onto CL. Is that planned like this, or is it just omitted from paper?

In my view it would be possible to overcome this limitation by redefining this tx type to include additional field outputs : Set[Output]. But then it would be getting closer and closer in semantics to proposed UniversalTx type :slight_smile:

Withdrawals into multiple UTxOs

Withdrawal transaction is defined like this

WithTx = (
  withdrawer : Address,
  outputs : List[Output],
  forge : Value,
  fee : Value,
  nonce : Int)

This type implies that it would be possible to convert a single-account withdrawal into multiple outputs. But what would be a use case for this? I understand why deposits should be a function from Set[Input] into Address, cuz “balance” of a UTxO-wallet would consist from a collection of outputs, and not a single value - so in order to be able to send your whole balance, you need to be able to combine inputs. But what would be a point of transferring a balance from a single account address and producing multiple outputs, if WithTx is intended to move value from CL to SL but to the same owner?

@vantuz-subhuman

Regarding deposits with no change: yes, it was planned like this. It is not a limitation. If you have a single unspent output in your wallet and you want to deposit only part of it, you can first create a utxo-transaction splitting that output into two (or more) smaller outputs and then create a deposit transaction spending the smaller output(s).

Regarding withdrawals with many outputs, there is no strong reason or use case to allow many outputs or restrict to a single output. Again, it could have been restricted to a single output, and then this single output could have been split into several outputs by a utxo-transaction created after the deposit transaction.

Technically, there are many possible variations of deposit and withdrawal transactions that could be explored. The variants described in the paper tried to stay close to an ATM analogy. When you withdraw cash from an ATM machine, you subtract money from your account and you receive several notes and coins of various denominations. Inspired by this, our withdrawal transaction type allows you to get several outputs of various denominations. Conversely, when you deposit money through an ATM machine (using a machine that allows deposits), the machine typically does not give any change. All the notes and coins that you insert are added to the balance of your account. The proposed transaction types are inspired by the way ATMs work and we hope that this will make them more intuitive to people who are already used to ATMs. So, I think it would be fair to say that, although there is no strong technical reason to choose the particular variant that we chose, there is mild psychological reason in favour of our choice.

2 Likes

This is still under discussion. What you have described is the most likely option, in my opinion, but it has not been decided for sure yet. There are a few other possibilities.

Coincidentally, that is one of the main questions that we are exploring now.

1 Like

Thanks! I would encourage you to write a paper about it anyway. It takes just a bit more of time and skill to write a proper paper, but result is more lasting than a forum post.

Anyway, if we ever have a chance to write about it, we will make sure to give you the credit.

1 Like

Hello, @chimeric, and thank you very much for your answers again!

Ok, now I understand the whole idea of ATM-symmetry, like:

>< = UTxO
-- = Account-based
>- = Deposit
-< = Withdrawal

I agree that it does really look good on paper. But as I understand (and hope) in implementation - some symmetry probably should be sacrificed for utility, and the Deposit transactions will get additional outputs field. Otherwise, in my opinion, it would look weird for user (who does not observe the symmetry of transactions directly) to pay for two transactions, when performing a single operation :slight_smile:

If so - then I get the whole thing finally. Thank you very much for this extremely interesting discussion!

Also, wanted to warn the @chimeric and other people that the website with sources, the paper have link to, seem to run hidden crypto-miner in the background, so should be possibly avoided in the future.

2 Likes

Interesting. Do you know any other anonymous file sharing service that you would recommend instead of gofile?

@chimeric Could you please share a link with the code on chimeric ledgers in Scala and/or haskell, again please? No links work anymore. I am trying to understand the paper, it’s intriguing but hardcore, some code would be welcome as a help

Hi! Turns out I still have a copy of the code, you can find it here:

3 Likes

Man, you rock!

Thanks mate,
I really appreciate it