diff --git a/foundations/addresses/overview.mdx b/foundations/addresses/overview.mdx index e81ad8ec5..e183295b7 100644 --- a/foundations/addresses/overview.mdx +++ b/foundations/addresses/overview.mdx @@ -5,22 +5,17 @@ sidebarTitle: "Overview" import { Aside } from '/snippets/aside.jsx'; -TON implements **Actor model**, where all entities, including wallets, are smart contracts. Each actor: +TON implements an [actor model](https://en.wikipedia.org/wiki/Actor_model), where entities, including wallets, are _smart contracts_ that exchange messages. Each smart contract is hosted on a distinct _account_ that manages its balance and persistent storage. These accounts have identifiable _addresses_, used for sending and receiving messages on the blockchain. -- processes incoming messages; -- updates its internal state; -- generates outgoing messages. +Each actor (account) processes incoming messages on its address one at a time, updating its internal state and generating outgoing messages. While multiple accounts can share the same code, each maintains its own storage and balance. To uphold this separation, each account address is unique. -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 are several types of addresses used in the TON blockchain. Here, we will focus on the two most important ones for developers: **internal** and **external**. -Every account in the TON blockchain has an internal address. External addresses are intended to be used by off-chain software. +On the TON blockchain, there are several types of addresses. The two most relevant ones for developers are [_internal_](#internal-addresses) and [_external_](#external-addresses). Every account has an internal address, while external addresses are intended for use by off-chain software. ## Internal addresses -Each smart contract deployed on TON blockchain has this type of the address. Let's look at the corresponding TL-B schemes: +Each smart contract deployed on TON has an internal address. The corresponding TL-B schemes are: -``` +```tlb addr_std$10 anycast:(Maybe Anycast) workchain_id:int8 address:bits256 = MsgAddressInt; addr_var$11 anycast:(Maybe Anycast) addr_len:(## 9) @@ -35,7 +30,7 @@ There are two constructors: And four components: - `workchain_id`: the workchain ID — a signed 8-bit integer in case of `addr_std` and a 32-bit integer in case of `addr_var`. -- `address`: an address of the account — from 64 to 512 bits, depending on the workchain. To avoid confusion with a full address, this field is usually called `account_id`. +- `address`: an address of the account — from 64 to 512 bits, depending on the workchain. To avoid confusion with a full address, this field is usually called `account_id` or a **hash** part of address. - `addr_len`: a length of the non-standardized address. - `anycast`: not currently used in the blockchain and is always replaced with a zero bit. It was designed to implement shard splitting for _global_ (or _large_) accounts, but was later deprecated in [TVM 10](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#anycast-addresses-and-address-rewrite). @@ -52,19 +47,21 @@ Both use **256-bit addresses** for accounts. ### Account ID -In the currently used workchains, an account ID is defined as the result of applying a hash function to a [`StateInit`](/foundations/messages/deploy) structure that stores initial code and data of a smart contract. +In the currently used workchains, the account ID is defined as the hash of the contract's initial state ([`StateInit`](/foundations/messages/deploy)) structure, which holds its code and data: -``` +```text account_id = hash(initial_code, initial_data) ``` -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.). +Uninitialized account can only become active by providing a `StateInit` that matches its account ID (hash) in the incoming message. If the [`fixed_prefix_length` is set](/foundations/messages/deploy#deploying-to-specific-shard), the first respective bits of the destination account ID are not compared with the `StateInit` hash — only the remaining bits must match. That short prefix is used to [deploy a contract in the specific shard](/foundations/messages/deploy#deploying-to-specific-shard). + +As such, for each pair of `initial_code` and `initial_data`, there exists a specific set of account IDs to which a smart contract with such code and data can be deployed. Account IDs are crucial for sharding and for delivering messages between shards during [Hypercube Routing](/foundations/shards). -