Multiple Native Tokens #1

IaroslavMazur · 2024-09-05T13:03:43Z

No description provided.

refactor: enhance wording

IaroslavMazur · 2024-09-08T17:33:38Z

@PaulRBerg, ready for your review

Note 1: I've used "assets", instead of "tokens", throughout the EIP, because it feels more appropriate in this context (vs SabVM)

Note 2: The only EIP section that is yet to be written is the Test Case one. However, I believe there's no point in starting to work on it until (and unless) the general idea is approved on the Ethereum Magicians forum first.

Looking forward to your feedback!

PaulRBerg

Thanks, @IaroslavMazur. Here's a log of the high-level changes I made:

I formatted the Markdown using Prettier.
Implemented the changes discussed on Slack, i.e., adding new opcodes as opposed to changing existing ones.
I removed the BALANCES opcode.
I removed all notes about there being a governance process for listing tokens. It's outside the scope of this EIP.
I refactored the EIP to say Multiple Native Tokens instead of Multiple Native Assets because (i) this is what it's said in the SabVM code, and (ii) our design isn't meant to envision NFTs, as opposed to Fuel's design, which does incorporate NFTs
I polished the Motivation, the Rationale, the Backwards Compatibility, and the Security Considerations section
I added a section about Prior Art (i.e. FuelVM inspiration)

And left many other comments below, as well as TODOs in the code.

https://github.com/sablier-labs/sabvm/discussions/19

PaulRBerg · 2024-10-18T14:42:24Z

EIPS/eip-draft_mna.md

+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+A global `token_id` -> `token_supply` mapping is introduced to keep track of the existing NAs and their circulating supply. This mapping is also being used to validate the supported NAs (a NA is supported iff its id can be found in the mapping). The supply of a NA increases as a result of the `MINT` opcode execution - and decreases during the execution of its `BURN` counterparty. The `token_id` of a NA is the Ethereum address of its associated smart contract.
+


Wasn't the token_id obtained by hashing the contract address with a subID?

Yes, it was - in the design of MNTs for our L2.

For Ethereum, however, I think that it'd be better to only allow one-to-one contract-to-NT relations (i.e. a smart contract may only have 1 associated NT). For extra security - and so that every single NT that is being added would have to be explicitly validated/approved (vs approving a smart contract once - and having it create an unlimited number of NTs afterwards).

With this new design, it's no longer needed to obtain the token ids by hashing: given the 1-1 relation, the id/address of the smart contract can simply be the id of the associated NT.

Hmm, I like this proposal but for a different reason, which is: simplicity and the laser-focus on replacing ERC-20s (which is the overarching goal of this EIP).

So OK great, let's keep it like this.

P.S. there might have been a misunderstanding when I asked you to start drafting this EIP. I'm sorry for that.

This EIP wasn't meant to be implemented on Ethereum Mainnet itself. It was meant to be proposed as a cool idea that could be explored in EVM-based rollups.

I clarified this in my latest review of the PR.

EIPS/eip-draft_mna.md

PaulRBerg · 2024-10-18T15:04:19Z

EIPS/eip-draft_mna.md

+
+Note: the burner MUST have a sufficient NA balance to cover the `amount`.
+
+#### `BALANCES` - `0xb2`


I don't think this opcode was part of the original design.

I suggest removing it because it's the kind of opcode that can lead to non-constant time complexity.

Users interested in querying multiple token balances can batch-call the single-token opcode using a tool like Multicall.

The motivation behind the BALANCES opcode was offering the same kind of information about the "VM-recognized value" inside an account as before.

Previously, querrying "all the value" inside an account could be done by calling the BALANCE opcode. Now, it would no longer be as easily obtainable.

The problem with the Multicall approach is that in order to call the single-token BALANCEOF, one would need to know the ids of all of the tokens that the account in question holds. One could not query the balance of a NT that they don't know the account holds.

Subgraphs solve this.

The real solution here is to offer subgraphs natively, at the VM level. But that is outside the scope of this EIP.

An opcode like BALANCES introduces non-constant time complexity, which is anathema for blockchains. So we can't add it.

Related discussion about querying multiple tokens' balances:

When developers learn what kind of piece of shit EVM is to work with

EIPS/eip-draft_mna.md

IaroslavMazur

@PaulRBerg, thank you for reviewing the PR and for your feedback!

I've replied to your comments, implemented the changes I agree with, leaving the rest of the subjects open for debate.

Also, I've left the TODO inside the Abstract section untouched, and am waiting for us to reach a consensus about the rest of the EIP before re-writing the Abstract section.

Notes:

I've removed the DELEGATECALL mentions from the NT-related contexts, because this kind of CALL inherits the transferred tokens from its parent context.
I've renamed the ...2 opcodes to NT...
I've introduced the transferred_tokens_no value in the opcode and tx structure, in order to be able to detect the ill-formed/ill-transported data sequences.

Looking forward to your further feedback!

IaroslavMazur · 2024-10-22T12:21:14Z

EIPS/eip-draft_mna.md


-#### `BALANCES` - `0xb2`
- **Gas**: Dynamic, proportional to the number of NAs owned by the queried account


@PaulRBerg, have you removed the Gas field by mistake?

No, not by mistake. I just think it's overkill to estimate it.

EIPS/eip-draft_mna.md

