FlareNetworksホワイトペーパー|FLRトークン

はじめに

スマートコントラクトプラットフォームを使用して分散型アプリケーションを促進することへの関心が高まっているから、計算スループットが向上した新しいコンセンサスプロトコルを開発する取り組みが行われています。特に、POS（Proof of Stake）プロトコルは、経済的手段を用いて攻撃を防御するコンセンサスプロトコルの一種です。具体的には、ネットワーク参加者は、悪意のある行為があった場合に失う可能性のあるネットワークのネイティブ・トークンをステーク契約でロックします。そのため、ネットワークの安全性は、コミットしたステークの価値に比例します。このため、POSベースのネットワークで表現できるユースケースが限定されてしまいます。さらに、Decentralized Finance (DeFi)など、ネットワークのネイティブトークンの用途が競合すると、ネットワークの安全性が損なわれる可能性があります[Chi20]。

対照的に、Federated Byzantine Agreement (FBA)は、ネットワークの安全性を確保するために経済的メカニズムに依存しない、スケーラブルなコンセンサスプロトコルの一種です[Maz15; SYB+14]。Flareは、このようなチューリング完全なFBAプロトコルの最初の反復を導入しました[RU19]。Flare Networkは、FBA設定[CC19]におけるAvalancheプロトコル[Roc18]に基づき、Ethereum Virtual Machine(EVM)を統合した、新しいTuring完全なスマートコントラクトプラットフォームです。このネットワークは、スケーラブルで安全かつ分散化されています。経済的な手段を用いてSybil攻撃を解決するという制約や潜在的な安全性の衝突から解放されています。

FlareのネイティブトークンであるSparkは、ネットワークレベルでのスパム制御に必要です。ネットワークの安全性はトークン自体に依存しないため、Sparkは他のネットワークでは安全ではない方法で使用できます。まず、Sparkはアプリケーションの中で担保として使用できます。第2に、SparkはFlare Time Series Oracle (FTSO)と呼ばれるオンチェーンの時系列データを提供するオラクルの唯一のコントリビューターではない。3つ目は、Sparkに依存するすべての要素のガバナンス方法論としてのSparkです。これらの3つの要素は、Sparkを使って構築できるアプリケーション群の構成要素であり、Spark Dependent Applications（SDA）と呼ばれています。さらに、ネットワークは安全性のために杭打ちや計算機のリターンを必要としないため、FTSOはSpark自体のインフレーション機能となる。

SDAの自然な応用として、非チューリング完全なトークンのトラストレスな表現を可能にすることが挙げられる。実際、パブリック・ブロックチェーンで出現した価値の約75%は、非チューリング完全ブロックチェーン上の暗号通貨である1。Sparkは、これらのトークンが表す価値を、スケーラブルなスマートコントラクト・プラットフォーム上でトラストレスに利用可能にします。さらに、Flare上でその価値が信頼できる形で表現されると、CosmosやPolkaDotなどの相互運用性ネットワークを通じて、他のネットワークに伝播する可能性があります。そのような最初の表現は、[Net20]で詳述されているように、XRPであり、これによって初めて、XRPをチューリング完全なスマートコントラクトでトラストレスに使用できるようになりました。

本文書は以下のように進みます。セクション2では、Flareネットワークとそのコンセンサス・メカニズムを紹介します。セクション3では、他の一連のトークンやアプリケーションのマスターキーのように機能するトークンとしてのSparkの仕様を概説します。セクション4では、Flareの時系列オラクルを紹介する。次にセクション5では、ネットワークのガバナンスについて説明する。FLRトークンの保有者は、ネットワークのパラメータを変更するために投票できる。最後にセクション6ではFlare Foundationを紹介している。Flare Foundationはネットワークを発展させ、特定のガバナンス決定を支援を目的としており、透明性、中立性を保ちながら、自然に存在感を薄めていくことを目指している。重要なのは、期待通りの成果が得られない場合、スパーク・トークン保有者によって解散させられます。

The Flare Network

このセクションでは、まず2.1でFlareネットワークの概要が示され、ネットワークのコンセンサスについて、その安全性、複雑性、livenessに関する考察が含まれています。サブセクション2.2では、Flare上のFXRPで使用するためのXRP Ledgerの状態など、下流のアプリケーションで使用するためにネットワークの外部にある任意の決定論的システムの状態について、コンセンサスを得るプロセスが示されています。

概要

Flare Networkは、ノードがAvalancheコンセンサスプロトコル[Roc18]を実行する分散型ネットワークで、Federated Byzantine Agreement（FBA）コンセンサストポロジー[CC19]への主要な適応が行われています。Flare Networkは、Ethereum Virtual Machine（EVM）を活用しており、Turing完全なスマートコントラクトを実行できます。FBAコンセンサストポロジーとチューリング・コンプリート・スマートコントラクト・レイヤーを組み合わせて、Flareは安全性のためのネイティブ・トークンを必要としない、スケーラブルなパブリック・スマートコントラクト・ネットワークとなります。これは有用な特性であり、安全のためにトークンを活用しているネットワークでは、ネットワークの安全性を攻撃するためのコストは、トークンの投機的価値に関連しているため、これらのネットワークでは、攻撃のコストが成功したダブルスペンドからの報酬よりも低くなるダブルスペンド攻撃を行うインセンティブが促進されます[Lok+19]。
定義 2.1. Flare Networkは分散型ネットワークであり、ノードはAvalancheコンセンサスプロトコル[Roc18]をFBA[CC19]コンセンサストポロジーに適合させ、EVMを活用して実行する。

FlareのネイティブトークンであるSparkは、ネットワークの安全性を確保するのではなく、XRPのようなチューリング完全ではないネットワークのトークンをFlare上で信頼性を持って発行し、チューリング完全なスマートコントラクトで利用できるようにするために使用されます。重要なのは、このFlare上での信頼性の高い発行は、非チューリング完全ネットワークの協力を必要としません。つまり、他のネットワークは、Flare上での発行を可能にするために、自分たちのプロトコルに変更を加える必要がありません。Flareネットワークは、二者間の協力を必要とする相互運用性プロトコルに協力できます。
Flareネットワークは、Cosmos[ICS20]のような、ネットワークをまたいだ資産発行のために二者間のプロトコル協力を必要とする相互運用性プロトコルと協力でき、Flareはこれらのネットワークへの非チューリング完全資産の統一された摩擦のないパイプラインとして機能できるのです。
5章で説明したように、FLRトークンの所有権により、ネットワークやパラメータのガバナンスを実現しています。これにより、Flareとそのコア・アプリケーションは非常にダイナミックで、アップグレード可能であり、実用性を高められます。

Consensus(合意)

Flare Networkは、ネットワークレベルのコンセンサスを得るために、FBAトポロジーで構成されている。FBAは、高価値・高リスクのユースケースを妨げる可能性のある経済的インセンティブに頼らずに安全性を実現するという点で、コンセンサストポロジーとしてはユニークである[Maz15]。

しかし、純粋なFBAは、構成ノードの構造が脆弱になり、単一ノードの故障がネットワーク全体の故障を引き起こすようなトポロジーシナリオを許容するという批判がある[Mac18]。このため、FBAのオープンメンバー性を維持しつつ、わかりやすさと使いやすさを重視したUNL（Unique Node List）トポロジー[CM18]と呼ばれるFBAの特定の設定が優先されている。UNLトポロジーの基本はネットワーク構造の対称性であり、各ノードがコンセンサスを得るために依存するノードのセットが、UNL交差セットと呼ばれるガバナンスで定義された閾値によって他のノードのセットとの交差を要求することで、純粋なFBAトポロジーの単一ノード故障モードを防げます。以下では、UNL内のノード総数をnと定義する。nの値は他の人が強制的に設定できない非公開の変数であるため、技術的にはノードオペレータごとに異なる可能性に注意してほしい。しかし、安全性の分析を簡単にするために、ノードは非自動のスパーク・トークン・ホルダーによるガバナンス投票を通じてnの値に合意が推奨される（セクション5.3.3参照）。

定義 2.2. ノードオペレータのユニークノードリスト（UNL）は、ノードオペレータが自発的にコンセンサスを得るために選択したノードのプライベートな定義である。
定義 2.3. UNLインターセクションセットとは、ノードオペレータのUNLに重なる最小のUNLサブセットであり、ネットワーク状態においてノードの一貫性を保ちたい2つのノードオペレータは少なくとも共通のUNLインターセクションセットを共有しなければならない。UNL交点セットのサイズはガバナンス定義のパラメータで、nのI%と定義される（nはノードオペレータのユニークノードリストのノード数）。
Flare Networkで使用されるコンセンサスプロトコルはAvalanche Consensus Protocol [Roc18]である。アバランシェは、FBA（したがってUNL）トポロジー[CC19]を含む、さまざまなサイビル抵抗性アプローチを使用できる柔軟なプロトコルである。アバランチェのパラメータkは、コンセンサスの際に照会されるネットワーク上のユニークなノードの一様ランダムサンプルのサイズである。CC19]では、Chitraらが、アバランシェネットワークにおけるコンセンサス時のノードの任意の2つのサンプルが少なくとも1つのノードで交差が保証される場合、QIP（Quorum intersection property）と呼ばれるFBAネットワークの安全性に必要な特性が達成されることを示している。

定義 2.4. FBAネットワークは、FBAネットワークの不連続なクォーラムが存在しない場合、クォーラム交点特性（QIP）を持つ。

