From 48c2ebbdca906c16cf4bc3a9e934c1e59aa555e7 Mon Sep 17 00:00:00 2001 From: Iaroslav Mazur Date: Thu, 5 Sep 2024 15:56:37 +0300 Subject: [PATCH] feat: MNAs EIP V1 --- EIPS/eip-draft_mna.md | 126 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 EIPS/eip-draft_mna.md diff --git a/EIPS/eip-draft_mna.md b/EIPS/eip-draft_mna.md new file mode 100644 index 0000000000000..aba1026a53899 --- /dev/null +++ b/EIPS/eip-draft_mna.md @@ -0,0 +1,126 @@ +--- +title: Multiple Native Assets +description: Introduces Multiple Assets, recognized by the VM alongside ETH +author: Paul Razvan Berg (@PaulRBerg), Iaroslav Mazur (@IaroslavMazur) +discussions-to: https://ethereum-magicians.org[] +status: Draft +type: Standards Track +category: Core +created: 2024-09- +--- + +## Abstract + +This EIP introduces changes to the EVM, making it recognize Multiple Native Assets (MNAs). ETH is made one of the Native Assets (NAs), while retaining its unique status in terms of how it is minted/burned, as well as remaining the only Native Asset (NA) that can be used to pay for EVM gas. +`MINT` and `BURN` opcodes are introduced to control the supply of NAs. The `CALL` and `CALLCODE`, `CREATE` and `CREATE2`, `BALANCE` and `CALLVALUE` opcodes are adapted to support NAs transfer, the NA-infused contract creation and the querying of the NAs-related information, respectively. +The `data` field of the transaction structure is adapted to support a collection of (`asset_id`, `asset_amount`) pairs. + +## Motivation + +The introduction of MNAs into the EVM addresses several limitations and inefficiencies present in the current Ethereum architecture, where ETH is the sole native asset. While ETH has served as the foundation for gas payments and the primary store of value within the ecosystem, the growing complexity of decentralized applications, decentralized finance protocols and cross-chain integrations has highlighted the need for a more versatile native asset system. Here are some of the main advantages of implementing MNAs in Ethereum: + + ### Enhanced Flexibility and User Experience: + + As the Ethereum ecosystem continues to expand, dApps and protocols increasingly require more specialized economic models that rely on native assets. Currently, developers must create and manage custom tokens via ERC standards, which are less efficient and more complex (read: "unreasonable") to integrate natively into the EVM. MNAs allow for the direct implementation of diverse native assets within the EVM, simplifying development and enabling new types of applications, such as native stablecoins, governance tokens or protocol-specific assets. + + ### Support for DeFi and Financial Innovation: + + #### Native Support for Financial Instruments: + + DeFi protocols heavily rely on various assets, including stablecoins and derivative tokens. Natively supporting these assets within the EVM enhances their integration, improves performance, and reduces the need for complex workarounds. This support enables more efficient liquidity provision, trading, and collateralization mechanisms, which are critical for the continued growth and innovation of DeFi. + + #### Facilitating Cross-Chain and Multi-Asset Solutions: + + As the blockchain ecosystem becomes increasingly interconnected, the ability to natively support multiple assets within the EVM positions Ethereum as a more versatile and integrative platform. This capability is crucial for enabling seamless cross-chain interactions and creating new financial products that leverage assets from multiple blockchains. + + ### Improved Reliability via Consistent Asset Handling: + + Natively recognizing multiple assets within the EVM ensures consistent and reliable asset handling across all transactions and smart contracts. This standardization simplifies development, testing, and auditing processes, leading to more secure and predictable interactions. + +## Specification + +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. The supply of a NA is increased during the execution of the `MINT` opcode - and decreased during the execution of its `BURN` counterparty. + +`ETH` becomes the "Base Asset" with the id and supply both equal to 0. `ETH` is the only NA with its supply not being tracked explicitly (i.e. the `ETH` supply is being determined just like it currently is). + +The addition of new NAs is being decided via a consensus expressed by the ETH validators. For security and consistency reasons, the smart contracts representing the NAs MUST NOT be mutable/upgradeable. + +### New Opcodes + +#### `MINT` + +#### `BURN` + +### Modified Opcodes + +#### `CALL` + +#### `CALLCODE` + +#### `CREATE` + +#### `CREATE2` + +#### `BALANCE` + +#### `CALLVALUE` + +### Transaction structure + + + +## Rationale + + + +TBD + +## Backwards Compatibility + + + +No backward compatibility issues found. + +## Test Cases + + + +## Security Considerations + + + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).