Ethereum to MultiversX migration tutorial #944
Merged
Conversation
This file contains hidden or 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
|
|
||
| Let’s take a look to a simple adder contract in Ethereum’s Solidity | ||
|
|
||
| ```solidity |
Contributor
There was a problem hiding this comment.
solidity option is not available, i tried typescript and it makes the code more eye-catching
|
|
||
| ## Handling the storage | ||
|
|
||
| Contracts in MultiversX are important to be as small as possible, the reason why the whole storage is not handled by the contract, but rather the VM, the contract only holding a handle of a memory location inside the VM where the data is actually stored. A very popular concept that you will see here is the one of storage mappers, which are some structures designed to handle the serialization inside the storage, depending on the data types. |
Contributor
There was a problem hiding this comment.
it would be nice to bold storage mapper to highlight the main topic
|
|
||
| One of the main issues of some Rust types such as `String` or `Vec<T>` when it comes to smart contract development is that they are dynamically allocated on heap, meaning that the smart contract asks for more memory than it actually needs from the runtime environment (the VM). For a small collection this is insignificant, but for a bigger collection, this can become slow and the VM might even stop the contract and mark the execution as failed. Not to mention that more memory used leads to longer execution times, which ultimately leads to also increased gas costs. | ||
|
|
||
| One of the most important outcomes of this issue is the fact that MultiversX smart contracts don’t use the `st` library. You will always see them marked with `#[no_std]`. |
Contributor
There was a problem hiding this comment.
typo st instead of std
|
|
||
| The Ethereum execution client relies on Solidity as its programming language, even though it provides several implementations and support for multiple other languages such as Javascript, Rust, Python, Java, C++, C# and Go. | ||
|
|
||
| On the other hand, the MultiversX virtual machine (VM) executes WebAssembly. This means that it can execute smart contracts written in any programming language that can be compiled to WASM bytecode. However, MultiversX strongly encourages developers to adopt Rust for the smart contracts by providing a strong Rust framework which allows for unusually clean and efficient code in smart contracts, a rarity in the blockchain field. A declarative testing framework is bundled as well. |
Contributor
There was a problem hiding this comment.
SpaceCraftSDK should be introduced here, rather than in the Data Serialization section.
|
|
||
| We implemented a concept called `ManagedType` which is a trait that many of our data types possess, allowing a more efficient way to hold them internally. | ||
|
|
||
| Lets take for example an endpoint having an optional parameter. Option as you know has 2 possible elements: an empty value representing `none` or a parameter encrusted in something representing `some`. Putting a small restriction for this parameter to be one of a kind in an endpoint we can assume that if by the time we reached it, if there are no bytes left to cover, we have a`none, or if we have straight up a parameter of the type we specified, than we have the `some` option. Imagine now that we also extended this principle to a multivalue type attribute having the same logic behind. |
Contributor
There was a problem hiding this comment.
Code section formatted wrong
|
|
||
| All of these positions (except the environment Env) can be empty, unitialized. This is signaled at compile time by the unit type, (). In fact, a transaction always starts out with all fields empty, except for the environment. | ||
|
|
||
| For instance, if we are in a contract and write self.tx(), the universal start of a transaction, the resulting type will be Tx<TxScEnv<Self::Api>, (), (), (), (), (), ()>, where TxScEnv<Self::Api> is simply the smart contract call environment. Of course, the transaction at this stage is unusable, it is up to the developer to add the required fields and send it. |
Contributor
There was a problem hiding this comment.
code snippets should be wrapped with code formatter
| .transfer(); | ||
| } | ||
| ``` | ||
| An essential element of the MultiversX smart contract is that every smart contract is also an account, just like a normal user, meaning that it also has an address and a balance and it can perform transactions. From this perspective we can say that transfers in MultiversX are always done from the address of the contract and in thai case, the tokens sent, before the transaction, they have to be owned by the contract. |
| self.candidates().insert(candidate); | ||
| } | ||
| } | ||
|
|
|
|
||
| Notice that the candidates from the Solidity contract in MultiversX’s contract translate into a storage mapper of type `UnorderedSetMapper`. This mapper was specially designed to allow easy and cheap access to a list of elements stored within at the cost of its ordering. Checking whether a candidate exists within the list or not becomes simple by just calling `self.candidates().contains(&candidate)`. | ||
|
|
||
| Next we have the increase of the number of votes which is done by `self.votes_received(&candidate).update(|votes| *votes += 1)`;. Here update receives a lambda allowing a total control of the contents of the storage. |
Contributor
There was a problem hiding this comment.
; is outside the code formatter
|
|
||
| While Ethereum implemented its own [tool](https://remix.ethereum.org/) to facilitate deployment and interaction with smart contracts, the developers at MultiversX went on an approach facilitating these elements from the same IDE, within the same framework, and by writing mostly the same Rust syntax as in the smart contract itself. | ||
|
|
||
| For MultiversX, the Interactors have multiple purposes, besides just helping you deploy a smart contract on the blockchain. These interractors work side by side with another tool developed by MultiversX developers called [sc-meta](https://docs.multiversx.com/developers/meta/sc-meta/) which facilitates smart contract building and proxies and interactor code auto-generation. |
mihaicalinluca
previously approved these changes
Aug 1, 2024
bogdan-rosianu
approved these changes
Aug 1, 2024
radumojic
approved these changes
Aug 1, 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?