RFC: Remove parallel balance

[qdrn]

Intro

We currently have two balances: the sequential balance used to transfer Massa and more importantly pay fees for operations and the parallel balance used to transfer coins in the smart-contract world. This RFC proposes to remove the parallel balance, effectively making Massa similar to other blockchains with only a single coin, greatly improving usability.

Constraints

In order to avoid operation censurability we need to be sure that coins used to pay fees can indeed be debited. This imposes that coins from a user address cannot be spent before the operation is included. Otherwise an attacker could emit transactions with an enormous fees, those would take all the place in the created blocks, and then publish a block in a previous slot that move all the funds to another address.

This constraint is enforced on user adresses as coins can only be spent in a given thread. When a staker produce a block, the balance of addresses emitting operations cannot change due to parallel operations and thus the staker is sure that the balance of the address is able to pay the fee.

Suggestion

In this RFC we propose to remove parallel coins. SCs would also use sequential coins. Effectively having only one sort of native coins.

In order to do that securely we need to ensure that coins from addresses that can emit operations cannot be spent in other threads. Those addresses correspond to addresses that have a public key. One way to do that is to disallow to store smart-contract bytecode on those adresses. We can go a bit further by allowing user addresses to store smart-contract bytecode. However this bytecode should not be able to spend the user coins when called from an operation that does not belong to the address' thread.

[qdrn]

cc @damip

[sebastien-forestier]

Sounds good :)

[sebastien-forestier]

In order to do that securely we need to ensure that coins from addresses that can emit operations cannot be spent in other threads. Those addresses correspond to addresses that have a public key. One way to do that is to disallow to store smart-contract bytecode on those adresses. We can go a bit further by allowing user addresses to store smart-contract bytecode. However this bytecode should not be able to spend the user coins when called from an operation that does not belong to the address' thread.

I would go for the first option : simpler, same as Ethereum, less prone to mistakes from developers / unexpected behaviours and failures.

[damip]

I agree. Let's allow externally owned acocunts to store non-executable/non-callable data only.
With account abstraction this might need a little rethink.

[qdrn]

Was it really done like this in the end ? @damip @AurelienFT

[AurelienFT]

Not for now. We can open an issue if we still want to do it and now. This should be easy now that we have the two differents addresses in the code

[qdrn]

I mean it's a (low) security issue so let's open an issue to not forget :)

[AurelienFT]

It has already been done https://github.com/massalabs/massa/blob/main/massa-execution-worker/src/context.rs#L833

[Eitu33]

In order to do that securely we need to ensure that coins from addresses that can emit operations cannot be spent in other threads. Those addresses correspond to addresses that have a public key. One way to do that is to disallow to store smart-contract bytecode on those adresses.

Current implementation handles the first part of this statement but still offers the possibility to store bytecode in a user address.

[Eitu33]

So an address from thread 1 could create an operation that calls a SC contained in a user address of thread 2 (which can spend coins towards any address), this operation would be included in a block of thread 1 but another operation performing the same call and a spend towards another thread could be included in a block of thread 3. So yeah there is an issue.