RFC: Transfer coins between parallel and sequential balances

[damip]

RFC: Transfer coins between parallel and sequential balances

Intro

There is currently no easy and ubiquitous way to transfer coins between the parallel and sequential balances, back and forth.

Constraints

• sequential coins can only be spent from operations, and only in their own thread
• fees must be paid only with sequential coins
• protocol staking must remain separate from the smart contract world

CallSC, ExecuteSC, Transactions

• the "coins" parameter (or amount transferred in the case of transactions) should be split into:
  • "source_parallel_coins" indicating how many parallel coins from the sender need to be spent
  • "source_sequential_coins" indicating how many sequential coins from the sender need to be spent
  • "target_parallel_coins" indicating how many parallel coins need to be credited to the target
  • there is no "target_sequential_coins" because it can be computed as target_sequential_coins = source_parallel_coins + source_sequential_coins - target_parallel_coins
• inside the called smart contracts, the "coins" contextual info should be split into "parallel_coins" and "sequential_coins" to indicate the amount of each that was credited at the execution/call

Inside smart contracts

• coin transfers can only spend the parallel balance, but they should allow choosing how much to credit on the target parallel and sequential balances
• the "coins" parameter of the async messages, coin transfers and calls should be split into "parallel_coins" and "sequential_coins"
• inside the called smart contracts, the "coins" contextual info should be split into "parallel_coins" and "sequential_coins" to indicate the amount of each that was credited at the execution/call

[AurelienFT]

I find the splitting of coins in 3 variable and an other deducted too heavy for developers. Maybe can we have a default behaviour that transfer only one of both (sequential/parallel)

[jwmdev]

@AurelienFT I somewhat agree with your opinion. Can you give more detais about this:
Maybe can we have a default behaviour that transfer only one of both (sequential/parallel)
Explain how this is invisioned to work?

[jwmdev]

@damip Thanks for this RFC. First, I agree with the three parameters and the derived one. However, following @AurelienFT comment,
I find the splitting of coins in 3 variable and an other deducted too heavy for developers. Maybe can we have a default behaviour that transfer only one of both (sequential/parallel)

I'm of the opinion that each operation should have default behaviour of crediting and debiting either sequential or parallel. That is for CallSC and ExecuteSC operations. Only Transaction operation should deal with the four [source_parallel_coins, source_sequential_coins, target_paralle_coins, target_sequential_coins ] parameters.

Or if we prefer, we can split the Transaction Operation into two operations, namely, Send Operation, and Transfer Operation. The Send operation can have default behave of sending the sequential coins like the current Transaction Operation, and the Transfer operation should deal with the four parameters [source_parallel_coins, source_sequential_coins, target_paralle_coins, target_sequential_coins ]. This looks like repeating ourself and violets DRY principal, but on the other hand, it will separate the two operations and transfer operation will only be used for specific usecases. Other operations will likely be using a few of the four suggested coin paramaters.

[sebastien-forestier]

#2952