アバランチのUNLトポロジー設定では、Flare Networkの展開において、ネットワークの任意のサンプルがUNL交点セットの50%以上を含むようにkが調整される。言い換えれば、kは以下のように設定される。

k > n(1 I=2); (1)

であり、nはUNLサイズである。これにより、UNL交点セットで重なるUNLを持つノードによるコンセンサス中のネットワークの2つのサンプルは、少なくとも1つのノードによる交点を含むことが保証され、したがってクォーラム交点特性（QIP）を達成します。
例 2.1. UNL交点セットのサイズを90%に調整したとすると、I = 0:9である。kの値はn(1 I=2) = 0:55nより厳密に大きく、すなわちUNLサイズの55%に設定する。これにより、ネットワークのサンプルはUNL交点セットの50%以上の含有率が保証されます。

ネットワークの安全性

Flare Networkの定義2.5の安全上の配慮は、2つのクォーラムが少なくとも1つのノードで交差を保証するために、クォーラムサイズは少なくともk > n(1 I=2); 0 < I 1以上でなければならないということである。実際に、おもちゃの例2.2は、1つのノードのクォーラムが交差が許容されるネットワークトポロジーである純粋なFBAのリスクを示している。この例は、Flare Networkが純粋なFBAトポロジーよりもUNLトポロジーの使用を優先している理由を示している。純粋なFBAにおいて以下のような許可された設定があると、1つのノードの障害がネットワーク全体の安全性に影響を与えるからです。
定義 2.5. FBAネットワークのノードセットは、2つのノードが同時に異なる値を外部化しない場合、安全性を示す。
例 2.2. UNL交点セットのサイズを1ノードに調整したとする。kの値をUNLサイズの100％に設定すると、UNL交点セットの1つのノードを常に含むネットワークのサンプルが保証される。このノードだけがすべての可能なクォーラムと交差しているため、ビザンチンになった場合、ネットワーク全体の安全攻撃を引き起こす可能性がある。

以下の分析は、クォーラム交差特性の保存を保証しつつ、1ノードの交差設定を回避するために、kの値をどのように調整できるかを示している。UNL交点セットの66%以上がどのクォーラムにも含まれると仮定します。これは、任意の2つの可能なクォーラムが、前の例のように1つのノードではなく、UNL交差セットのノードの少なくとも33%で交差を意味する。したがって、UNL交点セットを共有するノード間の安全性が失われるためには、UNL交点セット内の少なくとも33%のノードがビザンチンになる必要がある。なぜなら、この数は少なくとも2つのクォーラム候補の間でクォーラムの交点特性が失われるからである。UNL交点セットの66%は数学的には(2n I +1)=3と定義できる。次に、任意のクォーラムはUNL交点セットの外側のセクションも考慮しなければならない（n(1I)と定義）。
ノードオペレータのUNLの無作為サンプルがUNL交点セットの少なくとも66%からの表現を含むことを保証するために、n(1I)と定義される。2つのセットを組合わせで、サンプルサイズkはk = (2n I +1)=3+n(1I) = n(n I 1)=3 > n(1I=2); 0 < I 1に設定される。これは、kサイズのサンプルがFBAトポロジーフレームワーク[CC19]からクォーラムスライスを作成するために使用できるからであり、クォーラムスライスは各ノードがクォーラムとは何かをプライベートに定義したものである[Maz15]。なお、UNLオーバーラップが100%の場合（I = 1）、クォーラムサイズは従来のビザンチン協定のクォーラムサイズである(2n + 1)=3に戻ることに注意してください。

ネットワークの複雑さ

アバランシェ・コンセンサス・プロトコルの通信量はO(kn log n)である[Roc18 CC19]。これは、クォーラム交差特性を維持しつつ、kのサイズを拘束が必要であると意味する。

以下では、FBAの設定でAvalancheの通信の複雑さを軽減するアプローチを示しているが、Flare Networkの安全性分析を単純化する目的で、このアプローチに従わないことを推奨する理由を述べている。CC19]では、Chitraらは、ネットワーク内のノードのY個の独立して描画されたk 1要素のサブセットに依存する方法を提案している（ここでYはPoisson()）。

これらのサブセットはFBAコンセンサスフレームワークのクォーラムスライスの概念に近似しており、
Chitraらはlog(n)＜k n 2 and ＜ poly(k)の場合、クォーラムインターセクション特性が高確率で保証される証明をしています。

しかし、パラメータを1つだけ設定すればよいという利点は、ノード操作が簡単になるということであり、これはいずれにしてもネットワークに多数のノード操作者を参加させるために必要な特性である。したがって、コンセンサス時の通信の複雑さを犠牲にしても、kをk＞n（1 I=2）0＜I 1にのみ設定する方法が優先される。

Network liveness

Flare Networkのライブ性（定義2.6参照）は、コンセンサス時にあるノードが定足数を形成できないようにブロックするノードのセットがあると、そのノードのライブ性が失われるというものです。ノードがコンセンサス時にクォーラムを形成できないようにブロックするノードのセットは、そのノードのライブ性を失われます。UNLトポロジーでは、ノード はネットワーク内の他のノードとは無関係に自分のUNLを自由に変更でき、livenessの損失を被ったノードは は自分のUNLを変更して故障したノードを補える。これはグローバルなネットワークメンバーの合意を必要とする他のネットワークでは ネットワークのメンバーシップに関するグローバルな合意を必要とする他のネットワークにはない特徴である。

定義 2.6. FBAネットワークのノードは、敵対的なノードの参加を得ずに値を外部化できる場合、ライブ性を示す。敵対的なノードの参加なしに値を外部化できる場合、FBAネットワークのノードはlivenessを示す。

State-Connectors:外部システムの状況に関するコンセンサス

FXRP[Net20]のようなFlare上のアプリケーションで使用する、XRP Ledgerや株式市場などの外部システムの状態に関するコンセンサスは、ハイリスクなプロセスです。例えば、外部システムが突然、10億ドル相当の価値が動いたというシグナルを発します。このとき、Flareネットワークは、できるだけ早く、人手を介さずに、この外部の状態の最終性を計算し、FXRPなどのFlare上の下流のアプリケーションに信号として利用できるようにする必要があります。FXRPの場合、もしXRP Ledgerの状態がFlare Networkに誤って記録されていた場合、Flare Network上に10億ドル相当のFXRPを作成できますが、そのFXRPをXRPに戻せず、発行されたFXRPとそれに依存するアプリケーションの価値が損なわれてしまいます。

したがって、外部システムの状態に関するコンセンサスは、Flare Network上の下流のアプリケーションですぐに使用できるように安全に整理されなければなりません。これは、2.7で定義されている状態コネクターによって達成されます。状態コネクターは、外部システムの状態をFlare Networkに安全にエンコードする役割を果たします。
定義 2.7. 状態コネクターは、基盤となる Flare Network ノードと同様に、UNL 対称設定の FBA トポロジーで構成される。各ステート・コネクタは単一の Flare Network ノードによって実行され、ステート・コネクタはその Flare Network ノードと同じ UNL 定義を共有している。ステートコネクターシステムには、1) 外部システムの状態をサンプリングする、2) Flare Network上で状態を登録する、3) Flare Network上のスマートコントラクトで使用するために状態を最終化する、という3つのフェーズがあります。

ステートコネクターは、以下の条件を満たすように設計されています。

状態コネクターシステムのサンプリング、登録、最終決定の段階は、特定の外部システムに依存する。に依存します。以下では、XRP Ledgerの状態を例にして、これらの段階を具体的に定義します。この設計は 他の決定論的な外部システムにも簡単に一般化できます。

外部システムの状態をサンプリング

外部システムの状態をサンプリングする際に工学的に考慮すべき点は、外部システムが時間の経過とともに更新する速度です。例えば、XRP Ledgerは約5秒に1回のペースで急速に最終更新されます。しかし、ビットコインのような他のシステムでは、状態を更新するまでの時間がかなり長くなります。XRP台帳のように状態の更新時間が早いシステムでは、システムの状態に関する請求を請求期間にまとめて、状態接続者が外部システムをサンプリングしてその状態をFlare Networkに登録するのに十分な時間を確保が有効です。
例えば、クレームは、XRP台帳上のXRPの担保化や、株式市場におけるデリバティブのポジションを表している場合があります。債権は、外部システム固有のものであり、Flare Networkに記録される各外部システムの他の債権の中で、外部システム内で最初にどのように注文されたかに基づいて、完全に順序付けられます。
定義 2.8. クレームとは、外部システムの状態に関する情報の単位である。

図1：XRP台帳内のクレームの例。このクレームは、台帳内の取引のサブセットとして定義され、例えばFXRPの担保に関連するすべての取引で、クレーム期間はXRP台帳の3回のクローズに設定されています。

請求期間セットのサイズは柔軟で、その外部システムの状態更新速度に関連している必要があります。そうしないと、外部システムの請求期間の存在と順序について合意を得る際に、国家接続者は一貫性を失ってしまうからである。
定義 2.9. クレーム期間とは、完全に順序付けられたクレームの集合である。
例 2.3. ビットコインのクレーム期間は、ビットコインの新しいブロック間の時間が長いため、1つのビットコインブロックを表すことができる。
例2.4. しかし、XRP台帳では、請求期間は10回のXRP台帳のクローズを含むように調整できます。これは、状態コネクターがXRP台帳の状態を照会し、請求を処理し（例：スパム請求のフィルタリング）、Flareネットワークに請求を登録して請求期間を形成するのに適度な時間を与えるためです。

