Как да напишем и публикуваме смарт-контракт в TON

За какво става дума в тази статия?

В статията ще разкажа как участвах в първия (от два) конкурса на Telegram за блокчейн, не спечелих награда и реших да запиша опита си в статия, за да не изчезне в небитието и, може би, да помогне на някого.

Тъй като не ми се искаше да пиша абстрактен код, а да направя нещо работещо, за статията написах смарт-контракт за моментална лотария и сайт, който показва данните на смарт-контракта директно от TON без използване на междинни хранилища.

Статията ще бъде полезна на тези, които искат да направят своя първи смарт-контракт в TON, но не знаят откъде да започнат.

На примера на лотарията ще премина от инсталацията на среда до публикуването на смарт-контракта, взаимодействието с него и ще напиша сайт за получаване и публикуване на данни.

За участието в конкурса

През октомври миналата година Telegram обяви конкурс по блокчейн с нови езици Fift и FunC. Трябваше да изберете един от петте предложени смарт-контракта. Реших, че няма да е лошо да се занимавам с нещо необичайно, да изуча езика и да направя нещо, дори и в бъдеще да не се налага да пиша нещо друго. Плюс, темата е постоянно на слух.

Трябва да кажа, че нямам опит в разработката на смарт-контракти.

Планирах да участвам до самия край, докато мога, и след това да напиша обзорна статия, но се провалих веднага на първия. Аз написах портфейл с мултиподписване на FunC и той всъщност работеше. За основа взех смарт-контракт на Solidity.

В онзи момент реших, че това определено е достатъчно, за да заема поне някакво призово място. В крайна сметка около 40 от 60 участници станаха призьори, а мен сред тях не ме имаше. В общи линии, в това няма нищо страшно, но ме напрегна нещо. В момента на обявяване на резултатите проверка с теста на моя контракт не беше направена, попитах участниците в чата дали има някой друг, който също да не го е имал, но такива нямаше.

Явно замечая мои сообщения, через два дня судьи опубликовали комментарий, и я так и не понял, пропустили ли они мой смарт-контракт случайно во время судейства или просто сочли его настолько плохим, что не нуждается в комментарии. Я задал вопрос на странице, но ответа не получил. Хотя кто судил — не секрет, писать личные сообщения я посчитал излишним.

Времени на понимание было потрачено немало, поэтому было решено написать статью. Поскольку информации пока не очень много, статья поможет сэкономить время всем заинтересованным.

Концепция работы смарт-контрактов в TON

Прежде чем что-либо писать, нужно разобраться, с какой стороны подойти к этой теме. Поэтому сейчас я расскажу, из каких частей состоит система. Точнее, какие части нужно знать, чтобы написать хотя бы какой-то рабочий контракт.

Мы сосредоточимся на написании смарт-контракта и работе с TON Virtual Machine (TVM), Fift и FunC, поэтому статья больше похожа на описание разработки обычной программы. О том, как работает сама платформа, задерживаться не будем.

Вообще о том, как работает TVM и язык Fift есть хорошая официальная документация. Во время участия в конкурсе и сейчас, во время написания текущего контракта, я часто к ней обращался.

Основной язык, на котором пишутся смарт-контракты — FunC. На данный момент документации по нему нет, поэтому, чтобы что-то написать, нужно изучать примеры смарт-контрактов из официального репозитория и саму реализацию языка там же, плюс можно смотреть примеры смарт-контрактов с прошлых конкурсов. Ссылки в конце статьи.

Допустим, мы уже написали смарт-контракт на FunC, после этого мы компилируем код в Fift-ассемблер.

Скомпилированный смарт-контракт остается лишь опубликовать. Для этого нужно написать функцию на Fift, которая на вход будет принимать код смарт-контракта и некоторые другие параметры, а на выходе получится файл с расширением .boc (что означает "bag of cells"), и в зависимости от того, как мы напишем, приватный ключ и адрес, который генерируется на основе кода смарт-контракта. На адрес смарт-контракта, который еще не опубликован, уже можно отправлять грамы.

Чтобы опубликовать смарт-контракт в TON, полученный .boc Файл трябва да бъде изпратен в блокчейн с помощта на лайт-клиент (за което ще говорим по-долу). Но преди да го публикуваме, трябва да преведем грамове на генерирания адрес, в противен случай смарт-контрактът няма да бъде публикуван. След публикацията можем да взаимодействаме със смарт-контракта, изпращайки му съобщения отвън (например, с помощта на лайт-клиента) или отвътре (например, един смарт-контракт изпраща съобщение на друг вътре в TON).

След като разбрахме как се публикува код, по-нататък става по-лесно. Приблизително знаем какво искаме да напишем и как ще работи нашата програма. И по време на писането търсим как е реализирано това в съществуващите смарт-контракти, или надникваме в кода на реализирането. Fift и FunC в официалното хранилище, или гледаме в официалната документация.

Много често търсех по ключови думи в Telegram чата, където бяха събрани всички участници в конкурса и служители на Telegram. Така се случи, че по време на конкурса всички се събраха именно там и започнаха да обсъждат Fift и FunC. Връзка в края на статията.

Време е да преминем от теория към практика.

Подготовка на средата за работа с TON

Всичко, което ще бъде описано в статията, правих на MacOS и проверих отново в чиста Ubuntu 18.04 LTS на Docker.

Първото нещо, което трябва да направим, е да изтеглим и инсталираме lite-client , с помощта на който можем да изпращаме заявки в TON.

Инструкцията на официалния сайт доста подробно и ясно описва процеса на инсталация и пропуска някои детайли. Тук следваме инструкцията, докато инсталираме липсващите зависимости. Не реших сам да компилирам всеки проект, а инсталирах от официалното хранилище на Ubuntu (на MacOS използвах brew).

apt -y install git 
apt -y install wget 
apt -y install cmake 
apt -y install g++ 
apt -y install zlib1g-dev 
apt -y install libssl-dev

След като всички зависимости са инсталирани, можем да инсталираме lite-client, Fift, FunC.

Първо клонираме хранилището на TON заедно с зависимостите. За удобство всичко ще правим в папка ~\/TON.

