_CryptoNova

sat with the compliance receipts section of the Newton whitepaper last night and it clarified something i had been thinking about imprecisely for a while.@NewtonProtocol
there is a category distinction that matters enormously in regulatory compliance and almost nobody in the onchain space is building too it. the distinction is between evidence that monitoring was performed and evidence that enforcement actually happened. these sound similar. they are not the same thing.
a blockchain analytics platform produces logs. it 0bserved a transaction, ran a risk score against it, flagged or cleared it, and recorded that it did so. that log is evidence of monitoring. but monitoring is surveillance, not enforcement. the transaction executed before the log was produced. the funds moved before anyone acted on the flag. a regulator asking for evidence that illicit....
transactions were prevented cannot be satisfied by a log showing that suspicious activity was detected after the fact.
Newton produces compliance receipts. these are cryptographic records that bind the transaction intent, the policy evaluated, the operator responses, the aggregate BLS signature, and the block number. the receipt proves that a specific policy was evaluated for a specific transaction before it executed and that the evaluation produced a specific outcome. this is evidence of enforcement, not monitoring. tha transaction could only
have executed because the attestation was produced. the attestation could only have been produced because thepolicy evaluation passed.
the architecture of the receipt matters as much as its existence. on-chain the TaskManager contract stores an immutable record of every policy evaluation which policy was applied, the outcome, the aggregate signature, and the block number. regulators can verify that policies were applied consistently by inspecting on-chain recipts without
accessing any underlying personal data. the chain sees proofs, never the data that produced them.
off-chain indexing complements the on-chain record for query performance enabling dashboard and analytics access across evaluation history without burdning the chain with full evaluation logs. for deeper investigation, authorized access to off-chain evaluation details can be provided #Newt
through appropriate legal process without exposing data to the public chain.
i find the regulator access model particularly well designed. a compliance officer at an institution using Newton can demonstrate to a regulator that every transfer above a thres hold was evaluated against a sanctions policy before execution, with cryptographic proof of each evaluation, without handing over the underlying identity data of the parties involved. that combination audit evidence without
data exposure is what regulated institutions actually need and almost nothing in the current onchain compliance landscape provides itcleanly.
And the tamper-evident property of the on-chain record adds another layer. compliance receipts stored through the TaskManager contract cannot be retroactively altered. the audit trail is permanent, public, and indepen dently verifiable by any party with access to the chain including regulators, auditors, and counterparties
who need to verify that a specific transaction was compliantly processed.
whether regulators across diferent jurisdictions will formally accept cryptographic compliance receipts as satisfying their audit evidence requirements or whether additional legal frameworks need to develop around
their evidentiary status is the question that determines how quickly the institutional adoption curve accelerates??
@NewtonProtocol $NEWT

今朝からニュートンのホワイトペーパーの「機関向けDeFi」セクションを読み進めていて、そこには、それ自体の前提として取り出して検討に値する主張が埋め込まれていると思った。
この論文の主張はこうだ。機関投資家の資本は、深さと構成可能性（composability）のためにパブリックな流動性プールを必要とする。一方で、コンプライアンスと機密性のためには、プライベートな政策に基づく実行（execution）が必要である。これら2つの要件は相反する方向に働き、既存のほとんどのアプローチでは機関がどちらか一方を選ぶことになってしまう。つまり、パブリックDeFiを使うなら、あなたの注文フローは誰にでも見えることを受け入れる必要がある。あるいは、プライベートな環境を使ってプライバシーは得られるが、パブリックDeFiの価値の根幹である流動性の深さから切り離されてしまう。

オンチェーンのセキュリティは、通常スマートコントラクトの監査問題として語られます。デプロイ前にバグを見つけてください。より良いコードを書きましょう。起動時にコードが正しければ、そのシステムは安全だという前提です。私はその前提が何度も破られるのを十分に見てきたので、もはや信じないことにしました。
実際にプロトコルを破壊する脅威モデルは別物です。管理者キーの侵害。盗まれた資金がDEXやブリッジを通って移動し、誰も対応する前に事態が進んでしまう。
ガバナンス攻撃で、議決が最後の瞬間に大口トークン保有者によって揺り動かされるケースがあります。彼らは結果に影響を与えるために、そもそもその地位を買ったのです。これはコードのバグではありません。承認（オーソリゼーション）の失敗です。コードは書かれたとおりに実行されます。問題は、承認されていたはずの「実行内容」が間違っていたこと……。

昨晩、Newtonホワイトペーパーのクロスチェーン・アーキテクチャのセクションを読み進めていて、これが私がプロトコルの概要を最初に読んだときから抱えていた疑問を解決してくれた部分です。
NewtonのオペレーターネットワークがEthereum上にあり、トランザクションを許可するなら、トランザクションがArbitrum、Polygon、またはBaseで実行されるときはどうなるのでしょうか？それぞれの到達チェーンごとにコンプライアンスのインフラが必要になりますか？
オペレーターは、提供したいチェーンごとに個別に登録する必要があるのでしょうか？答えは両方とも「いいえ」です。そして、それを可能にする仕組みは注意深く理解する価値があります。

