Haskell で FunC を FunCtional に変える: Serokell が Telegram ブロックチェーン コンペティションで優勝した方法

あなたはおそらくそのテレグラムを聞いたことがあるでしょう Ton ブロックチェーン プラットフォームを立ち上げようとしています。 しかし、あなたは少し前のTelegramのニュースを見逃したかもしれません コンテストを発表しました このプラットフォームの XNUMX つ以上のスマート コントラクトの実装用。

大規模なブロックチェーン プロジェクトの開発に豊富な経験を持つ Serokell チームは、傍観することができませんでした。 私たちは XNUMX 人の従業員をコンテストに参加させ、XNUMX 週間後、彼らはセクシー カメレオンという控えめなランダムなニックネームで優勝しました。 この記事では、彼らがどのようにそれを行ったかについて説明します。 これからの XNUMX 分間で、少なくとも興味深い物語を読んでいただき、多くてもその中で自分の仕事に応用できる有益な何かを見つけていただければ幸いです。

しかし、少し文脈から始めましょう。

競争とその条件

したがって、参加者の主なタスクは、提案されたスマート コントラクトの 24 つ以上を実装することと、TON エコシステムを改善するための提案を行うことでした。 コンテストは15月15日からXNUMX月XNUMX日まで実施され、結果はXNUMX月XNUMX日にのみ発表された。 この間、Telegram は Telegram での VoIP 通話の品質をテストおよび評価するために、C++ でのアプリケーションの設計と開発に関するコンテストを開催し、結果を発表できたことを考えると、かなり長い時間がかかりました。

主催者が提案したリストから XNUMX つのスマートコントラクトを選択しました。 そのうちの XNUMX つは TON で配布されているツールを使用し、XNUMX つ目は当社のエンジニアが TON 専用に開発し、Haskell に組み込まれた新しい言語で実装しました。

関数型プログラミング言語の選択は偶然ではありません。 私たちの中で 企業ブログ 私たちは、関数型言語の複雑さが非常に誇張されていると考える理由や、一般にオブジェクト指向言語よりも関数型言語を好む理由についてよく話します。 ちなみに中にはこんなものも入ってます この記事のオリジナル.

なぜ参加しようと思ったのでしょうか？

つまり、私たちの専門分野は特殊なスキルを必要とする非標準的で複雑なプロジェクトであり、多くの場合 IT コミュニティにとって科学的価値があるからです。 私たちはオープンソース開発を強力にサポートし、その普及に取り組んでおり、コンピュータサイエンスと数学の分野でロシアの有力大学とも協力しています。

コンテストの興味深い課題と、私たちが愛する Telegram プロジェクトへの参加は、それ自体が大きな動機となりましたが、賞金はさらなるインセンティブとなりました。 🙂

TONブロックチェーン研究

私たちはブロックチェーン、人工知能、機械学習の新たな開発を注意深く監視し、私たちが取り組んでいる各分野での重要なリリースを見逃さないように努めています。 したがって、コンテストが開始されるまでに、私たちのチームはすでに次のアイデアに精通していました。 TONのホワイトペーパー。 ただし、TON での作業を開始する前に、プラットフォームの技術ドキュメントと実際のソース コードを分析しなかったため、最初のステップは非常に明白でした。つまり、TON の公式ドキュメントを徹底的に調査することです。 オンライン と プロジェクトリポジトリ.

コンテストが始まるまでにコードはすでに公開されていたため、時間を節約するために、次の著者が書いたガイドまたは概要を探すことにしました。 ユーザーによる。 残念ながら、これでは結果は得られませんでした。Ubuntu でプラットフォームを組み立てる手順以外に、他の資料は見つかりませんでした。

Сама документация оказалась тщательно проработанной, но читать ее в некоторых моментах было сложно. Довольно часто нам приходилось возвращаться к тем или иным пунктам и переключаться с высокоуровневых описаний абстрактных идей на низкоуровневые детали реализации.

仕様に実装の詳細な説明がまったく含まれていない方が簡単です。 仮想マシンがそのスタックをどのように表現するかに関する情報は、TON プラットフォーム用のスマート コントラクトを作成する開発者の助けになるというよりも、開発者の注意をそらす可能性が高くなります。

ニックス: プロジェクトをまとめる

