Skip to content

Patch 24 #58

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Mar 10, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 9 additions & 8 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,13 @@
<!--- Provide a general summary of your changes in the Title above -->

## Why is it important?
## Description

<!--- Describe your changes in detail -->
<--Brief description of the changes introduced in this pull request. Include any relevant issue numbers or links.-->

## Related Issue
Closes <--link to issue]-->.

<!--- This project accepts pull requests related to open issues, if possible -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- Please link to the issue here, if possible: -->
## Checklist

- [ ] I have created an issue.
- [ ] I am working on content that aligns with the [Style guide](https://docs.ton.org/v3/contribute/style-guide/).
- [ ] I have reviewed and formatted the content according to [Content standardization](https://docs.ton.org/v3/contribute/content-standardization/).
- [ ] I have reviewed and formatted the text in the article according to [Typography](https://docs.ton.org/v3/contribute/typography/).
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,4 +5,4 @@

### Thank you for your interest in contributing!

Please see [our contributing guide on documentation](/v3/contribute/) for the latest information on how to contribute!
Please see [our contributing guide on documentation](https://docs.ton.org/v3/contribute) for the latest information on how to contribute!
29 changes: 12 additions & 17 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,10 @@
<img align="left" width="300px" src="static\img\readme\about.png">

## TON Blockchain Documentation 📚
## TON documentation 📚

This is the official repository for The Open Network documentation.

Latest documentation release: [docs.ton.org](https://docs.ton.org)

The mission of this documentation is to collect all available information and knowledge that can help TON developers.

You can improve the documentation by following steps below.

---

Expand All @@ -30,29 +26,28 @@ Join TON Docs Club chat in Telegram to join contributors party:

## How to Contribute? 🦄

If you are a developer and faced some difficulties, successfully overcoming them - share this knowledge with future developers!

— Have an issue? [Prepare a solution with TON Docs Wizard](https://t.me/ton_docs_bot).
— Have an idea? [Submit a Feature Request](https://github.com/ton-community/ton-docs/issues/new/choose).
— Want to contribute? [Setup your environment](https://github.com/ton-community/ton-docs#set-up-your-environment-%EF%B8%8F).
— Want to contribute? [How to contribute](https://docs.ton.org/v3/contribute).
— Want to translate? [Localization](https://docs.ton.org/v3/contribute/localization-program/how-to-contribute)


Contributing best practices: [docs/contribute](/v3/contribute)

---

## Set up your Environment ☁️
## Set up your environment ☁️

If you are changing the sidebar or adding media-files, please check that your submission will not break production.
If you're changing the sidebar or adding media-files, links, please make sure that your submission won't break production.

You can do this in two ways:

### Cloud (quick way)
### Cloud

Use Gitpod (a free, online VS code-like IDE) for contributing. It will launch a workspace with a single click:
Use Gitpod for contributing. It'll launch a workspace with a single click:

[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/ton-community/ton-docs)

### Local (default way)
### Local

1. Download repository from GitHub with its submodules

Expand Down Expand Up @@ -81,14 +76,14 @@ Use Gitpod (a free, online VS code-like IDE) for contributing. It will launch a

This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.

## Install Recursive Module
## Install recursive module

If you cloned the repository from GitHub without step 1, you will need to install the submodules to enable local execution.
If you cloned the repository from GitHub without step 1, you'll need to install the submodules to enable local execution.
```
git submodule update --init --recursive
```

## Contributors Wall
## Contributors wall
<a href="https://github.com/ton-community/ton-docs/graphs/contributors">
<img src="https://contrib.rocks/image?repo=ton-community/ton-docs&max=204" />
</a>
Expand Down
3 changes: 3 additions & 0 deletions cspell.json
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,9 @@
"Tolk",
"Toncoin",
"Toncoins",
"Tonhub",
"Tonkeeper",
"Tonkey",
"Underload",
"Uninit",
"WAGMI",
Expand Down
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
# Blockchain Services
# Blockchain services

## Domain Name Systems
## Domain name systems

In Ethereum, users use the Ethereum Name Service (ENS), which is a decentralized naming system built on top of the Ethereum blockchain.
In Ethereum, users use the **Ethereum Name Service (ENS)**, which is a decentralized naming system built on top of the Ethereum blockchain.

The TON blockchain includes an embedded domain name system known as the TON DNS. It is a decentralized service that allows users to register human-readable domain names for their smart contracts, websites, or any other online content. Such a device facilitates interaction with decentralized applications (dApps) and other resources on the TON blockchain. The DNS system in TON functions similarly to traditional Internet DNS systems, but its decentralized nature eliminates the need for a centralized authority to control and manage domain names, thereby reducing the risks of censorship, fraud, and domain name hijacking.
The TON blockchain includes an embedded domain name system known as the TON DNS. It's a decentralized service that allows users to register human-readable domain names for their smart contracts, websites, or any other online content. Such a device facilitates interaction with decentralized applications (dApps) and other resources on the TON blockchain. The DNS system in TON functions similarly to traditional Internet DNS systems, but its decentralized nature eliminates the need for a centralized authority to control and manage domain names, thereby reducing the risks of censorship, fraud, and domain name hijacking.

## WWW

Expand Down
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# The Difference of Blockchains
# The difference of blockchains

In this chapter, we will examine the key differences between the Ethereum blockchain compared to the TON blockchain. The analysis will include an overview of the network architectures, highlight their unique features, and evaluate the advantages and disadvantages of each.

Expand Down Expand Up @@ -46,7 +46,7 @@ The result of scripts is always the creation of a transaction. The transactions

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](/v3/documentation/smart-contracts/contracts-specs/wallet-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 actively using multi-sig wallets (smart contracts) like gnosis and are just starting to introduce so-called `account-abstractions' like ERC-4337, where wallets will be filled with such functionality as sending transactions without a native token, account recovery, after its loss, etc., but it's worth noting, wallet accounts are much more expensive to use in terms of gas fees compared to EOA in Ethereum.

## Messages and Transactions
## Messages and transactions

What happens between two contracts is called a message - a small number of tokens and arbitrary data are sent to a specified address. When the message arrives at the contract, it is processed by the contract code, the contract updates its state and optionally sends a new message. All these actions on the contract are recorded as transactions. Let's imagine an example, we have a chain of messages, from contract `A` to contract `B`, from contract `B`, to contract `C`, then we will have two messages and three transactions. But initially, to change the state of the blockchain, you need an outside signal. To invoke a smart contract, you need to send an external message that goes to the validators and they apply it to the smart contract. And we already discussed in the last subsection that a wallet is a smart contract, so this external message usually first goes to the wallet's smart contract, which records them as the first transaction and that first transaction usually contains an embedded message for the actual destination contract. When the wallet smart contract receives the message, it processes it and delivers it to the destination contract (in our example, contract `A` could be a wallet and when it receives the external message, it will have the first transaction). The sequence of transactions forms a chain. So you can see that each smart contract has its own transactions, which means that each contract has its own `little blockchain` (you can read more about it [here](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains)), so the network can process the transactions due to this completely independent of each other

Expand Down
36 changes: 18 additions & 18 deletions docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,9 +37,9 @@ In case of FunC, the main data types are:

Currently, FunC has no support for defining custom types.

### See Also
### See also

- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)

## Declaring and using variables

Expand All @@ -58,9 +58,9 @@ FunC is a more abstract and function-oriented language, it supports dynamic typi
var z = x + y; // Dynamic variable declaration
```

### See Also
### See also

- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)

## Loops

Expand Down Expand Up @@ -88,9 +88,9 @@ repeat(10) {
;; x = 1024
```

### See Also
### See also

- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)

## Functions

Expand All @@ -114,33 +114,33 @@ Transitioning to FunC, FunC program is essentially a list of function declaratio
}
```

### See Also
### See also

- [Functions](/v3/documentation/smart-contracts/func/docs/functions)
- [Functions](/v3/documentation/smart-contracts/func/docs/functions/)

## Flow control structures

Most of the control structures known from curly-braces languages are available in Solidity, including: `if`, `else`, `while`, `do`, `for`, `break`, `continue`, `return`, with the usual semantics known from C or JavaScript.

FunC supports classic `if-else` statements, as well as `ifnot`, `repeat`, `while` and `do/until` loops. Also since v0.4.0 `try-catch` statements are supported.

### See Also
### See also

- [Statements](/v3/documentation/smart-contracts/func/docs/statements)
- [Statements](/v3/documentation/smart-contracts/func/docs/statements/)

## Dictionaries

Dictionary (hashmap/mapping) data structure is very important for Solidity and FunC contract development because it allows developers to efficiently store and retrieve data in smart contracts, specifically data related to a specific key, such as a user’s balance or ownership of an asset.

Mapping is a hash table in Solidity that stores data as key-value pairs, where the key can be any of the built-in data types, excluding reference types, and the value of the data type can be any type. Mappings are most typically used in Solidity and the Ethereum blockchain to connect a unique Ethereum address to a corresponding value type. In any other programming language, a mapping is equivalent to a dictionary.

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.
In Solidity, mappings don't 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. Working with potentially large cell trees can create several problems. Each update operation builds an appreciable number of cells (each cell built costs 500 gas), which means that these operations can run out of resource if used carelessly. To avoid exceeding the gas limit, limit the number of dictionary updates in a single transaction. Also, a binary tree for `N` key-value pairs contains `N-1` forks, which means a total of at least `2N-1` cells. The storage of a smart contract is limited to `65536` unique cells, so the maximum number of entries in the dictionary is `32768`, or slightly more if there are repeating cells.

### See Also
### See also

- [Dictionaries in TON](/v3/documentation/smart-contracts/func/docs/dictionaries)
- [Dictionaries in TON](/v3/documentation/smart-contracts/func/docs/dictionaries/)

## Smart-contract communication

Expand Down Expand Up @@ -208,15 +208,15 @@ var msg = begin_cell()
send_raw_message(msg, mode);
```
Let's discuss in more detail what it looks like for our smart contract to send a message to our recipient:
1. Initially, we need to build our message. The full structure of the send can be found [here](/v3/documentation/smart-contracts/message-management/sending-messages). We won't go into detail on how to assemble it here, you can read about that at the link.
1. Initially, we need to build our message. The full structure of the send can be found [here](/v3/documentation/smart-contracts/message-management/sending-messages/). We won't go into detail on how to assemble it here, you can read about that at the link.
2. The body of the message represents a cell. In `msg_body_cell` we do: `begin_cell()` - creates `Builder` for the future cell, first `store_uint` - stores the first uint into `Builder` (1 - this is our `op`), second `store_uint` - stores the second uint into `Builder` (num - this is our number that we will manipulate in the receiving contract), `end_cell()` - creates the cell.
3. To attach the body that will come in `recv_internal` in the message, we reference the collected cell in the message itself with `store_ref`.
4. Sending a message.

This example presented how smart contracts can communicate with each other.

### See Also
### See also

- [Internal Messages](/v3/documentation/smart-contracts/message-management/internal-messages)
- [Sending Messages](/v3/documentation/smart-contracts/message-management/sending-messages)
- [Non-bouncable messages](/v3/documentation/smart-contracts/message-management/non-bounceable-messages)
- [Internal Messages](/v3/documentation/smart-contracts/message-management/internal-messages/)
- [Sending Messages](/v3/documentation/smart-contracts/message-management/sending-messages/)
- [Non-bouncable messages](/v3/documentation/smart-contracts/message-management/non-bounceable-messages/)
Loading