🐂 Not all bull runs are created equal. November’s AI picks include 5 stocks up +20% eachUnlock Stocks

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

Published 02/14/2020, 05:17 PM
Updated 02/14/2020, 07:02 PM
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

    Latest comments

    Risk Disclosure: Trading in financial instruments and/or cryptocurrencies involves high risks including the risk of losing some, or all, of your investment amount, and may not be suitable for all investors. Prices of cryptocurrencies are extremely volatile and may be affected by external factors such as financial, regulatory or political events. Trading on margin increases the financial risks.
    Before deciding to trade in financial instrument or cryptocurrencies you should be fully informed of the risks and costs associated with trading the financial markets, carefully consider your investment objectives, level of experience, and risk appetite, and seek professional advice where needed.
    Fusion Media would like to remind you that the data contained in this website is not necessarily real-time nor accurate. The data and prices on the website are not necessarily provided by any market or exchange, but may be provided by market makers, and so prices may not be accurate and may differ from the actual price at any given market, meaning prices are indicative and not appropriate for trading purposes. Fusion Media and any provider of the data contained in this website will not accept liability for any loss or damage as a result of your trading, or your reliance on the information contained within this website.
    It is prohibited to use, store, reproduce, display, modify, transmit or distribute the data contained in this website without the explicit prior written permission of Fusion Media and/or the data provider. All intellectual property rights are reserved by the providers and/or the exchange providing the data contained in this website.
    Fusion Media may be compensated by the advertisers that appear on the website, based on your interaction with the advertisements or advertisers.
    © 2007-2024 - Fusion Media Limited. All Rights Reserved.