セロケルでは私たちは大ファンです ニックス。 それを使用してプロジェクトを収集し、それを使用してデプロイします。 ニクスオプス、すべてのサーバーにインストールされています Nix OS。 このおかげで、私たちのすべてのビルドは再現可能であり、Nix がインストールできるあらゆるオペレーティング システムで動作します。

そこで私たちは作成することから始めました TON アセンブリの式を備えた Nix オーバーレイ。 これを利用すると、TON のコンパイルが可能な限り簡単になります。

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

依存関係をインストールする必要がないことに注意してください。 NixOS、Ubuntu、または macOS のいずれを使用しているかに関係なく、Nix は魔法のようにすべてを実行します。

TONのプログラミング

TON ネットワークのスマート コントラクト コードは、TON 仮想マシン (TVM) 上で実行されます。 TVM は他のほとんどの仮想マシンよりも複雑で、非常に興味深い機能を備えています。 続き и データへのリンク.

さらに、TON のメンバーは XNUMX つの新しいプログラミング言語を作成しました。

フィフト は、次のようなユニバーサル スタック プログラミング言語です。 フォース。 彼の超能力は TVM と対話する能力です。

ファンシー に似たスマート コントラクト プログラミング言語です。 C そして別の言語であるFift Assemblerにコンパイルされます。

XNUMX 番目のアセンブラ — TVM 用のバイナリ実行可能コードを生成するための XNUMX つのライブラリ。 Fifth アセンブラにはコンパイラがありません。 これ 埋め込みドメイン固有言語 (eDSL).

私たちの競争はうまくいきます

最後に、私たちの取り組みの結果を見てみましょう。

非同期決済チャネル

支払いチャネルは、XNUMX 人のユーザーがブロックチェーンの外部に支払いを送信できるようにするスマート コントラクトです。 その結果、お金 (手数料がかからない) だけでなく、時間も節約できます (次のブロックが処理されるまで待つ必要がありません)。 支払いは必要なだけ少額で、必要な回数だけ行うことができます。 この場合、最終的な決済の公平性はスマートコントラクトによって保証されているため、当事者はお互いを信頼する必要はありません。

私たちはこの問題に対する非常に簡単な解決策を見つけました。 XNUMX つの当事者は、それぞれに XNUMX つの番号 (各当事者が支払った全額) を含む署名付きメッセージを交換できます。 これら XNUMX つの数値は次のように機能します ベクトル時計 従来の分散システムでは、トランザクションに「以前に発生した」順序を設定します。 このデータを使用すると、契約は起こり得る競合を解決することができます。

実際、このアイデアを実装するには XNUMX つの数値で十分ですが、この方法の方がより便利なユーザー インターフェイスを作成できるため、両方を残しました。 また、各メッセージにお支払い金額を記載することにしました。 これがないと、何らかの理由でメッセージが失われた場合、すべての金額と最終計算は正しくても、ユーザーは損失に気付かない可能性があります。

私たちのアイデアをテストするために、このようなシンプルで簡潔な支払いチャネル プロトコルの使用例を探しました。 驚いたことに、見つかったのは次の XNUMX つだけでした。

1. 説明 同様のアプローチですが、単方向チャネルの場合のみです。
2. チュートリアル、これは私たちの考えと同じ考えを説明していますが、一般的な正確性や競合解決手順などの多くの重要な詳細については説明していません。

その正確さに特に注意を払いながら、プロトコルを詳細に説明することが合理的であることが明らかになりました。 数回の繰り返しの後、仕様が完成しました。これで、あなたも仕様を作成できるようになりました。 彼女を見て.

主催者の推奨に従って、コントラクトを FunC で実装し、コントラクトを操作するためのコマンド ライン ユーティリティをすべて Fift で作成しました。 CLI には他の言語を選択することもできましたが、Fit を試して実際のパフォーマンスを確認することに興味がありました。

正直に言うと、Fift と協力した後、開発されたツールやライブラリを備えた人気があり積極的に使用されている言語よりも、この言語を優先する説得力のある理由は見つかりませんでした。 スタックベースの言語でのプログラミングは、スタック上にあるものを常に頭の中に入れておく必要があり、コンパイラはこれを助けてくれないため、非常に不快です。