cd ~\/TON
git clone https:\/\/github.com\/ton-blockchain\/ton.git
cd .\/ton
git submodule update --init --recursive

В хранилището също се съхраняват реализации. Fift и FunC.

Сега сме готови да съберем проекта. Кодът на хранилището е клониран в папка ~\/TON\/ton. В ~\/TON създаваме папка build и събираме проекта в нея.

mkdir ~\/TON\/build 
cd ~\/TON\/build
cmake ..\/ton

Тъй като възнамеряваме да напишем смарт-контракт, ни е нужен не само lite-client, но и Fift с FunC, затова компилираме всичко. Не е бърз процес, затова чакаме.

cmake --build . --target lite-client
cmake --build . --target fift
cmake --build . --target func

Следва да изтеглим конфигурационния файл, в който се съдържат данните за възела, с който ще се свържем. lite-client който ще се свързва.

wget https://test.ton.org/ton-lite-client-test1.config.json

Извършваме първоначални заявки в TON

Сега да стартираме lite-client.

cd ~/TON/build
./lite-client/lite-client -C ton-lite-client-test1.config.json

Ако компилацията е преминала успешно, след старта ще видите лог на свързването на lite клиента с възела.

[ 1][t 2][1582054822.963129282][lite-client.h:201][!testnode]   conn ready
[ 2][t 2][1582054823.085654020][lite-client.cpp:277][!testnode] версия на сървъра е 1.1, възможности 7
[ 3][t 2][1582054823.085725069][lite-client.cpp:286][!testnode] времето на сървъра е 1582054823 (делта 0)
...

Може да изпълните командата help и да видите какви команди са налични.

help

Нека изброим командите, които ще използваме в тази статия.

списък на наличните команди:
last    Получава последния блок и информация за състоянието от сървъра
sendfile  Зарежда сериализирано съобщение от  и го изпраща на сървъра
getaccount  []  Зарежда най-новото състояние на указаната сметка;  е в формат [<workchain>:]<hex-or-base64-addr>
runmethod  []  ...   Изпълнява GET метода  на сметка  с указаните параметри

last получава последния създаден блок от сървъра.

sendfile  изпраща файл с съобщение в TON, именно с тази команда се публикува смарт-контрактът и заявките към него.

getaccount  зарежда текущото състояние на смарт-контракта с указан адрес.

runmethod  []    стартира get-методите на смартконтракта.

Сега сме готови да напишем самия контракт.

Реализация

Идеята

Както вече споменах, смарт-контрактът, който пишем, е лотария.

И това не е лотария, в която трябва да купиш билет и да чакаш час, ден или месец, а моментална, в която потребителят прехвърля грамове на адреса на контракта N и получава незабавно обратно 2 * N грамове или губи. Вероятността за победа ще я направим около 40%. Ако грамовете за изплащане не са достатъчни, ще считаме транзакцията за допълване.

И е важно залозите да се виждат в реално време и по удобен начин, за да може потребителят веднага да разбере дали е спечелил или загубил. Затова е нужно да направим уебсайт, който да показва залозите и резултаците директно от TON.

Написване на смарт-контракт

За удобство направих подсветка на кода за FunC, плъгинът може да бъде намерен и инсталиран в търсенето на Visual Studio Code, ако искате да добавите нещо, го качих публично. Също така, по-рано е бил направен плъгин за работа с Fift, който също може да бъде инсталиран в VSC.

Нека веднага създадем хранилище, в което ще записваме междинните резултати.

За да си улесним живота, ще напишем смарт-контракт и ще го тестваме локално, докато не е готов. Само след това ще го публикуваме в TON.

Смарт-контрактът разполага с два външни метода, до които можем да получим достъп. Първият, recv_external() тази функция се изпълнява, когато поискането към контракта идва от външния свят, тоест не от TON, например когато сами формулираме съобщение и го изпращаме чрез lite-client. Вторият, recv_internal() е когато вътре в самия TON някой контракт се обръща към нашия. В двата случая можем да предадем параметри на функцията.

Нека започнем с прост пример, който ще работи, ако бъде публикуван, но в него няма функционално натоварване.

() recv_internal(slice in_msg) impure {
    ;; TODO: реализация 
}

() recv_external(slice in_msg) impure {
    ;; TODO: реализация  
}

Тук трябва да поясним какво е slice. Всички съхранявани данни в TON Blockchain представляват колекция от TVM cell или просто cell, в такава клетка могат да се съхраняват до 1023 бита данни и до 4 линка към други клетки.

TVM cell slice или slice е част от съществуваща cell използва се за нейното парсиране, по-късно ще стане ясно. Важно за нас е, че в смарт-контракт можем да предадем slice и в зависимост от вида на съобщението да обработим данните в recv_external() или recv_internal().

impure — ключова дума, която показва, че функцията променя данни в смарт-контракта.

Ще запазим кода на контракта в lottery-code.fc и ще го компилираме.

~/TON/build/crypto/func -APSR -o lottery-compiled.fif ~/TON/ton/crypto/smartcont/stdlib.fc ./lottery-code.fc

Стойността на флаговете може да се види с помощта на командата

~/TON/build/crypto/func -help

Получихме компилиран Fift-асемблерен код в lottery-compiled.fif:

// lottery-compiled.fif

"Asm.fif" include
// automatically generated from `/Users/rajymbekkapisev/TON/ton/crypto/smartcont/stdlib.fc` `./lottery-code.fc` 
PROGRAM{
  DECLPROC recv_internal
  DECLPROC recv_external
  recv_internal PROC:<{
    //  in_msg
    DROP    // 
  }>
  recv_external PROC:<{
    //  in_msg
    DROP    // 
  }>
}END>c

Можем да го стартираме локално, за това подготвяме средата.

Да отбележим, че в първия ред се включва Asm.fif, това е код, написан на Fift за Fift-асемблера.

Тъй като искаме да стартираме и тестваме смарт-контракта локално, ще създадем файл lottery-test-suite.fif и ще копираме компилирания код, заменяйки последния ред, който записва кода на смарт-контракта в константа code, за да можем после да го предадем на виртуалната машина:

