Flare改善提案 (FIP) 全履歴

背景・課題

FTSO（Flare Time Series Oracle）は分散型価格オラクルですが、複数プロバイダー間の不自然な統計的相関（データ複製・談合）などの不正行動を迅速に検知し、プロトコルの信頼性を担保する自律機構が求められました。

主な仕様変更・決定事項

• データプロバイダー代表等で構成される自主規制委員会「FTSO Management Group」を設立。
• データ提供の不正（同一ノードからの重複提出、同一エンティティによる実質同一コードベースでの提出）を調査・報告するフローの制度化。
• 価格ペアの追加やパラメータ更新提案の検証とガバナンスへの上程プロセスの整備。

背景・課題

従来の四分位（中央値周辺の25%〜75%）のみに報酬を与える仕組みでは、特定の大手プロバイダーへ委任が集中しやすく、中央値狙いのアルゴリズムによる脆弱性や寡占化が懸念されました。

主な仕様変更・決定事項

• プライマリ・リワード・バンド（主帯域）に加え、より広い許容誤差範囲を持つ「セカンダリ・リワード・バンド（第2帯域）」を新設。
• 適格と認められるデータプロバイダーの報酬獲得機会を拡大。
• 特定少数への極端な集中を防ぎ、データソースの多様性と中央値操作耐性を強化。

背景・課題

FlareおよびSongbird上のDeFi（DEX、レンディング）やFAssetsの展開に向けて、市場の需要に応じた多様なトークンペアの公式価格フィードが必要とされていました。

主な仕様変更・決定事項

• 主要暗号資産（BTC, ETH, XRP, DOGE, LTC, ADA, ALGO等）の価格フィード仕様を最適化。
• 需要の低い一部ペアを整理し、ネットワーク帯域を空けて新規通貨ペアを追加。
• プロバイダーの算出負荷とオンチェーンガス消費のバランスを調整。

背景・課題

Flareは当初FTSOへの委任が中心でしたが、Snowmanコンセンサスを保護する独立したPoSバリデータ層の確立と、ステーク資本による経済安全保障の強化が不可欠でした。

主な仕様変更・決定事項

• ネットワークインフレ報酬の配分比率を変更：30%をバリデータステーキング報酬、70%をFTSOプロバイダー報酬へ設定。
• 単一事業者が運用可能なバリデータノード数を最大4ノードに制限し、特定エンティティによるコンセンサス支配を防止。
• P-Chain（プラットフォームチェーン）でのステーキングとC-Chain（EVM）のFTSO委任を連携させるステーク鏡像化メカニズムを実装。

背景・課題

FTSOとState Connector（現FDC）が個別の枠組みで稼働していたため、プロトコル拡張時のオーバーヘッドが課題でした。DeFiの高速・大規模化に対応するため新統合プロトコルが必要とされました。

主な仕様変更・決定事項

• 「Flare Systems Protocol (FSP)」を導入し、FTSO、FDC、将来の新規プロトコルを単一の提出・集約エポック基盤で統合。
• FTSO Scalingプロトコルを実装し、最大1,000フィードまで同時配信可能なプロトコル圧縮仕様を定義。
• 署名集約アルゴリズムを刷新し、バリデータとデータプロバイダーのオンチェーン提出負荷を大幅削減。

背景・課題

アンカー更新は多くのプロバイダーの集計による安全な確定値ですが、パーペチュアルDEXや高頻度取引、リアルタイム担保清算にはブロック単位の俊敏な価格更新が求められていました。

主な仕様変更・決定事項

• 1〜2秒ごとのブロック生成に合わせて超低レイテンシで価格を配信する「Fast Updates」を本番稼働。
• 各ブロックでプロバイダーをランダム抽出して提出させることで、単一プロバイダーによる価格操作リスクを防止。
• FTSO向けインフレ報酬の内、30%をFast Updates提供プロバイダーへの報奨に充当。

背景・課題

FIP.06でFTSOの容量が飛躍的に拡大したことを受け、市場需要の高い銘柄を迅速に追加し、今後の新規フィード追加フローを制度化する必要がありました。

主な仕様変更・決定事項

• 既存の18フィードに加え、19種類の新規暗号資産価格フィードを追加。
• FTSO Management Groupが主導し、透明な基準（流動性、取引所数、API信頼性）を満たすフィードを追加できる標準プロセスを策定。
• Songbird（STP）での先行検証とパラメータ整合性の確認手順を明文化。

背景・課題

