Salman49

ホルムズ海峡。4つの市場。なぜすべての暗号資産投資家がホルムズを見ておくべきなのか。

多くの暗号資産投資家は、航路を追いかけていません。私も普段はそうです。ですが、ホルムズ海峡は、暗号資産の外で起きた出来事が、すぐにあなたのポートフォリオへ影響しうる場所のひとつです。

最近のデータでは、ホルムズを通過する船舶交通が約52%低下した一方で、供給の混乱に対する懸念が強まり、ブレント原油は1バレルあたり85ドルを超えて上昇しました。同時に、市場のボラティリティ（変動性）が増しているという報道が、暗号資産市場全体で大規模な強制清算を引き起こし、世界的な出来事がリスク選好をどれほど速く変えうるかをトレーダーに改めて思い出させました。

教訓は、「すべての地政学的イベントが暗号資産をクラッシュさせる」ということではありません。市場はつながっている、ということです。原油価格の上昇はインフレ懸念を高めることがあり、不確実性が強まると投資家がリスク資産から離れやすくなり、またレバレッジをかけたポジションは、急なボラティリティの際に解消しやすくなります。

私にとって最大の収穫は、次の見出しを当てることではありません。連鎖反応を理解することです。世界で最も忙しいエネルギー輸送ルートの一つでの混乱は、原油・株式・通貨、そして最終的に暗号資産にも影響を与えます。ビットコインが反応する頃には、物語はだいたい別の場所で始まっているのです。

暗号資産を取引するなら、暗号資産だけを見ているのではもう不十分です。最初のシグナルが、どのブロックチェーンからも数百マイル離れた場所で現れることもあります。 NFA.DYOR.

より高速な金融システムを構築してきました。もしかすると、ファイアウォールを作るのを忘れてしまったのかもしれません。

数日前、オンライン決済をしていました。金額は小さかったのですが、支払いは追加の本人確認手順のために一度止まりました。そのときは、不要に感じました。アプリはすでに私のアカウント、残高、受取人を把握していました。なら、なぜ私を止めるのでしょう？

その問いが、ニュートンのドキュメントを読んでいる最中にふとよみがえりました。実行の前にインテントが評価されるフローにたどり着きました。オペレーター・ネットワークはポリシーを確認し、BLSのアテステーションを生成し、その証明をPolicyClientが検証してから、取引を継続できるようにします。初めて読んだときは、単なる別の認可システムに見えました。

しかし次にVaultKitとShield Contractsに触れて、ある一点が引っかかって考え込んでしまいました。保護されたアクションは、オペレーターが拒否した場合、必要な67%のクォーラムに到達しない場合、アテステーションの有効期限が切れた場合、またはShieldの検証が失敗した場合には転送されません。そこで、私の最初の印象が変わりました。

私は、金融のセキュリティを間違った方向から見てきたのではないかと考え始めました。多くの金融システムは、取引が起きた後に不審な取引を検知することに重点を置いています。ニュートンは、そもそも取引が成立するに値するのかを判断することに時間を使っているように見えます。私にとってそれは、従来の金融セキュリティの仕組みというより、ファイアウォールの動きにずっと近いのです。

だからこそ、私の決済中に突然出てきた追加の本人確認ステップが、今になってより筋が通って感じられました。それは私が送金できる能力を疑っていたのではありません。特定のその行為が、前に進むための許可を得ているかどうかを問うていたのです。これからの金融のアップグレードは、より速い取引になるのではなく、取引が起きる前のより良い判断になるのではないでしょうか。

出典：Newton Protocol Documentation。Intent、Policy、Operator Network、BLS Attestation、PolicyClient、VaultKit、Shield Contracts、そして標準の67%クォーラムといった技術用語はドキュメントに基づいています。「金融のファイアウォール」という比較は、私自身の分析です。#newt $NEWT @NewtonProtocol #Web3 #AI

AIの最大のアップグレードは「分かりません」と言うタイミングを学ぶことかもしれない。

