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.
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
Disclaimer: Fusion Media
would like to remind you that the data contained in this website is not necessarily real-time nor accurate. All CFDs (stocks, indexes, futures) and Forex prices are not provided by exchanges but rather by market makers, and so prices may not be accurate and may differ from the actual market price, meaning prices are indicative and not appropriate for trading purposes. Therefore Fusion Media doesn`t bear any responsibility for any trading losses you might incur as a result of using this data.
Fusion Media or anyone involved with Fusion Media will not accept any liability for loss or damage as a result of reliance on the information including data, quotes, charts and buy/sell signals contained within this website. Please be fully informed regarding the risks and costs associated with trading the financial markets, it is one of the riskiest investment forms possible.