Flareの「内蔵オラクルネットワーク」の理念に基づき、全プロトコルが同等のセキュリティで稼働するため、特定プロトコルのみ参加して他を放置するフリーライダー問題を解消する必要がありました。

主な仕様変更・決定事項

• FTSO Scaling、Fast Updates、FDCの各プロトコルにおいて、エポックごとの最小提出率・正常稼働率基準を定義。
• 全プロトコルで基準を満たしたプロバイダーに報酬を付与し、不合格となったプロバイダーはそのエポックの受給資格を喪失。
• バリデータとオラクル事業者が最高品質の統合インフラを維持するインセンティブを制度化。

背景・課題

FTSO v2の本格稼働に伴い、プロバイダーの運用コストやステーキング利回りの市場均衡を維持するためのパラメータ微調整が必要でした。

主な仕様変更・決定事項

• エポックごとのインフレ報酬計算ロジックにおける係数と報酬プール配分を最適化。
• プロトコル監視・パラメータ提案を行うガバナンス分析手法（メソドロジー）を公式化。
• 誠実に行動する広範なプロバイダーが安定して運用継続できる経済的持続可能性を担保。

背景・課題

XRPLやビットコインなど外部ブロックチェーン上の事実をスマートコントラクトで検証する基盤として開発されてきたState Connectorが、FDCとして最終仕様へ昇華しました。

主な仕様変更・決定事項

• FDCプロトコルコントラクトをFlareメインネット上に本番デプロイ（State Connectorの後継・代替）。
• ネットワークの年間インフレの一部をFDCプロトコル報酬に配分し、プロバイダーの参加を経済的に動機付け。
• XRPL支払い検証、ビットコイン取引検証、EVMトランザクション検証などの基本アテスト型を有効化。

背景・課題

単純な取引所価格だけでなく、DeFiではリキッドステーキングトークン（stETHやsFLR等）の裏付け資産比率やボラティリティ指数などの特殊フィードが強く求められていました。

主な仕様変更・決定事項

• オンチェーンのスマートコントラクトロジックで値を導出する「カスタムフィード」カテゴリをFTSO上に新設。
• FTSOのブロック遅延フィード（LTSインターフェース）と同じ標準規格でdAppsへシームレスに提供。
• カスタムフィードに対するデータプロバイダーの提出・合意アルゴリズムと検証コストを最適化。

背景・課題

Web3アプリケーションが実世界のWeb2サービス（金融API、天候、ソーシャル、AI推論API）と連携する際、特定の中央集権サーバーに頼らない暗号学的証明が不可欠でした。

主な仕様変更・決定事項

• FDCにWeb2 APIエンドポイントからのHTTP/JSONレスポンスの正当性を証明する新アテステーション型を導入。
• FTSO Management Groupの枠組みの下でWeb2アテストソースを追加・更新・削除する標準化プロセスを制定。
• デフォルトのアテステーション手数料メカニズムを確立。

背景・課題

取引高が激減したり上場廃止となったトークンのフィードがFTSOに残り続けると、プロバイダーが虚偽データや市場操作に巻き込まれ、オラクル全体のセキュリティリスクになります。

主な仕様変更・決定事項

• 主要取引所のスポット市場データに基づく市場品質評価指標（取引所カバレッジ、流動性基準）を定義。
• 基準を満たさないフィードの検知からウォッチリスト掲載、そして最終的な廃止に至る透明なパスを確立。
• dAppsやユーザーに対する事前警告期間を設け、ダウンストリームへの影響と市場健全性リスクを最小化。

背景・課題

FlareDrops（36ヶ月）が完了した後の運用経済期において、トークンの継続的インフレを抑え、ネットワークの実際の経済活動（FAssets、FDC、DEX取引）が直接FLRの価値向上と供給削減につながる持続可能な仕組みが必要でした。

主な仕様変更・決定事項

• インフレ率の改定：年間5%（上限50億FLR）から、目標年率3%（年間上限30億FLR）へ大幅引き下げ。
• ガス代ベース料金の引き上げ：EIP-1559形式の基本ガス料金を従来の20倍に引き上げ、トランザクションに伴うFLRバーン量を一気に20倍化。
• FIRE（Flare Income Reinvestment Entity）の創設：FDC手数料やFAssetsシステム収益などプロトコル自体の収入を原資として、市場からFLRを買い戻して永久バーンする自律機構を設置。
• ステーキング報酬重み付けの調整：P-Chainでのバリデータステーキングのインセンティブを、C-Chainの流動委任に対して5倍の重みで評価。