TON code review

Worth noting that everything written below only represents the personal opinion of the author, which fully complies with the Fair Use laws and the First Amendment. It’s is in no way trading advice, and all the information was gathered from public sources.

There’s also the Russian version of this review. Careful: it might contain spoilers to Iron Man 4 movie.

Hey everyone, Nikita’s here. Our ICO review master has recently obtained TON test blockchain code. I won’t go into general details within this article but will just execute my poor development skills that I use all the time to analyze what’s up with the whole TON thing. You’ll find basic TON concept explanation here as well as somewhat thorough code review. Let’s see what did investors pay 1.7 billion dollars for.

Readme

What do we have here? README.txt contains description of the “light” client. “Light” client means that we won’t download the whole blockchain, but will just connect to some cloud node and talk to it through some kind of RPC connection, similar to Ethereum blockchain — if you were to download full client of Ethereum, you would have to dedicate ~243 GB of space on your drive to it. But having the light client you would be able to explore accounts, send Ethereum and create smart-contracts.

Then they say that it’s just test code, so it might be incomplete, outdated, and even plain not working because of inevitable major changes to the dev versions of the blockchain. The usual instruction written by developers for developers. It also contains the manual on how to launch the client and use smart-contracts.

Config

Let’s see what we can change. Following the ton-lite-client-test1.config.json code we see the key to connect to the node, node IP address, access port, type of the key as well as the node type. At least they JSON file here and didn’t make us to use env variables. But YAML would be better, yes. It looks like we’ll have the lightest version of the client that would connect to the node IP 1137658550. I wish we had actual node code — that would be a blast! It would have full-scale virtual machine, smart-contract execution, ponies and happiness for everyone (according to the TON whitepaper).

How so?

HOWTO.txt file gives us direct instructions on how to use TON blockchain, how addresses are formed, how smart-contracts are compiled, how to transfer GRAMs and faucet test GRAMs in the test network.

True TON

Pretty damn long document called ton.pdf consisting of 140 pages is finally here and explains everything we wanted to know about TON. I’ll try to give you a brief explanation of the main points.

TON term consists of mainchain, workchain and sharchain. Mainchain contains overall blockchain state with workchain hashes. Workchains contain the usual stuff contained in a blockchain (addresses, transactions, smart-contracts) and are subdivided in shardchains. Shardchains do not consist of usual blocks but instead consist of accountchains — each being a small blockchain itself. Just like in OOP where everything is an object or like Function Programming where everything is a function, in TON — everything is a blockchain, even if it just consists of address account details (hence the name — accountchain). I’m a blockchain, you’re a blockchain, your cat is blockchain, dog too. Everything is a blockchain.

In reality though, accountchains don’t exist — they are virtual. Just like in a bag of marbles. You can group all marbles in the groups of 10 and call them “smaller bags of marbles” to count them easier and faster — for your convenience. But in fact, it’s still just a large bag of marbles altogether. So “virtual” here means “for your convenience, but irrelevant for the machines”.

Also shardchains and workchains can all send messages to each other with the speed of light. Wanna send a message from one shardchain to another? Boom! It’s there, in the very next block of the destination shardchain. There can be up to 2³² workchain each consisting of up to 2⁶⁰ shardchains.

Workchains can have different virtual machines, account structure, etc. Shardchains always have the same logic within one workchain.

Workchains can be created by anyone, as soon as they pay fee high enough and get 2/3 validators to accept the workchain by supporting it’s peculiarities in logic programmatically.

Shards are actually pretty cool. If workchain is under huge load, it will split into smaller shardchains to support faster transactions and higher loads — as well as shardchains will merge if the load goes down. All done automatically to ensure the speed of transactions in TON.

Telegram has reserved workchain #0 or basic workchain where GRAMs are going to be circulating.

TON is a platform for creating blockchains. First blockchain created on this platform is GRAM circulation network with the first virtual machine to execute smart contracts.

TON will have validators — around 100 of them. The more GRAMs they have, the more GRAMs they get for keeping the state of the blockchain, executing smart contracts and attaching new blocks to the blockchain. Each workchain will have 1024 smaller validators who are selected pseudo-randomly every 1024 blocks. These are the guys who will suggest blocks to the main validators. If validators try to cheat, they get punished by lossing GRAMs or ability to become a validator for some time.

If the mainchain gets forked, most of the workchains will also have to be forked.

Anybody can become a snitch by telling the blockchain about bad validators and receiving reimbursement in GRAMs for snitching. In case if a bad block is found on the blockchain, blockchain doesn’t revert and recalculate everything like we used to in mainstream blockchains, instead blockchain self-heals with ripple-like process from the bad spot outwards.

Next portion of the document simply describes various types of blockchains. Nothing interesting.

It’s important to note that reimbursements to validators are going to be paid with GRAMs that are the base currency of the base workchain.

