# Uniswapのドキュメントを読んでみよう！ > Uniswapには、以下のようないくつかの領域が存在します。 - URL: https://cardene.dev/articles/b18277a7b568a5 - 公開日: 2023-08-24 - 更新日: 2023-08-24 - トピック: Blockchain - タグ: solidity, ethereum, smartcontract, defi # はじめに 初めまして。 **CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。 https://cryptogames.co.jp/ 代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。 https://cryptospells.jp/ 今回は**Uniswap**について公式ドキュメントを翻訳・補足しながらまとめていきたいと思います。 公式ドキュメントは以下になります。 https://docs.uniswap.org/concepts/overview # Uniswap概要 **Uniswap**には、以下のようないくつかの領域が存在します。 ## Uniswap Labs **Uniswap**プロトコルとウェブインターフェースを開発した会社です。 **Uniswap Labs**は、**Uniswap**プロトコル全体の開発を行っています。 ## Uniswapプロトコル **Uniswap**プロトコルは、永続的でアップグレード不可能なスマートコントラクトの集まりです。 これらのスマートコントラクトは、自動的なマーケットメーカーを作成し、ユーザーが互いにトークンを交換したり、マーケットメイキングを行ったりできるよう支援します。 これはEthereumブロックチェーン上で行われます。 **Uniswapインターフェース:** **Uniswap**インターフェースは、**Uniswap**プロトコルと手軽に対話するためのウェブベースのツールです。 このインターフェースを通じて、ユーザーはトークンをスワップしたり、流動性を提供したりできます。 ただし、これは**Uniswap**プロトコルとのやり取りの1つの方法に過ぎません。 他にも方法があります。 **Uniswapガバナンス:** **UNI**トークンによって可能になる**Uniswap**プロトコルを統治するためのガバナンスシステムです。 ユーザーは**UNI**トークンを使ってプロトコルの運営に参加できます。 これらの要素が**Uniswap**エコシステムの一部であり、**Uniswap**プロトコルを理解し、活用する際に重要な役割を果たしています。 エンジニアとして、**Uniswap**プロトコルや関連する要素について深く理解することで、さまざまなブロックチェーン関連の開発や取引に貢献できる可能性があります。 # Uniswapプロトコル ## はじめに **Uniswap**プロトコルは、Ethereumブロックチェーン上での仮想通貨（**ERC20**トークン）の交換を行うための仕組みです。 このプロトコルは、ピアツーピアのシステムを採用しており、ユーザー同士が直接トークンを交換できるよう設計されています。 :::message **ERC20**については以下を参照してください。 ::: https://chaldene.net/erc20 このプロトコルは、永続的でアップグレードできないスマートコントラクトの集まりで構成されています。 スマートコントラクトは一度デプロイされると変更できず、その性質から検閲に対する耐性やセキュリティを高めています。 また、ユーザー自身がトークンを管理し、取引を行うことができる自己保管の原則に基づいています。 このプロトコルは、信頼されていない中間組織がない状態で機能することを重視しています。 これにより、アクセスを制限する可能性のある中間組織による制約を排除し、開かれた取引環境を提供しています。 **Uniswap**プロトコルには、現在3つのバージョンが存在します。 **V1**と**V2**はオープンソースであり、GPLライセンスに基づいて提供されています。 **V3**もオープンソースで、わずかな変更が加えられています。 いずれのバージョンも、Ethereumブロックチェーンが継続的に存在する限り、永続的に機能します。 このプロトコルは、ユーザー同士が直接トークンを交換するための仕組みを提供し、セキュリティや自己管理といった重要な価値を重視しています。 ブロックチェーン技術の力を借りて、安全で信頼性のあるトークン交換を実現する手段として、**Uniswap**プロトコルは広く活用されています。 ## Uniswapプロトコルと従来の市場との比較 **Uniswap**プロトコルは、従来の市場とどのように異なるのかを理解するために、まず2つの観点を見ることが役立ちます。 1つ目は、自動マーケットメーカー（**AMM**）デザインが従来の中央集中型の注文ブック型取引所とどのように異なるか、2つ目は、許可制のシステムと比較して許可なくアクセスできるシステムの違いです。 ### 注文ブックとAMMの比較 従来の市場では、中央集中型の注文ブック方式が一般的に使用されています。 この方式では、買い手と売り手が価格ごとに注文を出し、需要と供給のバランスに応じて取引が進行します。 これは、株式取引をする際に証券会社を通じて行う注文ブックシステムと似たような仕組みです。 **Uniswap**プロトコルは、自動マーケットメーカー（**AMM**）というアプローチを採用しています。 これは、注文ブックの代わりに2つの資産の流動性プールを使用します。 1つの資産をもう1つの資産と交換する際に、それらの資産の相対価格が変動し、新しい市場価格が決まります。 ここでは、買い手や売り手は特定の注文を待つのではなく、プールと直接取引を行うことになります。 自動マーケットメーカーと従来の注文ブック方式の違いや長所と短所に関する研究が進行中です。 ### 許可なしシステム もちろんです。Uniswapプロトコルの許可なしシステムと変更不可能なデザインについて、もう少し詳しく説明します。 #### 許可なしシステムのデザイン **Uniswap**プロトコルは、従来の金融市場とは異なり、許可なしのデザインを採用しています。 これは、誰もが自由にプロトコルのサービスを利用できることを意味します。 制限された特定の人や組織だけがアクセスできるということはありません。 例えば、誰もがトークンを交換したり、流動性を提供したり、新しい取引ペアを作成したりできます。 従来の金融サービスでは、地域や富の状態、年齢などに基づいてアクセスが制限されることが多いですが、**Uniswap**プロトコルは誰でも自由に参加できるオープンな環境を提供します。 #### 変更不可能なデザイン **Uniswap**プロトコルは、変更不可能なデザインを持っています。 つまり、一度デプロイされたプロトコルはアップグレードできない状態です。 誰もがコントラクトを一時停止させたり、取引の実行を元に戻したり、プロトコルの振る舞いを変更することはできません。 このデザインは、安定性と信頼性を確保するためのものであり、プロトコルの動作に変更を加えることなく、誰もが同じ条件下で利用できることを保証します。 **Uniswap Governance**は、スワップ手数料の一部を特定のアドレスに割り当てる権限を持っていますが、これは予めすべての参加者に知られており、割合は`10%`から`25%`の範囲に制約されています。 これにより、プロトコルの変更が適切に管理され、乱用を防ぐ仕組みが確立されています。 **Uniswap**プロトコルの許可なしと変更不可能なデザインにより、誰もが公平な条件で金融サービスにアクセスできる未来が実現されています。 ## 詳しい情報 ### 詳細情報の入手方法 AMMの経済学、ゲーム理論、最適化研究などに関する情報を入手するには、**Uniswap**の[リサーチページ](https://docs.uniswap.org/concepts/research)をチェックしてみてください。 そこでは、さまざまなテーマについての研究が提供されています。 **Uniswap**プロトコルの背後にある理論や仕組みを深く理解するために役立つ情報が含まれています。 ### V3の新機能について **Uniswap**プロトコルの**V3**では、AMMデザインを拡張し洗練させる新機能が導入されています。 これに関する詳細情報は、**V3**の[コンセプトページ](https://docs.uniswap.org/concepts/protocol/concentrated-liquidity)を参照してください。 **V3**に関連する最新の概念や機能について学ぶことができます。 これにより、**Uniswap**プロトコルの最新の状態について理解を深めることができます。 以上の情報源を通じて、Uniswapプロトコルに関するさまざまな側面や概念について深く学ぶことができます。 プロトコルの理解を深めて、関連する開発や取引に貢献できるようになります。 # プロトコルのコンセプト ## 集中流動性 ### はじめに **Uniswap v3**の魅力的なアイデアは、「**集中流動性（Concentrated Liquidity）**」です。 これは、特定の価格範囲内に流動性を集中させるという概念です。 以前のバージョンでは、流動性は価格曲線の`0`から無限までの範囲に均等に分散していました。 この均一な分布により、価格の範囲（`0`、`∞`）全体での取引が流動性を損なうことなく行えました。ただし、多くのプールでは、流動性の大部分がほとんど使用されていない状態でした。 たとえば、ステーブルコインのペアの場合、2つの資産の相対価格がほぼ一定です。 通常の価格範囲外の流動性はあまり利用されていませんでした。 例えば、**v2**の**DAI/USDC**ペアでは、`$0.99`から`$1.01`の範囲での取引に全体の資本の約`0.50%`しか使用されず、LP（流動性プロバイダー）にとってもっとも取引量が多く、最も手数料を稼げる価格範囲となっていました。 **v3**では、流動性プロバイダーは、（`0`、`∞`）よりも狭い価格範囲に資本を集中させることができます。 例えば、ステーブルコイン/ステーブルコインのペアの場合、LPは資本を`$0.99`から`$1.01`の範囲に集中させることができます。 その結果、トレーダーには中間価格周辺でより深い流動性が提供され、LPは資本を使ってより多くの取引手数料を稼ぐことができます。 この狭い価格範囲に流動性を持たせることを「**ポジション**」と呼びます。 LPは1つのプールに対して複数の異なるポジションを持つことができ、各LPの選好に応じた独自の価格曲線が作成されます。 ### アクティブな流動性 アクティブな流動性について理解するために、以下のポイントを考えてみましょう。 #### 1. 価格範囲とポジション **Uniswap v3**では、流動性プロバイダー（LP）は特定の価格範囲内に流動性を集中させることができます。 つまり、LPは価格の範囲を指定し、その範囲内に流動性を割り当てることができるのです。 これを「**ポジション**」と呼びます。 #### 2. 価格の変動とアクティブな流動性 資産の価格は常に変動します。 もし価格がLPが指定した価格範囲を超えて変動すると、そのポジションの流動性は「**非アクティブ**」となり、その範囲内での取引手数料を稼ぐことはできなくなります。 #### 3. ポジションの調整と手数料の獲得 資産の価格が特定のポジションの価格範囲内に戻ると、そのポジションの流動性は再び「**アクティブ**」になります。 これにより、LPは再びその範囲内で取引手数料を獲得できるようになります。 #### 4. 自由なポジションの作成 LPは複数のポジションを作成することができます。 それぞれのポジションには異なる価格範囲が指定されます。 これにより、市場の状況やLPの戦略に合わせて流動性を調整することが可能です。 集中流動性の仕組みにより、市場が自然な形で価格範囲ごとに流動性を配分し、最適な状態を見つけることができるようになります。 このシステムによって、LPは最も効果的な方法で手数料を稼ぎつつ、市場参加者に深い流動性を提供することができるのです。 ### ティック 「**Ticks（ティック）**」は、**Uniswap v3**の特徴である集中流動性を実現するために使用される、価格スペースを分割するための境界です。 価格スペース内のティックは、価格の離散的な範囲を示す境界です。 価格スペース全体を均等な間隔で区切っており、1つのティックの増減が価格全体で`0.01%`の変動を表します。 ![ティックの図](https://storage.googleapis.com/zenn-user-upload/52673ba56061-20230823.png) :::message 上記の棒グラフのようなものが**Ticks（ティック）** です。 特定の価格ポイントを示していて、棒グラフの塊みたいになっています。 ::: ![ティックの図](https://storage.googleapis.com/zenn-user-upload/13314f20de41-20230823.png) :::message 拡大してみるとより分かるかもしれないです。 上の図だと、`435`~`440`という範囲で若干価格に差が出ていますね。 ::: ティックは流動性ポジションの境界として機能します。 ポジションを作成する際に、プロバイダーはそのポジションの上限ティックと下限ティックを選択する必要があります。 スワップが発生すると、プールコントラクトはその時点でのティック間隔内で取引に利用可能な流動性を活用します。 これによって、交換から出て行くアセット（アウトバウンドアセット）と交換で入ってくるアセット（インバウンドアセット）が交換されます。 具体的には、プール内の流動性を使って、あるトークンを売って別のトークンを取得します。 そして、次のティックに到達すると、プールコントラクトは新しいティックに切り替わります。 この切り替えによって、前のティックにおいて非アクティブだった流動性が活性化され、新しいティックの境界として機能します。 これによって、価格帯ごとに流動性が効率的に活用され、スワップが連続的に行われる仕組みが実現されます。 各プールには同じ数のティックがありますが、実際にはアクティブなティックは一部だけです。 **Uniswap v3**スマートコントラクトの性質により、ティックの間隔はスワップ手数料と直接的に関連しています。 低い手数料層では、アクティブなティックがより細かく設定され、高い手数料層ではアクティブなティックの間隔が相対的に広くなります。 非アクティブなティックはスワップ中のトランザクションコストに影響を与えませんが、アクティブなティックを越える際には、そのティックを境界とする新しいポジション内の流動性が活性化されるため、トランザクションのコストが増加します。 特にステーブルコインのペアなど、効率的な流動性が求められる場合には、ティックの間隔を狭く設定することで、スワップ時の価格への影響を減少させることができます。 これにより、ステーブルコインのスワップがより良い価格で実行される可能性が高まります。 ティック間隔と手数料レベルの関連性の詳細については、[ホワイトペーパー](https://uniswap.org/whitepaper-v3.pdf)を参照してください。 ## 手数料 ### スワップ手数料 スワップ手数料は、トークンのスワップが行われた際に、そのスワップが発生した価格の範囲内の流動性に比例して分けられます。 つまり、流動性プールに提供されているトークンの量や価格範囲に応じて手数料が分配される仕組みです。 もしスポット価格が特定のポジションの価格範囲から外れると、そのポジションに紐づく流動性は非アクティブとなり、その範囲外でのスワップによる手数料は発生しません。 しかし、スポット価格が再びそのポジションの価格範囲に戻ると、そのポジションの流動性は再びアクティブとなり、スワップによる手数料が再び生成される仕組みです。 以前の**Uniswap**のバージョンでは、スワップ手数料は自動的に再投資されていましたが、**Uniswap v3**ではそれが変更されました。 スワップ手数料はプールから別々に集められ、所有者が手数料を受け取るためには手動で引き出す必要があります。 この変更により、流動性プロバイダーが手数料の利用方法を柔軟に選択できるようになりました。 ### プール手数料 **Uniswap v3**では、異なるスワップ手数料を持つ複数のプールが各トークンペアに導入されています。 流動性プロバイダーは、最初に3つの手数料レベル（`0.05%`、`0.30%`、`1%`）でプールを作成できます。 また、**UNI**ガバナンスによって追加の手数料レベルが将来的に追加される可能性もあるのです。 過去にも、2021年11月に行われたガバナンス提案によって`0.01%`の手数料レベルが導入されました。 過去には、異なる手数料オプションによるインセンティブの調整は難しく、ペアを別々のプールに分割することは実現できませんでした。 このような分割は流動性の分散化の問題を引き起こし、ペアごとの流動性が低下し、スワップ時の価格影響が増加する結果を招いていました。 :::message 以前の**Uniswap**のバージョンでは、異なるスワップ手数料の選択肢を提供することで、流動性プロバイダーとトレーダーのインセンティブを調整することが難しかったです。 例えば`1%`の手数料を選択する流動性プロバイダーが、より多くの収益を得る一方で、トレーダーは高い手数料を支払うことになるためです。 このような場合、流動性プロバイダーとトレーダーの間でバランスを取るのが難しい状況が生じました。 **Uniswap v3**では、以前のバージョンとは異なる方法で流動性を管理し、流動性プールを設計しています。 この新しいアプローチにより、異なる手数料レベルを持つ複数のプールを作成することができます。 例えば`0.05%`、`0.30%`、`1%`の手数料レベルのプールが作成できます。 これにより、各資産ごとに最適な流動性が提供されるようになります。 以前は、1つのプールに異なる手数料レベルを導入することが難しかったため、資産間で適切な流動性の提供が難しかったのです。 しかし、新しい集中流動性の仕組みにより、異なる手数料レベルを持つ複数のプールを作成できるようになり、それぞれのプールが異なる手数料で取引を行うことが可能になりました。 このアプローチにより、流動性プロバイダーとトレーダーの双方の利益をバランスよく考慮したプールの設計が実現されました。 つまり、流動性プロバイダーは自分の資産を適切な手数料レベルのプールに提供することで適切な報酬を得ることができ、一方、トレーダーは異なる手数料レベルを選ぶことで、自分のニーズに合った取引を行うことができるようになったのです。 この新しいプールの設計は、以前の問題を解決し、トレーダーと流動性プロバイダーの双方にとってより柔軟で効率的な取引環境を提供することができるようになりました。 ::: 集中流動性の導入により、総流動性と価格影響の関係が切り離されました。 これにより、ペアを複数のプールに分割することが実現可能になりました。 以前は`0.30%`のスワップ手数料で満足していなかった資産に対しても、プールの機能性が向上するアプローチが可能となりました。 ### 適切なプール料金を見つける さまざまな種類の資産（例えば、ステーブルコインやエキゾチックな資産など）は、その性質や市場の特性に応じて、適切な手数料レベルを選ぶ傾向があります。 スワッパーや流動性プロバイダには、それぞれ異なる目標やインセンティブが存在するため、彼らのニーズやインセンティブに合わせて、適切な手数料レベルを選ぶことが重要です。 #### 1. 低ボラティリティ資産の手数料レベル ステーブルコインなどの低いボラティリティを持つ資産は価格リスクが低いため、流動性プロバイダーは最低の手数料レベルに集まる可能性が高いです。 スワップする人々も、できるだけ**1：1**に近い実行価格を得るためにこの手数料レベルを選ぶでしょう。 #### 2. エキゾチックな資産や取引の少ない資産の手数料レベル 逆に、エキゾチックな資産や取引が少ない資産は、流動性プロバイダーが保持期間中のコストリスクを相殺するため、高い手数料レベルに向かう可能性があります。 したがって、異なる種類の資産は、その特性や取引頻度によって、適切な手数料レベルに収束する傾向があるのです。 これにより、スワッパーや流動性プロバイダーの双方にとってバランスの取れたインセンティブが生まれ、プールの適切な運営が支えられます。 :::message **エキゾチックな資産** 一般的な金融市場や取引所で取引されることが比較的少なく、通常の資産とは異なる特性やリスクを持つ金融商品や資産を指す言葉です。 これらの資産は、通常の株式や債券、通貨とは異なる性質を持つことがあり、市場での流動性が低い場合があります。 エキゾチックな資産は、投資家や取引者にとって新しいチャンスやリスクを提供することがありますが、その一方で価格の変動が大きく、リスクが高い場合もあります。 エキゾチックな資産の例には、以下のようなものがあります。 1. デリバティブ商品 - オプション、先物、スワップなど、基本的な資産に関連する派生商品。 3. クオンツ商品 - 数学的モデルやアルゴリズムに基づいて設計された商品。 5. レバレッジ型ETF（上場投資信託） - レバレッジ効果を利用して、基本的な指数の変動を上回るリターンを追求するETF。 7. イルキッド・アセット - 取引が難しい、または取引が制限されている非流動性の高い資産。 エキゾチックな資産は、専門的な知識やリスク管理が必要な場合があるため、投資家や取引者は慎重に検討し、適切なリサーチを行う必要があります。 ::: ### プロトコル手数料 **Uniswap v3**では、プロトコル手数料というものがあります。 この手数料は、**UNI**ガバナンスによって有効にすることができます。 **Uniswap v2**と比べて、**Uniswap v3**では、スワップ手数料の一部をプロトコルに送る割合を選ぶ際に、**UNI**ガバナンスがより柔軟な選択肢を持っています。 具体的には、取引手数料の一部をプロトコルに寄付する割合を調整することができます。 詳細な内容については、[ホワイトペーパー](https://uniswap.org/whitepaper-v3.pdf)に詳しく記載されていますので、そちらをご参照いただけます。 ## オラクル **オラクル**という概念について馴染みがない場合は、まず[Ethereum Foundationのオラクル概要](https://ethereum.org/en/developers/docs/oracles/)をチェックしてみてください。 :::message オラクルとは、ブロックチェーン上で実行されるスマートコントラクトが、現実世界のデータや情報を取得するための仕組みです。 ブロックチェーン自体は閉じられた環境で動作するため、外部のデータへアクセスすることが難しいですが、オラクルを通じて外部からのデータを取り込むことが可能となります。 例えば、天候情報や株価などの現実世界のデータをスマートコントラクトに組み込む際に、オラクルを使用します。 オラクルは信頼性が求められる重要な役割を果たし、正確なデータを提供することが求められます。 ::: 全ての**Uniswap v3**プールは、オラクルとして機能することが可能であり、過去の価格や流動性のデータにアクセスすることができます。 これによって、さまざまなオンチェーンのユースケースが実現できるようになります。 過去のデータは、観測結果の配列として保存されます。 最初は、各プールは単一の観測結果しか記録せず、ブロックが進むにつれてそのデータを更新していきます。 そのため、ユーザーが過去のデータにアクセスできる期間には制限があります。 しかし、トランザクション手数料を支払うことで、追跡する観測結果の数を増やすことができます（最大`65535`まで）。 これにより、データの利用可能な期間が約9日以上に延長することが可能です。 価格や流動性の履歴をプールコントラクト自体に直接保存することにより、呼び出し側のコントラクトで論理エラーが発生する可能性が大幅に減少し、履歴データを保持する必要がないため、統合コストが削減されます。 記録できるデータの最大長さが十分に大きいため、呼び出し側のスマートコントラクトは比較的低コストで、任意の時間範囲内での加重平均を計算することができます。 これにより、オラクル価格の操作が困難になります。 :::message 具体的に言うと、プール内の価格や流動性の履歴データを直接保持しているため、特定の期間内での平均価格を簡単に計算することができるのです。 このデータは単純な数値の連続ではなく、時間に対する加重平均として格納されています。 呼び出し側のコントラクトは、プール内のこのデータを利用して、特定の時間範囲内での価格の変動を正確に把握できます。 この機能によって、オラクル価格の操作が困難になります。 なぜなら、呼び出し側のコントラクトは正確な加重平均を容易に計算できるため、価格の不正な操作や操作の透明性の欠如が検出される可能性が高くなるからです。 これにより、安全で信頼性の高いオラクルデータを提供することができます。 ::: ### 観測 `Observation`は以下の形式をとります。 ```solidity struct Observation { // the block timestamp of the observation uint32 blockTimestamp; // the tick accumulator, i.e. tick * time elapsed since the pool was first initialized int56 tickCumulative; // the seconds per liquidity, i.e. seconds elapsed / max(1, liquidity) since the pool was first initialized uint160 secondsPerLiquidityCumulativeX128; // whether or not the observation is initialized bool initialized; } ``` :::message `Observation`はプール内の特定の時点での情報を格納する構造体です。 - `blockTimestamp` - オブザベーションのブロックタイムスタンプ。 - このオブザベーションが記録されたブロックのタイムスタンプです。 - `tickCumulative` - ティックアキュムレータとも呼ばれ、ティックと時間の経過に関連した値。 - ティックは価格の指標であり、プールが初めて初期化されてからの経過時間によるティックの累積を表します。 - `secondsPerLiquidityCumulativeX128` - 流動性ごとの経過時間を示す値。 - この値は、プールが初めて初期化されてからの経過時間を最大値で割ったものであり、流動性が`1`以上の場合に影響を受けます。 - 上記の値に128を掛けて表現されています。 - `initialized` - オブザベーションが初期化されているかどうかを示すブール値。 - 初めてオブザベーションが生成されたときに`true`に設定されます。 ::: **v3**プールでは、観測結果は`observations`メソッドを使って取得できます。 ただし、これはオラクルデータを利用する推奨される方法ではありません。 代わりに、`observe`を利用することをおすすめします。 `observe`メソッドを呼び出すとき、呼び出し元は、過去の秒数を含む配列を渡す必要があります。 この配列には、どの時刻の観測結果を取得するかを示す秒数が含まれます。 ただし、指定された各時刻は、保存されている最も古い観測結果よりも新しい時刻（または同じ時刻）である必要があります。 なお、指定された時刻が観測結果が記録されたブロックと正確に一致しない場合でも、観測結果を自動的に調整してくれます。 これにより、手動で補間する必要がなくなります。 そのため、`observations`メソッドに比べて`observe`メソッドを使用することが推奨されます。 また、オラクルは最大で1つのブロックごとに更新されるため、`observe`メソッドを秒数**Ago**の値を`0`で呼び出すと、最も直近に書き込まれた観測結果が返されます。 これは、現在のブロックの開始時点と同じかそれよりも古い時刻である場合に該当します。 ### ティックアキュムレーター ティックアキュムレータは、特定の時間点でのアクティブなティックの累積合計を記録します。 この値は徐々に増加し、現在のティックの値によって秒ごとに増加していきます。 一定の期間内の平均ティックを算出するには、呼び出し元は2つの連続した観測結果を取得し、それらの値の差を求めて、それらの間の経過時間で割る必要があります。 :::message 一定の期間内での平均ティックを算出する際の具体的な手順を説明します。 想定するシナリオは、**Uniswap v3**のプールがある通貨ペアの価格をトラッキングする場面です。例えば、24時間の期間内での平均ティックを計算するケースを考えてみましょう。 1. **観測結果の取得** まず、24時間前と現在の2つの観測結果を取得します。 これにより、指定された期間内の価格変動を分析することができます。 2. **値の差を計算** 2つの観測結果の値を引き算して、価格の変動を計算します。 例えば、24時間前の観測値が`100`で現在の観測値が`120`であれば、価格の変動は`20`となります。 3. **経過時間の計算** 24時間の期間内の経過時間を計算します。 これにより、価格変動の速さや変動率を正確に評価できます。 例えば、24時間は`1,440`分または`86,400`秒です。 4. **平均ティックの計算** 値の差を経過時間で割ることで、一定期間内の平均ティックを算出します。 例えば、値の差が`20`で経過時間が`86,400`秒ならば、平均ティックは`20 / 86,400 ≈ 0.00023`となります。 このようにして、特定の期間内での平均ティックを計算することができます。 **Uniswap v3**では、この手法を使用してティックアキュムレータを活用し、価格の変動を正確に評価することが可能です。 ::: また、ティックアキュムレータからは**TWAP（Time-Weighted Average Price）** を計算する方法も[ホワイトペーパー](https://uniswap.org/whitepaper-v3.pdf)で説明されています。 なお、算術平均ティックを使用して価格を算出することは、幾何平均価格に対応することに注意してください。 :::message 幾何平均と算術平均は、統計や数学において異なる方法で平均値を計算するための手法です。 これらは、特に金融市場や経済において価格や指数の計算に使用されます。 1. **算術平均（Arithmetic Mean）** 算術平均は、一連の数値を合計してその個数で割ることによって計算されます。 以下の式で表されます。 ``` 算術平均 = (数値1 + 数値2 + ... + 数値n) / n ``` 算術平均は個々の数値の合計を平均値として表すため、一般的な合計の平均と言えます。 一方で、価格データの計算には幾何平均が使用されることがあります。 2. **幾何平均（Geometric Mean）** 幾何平均は、一連の数値をすべて掛け合わせ、その個数でn乗根を取ることによって計算されます。 以下の式で表されます。 ``` 幾何平均 = (数値1 * 数値2 * ... * 数値n)^(1/n) ``` 幾何平均は、比率や倍率を考慮する場合に特に有用です。 金融市場において、価格や指数の変動率を正確に反映するために幾何平均が使用されることがあります。 価格の変動率が等価であるように計算されるため、投資家やトレーダーが実際の市場の変動をより正確に理解できます。 **Uniswap v3**では、ティックアキュムレータを使用して平均ティックを計算し、それを価格に変換する際に幾何平均を使用することで、価格データをより適切に表現しています。 このようなアプローチは、価格の変動性を考慮した正確なデータ解釈を可能にするため、金融市場における価格の理解や予測に役立つのです。 ::: ティックアキュムレータの具体的な使用方法については、OracleLibraryを参照してみてください。 このように、ティックアキュムレータはUniswap v3のオラクル機能を支える重要な要素であり、価格や流動性のデータを効果的に活用するための手段となっています。 ### リキッドティーアキュムレータ リキッドティーアキュムレータは、**Uniswap v3**のプール内での流動性の変動を追跡するための仕組みです。 具体的には、リキッドティーアキュムレータは、観測時点での**秒数 / 範囲内の流動性の値**を記録します。 この値は、プール内の流動性の量とその有効な範囲を示します。 そして、このリキッドティーアキュムレータの値は時間の経過とともに単調に増加し、**秒数 / 範囲内の流動性の値**が秒ごとに加算されていきます。 一定期間内の調和平均流動性を導出するには、呼び出し元は2つの連続した観測結果を取得し、それらの値の差を求めます。 その後、経過時間をこの差で割ることで、調和平均流動性を計算します。 この手法によって、特定期間内の流動性の変動の評価が可能になります。 [ホワイトペーパー](https://uniswap.org/whitepaper-v3.pdf)には、この手法による**TWAL（Time-Weighted Average Liquidity）** の計算方法が詳しく説明されています。 この方法を使用することで、**Uniswap v3**のプール内の流動性の変動を評価し、トレードの際の最適なタイミングや条件を判断するのに役立ちます。 :::message 例えば、ある**Uniswap v3**プールのリキッドティーアキュムレータの値が次のように増加しているとします（時間単位は秒）。 - 100秒後: `5000` - 200秒後: `7000` - 300秒後: `10000` ここで、特定の期間内（例えば`100`秒から`300`秒まで）の調和平均流動性を計算したいとします。 この期間内でのリキッドティーアキュムレータの増加量は、**10000 - 5000 = 5000**です。 経過時間は**300秒 - 100秒 = 200秒**です。 調和平均流動性は、増加量（`5000`）を経過時間（**200秒**）で割った値です。 ``` 調和平均流動性 = 5000 / 200 = 25 ``` この値が一定期間内の調和平均流動性を表します。 この値を使って、**Uniswap v3**プール内での流動性の変動を評価することができます。 この評価により、特定の時間帯での流動性の強弱や需要の変化を把握し、トレードの際の最適な戦略を考える手助けとなります。 このように、リキッドティーアキュムレータと調和平均流動性を使用することで、**Uniswap v3**のプール内の流動性の変動を定量的に評価できるようになります。 ::: :::message 調和平均流動性の値が大きいほど、その期間内での平均的な流動性が高かったことを示します。 具体的には、調和平均は各値の逆数の平均を取るため、流動性の大きな値が含まれると平均値が上昇します。 調和平均は、個々の値が大きいほど影響を受けやすい性質を持ちます。 つまり、流動性が高い時間帯における値の増加が、平均値に大きな影響を与えると言えます。 このため、調和平均流動性が大きい場合、その期間内での流動性が比較的安定して高かったことが示唆されます。 逆に、調和平均流動性が小さい場合は、その期間内での流動性が低かったか、変動が大きかった可能性があります。 このように、調和平均流動性の値は、プール内の流動性の変動を評価する際の指標として活用されます。 要するに、調和平均流動性の値が大きいほど、その期間内での平均的な流動性が高かったことを示し、価格の変動や需要の変化が比較的少なかったことを示唆します。 一方で、小さい値は流動性の低さや変動の大きさを示す可能性があります。 ::: **⚠️注意** 範囲内流動性アキュムレータは注意して使用する必要があります。 なぜなら、現在のティックと現在の範囲内流動性が完全に無相関である可能性があるため、同じ期間内でプールの算術平均ティックと調和平均流動性を取ることで、別のプールと比較して誤った特性を示すことがあるからです。 例えば、プールAの現在のティックが`5`秒間`0`であり、`5`秒間`100`である場合、ティックアキュムレータは`50`になります。 同じ期間内で、範囲内流動性が`5000`と`50`だった場合、調和平均流動性は約`99`になります。 これに対して、同じ資産からなるプールBでは、ティックが`50`であり、範囲内流動性が約`99`の場合を考えてみましょう。 アキュムレータの値は同じになりますが、基本的な挙動はもちろんまったく異なります。 つまり、同じアキュムレータの値でも、実際のプールの特性は異なることがあるため、注意が必要です。 現在のティックの変動と範囲内流動性の変化が無相関の場合、アキュムレータの値だけではプール同士の比較が正確でないことに留意してください。 ### ティックから価格を導く まず、「**アクティブティック**」は、プールの現在の価格に最も近い下限ティックを指します。 プールが作成されると、各トークンはトークン0またはトークン1に割り当てられます。 これは、トークンの順番を固定し、相対的な評価やプールのロジックに使用するためのものです。 トークンがトークン0またはトークン1であるかどうかは、その価値には関係ありません。 資産価格を導出する際には、トークン0（例えば、**WETH**）の価格をトークン1（例えば、**USDC**）に対してどのように表現するかが重要です。 具体的な手法として、ティックから導き出されるティック価格を使います。 例として、**WETH / USDC**プールでの価格導出を考えてみましょう。 ある時点での`tickCumulative`が**[70,000、1,070,000]** というデータがあり、観測間の経過時間は`10`秒です。 まず、アキュムレータ値の差（`1,070,000 - 70,000 = 1,000,000`）を計算し、経過時間で割って平均ティックを導出します（`1,000,000 / 10 = 100,000`）。 次に、このティック値を使ってトークン1（**USDC**）の価格をトークン0（**WETH**）に変換します。 ``` 公式p(i) = 1.0001**i ``` （[ホワイトペーパー](https://uniswap.org/whitepaper-v3.pdf)の6.1を参照） を使用して計算します。 ``` 1.0001**100,000 ≅ 22015.5 USDC / WETH ``` ティックは符号付き整数であるため、トークン0とトークン1の価値が逆転する場合、負のティック値が返されることに注意してください。 この方法を使用することで、プール内の異なるトークン間の価格を導出することができます。 ただし、ティック価格や導出方法を理解する際には、アクティブティックと範囲内流動性の関係にも留意する必要があります。 これによって、プール同士の比較が正確でない場合があることに注意してください。 ### レイヤー2のロールアップでのオラクル #### Optimism **Optimism**は、**Ethereum**のスケーリングソリューションの一つであり、トランザクションを高速に処理するために設計されています。 **Optimism**上では、各トランザクションが個別のブロックとして扱われます。 しかし、ここで重要なのは、これらのブロックの`block.timestamp`（ブロックのタイムスタンプ）は、**Sequencer**によって最後にL1（Ethereumメインチェーン）ブロックに取り込まれた時刻に基づいています。 これは大きく遅延するため、**Optimism**上のブロックのタイムスタンプは、実際のトランザクションが行われた時刻とは異なる可能性があります。 **Optimism**は、Ethereumのスケーリングソリューションの1つであり、トランザクションを高速に処理するために設計されています。 **Optimism**上では、各トランザクションが個別のブロックとして扱われます。 しかし、ここで重要なのは、これらのブロックの`block.timestamp`（ブロックのタイムスタンプ）は、**Sequencer**によって最後にL1（Ethereumメインチェーン）ブロックに取り込まれた時刻に基づいています。 これは大きく遅延するため、**Optimism**上のブロックのタイムスタンプは、実際のトランザクションが行われた時刻とは異なる可能性があります。 このタイムスタンプの遅延は、オラクル価格を提供する際に問題を引き起こす可能性があります。 なぜなら、オラクル価格は正確で信頼性のあるデータでなければならず、遅延したタイムスタンプに基づいて価格を導出すると、価格の悪意ある操作が容易になってしまうからです。 将来的には、**Optimism**のブロックタイムスタンプが高い精度で更新される可能性があり、その場合はオラクル価格の提供が改善されるかもしれません。 また、強制的な取り込みトランザクションによってオラクルのセキュリティが向上する可能性も考えられます。 しかし、現在の状況では、**Optimism**上でのオラクル価格の提供は適切ではないとされています。 ## レンジオーダー **Uniswap V3**において、カスタマイズ可能な流動性ポジションと片方のトークンの供給を活用することで、自動市場メーカー（AMM）の新しいスワッピングスタイルである「**レンジオーダー**」が実現しました。 :::message **片方のトークンの供給** ユーザーが流動性プールに対して一方のトークンの供給のみを行うことを指します。 従来のAMMでは、ユーザーはトークンAとトークンBの両方を流動性プールに供給する必要がありました。 しかし、**Uniswap V3**では片方のトークンの供給が導入されたため、ユーザーは自分が持っている一方のトークンだけを供給することができます。 このとき、供給したトークンの価格範囲に応じて自動的にもう一方のトークンが供給されます。 たとえば、ユーザーがETHを持っている場合、**Uniswap V3**のカスタマイズ可能な流動性ポジションにおいて、**ETH**だけを供給することができます。 すると、プロトコルは**ETH**の価格範囲に合わせて自動的に対応するトークンを供給します。 これによって、ユーザーは自分の持っているトークンだけを供給して流動性を提供することができるため、より柔軟な取引戦略を実現できるのです。 ::: 通常のオーダーブック市場では、誰でも簡単にリミットオーダーを設定できます。これは、特定の価格で資産を買ったり売ったりするオーダーで、そのオーダーは将来のある時点で執行されることを期待しています。 一方、Uniswap V3では、特定の価格範囲内で単一の資産を流動性として提供することで、リミットオーダーに似た動作を実現できます。 レンジオーダーも同様に、将来のある時点で実行されることを期待して設定されます。 オーダーのスポット価格が注文の範囲を越えた後に、対象の資産が引き出し可能になります。 通常の市場では、リミットオーダーに手数料が発生することがありますが、**Uniswap V3**のレンジオーダーメーカーは、オーダーが執行される過程で手数料を受け取ります。 これは、レンジオーダーが実際には通常のスワップではなく、流動性提供の一形態であるためです。 ### レンジオーダーの可能性 AMM（自動市場メーカー）の設計には、リミットオーダーのスタイルに関して、一部は再現可能である一方、他のスタイルは再現できない場合があります。 以下に、4つの「**レンジオーダー**」の例とそれに対応する従来の注文の例を説明します。 最初の2つは再現可能であり、後の2つは再現できません。 > 1つ重要な違いがあります。従来のリミットオーダーと異なり、「レンジオーダー」は、スポット価格が指定された価格範囲を越えて交差し、その後逆方向に戻って再び範囲内に交差する場合、オーダーは執行されないままになります。この間、流動性プロバイダーはLP手数料を稼ぐことができますが、目標が特定の対象資産で完全に退出することである場合、オーダーの状況を監視し、オーダーが執行されたら手動で流動性を取り除くか、サードパーティのポジションマネージャーサービスを使用して代理で引き出す必要があります。 :::message 要するに、「**レンジオーダー**」は、価格が指定の範囲を交差し、逆方向に動いた場合、注文が執行されない点に注意が必要です。 この間、LP手数料を得ることができますが、目的の対象資産で完全に退出したい場合、オーダーの状態を監視し、執行されたら手動で流動性を取り出すか、サードパーティのポジションマネージャーサービスを使用して代理で引き出す必要があります。 この違いを理解することで、自動市場メーカーの異なる注文タイプを効果的に活用できるようになります。 ::: #### 指値注文 > テイクプロフィットオーダーは、特定の価格に達した際に自動的に実行される注文のことを指します。例えば、あなたがETHを持っており、その価格が1,500 DAI / ETHであるとします。しかし、ETHの価格が1,600 DAI / ETHに達した際に自動的に売却したいと考えているとします。 この場合、あなたはテイクプロフィットオーダーを設定します。具体的には、ETHを1,600 DAI / ETHの価格で提供する注文を出します。これは、将来的にETHの価格が1,600 DAI / ETHに達した時点で、あなたの注文が自動的に実行され、ETHを1,600 DAI / ETHで売却する仕組みです。 :::message 指値注文の利点は、市場を常に監視する必要がないことです。 市場価格があなたが設定した目標価格に達した瞬間に、注文が自動的に実行されます。 これにより、市場変動を逃すことなく、効率的に売買を行うことができます。 ただし、1つ注意があります。 指値注文が執行されても、流動性プロバイダーが供給したトークンがすぐに完全に取り出せるわけではありません。 指値注文の執行状況を監視し、注文が実行された際にトークンを取り出す必要があります。 指値注文は注文が執行されるまでの間、LP（流動性プロバイダー）手数料を得ることができますが特定のトークンの流動性を取り出したい時、注文の状態を監視し、注文が執行されたら手動で流動性を取り出すか、サードパーティのポジションマネージャーサービスを使用して代理で引き出す必要があります。 ::: ![指値注文の図](https://storage.googleapis.com/zenn-user-upload/02531a860bfb-20230823.png) 引用: https://docs.uniswap.org/concepts/protocol/range-orders ![指値注文の図](https://storage.googleapis.com/zenn-user-upload/a257323e884f-20230823.png) 引用: https://docs.uniswap.org/concepts/protocol/range-orders #### 買い指値注文 > DAI / ETHプールの現在の価格は1,500 DAI / ETHです。あなたは次の市場の下落時に、ETHの価格が1,000 DAI / ETHまで下落し、その後反発することを予想しています。このため、DAIをETHにスワップする範囲注文（レンジオーダー）を、価格1,000 DAI / ETHで設定したいと考えています。この注文は、ETHを低い価格で購入したいという目的を持つものです。 :::message 具体的には、あなたは**DAI**を**1,000 DAI / ETH**の価格で提供する注文を出します。 この注文は、**ETH**の価格が**1,000 DAI / ETH**を下回る場合に、自動的に実行される仕組みです。 この時点で、提供した**DAI**は**ETH**と交換され、あなたは**ETH**を**1,000 DAI / ETH**の価格で購入します。 注文が実行されるタイミングは、**ETH**の価格が目標の**1,000 DAI / ETH**に達した時です。 市場の価格が下落して目標価格に到達すると、注文は自動的に実行され、**ETH**の購入が行われます。 ただし、注文が実行されるタイミングは重要です。 もし**ETH**の価格が**1,000 DAI / ETH**を下回った後に再び上昇してしまうと、注文は未実行のままとなります。 また、注文が執行されるまでの間、流動性プロバイダー（LP）として手数料を得ることができますが、注文が実行されない場合、手動で流動性を取り出すか、サードパーティのポジションマネージャーサービスを使用して代理で引き出す必要があります。 ::: **Uniswap V3**では、あるトークン同士のペア（例：**DAI**と**ETH**）を1つのプール内に配置します。 このプール内では、2つのトークンがスポット価格を中心に上下に分かれて配置されます。 具体的には、高価格のトークン（ここでは**ETH**を想定します）がスポット価格よりも上に位置し、低価格のトークン（ここでは**DAI**を想定します）がスポット価格よりも下に位置する構造です。 この特徴によって、リミットオーダーと呼ばれる取引スタイルが可能になります。 従来の取引所では難しかったリミットオーダースタイルを**Uniswap V3**では実現できるのです。 :::message 例えば、高価格のトークン（**ETH**）をスポット価格よりも低い価格（例：**1,000 DAI / ETH**）で購入したいと考える場合、**Uniswap V3**ではその注文を設定できます。 その結果、スポット価格が設定した価格（**1,000 DAI / ETH**）に達すると、自動的に注文が実行され、ETHが低い価格で購入されます。 ::: この分離された価格空間によって、市場の価格動向やトレード戦略に合わせて、特定の価格帯でのトークン取引を効率的に行うことができるようになります。 **Uniswap V3**は、トレーダーや流動性プロバイダーにとって、柔軟性のある取引環境を提供しています。 #### 買いストップ注文 > 特定の価格に達した際に、通常のスポット価格よりも高い価格で購入する注文のことを指します。例えば、あるトークンの価格が現在1,500 DAI / ETHであり、将来的に2,000 DAI / ETHに達することを期待している場合を考えてみましょう。 あなたは、ETHの価格が2,000 DAI / ETHに達したときに急騰し、その後3,000 DAI / ETHに上昇すると予測しています。そのため、ETHを購入する際には、価格が2,000 DAI / ETHに達したら自動的に購入されるような注文を出したいと考えています。 :::message しかし、このような買いストップ注文は**Uniswap V3**では実現できません。 なぜなら、**Uniswap V3**では価格空間が特定の範囲でアセットが分離されており、スポット価格を超える高い価格帯は別のアセット（この場合はETH）で表示されるからです。 そのため、スワップ元のトークンである**DAI**を提供しても、スポット価格を超える高い価格帯でのETHを得ることができません。 したがって、買いストップ注文を設定する際には、スワップ元のトークン（この場合は**DAI**）が提供できる価格範囲内に注目する必要があります。 スポット価格を超える高い価格帯では、スワップ元のトークンを提供しても取引が成立しないため、注意が必要です。 ::: #### 損切り注文 > 現在のDAI / ETHプールの価格が1,500 DAI / ETHです。あなたは、ETHの価格が1,000未満に下落し、その後さらに200まで急落することを予想しています。そのため、ETHを1,000 DAI / ETHの価格でDAIに交換するレンジオーダーを設定したいと考えています。 しかし、この操作は実現不可能な状況です。なぜなら、現在の価格が1,500 DAI / ETHであるため、スポット価格よりも低い価格帯（1,000 DAI / ETH未満）はDAIで価格が表示されるからです。言い換えると、ETHを1,000 DAI / ETHでDAIに交換するためには、1,000 DAI / ETHの価格でETHを提供する必要があります。しかし、この価格帯ではDAIと交換されるため、必要なETHを確保することができません。 :::message したがって、レンジオーダーを設定する際には、スワップ先のトークンである**DAI**が提供できる価格範囲内に注意が必要です。 現在の価格を基準に、交換したいトークン（**ETH**）がどの価格帯でDAIと交換されるかを理解することが大切です。これによって、実現可能なスワップ戦略を慎重に計画することができます。 ::: ### 手数料 **Uniswap V3**の流動性提供には手数料が関わってきます。 あなたが特定のペアの流動性を提供する際、そのペアを構成する両方のトークンに対して手数料が発生します。 先程の例で言うと、**ETH**と**DAI**のペアの流動性を提供する場合、**ETH**と**DAI**の両方に対して手数料が発生します。 具体的な例を挙げてみましょう。 あなたが**ETH**を**DAI**にスワップする場合、その取引に関連する手数料は**ETH**と**DAI**の両方で支払われます。 逆に、**DAI**を**ETH**にスワップする場合も同様です。 また、レンジオーダーを設定する際、どれだけ範囲を広くするかについては個人で決めることができます。 範囲を広く設定すると、範囲内で価格が変動した際に多くの手数料が発生する可能性がありますが、その一方でスポット価格が逆転して範囲が完了する前に注文が執行されないリスクが増えるということです。 ## スワップ ### はじめに スワップは**Uniswap**プロトコルとやり取りする際に最もよく使用される方法です。 ユーザーにとっては、スワップは簡単です。 例えば、ユーザーが持っている**ERC20**トークンと、それを交換したい別のトークンを選択します。 スワップを実行すると、現在所有しているトークンが、希望する別のトークンと比例した量に自動的に交換されます。 しかし、交換には少額の手数料がかかります。 この手数料は流動性提供者に支払われる仕組みです。 **Uniswap**プロトコルを使ったスワップは、誰でも自由に行うことができます。 つまり、ユーザーが自分のトークンを他のトークンと交換する際、煩雑な手続きや許可の取得などは不要です。 **⚠️注意** **Uniswap**プロトコルを介してウェブインターフェース（ウェブサイト）を使用してスワップする場合、追加の許可構造が導入される可能性があり、**Uniswap**プロトコルを直接使用する場合と比較して異なる動作が生じる可能性があります。 **Uniswap**プロトコルを使用したスワップは、通常のオーダーブック取引とは異なる方法です。 オーダーブック取引では、特定の順序で個別の注文が処理されるのに対して、**Uniswap**ではスワップは受動的な流動性プールに対して行われます。 この流動性プールには、トークンと資金が対応しています。 具体的には、ユーザーがスワップを行う際には、注文を待つ必要はありません。 代わりに、ユーザーが提供したトークンと資金が流動性プールに追加され、その資金とトークンのバランスがスワップ時に使用されます。 この方法によって、ユーザーは即座にトークンを交換することができます。 また、流動性プロバイダーは、自身が提供した資本に応じた手数料を受け取ることができます。 スワップ手数料は流動性プール全体で分配され、流動性プロバイダーに報酬として支払われます。 **Uniswap**プロトコルのスワップは、流動性プール全体に対して実行されるため、特定の注文が待たれることなく、効率的で迅速な取引が行えるメリットがあります。 この方法によって、流動性プロバイダーも報酬を受け取りながら、ユーザーによるスワップが実現されています。 ### 価格インパクト 価格インパクトとは、スワップや取引の際に価格に与える影響のことを指します。 これは、従来のオーダーブック市場と**Uniswap**プロトコルのスワップの違いを理解する上で重要な概念です。 従来のオーダーブック市場では、大きな市場買い注文が既存のリミット売り注文の流動性を枯渇させ、その後の高い価格でのリミット売り注文にも実行されることがあります。 結果として、注文の最終的な実行価格は、埋まった2つのリミット売り注文の価格の間に位置します。 :::message 従来のオーダーブック市場では、取引が注文ブック（オーダーブック）と呼ばれるリストに基づいて行われます。 投資家は買い手と売り手として、自分たちの注文をリストに登録します。 買い手は限られた価格でトークンを買いたいと注文し、売り手は特定の価格でトークンを売りたいと注文します。 大きな市場買い注文が存在する場合、市場に流入する需要が増加し、既存の売り注文の流動性が減少します。 このため、最初のリミット売り注文が埋まった後でも、その後の価格でのリミット売り注文が実行されることがあります。 大量の買い注文が流動性を枯渇させるため、価格が徐々に上昇し、その結果として次のリミット売り注文が執行される価格が高くなることがあります。 最終的な注文の実行価格は、このようにして実行された複数のリミット売り注文の価格の間に位置することになります。 つまり、市場において実際に取引が行われる価格は、単一の価格ではなく、注文ブック内の複数の価格に影響される結果となります。 ::: 一方、**Uniswap**プロトコルを使用したスワップでは、自動市場メーカー（**AMM**）の特性により、スワップの実行中にトークン同士の相対価値が連続的に変動します。 つまり、スワップの開始時点と終了時点の間で価格が変動し、その影響を受けて最終的な実行価格が設定されます。 :::message スワップを開始する際の価格と、スワップが完了する際の価格の間で、トークン同士の交換レートが変動することがあります。 この変動は、流動性プール内のトークンの供給と需要のバランスによって引き起こされます。 例えば、スワップの開始時点ではある価格でトークンを交換しようとした場合でも、スワップが進行する間に価値が変わる可能性があります。 この連続的な価格変動の影響を受けて、スワップの最終的な実行価格が設定されます。 つまり、実際にスワップが完了した時点での相対価格に基づいて、トークンが交換されます。 この特性によって、スワップの最終実行価格は、取引が行われる間に変動する価格の影響を受けることになります。 ::: この価格変動のダイナミクスは、**Uniswap**プロトコルのすべてのスワップに影響を与えます。 流動性プール内の異なる価格ポイントでの利用可能な流動性の量によって、特定のスワップサイズに対する価格インパクトが変化します。 特定の価格で多くの流動性が利用可能な場合、スワップサイズに対する価格インパクトは低くなります。逆に、流動性が少ない場合は価格インパクトが高くなります。 :::message 具体的には、流動性プール内の特定の価格ポイントでどれだけの流動性が利用可能かによって、スワップの実行時に価格がどれだけ変動するか（価格インパクト）が変化します。 価格インパクトは、スワップを行う際に価格がどれだけ変動するかを示す指標です。 流動性が豊富な価格ポイントでは、多くのトークンが提供されているため、スワップを行っても価格が急激に変動することは少なくなります。 逆に、流動性が少ない価格ポイントでは、限られたトークンが提供されているため、スワップが価格に大きな影響を及ぼすことがあります。 そのため、特定のスワップサイズに対して価格インパクトがどれだけ変動するかは、流動性プール内の価格ポイントごとの流動性の量に依存します。 流動性が多い価格ポイントでは価格インパクトは低くなり、流動性が少ない価格ポイントでは価格インパクトが高くなる傾向があります。 この特性によって、ユーザーはスワップを行う際に価格変動や価格インパクトを考慮しながら取引を行うことが重要です。 ::: **Uniswap**のインターフェースを通じて、リアルタイムで価格インパクトを予測し、異常に高い価格インパクトが発生する場合には警告が表示されます。 これによって、ユーザーはスワップを実行する際に価格インパクトを考慮することができます。 ### スリッページ **スリッページ（Slippage）** は、**Uniswap**プロトコルを使用してスワップを行う際に重要な概念です。 スリッページとは、送信した取引が保留中に価格が変動し、予想した価格と実際の実行価格が異なる可能性を指します。 Ethereumに取引が送信される際、各取引の実行順序は「**ガス**」と呼ばれる手数料の量によって決まります。 高いガス手数料を提供すれば、取引が速く実行されますが、低いガス手数料では取引が保留状態になることがあります。 この保留中の間に、他のスワップが行われることで、最終的な実行価格が変動する可能性があります。 スリッページ許容範囲は、ユーザーが設定する価格の変動幅です。 実行価格がスリッページ許容範囲内に収まる場合（たとえば`1%`以内）、取引は実行されます。 しかし、実行価格が許容範囲外になると、取引は失敗してスワップは実行されません。 この概念は、従来の市場でも理解できます。 例えば、遅延後に実行される市場買い注文では、送信時の予想価格と実際の実行価格に差が生じる可能性があります。 スリッページは、取引の実行過程で価格変動が起こることを考慮し、スワップをより確実に行うために重要な概念です。 スリッページ許容範囲を設定することで、予想外の価格変動から保護され、意図した価格でのスワップが行えるようになります。 ### 安全チェック 価格インパクトとスリッページは、**Uniswap**プロトコルにおいてユーザーの取引が円滑に行われるようにするための安全チェックがあります。 #### 1. 期限切れ（Expired） スワップが設定された期限を超えて保留中になることを防ぐための安全チェックです。 スワップを送信してから実行されるまでの間、一定時間が経過すると価格が変動する可能性があります。 期限切れの時点で保留中のスワップが自動的にキャンセルされ、長期間の保留とそれに伴う価格変動から保護されます。 #### 2. 出力不足（INSUFFICIENT_OUTPUT_AMOUNT） ユーザーがスワップを送信すると、**Uniswap**はユーザーが受け取る予定のトークンの量を見積もります。 スワップの実行時に予測された出力量が、一定の許容範囲（スリッページ許容範囲）内に収まることを確認します。 もし出力量が許容範囲を超える場合、スワップはキャンセルされます。 これによって、保留中に価格が急激に変動してユーザーが不利な取引を避けるための保護が行われます。 これらの安全チェックは、ユーザーがスワップの実行中に予想外の状況に直面するリスクを軽減するために設けられています。 スワップ実行前にこれらの要因を考慮することで、ユーザーは安全かつ予測可能な取引環境を確保できます。 ## トークン統合の問題 **Uniswap v3**では、「**手数料転送トークン**」と「**リベーストークン**」が通常のトークンとは異なる挙動を示すことに注意が必要です。 ### 手数料転送トークン（Fee-on-transfer Tokens） 手数料転送トークンは、**Uniswap v3**のルーターコントラクトとは適切に機能しないことがあります。 代替策として、トークンの発行者はトークンのラッパーやカスタムのルーターを作成することができます。 ただし、**Uniswap**は手数料転送トークンをサポートする新しいルーターを提供する予定はありません。 ### リベーストークン（Rebasing Tokens） リベーストークンは、プールの作成やスワップの実行には成功するかもしれませんが、流動性プロバイダーはリベースがマイナスに変化すると、そのポジションが有効になった時に損失を被る可能性があります。 この損失は回復できないため、慎重に取引する必要があります。 # ガバナンス ## 概要 コードなどが中心なのでこの記事では飛ばします。 詳しく知りたい方は以下を参考にしてください。 https://docs.uniswap.org/concepts/governance/overview ## プロセス **Uniswap**ガバナンス提案の開発と進行に関する現在のプロセスガイドラインです。 ### プロセス Uniswapのガバナンスプロセスには、さまざまな目的を持ついくつかの手段があります。 1. **gov.uniswap.org** これは**Discourse**を利用したフォーラムで、**Uniswap**のガバナンスに関する議論が行われます。 コミュニティメンバーは、投稿を共有したり「**いいね**」をする前にアカウント登録する必要があります。 新しいメンバーは自分で投稿する前に、10分間で4つのトピックを読み、15件の投稿を読む必要があります。 2. **Snapshot**: **Snapshot**は、オフチェーンでセンチメントを示すためのシンプルな投票インターフェースです。 **Snapshot**上での投票は、投票に使用されたアドレスに委任された**UNI**の数によって重み付けされます。 3. **ガバナンスポータル**: 正式なガバナンスポータルは、**Uniswap**アプリのインターフェースから直接アクセスできます。 投票はこのポータルを介して委任され、行われます。 これらの手段は、ガバナンスの異なる段階で利用されます。 まず、議論を行うために[gov.uniswap.org](https://gov.uniswap.org/)でフォーラムが使われ、その後、[Snapshot](https://snapshot.page/#/uniswap)でセンチメントを示し、最終的な提案は[ガバナンスポータル](https://app.uniswap.org/#/vote)を通じて投票されます。 ただし、これらのプロセスは**Uniswap**のコミュニティからのフィードバックに基づいて変更される可能性があります。 Uniswapのガバナンスプロセスの第1フェーズである「テンパレチャーチェック」は、現状の変更に対する意欲が十分にあるかどうかを確認する段階です。 #### フェーズ1: Temperature Check — Discourse/Snapshot 以下が手順です。 1. **コミュニティへの質問投稿** [gov.uniswap.org](https://gov.uniswap.org/)のコミュニティフォーラムに、潜在的な変更に関する偏りのない質問を投稿します。 例えば、「**UniswapのガバナンスにXYZトークンの流動性マイニングを追加すべきか？**」などです。 フォーラム投稿には「**Temperature Check - [タイトル]**」というラベルを付けます。 フォーラム投稿内には、関連する[Snapshot](https://snapshot.page/#/uniswap)の投票へのリンクも含めます。 2. **Snapshotを使用した投票** コミュニティメンバーは[Snapshot](https://snapshot.page/#/uniswap)を利用して、提案に対する意欲を示します。 [Snapshot](https://snapshot.page/#/uniswap)上での投票期間は2日間に設定します。 これにより、提案を支持するプロセスが開始されます。 2日間の投票期間が終了し、`25,000`**UNI**の「**賛成**」投票が過半数を占める場合、Temperature Checkは成功となります。 もしTemperature Checkの結果、現状の変更が提案されない場合、そのトピックは[ガバナンスポータル](https://app.uniswap.org/#/vote)上で閉じられます。 一方、もしTemperature Checkが変更を提案する結果だった場合、ステージ2へ進むための「**コンセンサスチェック**」の段階に進みます。 このようにして、Temperature Checkはコミュニティの関心や意欲を測りながら、提案のサポートを得るためのプロセスが進行します。 ### フェーズ2：コンセンサスチェック — フォーラム/Snapshot コンセンサスチェックの目的は、潜在的な提案について公式の議論を確立することです。 コンセンサスチェックを行う手順。 1. **Temperature Checkのフィードバックを利用** **Temperature Check**の投稿からのフィードバックを活用して、サポートを得た選択肢をカバーする新しいSnapshotの投票を作成します。 この投票は2択または複数択の形式で作成できますが、「**現状変更なし**」または同等の選択肢を含める必要があります。 投票期間は5日に設定します。 2. **新しいトピックを作成** [gov.uniswap.org](https://gov.uniswap.org/)の「**提案ディスカッション**」カテゴリに、「**コンセンサスチェック — [タイトル]**」というタイトルの新しいトピックを作成します。 これにより、このトピックがすでに**Temperature Check**を通過したことがコミュニティに知らされます。 **Temperature Check**を通過していない「**コンセンサスチェック**」で始まるトピックは、モデレーターによってすぐに削除されます。 議論スレッドは新しいSnapshotの投票と**Temperature Check**のスレッドへのリンクを含むようにします。 3. **サポートを広げる** 提案を支持するためにコミュニティに働きかけます。 提案を議論し、積極的に代表者に投票を依頼します コンセンサスチェックのトピックで質問に答える用意を持ちつつ、中立を保つよう心がけましょう。 自分の意見を共有しますが、中立性を保つことが重要です。 5日間の投票期間が終了すると、過半数の投票を得た選択肢が勝者となり、フェーズ3のガバナンス提案に含まれることができます。 コンセンサスチェックが通過するには、`50,000`**UNI**の「**賛成**」投票が必要です。 もし「**現状変更なし**」が勝利する場合、モデレーターによってコンセンサスチェックのトピックは閉じられます。 ### フェーズ3：ガバナンス提案 — ガバナンスポータル フェーズ3であるガバナンス提案は、ガバナンスプロセスの最終段階です。 提案はコンセンサスチェックの結果に基づいており、1つまたは最大で10のアクションから構成されることがあります。 ガバナンス提案を行う手順。 1. **提案のコードを作成** ガバナンスポータルを通じて投票される提案のためのコードを作成します。 詳細は[ここ](https://docs.compound.finance/v2/governance/#propose)から見れます。 提案に含まれるすべてのコードは、プロの監査人によって監査されるべきです。 この監査プロセスはコミュニティの資金で支払われるか、あるいは資金の払い戻しでまかなわれます。 2. **250万UNI以上を確保** 提案を行うためには、少なくとも自分のアドレスに`250`万**UNI**以上が委任されていることを確認してください。 または、提案の閾値を満たすだけの**UNI**を保有する代理人を見つけて、提案を代理してもらうこともできます。 3. **gov.uniswap.orgの提案ディスカッションカテゴリにトピックを作成** 「**Governance Proposal — [タイトル]**」というタイトルで、[gov.uniswap.org](https://gov.uniswap.org/)の提案ディスカッションカテゴリにトピックを作成します。 このトピックには、関連するSnapshotの投票や議論スレッドへのリンク、そしてコード監査レポートへのリンクを含めます。 "**Governance Proposal**"というタイトルで始まるトピックは、**Temperature Check**と**コンセンサスチェック**段階を通過していない場合、モデレーターによって削除されます。 4. **Governor Bravoのpropose()関数を呼び出す** 提案を展開するために、Governor Bravoの`propose()`関数を呼び出します。 5. **propose()関数が呼び出されると、2日間の投票遅延が始まる**: `propose()`関数が呼び出されると、2日間の投票遅延が始まります。 投票遅延が終了すると、7日間の投票期間が開始されます。 [gov.uniswap.org](https://gov.uniswap.org/)フォーラムでの議論が続きます。 提案が成功すると、2日間のタイムロックが続き、提案されたコードが実行される前に待機します。 ### ソフトガバナンス ソフトガバナンスとは、特定の課題に対して形式的な投票を行うための手続きだけでなく、方針の方向性や実装プロセスに関する議論も含む運営の方法です。 具体的な手続きは、前述の通りです。 特定の提案に対して投票を行う際には、事前に**Temperature Check**や**コンセンサスチェック**といったステップを踏むことで、コミュニティの意向を集約し決定します。 しかし、システム全体を運営するには、方針そのものだけでなく、その方針をどのように進めていくかや実施手順に関する議論も不可欠です。 例えば、提案のプロセスを改善する方法や新しいアイデア、戦略を検討する際に、コミュニティ内で議論が行われます。 こうした議論を「**メタガバナンス**」と呼びます。 「**Governance-Meta（ガバナンスメタ）**」カテゴリーは、こうしたメタガバナンスの議論が行われる場所です。 ここでは、方針の運用に関するアイデアや変更、提案プロセスの改善に関する議論が行われます。 このカテゴリーでの議論は、オンチェーンの投票が必要なく、オフチェーンのプロセスを更新する際に活用されます。 このように、ソフトガバナンスは形式的な投票だけでなく、方針や手続きに関する柔軟な議論を通じてコミュニティの運営を進める仕組みです。 ## 初心者のための投票ガイド 以下に画像付きで説明されています。 https://docs.uniswap.org/concepts/governance/guide-to-voting ## 用語集 - **UNI（ユニ）** - **ERC20**トークンで、ユーザーの投票権の重みを示すものです。 - ユーザーがウォレットに保有する**UNI**の量が多いほど、提案への委任や投票における重みが大きくなります。 - **委任（デリゲーション）** - **UNI**の保有者は、投票権をアドレスに委任することなく、投票や提案を作成することはできません。 - 委任は1度に1つのアドレスに行うことができ、自分自身のアドレスに委任することも可能です。 - 委任はトークンをロックするものではなく、選択した委任先のアドレスに投票権を追加するものです。 - **提案（プロポーザル）** - 提案は実行可能なコードであり、ガバナンスコントラクトやトレジャリーの動作を変更します。 - 提案を作成するためには、ユーザーは少なくとも全**UNI**の`0.25%`（`2,500,000 `**UNI**）を自身のアドレスに委任している必要があります。 - 提案はガバナーのスマートコントラクトの「`proposals`」マッピングに格納され、7日間の投票期間が設定されます。 - 提案者が投票期間中に投票権のバランスを保持しない場合、他の誰かが提案をキャンセルできます。 - **クオーラム（議決要件）** - 投票が成立するには、`40,000,000`**UNI**（全**UNI**の`4%`）の賛成投票が必要です。 - クオーラムの目的は、適切な投票参加があることを確保し、提案が成立するかどうかを判断します。 - **投票** - ユーザーは、投票権がアドレスに委任されている場合、提案に賛成または反対の投票を行えます。 - 提案が「**アクティブ**」状態の間に投票を行い、即座に「`castVote`」を使用するか、後で「`castVoteBySig`」を使用して投票することができます。 - 過半数の投票と**UNI**の`4%`のクオーラムが賛成した場合、提案はタイムロックにキューイングされる可能性があります。 - **投票期間** - 提案が出されると、**Uniswap**コミュニティメンバーは7日間の投票期間内で投票できます。 - **タイムロック** - すべてのガバナンスや他の管理行動は、最低2日間タイムロックされ、その後実行されることができます。 ## 今後の課題 この文書は、将来**Uniswap**Uのガバナンスが直面するかもしれない課題を調査しています。 その目的は、**UUniswap**Uのガバナンスに興味を持つ人々が、設計の背後にある理由や制約、そして成長の可能性についての考え方を理解するのを支援することです。 文書は、ガバナンスのデザインに関する背景情報や制約、今後の成長に向けた可能性について議論しています。 ### シナリオ1 ある善意の提案が投票に出されますが、その提案には悪用可能なエッジケースが存在します。 悪意のある行為者は、DeFiのレバレッジ戦略を駆使して、投票期間内に急速に**UNI**トークンを大量に購入し、提案に賛成の投票を操作します。 これによって提案が承認され、その脆弱性が悪用されてしまう可能性があります。 **回避策** **UNI**の投票権は、提案が提出される前または提案の遅延期間中に、特定のアドレスに完全に委任される必要があります。 現時点では、提案の遅延期間は1ブロック（約`15`秒）に設定されています。 この短い提案遅延期間は、第三者が悪用可能なエッジケースを見つけて急いで**UNI**トークンを購入し、自己委任して投票を操作する余地をほとんど残しません。 将来的には、**Uniswap**のガバナンスは提案遅延期間を増やす可能性があります。 提案遅延期間を延長することには明らかな利点がありますが、一方で機会主義的なエッジケースの悪用など、潜在的な悪影響も考慮する必要があります。 このような変更はコミュニティによって投票で決定される可能性があります。 ### シナリオ2 悪意のある提案が作成され、投票に提出されます。 この提案は、**Uniswap**のガバナンスの最善の利益に合致しないものです。 複数の関係者が事前に協力して**UNI**市場を操作し、提案を強制的に通過させ、**UNI**の準備資産にアクセスし、資金を排出しようとします。 **回避策** **UNI**は自由に取引可能な資産であり、誰でも市場での購入が可能です。 これにより、ガバナンスの乗っ取りを試みることができます。 ただし、悪意のある提案を強制的に通過させるためには、最低でも**4000万UNI**が必要です。 この金額は非常に高額であり、価格の変動も考慮に入れると、攻撃から得られる利益よりもコストが高くなるでしょう。 もしも悪意のあるグループが乗っ取りを成功させた場合、タイムロックの遅延によって影響を受ける関係者はプロトコルから自身の資産を引き出す時間を確保できます。 また、この状況はプロトコルを分岐（フォーク）させる機会でもあります。 この場合、残る善意のある関係者が新しい方向性を持つプロトコルを継続する可能性が高いです。 ### シナリオ3 1人のユーザーがフラッシュローンを利用して提案を急速に通過させ、ガバナンスに短時間で多数の提案を送り込み、効果的な運用を阻害する可能性があります。 これは実質的な**DDOS**（分散型サービス拒否）攻撃を模倣することになります。 **回避策** 投票を提出するには、少なくとも`250`万**UNI**が特定のアドレスに委任されている必要がありますが、その残高の確認は1つ前のブロックで行われます。 この方法により、フラッシュローンを利用した提案が生成されるのを防ぎます。 なぜなら、フラッシュローンは1つのブロックの範囲内でしか実行できないためです。 また、提案者は投票期間中に少なくとも`250`万**UNI**の残高を保持しなければならず、それを満たさない場合、誰でも提案をキャンセルできるようになっています。 この残高の維持チェックによって、複数のブロックにわたる高度なレバレッジを利用した提案手法を防ぐことができます。 ### シナリオ4 悪意のある提案が作成され、その提案自体が悪意を持って行われており、その提案を支持する投票を促す行為が行われる可能性があります。 例: トレジャリー（資金）が排出されます。 賛成票の投票者にはトレジャリーの残高が送られます。 反対票の投票者にはトレジャリーの資金からロックされます。 **対策** このような状況を明示的に防ぐメカニズムは存在しませんが、市場の力がこれを抑制する役割を果たします。 トレジャリーは**UNI**トークンのみで構成されているため、もしもガバナンスの提案が**Uniswap**の経済的な持続可能性や**UNI**トークンに対して危険をもたらす内容であれば、市場は適切に反応するでしょう。 提案が通過する頃には、**UNI**の価格は低下しており、攻撃者が得るべき利益がほとんどなくなるでしょう。 **UNI**がガバナンストレジャリーの唯一の資産として機能することで、この種の悪意のある投票が防がれます。 将来的には、**Uniswap**のガバナンスはガバナンストレジャリーの資産を多様化することを選択する可能性があります。 ただし、この選択には多くの利点がある一方で、悪意のある投票を奨励するといった限られたリスクも考慮されるかもしれません。 ## 変更履歴 以下にまとまっています。 https://docs.uniswap.org/concepts/governance/changelog # リサーチ 以下にまとまっています。 https://docs.uniswap.org/concepts/research # リソース 以下にまとまっています。 https://docs.uniswap.org/concepts/resources # 最後に 今回は**Uniswap**のドキュメントをまとめてきました！ 普段はブログやQiitaでブロックチェーンやAIに関する記事を挙げているので、よければ見ていってください！ https://chaldene.net/ https://qiita.com/cardene