FunC Journey Part 1
FunC Journey Part 1
by Ivan Romanovich
Sep 16, 2022
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
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
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 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
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 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 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 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 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.
Sending Messages
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 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
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 shemes, therefore, in order to understand what the address for testing should look like, we will have to look at the block sheme.

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 TL Language.

To help you figure out how to test messages, there is a lesson:
Link 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. And of course, in the near future there will be a second article in which we will continue our journey.

Ivan Romanovich is a crypto enthusiast, creator of lessons on the language of smart contracts FunC. He also runs a telegram channel about the technical side of TON.