分散型のポリシー評価の中に埋もれている技術的な問題があって、重要性がほとんど語られていない。その理由を完全に理解するのに、あまりにも長い時間かかってしまったのが恥ずかしいくらいだ。
オペレーターがそれぞれ独立して、時間に敏感なデータ（資産価格、制裁リストの更新、オラクルのフィードなど）を取得すると、同じ情報源からでも、彼らのリクエストが届いた“タイミング”によって、異なる値を受け取ることがあります。制裁リストは更新されます。価格はミリ秒の間にも動きます。もし各オペレーターが少しずつ異なるデータを受け取ってから、ポリシー結果にBLS署名しようとすると、署名は集約されません。BLS集約には同一のメッセージが必要です。

昨日からニュートンのホワイトペーパーの紛争解決セクションを読み込んでいて、プロトコルを構築する多くの人が、実際に必要になるまで当然の前提として扱ってしまう部分だと思いました。そして、必要になったときに、この部分こそがシステムの中で最も重要になります。
ニュートンが主張する中核は、アテステーションは信頼不要である、という点です。信頼を最小化するのではなく、信頼不要です。
それは強い主張であり、それを裏付ける特定の仕組みが必要です。チャレンジシステムが、その仕組みです。
アテステーションがオンチェーンに記録された後、ガバナンスが定義した紛争期間が開始されます。この猶予期間中は、そのアテステーションは暫定的なものであり、取引を承認するために使うことはできません。成功したチャレンジがなく、このウィンドウが期限切れになって初めて、そのアテステーションは最終確定します。これにより、多くのシステムが1つに崩れてしまう2つの状態を、きれいに分離できるようになります。

ニュートンのうち、開発者が最も早く理解すると思うのは、機関のコンプライアンス担当者が最も遅く理解するであろう部分で、その逆もまた同じです。Regoは、この2つの世界が交わる場所にあります。さらに、これを使うという設計上の選択は、通常よりももっと注目されるべきです。
Regoは0pen Policy Agentプロジェクトのポリシー言語です。エンタープライズの基盤インフラに広く導入されており、Kubernetesのアドミッションコントロール、APIゲートウェイの認可、CI/CDパイプラインのポリシーなどで利用されています。クラウドネイティブなインフラを、ある程度の規模で真面目に扱ったことがあるなら、ほぼ確実にRegoのポリシーを書いたか、評価したことがあります。宣言的で、十分に整備されたツール群があり、既存の大規模なエコシステムの中で戦い抜いてきた言語です。

昨日の午後からニュートンのプライバシー・アーキテクチャを読み進めていて、これはホワイトペーパーの中でも特に、実際に理解するために何度も読み返しが必要だった部分です。説明が下手だからではありません。設計が本当に層構造になっていて、内容を完全に吸収するには時間がかかるからです。
出発点となる主張は、機微データは決してブロックチェーンに公開されない、ということです。ブロックチェーンが見るのは、証明（プローフ）と認証（アテステーション）だけで、基となるアイデンティティのデータではありません。その主張は、具体的な技術的メカニズムによって裏付けられる必要があります。そうでなければ、それはただのマーケティング表現に過ぎません。ニュートン・プライバシー・エンベロープは、そのメカニズムです。

オンチェーンのアイデンティティには、ほとんどの人が無言のうちに「解決不能」と受け入れている設計上の問題があります。誰かが誰であるかを検証するには、その人のデータが必要です。しかし、そのデータがパブリックチェーンに触れた瞬間、永久に公開されてしまいます。この2つの要件は互いに対立しており、既存の多くのアプローチはどちらか一方を選んで、その結果を受け入れるだけに留まっています。
NewtonのIdentity Oracleは、別のモデルを中心に構築されており、そのアーキテクチャを詳細に理解する価値があります。
システムは3つの役割で動作します。発行者はユーザーの属性をKYCプロバイダー、政府機関、金融機関、オンチェーン行動アナライザを通じて認証する事業体です。発行者は署名付きクレデンシャルを作成し、それをユーザーに渡します。保有者（ホルダ）であるユーザー自身が、それらのクレデンシャルを自分のウォレットに保存します。ユーザーは、いつ・誰に対して提示するかを決めます。検証者であるNewtonオペレーターおよびIdentity Oracle自体が、TEEエンクレーブ内でクレデンシャルの証明を検証します。つまり、基になるデータは検証者のホストシステムには一切公開されません。検証結果は、ポリシー評価に入力されるブール値（真偽値）または最小限の出力です。合格か不合格か。それ以外の情報はオンチェーンに記録されません。