Greetings reader, this series of posts will be a guide to FunC development. To make your path clear and effective, I
will give you a map and tips, you can use them to go through the lessons and thus understand FunC and possibly create
your own application on TON.

The TON ecosystem is visible on the horizon, our journey begins....

## TON blockchain smart contracts
 ![](https://storage.googleapis.com/ton-strapi/func1_77e94dd266/func1_77e94dd266.png) 

TON network consists of TVMs (TON Virtual Machines). Smart contracts are programs stored on a blockchain that run when
predetermined conditions are met. High-level language FunC is used to program smart contracts on TON blockchain. FunC
programs are compiled into Fift assembler code, which generates corresponding bytecode for the TVM.

Any developer can create a smart contract and publish it on the TON network by paying a network fee. Any user can then
call the smart contract to execute his code, again for a fee paid to the network.

Thus, with the help of smart contracts, developers can arbitrarily create and deploy complex user applications and
services.

> It is also important to note that published smart contracts have an address on the network.

The first thing we see when we enter the TON ecosystem is a "forest" of cells, in order to find a use for this and go
further, you need to deal with data types, exceptions and functions in FunC.

## Data types, functions and exceptions in TON

 ![](https://storage.googleapis.com/ton-strapi/func2_8b91792c57/func2_8b91792c57.png) 

All persistent data in TON Blockchain is stored in trees of cells. Every cell has up to 1023 bits of arbitrary data in
it and up to 4 references to other cells. Cells play a role of memory in stack-based TVM.

FunC program is essentially a list of function declarations/definitions and global variable declarations. any function
declaration or definition starts with a common pattern. The pattern is following:
```
[<forall declarator>] <return_type> <function_name>(<comma_separated_function_args>) <specifiers>
```
where [ ... ] correspond to an optional entry.

Smart contracts on the TON network have two reserved methods that can be accessed.

- `recv_internal()` is executed when inside TON itself, for example, when any contract refers to ours
- `recv_external()` is executed when a request to the contract comes from the outside world, that is, not from TON

An important part of any smart contract is throwing exceptions if something goes wrong. Exceptions can be thrown by
conditional primitives `throw_if` and `throw_unless` and by unconditional `throw`.

So that you can understand everything, I made a lesson in which you will write your first smart contract and in practice
deal with the information that you just
read. [Link](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/1lesson/firstlesson.md) to the first lesson.

Congratulations, the forest of cells is passed, but in order for others to use our path, we will have to test it ..

## Testing a smart contract

 ![](https://storage.googleapis.com/ton-strapi/func3_3956da34ab/func3_3956da34ab.png) 

Distracted for a moment by thinking about the tests, you do not notice how the sage approaches you. He says that now
there are two types of tests in TON.

### V1 Tests

In the old version v1 tests, you need to write two functions for each test:

- data function (or, as it would be more correct, a state function)
- test function

Thus, for each test, we will first set the data / state, and then, in the test function, describe the logic of the test,
causing exceptions every time the logic is violated.

Despite the fact that this is an old version of the tests, the sage urges you to pay attention to them in order to
understand how testing in TON is generally arranged. How to test the smart contract, which we wrote in the first lesson
with tests in version 1, can be read in the second lesson.

[Link](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/2lesson/secondlesson.md) to the second lesson.

### V2 Tests

As the sage leaves, he points to the distance, saying that there are also new tests in TON that you should pay attention
to if you want to create tests faster.

In the new v2 tests, testing occurs through two functions that allow you to call smart contract methods:

- `invoke_method` , which assumes no exception will be thrown
- `invoke_method_expect_fail` which assumes an exception will be thrown

These special functions, we will call inside the test functions, which can return any number of values, all of them will
be displayed when the tests are run in the report.

The name of each test function must start with __test. This way we can determine which functions are tests and which are
just helpers. Lesson with examples on new v2 tests:

[Link](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/11lesson/11lesson.md) to the lesson with v2 tests.

As you move through the TON ecosystem, we gradually realize that without the concepts of registers and stack, it is
impossible to create anything here, which means that this is a very important part of the journey through TON.

## Stack and Registers

TON virtual machine is a stack machine. The order in which an element added to or removed from a stack is described
as **last in, first out**. Therefore, we often have to read data in smart contracts, even if we do not use some of them.
The function in the example below, we want to get the address, but we have to get the flags first, even though we don't
use them.
```
slice parse_sender_address (cell in_msg_full) inline {
  var cs = in_msg_full.begin_parse();
  var flags = cs~load_uint(4);
  slice sender_address = cs~load_msg_addr();
  return sender_address;
}
```
Also, the state of the TVM is described by control registers, the most commonly used register in TON smart contracts
is `c4` - contains the root of persistent data, or simply the data section of the contract. This value is a Cell.

The journey deep into the ecosystem continues, we have several “smart contract base camps”, but how to organize
communication between them?

## Sending Messages

 ![](https://storage.googleapis.com/ton-strapi/func4_6a349dc13e/func4_6a349dc13e.png) 

TON uses an actor model of communication between smart contracts. Each smart contract can receive one message, change
its own state or send one or several messages per unit time. As a result, the entire blockchain, as well as a given
contract, can scale up to host an unlimited amount of users and transactions. Lesson that introduces messages in TON:

[Link](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/3lesson/thirdlesson.md) to the lesson about messages.

Also the TON blockchain and the contracts it hosts can receive external messages — from other blockchains and the web in
general. This means that one can send a message to a TON smart contract without having an on-chain account, and smart
contracts can process and utilize external data for on-chain operations.

It is important to test our logic with messages, let's do it further.

## Testing messages

 ![](https://storage.googleapis.com/ton-strapi/func5_6b56432ac3/func5_6b56432ac3.png) 

Moving inside the ecosystem, you stumble upon strange stones covered with runes....

To test smart contracts with messages on, we will need to generate addresses. Objects in the TON are described by TL-B
schemes, therefore, in order to understand what the address for testing should look like, we will have to look at
the [block scheme](https://github.com/ton-blockchain/ton/blob/master/crypto/block/block.tlb).

It becomes clear that the runes on the stones carry important information that will help in our journey.

In order to understand TL-B and I advise you to study: https://core.telegram.org/mtproto/TL .

To help you figure out how to test messages, there is a lesson:

[Link](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/4lesson/forthlesson.md)  to the lesson about message tests.

## Further path

In this article, we started our journey through the TON ecosystem with FunC programming language, I hope the first steps
sparked your desire to move on. 

Other parts:
- [Part 2](https://blog.ton.org/func-journey-2)
- [Part 3](https://blog.ton.org/func-journey-3)


FunC Journey: Part 1

This is the third part of the FunC journey, in which we will look at what tokens are, why standards are needed and what
are the standards for tokens in TON, we will analyze how the Jetton standard and the NFT collection standard work at the
top level, and also we will analyze some non-obvious points in the implementation examples of Jetton and NFT standards.

 ![](https://storage.googleapis.com/ton-strapi/func1_421c9e9af1/func1_421c9e9af1.png) 

The journey continues, in search of new opportunities, you stumble upon a building, a shrine of knowledge... .
Anticipating a lot of questions, the guardian shrine of knowledge sends you to the Tokens section.

## Tokens

 ![](https://storage.googleapis.com/ton-strapi/func2_121d8693d9/func2_121d8693d9.png) 

Crypto tokens are units of account for some digital asset in some network. It is important to note that a token does not
usually mean a cryptocurrency, but a record distributed on the blockchain, which is managed using smart contracts. The
smart contract contains the values of the balances on the accounts of token holders, and the smart contract also
provides the ability to transfer tokens from one account to another.

And everything seems to be simple, we are making a smart contract that can store balances and transfer tokens in some
way. But if everyone invents a wheel, then it will be difficult for applications like wallets, games, analytical
platforms to interact with your smart contracts.

Therefore, there are standards in blockchain networks that are being developed together with the community.

The thought of creating your own tokens so that future travelers on the TON can use them leads you to the guardian
again, you ask the question: Where can I see the standards?

### TEP and Standarts

 ![](https://storage.googleapis.com/ton-strapi/func3_0bc9c27c77/func3_0bc9c27c77.png) 

Blockchains usually have separate pages on github or on a platform with the necessary mechanics, where you can make
proposals on standards.

In TON, this is a [github repository](https://github.com/ton-blockchain/TEPs).

> Importantly, these pages are not a forum or a place for free discussion of the blockchain, so be responsible for your
> posts if you want to offer something in this repository.

The first standard we'll look at is
the [token metadata standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0064-token-data-standard.md). For
applications like wallets or marketplaces it is quite useful to be able automatically retrieve information for display.
Token data standard allows to simplify this process and uniform the way of token display across different applications.

### Risks

Since tokens are smart contracts, there may be errors or backdoors in them. Therefore, it is worth studying smart
contracts before using them.

You have been traveling on web3 for more than a day and you understand that you have already heard about tokens on other
continents, but there are clearly differences in TON...

## Difference of tokens in TON

The architecture of smart contracts of tokens in TON differs from the architecture of smart contracts in other networks,
since the TON is asynchronous, the interaction takes place according to the actor model and scaling in TON is based on
the concept of sharding.

The key difference from the standards of other networks is the lack of one smart contract that does all the work. For
example, if you want to release a NFT collection (we will talk about NFT in more detail later), then each element will
be a separate smart contract, and there will also be a separate smart contract for the entire collection.

Example from Standart: if you release a collection that contains 10 000 items, then you will deploy 10 001 smart
contracts.

You may have a question - why such an implementation was chosen? Briefly:

- Such a scheme makes it possible to make gas consumption predictable
- Such a scheme does not scale

Full explanation is in
the [NFT standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md#why-not-a-single-smart-contract-with-a-token_id---owner_address-dictionary)
.

## Types of tokens

One of the possible classifications of tokens is the classification by fungibility.

**Fungible tokens** are assets that are not unique and can be easily exchanged for another asset of the same type. Such
tokens are made in such a way that each token is equivalent to the next token.

The standard for a fungible token in TON
is [Jetton](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md).

**Non-fungible** tokens are assets, each instance of which is unique (specific) and cannot be replaced by another
similar asset. A non-fungible token is some kind of digital entity certificate with the ability to transfer the
certificate through some mechanism.

The standard for a fungible token in TON
is [NFT Standart](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md).

## Jetton

 ![](https://storage.googleapis.com/ton-strapi/func4_c12351ec4b/func4_c12351ec4b.png) 

So, the standard for a fungible token
is [Jetton](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md).

The Jetton standard token should consist of two types of smart contracts:

- master contract
- contract wallet

Each Jetton has a main smart contract (let's call it a master contract) that is used to mint new Jettons, account for
the total supply, and provide general information about the token.

Information about the number of tokens owned by each user is stored in smart contracts called the Jetton wallet.

There is a good example in the standard documentation:

If you release Jetton with a supply of 200 Jettons owned by 3 people, then you need to deploy 4 contracts: 1 Jetton
master and 3 jetton wallets.

In order to make it easier for you to understand the standard, I made
a [lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/9lesson/ninthlesson.md) that not only
understands the standard, but also understands an example of the implementation of the master contract and Jetton
wallets.

## NFT

 ![](https://storage.googleapis.com/ton-strapi/func5_c65fb3c114/func5_c65fb3c114.png) 

The NFT, of course, also has its
own [standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md). As mentioned above in TON,
each NFT Item and NFT Collection are separate smart contracts.

NFTs look like a great opportunity to capture FunC your journey, but a couple of questions remain:

- how to get a full link to the content if there is no single list in the smart contract
- how to get the address of the NFT or Token smart contract and what kind of StateInit that allows you to do this

### StateInit trick

Consider the [process of deploying](https://ton.org/docs/develop/howto/step-by-step#3-compiling-a-new-smart-contract) a
smart contract to the network. The code and data for the new smart contract are combined into a StateInit structure, the
address of the new smart contract (equal to the hash of this StateInit structure) is calculated and output, and then an
external message is created with the address destination equal to the address of the new smart contract. This message
contains both the correct StateInit for the new smart contract and a non-trivial payload (signed with the correct
private key).

For us, this means that we can get the address of the smart contract of the token from the address to which we need to
send the tokens. In simple terms, using the address and wallet code, we will collect the StateInit of the wallet and
from it we will get the address of the token wallet we need.

This is possible, since hashing functions are deterministic, which means that for different input data there will be a
different hash, while for the same input data the hash function will always return a uniform hash.

## NFT item content

Let's say we want to get the address of the collection element, its content, let's say a link to the picture. And
everything seems to be simple, we pull the Get-method and get the information. BUT in accordance with the NFT standard
in TON, in this way we will not get a complete link, but only a part, the so-called individual element content.

To get the full content, you need:

- by the get-method of the element `get_nft_data()`, we get the element index and individual content, as well as the
  initialization sign
- check if the element is initialized (More about this in lesson 10, where the NFT standard is discussed)
- if the element is initialized, then by the get-method of the collection `get_nft_content(int index, cell
  individual_content)`, we will get the full content (full address) for a separate element

In order to make it easier for you to understand the standard, I made
a [lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/10lesson/tenthlesson.md)

## Conclusion

On this series of articles, the journey through FunC ends. I publish new lessons in my [channel](https://t.me/ton_learn), I think they can help you if you plan to start developing on TON.

Other parts:
- [Part 1](https://blog.ton.org/func-journey)
- [Part 2](https://blog.ton.org/func-journey-2)


FunC Journey: Part 3

Greetings reader, this is the second part of the journey through the TON ecosystem. In this part, we will continue to
study different aspects of FunC.

 ![](https://storage.googleapis.com/ton-strapi/func1_02188d1f8f/func1_02188d1f8f.png) 

## Current state of affairs

In the previous part, we got acquainted with smart contracts in the TON network. We figured out why messages are needed,
why the c4 register is needed, and also talked about tests. Now let's talk about things that will allow you to create
complex smart contracts.

## OP and fees

 ![](https://storage.googleapis.com/ton-strapi/func2_360313f53d/func2_360313f53d.png) 

As we continue our journey through the TON ecosystem, we will learn that there are some rules that are recommended for
smart contracts to interact with.

Smart contracts in TON interact with each other by sending the so-called internal messages. For the convenience of
interaction between smart contracts, recommendations were developed. The key to these recommendations is adding
the `query_id` and `op` to the beginning of the message:

- `op` identifies the operation to be performed, or the method of the smart contract to be invoked.
- `query_id` used in all query-response internal messages to indicate that a response is related to a query (in case we
  want to send response).

This is how it looks:
```
() recv_internal (int balance, int msg_value, cell in_msg_full, slice in_msg_body) {
    int op = in_msg_body~load_int(32);
    int query_id = in_msg_body~load_uint(64);
       
      if (op == 1) {
        ;;
      } else {
        if (op == 2) {
          ;;
        } else {
          ;; there might be an exception here 
        }
      }
}
```

 ![](https://storage.googleapis.com/ton-strapi/func3_1dd0883e6f/func3_1dd0883e6f.png) 

The longer you travel through TON, the more you learn about interaction with the environment. The account manager on
your team says he knows how to make your smart contracts more efficient.

The TON network has its own currency - Toncoin. Thanks to the Toncoin cryptocurrency, there is a market for computing.
Such a marketplace provides an economic incentive for participants to validate and fulfill transactional requests and
provide computing resources to the network. Any participant broadcasting a transaction request must pay fees in Toncoin.
Smart contracts also use Toncoin, so you need to think about optimizing smart contracts in terms of fees.

In TON [the transaction fee](https://ton.org/docs/develop/smart-contracts/fees) consists of:

- `storage_fees` - fees for a "place" in the blockchain.
- `in_fwd_fees` - fees for importing messages (this is the case when we process external messages).
- `computation_fees` - fees for executing TVM instructions.
- `action_fees` - fees associated with processing a list of actions (for example, sending messages).
- `out_fwd_fees` - fees for importing outgoing messages.

One simple technique to reduce fees is to use the `inline` keyword for functions that are called once or twice, so that
when compiled they will simply be substituted into the function call site.

This is how it looks, if you need to load data, for example, only once:
```
(slice, slice) load_data () inline {
  var ds = get_data().begin_parse();
  return (ds~load_msg_addr(), ds~load_msg_addr());
}
```
[Lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/5lesson/fifthlesson.md) about `op`.

## Testing Op

Being already an experienced TON traveler you know that everything has to be tested....

 ![](https://storage.googleapis.com/ton-strapi/func4_11e33c5c02/func4_11e33c5c02.png) 

To test the work with op, we will need to understand what action the contract performed. Register c5 will help us with
this.

c5 - Contains the output actions. This value is a Cell.

Outgoing messages from smart-contracts are written to register c5. Therefore, in the tests, we will send messages from
address to address and parse the c5 register to make sure everything is correct.

Example of register c5 subtraction:
```
(int, cell) extract_single_message(cell actions) impure inline method_id {
    ;; ---------------- Parse actions list
    ;; prev:^(OutList n)
    ;; #0ec3c86d
    ;; mode:(## 8)
    ;; out_msg:^(MessageRelaxed Any)
    ;; = OutList (n + 1);
    slice cs = actions.begin_parse();
    throw_unless(1010, cs.slice_refs() == 2);

    cell prev_actions = cs~load_ref();
    throw_unless(1011, prev_actions.cell_empty?());

    int action_type = cs~load_uint(32);
    throw_unless(1013, action_type == 0x0ec3c86d);

    int msg_mode = cs~load_uint(8);
    throw_unless(1015, msg_mode == 64); 

    cell msg = cs~load_ref();
    throw_unless(1017, cs.slice_empty?());

    return (msg_mode, msg);
}
```
[Lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/6lesson/sixthlesson.md) about testing `op`.

## HashMap
 ![](https://storage.googleapis.com/ton-strapi/func5_7e9403a60a/func5_7e9403a60a.png) 

With the increase in the complexity of smart contracts, the question arises of how data can be stored and processed, for
example, with respect to time. This opportunity is provided by hashmaps or as they are also called dictionaries.

Hashmap is a data structure represented by a tree. Hashmap - maps keys to values of arbitrary type, so that quick lookup
and modification is possible. More details in [clause 3.3](https://ton-blockchain.github.io/docs/tvm.pdf). In FunC,
hashmaps are represented by a [cell](https://ton.org/docs/develop/func/stdlib#dictionaries-primitives).

For the convenience of working with hashmaps, the FunС standard library has many functions. For example, if you want to
add data to hashmap, you can use `dict_set` , which sets the value associated with the key index key n bit depth in the
dict dictionary to a slice and returns the resulting dictionary.
```
dic~udict_set(256, key, in_msg_body);
```
To work with hashmaps, we need loops:

Loops are often used to work with hashmaps. FunC has
three [loops](https://ton.org/docs/develop/func/statements#loops): `repeat`,`until`,`while`.

The most convenient hashmap loop is `until`, since many functions for working with hashmaps return a flag by which it is
convenient to check the loop termination condition.

[Lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/7lesson/seventhlesson.md) about hashmaps.

## Testing hashmaps

When we test contracts that use some kind of time logic, you need to use the c7 register. Therefore, in tests for a
smart contract, we will need to write a helper function that will allow us to work with time.

 ![](https://storage.googleapis.com/ton-strapi/func6_4eb6a99410/func6_4eb6a99410.png) 

c7 — Contains the root of temporary data. It is a Tuple.

The helper function will allow us to put any time we need into the register.The helper function would look like this:
```
tuple get_c7_now(int now) inline method_id {
    return unsafe_tuple([unsafe_tuple([
        0x076ef1ea,           ;; magic
        0,                    ;; actions
        0,                    ;; msgs_sent
        now,                  ;; unixtime
        1,                    ;; block_lt
        1,                    ;; trans_lt
        239,                  ;; randseed
        unsafe_tuple([1000000000, null()]),  ;; balance_remaining
        null(),               ;; myself
        get_config()          ;; global_config
    ])]);
}
```
Since the smart contract has the logic of storing values as well as receiving, we will have to test the data received
from previous tests, this cannot be done using the standard FunC library, BUT in toncli this moment is thought out: In
description of toncli tests, there are `get_prev_c4` / `get_prev_c5` functions that allow you to get `c4`/`c5` cells
from previous tests.

To make it convenient for us to work with the tuple from the stack, the standard library has functions:

- first - returns the first element of a tuple.
- second - returns the second element of a tuple.

[Lesson](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/8lesson/eighthlesson.md) about testing hashmaps.

## Further path

Congratulations, we have made significant progress on our journey. In the next part, we will talk about token standards
and NFTs in TON.

Other parts:
- [Part 1](https://blog.ton.org/func-journey)
- [Part 3](https://blog.ton.org/func-journey-3)


Ivan Romanovich