Workchains will be able to have both free and paid state storage. Paid (like Ethtereum has) will make users to pay for every action — transferring coins, for instance. Free portions are going to be limited by the threshold set by workchain logic. I.e. you might be able to run small transactions without fee on some workchains. If account won’t have enough money to cover an operation, account gets destroyed. Durovs assume that validators will offer free removal of such useless accounts to decrease the blockchain size, however some workchains might introduce reward for doing so.

In fact, every account in TON is an “actor”. “Actor” can get messages and act upon them. E.g. “actor” can be a smart-contract that does something when it receives funds. Messages can be sent out of nowhere — you don’t have to spend gas on such messsages.

TON cannot be mined by simply brute-forcing hashes. Instead you have to be a validator to execute smart contracts, store the blockchain state and add blocks to the blockchain. Instead of mining pools, TON has a concept of nominators. Nominators lend their GRAMs to validators. The more GRAMs validator has, the more GRAMs they are rewarded with — and they can split the reward with their nominators. If validators loose their GRAMs, nominators loose GRAMs as well. If a validator has poor hardware, they might receive less reward.

Then Nikolay tells us more about various types of the blockchains for 13 pages. Weird flex and sounds like communist propaganda, but ok.

Then Durovs answer the most popular question on Quora: can you upload Facebook to blockchain? The answer: no, silly, you wouldn’t want to do that — it would cost at least 100 times more than Zuck pays for servers now. Looks like they’ve got tired of such questions being asked by their investors.

And, of course, Nikolay doesn’t look for easy ways, does he? SSL? No — MTProto. UDP? No— it’s better to come up with our own network protocol with blackjack and the second thing (can’t remember which one).

Aside of the new and shiny network and encryption protocol, Kolya had to build his own DNS. One cannot simply use some weird for of IP, no, we need our own distributed list of TON member addresses. Can’t complain but it feels like an overkill here.

Actually, you should already be familiar with the concept if you’ve ever downloaded anything over the torrent system. Finding peers and the rest of the things. Next 10 pages are dedicated to explaining how it all works.

But it’s pretty cool that RON will be able to work as DNS server. In theory, anyone would be able to run a website or service on their hardware and tell TON about then — then anyone would be able to connect directly. Like Onion, yes.

Even better: Telegram will also be able to use TON DNS which will allow all the Telegram clients to quickly find and connect to the Telegram service rendering any attempts to block it by authorities useless.

Next topic of the paper is TON Payments. It begins with the explanation of various ways they could’ve implemented it and proceeds to what method they’ve picked.

Then the paper tells us about GRAMs. There will be 5 billion grams in the beginning. You’ll be able to buy them either on the free market or directly from TON. Each GRAM will be sold one billionth of the US dollar more expensive than the previous, starting with $0.1 per GRAM.

Durovs explain that this will help with the price fluctuation on the markets. Yes, it will help holding the growth, but they forget to mention that it won’t hold the price crash. Sure, they can offer buying coins back — but it will only last until they run out of money to buyback the tokens at lower prices.

This marks the end of the whitepaper. Such an awesome 100+ pages journey.

Fift or the new Forth

Yep, yet another language, but this time it looks like assembly — and feels this way too

Let’s begin withfiftbase.pdf and all the features of the Fift programming language. We have just adapted to Solidity by Vitalik and now we have to learn new programming language. THANK YOU KOLYA.

But let’s stop complaining and let’s dive into it. It’s worth to mention that Fift was created specifically for the base workchain of TON and TON virtual machine — other workchains can have different virtual machines and smart-contract languages.

Fift uses polish notation for its syntax. An argument for it would be that noobs won’t be able to write shitty code with it. An argument against — experienced developers are going to write this shitty code now with smart faces all the way through. The more complicated the language is, the easier it is to write crappy code.

Good thing though — we can run Fift files both independently as well as use sandbox in the terminal. Overall, FIft with it’s polish notation is soooo uneasy to read. As soon as you loose concentration, you have to start over. You always have to keep stack in the back of your mind. However, good think is that you can always read all the code from left to right.

One could ask: why would you even use this notation in a programming language? No answer will be given. It has exactly the same things as usual notation: loops, hashmaps, arrays, variables, functions. You just add a notation on top that would drive most of the developers mad.

Overall, yet another programming language. Nothing new and no break throughs. The only thing i can predict is millions of dollars stollen because of the complexity of Fift and developers’ mistakes.

Also, direct assembly command execution is cool and all, but probably close to no one will use it because the main use case is going to be creating a decentralized ledger for yet another ICO shitcoin.

Blockchain specifications

Let’s investigate the file named tblkch.pdf. OH. MY. GOD. 121 MORE PAGES. At this point I’m almost sure that TON team wrote less code than documentation for it!

All in all, nothing new can be learnt by a usual reader from this document. It’s dedicated for the smart ones who are going to create their own workchains. This doc is a longer (or sometimes shorter) version of the blockchain docs from ton.pdf. Same descriptions of the blockchain functions, blocks, accounts, types, abilities, etc.

I quite liked the example they give about how to implement your own cryptocurrency on the page 29. Looks like we are goin to be swamped with the new cryptocurrencies soon.

