技術シリーズ#5: ViteXのビルトインコントラクトの内部
ViteXは高性能な分散型取引所として、マッチングエンジンと経済モデルの両方をビルトインコントラクトvDexに実装しており、設計のシンプルさとシステムの堅牢性を両立させています。前回の記事「ViteXコントラクトの設計と実装」では、ViteXの設計の詳細について説明しました。そのフォローアップとして、本記事ではいくつかのFAQに焦点を当て、背景、問題点、解決策をさらに説明します。
- vDexが1つではなく2つのコントラクトとして実装される理由
ViteXでは、オーダーマッチングと経済モデルは2つの重要な機能ですが、互いに無関係の機能であるため、同じコントラクトに入れても意味がなく、開発者やAPIユーザーに混乱を招く可能性があります。さらに、マッチングエンジンは取引所の基本機能であり、経済モデルから切り離すと、独立して簡単にアップグレードすることができます。このような考えから、我々はdexFundとdexTradeに機能を分離しました。DexTrade は ViteX のオーダーブックとオーダーマッチングエンジンを実装し、DexFund は資産管理、マイニング、配当など ViteX の経済モデルに関連した機能を実行します。
2. 2種類の注文IDを使用する理由
前回の記事ではオーダーIDの構造を学びました。baseOrderIdと呼ばれるオーダーIDは、チェーン上の注文の並べ替えと効率的なマッチングによってパフォーマンスを最大化するように設計されています。 Viteの「Stem」ハードフォークでは、新しいオーダーID の hashOrderIdが追加されました。名前が示すように、hashOrderIdは注文が行われたトランザクションハッシュの値で構成されます。 baseOrderIdがコントラクトによって生成されるのとは異なり、hashOrderIdはvDexの応答を待たずにユーザーが注文した時点で作成されます。これにより、便利な注文ステータスの追跡に使用でき、それに応じて後続のアクションを実行できます。まとめると、hashOrderIdは取引ボットのようなクライアントプログラムで使用されることが多いのに対し、baseOrderIdはマッチング効率を高めるために設計されています。
3. 2つの注文キャンセルインターフェースが存在する理由
ViteXのオーダーブックはdexTradeに保存されており、注文をキャンセルするにはオーダーブックにアクセスする必要があるため、ViteXの初期バージョンでは注文キャンセルのインターフェースはdexTradeにありました。しかし、注文の配置は資金のロックアップを目的としてdexFundをベースにしているため、注文の配置とキャンセルの設計に一貫性がありません。実際の約定では、注文後、オンチェーンのコンセンサス遅延によりdexTradeのオーダーブックに書き込まれる前に、すぐにキャンセルされることがあります。このとき、該当の注文はオーダーブックに存在しないため、キャンセルが失敗します。この問題に対処するために、最近のフォーク「Mars」では、dexFund コントラクトにキャンセルインターフェースを追加しました。新しいデザインでは、ある注文に対して、ユーザーのアカウントチェーン上でのリクエストのシーケンスが保証されているため、注文後、キャンセルリクエストが確実にスマートコントラクトによって処理されることが保証されます。 2つのインターフェースを比較すると、新しいインターフェースは確定的な実行結果を生成しますが、dexFundからdexTradeにキャンセル要求を渡すための追加のステップを導入するコストがかかり、自動取引ツールの使用が推奨されます。
4. オーダーマッチングのパフォーマンスを向上させる方法
オーダーマッチングの速度を向上させる一般的な方法は、効率的なアクセスのために最良の注文またはすべての注文をメモリに入れることです。 しかし、スマートコントラクトの場合、ブロックチェーンが提供するストレージにアクセスできる能力が限られているため、オーダーブックをメモリに常駐させることができません。 現時点では、考慮すべき1つの方法は、基になるストレージを最大限に活用して、オーダーブックが正しい方法で保存されるようにすることです。これにより、マッチングプロセスでは逐次反復のみが必要になります。 注文IDの一部として価格を使用し、levelDBのストレージキーとして注文IDを使用することにより、単純なキーシーケンストラバーサルによって照合プロセスを完了することができます。 このソリューションはシンプルで非常に効率的です。
5. ストレージの使用率を下げる方法
オンチェーンストレージのコストは非常に高くなります。 そこで、データストレージを最小限に抑えるために、以下のようなアプローチを採用しています。第一に、Protobufを介してオブジェクトをシリアライズし、データサイズを小さくします。第二に、冗長なデータ格納を避けます。これは主にマイニングや配当に関連する指標の処理に反映されます。指標が一定時間変化していない場合は、最も古い値のみを格納します。第三に、リアルタイムクリーンアップと定期的なクリーンアップを併用すます。マイニングや配当などで蓄積された複数のバージョンの指標については、指標が更新された分だけ古いデータをリアルタイムで削除します。定期的なクリーンアップはオーダーブックに適用されます。オーダーブックの無制限の拡大を避けるために、各注文にタイムアウトのタイムスタンプを設定し、期限切れの注文は定期的にリサイクルされます。
6. vDexの信頼性を高める方法
組み込みコントラクトとして、vDexの各行のコードはプロトコルで書かれています。シンプルさと信頼性を十分に追求しなければなりません。過剰な設計はコードサイズを不必要に大きくし、最終的にはバグやエラーの数を増やすことになります。シンプルデザインの原則に基づき、vDexのデータ構造は可能な限りシンプルにしています。通常は変化しないコアデータのみをチェーン上に格納し、その他の無関係な情報はオフチェーンに格納しています。ViteXのオフチェーンデータサービスは、高度なクエリやデータ表示をサポートします。コードレベルでは、1つの関数のコード行数を制限しています。関数を分割し、関数に意味のある名前をつけることで、コードの重複を減らしています。コードをクリーンで読みやすいものにすることを目標としています。最後に、内蔵された監査機能により、定期的にコントラクト実行結果の正しさを検証し、ユーザー資産の安全性を確保しています。
