STP.06とFIP.06のガバナンス提案 STP.06とFIP.06のガバナンス提案が間もなく投票を開始する。これらの提案には、Flare Time Series Oracle (FTSO)のキャパシティをFlareとSongbirdの両ネットワークで拡張するために必要なアップデートが含まれている。

FTSO

FTSOはFlare上で動作するシステムで、中央集権的なプロバイダーに依存することなく、Flare上のDappsに分散型のデータフィードを配信する。現在利用可能なデータフィードは暗号通貨の価格ペアのみで、例えばBTC USDなど。サポートされているフィードは、ADA、ALGO、ARB、AVAX、BNB、BTC、DOGE、ETH、FIL、FLR（Flare上）、SGB（Songbird上）、LTC、MATIC、SOL、USDC、USDT、XDC、XLM、XRPです。

グーグル・クラウド、Ankr、Figmentなどの独立したインフラストラクチャー・プロバイダーは、システムにおいて重要な二重の役割を担っている。彼らはバリデーターとしてネットワークの安全性を確保し、データ・プロバイダーとしてFlareのオラクルに貢献する責任を負っている。

安全な分散型システムを実現するため、中央集権型や分散型の取引所などの外部ソースからデータを取得し、FTSOシステムに供給する。この情報は各プロバイダーの投票力（コミュニティから委任されたトークンの量）に応じて重み付けされ、重み付けされた中央値が計算されて最終的な推定値が算出される。

FTSOのスケーラビリティ

現在のFTSO（v1）は、主にオンチェーンのスマートコントラクトとして実装されている。現在、18のデータフィードの更新を180秒ごとに提供している。

より高速な更新と多種多様なデータを必要とする新しいユースケースをサポートするために、よりスケーラブルなシステムの再設計が必要でした。FTSOスケーリングにより、データプロバイダーは90秒ごとに最大1000のデータフィード（暗号通貨の価格ペア、株価、気象データなど）を提供できるようになる。

提案されている新しいデザインは、計算がオフチェーンで実行され、メルクル・ルート・ハッシュとして知られる、すべてのデータ・プロバイダーの結果をロールアップした表現のみがオンチェーンに保存されるため、よりガス効率が高い。このような表現により、オン・チェーン・データは、オン・チェーンで計算を実行し、個々の価格をすべてオン・チェーンに保存するよりも軽量でスケーラブルになる。

プロトコルが改善されたことで、より多くのデータ・フィードを提供できるようになった。まずは約25の暗号通貨価格ペアのフィードが追加される。また、開発者の要望に基づき、株式、債券、コモディティ、FXなどの暗号資産を段階的に追加する計画もある。

FTSO Scalingは、将来のガバナンス提案の対象となるFTSO Fast Updatesと混同してはならない。FTSO Fast Updatesは、1-2ブロックのレイテンシ（約1-3秒）で、dappsがオンデマンドでデータを要求し、支払うことを可能にする。ガバナンス提案がFlareコミュニティによって承認されれば、FTSO ScalingとFTSO Fast Updatesの組み合わせがFTSO v2のビジョンを実現することになります。

フレア・コミュニティの役割

Flareコミュニティは、これまでと同じようにFTSOと関わっていく。これらの変更は技術的な変更です。これまで通り、FTSOデータプロバイダーに委任し、委任報酬を請求することができます。

データプロバイダーの役割

FTSOスケーリングでは、データ・プロバイダーは価格ペアのような有用な情報を提供し続ける。中央値から離れすぎたデータ（外れ値）は除去され続ける。その結果、データの推定値は報酬を受け、オンチェーンで利用可能になる。データ・プロバイダーは、すべてのデータをコミットできるようにするコミット・プロセスを引き続き使用する。コミットフェーズでは、一部のデータプロバイダーが他のデータプロバイダーの推定値を見ることによって不正を行うことなく、推定値を提出することができる。公開フェーズでは、データ提供者がコミットされた推定値にアクセスして検証できるようにする。

承認されれば、FTSOスケーリングは2つの新しいフェーズを導入する：サイン・フェーズとファイナライゼーション・フェーズである。

