Ethereum to TON section #636
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
novusnota
reviewed
Jun 18, 2024
novusnota
reviewed
Jun 18, 2024
AlehNat
reviewed
Jun 25, 2024
|
|
||
| In Ethereum, the cost of a transaction is measured in `gas`, which reflects the amount of computing resources required for the transaction. The `gas` cost is divided into a `base fee` set by the protocol and a `priority fee` that the user adds to speed up transaction processing by validators. The `total fee` will be = `units of gas used` * (`base fee` + `priority fee`). | ||
|
|
||
| In TON, the calculation of transaction fees is complex and includes several types of fees: for storing smart contracts in the blockchain, for importing messages into the blockchain, for executing code on a virtual machine, for processing actions after code execution, and for sending messages outside the TON blockchain. The price of gas and some other parameters can be changed by voting on the main network. Unlike Ethereum, TON users cannot set the gas price themselves. Also, the developer needs to return the remaining gas funds to the owner manually, otherwise they will remain locked. The use of smart contract storage also affects the price: if a wallet's smart contract has not been used for a long time, the next transaction will cost more. |
There was a problem hiding this comment.
It is worth mentioning that storing smart contracts at Ethereum is free.
| FunC is a more abstract and function-oriented language, it supports dynamic typing and functional programming style. | ||
|
|
||
| ```func | ||
| (int x, int y) = (1, 2); // A tuple containing two integer variables |
There was a problem hiding this comment.
I would suggest to add couple of more examples to see the difference with the solidity
There was a problem hiding this comment.
New comparison subsections have been added, thanks!
| ### TON Virtual Machine (TVM) | ||
|
|
||
| - TVM also functions as a stack-based machine but with a key distinction: it supports both 257-bit integers and references to cells. | ||
| - This allows TVM to push and pop these two distinct types of data onto/from the stack, providing enhanced flexibility in direct data manipulation. |
There was a problem hiding this comment.
It would be nice to show how dapp developers can benefit from it
| - TVM uses a unique "bag of cells" model to represent data. Each cell can contain up to 128 data bytes and can have up to 4 references to other cells. | ||
| - This structure allows the TVM to natively support arbitrary algebraic data types and more complex constructions such as trees or directed acyclic graphs (DAGs) directly within its storage model. | ||
| 2. Flexibility and Efficiency | ||
| - The cell model provides significant flexibility, enabling the TVM to handle a wide variety of data structures more naturally and efficiently than the EVM. |
There was a problem hiding this comment.
Didn’t get the point. It would be nice to have some real-life examples
There was a problem hiding this comment.
There is an example in the next paragraph. Maybe I misunderstood what you wanted to see.
|
|
||
| In Solidity, mappings do not have a length, nor do they have the concept of setting a key or a value. Mappings are only applicable to state variables that serve as store reference types. When mappings are initialised, they include every possible key, and are mapped to values whose byte-representations are all zeros. | ||
|
|
||
| An analogy of mappings in FunC are dictionaries, or TON hashmaps. In the context of TON, a hashmap is a data structure represented by a tree of cells. Hashmap maps keys to values of arbitrary type so that quick lookup and modification are possible. The abstract representation of a hashmap in TVM is a Patricia tree, or a compact binary trie. |
There was a problem hiding this comment.
Are there any limitations? As far as I know, it is not recommended to use unbounded data types in ton smart contracts
|
|
||
| ## The difference of wallets | ||
|
|
||
| We have already discussed that in Ethereum, a user's wallet is generated based on their address, which is in a 1-to-1 relationship with their public key. But in TON, all wallets are smart contracts that must be deployed by the user himself. Since smart contracts can be configured in different ways and have different features, there are several versions of wallets, which you can read about [here](/participate/wallets/contracts). Due to the fact that wallets are smart contracts, a user can have multiple wallets with different addresses and initial parameters. To send a transaction, the user must sign the message with his private key and send it to his wallet contract, which in turn forwards it to the smart contract of a particular DApp application. This approach greatly increases flexibility in wallet design and developers can add new versions of the wallet in the future. In Ethereum at the moment, developers are just starting to implement so-called `account abstractions`, where wallets will be smart contracts, while in TON this approach exists from the very beginning. |
There was a problem hiding this comment.
"In Ethereum at the moment, developers are just starting to implement so-called account abstractions, where wallets will be smart contracts" - multi-sig wallets (smart contracts) have existed quite a long time (gnosis). Also, wallet accounts are much more expensive to use in terms of gas fees compared to EOA
There was a problem hiding this comment.
Changed the wording, thanks
|
@vkokosh thank you! |
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.
Why is it important?
Related Issue