Remove tx.value in favor of tx.token_values

[IaroslavMazur]

Discussed in #50

^{Originally posted by IaroslavMazur November 26, 2023}
While being useful for backwards-compatibility, the tx.value field, if kept alongside the SabVM-introduced tx.token_values, introduces a fair amount of confusion via the possible "overlap" with the BASE_TOKEN_ID "value" inside tx.token_values.

Here are several disadvantages of this approach that I could think of:

• Having to make sure that if the SabVM-specific tx.token_values and the tx.value are only used exclusively (never together).
• Having to support 2 types (abstractly-speaking) of txs: the ones that leverage tx.token_values - and the ones that only use tx.value.
• The latter tx type from above can also be represented via the former one (with the value for just the BASE_TOKEN_ID token submitted in tx.token_values. This essentially creates redundancy for the system - and confusion for the users and us (the devs), with the very same end result that could be obtained by 2 different tx types.
• Besides just the production code, all of the above would also need to be taken into consideration and maintained in the system tests.

At the same time, the whole "Multiple Native Tokens" paradigm feels like a serious-enough perspective shift that the future users and Application-level Devs should adopt in order to properly understand and interact with SabVM.

@sablier-labs/everybody, wdyat?

[IaroslavMazur]

Closing the issue, as it has been completed in #14

[PaulRBerg]

Will reopen, we close Issues only once PRs are merged

[IaroslavMazur]

Will reopen, we close Issues only once PRs are merged

Noted!

[PaulRBerg]

I have turned this into a discussion because it's less clear now that removing tx.value was a good idea. The question we need to ponder and answer is this:

To what extent will this removal impact backward compatibility, especially with wallets?

My guess is that the answer is "a lot". All EVM wallets pass a value field. By removing it, the SabVM would be incompatible from the get-go with all existing wallets. This is bad.

If my guess is correct, we need to find a more creative solution:

• Keep the standard transaction type (Type 0) unchanged (see this reference)
• Add a new transaction type in the SabVM that is identical to Type 0 except that it has tx.token_ids and tx.token_values instead of tx.value

P.S. you might notice a trend in our latest design choices. We want to ensure maximum EVM compatibility by not altering the default opcodes, and instead building on top or besides them.

[IaroslavMazur]

The fact that we've transformed tx.value into tx.transferred_tokens in TxEnv known to the VM doesn't have to affect the compatibility/interoperability with the external entities (e.g. wallets) interacting with the VM because this interaction is not "direct".

A wallet sends a tx to an RPC provider which, in its turn, either runs a full-fledged Chain Node and is capable of processing/executing the tx itself - or forwards the tx to another node capable of doing this. So, as long as this executing node possesses the necessary knowledge to "explain" to the VM that tx.value is, actually, the tx.transferred_tokens initialized with the BASE_TOKEN_ID-tx.value pair, we should be good to go.

Those RPC providers will all be created by us, though. At least, in the beginning.

A practical example that should also speak to the above is that SabVM is currently passing the Ethereum Tests, even though we've got transferred_tokens - instead of value - as part of a Tx, as viewed by the VM.

This is what concerns the backwards-compatibility.

---

As to the SabVM-specific operations (e.g. a wallet allowing its users to send MNTs in their tx), it does sound like we'll need to introduce another tx type. However, I believe that this doesn't have to have an effect on our VM - and should only be done at the more abstract level (e.g. the SabVM clients/nodes (of which the VM is just one of the parts)).

[PaulRBerg]

Beautiful! Thanks for explaining.

A practical example that should also speak to the above is that SabVM is currently passing the Ethereum Tests

Very nice.

I believe that this doesn't have to have an effect on our VM - and should only be done at the more abstract level

Correct.

[IaroslavMazur]

One note concerning this thread, which has resulted from a technical discussion about SabVM with a friend this weekend:

We can only "adapt" one tx type into the other one (i.e. the value tx into the transferred_tokens one) after all of the private key signature verifications have been performed. Otherwise, the "adapted" tx will, simply, not pass the verifications. (please, let me know if I should elaborate this)

At the same time, it'd be terrible UX to make the user re-sign the adapted tx. Nor would this be possible, honestly, given that this'd require some extra customizations from the wallet provider (which would defeat the purpose of the whole "backwards-compatibility" plan).

So, to counter my previous statement, it seems that we will, actually, need to make the VM aware of both tx types.

However, the good news is that we might be able to only have to make a more abstract level of the VM architecture aware of the tx types, while the core execution layer remains agnostic of them.

[PaulRBerg]

Big-brain observation about the signature verification.

we will, actually, need to make the VM aware of both tx types

Indeed.