"TonUtil.fif" include
"Asm.fif" include

PROGRAM{
  DECLPROC recv_internal
  DECLPROC recv_external
  recv_internal PROC:<{
    \/\/  in_msg
    DROP    \/\/ 
  }>
  recv_external PROC:<{
    \/\/  in_msg
    DROP    \/\/ 
  }>
}END>s constant code

Засега изглежда разбираемо, сега ще добавим в същия файл кода, който ще използваме за стартиране на TVM.

0 кортеж 0x076ef1ea , // магия
0 , 0 , // действия msg_sents
1570998536 , // unix_time
1 , 1 , 3 , // block_lt, trans_lt, rand_seed
0 кортеж 100000000000000 , dictnew , , // оставшийся баланс
0 , dictnew , // contract_address, global_config
1 кортеж // обернуть в другой кортеж
константа c7

0 константа recv_internal // для выполнения recv_internal()
-1 константа recv_external // для вызова recv_external()

В c7 записваме контекста, т.е. данни с които ще бъде стартиран TVM (или състояние на мрежата). Още по време на конкурса един от разработчиците показа как се създава c7 и аз копирах. В тази статия вероятно ще трябва да сменим rand_seed тъй като от него зависи генерирането на произволно число и ако не бъде променено, при всяко стартиране ще се връща същото число.

recv_internal и recv_external константите със стойността 0 и -1 ще отговарят за извикване на съответните функции в смарт договора.

Сега сме готови да създадем първия тест на нашия празен смарт договор. За по-добра видимост, засега всички тестове ще добавим в този файл lottery-test-suite.fif.

Създадем променлива хранилище и ще запишем в нея празен cell, това ще бъде хранилището на смарт договора.

message това съобщение, което ще предадем на смарт договора от вън. И него също ще направим засега празно.

променлива съхранение 
<b b> съхранение ! 

променливо съобщение 
<b b> съобщение !

След като подготвихме константите и променливите, стартираме TVM с командата runvmctx и предаваме създадените параметри на вход.

съобщение @ 
recv_external 
код 
съхранение @ 
c7 
runvmctx

В резултат ще получим такъв междинен код на Fift.

Сега можем да стартираме получения код.

export FIFTPATH=~\/TON\/ton\/crypto\/fift\/lib // изпълняваме веднъж за удобство
~\/TON\/build\/crypto\/fift -s lottery-test-suite.fif

Програмата трябва да се изпълни без грешки и в изхода да видим лог на изпълнението:

execute SETCP 0
execute DICTPUSHCONST 19 (xC_,1)
execute DICTIGETJMPZ
execute DROP
execute implicit RET
[ 3][t 0][1582281699.325381279][vm.cpp:479] steps: 5 gas: used=304, max=9223372036854775807, limit=9223372036854775807, credit=0

Отлично, написахме първата работеща версия на смарт договора.

Сега трябва да добавим функционалност. Първо ще се занимаем със съобщенията, които идват от външния свят в recv_external()

Разработчикът сам избира формата на съобщението, което договорът може да приеме.

Но обикновено,

първо, искаме да защитим договора си от външния свят и да направим така, че само собственикът на договора да може да изпраща външни съобщения към него.
второ, когато изпращаме валидно съобщение в TON, искаме то да се случи точно веднъж и при повторно изпращане на същото съобщение смарт договорът да го отхвърли.

Затова почти във всеки договор се решават тези два проблема, тъй като нашият договор приема външни съобщения, ние също трябва да се погрижим за това.

Ще го направим в обратен ред. Първо ще решим проблема с повтарянето, ако договорът вече е получил такова съобщение и го е обработил, то няма да бъде изпълнено втори път. След това ще решим проблема с това, че само определен кръг лица може да изпраща съобщения до смарт-договора.

Има различни начини за решаване на проблема с повтарящите се съобщения. Ние ще направим следното. В смарт-договора инициализираме брояч на приетите съобщения с начало 0. На всяко съобщение към смарт-договора добавяме текущата стойност на брояча. Ако стойността на брояча в съобщението не съвпада със стойността в смарт-договора, то не го обработваме, ако съвпада, то го обработваме и увеличаваме брояча в смарт-договора с 1.

Връщаме се в lottery-test-suite.fif и добавяме втория тест. Ще изпратим неправилен номер, кодът трябва да предизвика изключение. Например, нека в данните на договора да се съхранява 166, а ние да изпратим 165.

<b 166 32 u, b> съхранение !
<b 165 32 u, b> съобщение !

съобщение @ 
recv_external 
код 
sъхранение @ 
c7 
runvmctx

drop 
exit_code ! 
."Код на изхода " exit_code @ . cr 
exit_code @ 33 - abort"Тест #2 Не е преминат"

Стартираме.

 ~\/TON\/build\/crypto\/fift -s lottery-test-suite.fif

И ще видим, че тестът се изпълнява с грешка.

[ 1][t 0][1582283084.210902214][words.cpp:3046] lottery-test-suite.fif:67: abort": Тест #2 не е преминал
[ 1][t 0][1582283084.210941076][fift-main.cpp:196]      Грешка при интерпретацията на файла `lottery-test-suite.fif`: грешка при интерпретацията на включения файл `lottery-test-suite.fif`: lottery-test-suite.fif:67: abort": Тест #2 не е преминал

На този етап lottery-test-suite.fif трябва да изглежда като на линка.

Сега да добавим логиката на брояча в смарт-договора в lottery-code.fc.

() recv_internal(slice in_msg) impure {
    ;; TODO: implementation 
}

() recv_external(slice in_msg) impure {
    if (slice_empty?(in_msg)) {
        return (); 
    }
    int msg_seqno = in_msg~load_uint(32);
    var ds = begin_parse(get_data());
    int stored_seqno = ds~load_uint(32);
    throw_unless(33, msg_seqno == stored_seqno);
}

В slice in_msg съдържа съобщението, което изпращаме.

Първото, което правим, е да проверим дали в съобщението има данни, ако няма, просто излизаме.

