feat: improve wording in addresses/overview #1329
Conversation
|
Skipping AI review because this PR is from a fork. A maintainer can start the review by commenting /review in this PR. |
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| - generates outgoing messages. | ||
|
|
||
| As a result, every actor must have a unique address to ensure the correct message routing. This section explains how these addresses are structured and why they are fundamental to the TON architecture. | ||
| There can be multiple contracts which have the same code, but each program only manages its own storage and balance. To uphold this separation, every actor must have a unique address. This section explains how these addresses are structured and why they are fundamental to the TON architecture. |
There was a problem hiding this comment.
| There can be multiple contracts which have the same code, but each program only manages its own storage and balance. To uphold this separation, every actor must have a unique address. This section explains how these addresses are structured and why they are fundamental to the TON architecture. | |
| There can be multiple contracts which have the same code, but each contract only manages its own storage and balance. To uphold this separation, every actor must have a unique address. This section explains how these addresses are structured and why they are fundamental to the TON architecture. |
| import { Aside } from '/snippets/aside.jsx'; | ||
|
|
||
| TON implements **Actor model**, where all entities, including wallets, are smart contracts. Each actor: | ||
| TON implements **Actor model**. In it, every entity (smart contract), including even wallets, is a program which manages its own balance and persistent storage and is identified by its address. Each actor: |
There was a problem hiding this comment.
Contract doesn't manage its balance in the same way it manages its storage. While it can put arbitrary data into its storage, it cannot put arbitrary value into the balance.
In some sense, balance is managed by the blockchain. The word "manage" is too ambiguous here.
|
|
||
| ``` | ||
| account_id = hash(initial_code, initial_data) | ||
| account_id = StateInit {code: initial_code, data: initial_data}.toCell().hash() |
There was a problem hiding this comment.
This is not a page on Tolk. The math/pseudolanguage formula was intentionally there, as it's considerably more concise.
There was a problem hiding this comment.
The problem being, account_id is not hash of exclusively code and data but also those additional parameters (libraries - not sure if contract can be deployed having them immediately - and also non-compared prefix length).
There was a problem hiding this comment.
@ProgramCrafter fun fact not related to this PR. It can be can be deployed having them immediately. But only to basechain. It is now allowed for the masterchain
There was a problem hiding this comment.
@ProgramCrafter but your change also does not mention any libraries
There was a problem hiding this comment.
In the overview it's ok to be a bit informal and imprecise and even lie a little bit, as long as there are links to the part of the docs where these simplified explanations refined into rigorous ones: it's a common educational strategy.
| </Aside> | ||
|
|
||
| Additionally, a 64-bit prefix of an account id is crucial for the sharding process and delivering messages from one shard to another during [Hypercube Routing](/foundations/shards). | ||
| <Aside type="tip"> |
There was a problem hiding this comment.
There's no need to highlight this text, or break it out of the flow of the article. It should be a regular paragraph of text.
The tip above is there to highlight the fact that hash of code and data might change over time, as it's not obvious.
|
|
||
| Additionally, a 64-bit prefix of an account id is crucial for the sharding process and delivering messages from one shard to another during [Hypercube Routing](/foundations/shards). | ||
| <Aside type="tip"> | ||
| There are contracts which, as their first action, transform into another contract with specified code and data. They are called "vanity contracts" as they, by expanding set of possible account ids, allow to find a subjectively prettier address for the new contract. |
There was a problem hiding this comment.
| There are contracts which, as their first action, transform into another contract with specified code and data. They are called "vanity contracts" as they, by expanding set of possible account ids, allow to find a subjectively prettier address for the new contract. | |
| There are contracts which, as their first action, transform into another contract with specified code and data. They are called [vanity](/contract-dev/vanity) contracts as they, by expanding set of possible account ids, allow to find a subjectively prettier address for the new contract. |
| ``` | ||
|
|
||
| So, for each pair (`initial_code`, `initial_data`), there exists a unique account id to which a smart contract with such code and data can be deployed (this logic may become more complex when [TVM 11](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#version-11) is deployed on the main network.). | ||
| An uninitialized contract can only be deployed by providing `StateInit` which matches hash part of its address; so, for each pair (`initial_code`, `initial_data`), there exists a specific set of account ids to which a smart contract with such code and data can be deployed (it isn't only one ID, as [TVM 11](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#version-11) and onwards allows rewriting a short prefix to put contract in another shard). |
There was a problem hiding this comment.
| An uninitialized contract can only be deployed by providing `StateInit` which matches hash part of its address; so, for each pair (`initial_code`, `initial_data`), there exists a specific set of account ids to which a smart contract with such code and data can be deployed (it isn't only one ID, as [TVM 11](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#version-11) and onwards allows rewriting a short prefix to put contract in another shard). | |
| An uninitialized contract can only be deployed by providing `StateInit` which matches hash part of its address; so, for each pair (`initial_code`, `initial_data`), there exists a specific set of account IDs to which a smart contract with such code and data can be deployed (it isn't only one ID, as [TVM 11](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#version-11) and onwards allows rewriting a short prefix to put contract in another shard). |
There was a problem hiding this comment.
- The sentence is too long.
- The description can be simplified by linking relevant docs page, i.e.
/foundations/messages/deploy#deploying-to-specific-shard
There was a problem hiding this comment.
Also the sentence was incorrect before, because it happened in version 10, and are "not compared", not "rewritten".
verytactical
changed the title
4 participants
Closes #1365