The whole document is simple a reference for developers. Sharding — concept explained. Split and merge — concept explained. Proof of Stake — concept explained. Hypercube Routing — concept explained. Like an encyclopedia but for TON developers.

Overall, everything is quite well-written, easy to understand and pretty logical. I couldn’t find any obvious loopholes.

Virtual Machine

So what do we have in the tvm.pdf file? It’s the TON virtual machine implementation explanation. Basically, how it runs smart-contracts on validators’ hardware. And yes, 155 pages of specifications. Why did I even start reading all of it?

This doc explains the bottom layer of the program that is going to use CPU or GPU to run Fift code. It really looks like assembly specs, familiar to anyone who has built a programming language from scratch in University.

Registers docs, stack, data types, data structures, function interpretation, operations, permanent storage, etc. It’s like reading LLVM specs all over again. Everything you can do with Fift is laid out in this doc.

No breakthroughs, again. It’s just a virtual machine, no more — no less. The on just like Ethereum, EOS or even Bitcoin has.

Coding

Time to skim through the code repository. As I’m officially the TON blockchain and technology expert (after reading over 500 pages of manuals), I’m sure able to provide you with the first look on the light client code files.

As usual, I’ll start from general things. Code is written mostly in C++, there is close to none formal documentation — only the general commands are outlined in the readme, which isn’t that bad as we have tests. And we all know that types and tests are the best documentation. License used is LGPLv2 — if anything goes south, TON isn’t accountable for it. Usual for such types of projects.

Let’s go though the code folders.

• validator — I think that it’s the data model for validators to show in the blockchain explorer
• ton — interfaces of the actual TON node sitting in the cloud; allows to see what’s happening with the shardchains, blocks and addresses
• tl — this is a bit more interesting: different utils like JSON encoding and decoding, as well as the base TLObject class
• third-party — just third party dependencies:: abseil-cpp (standard C++ library extensions), crc32c (library by Google), rocksdb (key-value storage by Facebook)
• test — this folder contains tests that show what cat TON light client do — in particular to observer what’s happening in the blockchain
• terminal — just a terminal interface to run commands
• tdutils — it’s nice to realize that even TON developers have a folder that contains all the utility functions that can’t be put anywhere else: helpers for buffers, gzip, JSON, ports, heap, various enumerations, etc.
• tdtl — I think it’s the data structures for Fift (just like tl)
• tdnet — looks like the files for the TON node network layer, we can connect to it over UDP, TCP and FD
• tddb — I think it’s the local database persistent storage based on rocksdb
• tdactor — looks promising (pun intended) because the concept of “actor” is one of the central in TON; we can notice the promise and multipromise implementations here
• crypto — various cryptography functions as well as full on Fift compilator and the stripped virtual machine! Looks like it’s used to compile smart-contracts. Nice.
• adnl — the tunnel for the networking layer discussed before, looks like it runs over TCP или UDP — almost like SSL

As I anticipated, it’s just the light client. No mining, no validation, no special and unique functions were present (and they should not have been). In fact, it’s just a wrapper around the TON cloud node hanging on the specified IP address. You can create addresses, faucet test GRAMs, send messages and transactions, create smart-contracts.

Can’t say much about the code. Standard C++ code — not the best I’ve seen, but neither it is the worst. It gets a C+ or B-. Could’ve ran prettier over it. Just one issue though — why C++ wrapper for a simple JSON RPC of the TON node? Why nothing fancier like Node, Python or Ruby? You can always make Fift compiler and virtual machine as a stand alone module. It just looks like an overkill for such a simple task.

Conclusion

Thank you for reading through my boring review. I’m glad you’re here — it means that you are now also an expert on TON topics and can use points from this article in the next Drink & Code meetup to impress your crush. We can conclude the following:

1. Only the light version of the client got “leaked” — just a wrapper around TON cloud node RPC
2. There is no node and validation code yet, looking forward to the new “leaks”
3. Code looks too fresh and unready — almost feels like a quick wraooer to show the functionality to the investors
4. Aside of looking at your address, getting 20 test GRAMs and Fift compiler with the stripped virtual machine, we haven’t seen much yet
5. Fift with its polish notation is hell for a usual developer. WHy overcomplicating things? No one knows.
6. I unironically loved the TON documentation. Every page out of 500+ pages was delightfully crafted with as much information on it as possible. It’s clear now how TON and all of it’s components are going to be built and how they are going to be working.

To sum up, it’s too early to come to any conclusions. But as soon as TON cloud node code will be released, you can bet on me reviewing it. However, I was still pretty pleased to finally learn what the Telegram team was up to instead of fixing bot API (seriously, Voicy has been experiencing huge issues over last few weeks, I’m angry).

This was Nikita, Golden Borodutch Telegram channel author (sorry, it’s in Russian). I also facilitate Honest ICO Reviews — worth checking out and subscribing to be protected from scam ICO’s.

The best reward for me would be if you clapped 50 times to this article (by holding the clap button) and if you shared this article with a couple of friends interested in TON. Thank you a lot! And good luck.

P.S., I’m here in comments, ask me anything about TON. Cheers.