След това парсваме съобщението. in_msg~load_uint(32) зарежда числото 165, 32-битово unsigned int от предаденото съобщение.

След това зареждаме 32 бита от хранилището на смарт-договора. Проверяваме, че зареденото число съвпада с предаденото, ако не, хвърляме изключение. В нашия случай, тъй като подаваме несъответстващо, трябва да се хвърли изключение.

Сега ще компилираме.

~/TON/build/crypto/func -APSR -o lottery-compiled.fif ~/TON/ton/crypto/smartcont/stdlib.fc ./lottery-code.fc

Полученият код ще копираме в lottery-test-suite.fif, не забравяйки да заменим последния ред.

Проверяваме, че тестът преминава:

~\/TON\/build\/crypto\/fift -s lottery-test-suite.fif

Ето тук можете да видите съответния комит със сегашните резултати.

Забелязваме, че постоянното копиране на скомпилирания код на смарт-контракта в файл с тестове е неудобно, затова ще напишем скрипт, който ще запише кода в константа вместо нас, а ние просто ще включим скомпилирания код в нашите тестове с помощта на "include".

В папката с проекта ще създадем файл build.sh със следното съдържание.

#!/bin/bash

~/TON/build/crypto/func -SPA -R -o lottery-compiled.fif ~/TON/ton/crypto/smartcont/stdlib.fc ./lottery-code.fc

Ще го направим изпълним.

chmod +x ./build.sh

Сега, достатъчно е да стартираме нашия скрипт, за да компилираме договора. Но освен това трябва да запишем кода в константа code. Затова ще създадем нов файл lotter-compiled-for-test.fif, който ще включим във файла lottery-test-suite.fif.

Добавяме в sh скрипта код, който просто ще дублира скомпилирания файл в lotter-compiled-for-test.fif и ще промени последния ред.

# copy and change for test 
cp lottery-compiled.fif lottery-compiled-for-test.fif
sed '$d' lottery-compiled-for-test.fif > test.fif
rm lottery-compiled-for-test.fif
mv test.fif lottery-compiled-for-test.fif
echo -n "}END>s constant code" >> lottery-compiled-for-test.fif

Сега, за да проверим, ще стартираме получения скрипт и ще генерираме файл lottery-compiled-for-test.fif, който ще включим в нашия lottery-test-suite.fif

В lottery-test-suite.fif изтриваме кода на договора и добавяме реда "lottery-compiled-for-test.fif" include.

Стартираме тестовете, за да проверим, че те преминават.

~\/TON\/build\/crypto\/fift -s lottery-test-suite.fif

Отлично, сега, за да автоматизираме стартирането на тестовете, създаваме файл test.sh, който първо ще изпълни build.sh, а след това ще стартира тестовете.

touch test.sh
chmod +x test.sh

Вътре пишем

./build.sh 

echo "nКомпилацията завърши успешноn"

export FIFTPATH=~/TON/ton/crypto/fift/lib
~/TON/build/crypto/fift -s lottery-test-suite.fif

Да направим test.sh и да стартираме, за да се уверим, че тестовете работят.

chmod +x ./test.sh
./test.sh

Проверяваме, че договорът се компилира и тестовете се изпълняват.

Отлично, сега при стартиране test.sh веднага ще се извършва компилация и стартиране на тестовете. Ето линк на комит.

Окей, преди да продължим, да направим още нещо за удобство.

Създаваме папка build къде ще съхраняваме компилирания договор и неговия клон, записан в константа lottery-compiled.fif, lottery-compiled-for-test.fif. Също така създаваме папка test където ще се съхранява файлът с тестовете lottery-test-suite.fif и потенциално други помощни файлове. Линк към съответните промени.

Продължаваме разработката на смарт-контракта.

По-нататък трябва да има тест, който проверява, че съобщението се получава и броячът се обновява в хранилището, когато изпращаме правилно число. Но ще го направим по-късно.

Сега да помислим каква структура от данни и какви данни трябва да съхраняваме в смарт-контракта.

Ще опиша всичко, което съхраняваме.

`seqno` 32-битовo цяло положително число, което представлява брояча. 

`pubkey` 256-битовo цяло положително число, публичен ключ, с който ще проверяваме подписа на полученото съобщение от външната страна, за което ще говорим по-долу. 

`order_seqno` 32-битовo цяло положително число, което съхранява броя на залозите. 

`number_of_wins` 32-битовo цяло положително число, което съхранява броя на победите. 

`incoming_amount` тип данни Gram (първите 4 бита отговарят за дължината), съхранява общото количество грамовe, които бяха изпратени на контракта. 

`outgoing_amount` общото количество грамовe, което е изпратено на победителите. 

`owner_wc` номер на работния чейн, 32-битовo (в някои места е написано, че е 8-битовo) цяло число. В момента има само две -1 и 0. 

`owner_account_id` 256-битовo цяло положително число, адрес на контракта в текущия работен чейн. 

`orders` променлива от тип речник, съхранява последните двадесет залога.

Следва да напишем две функции. Първата ще наречем pack_state(), която ще пакетира данните за последващо запазване в хранилището на смарт-контракта. Втората ще наречем unpack_state() , която ще чете и връща данни от хранилището.

_ pack_state(int seqno, int pubkey, int order_seqno, int number_of_wins, int incoming_amount, int outgoing_amount, int owner_wc, int owner_account_id, cell orders) inline_ref {
    return begin_cell()
            .store_uint(seqno, 32)
            .store_uint(pubkey, 256)
            .store_uint(order_seqno, 32)
            .store_uint(number_of_wins, 32)
            .store_grams(incoming_amount)
            .store_grams(outgoing_amount)
            .store_int(owner_wc, 32)
            .store_uint(owner_account_id, 256)
            .store_dict(orders)
            .end_cell();
}

_ unpack_state() inline_ref {
    var ds = begin_parse(get_data());
    var unpacked = (ds~load_uint(32), ds~load_uint(256), ds~load_uint(32), ds~load_uint(32), ds~load_grams(), ds~load_grams(), ds~load_int(32), ds~load_uint(256), ds~load_dict());
    ds.end_parse();
    return unpacked;
}

