おそらく本来よりも時間を取らせてしまう癖があります。何かの技術的な説明を読んでいて、その説明が実際に解こうとしている問題が分からないと、私はそこで止めて最初に戻ります。問題がはっきりするまで前に進むことを拒みます。だって、壊れているものが理解できなければ、その修正が本当に機能するのかを判断できないからです。
じゃあここでニュートンの二段階コンセンサス設計を使ってやってみます。まず問題。次に解決策です。
十分に語られない問題
分散ポリシーネットワークが実際にどのように動くのかを掘り下げ始めるまで、私はこれを明確に考えていませんでした。トランザクションが、決済前にライブデータに対してチェックされるとき、そのチェックは「クリーンで単一の真実の情報源」に対して行われるのではありません。複数の演算子からなるネットワーク全体で行われ、その各演算子は、まったく同じ瞬間に少し異なる情報を見ている可能性があります。
実際のところ、「ライブデータ」とは何を意味するのでしょうか。制裁リストが更新される。ウォレットアドレスがフラグ付けされる。価格フィードがティックする。こうした更新は、すべての演算子にまったく同時には届きません。ある演算子は、別の演算子よりも2秒早く更新された制裁リストを持っているかもしれません。ある演算子は、ネットワークのどこかでルーティング遅延があるせいで、少し遅れた価格フィードを動かしているかもしれません。
ここで評価のためにトランザクションが入ってきます。演算子Aは、それに最新の制裁アップデートを含むデータで照合します。演算子Bは、そのアップデートがまだ反映されていないデータで、まったく同じトランザクションを照合します。片方は通すと言い、もう片方はブロックせよと言う。ネットワークは意見の不一致状態になり、誰もそれを原理に基づいて解決する仕組みを作り込んでいません。
ここで明確にしておきたいことがあります。見落とされがちな点だと思うからです。これは例外ケースでも最悪のシナリオでもありません。これは、リアルタイムデータを扱う分散システムの「通常の状態」です。データは異なる時刻に異なるノードへ到着します。ネットワークがそう振る舞うのは当然のことです。問題は、システムがそれを正直に扱う設計になっているか、それともタイミングが問題にならないことを黙って期待しているだけかです。
なぜ金融データだとこれが難しくなるのか
Newtonの文脈でこの問題が特に居心地悪いと感じる理由は、「ライブデータが実際に何か」です。2秒の不整合が害のないタイプのデータの話ではありません。制裁リスト、価格フィード、そしてリスクの閾値の話です。
制裁リストは警告なしに更新されます。新しい実体が現れ、その瞬間以降、その実体に関わるあらゆるトランザクションはブロックされるべきです。ある演算子にはその更新があり、別の演算子にはない場合、同じトランザクションが片側のネットワークでは通り、もう片側ではブロックされる可能性があります。これは技術的な不具合ではありません。コンプライアンスの失敗です。
価格フィードは速く動きます。現在の価格に基づいてリスク閾値を超えてしまったトランザクションは、30秒遅れのフィードに照らすと問題ないように見えるかもしれません。数字が違うのです。判断も違います。そしてシステム外の誰も、どの演算子のデータが正しいのか判別できません。
私がNewtonの二段階設計が実際に解決しようとしていることを理解しようとしていたとき、ずっとぶつかり続けたのがこれです。単に演算子同士に「一般的に」合意させる話ではありません。意思決定を行ったときに、彼らが「どのデータ」を使っていたのかについて具体的に合意させる話です。この区別は非常に重要です。
二段階コンセンサスは実際に何をするのか
ようやく設計を理解したとき、後から考えると論理は明白に感じました。これは、誰かが正しく何かを解決したときにありがちなサインです。
Newtonは評価プロセスを、まとめて一度に実行するのではなく、2つの別々のステップに分割します。1つ目がPrepareフェーズ。2つ目がEvaluateフェーズです。
私の中で腑に落ちたのはここです。Prepareフェーズは何も評価しません。単に合意するだけです。どの演算子も実際のポリシーチェックに触れる前に、ネットワークは、評価に使われるデータが何かについて、正確にコンセンサスに到達します。ざっくり同じデータではありません。その瞬間に各演算子がローカルに持っている任意のデータでもありません。評価が始まる前に、合意されて固定されたまったく同じスナップショットです。
この単一の操作で問題は解消されます。演算子間の不一致が生じていたのは、それぞれが自分自身のローカルなライブデータの版に対して評価していたためです。Prepareフェーズは、これらの異なるローカルな見え方を、ネットワーク上のすべての演算子が合意する1つの共有スナップショットに置き換えます。
そしてEvaluateフェーズが実行されます。すべての演算子が、その合意されたスナップショットに対してトランザクションを照合します。入力が同一だから、結果は比較可能です。データの不一致が判断の下に存在しなくなるため、ネットワークは結果について本当のコンセンサスに到達できます。
NATSはここにどう収まるか
両方のフェーズにわたる演算子間の協調はNATS上で行われます。この文脈でNATSに初めて出会ったとき、オンチェーンのシステムよりもインフラのエンジニアリングに結び付けて考えていたので調べる必要がありました。その関連づけは正しいです。NATSは、高性能な分散環境のために作られたメッセージングシステムです。金融サービスやクラウドのプラットフォームで長年使われています。多数のノードが、最小のレイテンシでメッセージを交換する必要がある状況のために、まさにそのように作られています。
Newtonの設計では、NATSがPrepareフェーズが実行されるチャネルです。演算子は、評価が始まる前に共有データスナップショットを確立するためにNATSを使います。その協調は十分に高速で、プロセスに意味のある遅延を増やしませんが、合意が「ただの前提」ではなく、検証可能になるように構造化されています。
この選択について私がありがたいと思っているのは、Newtonがポリシー言語としてRegoを使うことへの評価と同じ点です。実運用システムでの実績がある、実証済みのインフラです。だれも、規模をかけてストレステストされたことのない独自のメッセージング層を信じるよう求められていません。NATSが使われています。
外から見るとどう見えるか
外から見ると、トランザクションが評価されるのを眺めているだけなら、この二段階設計は見えません。トランザクションが投入され、結果が返る。通るか、ブロックされるか。
見えないのは、ポリシーチェックが実行される前に、ネットワーク全体がそのチェックが参照するデータに合意していることです。制裁リスト、価格フィード、リスクパラメータなど、すべてが、参加する各演算子にまたがって1つのスナップショットに固定されます。返ってくる結果は、どれか1つの演算子がローカルに持っていたものに基づく見解ではありません。ネットワークが一緒に検証した入力に基づくコンセンサス結果です。
なぜこれが、コンプライアンスを現実のものにする部分なのか
この設計が技術的な優雅さだけでなく、なぜ重要なのかを考えるとき、私はいつもある一点に立ち返ります。
どの演算子が実行したかによって異なる結果を生み得るコンプライアンスチェックは、実際にはコンプライアンスチェックではありません。手順が追加された「当て推量」に近いものです。出力が、どのノードがたまたま最も新しいデータを持っていたかで変わるのなら、その出力は一貫した意味を持ちません。整合性のないものに対して規制上のコミットメントを賭けることはできません。
評価が始まる前にデータの合意問題を解くことで、NewtonはEvaluateフェーズを、実際に信頼できるものにします。結果は、どの演算子に尋ねても同じ意味になります。なぜなら、彼ら全員が同じ入力から作業したからです。この整合性こそが、事前決定されたポリシーチェックを、単なるパフォーマンスではなく、現実のコンプライアンス機構に変えるのです。
シンプルなバージョン
2つの演算子が、どちらか一方がもう一方より新しい制裁リストを持っているからといって、同じトランザクションについて意見を食い違わせるべきではありません。Newtonは、評価がどれか1回でも走る前に、演算子が参照する「正確なデータ」に合意させることでこれを解決します。Prepareフェーズがデータを固定します。Evaluateフェーズがチェックを実行します。その間の調整はNATSが担います。
その結果、コンプライアンスチェックはネットワーク全体で一貫し、最新アップデートを最初に受け取った相手とだけ一致するのではありません。最終出力が「トランザクションが適切に検証された」ことをオンチェーンで証明するものであるシステムでは、その整合性は「あると嬉しい」ものではありません。これは全てです。
#SKHynixSaysFundsEyeUpTo$7BInADRs #AsianPCBStockSlideOnNvidiaAIServerDelay #AsianPCBStockSlideOnNvidiaAIServerDelay #Newt $NEWT