したがって、私たちの意見では、Fift の存在を正当化する唯一の理由は、Fift Assembler のホスト言語としての役割です。 しかし、この本質的に唯一の目的のために新しいものを発明するよりも、TVM アセンブラを既存の言語に埋め込んだ方が良いのではないだろうか?

TVM Haskell eDSL

今度は XNUMX 番目のスマート コントラクトについて説明します。 私たちはマルチシグネチャウォレットを開発することにしましたが、FunC で別のスマートコントラクトを書くのは退屈すぎます。 いくつかのフレーバーを追加したかったのですが、それが TVM 用の独自のアセンブリ言語でした。

Fift アセンブラーと同様に、新しい言語は埋め込まれていますが、ホストとして Fift ではなく Haskell を選択し、その高度な型システムを最大限に活用できるようにしました。 スマート コントラクトを扱う場合、小さなエラーでもコストが非常に高くなる可能性があるため、静的型付けは大きな利点であると私たちは考えています。

Haskell に埋め込まれた TVM アセンブラーがどのようなものかを示すために、それに標準のウォレットを実装しました。 注意すべき点がいくつかあります。

• この契約は XNUMX つの機能で構成されていますが、必要に応じて複数の機能を使用できます。 ホスト言語 (Haskell など) で新しい関数を定義する場合、eDSL を使用すると、それを TVM の別個のルーチンにするか、呼び出し時点で単にインライン化するかを選択できます。
• Haskell と同様、関数にはコンパイル時にチェックされる型があります。 eDSL では、関数の入力タイプは関数が予期するスタックのタイプであり、結果タイプは呼び出し後に生成されるスタックのタイプです。
• コードには注釈が付いています stacktype、呼び出しポイントで予想されるスタック タイプを説明します。 元のウォレット契約では、これらは単なるコメントでしたが、eDSL では実際にはコードの一部であり、コンパイル時にチェックされます。 これらは、コードが変更されスタック タイプが変更された場合に、開発者が問題を発見するのに役立つドキュメントまたはステートメントとして機能します。 もちろん、このようなアノテーションは TVM コードが生成されないため、実行時のパフォーマンスには影響しません。
• これはまだ XNUMX 週間で書かれたプロトタイプなので、このプロジェクトにはまだやるべきことがたくさんあります。 たとえば、以下のコードにあるクラスのインスタンスはすべて自動的に生成される必要があります。

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 およびマルチシグネチャ ウォレット コントラクトの完全なソース コードは、次の場所にあります。 このリポジトリ。 もっと 詳しく語られた 組み込み言語については、同僚の Georgy Agapov が説明します。

コンテストと TON に関する結論

私たちの作業には合計 380 時間かかりました (ドキュメントの作成、会議、実際の開発を含む)。 コンテスト プロジェクトには、CTO、チーム リーダー、ブロックチェーン プラットフォームのスペシャリスト、Haskell ソフトウェア開発者の XNUMX 人の開発者が参加しました。

ハッカソンの精神、緊密なチームワーク、そして新しいテクノロジーの側面に素早く没頭する必要性は常に刺激的なものであるため、私たちはコンテストに簡単に参加できるリソースを見つけました。 限られた資源の中で最大限の成果を達成するために数晩眠れぬ夜を過ごしたとしても、それは貴重な経験と素晴らしい思い出によって補われます。 さらに、このようなタスクに取り組むことは、常に会社のプロセスを試す良いテストとなります。社内の相互作用が適切に機能しなければ、真に適切な結果を達成することは非常に困難だからです。

歌詞はさておき、私たちは TON チームが費やした労力に感銘を受けました。 彼らは、複雑で美しく、そして最も重要なことに、機能するシステムを構築することに成功しました。 TON は、大きな可能性を秘めたプラットフォームであることが証明されています。 ただし、このエコシステムが発展するには、ブロックチェーン プロジェクトでの使用と開発ツールの改善の両方の点で、さらに多くのことを行う必要があります。 私たちは今、このプロセスに参加できることを誇りに思っています。

この記事を読んでもまだ質問がある場合、または TON を使用して問題を解決する方法についてアイデアがある場合は、 私たちに書いてください — 私たちの経験を喜んで共有させていただきます。

出所： habr.com