Newton Protocolのプライバシー層に関するドキュメントを読んでいたところ、ある実装上の詳細が際立っていました。多くのプライバシー重視のシステムは、機微な情報を保護するために強力な暗号化を重視していますが、Newtonは、保護されたデータがポリシー評価の際に参照される前に、もう1つの要件を追加します。
ドキュメントによると、身分証明書類、財務記録、認証情報、独自のパラメータなどの機微情報は、アップロード前にHPKEを用いてクライアント側で暗号化されます。暗号化されたデータが平文のままブロックチェーンに書き込まれることはありません。代わりに、オンチェーンではハッシュ、コミットメント、参照IDのみが使用されます。
興味深いアーキテクチャ上の判断は、タスクの実行中に現れます。
オペレータが暗号化されたいかなるデータも復号できるようになる前に、Newtonはデュアル署名による認可を要求します。2つの独立したEd25519署名が必要です。
エンドユーザーは、ポリシークライアント、意図ハッシュ、暗号化データ参照に署名することで、特定の要求を認可します。
その後、dAppがユーザーの認可に署名します。
2つの署名がすべて正常に検証された後にのみ、オペレータはしきい値復号プロセスを開始します。
これにより、暗号化そのものとは別の追加の認可レイヤーが作られます。
ドキュメントでは、復号はしきい値復号によって行われるとも説明されています。単一のオペレータが完全な秘密鍵を保持するのではなく、オペレータそれぞれが分散鍵生成（DKG）で生成された分散鍵シェアを保持します。ポリシー評価の間、オペレータは部分復号シェアを交換し、プレーンテキストをローカルで再構成し、ポリシーを評価し、その後、評価結果に対してBLS署名を生成します。
この設計の重要な帰結は、暗号化だけでは十分な保護と見なされないことです。誰かが暗号化データ参照を入手できたとしても、ドキュメントによれば、必要な認可署名の両方が揃わない限り復号できないとのことです。参照ID単体は意図的に役に立たないものです。
プライバシーレイヤーは、暗号化データの周りにも追加の保護を導入します。ドキュメントでは、X25519、HKDF-SHA256、ChaCha20-Poly1305を用いたHPKEによる認証付き暗号化について説明されています。追加認証データ（AAD）は、すべての暗号文をターゲットのPolicyClientとチェーンIDの両方に結び付けます。いずれかの値が変更されると復号に失敗し、暗号化ペイロードが異なる実行コンテキストで再利用されるのを防ぎます。
もう一つ注目すべきエンジニアリング上の決定はキー分離です。Newtonは、しきい値復号の鍵が、オペレータのECDSAおよびBLS署名鍵とは暗号学的に独立していると説明しています。これは、ある暗号サブシステムが侵害されても、それが別のサブシステムを自動的に公開しないため、影響を抑えられます。
これらの仕組みをまとめると、Newtonはプライバシーを単なる機密データの保存以上のものとして扱っていることが分かります。暗号化は内容を保護し、デュアル署名による認可が復号を許可するタイミングを制御し、しきい値復号は単一当事者への信頼を排除し、コンテキストバインディングは契約やチェーンをまたいだ暗号文の再利用を防ぐのに役立ちます。
単一のプライバシー手段に依存するのではなく、プロトコルは同じ機密情報の周りに複数の独立した制御を重ねます。この重層化されたアプローチは、Newtonプロトコルのプライバシーレイヤーで記録されている、より興味深いエンジニアリング上の選択肢の1つです。
ビルダーへの質問：Newtonのプライバシー保証により大きく寄与しているのはどちらの設計でしょうか。しきい値復号のアーキテクチャか、それとも、そもそも復号を許可するかどうかを決めるデュアル署名による認可か？@NewtonProtocol #Newt $NEWT