概要：（１）基本的な仕組みで[透明性、説明責任、運用堅牢性の3つのOracle欠落点]に対処＋データ投稿スケジュールの保証、（２）罰金、（３）統制、（４）読専入力によるコアインフラ化、（５）コピペ攻撃回避、（６）ダイナミックエントリー、（７）階層設計（第一層がオラクル、第二層がオラクルプール、第三層にオラクルプールのプール、第四層に署名付初回投稿プールとの統合）。Ergoでまず実験進める。
（１）基本：データ提出期間に複数のOracleがposting priceを支払いデータを提供→データ確定時にすべてを集計し、平均値確定値を出したオラクルはposting priceが2倍となって戻され、適切なデータを提供したオラクルにposting priceが戻される（提出しなかったり、外れ値を提供すると、posting priceが戻されなかったりステークが削減されたりする）
（２）罰金：参加前に、預け金を払い（事前に決め、ガバナンスで制御）、データを送らない、集計ミス、外れ値の場合に罰金として差し引かれる。
（３）ガバナンス投票：パラメータ（75％同意でパラメータ変更可能（転記価格、エポック長さ、担保、オラクル数）：変更量は事前に制限する）、エントリー（投票により新たなオラクルになれる仕組み、追加されたオラクルはしばらくこの投票には参加できず、一定の投票で排除される）、投票期間（データポイント提供時か、それ以外のダウンタイム中か。前者はタイミングはシンプルだが構造が複雑に。）、外部アクター投票（ガバナンストークンを外部者や両方に付与）
（４）読込専用入力によるコアインフラ化：大規模なデータセットを提供するとそれだけスラッシングにより不正をしづらくなり、提供されるデータは読取専用入力により無料でデータを読み取れ、公共材のようになり、dAppが小学の資金を要求することも可能。
（５）データポイントコピー攻撃（最初にデータ投稿されたオラクルデータをコピーすること）阻止2つの方法：①直接防止：エポックはハッシュ送信期間とデータポイント公開期間の2つの期間に分割。複雑で短期間にたくさん投稿するものに向かない。②最初にデータを一定確率で送信させる（最初に送信されることになるとコピペできない）：リーダーの投稿期間とその他の投稿期間に分割。（※なお、この攻撃はすぐにきづくことができ、気づかれるとユーザーの信頼を失い損をすることになるので直ちに重大な問題ではない。ガバナンスで投票排除も可能で排除しないと競合がサービスを作るのも簡単。）
（６）ダイナミックエントリOracleプール：無許可型。かなりリスクはあり、解決には注意が必要だが、品質を向上できる。例：成功トークン：既存オラクル＋見込みオラクルが外れ値でないオラクルを投稿すると付与。見込みオラクルは既存オラクルより前に投稿して外れ値でなければ成功トークン。成功トークンが一定以上多い、または多い順に参加可能とする。
（７）４層階層構造：１層目オラクル達、２層目オラクルプール、３層目オラクルプールをまとめるプール（コストと速度が犠牲になるが信頼性強化される、拡張UTXOのサブプロトコルを同時実行する機能で効率的に実施可能、オラクルプールにインセンティブ機能があるため機能するもので、現在の典型的なスキームでは実現できない）、４層目署名済みデータポイントFirst-To-Post Oracle Pools提供するものと統合：Coinbaseなどの有名で信頼できる企業の署名付きデータをそのまま渡すオラクル…最初に渡したプールに報酬が出る（やすく、早く、高保証）これは簡単に無許可型にできる…コンセンサスが必要ないため。
2 Likes