Как да напишем и публикуваме смарт-контракт в 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] server version is 1.1, capabilities 7
[ 3][t 2][1582054823.085725069][lite-client.cpp:286][!testnode] server time is 1582054823 (delta 0)
...

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

help

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

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

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

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

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

runmethod  [<block-id-ext>]    стартира 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 tuple 0x076ef1ea , \/\/ magic
0 , 0 , \/\/ actions msg_sents
1570998536 , \/\/ unix_time
1 , 1 , 3 , \/\/ block_lt, trans_lt, rand_seed
0 tuple 100000000000000 , dictnew , , \/\/ remaining balance
0 , dictnew , \/\/ contract_address, global_config
1 tuple \/\/ wrap to another tuple
constant c7

0 constant recv_internal \/\/ да се изпълни recv_internal() 
-1 constant recv_external \/\/ за да се извика recv_external()

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

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

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

Нека създадем променлива storage и да запишем в нея пуст cell, това ще бъде хранилище на смарт-контракта.

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

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

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

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

message @ 
recv_external 
code 
storage @ 
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]     стъпки: 5 газ: използвани=304, макс=9223372036854775807, лимит=9223372036854775807, кредит=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: реализация 
}

() 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-бито цяло положително число - публичен ключ, с който ще проверим подписа на входящото съобщение, за което по-долу. 

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

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

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

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

`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. 

Ще създадем папка keys вътре в папката 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()и записваме в променливата storage.

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

".\/keys\/owner.pk" файл>B owner_private_key !
owner_private_key @ priv>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> съхранение !

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

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

променливо съобщение_за_подписване
променливо съобщение_за_изпращане
променливо подпис
<b 0 32 u, b> съобщение_за_подписване !
съобщение_за_подписване @ хаш собственик_на_частен_ключ @ ed25519_sign_uint подпис !
<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() ще приемаме два типа съобщения.

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

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

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

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

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

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

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

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

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

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

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

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

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 <= пружина = вярно
    ;;  .store_uint(0, 1) ;; 0 <= пружината = невярно
    ;;  .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, която измествa стека, така че на върха на стека се оказва уникалният номер на смарт-контракта:

"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));
}

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

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

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

Също така забравих да добавя код, който ще обработва първоначалната заявка, която се изпраща при публикуването на смарт-контракта. Съответстващият комит. И още коригирах бъг с изпращането на 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)
Необратим адрес (за инициализация): 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd
Обратим адрес (за по-късен достъп): kQAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8KpFY

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

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

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

състоянието на акаунта е празно

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

> getaccount 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd

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

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

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

> sendfile 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 

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

> last
> getaccount 0QAESRAUnb6vjq27KyhyLn1qLcbiZOwvHZvr1vsgkHm8Ksyd

Сред другите неща, получаваме.

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

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

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

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

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

Такова съобщение ще изпратим на смартконтракта, където msg_seqno 165, действие 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 balance
аргументи:  [ 104128 ] 
резултат:  [ 64633878952 ] 
...

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

> 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 и GET методи, за да извлечем информация за смарт договора на сайта.

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

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

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

Опитваме

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

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

Следсловие

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

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

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

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

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

Връзки

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

Източник: habr.com