Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/esdt prefix #6137

Open
wants to merge 180 commits into
base: rc/v1.7.next1
Choose a base branch
from
Open

Feat/esdt prefix #6137

wants to merge 180 commits into from

Conversation

mariusmihaic
Copy link
Contributor

@mariusmihaic mariusmihaic commented Apr 23, 2024

Reasoning behind the pull request

This branch includes several cross chain features needed for main chain(mainnet/devnet/testnet/local-testnet) -> sovereign chain communication:

  1. Added a config possibility to have your chain issue tokens with a specific prefix (unique ID used for each sovereign chain)
  2. We will use the same token and tokenID (no wrapping) for tokens that are going to be bridged across different chains. Therefore, when depositing tokens from one chain to another, we need to whitelist specific addresses which can mint those tokens. This is also possible using specific config addresses.

More specifically, let's consider a mainnet scenario, where this deposit safe contract is deployed (therefore, all issued esdts will have no prefix). Now, if we want to mint extra esdts/nfts/sfts, this won't be possible, only through our whitelisted address. Our use case is that a user will call an endpoint deposit from this sc, which will contain several information including tokenID and amount to deposit to a specific address. This contract shall be allowed to mint required token amount(with the same tokenID and prefix) and send them to destination.

Same scenario should work for a sovereign chain(where the config specifies that the chain will issue tokens with a specific ESDTPrefix) and where we will deposit unprefixed tokens.

Another interesting use case is for cross chain sfts/nfts(basically a token with meta data and nonce). For those specific bridged in(from sov->main) tokens, a different type of input for builtInFunc from esdtNFTCreate will be created and executed. More specifically, for cross chain operations, last two arguments should be(these are added from inside the whitelisted address, if not, tx should fail):

  • original token nonce
  • original creator address

Also, use cases with "proxy" contracts (e.g.: user calls -> contract A -> calls ESDTSafe(whitelisted) contract) should work only for whitelisted addresses and meta data should be correctly filled.

The same bridged in meta data (from sov->main) should be found in the contract emitted log when bridged out (main->sov) .

This is the list with all whitelisted cross actions that should be tested:

	-ESDTRoleLocalMint
	-ESDTRoleNFTAddQuantity
	-ESDTRoleNFTCreate
	-ESDTRoleLocalBurn
	-ESDTRoleNFTBurn

Proposed changes

  • Added possibility to issue tokens with prefix(which will be followed by - separator)
  • Each prefix should have max 4 characters (lower and alphanumeric only)
  • In cmd/node/config/systemSmartContractsConfig.toml:
[ESDTSystemSCConfig]
    BaseIssuingCost = "5000000000000000000" #5 eGLD
    OwnerAddress = "erd1fpkcgel4gcmh8zqqdt043yfcn5tyx8373kg6q2qmkxzu4dqamc0swts65c"
    ESDTPrefix = ""

Whitelisted addresses can be found in cmd/node/config/config.toml

[VirtualMachine]
    [VirtualMachine.Execution]
        ....
        TransferAndExecuteByUserAddresses = [ # TODO: set real contract addresses for all shards
            "erd1qqqqqqqqqqqqqpgqr46jrxr6r2unaqh75ugd308dwx5vgnhwh47qtvepe3", #shard 0
        ]

Testing procedure

  • All possible "crazy" scenarios should be tested, especially "happy path" scenarios. Whitelisted deployed addresses shall be precomputed and set in config. We need specific contracts deployed for these actions. We can start by using bridge contracts used for sovereign, which will be the main use case, see https://docs.multiversx.com/sovereign/setup. For any help setting up contracts, please contact @andreiblt1304 & @axenteoctavian
  • We will probably need multiple testnets to run in parallel with different scenarios(some with prefixed tokens and some without)

Pre-requisites

Based on the Contributing Guidelines the PR author and the reviewers must check the following requirements are met:

  • was the PR targeted to the correct branch?
  • if this is a larger feature that probably needs more than one PR, is there a feat branch created?
  • if this is a feat branch merging, do all satellite projects have a proper tag inside go.mod?

@mariusmihaic mariusmihaic self-assigned this Apr 23, 2024
Copy link

📊 MultiversX Automated Test Report: View Report

🔄 Build Details:

  • mx-chain-go Commit Hash: c07db4cbacd62f26a264931468d3ab098bcdda57
  • Current Branch: feat/esdt-prefix
  • mx-chain-go Target Branch: rc/v1.7.next1
  • mx-chain-simulator-go Target Branch: rc/v1.7.next1
  • mx-chain-testing-suite Target Branch: rc/v1.7.next1

🚀 Environment Variables:

  • TIMESTAMP: 17102024-114409
  • PYTEST_EXIT_CODE: 0
    🎉 MultiversX CI/CD Workflow Complete!

Copy link

github-actions bot commented Nov 7, 2024

📊 MultiversX Automated Test Report: View Report

🔄 Build Details:

  • mx-chain-go Commit Hash: eaae00cdae56429997474ceca1ee76d06a130f7c
  • Current Branch: feat/esdt-prefix
  • mx-chain-go Target Branch: rc/v1.7.next1
  • mx-chain-simulator-go Target Branch: rc/v1.7.next1
  • mx-chain-testing-suite Target Branch: rc/v1.7.next1

🚀 Environment Variables:

  • TIMESTAMP: 07112024-125540
  • PYTEST_EXIT_CODE: 0
    🎉 MultiversX CI/CD Workflow Complete!

Copy link

📊 MultiversX Automated Test Report: View Report

🔄 Build Details:

  • mx-chain-go Commit Hash: 139e848e9a995ce20fe6f03751bb7ba7d2c286fc
  • Current Branch: feat/esdt-prefix
  • mx-chain-go Target Branch: rc/v1.7.next1
  • mx-chain-simulator-go Target Branch: rc/v1.7.next1
  • mx-chain-testing-suite Target Branch: rc/v1.7.next1

🚀 Environment Variables:

  • TIMESTAMP: 12112024-125615
  • PYTEST_EXIT_CODE: 0
    🎉 MultiversX CI/CD Workflow Complete!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants