Added docs for contract interactions using abi file through mxpy #980
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| You'll need **pipx** installed on your machine. For more details on how to install **pipx** check out [**this page**](https://pipx.pypa.io/stable/#install-pipx). | ||
|
|
||
| :::note | ||
| If you've previously installed **mxpy** using **mxpy-up** and you'd like to switch to **pipx**, make sure to remove the old `mxpy` shortcut and virtual Python environment beforehand: | ||
| If you've previously installed **mxpy** using **mxpy-up** we advise you to switch to **pipx**, but make sure to remove the old `mxpy` shortcut and virtual Python environment beforehand: |
There was a problem hiding this comment.
Maybe a comma after "If you’ve previously installed mxpy using mxpy-up", to help separate the introductory clause from the main part of the sentence.
| ## **Upgrade mxpy using pipx** | ||
|
|
||
| To upgrade **mxpy** to a newer version you can simply run the following command: | ||
| Aditionally, if you'd like to have shell completion for `bash` and `zsh` run the following command then restart the shell: |
There was a problem hiding this comment.
- The word
additionallyis misspelled; - A comma after
bash and zshhelps separate the introductory clause; - A comma before
thenmight improve readability.
|
|
||
| If you've previously installed **mxpy** using the legacy **mxpy-up**, you should switch to the **pipx** approach. Make sure to remove the old `mxpy` shortcut and virtual Python environment beforehand: | ||
| To upgrade **mxpy** to a newer version you can simply run the following command: |
There was a problem hiding this comment.
A comma after version might improve readability.
| For example, to install `rust`, you can simply type the command: | ||
|
|
||
| ```sh | ||
| mxpy deps install rust | ||
| ``` | ||
|
|
||
| If no tag is provided **the default version** will be installed. | ||
| When installing dependecies the `--overwrite` argument can be used to overwrite an existing version. |
There was a problem hiding this comment.
- The word
dependenciesis misspelled; - A comma after
dependencieshelps separate the introductory clause.
| mxpy deps install rust --overwrite | ||
| ``` | ||
|
|
||
| If the configuration is not altered **the default version** will be installed. |
There was a problem hiding this comment.
A comma after altered helps separate the introductory clause.
| @@ -242,6 +243,44 @@ The `--pem` argument is used to provide the sender of the transaction, the payer | |||
|
|
|||
| [comment]: # (mx-context-auto) | |||
|
|
|||
| ### Deploying a smart contract providing the ABI file | |||
|
|
|||
| For functions that have complex arguments we can use the ABI file generated when building the contract. The ABI can be provided using the `--abi` argument. When using the ABI, and only when using the ABI, the arguments should be written in a `json` file and should be provided via the `--arguments-file` argument. | |||
There was a problem hiding this comment.
Comma after arguments to separate introductory clause.
| ] | ||
| ``` | ||
|
|
||
| Let's go a bit through our file and see why it looks like this. First, as mentioned above, we have to place all the arguments inside a list. Then, the value `2` coresponds to the type `u32`. After that, we have another list that coresponds to the type `variadic`. Inside this list, we need to insert our addresses. For `mxpy`to encode addresses properly, we need to provide the address values inside a dictionary that can contain two keys: we can provide the address as the `bech32` representation or as the `hex encoded` public key. |
There was a problem hiding this comment.
The word corresponds is misspelled.
|
|
||
| Let's go a bit through our file and see why it looks like this. First, as mentioned above, we have to place all the arguments inside a list. Then, the value `2` coresponds to the type `u32`. After that, we have another list that coresponds to the type `variadic`. Inside this list, we need to insert our addresses. For `mxpy`to encode addresses properly, we need to provide the address values inside a dictionary that can contain two keys: we can provide the address as the `bech32` representation or as the `hex encoded` public key. | ||
|
|
||
| After finishing the arguments file we can run the following command to deploy the contract: |
There was a problem hiding this comment.
Comma after arguments file to separate introductory clause.
|
|
||
| Let's go a bit through our file and see why it looks like this. First, as mentioned above, we have to place all the arguments inside a list. Then, the contract expects an address, so we provide the `bech32` representation. After that, we have a `BigUInt` value that we can provide as a number. The third value is `Option<u64>` so we provide it as a number, as well. In case we wanted to skip this value, we could've simply used `0`. The last parameter is of type `variadic<bytes>`. Because it's a variadic value we have to place the arguments inside a list and since we can't write bytes we `hex encode` the value and place it in a dictionary containing the key-value pair `"hex": "<hex_string>"`, same as we did above for the address. | ||
|
|
||
| After finishing the arguments file we can run the following command to call the endpoint: |
There was a problem hiding this comment.
Comma after arguments file to separate introductory clause.
| ] | ||
| ``` | ||
|
|
||
| Let's go a bit through our file and see why it looks like this. First, as mentioned above, we have to place all the arguments inside a list. Then, the contract expects an address, so we provide the `bech32` representation. After that, we have a `BigUInt` value that we can provide as a number. The third value is `Option<u64>` so we provide it as a number, as well. In case we wanted to skip this value, we could've simply used `0`. The last parameter is of type `variadic<bytes>`. Because it's a variadic value we have to place the arguments inside a list and since we can't write bytes we `hex encode` the value and place it in a dictionary containing the key-value pair `"hex": "<hex_string>"`, same as we did above for the address. |
There was a problem hiding this comment.
Some commas might help with readability:
- After
The third value is Option<u64> - After
Because it's a variadic value - After
since we can't write bytes
Also, it might be easier to read if we split the long sentence in two: "Because it's a variadic value, we have to place the arguments inside a list. Since we can't write bytes..."
danidrasovean
previously approved these changes
Sep 24, 2024
|
|
||
| ### Creating the inner transactions | ||
|
|
||
| We can simply create the inner transactions the same way we did above, by using the `mxpy tx new` command. The only difference is that we'll have to provide an additional argument called `--inner-transactions-outfile` that represents the file where the inner transactions are saved to be later used by the relayer. To keep it simple, we'll send 1 EGLD from Alice to Bob and Carol will be the relayer. To create the EGLD transfer transaction from Alice to Bob we run the following command: |
There was a problem hiding this comment.
Suggested change
| We can simply create the inner transactions the same way we did above, by using the `mxpy tx new` command. The only difference is that we'll have to provide an additional argument called `--inner-transactions-outfile` that represents the file where the inner transactions are saved to be later used by the relayer. To keep it simple, we'll send 1 EGLD from Alice to Bob and Carol will be the relayer. To create the EGLD transfer transaction from Alice to Bob we run the following command: | |
| We can simply create the inner transactions the same way we did above, by using the `mxpy tx new` command. The only difference is that we'll have to provide an additional argument called `--inner-transactions-outfile`, which represents the file where the inner transactions are saved to be later used by the relayer. To keep it simple, we'll send 1 EGLD from Alice to Bob, and Carol will be the relayer. To create the EGLD transfer transaction from Alice to Bob, we run the following command: |
andreibancioiu
approved these changes
Sep 25, 2024
danidrasovean
approved these changes
Sep 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the pull request (what is new / what has changed)
Did you test the changes locally ?
Which category (categories) does this pull request belong to?