ステートコネクターは、クレーム期間のコンセンサスを組織することで、外部システムの状態更新をFlare Networkに適用します。クレーム期間は、他のクレーム期間の間で完全に順序付けられており、アプリケーション不変である。つまり、Flare上のスマートコントラクトでステートコネクターが活用しているコンセンサスシステムは、クレームペイロードに含まれるアプリケーションの詳細を認識しておらず、代わりにシステムはクレーム期間セットの存在と順序に関するコンセンサスを組織することにのみ関心がある。

外部システムの状態をFlare Networkに登録する

各状態コネクターは、定期的にサンプルを採取し、その状態コネクターが以前に登録していなかった請求を独立してFlare Networkに登録することで、現在の請求期間のローカルな定義を構築する。

クレームは、ステートコネクタによるクレームの登録だけでは、Flare Network上で非可逆的なアクションが発生するような、自動的に最終的なものにはならない。状態コネクターは、ノードオペレータのUNL内でコンセンサスを得るために依存を選択した十分な数の他の状態コネクターがクレームを登録し、クレーム期間セットの一部として確定させることを必要とする。クレーム期間セットの最終性は次のセクションで具体的に定義される。

Flare Networkのスマートコントラクトで使用する外部システムの状態を最終的に決定する。

ある状態コネクターがクレーム期間セットに含まれるすべてのクレームを登録すると、その状態コネクターは、クレーム期間を最終的に受け入れるよう提案しているという信号をFlare Networkに発行する。あるステートコネクターのUNLから見て定足数のステートコネクターがクレーム期間Nに対して同じ状態を登録した場合、このステートコネクターはこの状態を受け入れたとみなされる。ここで、ノードのVブロッキングセットとは、ステートコネクターのすべての可能なクォーラムと少なくとも1つのノードで交差するようなものである。

このクレーム期間Nの状態を受け入れることは、構成するクレームがまだ最終的に決定されていないと意味し、Flare Network上のスマートコントラクトが利用できることを意味する。最終段階では、状態連結者が、外部システムの独自の観察に基づいて、受け入れられたクレーム期間Nの状態に対して同じ定義を個人的に登録しなければならない。状態連結者の登録がある場合、主張期間N + 1が最初に受け入れられたときに、その状態連結者の観点から主張期間Nが自動的に確定される。ステートコネク ターの登録がない場合、ローカルのステートコネクターはクレーム期間Nの状態を 個人的に観察できなかったため、このステートコネクターの視点では最終 的な状態にならず、ステートコネクターのノードが安全に停止になる2。

ステートコネクターのコンセンサスを計算する際に使用する、スマートコントラクトレイヤー内のユニークなノードリストのオーダーメイドの定義のエンコーディングに関するエンジニアリング上の考慮点については、付録Aで説明しています。

したがって、XRP台帳のような外部システムの状態は、スマートコントラクトで使用するためにFlareネットワーク上で利用可能となります。その方法は、オープンメンバー、一貫性、独立した検証、そして安全性を経済的インセンティブに依存しないことです。

The Spark token

FLRトークンは、Flare Networkの固有の通貨です。3.1では、ネットワーク・スパムを抑制するための技術的な使い方を紹介します。次に、スパークのアプリケーションを3.2で紹介します。続いて3.3では、Sparkの生成、分配、割り当て方法を規定します。
定義 3.1. Sparkは、Flare Networkのネイティブ・トークンである。

スパーク技術利用

Sparkの技術的な目的は、取引にコストを課すことで、余計な取引（ネットワーク・スパミングなど）を抑制することにあります。これを実現するのが、取引手数料です。

Flare Networkでは、Ethereum Virtual Machine（EVM）[Woo+]を使用しています。EVMは、トランザクションの計算の複雑さをガスの単位で定義します。極端に長い取引や延々と続く取引を避けるために、Flareはガス単位で定義された複雑さの制限を課しています。
制限を設けています。これはガス単位で定義されています。ガスとスパーク・トークンの間のガス換算レートは、ネットワークによって設定されます。したがって、取引コストは、複雑さの制限にガスとスパークの変換率を掛けたものと定義されます。取引コストは、ある参加者に発生するのではなく、燃やされます。複雑さの制限とガスとスパークの変換率は、どちらもガバナンスのパラメータである。ガバナンスについての詳細は第5節を参照のこと。

定義 3.2. 複雑さの限界とは、1つの取引で消費できるガスユニットの最大量である。
定義 3.3. ガス変換レートは、FLRトークンにおけるガスユニットのコストである。
定義 3.4. 複雑性限界までの複雑性を持つ取引には、単一の取引コストが存在する。FLRトークンでは、T = c で与えられ、ここで c は複雑さの限界であり、ガス変換レートである。

スパーク依存のアプリケーション

Sparkはネットワークガバナンスの決定者であり、分散型アプリケーションを構成するユーティリティーの中心的存在である。Spark Dependent Applications (SDA)と呼ばれる新しい分散型アプリケーションの構造を形成している。

定義 3.5. Spark Dependent Application (SDA)とは、以下の3つのコンポーネントを組み合わせて構築されたアプリケーションである。Spark依存アプリケーション(SDA)とは、Sparkが仲介する時系列オラクル(セクション4参照)、担保としてのSpark、Sparkが仲介するガバナンス(セクション5参照) Sparkによるガバナンス（第5章参照）。

これらの各コンポーネントについて、以下に簡単に説明します。

SDAの構造は、Flare上で展開されるアプリケーションがオプションで以下のような恩恵を受けられるようにすることで、実用性の提供を目的としています。

これらを総称して、SDAの「ネットワーク効果」と呼べます。これは、使用すればするほどメリットが大きくなるからです。
--------------------------------------------------------------------------------------------------------------
2ノードがこの状態から回復する方法は2つある。1)提案された請求期間Nの状態を批准する署名を発行する、または2)ノードが自分のUNLの観点から請求期間Nの状態に関するネットワーク全体の決定に同意しない場合は、現実に一致する別のUNLにブートストラップできる。ブートストラップ中、最新の状態にすぐに同期するために、台帳期間の署名を1つのステップにまとめるられます。

SDA components(部品)

SDAの第一の要素は、担保を必要とするあらゆるアプリケーションの担保としてSparkを使用することです。スマートコントラクト・プラットフォームのネイティブ・トークンは、スラッシュ（切り崩し）を含むProof of Stakeを使用していますが、Flareのネットワーク・セーフティはトークンに依存していないため、スパーク・トークンを担保として使用しても、ネットワーク・セーフティ自体と競合はありません。ネットワーク上のどのアプリケーションもスパーク・トークンを担保として使用できます。そのような最初のアプリケーションは、スパーク・トークンを使って、XRPの信頼性のない1対1の表現であるFXRPを作成しています[Net20]。

SDAの2つ目のコンポーネントは、Flare Time Series Oracle（セクション4参照）で、任意の数のオフチェーン時系列の現在値を定期的にオンチェーンで推定します。特定の時系列の貢献者は、最低でもFLRトークン保有者で構成されますが、特定の状況下では、その時系列に依存するアプリケーションのトークン保有者も含まれます (F-Assets保有者と呼びます)。

定義 3.6. F-Assets とは、1 つまたは複数のデータを対象とした Flare Time Series Oracle への参加を Spark ガバナンス(セクション 5 参照)によって許可された SDA が発行するトークンである。
F-Assetsは、FLRトークン保有者からガバナンスを通じて同意を得た任意の形態をとることができる。このような例を2つ紹介します。

例 3.1. 1対1の表現 FXRPはFlareネットワーク上のXRPの信頼性のない表現です[Net20]。FXRPアプリケーションは、XRP/Spark価格のプライスフィード（データ推定値）を必要とする。FXRPは，XRP/Sparkの価格フィードに関連するF資産である。

例 3.2. 一対多の表現 例となるアプリケーションでは、様々な異なる時系列でのピアツーピアのベットに対して、FLRトークンで表現された利益と損失を自動的に発生させ、実現できます。時系列は、Flare Time Series Oracleによって推定されます。アプリケーションにはガバナンス・トークンがあり、これは担保などのアプリケーション内部の特定のパラメータを決定しますが、アプリケーションのF資産でもあり、アプリケーションが使用する特定の時系列の推定のためにFlare Time Series Oracle（FTSO）に貢献します。一対多の F-Assets を使用するアプリケーションの設計は、FTSO を攻撃するインセンティブを与えないように、慎重に検討する必要があります。
FTSOを攻撃する動機とならないよう、慎重に考慮する必要があります。これは、アプリケーションが提案するF-AssetsのFTSOへの参加を許可するかどうかを決定する際に、Sparkガバナンスセットが考慮する重要な点です。

Flare Time Series Oracle (FTSO)には、新しいFLRトークンを生成する報酬機能があります。新しいスパーク・トークンは、スパーク・ホールディングのコントリビューターに報酬を与えるために使用されます。貢献者への報酬の決定は、正直者に経済的なインセンティブを与えるように設計されたプロセスに基づいており、セクション4で詳しく説明しています。報酬の総額は、スパーク・トークンのインフレ率であり、ガバナンスによって決定されます。データを提供するFアセットホルダーは、FTSOから直接報酬を受けません。しかし、データを提供することで、データの有効性やアプリケーション内で指定された貢献報酬についてより確実なものとなるため、貢献することにインセンティブが与えられる場合があります。

