Behind the Scenes of TON: Lessons Learned on Deploying Smart Contracts, Part 2

Cointelegraph

Published Feb 14, 2020 05:17PM ET

Updated Feb 14, 2020 07:02PM ET

Behind the Scenes of TON: Lessons Learned on Deploying Smart Contracts, Part 2

This is the second article in our series on integrating payment channels on Telegram Open Network. In the first part, we introduced the network, detailed our experience of the contest, and explained how synchronous and asynchronous smart contracts work. As the next addition to the series, this article details how we built a synchronous payment channel on the network during TON’s contest back in September. Here, we will be talking only about Fift (TON’s general-purpose programming language) and FunC (TON’s programming language for writing smart contracts).

The TON white paper provides more in-depth information about payment channels, but we will briefly explain them again.

  • Code of the smart contract as a single cell (usually written in FunC, then compiled into Fift ASM code and included in the main .fif file using path-to-compiled-asm.fif).
  • Initial storage of the smart contract (see below).
  • New smart contract address (the hash from the initial state of the smart contract that also includes the smart contract code cell and the initial storage cell).
  • Arguments of the first call of the recv_external function (the amount of arguments and type depends on the contract).
  • An external message cell for initialization, which will be serialized into bytes and packed to the .boc file, which consists of all the data from points 1–4 and some additional ones that are still lacking documentation.
  • seqno 32 bits
  • contract_status 4 bits
  • first_user_pubkey. The first party’s public key 256 bits
  • second_user_pubkey. The second party’s public key 256 bits
  • time_to_send. Time to send after the first actual state being submitted 32 bits (valid until 2038)
  • depositSum. The deposited sum of two participants up to 121 bits
  • state_num 64 bits. The current amount of states that occurred
  • The user generates an additional body payload that includes a message (for example, 1 bit) and its signature in a separate .fif file.
  • Body payload is compiled to a .boc file.
  • Body payload is loaded from this .boc file into a .fif file as a body-cell “transferring” reference (the .fif is responsible for transferring GRAMs from the wallet).
  • The recv_external function is called with arguments (the deposit amount and the destination address of the channel) when the compiled .fif file is sent to the network.
  • The send_raw_message function is executed. Deposited GRAMs and additional body payload is sent to a P2P channel smart contract destination address.
  • The recv_internal function of the P2P channel smart contract is called. GRAMs are received by channel contracts.
  • Smart contract address (to exclude the possibility of entering the correct state from the previous P2P channel with the same participants).
  • The final balance of the first participant.
  • The final balance of the second participant.
  • State number.
  • The deposited amount from the storage should be equal to the sum of the total balances of the participants.
  • The new entered state number must be greater than or equal to the previous one.
    • Continue Reading on Coin Telegraph