Bitcoin is dead again, economies are in recession, wars are everywhere. It’s once again the time to build decentralized systems!

Preface

For the past 8 years I’ve been extensively studying cryptography, Bitcoin, politics of crypto-anarchy and cypherpunk culture. The very first day when I discovered Bitcoin I understood that the world is irreversibly moving towards decentralized finance based on asymmetric security offered by powerful cryptographic protocols.

As a product designer, I decided to help bridge the UI/UX culture with the most hardcore cipherpunk culture. I built the first iOS library for Bitcoin that at some point powered half of the wallets on AppStore. My Bitcoin FAQ was recurring in the Bitcoin Magazine. I’ve written a number of popular articles on crypto-anarchy and Bitcoin.

I began studying cryptography by designing my own blind signature scheme aimed at improving security of crypto-wallets while not compromising ergonomics and privacy. Together with amazing Cathie Yun and Henry de Valence I’ve built zero-knowledge library Bulletproofs. Then on top of it — a novel blockchain format for confidential smart contracts ZkVM based on our prior work on TxVM with Dan Robinson and others at Chain.

TON born and reborn

While I was busy with ZkVM, folks at Telegram invented yet another blockchain, TON (then — “Telegram Open Network”). They tried to do an ICO, but were threatened by SEC and abandoned the project.

But TON did not die. The coins were dumped into mining contracts on the testnet (sidenote: oh, the irony — people mining coins on the proof-of-stake blockchain), from where the early community of developers and investors continued tinkering with the thing. This was somewhat similar to Bitcoin where we all had to decipher Bitcoin all by ourselves after its founder left the project without leaving much guidance.

In 2021 TON testnet was renamed into mainnet, its coins got listed on a couple of exchanges and the activity around the network began to grow. That’s when I learned (to my surprise) that TON is no longer an abandonware and began work on Tonkeeper.

It’s all about scaling

TON is an attempt to resolve two conflicting requirements: provide a flexible development environment on the blockchain to allow any sort of apps to be programmed, while making sure they also become horizontally scalable.

Bitcoin and Ethereum make two opposing choices here. Bitcoin (and LN) work fine at scale, but focus on virtually one use-case — securing your savings. Ethereum offers a simple yet powerful development environment, but it does not scale for the intended use-cases.

The idea of TON is to solve both of these issues and roll out decentralized markets at a massive scale.

TON is weird

Any engineer worth their salt would recognize that there must be some tradeoff if you attempt to solve both problems. The tradeoff that TON makes is employing one of the weirdest execution models in the entire computer industry. TON’s model has elements of Smalltalk’s OOP, Erlang’s distributed processes, hostility of web services and unforgiveness of smart contract and consensus systems.

In the name of scalability, TON makes many hard decisions.

For instance, your smart contract has to pay rent for its storage. When it runs out of money — it is frozen, and when it runs out of money more, its entire state is completely forgotten. This is somewhat dangerous because the contract may later be reset and all its external messages could be replayed.

Another example: contracts cannot read each other’s state. Of course, we can only send one-way messages, but we can do some good-old client-server request-response exchange, right? Not really. Those requests and responses are taking many seconds, you cannot afford any locks or mutexes (due to denial-of-service exploits), and yours or someone else’s state may change in-between these communications. Your only option is to carefully design mostly unidirectional graphs of transactions where you “tell, don’t ask” as Smalltalk programmers taught us.

One more shocking idea: in TON there are no allocations and no arrays. Your only array is the blockchain itself. The reason again is the goal of infinite scalability. The network shards the blockchain, you place your data all over the place so it’s not creating a bottlneck anywhere. If you have a multi-user contract, you should store per-user data in some sort of tokens — independent smart-contracts held by individual users. The endgame is to have O(1)-ish complexity of all the pieces, which is good, but sometimes feels like you are designing a real-time aviation software (which is also good).

Crossing the chasm

I think TON is an exciting technology. All its shortcomings are not rooted in the architecture, but in the lack of tooling and infrastructure. It is too low-level: it is a platform for building a platform for decentralized apps. Or maybe for a platform for a platform for a platform. The exciting bit is that we are starting to discover missing concepts and abstractions and can improve the design of the apps and programming languages.

This summer I kickstarted work on a new language for TON: Tact language. It is aimed at bringing order into highly asynchronous nature of smart contracts and make it easy to write secure multi-contract apps.

Later in this year I’ve attended a couple of TON-themed meetups in Prague and Dubai, where together with fellow developers we brainstormed a conceptual framework for TON contracts.

This is an exciting start of a long journey.