サインフェーズでは、データプロバイダーはコミットと一致しない公開をフィルタリングします。フィードの中央値と報酬を計算するために、有効な暴露のみが使用されます。結果はコード（"ハッシュ"）で表され、データプロバイダーがそれに署名します。
最終化フェーズでは、十分な投票ウェイトの署名が提出されると、どのエンティティもそれらを収集し、投票スマートコントラクトに提出することができる。提案された署名が累積して必要な重みのしきい値（すべての適格なデータ提供者の総重みの少なくとも50%）に達するかどうかを検証するためのチェックが実行される。成功した場合、Merkle Rootは、指定された投票ラウンドIDの投票コントラクト上で公開される。その後、計算結果を検証するためにデータを使用できる他のすべてのスマートコントラクトが利用できるようになる。

報酬分割

FTSO (v1)と同様、データ提供者は中央値に近いデータを提出することで報酬を受け取ることができる。ガバナンス提案が承認された場合、FTSOスケーリングが完全に実装されたとき、利用可能なFTSOデータ提供報酬総額のうち主要なシェアである80%が、これを達成したデータ提供者に引き続き分配される。

同様に、FTSOスケーリングが完全に実装された場合、署名フェーズで署名を提出し、最終化フェーズで最終化をトリガーした場合にも報酬が支払われる。署名フェーズの署名提出については、有効な署名を1つ提出したデータ・プロバイダーに、データ提供報酬の10%が分配される。FinalizationフェーズでFinalizationをトリガーする場合、最大5つのエンティティがFinalizationを実行できる。利用可能なデータ提供報酬の10%は、これらのデータ提供者に支払われる。

罰則

FTSOスケーリングは、データ・プロバイダーに対して、レバレルの保留や二重署名のペナルティを課す：

保留を明らかにする：データ提供者は、公開されたデータのハッシュがコミットされたデータのハッシュと一致することを検証できなければならない。コミットデータのハッシュが省略されたり、一致しなかったりした場合、それはReveal Withholdingと呼ばれ、ペナルティが課される。
二重署名：同じ投票ラウンドにおいて、無効な署名または複数の結果に対する署名を行うことは、ダブルサインと呼ばれ、罰則の対象となります。

どちらの場合も、ペナルティは、違反したデータ・プロバイダーのその投票ラウンドにおける報酬の予想相対シェアの30倍となり、報酬エポックの終了時に報酬総額から差し引かれる。差し引かれる金額の上限は、そのエポックにおけるデータ・プロバイダーの報酬総額に等しい。差し引かれた金額は燃やされる。

展開フェーズ

FTSOシステムを最大1000のデータフィードに対応させるためには、一連の大幅なアップデートが必要となる。Flare Foundationがテストし、データプロバイダーが変更に適応するための時間を確保するため、承認された場合、アップデートは試験段階、ベータ段階、非推奨段階から構成される。

これらのフェーズでは、現行のデータプロバイダーとアップグレードされたデータプロバイダーが共存する。現在のデータプロバイダーとは、既存のFTSO（v1）コードを実行しているプロバイダーを指し、アップグレードされたデータプロバイダーとは、FTSOスケーリングを含む新しいコードを実行しているプロバイダーを指します。Flareの総インフレ率の70%は依然としてFTSOデータ提供の報酬に充てられますが、それは以下の方法でデータプロバイダーに分配されます：

試行段階：現在のデータプロバイダーは、FTSOデータ提供報酬の100％を引き続き受け取るが、アップグレードされたデータプロバイダーは報酬を受け取らない。
ベータ段階：このフェーズでは、フレア財団はインフレ契約を更新し、現在のデータプロバイダーがFTSOデータ提供の報酬配分総額の50％を受け取り、アップグレードされたデータプロバイダーが残りの50％を受け取るようにします。この時点で、すべてのデータプロバイダーが報酬を請求できるようになります。例えば、ベータ期間中に100のFLRインフレが発生したとします。現在のデータ・プロバイダーには50FLRが分配され、アップグレードされたデータ・プロバイダーには次のような分配が行われる：中央値で40、有効な署名提出で5、最終決定への貢献で5。
非推奨フェーズ：このフェーズでは、フレア財団はインフレ契約を再度更新し、アップグレードされたデータプロバイダーだけが報酬を受け取れるようにします。したがって、上記の例のインフレ量である100FLRでは、アップグレードされたデータプロバイダーは完全な分配を受けることになります：80は中央値への近さ、10は有効な署名の提出、10は確定への貢献です。