FTSOは当初、XRP/Spark、USD/Spark、BTC/Spark、XLM/Sparkの推定データを提供します。そのうち、初期の依存アプリケーションであるFXRP[Net20]のトークン保有者は、スパーク保有者に加えて、XRP/Sparkの価格に貢献します。FTSOは、セクション5で詳述するように、追加の時系列を含むように拡張可能です。FTSOによって生成されたすべてのデータは、システム内のどのアプリケーションでも自由に使用できます。そのため、どのアプリケーションも設計者が適切と考える方法でデータを再構成し、追加できます。

SDAの3つ目の要素は、ガバナンスを目的としたSparkの利用です。SparkはネットワークやFLRトークンのパラメータを管理するために使用されます。また、重要な意思決定を行う際に、より多くの参加者を巻き込むためにアプリケーションで使用も可能です。SDAのガバナンスにSparkをどのように使用するか、またどのくらいの期間使用するかについては、決まったルールはありません。FXRPは、担保比率、手数料、その他様々なパラメータを設定するFLRトークンからガバナンスを得ているアプリケーションの一例です。ガバナンスシステムの詳細については、セクション5で説明します。

潜在的なトレードオフを軽減する

SDA構造の3つの要素は、それぞれが連携して初めて最適な効果を発揮します。実際、次の事象が必要です。「スパークを担保として使用すること」と、「同じFLRトークンを使ってFTSOやガバナンスシステムに貢献すること」との間に「競争がないこと」が必要です。FTSOやガバナンスシステムに貢献するためにFLRトークンを使用できます。

スパークを3つの要素に同時に使用する際の障害となるのは、スパークを担保としての使用です。スパークを担保として使用して発生します。これは、スマート・コントラクトでロックされているために、1人または多数のカウンターパーティの補償に利用できるからです。スマートコントラクトにロックされ、アプリケーションの決定に応じて1人または多数のカウンターパーティに補償できるからです。

スパークが担保としてアプリケーションにロックされている場合、その担保の提供者は、潜在的にその全部または一部に対する請求権を持っています。スマートコントラクトのアルゴリズムによって実行されます。ほとんどのアプリケーションでは、その請求権は、元の担保金額 担保金額に追加分を加え、損失や費用を差し引いたものになります。通常、この請求権は、担保提供者が は、担保提供者がアプリケーションへの参加を解除した場合にシステムから引き出せる金額に相当します。この請求権は、時間の経過とともに変化する可能性があり、スパーク請求権と呼ばれます。

定義 3.7. スパーク・クレームとは、あるアドレスがアプリケーションから実現可能なスパーク・トークンの量です。そのアプリケーションへの参加がすべて取り消された場合。

もし、アドレスがスパーク請求額を使ってFTSOに貢献する（そしてFTSO報酬を得る可能性がある）方法がなかったとしたら アドレスの所有者は、アプリケーションの担保としてスパークを利用して、望ましくない機会費用に直面します。機会費用が発生します。

この問題を解決するために、デリゲーションシステムが導入されました。デリゲーションとは、あるアドレスに対して 委任で、あるアドレスは、FTSOとガバナンスへの参加を目的として、スパーク・トークンに関連する票のすべて、または一部を他のアドレスに付与できます。ガバナンスに参加できます。

各スパーク・トークンは、FTSOとガバナンスに貢献できる1票を保持しています。各スパーク・トークンは、FTSOに貢献できる1票と、ガバナンスに貢献できる別の1票を保有しています。これらの票は、異なる当事者に委任できます。上述の機会費用は、スパーク・クレームを作成するアプリケーションは、担保提供者が指定したアドレスへの請求額の委任を自動化で解決します。

定義 3.8. 委任とは、Flare上のあるアドレスが、自身のFLRトークン票（またはF-Assets票）と既に割り当てられている票 および既に割り当てられている票を、Flare上の別のアドレスに割り当てます。

トークンの所有者は、いつでも自由に投票を委譲したり、委譲を解除したりできます。委任は、ある当事者が次の当事者に委任できるような構造にできます。委譲は、一人の当事者が二人目の当事者に委譲し、その二人目の当事者が三人目の当事者に委譲する、というように構成できます。これにより、自然と これは、FTSOとガバナンスシステムの両方で使用されるアドレスの議決権という概念に自然につながる。

定義 3.9. あるアドレスが保有する非委任トークンの数と、そのアドレスに委任されたトークンのうち、それ自体がさらに委任されていないトークンの数が、そのアドレスの議決権となる。そのアドレスに委譲されたトークンのうち、それ自体がさらに委譲されていないものが、そのアドレスの議決権を与える。

要約すると、スパークを担保として使用し、スパーク・トークンの委任を許可するアプリケーションは、FTSOやガバナンス機能に影響を与えません。やガバナンス機能に影響を与えず、スパークを担保として使用してもネットワークの安全性を損ないません。スパークホルダーは 同時にFTSOのリターンを得て、依存するトークンからのリターンを得て、ガバナンスに参加し続けられます。

例 3.3. Flare XRP (FXRP) [Net20]は、XRP Ledger (XRPL)の固有トークンであるXRPを表現したものです。FXRP は、FLRトークンに裏付けられており、XRPと1対1で交換可能です。ユーザーは、XRPの作成、使用、使用後のどの段階においても、中央管理者を信頼する必要はありません。ユーザーはFXRPの生成、使用、償還のどの段階においても中央管理者を信頼する必要がなく、FXRPはトラストレスです。FLRトークンは FLRトークンはFXRPを支える担保を提供していますので、FLRトークンの保有者がFXRPのシステムパラメータに対して高いレベルのガバナンスの保有は当然です。FXRPのシステムパラメータに対して、FLRトークンの保有者が高いレベルのガバナンスを持つのは当然です。FLRトークンの保有者は、スマートフォンに格納されているシステムパラメータに対して スマートコントラクトにコード化されたシステムパラメータへの投票を通じて、FXRPシステムに対するガバナンスを発揮します。そのようなパラメータの一例として、FXRPの担保比率があります。

これは、発行されたFXRPに対してロックしなければならないスパーク・トークンの値で、最初は2.5に設定されています。このパラメータは この値は、FLRトークン保有者の提案とガバナンスプロセスによって変更可能であり、ガバナンスセクションで定義されている超過半数を必要とします。ガバナンスセクション（セクション5参照）で定義されたスーパーマジョリティ（全トークン保有者の少なくとも50％が参加し、提案が2/3の過半数を獲得すること）を必要とします。

FXRPシステムは、発行されたFXRPに対して計上された担保の価値が担保率を上回るように、XRP/Spark価格のフィードを必要とします。が担保比率以上に保たれるよう、XRP/Sparkの価格をフィードする必要があります。この価格フィードは、FXRPシステムの2つのステークホルダーであるスパーク社とFX社の責任で確保されます。FXRPシステムの2つのステークホルダーであるSparkとFXRP保有者の責任とすることで、価格フィードを確保しています。

スパークの作成と配信

FLRトークンは、XRPエコシステムに配布され、元のチェーン（XRP）にかなりの効用を生み出すソフトフォークとなることを意図しています。競合するのではなく、チューリング方式のスマートコントラクトでXRPを使用できるように、オリジナルチェーン（XRP）にかなりの効用をもたらすソフトフォークを目指しています。このソフトフォークは、元のチェーン（XRP）に大きな利益をもたらすことを目的としています。

このプロセスをより適切な言葉で表現すると、ユーティリティーフォークということになります。

分担

XRP台帳のスナップショットは、3.3.2項に詳述されているように、特定の日に取得されます。Flare Networkの開始時に1,000億トークンが生成されます。45Bnトークンは、既知のRipple Labsアカウントを除くXRPトークン保有者によって6ヶ月間請求可能です。請求額は、XRP Ledgerスナップショットの時点でのXRP保有量に対して、定義3.10を参照した配分計算式によって算出されます。請求期間が終了すると、未請求のトークンはすべて削除されます。
削除されます。250億トークンはFlare Network Limitedに、300億トークンはFlare foundationに支払われます。セクション6を参照してください。フレア財団は、フレアネッ トワークの開発を支援し、ネットワークガバナンスを促進を目的とした非営利組織です。
定義 3.10. XRP保有者（バー・リップル・ラボ）は、以下の配分に従ってスパーク・トークンを請求できます。
の式に従う。

xSpark = xXRP=(N 􀀀 NRipple)  45Bn; (2)

ここで、xSparkは請求可能なSparkの量、xXRPはスナップショット日に保有されているXRPの量、Nはスナップショット日に存在するXRPの総量、NRippleはスナップショット日にRipple Labsが保有していることが知られているXRPの総量です。

XRP snapshot date

多くのXRPトークンは取引所で保有されているため、XRP Ledgerのスナップショットは、将来、以下の時点で取得されます。十分な数の取引所が、お客様に代わってスパーク・トークンを請求するかどうかを明確にした時点で、XRP Ledgerのスナップショットが行われます。

スナップショットが行われた際には、https://flare.xyz で発表されます。スナップショットの取得を遅らせて スナップショットの取得を遅らせることで、トークンを取引所の口座で保有しているが、スパークの配布に参加したいと考えているXRPオーナーに、その手段を提供します。スパークの配布に参加したいと考えているXRP所有者は、取引所がそのようなオプションを提供していない場合、その手段を得られます。既知の取引所アカウントで FLRトークンを顧客に提供せず、スナップショットの時点でXRPの残高を保持している既知の取引所口座は、トークンの配布対象から外れます。トークンの配布対象から外れます。これらのアカウントが請求できるはずだったトークンは、有効な請求権者に再配分されます。有効な請求権者に比例配分されます。

