Превръщайки FunC в FunCtional с помощта на Haskell: как Serokell спечелиха в Telegram Blockchain Competition

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

Екипът на Serokell с богат опит в разработката на големи блокчейн проекти не можеше да остане безучастен. Делегирахме петима служители на конкурса и вече след две седмици те заеха първото място под (не)скромния рандомно избран ник Sexy Chameleon. В тази статия ще ви разкажа как успяха. Надяваме се, че през следващите десет минути ще прочетете интересна история, а като най-добър случай ще намерите нещо полезно, което можете да приложите в работата си.

Но нека започнем с малко потапяне в контекста.

Конкурсът и неговите условия

И така, основните задачи на участниците бяха реализирането на един или повече от предложените смарт контракти, както и внесенето на предложения за подобряване на екосистемата TON. Конкурсът се провеждаше от 24 септември до 15 октомври, а резултатите бяха обявени едва на 15 ноември. Доста дълго, предвид че през това време Telegram успя да проведе и обяви резултатите от конкурси за дизайн и разработка на приложения на C++ за тестване и оценка на качеството на VoIP обажданията в Telegram.

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

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

Защо изобщо решихме да участваме

Накратко, защото нашата специализация са нестандартни и сложни проекти, изискващи особени умения и често представляващи научна стойност за IT общността. Горещо подкрепяме open-source разработката и се занимаваме с нейното популяризиране, а също така сътрудничим с водещи университети в Русия в областта на компютърните науки и математиката.

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

Изследване на блокчейна TON

Ние внимателно следим новите разработки в блокчейна, изкуствения интелект и машинното обучение и се стараем да не пропускаме нито един значителен релиз в сферите, в които работим. Затова, когато конкурса стартира, нашият екип вече познаваше идеите от TON white paper. Обаче преди да започнем работа с TON, не анализирахме техническата документация и фактическия изходен код на платформата, така че първата стъпка стана изключително ясна — старателно проучване на официалната документация на сайта и в репозитория на проекта.

Към началото на конкурса кодът вече беше публикуван, затова, за да спестим време, решихме да потърсим ръководство или резюме, написано от потребители. За съжаление, това не доведе до резултати — освен инструкциите за настройка на платформата на Ubuntu, не намерихме други материали.

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

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

Nix: създаваме проект

В Serokell много харесваме Nix. Събираме нашите проекти и ги разгръщаме с помощта на NixOps, а на сървърите ни е инсталиран NixOS. Благодарение на това, всички наши билдове са възпроизвеждаеми и работят на всяка операционна система, на която може да бъде инсталиран Nix.

Затова започнахме с изграждането на Nix overlay с израз за компилиране на TON. С негова помощ компилирането на TON е максимално просто:

$ cd ~/.config/nixpkgs/overlays && git clone https://github.com/serokell/ton.nix
$ cd /path/to/ton/repo && nix-shell
[nix-shell]$ cmakeConfigurePhase && make

Обърнете внимание, че не трябва да инсталирате никакви зависимости. Nix магически ще свърши всичко вместо вас, независимо дали използвате NixOS, Ubuntu или macOS.

Програмиране за TON

Кодът на смарт-контрактите в TON Network се изпълнява на TON Virtual Machine (TVM). TVM е по-сложен от повечето други виртуални машини и предлага интересен набор от функции, като например може да работи с продълженията (continuations) и ссылките на данни.

Освен това, екипът от TON е създал три нови програмни езика:

Fift — универсален стеков език за програмиране, наподобяващ Forth. Неговата суперспособност е възможността да взаимодейства с TVM.

FunC — език за програмиране на смарт контракти, който е подобен на C и се компилира в друг език — Fift Assembler.

Fift Assembler — библиотека Fift за генериране на двоичен изпълним код за TVM. Fift Assembler няма компилатор. Това е вграден предметно-ориентиран език (eDSL).

Нашите конкурсни работи

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

Асинхронен платежен канал

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

Намерихме доста просто решение на проблема. Двете страни могат да обменят подписани съобщения, всяко от които съдържа две числа — общата сума, платена от всеки от участниците. Тези две числа функционират като векторни часовници в традиционните разпределени системи и задават реда на „събитията преди“ в транзакциите. Използвайки тези данни, контрактът ще може да разреши всякакви възможни конфликти.

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

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

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

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

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

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

Следователно единственото, по наше мнение, оправдание за съществуването на Fift е, че служи като хост-език за Fift Assembler. Но не би ли било по-добре да вградим TVM асемблер в някой съществуващ език, отколкото да измисляме нов за тази, по същество единствена, цел?

TVM Haskell eDSL

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

Както и Fift Assembler, нашият нов език е вградим, само че като хост вместо Fift избрахме Haskell, което ни позволи да използваме напълно неговата усъвършенствана система от типове. При работа със смарт-контракти, където цената на дори и най-малката грешка може да бъде много висока, статичната типизация, по наше мнение, е голямо предимство.

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