多くのAIユーザーは、こういうことを見たことがあるはずです。質問すると、自信ありげな答えが返ってきて、後になって初めて「その一部は間違っている」ことに気づく。だから私は、AIの最大の進化は「もっと質問に答えること」ではなく、「答えないほうがよいときに分かること」だと思いました。

この考えは、ニュートンのコンセンサスに関するドキュメントを読んでいるときにふと再び思い出されました。ひとつの点が特に印象に残りました。オペレーター同士のデータに合意がない場合、ニュートンはその食い違いを黙って無視して先に進まないのです。ドキュメントによると、デフォルトの10%許容範囲を超えた値は ToleranceExceeded を返し、オペレーターが沈黙のうちに除外されることはありません。プロトコルは単に停止します。

システムの他の部分でも同じパターンが見られます。オペレーターが誰も応答しなければ NoResponses。ネットワークがデフォルトの67%のステーク加重クォーラムに到達できなければ InsufficientQuorum。ドキュメントでは、これらは隠された失敗ではなく、ネットワークが信頼できる判断に到達できなかったことを示す明確なシグナルだとされています。

ATMの例えを思い浮かべたことで、設計の意図が腑に落ちました。銀行が取引を確認できないのなら、「残高を当ててATMが現金を渡す」よりも、「取引失敗（Transaction Failed）」と表示されるほうがいい。ニュートンも同じ発想を適用しているように思えました。うまくいっていないのに全部が問題ないふりをして続行するより、拒否するほうが安全なこともあります。

これがブロックチェーンの話だけだとは思いません。信頼の話です。システムは、不確実性を認めて隠さないほど、より信頼性が高くなります。私の見立てでは、そもそも信頼できなかった答えよりも、「分かりません（I don't know）」のほうがはるかに価値がある場合があるのです。

出典：Newton Protocol Documentation（Consensus & Security）。 #newt $NEWT @NewtonProtocol

バグを見つけるのに最適な時間は本番ではない

多くの開発者はコードを書くことを気にしません。気にするのは、コードが期待と違う動きをしていると気づくのが遅すぎることです。Newtonのテストドキュメントを読むことで、この問題に対する考え方が変わりました。投稿前に写真をプレビューし、長距離ドライブの前に道順を確認します。テストせずにポリシーをデプロイし始めると、「両方の手順を飛ばす」ような感覚になってしまいます。

Newtonのドキュメントにはシンプルな原則があります。まずテストし、後でデプロイする。開発者は、ブロックチェーンに何も到達する前に、個々のコンポーネントを検証したり、完全なワークフローをシミュレートしたりできます。最後のステップであるsimulatePolicy()は、オラクルデータを収集し、Regoポリシーを評価し、デプロイ前に結果が許可（allow）になるのか拒否（deny）になるのかを示します。

そこで私は、ドキュメントが単なるデバッグガイドに感じなくなっていきました。よくある「何かが壊れてから初めて開発者が尋ねる質問」に答え始めたのです。つまり、「このポリシーは実際に何をするのか？」です。失敗したトランザクションによって答えを探すのではなく、シミュレーションは、変更がまだ安全でコストも低い段階で意思決定を明らかにします。

Newtonはさらに、テストをさまざまな段階に分けています。simulatePolicyData()は、オラクルが期待するデータを返すかどうかを確認します。simulatePolicy()は、完全な認可フローを検証します。simulateTask()は、デバッグ中に既存のタスクを再生するのに役立ちます。各ツールは、すべてを解決しようとするのではなく、ひとつの課題に集中します。

覚えておくべき制約もひとつあります。simulateTask()はローカルで実行されるため、完全なOperatorパイプラインは実行しません。開発者は、デプロイ前に完全な実行フローを検証するために、引き続きsimulatePolicy()が必要です。

私の結論は、信頼できるシステムはミスを避けることで作られるのではない、ということです。ユーザーが目にするよりも前に、できるだけ多くのミスを見つけることで作られます。

出典: Newton Protocol Documentation (Testing & Debugging, Testing Policies & Oracles, SDK Reference). 明示されている場合のみ個人的分析。NFA.DYOR. #Newt $NEWT @NewtonProtocol