Добавяме тези две функции в началото на смарт-контракта. Получава се такъв междинен резултат.

За да запазим данните, трябва да извикаме вградена функция set_data() , и тя ще запише данните от pack_state() в хранилището на смарт-контракта.

cell packed_state = pack_state(arg_1, .., arg_n); 
set_data(packed_state);

Сега, когато имаме удобни функции за запис и четене на данни, можем да продължим напред.

Трябва да проверим, че входящото съобщение от външната страна е подписано от собственика на контракта (или от друг потребител, който има достъп до частния ключ).

Когато публикуваме смарт-контракт, можем да го инициализираме с необходимите данни в хранилището, които ще се запазят за бъдеща употреба. Ще запишем там публичния ключ, за да можем да проверим, че подписът на входящото съобщение е направен с отговарящия приватен ключ.

Преди да продължим, да създадем приватен ключ и да го запишем в test/keys/owner.pk. За това ще стартираме Fift в интерактивен режим и ще изпълним четири команди.

`newkeypair` генерира публичен и приватен ключ и ги записва в стека. 

`drop` премахва от стека най-горния елемент (в този случай публичния ключ)  

`.s` просто показва какво има в стека в момента 

`"owner.pk" B>file` записва приватния ключ във файл с име `owner.pk`. 

`bye` завършва работата с Fift.

Създаваме папка ключове във папката test и там ще запишем приватния ключ.

mkdir test/keys
cd test/keys
~ /TON/build/crypto/fift -i 
newkeypair
 ok
.s 
BYTES:128DB222CEB6CF5722021C3F21D4DF391CE6D5F70C874097E28D06FCE9FD6917 BYTES:DD0A81AAF5C07AAAA0C7772BB274E494E93BB0123AA1B29ECE7D42AE45184128 
drop 
 ok
"owner.pk" B>file
 ok
bye

Виждаме в текущата папка файла owner.pk.

Премахваме публичния ключ от стека, когато ни потрябва, можем да го получим от приватния.

Сега трябва да напишем проверка на подписа. Нека започнем с тест. Първо прочитаме приватния ключ от файла с помощта на функцията file>B и го записваме в променливата owner_private_key, след това с помощта на функцията priv>pub конвертираме приватния ключ в публичен и записваме резултата в owner_public_key.

variable owner_private_key
variable owner_public_key 

"./keys/owner.pk" file>B owner_private_key !
owner_private_key @ priv>pub owner_public_key !

И двата ключа ще ни трябват.

Инициализиране на произволни данни в хранилището на смарт-контракта в същата последователност, каквато е в функцията pack_state()и записваме в променливата хранилище.

променлива owner_private_key
променлива owner_public_key 
променлива orders
променлива owner_wc
променлива owner_account_id

".\/keys\/owner.pk" файл&gt;B owner_private_key !
owner_private_key @ priv&gt;pub owner_public_key !
dictnew orders !
0 owner_wc !
0 owner_account_id !

<b 0 32 u, owner_public_key @ b, gram, owner_wc i, owner_account_id 256 orders dict, b> съхранение !

След това ще съставим подписано съобщение, в което ще има само подпис и стойността на брояча.

Първо създаваме данните, които искаме да предадем, след това подписваме с приватния ключ и накрая формулираме подписаното съобщение.

променлива message_to_sign
променлива message_to_send
променлива signature
<b 0 32 u, b> message_to_sign !
message_to_sign @ hashu owner_private_key @ ed25519_sign_uint signature !
<b signature @ b, 0 32 u, b> &lt;s !

В крайна сметка съобщението, което ще изпратим в смарт-контракта, е записано в променливата message_to_send, относно функциите hashu, ed25519_sign_uint можете да прочетете в документацията за Fift.

И за да стартираме теста отново извикваме.

message_to_send @ 
recv_external 
code 
storage @
c7
runvmctx

Така трябва да изглежда файлът с тестовете на този етап.

Нека стартираме теста и той ще падне, затова ще променим смарт-контракта, за да може да получава съобщения от такъв формат и да проверява подписа.

Първо ще прочетем 512 бита от подписа от съобщението и ще ги запишем в променлива, след което ще прочетем 32 бита от променливата на брояча.

Тъй като имаме функция за извличане на данни от хранилището на смарт контракта, ще я използваме.

Следва проверка на брояча, подаден от хранилището, и проверка на подписа. Ако нещо не съвпадне, ще хвърлим изключение с подходящия код.

var signature = in_msg~load_bits(512);
var message = in_msg;
int msg_seqno = message~load_uint(32);
(int stored_seqno, int pubkey, int order_seqno, int number_of_wins, int incoming_amount, int outgoing_amount, int owner_wc, int owner_account_id, cell orders) = unpack_state();
throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, check_signature(slice_hash(in_msg), signature, pubkey));

Съответстващ комит са тук.

Ще стартираме тестовете и ще видим, че вторият тест пада. По две причини: недостиг на битове в съобщението и недостиг на битове в хранилището, затова кодът пада при парсинга. Трябва да добавим подписа на съобщението, което изпращаме, и да копираме хранилището от последния тест.

Във втория тест ще добавим подписа на съобщението и ще променим хранилището на смарт контракта. Така в момента файлът с тестовете изглежда така.

Нека напишем четвърти тест, в който ще изпратим съобщение, подписано с чужд частен ключ. Ще създадем още един частен ключ и ще го запишем в файл not-owner.pk. С този частен ключ ще подпишем съобщението. Ще стартираме тестовете и ще се уверим, че всички тестове преминават. Комит в момента.

Сега накрая можем да преминем към реализиране на логиката на смарт контракта.
В recv_external() Ще приемаме два типа съобщения.

Тъй като нашият контракт ще акумулира загуби на играчите, тези пари трябва да бъдат превеждани на създателя на лотарията. Адресът на портфейла на създателя на лотарията се записва в хранилището при създаването на контракта.

За всеки случай имаме нужда от възможността да променяме адреса, на който да изпращаме грамовете на загубилите. Също така трябва да имаме възможност да изпращаме грамове от лотарията на адреса на собственика.

