Превръщане на FunC във FunCtional с Haskell: Как Serokell спечели състезанието за блокчейн на Telegram

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

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

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

Конкуренция и нейните условия

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

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

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

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

Накратко, защото нашата специализация са нестандартни и сложни проекти, които изискват специални умения и често имат научна стойност за ИТ общността. Ние силно подкрепяме разработката с отворен код и се занимаваме с нейното популяризиране, а също така си сътрудничим с водещи руски университети в областта на компютърните науки и математиката.

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

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

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

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

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

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

Nix: сглобяване на проекта

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

Така че започнахме със създаването Nix наслагване с израз за асемблиране на 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 работи на виртуалната машина TON (TVM). TVM е по-сложен от повечето други виртуални машини и има много интересна функционалност, с която например може да работи продължения и връзки към данни.

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

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

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

Пети асемблер — Библиотека на Fift за генериране на двоичен изпълним код за TVM. Fifth Assembler няма компилатор. Това Вграден специфичен за домейн език (eDSL).

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

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

Асинхронен канал за плащане

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

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

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

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

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

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

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

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

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

TVM Haskell eDSL

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

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

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

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

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

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

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