Muutes FunC FunCtionaliks Haskelliga: kuidas Serokell võitis Telegrami Blockchaini konkurssi

Te olete kindlasti kuulnud, et Telegram kavatseb käivitada plokiahela platvormi Ton. Kuid te võisite jääda ilma uudisest, et mitte nii kaua tagasi Telegram kuulutas välja konkursi ühe või mitme nutilepingute elluviimiseks sellel platvormil.

Serokelli meeskond, kellel on ulatuslik kogemus suurte plokiahela projektide arendamisel, ei saanud kõrvale jääda. Me delegaatsime konkursile viis töötajat, ja juba kahe nädala pärast saavutasid nad seal esikoha (mitte)vaikselt tegutseva kasutajanimega Sexy Chameleon. Selles artiklis räägin, kuidas nad selle saavutada suutsid. Loodame, et järgmise kümne minuti jooksul loete vähemalt huvitava loo, ja ehk leiate selles midagi kasulikku, mida oma töös kasutada.

Aga alustame väikese konteksti tõlgendamisega.

Konkursi tingimused

Nii et osalejate peamised ülesanded olid ühe või mitme pakutud nutilepingu elluviimine ning ettepanekute tegemine TONi ökosüsteemi täiustamiseks. Konkurs kestis 24. septembrist kuni 15. oktoobrini, kuid tulemused kuulutati välja alles 15. novembril. Suhteliselt pikk aeg, arvestades, et selle aja jooksul suutis Telegram korraldada ja välja kuulutada disainikonkursside ja C++ rakenduste arenduskonkursi tulemused VoIP kõnede testimise ja kvaliteedi hindamiseks Telegramis.

Valisime korraldajate pakutud nimekirjast välja kaks nutilepingut. Ühe jaoks kasutasime TONiga kaasasolevaid tööriistu, teise rakendasime uuel keelel, mille meie insenerid koostasid spetsiaalselt TONi jaoks ja mis on integreeritud Haskellisse.

Funktsionaalse programmeerimiskeele valik ei ole juhuslik. Meie ettevõtte blogis räägime sageli, miks peame funktsionaalsete keelte keerukust suureks liialduseks ja miks eelistame neid üldiselt objekti-orienteeritud keeltele. Muide, seal on ka artikli originaal.

Miks me üldse otsustasime osaleda

Lühidalt öeldes, meie spetsialiseerumine on ebatavalised ja keerulised projektid, mis nõuavad erioskusi ja omavad sageli teaduslikku väärtust IT-kommuunile. Me toetame innukalt open-source arendust ja tegeleme selle populariseerimisega ning teeme koostööd Venemaa juhtivate ülikoolidega arvutiteaduse ja matemaatika valdkonnas.

Võistluse huvitavad ülesanded ja seotus meie armastatud projektiga Telegram olid iseenesest suurepärane motivatsioon, lisaks tõi auhinnafond täiendavat stiimulit. 🙂

TONi plokiahela uurimine

Me jälgime tähelepanelikult uusi arenguid plokiahelas, tehisintellektis ja masinõppes, püüdes mitte magada maha ühtegi olulist väljaannet igas valdkonnas, kus töötame. Seega, konkursi alguseks oli meie meeskond juba tuttav ideedega, mis on pärit TON white paperist. Enne kui alustasime tööga TONi kallal, ei analüüsinud me tehnilist dokumentatsiooni ega platvormi tegelikku lähtekoodi, seega esimene samm oli üsna selge — põhjalik uurimine ametlikust dokumentatsioonist veebisaidil ja projekti hoidlas.

Kuna konkursi alguseks oli kood juba avaldatud, otsustasime aega säästes otsida juhendit või kokkuvõtet, mille olid kirjutanud kasutajad. Kahjuks ei andnud see tulemust — peale juhiste Ubuntu platvormi ülesehitamiseks ei leidnud me muid materjale.

Dokumentatsioon ise osutus hästi läbimõeldud, kuid selle lugemine oli mõningates kohtades keeruline. Me pidime üsna sageli tagasi pöörduma erinevate punktide juurde ja liikuma kõrgetasemelistelt abstraktsetelt ideedelt madalama taseme rakenduse detailide juurde.

Oleks olnud lihtsam, kui spetsifikatsioonis ei oleks üldse olnud üksikasjalikku rakenduse kirjeldust. Teave selle kohta, kuidas virtuaalne masin oma virna esitleb, pigem segab arendajaid, kes loovad TONi platvormile nutikaid lepinguid, kui aitab neid.

Nix: kogume projekti

Serokellis oleme suured fännid Nix. Me kogume oma projekte ja käivitame need kasutades NixOps, ja kõikidel meie serveritel on paigaldatud NixOS. Tänu sellele on kõik meie buildid reprodukutitavad ja töötavad igas operatsioonisüsteemis, kuhu Nixi saab installida.