Да започнем с първото. Първо ще напишем тест, който ще проверява, че след изпращане на съобщение смарт контрактът е запазил новия адрес в хранилището. Обърнете внимание, че в съобщението освен брояча и новия адрес, ние предаваме още action 7-битово неотрицателно цяло число, в зависимост от него, ще изберем как да обработим съобщението в смарт контракта.

<b 0 32 u, 1 @ 7 new_owner_wc i, new_owner_account_id 256 b> съобщение_за_подпис !

В теста можете да видите как се извършва десериализация на хранилището на смарт контракта хранилище В Fift. Десериализация променливите е описана в документацията на Fift.

Връзка към комита с добавянето на тест.

Стартираме теста и се уверяваме, че той пада. Сега ще добавим логика за промяна на адреса на собственика на лотарията.

В смарт контракта продължаваме да парсираме message, четем в action. Да припомним, че ще имаме два action: промяна на адреса и изпращане на грами.

След това четем новия адрес на собственика на контракта и го запазваме в хранилището.
Стартираме тестовете и виждаме, че третият тест пада. Пада заради факта, че контрактът сега допълнително парсира 7 бита от съобщението, които не достигат в теста. Ще добавим в съобщението несъществуващ action. Стартираме тестовете и виждаме, че всички минават. Тук комит за промените. Отлично.

Сега ще напишем логика за изпращане на указаното количество грами на запазения по-рано адрес.

Първо ще напишем тест. Ще напишем два теста - един, когато балансът не е достатъчен, и втори, когато всичко трябва да мине успешно. Тестовете могат да се видят в този комит.

Сега ще допишем кода. Първо ще напишем два помощни метода. Първият е get метод за да разберем текущия баланс на смарт контракта.

int balance() inline_ref method_id {
    return get_balance().pair_first();
}

И вторият за изпращане на грами на друг смарт контракт. Този метод изцяло копирах от друг смарт контракт.

() send_grams(int wc, int addr, int grams) impure {
    ;; int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool src:MsgAddress -> 011000
    cell msg = begin_cell()
    ;;  .store_uint(0, 1) ;; 0 <= формат индикатор int_msg_info$0 
    ;;  .store_uint(1, 1) ;; 1 <= ihr деактивиран
    ;;  .store_uint(1, 1) ;; 1 <= bounce = вярно
    ;;  .store_uint(0, 1) ;; 0 <= bounced = невярно
    ;;  .store_uint(4, 5)  ;; 00100 <= адресни флагове, anycast = невярно, 8-битов работен клон
        .store_uint (196, 9)
        .store_int(wc, 8)
        .store_uint(addr, 256)
        .store_grams(grams)
        .store_uint(0, 107); ;; 106 нули +  0 като индикатор, че няма клетка с данни.
        .end_cell(); 
    send_raw_message(msg, 3); ;; режим, 2 за игнориране на грешките, 1 за платец на таксите, 64 за връщане на стойността на входящото съобщение
}

Добавяме тези два метода в смарт контракта и пишем логика. Първо парсираме количеството грами от съобщението. След това проверяваме баланса, ако не достига, хвърляме изключение. Ако всичко е наред, тогава изпращаме грами на запазения адрес и актуализираме брояча.

int amount_to_send = message~load_grams();
throw_if(36, amount_to_send + 500000000 > balance());
accept_message();
send_grams(owner_wc, owner_account_id, amount_to_send);
set_data(pack_state(stored_seqno + 1, pubkey, order_seqno, number_of_wins, incoming_amount, outgoing_amount, owner_wc, owner_account_id, orders));

Така изглежда смарт контрактът в момента. Ще стартираме тестовете и ще се уверим, че те минават.

Между прочим, за каждое обработанное сообщение смарт-контракту взимается комиссия. Чтобы смарт-контракт выполнил запрос на сообщение, после базовых проверок нужно вызвать accept_message().

Теперь перейдём к внутренним сообщениям. На самом деле, мы будем просто принимать грамы и отправлять игроку обратно двойную сумму при выигрыше, и треть владельцу при проигрыше.

Сначала напишем простой тест. Для этого нам потребуется тестовый адрес смарт-контракта, с которого мы будем отправлять грамы на смарт-контракт.

Адрес смарт-контракта состоит из двух чисел: 32-битное целое число отвечает за workchain и 256-битное неотрицательное уникальный номер аккаунта в этом workchain. Например, -1 и 12345, этот адрес мы и сохраним в файл.

Я скопировал функцию сохранения адреса из TonUtil.fif.

// ( wc addr fname -- )  Save address to file in 36-byte format
{ -rot 256 u>B swap 32 i>B B+ swap B>file } : save-address

Давайте разберёмся, как работает функция, это поможет понять, как работает Fift. Запускаем Fift в интерактивном режиме.

~\/TON\/build\/crypto\/fift -i

Сначала мы помещаем в стек -1, 12345 и название будущего файла "sender.addr":

-1 12345 "sender.addr"

Следующим шагом выполняется функция -rot, которая сдвигает стек так, что на вершине оказывается уникальный номер смарт-контракта:

"sender.addr" -1 12345

256 u>B конвертирует 256-битное неотрицательное целое в байты.

"sender.addr" -1 BYTES:0000000000000000000000000000000000000000000000000000000000003039

swap меняет местами два верхних элемента стека.

"sender.addr" BYTES:0000000000000000000000000000000000000000000000000000000000003039 -1

32 i>B конвертирует 32-битное целое в байты.

"sender.addr" BYTES:0000000000000000000000000000000000000000000000000000000000003039 BYTES:FFFFFFFF

B+ соединяет две последовательности байтов.

 "sender.addr" BYTES:0000000000000000000000000000000000000000000000000000000000003039FFFFFFFF

Снова swap.

BYTES:0000000000000000000000000000000000000000000000000000000000003039FFFFFFFF "sender.addr"

И наконец выполняется запись байтов в файл B>file. После этого наш стек пуст. Останавливаем Fift. В текущей папке создан файл sender.addr. Переносим файл в созданную папку test\/addresses\/.

