Mitja Goroshevsky — CTO of TON Labs team. It is known that after the Telegram team was forced to abandon the launch of the Telegram Open Network (TON), the TON Labs development community continued to develop the project and launched the Free TON blockchain in May 2020.
In the broadcast on the Basic Block Radio, they discussed the problems of scaling, the technical nuances of the TON protocol and promising applications based on it.
Hosts: Alexander Seleznev and Sergei Tikhomirov.
Getting to know TON, working in the Telegram team
- Mitja, how did you get into the blockchain?
I have been developing a distributed database since 2004, and I was very interested in all the protocols associated with everything distributed. I learned about bitcoin around the very beginning, in 2010. Of course, it was interesting, we talked about it for a long time. I wanted to mine, but my colleagues dissuaded me: “Stop it, it’s pointless, now all the Chinese will win, you will lose money…” Then I listened to my colleagues. Since then I never listen (smiles).
The idea itself was amazing because we knew how hard it was. When we created our base, we did not think in this direction. We did not have a task to solve the Double-Spending problem, we did not create such a payment system. But it was fun to see how elegantly it was done. But nothing could be done on it. That is, the script is clear, Forth is clear, a very cool cyberpunk idea is a plus. But as with the technology platform, it was difficult to do anything with it. After Ethereum came out, then it became really interesting.
I joined and at first, wanted to make a messenger with inside money transfers and even talked to all sorts of funds, but then Facebook came out and said that it would make a messenger with inside money transfers. And the funds told me, that, unfortunately… Nobody saw messengers with money transfers on Facebook… But when Mark comes out and begins to tell how he will send anything through the messenger all over the world — it’s hard to oppose something.
I got involved in other projects, was the chief architect of ShelterZoom — a blockchain-based real estate project… There is a huge chain of people selling real estate in the USA. And this is not a single broker, as in Europe, but entire hierarchies of other market participants. And there is no trust between them, they do not believe each other for a single second. And it is clear that this is a good case for blockchain.
Later we crossed paths with Pavel Prigolovko. At some point, he called me and said: “What do you think about TON?” I replied that I don’t know anything about it. He explained that it is Telegram that launches the blockchain. I read the white paper, but we didn’t think then that Telegram wouldn’t be able to continue the project. I drew a roadmap, what I would do to help TON, what needs to be developed so that the project can develop, etc. And we still follow this almost unchanged.
- You decided to dedicate many years of your life to the TON project… Why did you make TON Labs, and not Ethereum Labs, for example?
Initially, when Pavel called me, they were already engaged in TON from the investment side. So they wanted to help develop this ecosystem, because there was money in it, and that’s natural. And from my point of view, I evaluated it as a technological story of how interesting it can be. I read the design and it was fun enough to do it.
- I remember flipping through that whitepaper that was published somewhere, and it was not completely clear whether it was TON or some kind of fake. And if we all agreed that it was TON and it turned out to be so, I had the impression that there are a lot of ideas that sound very impressive, perhaps, especially for an uninitiated person, but without specifics.
They promised some kind of endless sharding, hypercubes… It seems that the author of the document had a glance, they say, that you are digging into your Bitcoin, Ethereum? Here we, the smart Durovs and the company came, and we will explain to you how it should be. Why didn’t Bitcoin or Ethereum figure it out before? What is the grain of innovation here, as it seemed to you then?
We are probably talking about different documents, of which there were several. For example, the document “Premier” is such a “high-level blah blah”, sorry. There was a little more detailed white paper, but yes, in some places it is very superficial. And you are right, he talked about submarines plowing through the skies (smiles). There was also a document called TON Virtual Machine, which talked about Fift, Assembler, which was already more interesting.
I did not form my opinion solely based on a single document. There was also communication with the Telegram team and other documents. We started with the implementation of the Virtual Machine.
To build our tools for developers, for example, on TON, at least something was needed, but Telegram did not give any code, so we had to implement things ourselves. By the beginning of 2019, we had the blockchain working based on the Telegram virtual machine, etc., just with a different consensus to debug our tools.
- We probably messed up a little bit. You said you wrote a roadmap. Can you tell us what you were planning to do at all?
What we now call the TON operating system (TON OS). What TON Labs always planned to do — from the second parallel implementation of the protocol (we always wanted to do the second one, because it is useful for the network at least), and further — the entire stack, right down to the user interface.
If we consider the blockchain as a processor, then this is what is further between the processor and the end-user, the user of the interface. What we call the persona of the system. What helps us manage resources and throws it to the user — allows writing applications for the user.
And further, if you follow this stack, you immediately understand what needs to be done for this stack to happen. You need to write compilers, development tools, some SDK, API for this operating system so that you can communicate with its resources from your applications. And, in fact, all the protocols that will work inside this stack (insert the API protocol, etc.). The cloud-based implementation of this operating system immediately appears…
If you take such a Graph project, they take some POSTGRES and GraphQL, data in Ether and transfer it to this Postgres so that developers do not have to deploy their infrastructure. And when we talk about cloud in TON OS — it’s something similar. But you need to understand you have a blockchain that works several thousand times faster than Ether.
The amount of real-time data is simply huge because now blocks are released on average over the network in 0.2 seconds. It’s not an easy infrastructure to build. Then you need to make this SDK multi-platform, so that when a person has an application that runs today on React, tomorrow on Java, the day after tomorrow on Kotlin, Swift — it has this interface to the entire working infrastructure. This is called our SDK bindings, etc.
This is the whole stack we are doing. We started with a virtual machine, some protocols so that we could first implement messages and emulate the work of the blockchain.
We took LLVM and said that let’s first write such a compiler since we will have a blockchain for mass adoption, a large number of people. Because Telegram has 150 million users. Accordingly, when a million developers will come, in what language should they write programs? I immediately said that it is unlikely that we will force developers to write in Swift, Assembler. You need some kind of full-fledged language — for example, C or C++. And we took the LLVM framework, made the TON target platform and two compilers — C and C++.
And the second thing — there are a huge number of developers in Ether who are familiar with Solidity. We also don’t want to retrain them, so we tried to make a compiler out of Solidity. It was difficult because in Solidity there is a completely different paradigm, synchronous blockchain, a lot of things needed to be done. But fortunately, there is a person who agreed to take on this burden — a brilliant developer, Vitya Bargachev — a three-time world champion in computer science, and two-time in programming.
He alone wrote the entire Solidity compiler, including the new modified Solidity language, which is currently far ahead of the usual one. If Ethereum ever does sharding, they will have everything asynchronous and they face the same problems that we do. But we have a stable compiler ready, which has been working for a long time. This is an illustration of the fact that all the tasks that we solved lead the progress of the Solidity language itself forward. This is an interesting development.
- It was an insanely interesting speech, but I would like to go back a little. We have more or less established 2-3-5 operating system stacks, plus languages, virtual machines — everything has been working for decades, everything has been perfected … Now we have blockchains — some other paradigm of code execution, but it applies in a rather narrow area. And what you are saying sounds to me like “let’s rewrite the entire IT stack, which has been developed since the 80s, if not earlier, for the blockchain”.
How necessary is this? If we need a blockchain for a rather narrow class of applications, then let’s write its languages for it. But if it is for a wide range, then maybe we should try to use what was before us in an alternative way? JVM, existing languages, etc. What do you think about it?
Very simple. If we continue the analogy that this is a processor, then this is just another archiprocessor with a different architecture. You can’t just say: we already have a processor, no matter which one, let’s take something from there and use it. The blockchain (this processor) has absolutely some special features that do not fit into another architecture.
Distribution, verification of calculations, what these programs do… They can’t be wrong. There are very few applications or platforms in the world on which you have to write such a program so that it never fails. If it’s wrong, you will immediately lose money. This imposes some restrictions.
We do a lot of formal verification for Free TON, but there is a whole direction in the blockchain, as we know, like Tezos, which tried to make the basic language of the platform, such as verifiable.
Is it possible to take Linux and make a blockchain operating system out of it? I don’t think so. Because you run into something. In Linux, for example, the performance of your video card, local bus, memory between one component and another. In the blockchain, you run into the Network, and that’s a whole different thing. And optimization should work for these things.
- We went deep. For me, it all looks like an incredibly huge amount of work, just titanic. As I understand it, this is a powerful commit for many years, and your motivation was initially the prospect that a huge Telegram user base would be onboard quickly enough in TON, which will automatically give 100,000 points ahead of all other blockchains, which means a huge user base will instantly appear. Right?
This is partly true. Undoubtedly, this is an important motivating factor, but not all of it. If you look at the logic of Telegram — why would they invent their blockchain? They could have forked something, and that’s it. But imagine the challenge: you have 200 million users. And what can you fork, what all these users would do, and how to handle all this?
- Do we want to allow this user base to do this in the blockchain? What is it that would make sense to do this on a decentralized blockchain, and not on Telegram servers?
To be honest, Telegram saw payments first of all. But when you need to make instant payments between 200 million users and at the same time so that gas does not cost some crazy money, what blockchain (I return to my question) could have been forked 3-4 years ago? So that such a use case (even the simplest payments) could be met with a minimum gas between 200 million users?
The bandwidth needed would be such that no existing blockchain at that time and to this day can not provide… Everyone said that one day they would all make a mega-scalable blockchain, but no one did. And they had a specific design.
- And how did you plan to monetize your titanic efforts?
Initially, we had a business plan. A lot of developers come to you, they all need development tools, clouds. Since we were the main and only infrastructure player, besides Telegram, in the ecosystem, we were going to monetize, just like the usual open source model, around this infrastructure.
- It was planned to monetize more by selling development tools to developers, and not by selling some kind of core service blockchain for users? For users, the blockchain remains free, or do they pay market fees to the blockchain, and not to you as an organization? Are organizations paid by the more professional members of this ecosystem?
Yes, either way. Again, everything is within the framework of some operating system, the idea of the same Red Hat or something else. You always have some market players who pay you for expertise and infrastructure. To give it to the user later. We initially have our TON Surf — a blockchain browser that also had a user interface and the ability to use it as an application. Unlike Telegram, which would be sharpened more with TONs, interactions with smart contracts.
If you have a system of smart contracts that provide, for example, DeFi, theoretically there is an opportunity to monetize — create a project of such a plan as tokens, etc.
- Again, at the application level, and not at the core of the blockchain itself.
Of course, we didn’t have any tokens, so we couldn’t expect to receive gas fees.
- I remember when TON was still in active development, an environment of not even secrecy surrounded it, but mystics — constantly something like “leaked new documentation, Durovs confirmed it was real”, etc. At that time I was still engaged in reading white papers at my leisure. But because of this strange atmosphere — what it is, where it came from — there was no motivation to master it all.
As I understand it, you had direct interaction with the Durov brothers, i.e. you were not forced to read tea leaves of incomprehensible leaks, but could communicate directly with the development team?
We could and did communicate, but not quite in the way you think. All the same, this culture of secrecy and non-proliferation of information persisted for us. It’s not like we come and they tell us everything. This is some part of the PR, the image of Telegram, I think. This does not fit with what we have preached and are preaching — it is not as open source but as a social story.
We wrote the code for four years, then put it in open source. Everything is fine there, use it. It’s not like if we put the code in an open source at an early stage, they say, let’s contribute there, we will do it together. It never happened, and we had to play it too. We were also closed. When your basic layer is not disclosed, it is difficult to distribute any higher-level tools in open source.
It was very often that we ran ahead with tools, compilers, and then only some Telegram code came out, and we had to go back because nothing worked with this code anymore, we had to change it. This is not according to the documentation at all and was very common. For example, we almost made a node and a blockchain, and then we received the node code (Nikolai posted it in September), and we had to rewrite a lot. Actually, we are still debugging it.