Elixir Protocolについて(ドキュメント和訳)
本記事は、Elixirチームに許可をいただき、Elixir Protocol公式ドキュメントを日本語訳したものです。
Elixirについて
次世代流動性供給の導入：誰でも直接オーダーブックに流動性を供給できるDPoSネットワーク
Elixir Protocolは、高スループットのDPoSコンセンサス・ネットワークであり、誰でもオーダーブックに流動性を供給することができます。このプロトコルは、x*y=k カーブに相当するオーダーブックを活用して流動性を構築し、Bid/Askスプレッドを狭くし、オーダーブックに流動性をアルゴリズム的に配置します。
Elixirは完全にコンポーザブル(複数の要素を結合して構成が可能)であるため、オーダーブックDEXは、Elixirを自分たちのコア・インフラとしてネイティブに統合し、取引ペアのリテール流動性を解放することができます。このプロトコルは重要な分散型インフラとして機能し、取引所やプロトコルが簡単に流動性をブートストラップすることを可能にします。
Elixirは20以上の主要なDEXのコア・インフラにネイティブに統合されています。
ネットワークのアーキテクチャ(構造)
Elixir Protocolの地盤
Elixirの基盤となるDPoSインフラは分散型で高スループットです。プロトコルは、取引所に対して発注された注文のコンセンサスを得ます。このインフラはArbitrumのセキュリティモデルに似ており、fraud proof(不正の証明)はオンチェーンにポストされます。
取引所フィード
取引所フィードは、各取引所の読み取り専用認証情報を保持し、個別に単一の更新ストリームを購読し、そのデータをデータアグリゲータにブロードキャストします。Elixirが取引所のセントラル・リミット・オーダーブックに接続する方法の詳細については、「取引所オーダーブック接続」のサブセクションを参照してください。
データアグリゲーター
データアグリゲーターは、複数の取引所フィードからデータを収集し、決定論的なデータフレームに結合して署名し、バリデーターとオーディター（監査人）に送信します。Elixirの技術スタックにおいて、データアグリゲーターにより、バリデーターは取引所フィードから関連する正確なデータに基づいて行動できるようになります。
バリデーターネットワーク（DPoS）
Elixirのバリデーターネットワークは、リレーノードで実施される、66%のコンセンサスを必要とする分散型プルーフ・オブ・ステークシステムで運営されています。エンドユーザーは自分のステークをバリデーターに委任し、ステークされた金額で上位のバリデーターが最大の報酬を受け取ります。
リレーノード
リレー(中継)ノードは各取引所の取引キーを保持し、各バリデーターからの注文提案フレームを集計します。注文提案の有効期限が切れたら、その注文は監査人に渡され、正しいかどうかが検証されます。長期的には、APIキーはこれらのノード内でSGX + SSS(Shamir’s Secret Sharing)によって保護されます。
紛争解決（監査人＋コントローラー・ノード）
紛争解決レイヤー（監査人、コントローラー、Provable.xyzインフラ(後述)で構成）は、ネットワークが不正なく行動していることを保証し、紛争が発生した場合に解決するために機能します。具体的には、このレイヤーは、バリデーターが最初のガイダンスに基づいて適切に設定されたパラメーターでマーケットメイキングアルゴリズムを実行していることを保証します。さらに監査人は、報奨金によってバリデーターに誠実な行動を促すと同時に、不正行為にはペナルティを科します。
Provable.xyz
Provableは、私たちのコントローラーのスマートコントラクトによってオンチェーンで呼び出され、アルゴリズムの実行と整理を行います。実行が完了すると、結果は暗号証明とともにコントローラーのスマートコントラクトへのコールバックを介してオンチェーンで提供されます。
バリデーター
Elixirのバリデーターネットワークは、プロトコルの技術インフラの中核をなすものです。
バリデーターはElixirスタックの重要なコンポーネントであり、基礎となるアルゴリズムを実行し、ネットワーク内でコンセンサスを得る役割を担っています。
これらのインフラを運営する関係者は、ネットワークと経済的に連携しています。バリデーター・ネットワークは、分散型のプルーフ・オブ・ステーク・システムによって運営されています。このコンセンサスを実行するリレー(中継)ノードにデータを渡すためには、66%のコンセンサスが必要です。
ユーザーとバリデーターは、ELXRトークンを個々のバリデーターに委任することができ、委任された上位のバリデータがコンセンサスに参加することになります（そしてネットワークから最大の報酬を受け取ります）。
ステーキング、報酬、ボンドプール、スラッシングの管理を担当するコントローラーは、オンチェーンでProvableを呼び出し、紛争が発生した場合に監査人から注文提案を検証または拒否するオンチェーン・コールバックを受け取ります。バリデーターが悪意を持って行動していることが発覚した場合、委任されたトークンのステークは削減されます（詳細は「紛争解決」を参照）。
各ストラテジーにはランダムな要素が含まれます。最初のストラテジーは、AvellanedaとStoikovのアルゴリズム（詳しくはアルゴリズムによるオーダーブックの構築）の変形で、（T — t）が直線的に0に進むのではなく、ランダム・ウォークとしてアプローチします。このランダム性は、バリデータ間で同期できる VRF を備えた SGXセキュア・エンクレーブ内で生成されます。プロトコルがどのようにゲーミフィケーションを防止し、回復力を構築するかについては、ゲーミフィケーションの防止をお読みください。
Fraud Proofs(不正防止)
エリクサーのテクニカルアーキテクチャは、オーダーブックのフローとオフチェーンマーケットメイキングが機能的かつ安全に動作することを保証します。
セキュリティはElixir Protocolの中核です。技術的なプロセスフロー面では、監査人とコントローラーのインフラが、取引所に送信されるデータが正直で正確であることを保証します。
監査人インフラはネットワーク内のインプット/アウトプットを監視し、コントローラーインフラはアウトプットの不整合の結果として発生する可能性のあるコンフリクトを解決します。これによってネットワーク内の正確性が保証され、ストラテジーやユーザーにとって有害なデータを出力しようとするバリデーターからの、悪意のある行為をブロックすることができます。
監査人
監査人はネットワークの残りの部分を公正に保つための働きをします。監査人は、ネットワーク内の様々なアクターからの入力と出力を監視し、（報告された、または観察された）不整合がある場合、監査人は、報奨金と引き換えに、悪意のある活動の証明をコントローラーのETHスラッシング・スマートコントラクトに提出します。報奨金はバリデーターのステークから抽出され、監査人に入金されます。
最後に、監査人はステーク報酬のためにバリデーターのアップタイムを確保する責任があります。
コントローラー（スマートコントラクト）
バリデーターが矛盾する出力を提出した場合、ElixirはProvable TEE (https://docs.provable.xyz/)を使用して、与えられた入力データセットに対して正しい出力を安全に計算し、対応する真正性の証明を返します。各マーケットメイキング・ストラテジーをオンチェーンで実行する能力を持ち、ネットワーク上の当事者間の意見の相違を裁定する役割を果たします。
コントローラーは、ステーキング、報酬、ボンドプール、および（バリデータが不正に行動していることが判明した場合の）スラッシングの管理などの重要な活動を担当します。
取引所オーダーブック接続
Elixirは取引所のオーダーブックに接続し、アルゴリズムによるマーケットメイキングを行います。取引所はウェブソケットを公開し、取引、ポジション、オーダーブックに関する低遅延アップデートを提供します。Elixir protocolはこれらのリアルタイムデータストリームを消費し、プロトコルのティックサイズに対応する時間スライスで定期的にオーダーブックをデータフレームにスナップショットします。データフレームデータは、各取引所間のオーダーブックの一貫した表現を提供するために正規化されます。
データフレームとは？
データフレームとは、Elixirのセキュリティ・インフラとユーザー自身が、ネットワーク上のデータフローの信頼性と正確性を検証するための、一貫した真実の情報源（真実を語る資料）です。
データフレームは暗号署名され、ネットワーク内のすべての参加者に送信されます。ネットワーク参加者は、署名をチェックすることでデータフレームの出所を検証できます。これはオンチェーンとオフチェーンの両方で行うことができます。
署名されたデータフレームは、ネットワーク内のノードからの提案された命令や、プロトコル内で保持されている全体的なポジションに異議を唱えるために使用できます。
Elixirのテクニカルアーキテクチャの詳細については、「バリデーター/ ノードネットワーク」のセクションを参照してください。
取引所とのネイティブ統合
Elixir Protocolは、主要なDEXによってネイティブに統合されており、リテールユーザー（エンドユーザー）がオーダーブックに直接流動性を供給し、補助金付きのAPYを得ることを可能にします。パーペチュアルとスポットのオーダーブック DEX はいずれも、流動性のブートストラップという根本的な問題に直面しており、流動性の唯一の選択肢は、中央集権型のマーケットメイキング企業です。
Elixir Protocol は、DeFiオーダーブック・ベースの取引所に簡単に統合でき、リテール・ユーザーがワンクリックでオーダーブックに流動性を供給し、補助金付きのAPYを得ることができます。
Elixirを通じて、主要なオーダーブックDEXは、ユーザーが受動的に流動性をペアに供給することを可能にし、オーダーブックを構築し、そのオーダーブックのためにリテール流動性をアンロックします。その結果、取引ペアのBid-Askスプレッドが狭くなり、流動性が高まります。LPへの報酬は、取引所から長期的なElixirインセンティブや流動性プロバイダーインセンティブプログラムを通じて支払われます。
これにより、DEXがマーケットメイキングのために一握りの中央集権企業と取引する必要がある現状に代わる選択肢が生まれます。
Elixirがこれらのペアのオーダーブックを構築するために使用しているアルゴリズムについての詳細は、「アルゴリズムによるオーダーブックの構築」のセクションをご覧ください。
取引所報酬
Elixirのネイティブ統合により、取引所レベルで提供する報酬（リワード）の詳細をご覧ください。
以下のリンクは、各ネイティブ統合の取引所報酬プログラムに関連付けられており、個々のユーザーは Elixir のそれぞれのネイティブ統合に入金することで利用できます。Elixirへの入金者に報酬を与える「メイカー・プログラム」はそれぞれ異なるため、取引所の報酬がユーザーにいつどのように支払われるかについては、注意深く確認してください。
- Vertex Fusion: https://vertex-protocol.gitbook.io/docs/community-token-and-dao/trading-rewards-detailed-mechanism. Elixir LPの場合、最初の3ヶ月間は15%のAPRが適用されます（ARBで支払い）。
- Injective: https://trading.injective.network/program/liquidity
- Bluefin: https://bluefinfoundation.notion.site/Early-Partner-Program-11601ca9487a4a35928ec7e9c467d71c
- RabbitX Fusion: https://docs.rabbitx.io/liquidity-incentive-rewards
- Satori: 近日発表
- WooFi: 近日発表
- dYdX: 近日発表
アルゴリズムによるオーダーブックの構築
Elixirは、Uniswap v2のx*y=k式とほぼ同等のオーダーブックを実行します。LPはAMMのLPと非常に似たリスク/リターンプロファイルを持っています。マーケットメイカーには、在庫ーリスクと最適なビッド-アスクスプレッドの提示という2つの主要な懸念事項があります。
AvellanedaとStoikovは、理想的なリザーブ価格と理想的なBid-Askスプレッドの公式を開発し、これらの懸念に対処するモデルを計算したことで有名です。Avellaneda Stoikovはシンプルで、Uniswap v2 の x*y=k 式とほぼ同等のオーダーブックと考えることができます。その LP は、Uniswap v2 LP と非常によく似たリスク/リターン プロファイルを持っています。
Elixirは、DEXのオーダーブック全体に流動性を配備するために、AvellanedaとStoikovのアルゴリズムのカスタムバリエーションを使用しています。これらの計算式に入る前に、「リザーブ価格」について言及するとき、何が参照されているかを理解することが重要です。
マーケットメイクの最も単純な形式では、BidとAskを市場価格から等しい距離に設定します。純粋なマーケット・メイキングストラテジーは、横ばい相場ではうまく機能しますが、強い方向性のトレンド時には、ほぼ間違いなく在庫(インベントリー)が偏ることになります。Avellaneda & Stoikovのリザーブ価格式（下図）は、マーケットメイカーがBidとAskのスプレッドを設定するために使用する市場価格を再設計することで、この懸念を阻止しようとするものです。
s = 現在のマーケット価格(BidとAskの中間)
q = 希望するアセットターゲットに対するベースアセットの単位あたり数量σ = ボラティリティ
T = 取引終了時間
t = 現在の時間 (Tは1に正規化され、したがってtは時間分数)
δa, δb = bid/askスプレッド
δa=δb = 対称スプレッド
γ = 在庫リスクパラメーター
κ = オーダーブックの流動性パラメーター
この式により、プロトコルは現在の在庫が目標在庫からどの程度離れているかを判断し、それに応じてBidとAskを調整することができます（Bidをミッドに近づけ、Askを遠ざける、またはその逆）。こうすることで、流動性はオーダーブックの両側に配置されますが、資産価格が一方向に傾き始めても、メイカーは資産在庫の大きな不均衡に遭遇することはありません。
上図の凡例では、q、γ、(T-t)はすべてカスタマイズ可能なインプットであり、メイカーは目標とする基本資産在庫を決定し、在庫リスクパラメータを設定し（資産残高が一貫性を維持するようにする）、取引時間を設定できます（24時間365日のクリプトマーケット内で無限マーケットメイクを行う場合は1に設定される可能性が高い）。
AvellanedaとStoikovは、最適なBidとAskのスプレッドを設定するために、オーダーブックの密度を決定し、BidとAskの注文スプレッドを設定する基準価格を設定する計算式を開発しました。
上式では、κはオーダーブックの流動性パラメータを表し、特定のブックについて、この変数の値が高いほど、流動性が高いことを示します。スプレッドはκの値と相関しており、一般にオーダーブックが厚いほどスプレッドは狭く、薄いほどスプレッドは広くなります。
実際には、このストラテジーは、オーダーブックの流動性を展開するためのいくつかの重要なステップを完了しました。
まず、前述のリザーブ価格の公式を使用し、ユーザーが設定した在庫目標に基づいて、このストラテジーは使用すべき理想的な市場価格を計算します。次に、ブックの深さに応じてペアの最適なBidとAskのスプレッドを計算し、最後にスプレッドに基づいてBidとAskの発注を開始します。
このストラテジーのパフォーマンスと実践に関する詳細は、Takahiro Fushimi、Christian Gonzalez Rojas、Molly Hermanによるスタンフォードの「Optimal High-Frequency Market Making」（2018年）に記載されています。
私たちのプロトコルが完全に透明性を確保していることを考えると、Elixir Protocol によってオーダーブックを構築するために使用されるアルゴリズムのゲーミフィケーションから保護するためには、外部のプレーヤーに対する耐性を構築することが非常に重要です。詳しくは「ゲーミフィケーションの防止」をお読みください。
ゲーミフィケーションの防止
分散化された透明な取引システムは、外部のプレイヤーがElixirのLPに有害な影響を及ぼそうと試みるゲーミフィケーションのリスクに直面しています。
これに対抗するために、私たちのプロトコルでは、使用するストラテジー内でランダムに生成されたコンポーネントを利用します。私たちのストラテジーは、AvellanedaとStoikovのアルゴリズムの変形であり、(T — t)が線形に0に進む代わりに、プロトコルはこのパラメータの値をランダムに生成します（0と1の間のランダムウォーク）。これはバリデーターの SGXセキュアエンクレーブ内で生成され、バリデーター間で同期されます。
この値は各取引所のペアごとに独立して継続的に計算されるため、重大なエントロピーが導入され、最適なBid/Ask (δa、δb) と最低価格 r の両方の入力データが与えられた場合にリザーブ価格 r (s、t)を計算することが不可能になります。
注文時間もランダムになります。注文は、ランダムに決められた間隔で（あるいはまったく出されないこともあります）取引所に出されます。「フリッカー注文」として知られるこのプラクティスは、知識のあるマーケットテイカーが取引所でプロトコルの注文を悪用しようとすることを防ぎます。
ELXRトークン
ELXR は、Elixir エコシステムの将来のネイティブ・ユーティリティおよびガバナンス・トークンであり、コンセンサスを強化し、保有者がプロトコルの将来を方向付けることを可能にします。最終的にメインネットがローンチされると、Elixirは完全に分散化された状態を実現します。これには、完全に分散化されたテクニカルアーキテクチャ、ELXRトークンによって運営されるガバナンスフォーラム、ELXRトークンの価値を高めるためのフォーラムへの複数の提案が含まれます。包括的な目標は、1.効果的なガバナンスメカニズムを構築すること、2.ELXRをクリプト経済的なセキュリティ・インセンティブとして活用すること、3.プラットフォームを完全に分散化し、パーミッションレスにすることです。
ノード/バリデータELXRステーキング要件
プロトコルの中核をなすノードとバリデーターのインフラは、主にELXRトークンによって主導されます。すべてのバリデーターとノードは、インフラを有効かつ良好な状態に保つために、一定量のELXRトークンをステークする必要があります。ELXRトークンの需要を生み出すだけでなく、これはプラットフォーム全体のセキュリティにとってより大きな役割を果たします。
「テクニカルアーキテクチャ」のセクションで説明したように、ノードとバリデータはプロトコル全体のセキュリティと適切な機能を保証します。これらの関係者に大量のELXRトークンのステークを要求することで、彼らの行動がすべてプロトコルをより良くするために行われることを保証します。プロトコルに損害を与えようとする不誠実なノードやバリデーターは、逆に自分の保有するトークンの価値を傷つけることになります。さらに、これらの当事者による不誠実な行動は、コントローラー・インフラがステークされたトークンの保有量を削減することにつながり、非常に直接的な経済的阻害要因となります。また、このような経済的インセンティブだけでは、すべてのインフラプロバイダーの誠実さと正確さを保証できない場合、監査人とコントローラー・インフラが真実の裁定者として機能します。
Elixirエコシステムは、ELXRトークンのセキュリティに依存しており、ELXRトークンはプラットフォームのアーキテクチャの重要な構成要素となっています。
ガバナンス
ELXRトークンはエコシステム内の唯一のガバナンストークンでもあり、保有者とネットワーク参加者に、プロトコルの将来の成長を形作る案を提案し、投票する能力を与えます。
手数料の方向性
メインネットローンチ後、ELXRの保有者は完全なガバナンス権を持つと同時に、プロトコルの手数料の方向性をコントロールできるようになります。ガバナンスの参加者は、これらの手数料の内容や、発生した価値の方向性を選択する自治権を持ちます。
Elixir v2.0バリデータの実行
Elixir Testnet v2 バリデータの設定ガイド
以下は、Elixirプロトコルのテストネット上でバリデーターを実行し、マーケットメイキング・アルゴリズムの安全性と有効性を保証するためのステップバイステップ・ガイドです。
Testnet v2 バリデーターの設定ガイド
準備 — ハードウェア要件
ほとんどのハードウェアでバリデータノードを実行させることができます。ただし、4GBのメモリと信頼性の高い100Mbitのインターネット接続が可能で、24時間稼働できるシステムを用意することを推奨します。ディスク使用量は最低限で、ほとんどの場合30GBあれば十分です。仮想専用サーバー（AWS、Vultr、その他のVPSなど）の利用をお勧めします。
準備 — システムのセットアップ
バリデータを実行するには、最新のDockerがインストールされたシステムが必要です。お使いのオペレーティングシステムのインストールガイドに従ってください。ターミナルを開き、
docker psを実行して、インストールがうまくいくことを確認してください。以下のような出力が表示されるはずです。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESエラーが表示された場合は、お使いのオペレーティング・システムのインストール・ガイドを見直してください。
バリデーターセットアップ
Elixirは、バリデータを実行する際には、新しいウォレットを使用することを推奨しています。Testnet-1バリデーターを実行した場合は、同じウォレットをそのまま使用してもかまいません。Metamaskでは、右上の “My Accounts “アイコンをクリックし、”+ Create Account “をクリックします。
セキュリティを考慮し、このウォレットはテストネットバリデーターの実行以外には決して使用しないでください。
アカウントを作成したら、アドレスと秘密鍵のコピーを取得します。Metamaskでは、elipsisメニューからAccount Detailsをクリックし、”Export private key”をクリックすることで秘密鍵を取得できます。Testnet-1の秘密鍵とアドレスを使用する場合は、Testnet-1の
Dockerfileに保存されている値を使用してください。
Dockerfileのダウンロード
validator Dockerfileをダウンロードし、テキストエディタで開きます。前のステップで生成したウォレットアドレスと秘密鍵をテキストファイルに入力します。バリデータに名前を付けておくと、他のELXRホルダーが自分のステークを誰に委任すればいいかわかるようになります。
Dockerイメージのビルド
Dockerfileをダウンロードしたディレクトリで以下のdockerコマンドを実行して、バリデータイメージをビルドします。
docker build . -f Dockerfile -t elixir-validatorバリデーターを開始する
以下の docker コマンドを実行してバリデータを実行します。
docker run -it --name ev elixir-validatorオプションで、バリデータが起動時に自動的に実行されるように設定することもできます。
docker run -d --restart unless-stopped --name ev elixir-validatorバリデーターは 20 秒以内に起動し、ネットワークへの注文提案の送信を開始します。
バリデータとしてウォレットを登録
ウォレットに接続したブラウザでElixir Network Dashboardを開きます。Metamask に接続し、Goerli ネットワークに切り替えます。ELXR をクレームします。Goerli ETHが必要な場合は、私たちのDiscordサーバーで要望することができます。Testnet-1のオペレーターは、ネットワークガス料金を支払うのに十分な量のGoerli ETHエアドロップを受け取っています。
ELXRトークンを受け取ったら、そのトークンをステークする必要があります。100～1000ELXRの任意の金額で構いません。
次に、バリデータを登録します。登録（enroll）ボタンをクリックし、前のステップでバリデータを起動するために使用したウォレットアドレスを入力します。このトランザクションが確認されたら、リーダーボードをチェックし、アドレスが登録されていることを確認します。次に、有効な注文が処理されていることを、メトリクスのページで自分のバリデータを見つけて確認します。
最新バージョンへのアップグレード/インストール
バリデータの最新バージョンを随時プルする必要があります。そのためには、Dockerfileのあるディレクトリでコマンドラインを開き、以下のコマンドを実行してください。
docker kill ev
docker rm ev
docker pull elixirprotocol/validator:testnet-2
docker build . -f Dockerfile -t elixir-validatorそしてdockerコマンドを再実行してバリデータを起動します。
docker run -it --name ev elixir-validatorまたは
docker run -d --restart unless-stopped --name ev elixir-validator自身のバリデーターメトリックスの追跡
ユーザーは、Elixir Network Dashboardにアクセスして、自分のバリデーターのステータスを確認することができます。リーダーボードには登録されているすべてのバリデーターのリストが表示され、メトリックスページには個々のバリデーターの有効注文数と無効注文数が表示されます。
監査
Elixir ProtocolのSolidityとCosmWasmコントラクトは、Trail of Bitsによって監査されています。レポートはこちらでご覧いただけます。
https://github.com/trailofbits/publications/blob/master/reviews/2023-09-elixir-securityreview.pdf
バグバウンティ（報奨金）
Elixir は、Immunefi を通じてバグ報奨金プログラムを主催し、ユーザーエクスペリエンスを低下させたり、ユーザーに金銭的な影響を与える可能性のあるバグに注意するようコミュニティに奨励しています。バグ報奨金についてはこちらをご覧ください。
ソーシャル（SNS）
Elixirのコミュニティと繋がりましょう！
- Webサイト: https://elixir.finance/
- Twitter: https://twitter.com/ElixirProtocol
- Discord: https://discord.gg/elixirprotocol
- Telegram: https://t.me/elixirprotocol