Напишем простой тест, который будет отправлять грамы на смарт-контракт. Вот коммит.

Теперь займёмся логикой лотереи.

Первое, что мы делаем, проверяем сообщение bounced или нет, если bounced, то игнорируем. bounced это значит, что контракт вернёт грамы, если произойдёт какая-то ошибка. Мы не будем возвращать грамы, если возникнет ошибка.

Проверяем баланс: если он меньше чем полграмма, то просто принимаем сообщение и игнорируем.

Следва да парснем адреса на смартконтракта, от който е получено съобщението.

Четем данни от хранилището и след това изтриваме старите залози от историята, ако са повече от двадесет. За удобство написах три допълнителни функции. pack_order(), unpack_order(), remove_old_orders().

След това проверяваме дали балансът е недостатъчен за изплащане, в такъв случай сметката се счита за не залог, а за попълване и запазваме попълването в orders.

След това, важното е съществото на смартконтракта.

Първо, ако играчът загуби, запазваме го в историята на залозите, и ако сумата е над 3 грама, изпращаме 1/3 на собственика на смартконтракта.

Ако играчът спечели, изпращаме удвоената сума на адреса на играча и след това запазваме информацията за залога в историята.

() recv_internal(int order_amount, cell in_msg_cell, slice in_msg) impure {
    var cs = in_msg_cell.begin_parse();
    int flags = cs~load_uint(4);  ;; int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool
    if (flags & 1) { ;; игнорирай бонсирането
        return ();
    }
    if (order_amount < 500000000) { ;; просто получаваме грамове без да променяме състоянието
        return ();
    }
    slice src_addr_slice = cs~load_msg_addr();
    (int src_wc, int src_addr) = parse_std_addr(src_addr_slice);
    (int stored_seqno, int pubkey, int order_seqno, int number_of_wins, int incoming_amount, int outgoing_amount, int owner_wc, int owner_account_id, cell orders) = unpack_state();
    orders = remove_old_orders(orders, order_seqno);
    if (balance() = 4) {
        builder order = pack_order(order_seqno, 3, now(), order_amount, src_wc, src_addr);
        orders~udict_set_builder(32, order_seqno, order);
        set_data(pack_state(stored_seqno, pubkey, order_seqno + 1, number_of_wins, incoming_amount + order_amount, outgoing_amount, owner_wc, owner_account_id, orders));
        if (order_amount > 3000000000) {
            send_grams(owner_wc, owner_account_id, order_amount / 3);
        }
        return ();
    }
    send_grams(src_wc, src_addr, 2 * order_amount);
    builder order = pack_order(order_seqno, 2, now(), order_amount, src_wc, src_addr);
    orders~udict_set_builder(32, order_seqno, order);
    set_data(pack_state(stored_seqno, pubkey, order_seqno + 1, number_of_wins + 1, incoming_amount, outgoing_amount + 2 * order_amount, owner_wc, owner_account_id, orders));
}

И това е всичко. Съответният комит.

Сега остава само да направим GET методи, за да можем отвън да получим информация за състоянието на контракта (по същество да извличаме данни от хранилището на смартконтракта).

Добавим GET методи. За това как да получаваме информация за смартконтракта ще напишем по-долу.

Също така забравих да добавя код, който ще обработва първоначалната заявка, която се извършва при публикуване на смарт-контракт. Съответният комит. И още поправих бъг с изпращането на 1/3 от сумата на акаунта на собственика.

След това остава да публикуваме смарт-контракта. Нека създадем папка requests.

В основата си взех кода за публикуване simple-wallet-code.fc който може да бъде намерен в официалното хранилище.

От това, на което си заслужава да се обърне внимание. Ние формираме хранилище на смарт-контракта и входящото съобщение. След това се генерира адрес на смарт-контракта, т.е. адресът е известен още преди публикуването в TON. След това на този адрес трябва да се изпратят няколко грама и само след това трябва да се изпрати файлът със самия смарт-контракт, тъй като мрежата таксува за съхранението на смарт-контракта и операциите в него (валидатори, които съхраняват и изпълняват смарт-контракти). Кодът може да се види тук.

След това изпълняваме кода за публикуване и получаваме lottery-query.boc файла и адреса на смарт-контракта.

~\/TON\/build\/crypto\/fift -s requests\/new-lottery.fif 0

Не забравяйте да запазите генерираните файлове: lottery-query.boc, lottery.addr, lottery.pk.

Сред другото, в логовете на изпълнението ще видим адреса на смарт-контракта.

new wallet address = 0:044910149dbeaf8eadbb2b28722e7d6a2dc6e264ec2f1d9bebd6fb209079bc2a 
(Записване на адреса в файл lottery.addr)
Non-bounceable address (for init): 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd
Bounceable address (for later access): kQAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8KpFY

За интерес ще направим заявка в TON

$ .\/lite-client\/lite-client -C ton-lite-client-test1.config.json 
getaccount 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd

И ще видим, че акаунтът с такъв адрес е празен.

account state is empty

Изпращаме на адрес 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd 2 Gram и след няколко секунди изпълняваме същата команда. За изпращане на грами използвам официалния портфейл, а тестови грами може да поискате от някого от чата, за който ще спомена в края на статията.

> getaccount 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd

Проверява, че в мрежата се е появил неинициализиран (state:account_uninit) смарт-контракт с такъв адрес и баланс 1 000 000 000 нанограма.

състоянието на сметката е (сметка
  адрес:(addr_std
    anycast:няма workchain_id:0 адрес:x044910149DBEAF8EADBB2B28722E7D6A2DC6E264EC2F1D9BEBD6FB209079BC2A)
  storage_stat:(storage_info
    used:(storage_used
      клетки:(var_uint len:1 стойност:1)
      битове:(var_uint len:1 стойност:103)
      публични клетки:(var_uint len:0 стойност:0)) последно платено:1583257959
    дължимо плащане:няма)
  storage:(account_storage last_trans_lt:3825478000002
    баланс:(валути
      грамове:(нанограм
        количество:(var_uint len:4 стойност:2000000000))
      други:(допълнителни валути
        dict:hme_empty))
    състояние:account_uninit))