Seega alustasime Nixi overlay loomisest TONi kogumise väljendiga. Tema abil on TON-i kiiresti kompileerida:

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

Pange tähele, et te ei pea installima mingeid sõltuvusi. Nix teeb kõik teie eest maagiliselt olenemata sellest, kas kasutate NixOS-i, Ubuntu või macOS-i.

Programmeerimine TON-i jaoks

Tarkvaralepingud TON võrgus töötavad TON Virtuaalmasinas (TVM). TVM on keerulisem kui enamik teisi virtuaalmasinaid ja omab väga huvitavaid funktsioone, näiteks oskab ta töötada katkestustega (continuations) ja andmeviidete (data references).

Veelgi enam, TON-i poisid on loonud lausa kolm uut programmeerimiskeelt:

Fift — universaalne virnastatud programmeerimiskeel, mis meenutab Forth. Tema supervõime on suhelda TVM-iga.

FunC — tarkvaralepingute programmeerimiskeel, mis sarnaneb C ja kompileeritakse veel üheks keeleks — Fift Assembliks.

Fift Assembler — Fifti teek TVM-i jaoks binaarse täidetava koodi genereerimiseks. Fift Assemblil pole kompilaatorit. See on sisseehitatud domaani spetsiifiline keel (eDSL).

Meie konkursitööd

Lõpuks on aeg vaadata meie pingutuste tulemusi.

Asünkroonne maksetee

Maksetee (payment channel) — tarkvaraleping, mis võimaldab kahel kasutajal teha makseid väljaspool plokiahelat. Seeläbi säästetakse mitte ainult raha (komisjoni pole), vaid ka aega (te ei pea ootama, kuni järgmine plokk töödeldakse). Maksed võivad olla tootmiselt nii väikesed kui vaja ja toimuda niipea kui vajalik. Samuti ei pea pooled üksteisega usaldama, kuna lõpliku arveldamise õiglus on tagatud tarkvaralepinguga.

Me leidsime probleemi jaoks üsna lihtsa lahenduse. Kaks osalist saavad vahetada allkirjastatud sõnumeid, millest igaüks sisaldab kahte numbrit — iga osaleja makstud kogusummat. Need kaks numbrit toimivad nagu vektorikellad traditsioonilistes hajusates süsteemides ja määratlevad järjekorra "toimus enne" tehingute puhul. Kasutades neid andmeid, suudab leping lahendada iga võimaliku konflikti.

Tegelikult piisab selle idee elluviimiseks ühest numbrist, kuid jätsime mõlemad, kuna nii suudame teha mugavama kasutajaliidese. Lisaks otsustasime igas sõnumis näidata makse suurust. Ilma selleta, kui sõnum mingil põhjusel kaob, võib kasutaja kaotust mitte märgata, kuigi kõik summad ja lõplik arvestus on õiged.

Kuna tahtsime meie ideed testida, otsisime näiteid sellise lihtsa ja lakoonilise maksekanali protokolli kasutamisest. Üllatuseks leidsime vaid kaks:

1. Kirjeldus sarnast lähenemist, ainult ühe suunalise kanali puhul.
2. Tutorial, milles on kirjeldatud sama ideed, mis meil, kuid ilma selgitusteta paljude oluliste detailide kohta, nagu üldine kehtivus ja konfliktide lahendamise protseduur.

Selgeks sai, et on mõistlik detailselt kirjeldada meie protokolli, pöörates erilist tähelepanu selle kehtivusele. Pärast mitmeid ringe oli spetsifikatsioon valmis ja nüüd saate seda ka vaadata.

Rakendasime lepingu FunC-is ning CLI tööriista meie lepinguga suhtlemiseks kirjutasime täielikult Fiftis, nagu soovitasid korraldajad. Me oleksime saanud valida mõne muu keele meie CLI jaoks, kuid meid huvitab proovida just Fiftit, et näha, kuidas see praktikas toimib.

Ausalt öeldes, pärast Fiftiga töötamist ei näinud me tõsiseid põhjuseid eelistada seda keelt populaarsetele ja laialdaselt kasutatavatele keeltele, millel on hästi arenenud tööriistad ja raamatukogud. Steke keeles programmeerimine on üsna ebameeldiv, kuna tuleb pidevalt meeles pidada, kus miski virnas asub, ja kompilaator selles ei aita.

Seega on ainus meie arvates Fift olemasolu õigustus selle roll host-keelena Fift Assembler'i jaoks. Kas poleks parem, kui integreerida TVM assembler mõne olemasoleva keele sisse, selle asemel et välja mõelda uus just selle, sisuliselt ainulaadse, eesmärgi jaoks?

TVM Haskell eDSL