Time series oracle

Flare Time Series Oracle (FTSO)は、オンチェーンで必要とされる外界に関する情報の推定値を提供します。この推定値を提供するために、システムが1つまたは複数の外部情報源に依存は、事実上、中央集権の導入です。ネットワークの分散化された性質を利用して、広範囲の時系列データの推定値を分散化されたオラクルを介して計算できます。これにより、ネットワークのpeer-to-peerの性質を利用しつつ、Sparkユーザーに報酬を与えて貢献を促せます。

以下では、まず4.1で分散型オラクルの背景を説明し、4.2でFTSOの概要を説明します。次に、4.3では推定値の計算プロセスについて、4.4では報酬スキームについて、4.5では擬似乱数生成器について説明しています。最後に、4.6では、FTSOが悪意のある者からの攻撃を受けやすいことについて議論します。

背景

分散型オラクルは、通常、システム参加者を利用して、与えられた提案の性質に関する投票を行います。例えば、Schelling Coinプロトコル[But14]では、ネットワーク参加者からの投票を集めるために、commit and revealスキームを使用しています。これにより、投票の分布が得られ、そのうち上位25%と下位25%が切り捨てられます。結果として得られた分布の中央値が価格推定値となり、投票が利用された50%の投票者に報酬が与えられます。このようなスキームは、ゲーム理論的な観点から研究でき、各参加者は報酬を最大化するために選択しなければなりません。例えば，Schelling Coin方式は，このようなゲームにはSchelling点，すなわち焦点があるという考えに基づいている[Sch80]．

近年、チェーンに外部情報を照会する必要性から、TruthCoin consensus [Szt15]、Chainlink [EJN17]、Astraea [Adl+18]、Terra [KDKP19]など、様々なアプローチのオラクルが開発されています。オラクルの主な特徴は、プレイヤーに正直であることのインセンティブを与える一方で、基礎となるシステムの分散型の性質を利用した分散型のデータフィードであるべきです。

FTSO概要

Flare時系列オラクルは、Flareネットワーク上のオフチェーン時系列データの正確な推定値を生成を目的とした分散型アプリケーションです。推定値の生成を目的とした分散型アプリケーションです。オラクルは、2組の参加者からの推定値を入力とします。スパークホルダーと 関連するF-Assets保有者です。

定期的に所定の時間間隔（ガバナンス・パラメータ）で、両セットの参加者は の参加者は、現在の推定値をシステムに提出できる（ただし、義務ではない）。 結果として得られた投票セットは、データ推定値に対する分布を形成し、加重推定値分布と呼ばれる。定義 4.5 を参照のこと。誤りや悪意のある試みからなる可能性が高い外れ値を除去するために、投票数で決まる中間の 投票数で決定される中間の50%のみを保持します。

これにより、更新された切り捨てられた推定分布が得られます。定義4.6を参照してください。切り捨てられた分布の加重平均は、次のAblocksの推定値として使用される。ここで、Ablocksはシステムパラメータである。最終的な出力に貢献した投票権者には、補償が行われる。は、定義4.12の補償スキームに記載されているとおりである。

推定値の算出

時系列のオラクルでは、与えられた変数のオラクル推定値が得られます。この推定値は、投票ラウンドと呼ばれる一定の時間間隔で、関連するトークンホルダーからの推定値を処理して算出されます。各投票ラウンドの開始時に，関連するトークン・ホルダー（後に定義）が自分のデータ推定値を投票と称して提出し，それを基にオラクルがオラクル推定値を計算する．投票はcommit and reveal方式 [Gol07]で行われる．
定義 4.1. 投票ラウンドtは，投票できる時間間隔である．これはシステムガバナンスのパラメータである．
定義 4.2. 投票ラウンドtにおける投票vitは、i番目の参加アドレスの提出された推定値である。

各オラクルの推定値は、スパークの保有者と、関連するデータ推定値に関連して発行されたF-Assetsトークンの保有者という、利害が一致する2つのグループによって決定される。表記を簡単にするために、以下では1つのデータ推定値を考慮します。提案された手順は、n個の異なる時系列に簡単に拡張できる。

例 4.1. FXRPシステム[Net20]では、発行されたFXRPに対して十分な担保を確保するために、XRP/Spark価格のロバストな推定値が必要です。この場合、F資産はFXRPであり、時系列オラクルはスパークとFXRPの両方の保有者から提出された推定値に基づいて、オンチェーンのXRP/Spark価格を提供します。FXRPとSparkのどちらかを持っていることで、これらのグループはシステムに暗黙の利害関係を持ち、正確な価格設定がシステムの整合性と効用を維持するため、正直に行動するインセンティブを持ちます。
各投票ラウンドtにおいて、投票に参加したいNS t SparkアドレスとNF t F-Assetsアドレスがいるとする。これらを4.3で定義したpartaking addressと呼ぶ。QStをNS tの参加SparkアドレスのSpark投票力の総量とし、QFt
は、投票ラウンドtにおけるNF tのF-Assets参加アドレスのF-Assets投票力の総量とする。
t + NF t 。

定義 4.3. ある投票ラウンドtにおいて、partaking addressは以下のもので構成される。
1. 1. ラウンドtに参加を選択したスパークアドレス。
2. ラウンドtに参加を選択したF-Assetsのアドレス。
次に，各アカウントが投票，つまり見積もりを提出します．投票ラウンド開始時点での投票アドレスに関連するトークンの数を考慮します。アドレスiの投票力をxSiとします。
であり、F-AssetsアドレスであればxFi F-Assetsである。F-Assetsアドレスの場合、投票力は調整係数QS t QFtで比例的にスケーリングされ、調整後の投票力となる（定義4.4参照）。

ここで、QSt, QFtは、ラウンドtの開始時にSparkおよびF-Assets参加アカウントに保有されているトークンの総量で、xFiはi番目に参加したF-Assetsアドレスの議決権です。
F-Assetsアドレスの議決権は、議決権を持つSparkアドレスの保有資産量に合わせて調整・スケーリングされるため、議決権の総量QtはQt=2QStで与えられます。

そして、投票権（またはアドレスの種類に応じて調整された投票権）で重み付けされた提出された投票は、重み付けされた推定値分布Ptと呼ばれるデータ推定値の分布になります。 各投票は、以下のように保有するトークンの量で重み付けされます。
定義 4.5. 投票期間tの加重推定分布Ptは、推定値のセットfvigNt i=1と、関連する重みのセットfwigNt i=1で構成される。

次に，0:25Qt を計算して分布を切り詰め，最低票と最高票を削除する（つまり，提出された票の 50% を残す）。これにより、新しい価格のセット、つまり同じかより小さいセットに対する切り捨てられた分布P0 tが得られます。実際、アドレスiが最初にxi個のトークンを持っていた場合、切り捨てられた後にこれらのトークンがすべて削除されることも、一部削除されることも、あるいはまったく削除されないこともあります。そのため、アドレスiにはx0 iトークンの票が残ります。このように、x 0S iと~x 0F iは、切り捨て後に残るスパーク票とFアセット票にそれぞれ対応しています。

定義 4.6. 投票期間tの切り捨てられた推定分布P0 tは、推定値fvigN0 t i=1 (ここでN0 t Nt)と、それに関連してx 0S iと~x 0F iから計算される重みfw0i gN0 t i=1で構成される。
i および ~x 0F i から計算されます。これらはそれぞれ Spark および F-Assets のアカウントホルダーの生存票です。
最後に，オラクルの出力は，結果として得られる分布の加重平均をとって計算できます。

定義 4.7. オラクルの推定値とは，投票ラウンドtにおいて，参加者の投票に基づいて計算された推定値である．これは，切り捨てられた推定値分布P0 tの加重平均をとることで計算され，mtと表す。

以下の2つの例では，オラクル推定値がどのように計算されるかを示している。簡略化のため、これらはすべてのパーティキングアカウントがスパークアカウントである場合を考慮している。

例 4.2. Alice，Bob，Charlie，Eveはそれぞれ10，20，30，20のFLRトークンを持ち，価格投票のラウンドtに参加を決めた。彼らは投票を選んだ唯一の4人の参加者である。保有量の加重で考えると、10+20+30+20=80票となります。アリスは3票、ボブは4票、チャーリーは5票、イヴは6票の投票を提出し、その結果、価格に関する分布Ptが得られます。 次に、上位25%と下位25%の票が破棄されます。つまり、上位20票と下位20票が削除されます。その結果、分布P0
tは，ボブが価格4に10票，チャーリーが価格5に30票投票したことになります。この分布の加重平均は，m = 10 40 4 + 30 40 5，すなわち m = 4:75 であり，これがオラクルの出力である．

例 4.3. Alice、Bob、Charlieはそれぞれ100、50、100のFLRトークンを持っており、価格投票に参加した。彼らは投票を選択した唯一の3人の参加者です。保有量の加重で考えると、100+50+100=250票となります。アリスは2票、ボブは3票、チャーリーは4票を投じ、その結果、価格に関する分布Ptが得られます。 次に、上位25%と下位25%の票を破棄します。すなわち、上位62.5票と下位62.5票を削除します。その結果、分布P0
tは、アリスからの価格2の投票が37.5票、ボブからの価格3の投票が50票、チャーリーからの価格4の投票が37.5票となり、合計125票が切り捨てられずに残ります。この分布の加重平均はm = 37.5/125*2 + 50/125*3 + 37.5/125*4、つまりm = 3:0となり、これがオラクルの出力となります。

