Transformant FunC en FunCtional avec Haskell : comment Serokell a remporté le Telegram Blockchain Competition

Vous avez sûrement entendu dire que Telegram prépare le lancement d'une plateforme blockchain Ton. Mais vous avez peut-être manqué la nouvelle indiquant que Telegram a annoncé un concours pour la mise en œuvre d'un ou plusieurs contrats intelligents pour cette plateforme.

L'équipe Serokell, fort d'une riche expérience dans le développement de grands projets blockchain, ne pouvait pas rester en dehors. Nous avons délégué cinq employés au concours, et seulement deux semaines plus tard, ils ont remporté la première place sous le pseudo (non)modeste de Sexy Chameleon. Dans cet article, je vais vous raconter comment ils y sont parvenus. Nous espérons qu'au cours des dix prochaines minutes, vous lirez au minimum une histoire intéressante, et au maximum que vous trouviez quelque chose d'utile que vous pourrez appliquer dans votre travail.

Mais commençons par une petite immersion dans le contexte.

Concours et ses conditions

Ainsi, les principales tâches des participants étaient la mise en œuvre d'un ou plusieurs des contrats intelligents proposés, ainsi que la soumission de propositions pour améliorer l'écosystème TON. Le concours s'est déroulé du 24 septembre au 15 octobre, et les résultats n'ont été annoncés que le 15 novembre. C'est assez long, considérant que pendant ce temps Telegram a réussi à mener et à annoncer les résultats des concours de design et de développement d'applications en C++ pour tester et évaluer la qualité des appels VoIP sur Telegram.

Nous avons choisi parmi la liste proposée par les organisateurs deux contrats intelligents. Pour l'un d'eux, nous avons utilisé les outils fournis avec TON, tandis que le second a été réalisé dans un nouveau langage développé par nos ingénieurs spécifiquement pour TON et intégré dans Haskell.

Le choix d'un langage de programmation fonctionnel n'est pas un hasard. Dans notre blog d'entreprise , nous expliquons souvent pourquoi nous pensons que la complexité des langages fonctionnels est une exagération et pourquoi nous préférez de manière générale ces derniers aux langages orientés objet. Au fait, il contient également l' original de cet article.

Pourquoi avons-nous décidé de participer ?

En résumé, parce que notre spécialité réside dans des projets non standards et complexes, nécessitant des compétences particulières et représentant souvent une valeur scientifique pour la communauté IT. Nous soutenons activement le développement open-source et nous nous engageons à sa promotion, tout en collaborant avec les principales universités de Russie dans le domaine des sciences informatiques et des mathématiques.

Les défis intéressants du concours et l'implication dans le projet bien-aimé Telegram étaient déjà une excellente motivation, et le fonds de prix a constitué un stimulant supplémentaire. 🙂

Recherche sur la blockchain TON

Nous suivons de près les nouvelles avancées dans le domaine de la blockchain, de l'intelligence artificielle et de l'apprentissage automatique, et nous veillons à ne manquer aucun lancement significatif dans chacun des domaines dans lesquels nous travaillons. Ainsi, au moment du lancement du concours, notre équipe était déjà familière avec les idées de la white paper de TON. Cependant, avant de commencer à travailler avec TON, nous n'avions pas analysé la documentation technique ni le code source réel de la plateforme, donc la première étape était assez évidente : une étude approfondie de la documentation officielle sur site et dans le référentiel du projet.

Au début du concours, le code avait déjà été publié, donc, pour gagner du temps, nous avons décidé de chercher un guide ou un résumé rédigé par des utilisateurs. Malheureusement, cela n'a pas donné de résultats : à part un manuel sur la compilation de la plateforme sur Ubuntu, nous n'avons trouvé aucun autre matériel.

La documentation elle-même s'est révélée soigneusement conçue, mais il était parfois difficile de la lire. Il nous a souvent fallu revenir sur certains points et passer d'une description abstraite de haut niveau à des détails d'implémentation de bas niveau.

Il aurait été plus simple si la spécification n'avait pas du tout comporté de description détaillée de l'implémentation. Les informations sur la façon dont la machine virtuelle représente sa pile distraient davantage les développeurs qui créent des contrats intelligents pour la plateforme TON qu'elles ne les aident.

Nix : Construction du projet

Chez Serokell, nous sommes de grands fans Nix. Nous construisons nos projets et les déployons à l'aide de NixOps, et tous nos serveurs sont équipés de NixOS. Grâce à cela, toutes nos créations sont reproductibles et fonctionnent sur n'importe quel système d'exploitation sur lequel Nix peut être installé.

Nous avons donc commencé par créer un overlay Nix avec une expression pour la construction de TON. Avec celui-ci, compiler TON est un jeu d'enfant :

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

Notez qu'il n'est pas nécessaire d'installer des dépendances. Nix fera magiquement tout pour vous, que vous utilisiez NixOS, Ubuntu ou macOS.

