Summary of https://contest.com/blockchain from BUTTON Wallet Team
Not everyone has heard about the Telegram Open Network competition that occurred several weeks ago. It was a really important event, that changed a lot in the TON developer community.
As we already said, TON had quite a lack of a developers community and Fift (TON’s smart contract language) is pretty different from common languages by its low-level approach.
The contest is a great way to attract new developers and build a community, and also to solve the issue of there being a lack of documentation and examples. We decided to sum up all that happened during and after the contest from our point of view.
Lack of Documentation
(FunC) There was no documentation of funC (C-like smart contract language). It was an issue because most of the TON contest tasks require you to write a smart contract. FunC — is the main language that will be used and can be used to write smart contracts.
It is much easier to use it instead of Fift. However, due to lack of documentation (there was no documentation at all), everyone needs to analyze and try to understand several examples that were written using funC at
crypto/smartcontractIt is not really that hard, however, it is hard to understand the necessary things. It takes about several days to start writing on funC without difficulties.
(Basics) When you write a smart contract using funC — you need to understand how to deploy and compile it and how to call your functions with arguments — basics. It is funny that there was not any detailed information about that and there are no full steps examples.
We are thankful that TON gave as a small guideline that really helps us, but it is still pretty challenging. We found out how to do all of that — but it takes a lot of time and pain.
About Contest Tasks
There were two tasks from 5 that we want to highlight. An asynchronous payment channel and synchronous one. So, what is a payment channel?
Payment channel — is a way to send transactions between 2 parties off-chain (out of blockchain) to make it faster, less expensive and is more customized. Each party has own account on a blockchain.
Also, there is a special smart contract that will store deposited funds of two parties while the payment channel is open. You can send transactions between each other with the capacity of your deposited sum.
When you need to withdraw — you will call the smart contract with special data that will be discussed below.
Agent A and B send coins to the smart contract, making deposits to open a payment channel between them
When you open the payment channel — you need to deposit funds to the smart contract from both sides.
A send a transaction to B and changing the state of payment channel from (a, b) to new one
If the payment channel is open — you can start to send transactions to each other with speed more than 100 000 transactions per second.
It is important to understand that all happens off-chain and one day you will need to reach an agreement with your counterparty and withdraw your funds from the smart contract.
(Visual representation of off-chain transaction from A to B at sync payment channel)
We assume that each of the parties can cheat to withdraw all of the pool. Because of that, each party needs to prove that the sum that they are going to withdraw belongs to them.
To prove it — they will need to send a signature of each partner that proves correctly the state (sum A, sum B, and some other information). If we are talking about the synchronous payment channel — we have a state number.
A can’t send several transactions to B in a row. Each new state needs a signature from both parties (A and B). So, when A sends a transaction to B, A needs to create a state that will change the amount that will belong to A and B, sign this state using A private key, and send new state and signature to B. B needs to sign this state and send signature back to A.
Only after that transaction status is confirmed. A cannot send another transaction before B after that. A needs to wait for B to create a new state. Because of that, it is called a synchronous channel.
(Visual representation of off-chain transaction from A to B at async payment channel)
In an asynchronous payment channel, each counterparty has its own group of states. Each state consists of the amount that A received from B, the number of transactions that A sent to B, the amount that B sent to A, the number of transactions that B sent to A.
In that case A and B do not need to wait for confirmation. They just need to send a signed state.
The most difficult part of both channels — is the withdrawl process. The smart contract needs to check that each of the parties provided corrected data to withdraw funds.
We need to check the signatures of state, and also that state is the latest. It could be a conflict between parties and a smart contract needs to resolve it according to the rules (latest state). There must be protection from sending the same data to different payment channels and also we need to resolve the situation if one of the participants will not provide any information.
All of that must be written in funC and well tested to be secure. Sounds challenging.
Solutions and competitors
According to the official contest channels, there are 65 submissions.
Most of the submissions are multi-signature wallets and DNS resolvers. However, there are several of them with payment channels. It is obvious that payment channels are the most complex tasks, so there will fewer solutions and most of the teams who will provide them will be more powerful than others. We saw several strong teams and solutions like 363, 375, 381
What is next?
Currently, there are about 10–20 teams with enough skills and knowledge to start building TON’s infrastructure. We suppose that most of the successful ETH solutions will be transferred to TON by these teams. TON contest really changes the situation with the number of teams who can work with TON. Some of the teams are going to continue working on their projects.
BUTTON Wallet Team Experience
As early TON adopters and lovers of Telegram, we decided to play all in. We had a really big team with about 8 people. So, we decided to build sync and async payment channels.
We made a lot of mistakes during the contest, however, we succeeding in making a sync payment channel with all the wrappers that allow you to deposit, withdraw and send transactions using our CLI. So, we made not only a smart contract but a lot of wrappers over it that allows working with TON much easier.
After we finished the sync channel, we remembered a lot of stuff that we already know from our Plasma developing experience, so we built another smart contract that implements async off-chain payments.
However, we did not succeed to write all the wrappers to it too before the deadline.
We really liked all the tasks and wish that we had more time to implement all of them. But for now we have only sync and async payment channels :)
We will have more details about our smart contract in Part 2 that will be released soon