より一般的には、計算すべき推定値がn個ある場合、投票を選択したスパークアドレスは、ラウンドごとに1票ではなく、n票のリストv = (v1; : : ; vn)を提出することになります。これにより、n個の推定分布が得られ、それぞれが切り捨てられ、n個の切り捨てられた分布が得られます。そして、この切り捨てられた分布のi = 1; : : ; nの加重平均miが計算され、n個のオラクル推定値m = (m1; : : ;mn)が得られる。

定義 4.8. Flare時系列オラクル(FTSO)は、以下のようにデータの推定値を提供する。ある投票ラウンドtにおいて

報酬

切り捨て後も分配に残った推定値を提出したスパークホルダーには報酬が支払われます。報酬のために鋳造されるスパーク・トークンの正確な量は、ネットワーク・ガバナンス・パラメータであり、当初は年間流通するスパーク・トークンの10%に設定されており、これをアワード・レートと呼んでいます（定義4.9参照）。定義4.9を参照してください。スパーク・トークンの保有者は、第5節に記載されているように、これを変更するために投票できます。なお、F-Assets保有者は参加できますが、報酬は得られません。その代わり，F-Assets保有者はF-Assetsに関連するデータの整合性を確保するために投票するインセンティブが与えられます。

定義 4.9. 付与率rAは、年初に流通しているFLRトークンの割合として、成功した投票（切り捨てを免れた投票）に付与されるFLRトークンの年間鋳造量です。デフォルトでは10%に設定されています。
年間の補償用トークンの総量は、ガバナンスのパラメータである年間の投票ラウンド数に応じて計算されます。これにより、スパーク保有者が各投票ラウンドで獲得できる報酬が決定される。

定義 4.10. 年間の投票ラウンド数kは、1暦年に発生する投票ラウンドの数である。
定義 4.11. 期間賞 A は、ある投票ラウンドで獲得できる賞であり、以下のように決定される。A = rA ST tot=k, ここで，ST tot は T 年目に流通しているスパークの総量，k は 1 年あたりの投票ラウンド数である。

例 4.4. 1年目に1440枚のスパークが流通していたとします（S1 tot = 1440）。既定の年率10%で144スパークが補償のために鋳造されます。k = 12の場合、投票は月単位で行われる（実際にはもっと頻繁に行われることに注意）。この場合、毎月12スパークが補償対象となります。

ラウンドtでn個のオラクル推定値が計算された場合、そのうちの1つだけが報酬を得ることができます。どれかを決定するために、チェーン上の擬似乱数発生器を使って、1からnまでの間の擬似乱数が引かれます（4.5項参照）。抽選された疑似乱数をkとし、1 k nとします。そして、k番目の分布の切り捨てに耐え、k番目のオラクル推定値の計算に貢献した票を持つアドレスに報酬を与えます。k番目のオラクル推定値の算出に貢献した票を持つ各アドレスiには、定義4.12に従って計算された補償額aiが与えられる。このように、投票ラウンドごとに新しいオラクル推定値が報われるため、参加者はすべての価格で投票するインセンティブが得られる。

定義 4.12. 賞金は、スパーク保有者の投票がオラクル推定値に貢献した場合、つまり切り捨てられずに生き残った場合に、スパーク保有者が受け取るスパークの量であり、以下のように計算される。N 0S tを切り捨てられずに残ったスパーク・アドレスの数とする。スパークアドレスiの賞は次のように与えられる。

for i = 1; : : : ;N 0St
例 4.5. 例4.4に続いて、金額12スパークが補償に上がったとする。例4.2では、BobとCharlieは切り捨てを免れたので、参加した分だけ補償されます。ボブの票のうち、50%が最終的に分配された票に貢献し、チャーリーの票は100%貢献しています。したがって，ボブは補償額の1/3，チャーリーは2/3，すなわちそれぞれ4スパーク，8スパークを得ます。

例 4.6. 例4.4に続いて、12スパークの金額が補償対象になったとする。例4.3では、アリス、ボブ、チャーリーは切り捨てられた後も生き残っているので、参加した分だけ補償されます。まず、生き残った票の割合を計算します。アリスとチャーリーの場合は37.5/100=0.375、ボブの場合は50/50=1となります。それぞれの重みを計算すると、アリスとチャーリーは0:375=(0:375+1+0:375)=0:375=1:75となり、ボブは1=1:75となる。この結果、AliceとCharlieには2:57Spark、Bobには6.86Sparkの補償が行われます。

重要な点は、十分な数のスパークアドレスが、ダミーの時系列や関連するFアセットを作成してFTSOに追加してシステムを不正に操作し、報酬を得る機会を増やしたいと考える可能性があります。そうすると、参加しているアドレスがFTSOに正直な推定値を提供するという経済的なインセンティブが損なわれる可能性があります。この問題に対処するために、Flare上のF-Assetsの数が1より大きい場合、各F-Assetsに値の閾値Qthresholdが課せられます。QFt Qthresholdであれば、補償スキームは前述のように進行します。しかし、QFt < Qthresholdの場合、F-Assetsは自分に関連する時系列にデータを提供する能力を保持していますが、その票は
報酬の計算には含まれなくなります。より具体的には、閾値を下回る各F資産について、F資産Fに関連するすべての参加アドレスiについて、加重推定分布Ptが~xFi=0で再計算され、そこから切り捨てられた分布が再計算され、この切り捨てられた分布に対して賞が計算されます。

オンチェーンで疑似乱数にアクセスする

各投票ラウンドにおいて、報酬スキームは1からnの間の乱数へのアクセスを必要とする。中央集権的な要素を導入せずにオンチェーンで乱数にアクセスは、ブロックチェーンの研究開発において活発な分野である[EJN17; Gil+17]。報酬を与えるデータフィードを選択するために、Flare時系列オラクルはオンチェーン疑似乱数生成器（定義4.13参照）に依存し、以下のように進行する。

各投票ラウンドtにおいて、参加しているアカウントは、自分の投票と一緒に1からnまでの乱数を提出しなければなりません。この数字を yi t とし，i = 1; : : : ;Nt とする。次に、これらの数字を足し合わせてYtという数字が得られます。n 個のデータフィードの場合、これは NS t + n Pn i=1 NFi t Yt n(NS t + n Pn i=1 NFi t ) を意味します。ここで、下限は各アカウントが 1 を送信した場合に対応し、上限は n です。次に、ハッシュ関数 SHA-256 を Yt に適用し、256 ビットの文字列、つまり 0 から 2256 までの数字を出力します。次に、この文字列をn倍し、その結果に1を加えて、1からnまでの整数を求めます。これが、4.13にまとめられたオンチェーン擬似乱数生成器の出力です。

定義 4.13. 各ラウンドtにおいて，オンチェーン擬似乱数生成器は，投票ラウンドtの各パーティキングアカウントiからのランダムな整数yi tを入力として，以下のように計算する。

オンチェーン疑似乱数生成器は，SparkとF-Assetsの両方の保有者が乱数提出に依存しています．なお、ネットワーク側では、送信された値が本当にランダムかどうかを確認できません。その代わり、システムは参加者が要求された乱数を提出するインセンティブに依存しています。スパークホルダーにとっては、報酬を得ることでスパークの保有量を増やすことがインセンティブとなります。もし参加者が結果が本当にランダムだと信じているのであれば、n個のデータの推定価格が本当だと信じているものを提出して、分布の切り捨てに耐えられる可能性が最大になるというインセンティブが働きます。対照的に、F-Assets保有者のインセンティブは、FTSOが正しく機能すること、つまり参加者が推定値に関して正直な投票を行うことです。

攻撃の受けやすさ

FTSOは、P + " 攻撃（But15）を受けやすいSchelling Coin（But14）で紹介されたアイデアを基にしている。FTSOは、スパークと貢献するF資産という暗黙のステークを導入し、各シリーズが異なるインセンティブを持つ少なくとも2組の参加者によって形成されるという点で、シェリングコインとは異なる。以下では、P + " 攻撃に対するFTSOの影響力について考察します。すべての既知の攻撃の定量的な分析は、FTSOの構造に必要な更新とともに、別途発表される予定である。

P + " [But15] 攻撃の特徴を簡単に説明すると、以下のようになります。二者択一の結果プロセスにおいて、参加者は報酬Pを得るために、大多数が投票すると思われる内容に従って1または0を投票します。各参加者は1票を持ち、参加者に制限はありません。攻撃者は、大多数が0票のときに1票を投じた人にP + " を支払うことを約束します。これにより，真偽にかかわらず，すべての参加者が1に投票するように経済的利益が歪められます。したがって、参加者の過半数が1に投票し、攻撃者は支払いをする必要がありません。シェリングコインのような価格決定メカニズムは、システムの参加者の大多数がどのように投票するかに依存しているため、P + " 攻撃の影響を受けやすい。これに対し、FTSOでは、トークンの保有量で投票を計量します。つまり、投票の結果は参加者の過半数に依存するのではなく、ステークの過半数に依存します。つまり、システムを破壊するためには、ステークの過半数を持つ保有者が所定の方法で投票する必要があります。

具体的には、P + " は、各参加者が 1 票を持つという事実に基づいています。つまり、投票は事実上、参加者に一様に分配されます。したがって、攻撃者は、参加者の50％以上を厳密に破損させる資本を持っていることを、信頼できる形で示さなければなりません。これをFlareに置き換えると、各アドレスは1トークンを持ち、委譲できない1の議決権を持ちます。

