Amidst news of its contempo spat with the United states of america Securities and Exchange Commission, relatively few people have likely heard well-nigh Telegram's Open Network competition that occurred some weeks ago. It was a milestone event that transformed the once-miniscule TON developer community writing in Fift (TON'south general-purpose programming language), which differs greatly from mutual languages due to its depression-level approach.

The competition attracted new developers, further built a community around the new platform, and solved existing problems apropos the lack of documentation on smart contracts past providing examples of them and how they are deployed on TON. My squad, Button Wallet, and I too participated, and take summed upwardly everything that happened during and after the TON contest.

Lack of documentation

FunC — TON's other language for writing smart contracts is FunC, a loftier-level linguistic communication similar to C with functions and variables that is much easier to read and write in than the general-purpose Fift. A like comparison would be C# and CIL. Still, prior to the contest, there was barely any documentation of FunC. This posed an event, as nearly of the TON contest tasks required contestants to write a smart contract.

Due to the lack of documentation on writing for TON using FunC, contest participants needed to analyze and learn from existing examples, which had been uploaded to a small GitHub repository and the TON test website along with some theoretical details. While this wasn't a difficult chore overall, understanding the basic necessities of a language based on nothing but examples can testify challenging. Nevertheless, most contestants were able to start writing freely in FunC later on the get-go few days.

Nuts — When writing a smart contract using FunC, nosotros needed to sympathize how to deploy and compile the smart contract, as well as how to telephone call functions using arguments. The complete lack of detailed information on this fundamental aspect of the language — in addition to in that location not beingness any examples showing the total steps — was almost laughable for its irony. TON's brief guideline was extremely helpful to those who participated in the competition, simply it was simply an introduction to writing smart contracts on TON that conveniently left out examples or detailed data on deploying and running part calls on smart contracts. Eventually, anybody figured out how to do all of this, but it took considerable time and effort.

Contest tasks

There were two tasks out of the five total that I want to highlight: the asynchronous payment channel and the synchronous i. Simply first, what is a payment channel?

A payment channel is a way to send transactions between two parties off-chain (i.due east., outside of the blockchain) to make it faster, less expensive and more than customized. Users accept their ain accounts on the blockchain and can send transactions between themselves using their deposited sums. For this, a special smart contract stores the deposited funds of the ii parties while the payment channel is open. Withdrawals crave a smart contract containing certain data, which volition be discussed below.

Parties A and B send coins to the smart contract, making deposits to open a payment channel between them Parties A and B transport coins to the smart contract, making deposits to open up a payment channel between them

To open the payment channel, funds demand to be deposited to the smart contract from both sides.

Party A sends a transaction to Party B, changing the state of payment channel from (a, b) to a new one

Party A sends a transaction to Political party B, changing the country of payment aqueduct from (a, b) to a new one

If the payment channel is open, transactions tin can be sent betwixt parties with a speed of more than 100,000 transactions per 2nd. It is important to empathise that this all happens off-chain and that at some point, the parties will need to reach an agreement and withdraw their funds from the smart contract.

An off-chain transaction from A to B through their synchronous payment channel

An off-chain transaction from A to B through their synchronous payment channel

It is assumed that the parties might try to unfairly withdraw all funds within the pool. Because of this, each party needs to evidence that the sum they are going to withdraw belongs to them. To bear witness this, each party needs to transport their signature, which correctly proves the state (sum A, sum B, and some other information).

The synchronous payment channel has a state number that does not change unless specific requirements, such every bit receiving Political party B'southward confirmation and signature, are met. Therefore, Party A cannot send several transactions to B in a row, every bit each new state requires a signature from both parties.

When sending a transaction to Party B, Party A needs to create a state that will change the amount that will belong to both A and B, sign this state using its own private cardinal, and and so send the new country and signature to B. Party B and then signs this country and sends its signature dorsum to Party A, thereby confirming the transaction condition. Party A cannot send another transaction to Party B until B creates a new state. Due to this, it is called a synchronous channel.

An off-chain transaction from Party A to Party B through an asynchronous payment channel

An off-chain transaction from Political party A to Party B through an asynchronous payment channel

In an asynchronous payment channel, each counterparty has its ain group of states. Each state consists of the amount that Party A received from Party B, the number of transactions that Party A has sent to Party B, the amount that B sent to A, and the number of transactions that B has sent to A. Dissimilar in a synchronous payment aqueduct, A and B do not demand to wait for confirmation from one some other, they but demand to send a signed country.

The most hard aspect for both channels is the withdrawal process. The smart contract needs to bank check that each political party has provided the correct data before funds can be withdrawn. We need to cheque the signatures of state and as well that this state is the latest. If in that location is a conflict betwixt the parties, the smart contract needs to resolve it according to the latest country.

At that place must exist protection against sending the same information to unlike payment channels, equally well every bit a resolution for when i party does not provide any information. All of this must be written in FunC and thoroughly tested in order to exist secure.

Solutions and competitors

According to the contest's official channel, there are 68 submissions.

Most of the submissions were multisignature wallets and domain proper noun system (or DNS) resolvers. Nonetheless, several submissions are for payment channels. Writing payment channels was the contest'south about complex task, so the few strong teams (such as 363, 375, 381) that were able to produce such solutions were more than prominent than the others.

What's side by side?

Currently, there are about 10 to 20 teams with enough skills and cognition to outset edifice TON'south infrastructure, and they will probable transfer most of the successful Ethereum solutions to TON. The TON contest and its $200,000 prize pool incentive greatly additional the number of teams that can work with the platform by providing an opportunity to gain feel with it first-manus. Now, the participating teams are all set to build their own projects or startups on TON.

Key takeaways for the Push Wallet team

As early on TON adopters and lovers of Telegram, my team and I decided to participate in the TON competition. Nosotros had a big team of eight people. For our solution, nosotros decided to build synchronous and asynchronous payment channels. Although nosotros fabricated some mistakes during the contest, we did manage to make a synchronous payment channel with all the wrappers that allow deposits, withdrawals, and the transfer of transactions using our command-line interface. Then, we made not only a smart contract but a lot of wrappers over it that allowed working with TON much easier. After we finished the synchronous channel, we leveraged noesis from our Plasma developing experience and built another smart contract that implements asynchronous off-chain payments. All the same, we were unable to write all the wrappers to it before the deadline.

We thoroughly enjoyed all the tasks and wish that we'd had more fourth dimension to implement all of them. Nevertheless, we won the first place for all-time synchronous payment channel equally well as third place for best asynchronous payment channel.

The views, thoughts and opinions expressed hither are the author's lonely and do non necessarily reflect or represent the views and opinions of Cointelegraph.

Nick Kozlov is the CTO of Button Wallet, a software programmer and researcher, too as one of the winners of the TON competition.