Programmation pour TON

Le code des smart contracts dans le réseau TON est exécuté sur la TON Virtual Machine (TVM). La TVM est plus complexe que la plupart des autres machines virtuelles et possède des fonctionnalités très intéressantes, par exemple elle peut travailler avec des continuations (continuations) et des liens vers des données.

De plus, les gars de TON ont créé trois nouveaux langages de programmation :

Fift — un langage de programmation basé sur la pile, similaire à Forth. Sa super-pouvoir est la capacité d'interagir avec la TVM.

FunC — un langage de programmation de smart contracts, qui ressemble à C et se compile en un autre langage — le Fift Assembler.

Fift Assembler — une bibliothèque Fift pour la génération de code binaire exécutable pour la TVM. Le Fift Assembler n'a pas de compilateur. C'est un langage orienté domaine embarqué (eDSL).

Nos travaux de concours

Enfin, il est temps de regarder les résultats de nos efforts.

Canal de paiement asynchrone

Un canal de paiement (payment channel) est un smart contract qui permet à deux utilisateurs d'envoyer des paiements en dehors de la blockchain. Cela permet non seulement d'économiser de l'argent (pas de frais), mais aussi du temps (vous n'avez pas à attendre que le prochain bloc soit traité). Les paiements peuvent être aussi petits que nécessaire et se produire aussi souvent que requis. De plus, les parties n'ont pas besoin de se faire confiance, car l'équité du règlement final est garantie par le smart contract.

Nous avons trouvé une solution assez simple au problème. Les deux parties peuvent échanger des messages signés, chacun contenant deux nombres — le montant total payé par chaque participant. Ces deux nombres fonctionnent comme les horloges vectorielles dans les systèmes distribués traditionnels et établissent l'ordre de « s'est produit avant » sur les transactions. En utilisant ces données, le contract pourra résoudre tout conflit potentiel.

En réalité, il suffirait d'un seul nombre pour réaliser cette idée, mais nous avons conservé les deux, car cela nous permettait de créer une interface utilisateur plus pratique. De plus, nous avons décidé d'inclure dans chaque message la taille du paiement. Sans cela, si un message est perdu pour une raison quelconque, bien que tous les montants et le règlement final soient corrects, l'utilisateur risque de ne pas se rendre compte de la perte.

Pour vérifier notre idée, nous avons recherché des exemples d'utilisation d'un protocole de canal de paiement aussi simple et concis. À notre grande surprise, nous n'en avons trouvé que deux:

1. Description une approche similaire, mais pour un canal unidirectionnel.
2. Tutoriel, qui décrit la même idée que la nôtre, mais sans expliquer de nombreux détails importants, tels que la correction globale et la procédure de résolution des conflits.

Il est devenu évident qu'il était nécessaire de décrire notre protocole en détail, en mettant particulièrement l'accent sur sa correction. Après plusieurs itérations, la spécification était prête, et maintenant vous pouvez aussi y jeter un œil.

Nous avons implémenté le contrat en FunC, et l'utilitaire en ligne de commande pour interagir avec notre contrat a été entièrement écrit en Fift, comme recommandé par les organisateurs. Nous aurions pu choisir n'importe quel autre langage pour notre CLI, mais nous étions intéressés à essayer Fift pour voir comment il se comporterait en pratique.

Honnêtement, après avoir travaillé avec Fift, nous n'avons pas vu de raisons convaincantes de préférer ce langage à des langages populaires et largement utilisés avec des outils et des bibliothèques développés. Programmer dans un langage de pile est assez désagréable, car il faut constamment garder à l'esprit ce qui se trouve dans la pile, et le compilateur n'aide pas vraiment.

Ainsi, la seule justification de l'existence de Fift, à notre avis, est son rôle en tant que langage hôte pour l'assembleur Fift. Mais ne serait-il pas mieux d'intégrer l'assembleur TVM dans un langage existant plutôt que d'en inventer un nouveau uniquement pour cette fin?

TVM Haskell eDSL

Il est maintenant temps de parler de notre deuxième contrat intelligent. Nous avons décidé de développer un portefeuille avec multisignature, mais écrire un autre contrat intelligent en FunC serait trop ennuyeux. Nous voulions ajouter une touche originale, et celle-ci est devenue notre propre langage d'assemblage pour TVM.

Tout comme l'assembleur Fift, notre nouveau langage est embarqué, mais au lieu de Fift, nous avons choisi Haskell comme hôte, ce qui nous a permis de tirer pleinement parti de son système de types avancé. Travailler avec des contrats intelligents, où le coût d'une petite erreur peut être très élevé, nous semble être un avantage considérable de la typage statique.

Pour démontrer à quoi ressemble l'assembleur TVM intégré dans Haskell, nous l'avons utilisé pour implémenter un portefeuille standard. Voici quelques éléments à considérer :