x{C00044910149DBEAF8EADBB2B28722E7D6A2DC6E264EC2F1D9BEBD6FB209079BC2A20259C2F2F4CB3800000DEAC10776091DCD650004_}
последна транзакция lt = 3825478000001 хаш = B043616AE016682699477FFF01E6E903878CDFD6846042BA1BFC64775E7AC6C4
балансът на сметката е 2000000000ng

Сега ще публикуваме смарт-контракта. Ще стартираме lite-client и ще изпълним.

> изпрати файл lottery-query.boc
[ 1][t 2][1583008371.631410122][lite-client.cpp:966][!testnode] изпращане на запитване от файл lottery-query.boc
[ 3][t 1][1583008371.828550100][lite-client.cpp:976][!query] статусът на външното съобщение е 1

Нека проверим дали контрактът е публикуван.

> последно
> getaccount 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd

Сред другото ще получим.

  storage:(account_storage last_trans_lt:3825499000002
    баланс:(валути
      грамове:(нанограм
        количество:(var_uint len:4 стойност:1987150999))
      други:(допълнителни валути
        dict:hme_empty))
    състояние:(account_active

Виждаме, че account_active.

Съответният комит с промените са тук.

Сега ще създадем заявки за взаимодействие със смарт-контракта.

По точно първата за промяна на адреса ще я оставим за самостоятелна работа, а втората за изпращане на грамове на адреса на притежателя ще я направим. Всъщност трябва да направим същото, което и в теста за изпращане на грамове.

Такова съобщение ще изпратим на смартконтракта, където msg_seqno 165, action 2 и 9.5 грама за изпращане.

<b 165 32 u, 2 7 9500000000 gram, b>

Не забравяйте да подпишете съобщението с частния ключ lottery.pk, който беше генериран по-рано при създаването на смарт-контракта. Ето съответният комит.

Получаваме информация от смарт-контракта с помощта на get-методи

Сега ще разгледаме как да стартираме get-методите на смартконтракта.

Стартираме lite-client и стартираме get-методите, които написахме.

$ .\/lite-client\/lite-client -C ton-lite-client-test1.config.json
> runmethod 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd баланс
аргументи:  [ 104128 ] 
резултат:  [ 64633878952 ] 
...

В резултат съдържа стойността, която функцията баланс() върнува от нашия смарт-контракт.
Същото ще изпълним още за няколко метода.

> runmethod 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd get_seqno
...
аргументи:  [ 77871 ] 
резултат:  [ 1 ]

Ще поискаме история на залозите.

> runmethod 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd get_orders
...
arguments:  [ 67442 ] 
result:  [ ([0 1 1583258284 10000000000 0 74649920601963823558742197308127565167945016780694342660493511643532213172308] [1 3 1583258347 4000000000 0 74649920601963823558742197308127565167945016780694342660493511643532213172308] [2 1 1583259901 50000000000 0 74649920601963823558742197308127565167945016780694342660493511643532213172308]) ]

Ще използваме lite-client и методи за извличане, за да покажем информация за смарт-контракта на сайта.

Показваме данни от смарт-контракта на сайта

Написах прост уебсайт на Python, за да показвам данни от смарт-контракта в удобен формат. Тук няма да задълбавам и просто ще публикувам сайта. с един комит.

Запитванията към TON се правят от Python чрез lite-client. За удобство, сайтът е пакетирани в Docker и публикуван в Google Cloud. Връзка към сайта.

Опитваме

Сега ще опитаме да изпратим грамове за зареждане от портфейла. Ще изпратим 40 грама и ще направим няколко залога за визуализация. Виждаме, че сайтът показва история на залозите, текущия процент на печалба и друга полезна информация.

Виждаме, че първият залог спечелихме, а вторият загубихме.

Следсловие

Статията стана много по-дълга, отколкото предполагах, може би можеше да е и по-кратка, а може би е точно за човек, който нищо не знае за TON и иска да напише и публикува не толкова прост смарт-контракт с възможност за взаимодействие. Може би някои неща можеха да бъдат обяснени по-просто.

Може би някои аспекти на реализацията можеха да бъдат направени по-ефективно и елегантно, но иначе щеше да отнеме още повече време за подготовка на статията. Също така е възможно да съм направил грешка или нещо да не съм разбрал, затова ако правите нещо сериозно, трябва да се опирате на официалната документация или на официалното хранилище с код на TON.

Трябва да отбележа, че тъй като самият TON все още е в активна разработка, могат да настъпят промени, които да счупят някой от стъпките в тази статия (както се случи, докато пишех, вече поправих), но основният подход едва ли ще се промени.

Не искам да спекулирам относно бъдещето на TON. Може би платформата ще стане нещо повече и ние трябва да отделим време за нейното проучване и да заемем ниша с нашите продукти още сега.

Има и Libra от Facebook, чиято потенциална аудитория е по-голяма от тази на TON. Почти нищо не знам за Libra, но според форума, активността там е значително по-висока от тази в общността на TON. Въпреки това, разработчиците и общността на TON изглеждат повече като андерграунд, което също е готино.

Връзки

Официална документация за TON: https://test.ton.org
Официален репозиторий на TON: https://github.com/ton-blockchain/ton
Официален портфейл за различни платформи: https://wallet.ton.org
Репозиторий на смарт-контракта от тази статия: https://github.com/raiym/astonished
Връзка към сайта на смарт-контракта: https://ton-lottery.appspot.com
Репозиторий за разширение за Visual Studio Code за FunC: https://github.com/raiym/func-visual-studio-plugin
Чат за TON в Telegram, който много помогна да разбера основите. Мисля, че не греша, ако кажа, че там са всички, които са писали нещо за TON. Може също да поискаш тестови грамове. https://t.me/tondev_ru
Още един чат за TON, в който намерих полезна информация: https://t.me/TONgramDev
Първи етап на конкурса: https://contest.com/blockchain
Втори етап на конкурса: https://contest.com/blockchain-2