Tonscan

Collaborating closely with Bastion Digital, we built Tonscan—the most user-friendly explorer of the TON blockchain. In this article, we dive deep into the tech work, outlining how we built both the front- and backend of the explorer.

Fostering the TON Blockchain

Bastion Digital is the global leader in secure institutional custody, staking and asset management for The Open Network (TON)—a blockchain platform that’s rapidly expanded since its launch in 2021 and the largest TON staking institutional provider in the world. Their team approached BB back in 2023, asking us to help them with a variety of products, including a set of better tools to foster the (then quite low-key) TON Blockchain.

Since then, TON has gained lots of traction. Toncoin, TON's native cryptocurrency, has gone from a largely unknown currency, valued at around $2 back in spring 2023, to having an embedded wallet in the Telegram Messenger, used daily for payout of Telegram ad-sharing profits. Valued at $6–$7, TON is on track to surpass Ethereum in on-chain holders in the near future.

Challenges

As part of our long-term collaboration with Bastion Digital, we were tasked with building the blockchain explorer Tonscan. A blockchain explorer is an indexed database of all the things that happen on a blockchain—making this a user-friendly experience raises several challenges.

Firstly, blockchain technology is often quite a leaky abstraction — although you can deal with high level concepts like a wallet and transfers of tokens or coins, you quickly got exposed to technical details like hashes or block validation time. How can we both make the blockchain approachable to novice users, while still offering developers or enthusiasts a chance to see all the nitty gritty details?

Secondly, as the name implies, an explorer is for exploring. People come for all sorts of reasons, and you cannot design a tightly targeted UI flow like you could for a straight-forward product, like an e-commerce checkout. How do you design a sensible information hierarchy for a very open application?

And thirdly, the TON Blockchain has just north of 5M daily transactions these days. This means significant storage is required to keep all of TON history, as well as significant compute power to keep up-to-date with the ever changing chain. How do you store and update this information while still keeping the UI snappy and updated?

Starting on the backend

We started Tonscan on the back-end, by building on an open source TON Indexer. Since then, we have replaced it completely with our own indexer. The indexer is written in Python and talks directly to the TON Node’s LiteServer interface. We run these on the same bare metal machine from AWS, allowing us minimum latency between TON Node and indexer. The indexer feeds a PostgreSQL database which serves all tonscan.com API requests. At the time of writing the database is around 500G, with tables for accounts and transactions dominating that storage, at around 125M and 2B rows each.

Understanding the blockchain

All data, from transaction details to smart contracts and account data is stored on the TON blockchain as so called Bag-of-Cells (BoC). BoC is a tightly packed binary data in cells no larger than 1023 bytes. The format is ideal for a blockchain where a lot of time is spent ensuring global consensus and verifying the integrity of this data, but is not the most developer friendly format.

Unlike something like JSON, which is self-describing, BoC does not include any schema information. TON defines the TL-B type definition language used to define the schemas determining how binary blobs are to be decoded into structured data. These TL-B definitions are available for core blockchain concepts, such as blocks, transactions, messages, etc., and are also usually specified for standards such as NFTs or Jettons (TON’s fungible tokens, like ERC20 on Ethereum) building on top of TON.

We built our own framework for decoding BoC data for Tonscan, indexing the content of messages, transactions and other important things as JSON in our database. This allows us to quickly do aggregate queries and keep important meta-data such as NFT ownership up to date.

Another barrier to understanding what is happening on the chain is the lack of human understandable identifiers. Accounts, transactions, and contracts are all identified by long hashes. TON does define user-friendly address formats, but it remains a string of essentially random characters and numbers.

For Tonscan, we try to find labels for things wherever possible – starting with a community maintained address book which gives names to some central and important accounts. We also build on a list of official contracts from our friends at TON Keeper (like the real Tether/USD contract, or the Ethereum/TON Bridge), adding a ruled based classifier for scam accounts on top.

Database performance

Tonscan's database is of a size where all queries used by interactive feature in the webapp require dedicated indexes for acceptable performance. A blockchain explorer is also a slightly tricky beast to performance tune. When people visit, it's mostly to check that their transaction has gone through and that their balance has changed. This means these have to be as up to date as we can manage, making them unfit candidates for extended caching. 

To work around these limitations, we have three layers of caching with carefully tuned caching durations, internally using Redis (which we can also invalidate selectively), then a layer of server-side rendering in Vercel, and finally a global CDN and caching in Cloudfront.

A flexibile frontend system

Building a frontend for a blockchain explorer meant that we had to create a system that matched the network’s versatility. A smart contract can take any form, so the frontend had to reflect this flexibility. For example, an address might represent a wallet, an NFT, or another unique contract type. To handle this, we parse the blockchain data and dynamically render the appropriate components.

Graphs were essential for clarifying complex data for both casual and advanced users. We developed custom graphs that are both information-dense and interactive. For example, a graph that shows the sequence of messages in a transaction and the relationship between them.

Another example is the validation graph. Validation is a process that keeps the blockchain secure and stable. A validation cycle involves multiple events occurring at different points in time. We developed a graph that clearly visualises these events, making it informative and easy to navigate.

Design-driven tech, or tech-driven design

Building Tonscan has been a fun and challenging endeavour. Dealing with a blockchain that has such a high daily transaction volume and a growing community of devs who keep on building new distributed applications means there is never a quiet moment. We love this complexity.

BB has always been a tech-driven design agency or a design-driven tech agency, depending how you look at it. Either way, this project showcases how the two disciplines combined make for a stronger end-product!