また、参加者は1つのアドレスしか持てません。つまり、100人の参加者がいた場合、攻撃者は51人の参加者にP + " を支払うだけの資本を証明しなければ、成功のチャンスを得れません。しかし、Flareでは、各トークンが1票に相当し、トークンは参加者に一様に分配されません。Flareに置き換えると、P + " 攻撃は、攻撃者が過半数のトークンの保有者を説得して、攻撃に参加させる必要があります。

この結果、攻撃者にとっては、攻撃を成功させるために最低限示さなければならない経済的コミットメントが、トークンの50％以上を占めなければならないという状況になります。しかし、トークンの50％以上を厳密に所有するフレアの参加者の最小セットは、50％強よりも合理的に多い量を所有する可能性があります。

この最小限の参加者は、保有しているトークンの一部のみに対する補償を受け入れないため、その最小限の参加者が保有するトークンの全てを補償する必要があります。このように、攻撃者は少なくとも、P + " の分析よりもはるかに大きな資本量を、信頼できるコミットメントとして示す必要があります。

第二に、P + " は参加者の大部分が利他的でないことを必要とするという点です。フレアでは 少数の参加者が利他的であっても過半数のトークンを所有しているというシナリオが発生する可能性があります。そうなると このような攻撃は不可能になります。

第三に、将来のどの時点でもトークンの所有権の分布が不明であることから、P+αの場合のように自動的に 第三に，将来の任意の時点でのトークン所有分布が不明であるため，P + " のように，攻撃者が将来の投票ラウンドで攻撃に成功し，その影響が現在のラウンドに逆伝播することを自動的に想定できません。のように自動的に想定できません。

最後に、参加者が投票するためには、スパーク・トークンまたはFアセットを所有していなければならない。したがって、すべての投票は、それぞれのトークンで表現される価値を持ちます。トークンによって表現されます。スパークの価値の一部はFTSOに由来しています。F-Assetsの価値は、次のようにリンクしています。F-Assetsにリンクされたアプリケーションの時系列を通じてオラクルとスパークの価値の両方にリンクされています。

したがって、もし オラクルが不正確な推定値の提供で実用性を失った場合、FLRトークンとF-Assetsの保有者の両方に大きな損失が生じます。かなりの損失となります。P + " 攻撃のインセンティブ構造をSpark保有者に再現するには，攻撃者は最低でも 攻撃者は最低でも攻撃前のP + " の値とSparkの損失額を提示しなければなりません。同様に，F資産家に対する 同様に、F資産保有者に対する攻撃構造を再現するためには、攻撃者は最低でもF資産の損失額を提示しなければなりません。

このような報酬は、攻撃者が次のような攻撃のインセンティブの合計に相当する額の資本を攻撃に投入した場合にのみ、信頼できるものとなります。十分な数のオラクル参加者に対する攻撃インセンティブの合計であり、各時系列においては これは、各時系列において、スケールされた投票の50％よりも厳密でなければならない。

経済的合理性を仮定すると，このようなコミットメントは，攻撃者が以下のような経済的メカニズムがある場合にのみ発生する。経済合理性を仮定すると，このコミットメントは，攻撃者が Spark と指定された F-Assets の単位価値が下がるごとに利益を得られるような経済的メカニズムがある場合にのみ発生する．の値が1単位下がるごとに攻撃者が1単位以上の価値＋P＋"を得られるような経済的メカニズムがあり、そのメカニズムが攻撃者に利用可能である場合にのみ、このコミットメントは発生する。このメカニズムは、非常に大きな参加者の保有比率をカバーする規模で攻撃者が利用できる。このようなメカニズムを提供するカウンターパーティまたはカウンターパーティ群は このようなメカニズムを攻撃者に提供するカウンターパーティは、それ自体が経済的に不合理なものである必要がある。そのため、攻撃は非常に起こり得ない。

Governance

FLRトークンは、Flareネットワーク、FLRトークン、Flare Time Series Oracle(FTSO)に対する主要なガバナンスメカニズムとして使用されます。これらの要素については、以下に詳述します。また、オプションとしてSparkを依存するアプリケーションのガバナンスに使用きます。これはアプリケーション自体が決めることであり、本稿では関係ありません。

ガバナンス決定からの更新のうち、自動化できるもの（自動化プロセス）と、そうでないもの（非自動化プロセス）があります。後者は通常、より複雑な手順を必要とし、例えばコードベースの変更を必要とします。

値の範囲を取得できる変数に関連する自動化プロセスは、システムへの衝撃を避けるために、ゆっくりと増加するように設計されています。緊急自動化プロセスは、スパークオーナーの間で、対象となる変数を迅速に変更する必要があるという一般的なコンセンサスが得られた場合に定義されます。

表1にFlareネットワークのガバナンス・パラメータを示す。決定事項は、ネットワークとその技術的パラメータ、FLRトークン、Flare Time Series Oracleのいずれに関連するかによって分類されている。

表1：Flare Networkのガバナンス・パラメータ。自動化が可能な決定は黒で示され、コードの変更を必要とし コードの変更が必要な決定、つまり非自動化と呼ばれる決定は青で示されています。

決定カテゴリー

ガバナンスの決定は、FLRトークンを使った投票によって行われます。FLRトークン1個につき1票とします。決定事項によってネットワークへの影響が異なるため、単純多数決（定義5.1）、超多数決（定義5.2）、超超多数決（定義5.3）の3つの決定ルールが規定されています。それぞれ、投票プロセスに参加するFLRトークンの数や、議案が可決されるための投票数に特定の要件が設定されています。フレア財団（セクション6）が保有するFLRトークンは、投票に使用できず、ガバナンスの目的では存在しないとみなされます。

定義 5.1. 単純多数決の場合、厳密には50％以上の賛成票があり、かつFLRトークン総数の30％以上の投票があれば、その議案は確定します。

定義 5.2. 超多数決の場合、厳密には投票数の3分の2以上が賛成で、かつFLRトークン総数の50％以上の投票があれば、その命題は確定する。

定義 5.3. 超超多数決の場合、FLRトークンの80%以上の賛成票が厳密にあり、かつFLRトークン全体の70%以上の最低投票数があれば、その命題は確定する。

決定は、ネットワークのインスタンス化に先立って定義されたカテゴリに分類されます。カテゴリー自体は、自動化されていないガバナンス・プロセスを通じて変更できます。

表2は、様々なシステム・パラメータに対するガバナンス決定カテゴリを示している。

表2: 意思決定のカテゴリー ガバナンスに関する意思決定は、それがネットワークに与える様々な影響に応じて、3つのカテゴリーのいずれかに分類されます。

直接投票と委譲投票

Flareはリキッド・デモクラシー4モデルを採用しており、トークン保有者は自ら投票も、自分のトークン（票）の一部または全部を委任も自由にできます。トークン保有者が自ら投票したり、一部または全部のトークン（票）を他のエンティティに委ねて、そのエンティティが自分に代わって投票するという流動的民主主義4モデルを採用しています（3.8で定義）。委任された議決権を集める議決権行使団体は 委任された票を集める投票主体は、任意の1人または複数の人で形成できます。そのようなエンティティの1つが、フレア財団です。

議決権行使に関する注意事項

以下のセクションでは、自動化された変数に対するガバナンス投票と、コードの更新が必要なより複雑な決定について説明します。投票は、3.9で定義されているように、アドレスの投票権に基づいて行われます。投票期間中にトークンがあるアドレスから別のアドレスに移動するようなガバナンスへの攻撃を避けるため、Flareはアドレスの投票力を投票期間の開始時の投票力に制限します。

定義 5.4. ガバナンス投票期間TGは、投票が行われるブロックの数である。

ガバナンスのためのアドレスの投票権は、TGの最初のブロックにあるアドレスの投票権とする。

自動化プロセス

自動更新可能な変数については、ネットワークのインスタンス化の際に初期パラメータが設定されます。自動更新が可能な変数は、二値であるか、実数の有限部分集合の値を取れます。

定義 5.5. 自動化された変数は、二値であるか、有限の値のいずれかを取る。ネットワークのコンセンサスによって設定される。

二値ではない自動化された変数の場合、変化の方向と大きさの両方について合意に達することは複雑になる可能性がある。そのため、このような変数では、特定の方向に変数を増加させるかどうかが、ステップのサイズではなく、ガバナンスの決定であるように、プリセットの増加が設定されます。これは、変数の作成者によって最初に設定されますが、それ自体が自動化された方法で統治できます。

定義 5.6. 変数の増分とは、特定の自動化された変数に関する、事前に定義された増分または減分のことである。

自動化された変数について、ネットワーク全体のガバナンス投票を行うためには、変数を増減させるための関心のある最小のプリセット閾値（またはバイナリの場合は状態を切り替える）に到達する必要があります。ガバナンス投票とは、変数の変更を決定するプロセスである。

定義 5.7. ガバナンス投票トリガーは、各自動変数に関連付けられたスマートコントラクトであり、以下のように実行される。

定義 5.8. ガバナンス投票は、ガバナンス投票が発生した場合に行われるネットワーク全体の投票であり、以下のように進行する。は以下のように進行する。

緊急自動化ガバナンス

自動化されたガバナンスプロセスは、システムと参加者が調整し、それに応じて自分のことを整理する時間を持てるように、ゆっくりと価値観を繰り返すように意図的に設計されています。しかし、場合によっては、より大きな調整を迅速に行う必要があるかもしれない。