ニュートンのBN254証明書がクロスチェーンの信頼コストを静かに引き下げる

私は、資産がどのようにブロックチェーン間を移動するのかについて、たくさんの時間をかけて読み物を調べています。今回は、いつもと違う流れを追うことになりました。つまり、宛先チェーンが、毎回Ethereumに問い合わせることなく、結果を信頼すべきかどうかをどう判断するのかを理解したいのです。

ニュートンのマルチチェーン・ドキュメントを読み進める中で、資産の流れではなく証明書のフローを追いました。オペレーターがリクエストを評価し、BLSの集約署名を作成すると、ニュートンはその結果をBN254証明書にパッケージします。宛先チェーンは、Ethereumへのライブな問い合わせを行わずに、その証明書を検証します。

ひとつの細部が特に気になります。宛先チェーンは、キャッシュされたオペレーター・テーブル（Ethereumから同期されたもの）に対して、すべてのBN254証明書を検証するのです。さらに、EthereumのBN254プリコンパイルと組み合わさることで、検証は別のクロスチェーン依存ではなく、ローカルな暗号学的チェックになります。

これにより、マルチチェーン開発に対する考え方が変わります。開発者は、対応する各チェーンごとに異なる信頼検証システムを用意する必要がありません。別のチェーン上にPolicyClientをデプロイして、毎回ゼロから検証を作り直すのではなく、同じオペレーターの信頼モデルを再利用できます。

このアプローチには、それでも規律あるインフラへの依存があります。キャッシュされたオペレーター・テーブルは同期を維持する必要があり、オペレーターの更新は原子的に行われなければ、証明書の検証が失敗する可能性があります。

フローを何度か読んだあと、私は別の印象を持って立ち去ります。面白いのは、BN254証明書そのものではありません。むしろニュートンが、信頼を「新しい場所にデプロイするたびに毎回作り直すもの」ではなく、「アプリケーションがチェーンをまたいで再利用できるもの」として扱っている点です。

出典：Newton Protocol Documentation（Multichain Support, Cross-Chain Interoperability & BLS Attestation）。個人的な分析。#newt $NEWT @NewtonProtocol

SecureEnvelopeはプライバシーを「本来あるべき場所」に留める

SecureEnvelopeには何度も戻ってきます。これは「データ単体をロックする」だけでは解決できない課題を解決してくれるからです。ロックはデータを隠しますが、データが「どこに属しているか」は示しません。Newtonはエンベロープを特定の「policy_client」および「chain_id」に結び付けます。そのため、同じロック済みデータでも、間違ったコントラクトや間違ったチェーン上では失敗します。私にとって、ロックそのものよりもこの点が重要です。

私の中で引っかかるのはAADです。 「policy_client」と「chain_id」はkeccak256によってコントラクトコードに固定されます。だから、どんな変更でもアンロックが壊れます。エンベロープには「enc」「ロック済みデータ」「policy_client」「chain_id」「recipient_pubkey」が含まれます。データは単に隠されるだけではありません。1つの場所にロックされます。

それによって、Newtonにおけるプライバシーの捉え方が変わります。KYCの記録、APIキー、あるいはコンプライアンス文書が、どこへでも移動できる「緩い秘密」になるわけではありません。それは、それを要求したコントラクトとチェーンに結び付いたままです。その場所の外へ同じロック済みデータを移せば、アンロックはもう機能しません。バイト列は同じでも、それらを機能させる「場所」が消えてしまうからです。

私が持ち続けているのは、これです。プライバシーとは、情報を隠すことだけではありません。間違った場所で機能しないように、情報を保つことでもあります。SecureEnvelopeは「本来あるべき場所」の部分を保護に組み込みます。ここでの本質的な考え方は、まさにそれだと感じています。

出典: http://docs.newt.foundation - SecureEnvelope セクション。以上は、Newtonの設計に関する私個人の分析です。#newt $NEWT @NewtonProtocol $SKYAI $POWER