IaroslavMazur · 2024-10-22T13:02:02Z

EIPS/eip-draft_mna.md

+
+Note: the burner MUST have a sufficient NA balance to cover the `amount`.
+
+#### `BALANCES` - `0xb2`


The motivation behind the BALANCES opcode was offering the same kind of information about the "VM-recognized value" inside an account as before.

Previously, querrying "all the value" inside an account could be done by calling the BALANCE opcode. Now, it would no longer be as easily obtainable.

The problem with the Multicall approach is that in order to call the single-token BALANCEOF, one would need to know the ids of all of the tokens that the account in question holds. One could not query the balance of a NT that they don't know the account holds.

EIPS/eip-draft_mna.md

IaroslavMazur · 2024-10-22T13:29:47Z

EIPS/eip-draft_mna.md

+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+A global `token_id` -> `token_supply` mapping is introduced to keep track of the existing NAs and their circulating supply. This mapping is also being used to validate the supported NAs (a NA is supported iff its id can be found in the mapping). The supply of a NA increases as a result of the `MINT` opcode execution - and decreases during the execution of its `BURN` counterparty. The `token_id` of a NA is the Ethereum address of its associated smart contract.
+


Yes, it was - in the design of MNTs for our L2.

For Ethereum, however, I think that it'd be better to only allow one-to-one contract-to-NT relations (i.e. a smart contract may only have 1 associated NT). For extra security - and so that every single NT that is being added would have to be explicitly validated/approved (vs approving a smart contract once - and having it create an unlimited number of NTs afterwards).

With this new design, it's no longer needed to obtain the token ids by hashing: given the 1-1 relation, the id/address of the smart contract can simply be the id of the associated NT.

PaulRBerg · 2024-10-23T16:23:15Z

Great feedback @IaroslavMazur, and thank you for completing the remaining TODOs. I agree with all of your proposed changes, except:

I've removed the DELEGATECALL mentions from the NT-related contexts, because this kind of CALL inherits the transferred tokens from its parent context.

Interesting. So we don't need an NTDELEGATECALL then?

I've introduced the transferred_tokens_no value in the opcode and tx structure

I've renamed this to transferred_tokens_length, for increased clarity and consistency with how this value is typically referred to in the EVM.

Could you please update the abstract?

IaroslavMazur added 7 commits September 5, 2024 15:56

feat: MNAs EIP V1

48c2ebb

feat: add opcodes specification

f20c886

feat: tx structure spec

8e985b3

refactor: enhance wording

feat: enhance wording

541d195

feat: Rationale

8c8b663

feat: Backwards Compatibility

83ffa0f

feat: Security Considerations

fa3fa41

IaroslavMazur requested a review from PaulRBerg September 8, 2024 17:27

IaroslavMazur marked this pull request as ready for review September 8, 2024 17:27

IaroslavMazur changed the title ~~feat: MNAs EIP V1~~ The EIP on Multiple Native Assets Sep 8, 2024

refactor: prb feedback

9304f1d

PaulRBerg requested changes Oct 21, 2024

View reviewed changes

refactor: review

b4c9f9f

IaroslavMazur commented Oct 22, 2024

View reviewed changes

PaulRBerg changed the title ~~The EIP on Multiple Native Assets~~ Multiple Native Tokens Oct 23, 2024

refactor: more prb feedback

4640cc0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multiple Native Tokens #1

Multiple Native Tokens #1

IaroslavMazur commented Sep 5, 2024

IaroslavMazur commented Sep 8, 2024 •

edited

Loading

PaulRBerg left a comment

PaulRBerg Oct 18, 2024

IaroslavMazur Oct 22, 2024

PaulRBerg Oct 23, 2024

PaulRBerg Oct 18, 2024

IaroslavMazur Oct 22, 2024

PaulRBerg Oct 23, 2024

PaulRBerg Oct 23, 2024

IaroslavMazur left a comment

IaroslavMazur Oct 22, 2024

PaulRBerg Oct 23, 2024 •

edited

Loading

IaroslavMazur Oct 22, 2024

IaroslavMazur Oct 22, 2024

PaulRBerg commented Oct 23, 2024 •

edited

Loading

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

		A global `token_id` -> `token_supply` mapping is introduced to keep track of the existing NAs and their circulating supply. This mapping is also being used to validate the supported NAs (a NA is supported iff its id can be found in the mapping). The supply of a NA increases as a result of the `MINT` opcode execution - and decreases during the execution of its `BURN` counterparty. The `token_id` of a NA is the Ethereum address of its associated smart contract.


		Note: the burner MUST have a sufficient NA balance to cover the `amount`.

		#### `BALANCES` - `0xb2`


		#### `BALANCES` - `0xb2`
		- Gas: Dynamic, proportional to the number of NAs owned by the queried account

Multiple Native Tokens #1

Are you sure you want to change the base?

Multiple Native Tokens #1

Conversation

IaroslavMazur commented Sep 5, 2024

IaroslavMazur commented Sep 8, 2024 • edited Loading

PaulRBerg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

IaroslavMazur left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PaulRBerg Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PaulRBerg commented Oct 23, 2024 • edited Loading

IaroslavMazur commented Sep 8, 2024 •

edited

Loading

PaulRBerg Oct 23, 2024 •

edited

Loading

PaulRBerg commented Oct 23, 2024 •

edited

Loading