各ガバナンス・トリガーの投票期間TGにおいて、投票権を持つアドレスは、現在の値から少なくともn + 2可変増分離れた提案された数値を入力できます（nは整数およびガバナンス・パラメータ）。これにより、現在の投票期間中に残る追加のガバナンス・トリガー提案が作成され、これに対して投票権を表明できる。5.7と同じルールが適用される。十分な票が集まった場合には、この値に対してネットワーク全体のガバナンス投票が行われる。そうでない場合は、現在のガバナンストリガーの投票期間の終わりに、新しいガバナンストリガーが削除される。複数の追加のガバナンストリガーを提案できるが、それらは互いに少なくともn個の変数増分である。

定義 5.9. 緊急ガバナンス投票トリガは、以下のように実行されるプロセスである。
自動化されたガバナンスによって変更可能な特定の変数について、その変数のガバナンストリガーを参照する。

非自動化プロセス

コードベースの変更を必要とするガバナンス決定の実施は、非自動化プロセスに従っており、定義5.10では、そのような変更のために行われる、発案から実施までの一連のステップを規定している。このようなプロセスが包含する意思決定のセットは幅広い。例えば、アプリケーションを追加または削除するために、依存するアプリケーショ ンのセットを更新するなどの決定が含まれる。これにより、FTSOでの価格フィードの追加や削除、セカンダリーユーティリティーフォークによるトークンの発行が必要になることもあります。

定義 5.10. 非自動化プロセスは以下のように進行する。

ある種の非自動化された決定は、スマートコントラクトを増強したり、新しいスマートコントラクトのセットを採用することで実施できる。しかし、その他の決定では、ノード運用者はFlare Networkのコードディストリビューションの新しいバージョンを採用する必要があります。注意しなければならないのは、ノードに新しいコードディストリビューションの実行を強制できません。自動化されていない方法論の目的は、潜在的に有益なアップデートを選別し、必要に応じてFlare財団の技術的専門知識を利用してアドバイスやアップデートの構築を行い、Costonをテストベッドとして利用し、投票によってそれらのアップデートにFLRトークンの重みを示すことにあります。このFLRトークンの重みが、そのアップデートを採用するノードのインセンティブになると考えられます。

SDAとSparkガバナンスの関係

SDA は、いくつかの定義された方法で Spark のガバナンスと関わります。

FTSO にデータストリームを追加したい SDA または SDA 候補は、自動化されていないガ バナンスプロセスを使用して追加を提案するが、成功する場合もしない場合もある。SDA または SDA 候補は、スパーク・トークン・ホルダーの集合体の同意を得ずに、いつでも 全部または一部をスパーク・トークン・ホルダーのガバナンスセットとして使用できます。
スパーク・トークン・ホルダーの参加は完全に任意である。

Flare foundation

このセクションは、Flareの基盤の概要を説明するためのものです。完全な規約は別途公開される予定です。

Flare 財団は非営利団体であり、ネットワークの開発と改善に参加を目的としています。当財団は、助成金、投資、直接のソフトウェア開発、教育コンテンツ、広報・パートナーシップの5つの方法でこれを行います。

哲学を導く。

正しく運営されていれば、財団はエコシステムがコミュニケーションをとり、イノベーションを起こし、さらに発展するための結集点となるはずです。財団は、ネットワーク内で過剰な力を持つべきではなく、また、ネットワーク上で動作する経済プロセスを妨害したり、歪めたりするべきではない。そのために、財団は、定義6.1に示すような一連のルールに縛られている。

定義 6.1. 財団の規則は、以下の5つの規則で構成されている。

投票はしない。フレア財団は、ネットワークの集合的な意思の実現を目的としています。ガバナンスプロセスにおける財団の役割は、提案に対する意見や技術的な分析を行い、受け入れられた提案実施の支援です。財団は、ガバナンスプロセスのいかなる段階においても、保有するトークンを使用して投票できません。

担保なし。財団のトークンは、依存するトークンの担保として使用されません。実際、FXRPシステムのような依存性のあるトークンの担保の需要と供給は、財団がその担保をこれらのアプリケーションに展開して歪められます。

オラクルは参加しない。時間の経過とともに、財団が他の参加者と比較して重要性を下げていくことが望ましいです。最初に大量のトークンを保有し、賢明な財務管理と組み合わせることで、ネットワークが牽引力を得れば、財団が十分に長い期間その任務を果たせ、期間の終わりには財団が必要とされなくなることを確認するのに十分なはずです。したがって、財団はFTSOに参加しません。

事実上、FTSOの受賞率は、他の参加者の集合的な所有権と比較して、財団の所有権の割合が減少する速度の指標となる。なお、スパーク・トークンの価値が変動したり、スパーク・トークンを使った投資がプラスのリターンをもたらす可能性があるため、財団の純資産が必ずしも並行して減少するわけではありません。

解散の権利。ネットワークは、必要に応じて財団を解散する権利を有しています。これは、財団の法的構造の細則に、ネットワークが解散を決議した場合には財団を解散しなければならないという規定を設けて実現しています。このような投票が行われた場合、財団を直ちに解散させるのは現実的ではなく、不可能である可能性が高いです。

しかし、財団は60日以内に事業を縮小し、資産を清算し、保有するトークンを消滅させる計画を提出します。スパーク以外の資産は、スパーク・トークンの購入に使用され、その後焼却されます。

報告。透明性は重要です。財団は6ヶ月ごとに報告書を発行し、スパーク・トークンの販売、従業員の報酬、経費、その他の資金の使用、投資、助成金などの詳細を報告します。

付録：スマートコントラクト層内でのUNLのエンコード

外部システムの状態に関するコンセンサスを計算するために、クレーム期間の最終性システムがスマートコントラクト層でUNL定義にアクセスする場合、利用されるUNLは各ノードオペレータがネットワークレベルのコンセンサスに使用するUNLと一致しなければならない。

しかし、スマートコントラクトレイヤーは一貫性のあるノード間で統一された実行とその結果としての状態を必要とするため、これは困難である。つまり、一貫性のある異なるノード間でクレーム期間システムの最終性を制御するスマートコントラクトレイヤー内でUNLのユニークな定義をエンコードする明白な方法がないということである。

本セクションの残りの部分では、請求期間の最終性システムなどの契約を制御するために、スマートコントラクト層内でユニークなUNL定義のエンコードを可能にする新しいソリューションを提示する。そして、このアプローチを使用する際のエンジニアリング上の検討事項について説明します。

ノードごとにcoinbaseのカスタム値を使用してUNL定義の配列にインデックスを作成する

ビットコインのようなリーダー型ネットワークでは、1人のノードオペレータが各ブロックの定義をコントロールします。このノードオペレータは、ブロックごとに、例えば、プルーフ・オブ・ワークの課題を解決したり、プルーフ・オブ・ステークネットワークで所有するステークの量に応じて疑似乱数アルゴリズムによって選択されたりして、コントロールされるように選択されます。

このようなネットワークでは、リーダーノードの受益者アドレスは、ブロックをコントロールしていることに報酬を与えるために使用され、coinbaseアドレスと呼ばれるブロックにエンコードされたフィールドを使用して示されます。Flare Networkはリーダー不在のネットワークであり、コンセンサスの安全性が経済的インセンティブに依存していないため、coinbaseフィールドは使用されていません。しかし、スマートコントラクト層は、リーダーベース、リーダーレス、経済的インセンティブ、非経済的インセンティブなど、さまざまなコンセンサストポロジーに柔軟に対応できるように構築されているため、Flare Networkでは、スマートコントラクト層を活用して、coinbaseフィールドへのアクセスを可能にしています。
スマートコントラクト層は、リーダーベース、リーダーレス、経済的インセンティブ付き、非インセンティブ付きなど、さまざまなコンセンサストポロジーに柔軟に対応できるように構築されています。したがって、coinbaseフィールドはFlare Networkのネットワークレベルのコンセンサスに影響されないため、各ノードオペレータはcoinbaseフィールドをローカルに自分のアドレスに設定できます。

これは、各ローカルノードでのスマートコントラクト実行中に、coinbaseフィールドが参照されるたびに、実行ノードのアドレスが返されることを意味します。

クレーム期間の最終性を計算する目的で、coinbaseのユニークな値は、スマートコントラクトレイヤー内のUNL定義の配列へのインデックスとして使用されます。実行時には、請求期間の最終性を計算するコードは、coinbaseアドレスを使ってUNL配列にインデックスを付けることを求める行に到達する。このアドレスはノードオペレータごとに異なり、ノードオペレータのマシンで実行されると、そのノードオペレータのUNL定義にインデックスされる。

アプローチのための工学的考察

しかし、各ノード事業者ごとにコインベースの固有値を活用する際には、2つのエンジニアリング上の考慮点があります。1) コインベースのユニークな値を利用する契約では、取引コストを一定にすること、2) コインベースのユニークな値を利用するのは、stateconnector finality system のようなガバナンスが承認した契約に限ること。

1つ目の技術的配慮の理由は、トランザクションのガスコストは計算ステップ数だけでなく、計算に関わるデータ値にも依存するため、coinbaseのユニークな値は計算実行時に異なるガスコストを発生させることになるからである。2つ目の工学的考察の理由は、coinbaseのユニークな値が、オーダーメイドのスマートコントラクトで誤って利用され、ノードの状態間の不整合を意図的に引き起こす可能性があるからです。

ステートコネクターファイナリティシステムでは、コインベースの固有値を特定の安全な方法で活用することで、ステートコネクターファイナリティシステムが必要とするUNLコンセンサス機能を実現しつつ、ノードの状態間の不整合を防止しています。