• Ce contrat se compose d'une seule fonction, mais vous pouvez en utiliser autant que nécessaire. Lorsque vous définissez une nouvelle fonction dans le langage hôte (c'est-à-dire en Haskell), notre eDSL vous permet de choisir si vous souhaitez qu'elle devienne un sous-programme distinct dans TVM ou simplement intégrée au point d'appel.
• Comme en Haskell, les fonctions ont des types qui sont vérifiés lors de la compilation. Dans notre eDSL, le type d'entrée de la fonction est le type de pile attendu, tandis que le type de résultat est le type de pile qui sera obtenu après l'appel.
• Le code contient des annotations stacktype, décrivant le type de pile attendu au point d'appel. Dans le contrat original du portefeuille, il s'agissait simplement de commentaires, mais dans notre eDSL, elles font réellement partie du code et sont vérifiées lors de la compilation. Elles peuvent servir de documentation ou d'assertions qui aident le développeur à identifier un problème si le type de pile change lors de modifications du code. Naturellement, ces annotations n'affectent pas les performances à l'exécution, car aucun code TVM n'est généré pour elles.
• C'est toujours un prototype, écrit en deux semaines, donc il reste encore beaucoup de travail à faire sur le projet. Par exemple, toutes les instances de classes que vous voyez dans le code ci-dessous doivent être générées automatiquement.

Voici à quoi ressemble l'implémentation d'un portefeuille multisig dans notre eDSL :

principal :: IO ()
principal = putText $ pretty $ declProgram procedures methods
  où
    procédures =
      [ ("recv_external", decl recvExternal)
      , ("recv_internal", decl recvInternal)
      ]
    méthodes =
      [ ("seqno", declMethod getSeqno)
      ]

donnée Stockage = Stockage
  { sCnt :: Word32
  , sPubKey :: CléPublique
  }

instance DecodeSlice Stockage où
  type DecodeSliceFields Stockage = [CléPublique, Word32]
  decodeFromSliceImpl = do
    decodeFromSliceImpl @Word32
    decodeFromSliceImpl @CléPublique

instance EncodeBuilder Stockage où
  encodeToBuilder = do
    encodeToBuilder @Word32
    encodeToBuilder @CléPublique

donnée ErreurDePortefeuille
  = SeqNoMismatch
  | SignatureMismatch
  dérivé (Eq, Ord, Show, Générique)

instance Exception ErreurDePortefeuille

instance Enum ErreurDePortefeuille où
  toEnum 33 = SeqNoMismatch
  toEnum 34 = SignatureMismatch
  toEnum _ = error "Id MultiSigError inconnu"

  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 @Stockage
  stacktype @[CléPublique, Word32, Word32, Slice, Signature]
  -- pk cnt' cnt cs sign

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

  equalInt >> throwIfNot SeqNoMismatch

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

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

  chkSignU
  stacktype @[Bool, Word32, Slice, CléPublique]
  -- ? 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, CléPublique]
    xchg @2
    sendRawMsg
    stacktype @[Slice, Word32, CléPublique]

  endS
  inc

  encodeToCell @Stockage
  popRoot

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

Vous pouvez trouver le code source complet de notre eDSL et du contrat de portefeuille avec multip signature dans ce dépôt. Notre collègue Georgy Agapov a expliqué plus en détail sur les langages intégrés. Les conclusions sur le concours et TON

En tout, notre travail a pris 380 heures (y compris la prise de connaissance de la documentation, les réunions et le développement proprement dit). Cinq développeurs ont participé au projet du concours : CTO, team lead, spécialistes des plateformes blockchain et développeurs de logiciels Haskell.

À propos du projet à gagner.

Les ressources pour participer au concours ont été faciles à trouver, car l'esprit du hackathon, le travail d'équipe rapproché et la nécessité de plonger rapidement dans les aspects de nouvelles technologies sont toujours passionnants. Quelques nuits blanches pour obtenir le meilleur résultat dans des conditions de ressources limitées sont compensées par une expérience inestimable et d'excellents souvenirs. De plus, travailler sur ce type de tâches est toujours un bon test des processus de l'entreprise, car obtenir des résultats vraiment dignes sans une interaction interne parfaitement réglée est très difficile.

Au-delà de la lyrisme : nous avons été impressionnés par l’ampleur du travail réalisé par l’équipe TON. Ils ont réussi à construire un système complexe, beau, et surtout, fonctionnel. TON a montré qu'il s'agit d'une plateforme ayant un grand potentiel. Cependant, pour que cet écosystème se développe, beaucoup de travail doit encore être fait, tant en ce qui concerne son utilisation dans des projets blockchain qu'en matière d'amélioration des outils de développement. Nous sommes fiers de faire désormais partie de ce processus.

Si après avoir lu cet article, vous avez des questions ou des idées sur la façon d'appliquer TON à vos besoins, contactez-nous — nous serons ravis de partager notre expérience.

Source : habr.com