複数の @NewtonProtocol オペレーター間の合意が、それでも誤った外部の値を生みうるのはなぜかについて、しばらく調べました。
最初は、中央値によるコンセンサスが自然な保護のように見えました。
1人のオペレーターが通常とは異なる価格を報告し、他のオペレーターが類似した値を返している場合、その中央値は外れ値の影響を減らします。
しかし、その保護が最も効果を発揮するのは、オペレーターが独立して失敗するときです。
より難しいケースは、複数のオペレーターが同じ上流ソースに依存しているために同意してしまうときに現れます。
5人のニュートン・オペレーターが別々のインフラで動いている状況を想像してください。それぞれのオラクル要求は独立しているように見えますが、各要求は最終的に、同じ基礎となる価格フィードに依存するプロバイダーへ解決されます。
市場の急な動きの間に、そのフィードは遅れてしまいます。資産はすでに約$80近辺で取引されているのに対し、共有された情報源はなお、約$100に近い値を報告しています。
オペレーターはわずかに異なるタイミングで問い合わせるため、応答は同一ではありません。あるものは99.8を返し、別のものは100.1を報告し、残りの値は同じ範囲に近いままです。
分散は健全に見えます。各応答は、設定された許容範囲の中にとどまっている可能性があります。中央値は安定しており、ポリシーには、複数のオペレーターによって支持されているように見える基準となる価格（canonical price）が渡されます。
それも誤りです。
ここで重要なのは、この区別です：
オペレーターの多様性は、必ずしも情報源の多様性を自動的に生みません。
中央値は、報告された値がどこに固まっているかをシステムに伝えます。孤立した外れ値を抑え、遅延や更新タイミングによって生じる通常の差を滑らかにできます。
それらの値が、独立した観測から来たのか、複数のマシンで繰り返された1つの共通の誤りから来たのかは明らかになりません。
それにより、相関した失敗は、目に見える不一致よりも危険になります。
孤立した誤りは摩擦を生みます。
共通の上流エラーは、確信を生みます。
ニュートンの実行経路の残りの部分は、まだ正しく振る舞うことができます。オペレーターは、意図されたポリシーを基準となる入力に対して評価し、同じ結果に署名できます。結果として得られるアテステーションは、その入力と整合したままになり得て、アプリケーションのバリデータは、実行前にそれを受け入れられます。
すると、融資申請は報告された担保価値が必要な閾値を上回ったままであるため、引き出しを承認してしまうかもしれません。実際の市場価格ならポリシーはこれを拒否すべきだったのにです。
どのオペレーターも、不正を働く必要はありません。
失敗は、オペレーターの集合の下から始まります。
だからこそ、オペレーターの数を数えるだけでは不十分です。別々のエンドポイントが1つのキャッシュを共有することがあります。同じ取引所のフィードを、異なるデータベンダーがライセンスしているかもしれません。独立したマシンが、1つの提供者に対して同一のオラクルコードを実行することもあります。
したがって、ネットワークはオペレーター層では分散しているように見えても、データ層では集中しているままになり得ます。
そのリスクを減らすには、集計の前に統制が必要です。
ポリシーには、リクエストに紐づいた厳格な鮮度制限とタイムスタンプが必要になる場合があります。オラクルの設計では、同じデータに対する複数のインターフェースではなく、真に独立したソースの系統が必要になるかもしれません。さらに、座標（coordination）層は、報告された値とその出所の間に十分な分離を確立できないときは、クローズドで失敗する必要がある場合もあります。
しかし、独立性は証明しにくい。
2つの提供者は無関係に見えても、同じ取引市場の場を利用していることがあります。バックアップのエンドポイントは、プライマリのものとインフラを共有できます。きれいな中央値は、それらの関係を隠すことがあります。なぜなら、集計は値だけを見て、それらの背後にある完全な依存関係の連鎖までは見ないからです。
ニュートンの中央値コンセンサスは、オペレーター間の通常の意見相違を減らせます。
合意が独立した証拠ではなく、共有された盲点を反映しているときに、その限界が見えてきます。
重要なのは、同じ答えを返したオペレーターが何人かだけではありません。
それが、ニュートンが「現実への、真に独立した経路がいくつ作られ、その答えを生み出したのか」を判断できるかどうかです。
@NewtonProtocol #Newt $BEAT $DEXE $NEWT