• Този контракт съдържа една функция, но можете да използвате толкова, колкото желаете. Когато определите нова функция на езика хост (тоест на Haskell), нашето eDSL ви позволява да изберете дали искате тя да се превърне в отделна подпрограма в TVM или просто да бъде интегрирана в мястото на извикването.
• Както в Haskell, функциите имат типове, които се проверяват по време на компилация. В нашето eDSL типът на входа на функцията е типът на стека, който функцията очаква, а типът на резултата е типът на стека, който ще се получи след извикването.
• В кода има анотации stacktype, описващи очаквания тип стек в точката на извикване. В оригиналния контракт на портфейла те бяха просто коментари, но в нашето eDSL те всъщност са част от кода и се проверяват по време на компилацията. Те могат да служат за документация или твърдения, които помагат на разработчика да открие проблем, в случай че при промяна на кода типът на стека се промени. Разбира се, такива анотации нямат влияние върху производителността по време на изпълнение, тъй като за тях не се генерира код за TVM.
• Това все още е прототип, написан за две седмици, така че по проекта има още много работа. Например, всички инстанции на класовете, които виждате в предоставения по-долу код, трябва да се генерират автоматично.

Ето как изглежда реализацията на multisig-портфейл на нашето eDSL:

main :: IO ()
main = putText $ pretty $ declProgram procedures methods
  where
    procedures =
      [ ("recv_external", decl recvExternal)
      , ("recv_internal", decl recvInternal)
      ]
    methods =
      [ ("seqno", declMethod getSeqno)
      ]

data Storage = Storage
  { sCnt :: Word32
  , sPubKey :: PublicKey
  }

instance DecodeSlice Storage where
  type DecodeSliceFields Storage = [PublicKey, Word32]
  decodeFromSliceImpl = do
    decodeFromSliceImpl @Word32
    decodeFromSliceImpl @PublicKey

instance EncodeBuilder Storage where
  encodeToBuilder = do
    encodeToBuilder @Word32
    encodeToBuilder @PublicKey

data WalletError
  = SeqNoMismatch
  | SignatureMismatch
  deriving (Eq, Ord, Show, Generic)

instance Exception WalletError

instance Enum WalletError where
  toEnum 33 = SeqNoMismatch
  toEnum 34 = SignatureMismatch
  toEnum _ = error "Uknown MultiSigError id"

  fromEnum SeqNoMismatch = 33
  fromEnum SignatureMismatch = 34

recvInternal :: '[Slice] :-> '[]
recvInternal = drop

recvExternal :: '[Slice] :-> '[]
recvExternal = do
  decodeFromSlice @Signature
  dup
  preloadFromSlice @Word32
  stacktype @[Word32, Slice, Signature]
  -- cnt cs sign

  pushRoot
  decodeFromCell @Storage
  stacktype @[PublicKey, Word32, Word32, Slice, Signature]
  -- pk cnt' cnt cs sign

  xcpu @1 @2
  stacktype @[Word32, Word32, PublicKey, Word32, Slice, Signature]
  -- cnt cnt' pk cnt cs sign

  equalInt >> throwIfNot SeqNoMismatch

  push @2
  sliceHash
  stacktype @[Hash Slice, PublicKey, Word32, Slice, Signature]
  -- hash pk cnt cs sign

  xc2pu @0 @4 @4
  stacktype @[PublicKey, Signature, Hash Slice, Word32, Slice, PublicKey]
  -- pubk sign hash cnt cs pubk

  chkSignU
  stacktype @[Bool, Word32, Slice, PublicKey]
  -- ? cnt cs pubk

  throwIfNot SignatureMismatch
  accept

  swap
  decodeFromSlice @Word32
  nip

  dup
  srefs @Word8

  pushInt 0
  if IsEq
  then ignore
  else do
    decodeFromSlice @Word8
    decodeFromSlice @(Cell MessageObject)
    stacktype @[Slice, Cell MessageObject, Word8, Word32, PublicKey]
    xchg @2
    sendRawMsg
    stacktype @[Slice, Word32, PublicKey]

  endS
  inc

  encodeToCell @Storage
  popRoot

getSeqno :: '[] :-> '[Word32]
getSeqno = do
  pushRoot
  cToS
  preloadFromSlice @Word32

Пълният изходен код на нашия eDSL и контракта на портфейла с мултиподпис можете да намерите в този репозитории. А по-подробно разказа за вградени езици нашият колега Георгий Агапов. Изводите от конкурса и TON

В сумата нашата работа отне 380 часа (включително запознаването с документацията, срещите и непосредствената разработка). В конкурсния проект участваха петима разработчици: CTO, тим-лидер, специалисти по блокчейн платформи и разработчици на софтуер на Haskell.

В сумме наша работа заняла 380 часов (вместе со знакомством с документацией, совещаниями и непосредственно разработкой). В конкурсном проекте приняли участие пять разработчиков: СТО, тим-лид, специалисты по блокчейн-платформам и разработчики программного обеспечения на Haskell.

Ресурсите за участие в конкурса намерихме без трудности, тъй като духът на хакатона, здравото teamwork, необходимостта от бързо потапяне в аспектите на новите технологии — винаги е вълнуващо. Няколко безсънни нощи, за да постигнем максимален резултат в условия на ограничени ресурси, се компенсират с безценен опит и отлични спомени. Освен това, работата по подобни задачи е винаги добра проверка на процесите в компанията, тъй като е изключително трудно да се постигнат наистина достойни резултати без отлично настроено вътрешно взаимодействие.

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

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

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