Nüüd on aeg rääkida meie teisest nutilepingust. Otsustasime arendada multifirma rahakoti, kuid uue nutilepingu kirjutamine FunC-is oleks olnud liiga igav. Soovisime lisada midagi erilist, ja selleks valisime meie enda assembleri keele TVM jaoks.

Nagu Fift Assembler, on meie uus keel sisseembedatud, kuid hostina valisime Haskelli, mis võimaldab meil täielikult kasutada selle edasijõudnud tüübistikut. Targa lepingu puhul, kus isegi väikse vea hind võib olla väga kõrge, on staatiline tüübihindamine meie arvates suur eelis.

Kuidas demonstreerida, kuidas Haskellisse sisseembedatud TVM assembler välja näeb, oleme selle peal rakendanud tavalise rahakoti. Siin on mõned asjad, millele tasub tähelepanu pöörata:

• See leping koosneb ühest funktsioonist, kuid võite kasutada nii palju, kui soovite. Kui teete hostkeeles (st Haskellis) uue funktsiooni, võimaldab meie eDSL teil valida, kas soovite, et see muutuks eraldi alamprogrammi TVMs või lihtsalt integreeritakse kutsumisekohta.
• Nagu Haskellis, on funktsioonidel tüübid, mis kontrollitakse kompileerimise ajal. Meie eDSL-is on funktsiooni sisendi tüüp see, mida funktsioon väntab, ja tulemuste tüüp on see, mis tekib pärast kutset.
• Koodis on annotatsioonid stacktype, mis kirjeldavad oodatavat tüübistikut kutsepunktil. Originaalses rahakoti lepingus olid need lihtsalt kommentaarid, kuid meie eDSL-is on need tegelikult osa koodist ja neid kontrollitakse kompileerimise ajal. Need võivad toimida dokumentatsioonina või kinnitustena, mis aitavad arendajal probleemile jälile jõuda juhuks, kui koodi muutmisel tüübistik muutub. Muidugi ei mõjuta sellised annotatsioonid tööajal tulemuslikkust, kuna nende jaoks ei genereerita ühtegi TVM koodi.
• See on endiselt prototüüp, mis kirjutati kahe nädalaga, seega on projektis veel palju tööd teha. Näiteks kõik klasside eksemplarid, mida näete allpool olevas koodis, peavad olema automaatselt genereeritud.

Nii näeb välja multisig-rahakoti rakendamine meie eDSL-is:

peamine :: IO ()
peamine = putText $ pretty $ declProgram protsessid meetodid
  kus
    protsessid =
      [ ("recv_external", decl recvExternal)
      , ("recv_internal", decl recvInternal)
      ]
    meetodid =
      [ ("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
  tuletab (Eq, Ord, Show, Generic)

instance Exception WalletError

instance Enum WalletError where
  toEnum 33 = SeqNoMismatch
  toEnum 34 = SignatureMismatch
  toEnum _ = error "Tundmatu 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

Teie saate täielikku algkoodi meie eDSL ja mult_signature rahakoti lepingu leida selles hoidlas. Ja rohkem rääkis üksikasjalikult meie kolleeg Georgy Agapov.

Kokkuvõtted konkursist ja TON

Kokku meie töö võttis 380 tundi (koos dokumentatsiooniga tutvumise, koosolekute ja arendamisega). Konkursi projektis osales viis arendajat: CTO, meeskonna juht, plokiahela platvormide spetsialistid ja Haskellil tarkvara arendajad.

Meeskonnale osalemiseks vajalikke ressursse leidsime kiiresti, kuna hackathoni vaim, tihe meeskonnatöö, vajadus uute tehnoloogiate aspektidesse kiiresti süveneda — see on alati haarav. Mitmed unetukesed maksimaalse tulemuse nimel piiratud ressursside tingimustes on tasustatud hindamatu kogemuse ja suurepäraste mälestustega. Lisaks on selliste ülesannete kallal töötamine alati suurepärane katsumus ettevõtte protsesside jaoks, kuna tõeliselt rahuldavate tulemuste saavutamine ilma hästi toimiva sisemise koostööta on äärmiselt keeruline.

Lisaks lirikale: olime muljetavaldatud TONi meeskonna tehtud töö mahust. Neil õnnestus luua keeruline, ilus ja mis kõige tähtsam, töötav süsteem. TON on näidanud end platvormina, millel on suur potentsiaal. Kuid selleks, et ökosüsteem areneks, tuleb veel palju teha, nii plokiahela projektides kasutamise osas kui ka arendustööriistade täiustamise osas. Oleme uhked, et oleme nüüd osa sellest protsessist.

Kui pärast selle artikli lugemist on teil veel küsimusi või olete leidnud ideid, kuidas TONi oma probleemide lahendamiseks rakendada, kirjutage meile — me jagame meeleldi oma kogemusi.

Allikas: habr.com