先週、暗号のプロファイル（proof）に関する小さな疑問でずっとつまずいていました。
proof に verify ができるのかを聞く前に、そもそもそれが元の正しい proof なのか、どうやって確かめるのでしょうか？
数日後、Newton Protocol のドキュメントにある zkTLS Twitter/X Example を読んで、proofCid の詳細で止まってしまいました。
最初は、CID は単に proof を保存しておくためのアドレスに過ぎないのだと思っていました。
zkTLS の proof が作られます。クライアントはその proof を保存します。ゲートウェイは proofCid を返します。その後、タスクはこの CID を使って、ポリシー評価を実行するときにオペレーターがどの proof を取得すべきかを知るようになります。
一見すると、ファイルを保存するごく普通の一手順のように見えます。
でもよく読むほど、私は@NewtonProtocol が「proofがどこにあるか」を尋ねているだけではないように見えてきます。
そのアドレスの先の内容が、clientが作ったproofそのものかどうかを尋ねています。
それが、CIDが一般的なURLと違う点です。
URLは通常、その内容がどこで見つかるかを示唆します。
CIDはより強いことを言います。この内容はどんなハッシュなのか。
内容が変われば、CIDも変わらなければなりません。だから、proofCidは単なるポインタではありません。ポインタの背後にあるbytesについての約束です。
しかしauthorization flowでは、GatewayからCIDを1つ受け取ってそのまま信じるだけではまだ不十分です。
Newtonの例は、proofCidを受け取るところで終わりません。proofバイトを取り出すとき、clientは返ってきたbytesがCIDのmultihashと一致することを検証します。store()の後、SDKはさらに送ったbytesからCIDを再導出し、Gatewayの応答が一致しない場合は拒否します。
この詳細は小さいですが、とても重要な境界を開きます。
Newtonは、proofCidをGatewayからの約束にしません。
その約束に従って戻り、実際のバイトと突き合わせます。
そのため、Clientは証拠がauthorization pathに投入される際、Gatewayやストレージ層に完全に信頼をアウトソースしません。信頼の感覚ではなく、CIDを実際の内容そのものと照合して確認します。
ここが私の中では面白いところです。
zkTLS proofは正しくてもよい。policyも正しく書ける。taskも正しく見えることはある。ですが、proof作成とpolicy評価の引き渡しがずれてしまい、proofCidが最初のproofとは別のbytesを指しているなら、システムは誤った証拠を評価しています。
そのときのエラーは、proofの暗号方式にあるのではありません。
証拠を保存する境界のところにあります。
Newton Protocolは、その手の問題をclientの境界で止めようとしているようです。proofがtaskに渡される前に、オペレーターがそれを使う前に、policyがそれに依存する前に、clientはアドレスと実際の内容が本当に一致していることを確信していなければなりません。
その観点から見ると、CID Integrity Boundaryは、利便性のためにproofを保存する話ではありません。
それは、証拠が作成された時から、authorizeに使われるまでの経路で改ざんされないように保つためのやり方です。
もちろん、CIDの完全性（integrity）だけではすべてを解決しません。
それは、proofの中のclaimが良いことを証明しません。policyの代わりでもありません。また、外部データソースが常に信頼できることも保証しません。
ですが、それはとても具体的なことを守ります。proofが保存され、取り出され、アドレスの背後の内容が変えられることなくtaskに渡されることです。
私にとって、これはNewtonの中で小さな、しかし注目すべき細部です。
Authorizationには、正しいルールだけでなく、
それでも、正しい証拠が必要です。
そして、証拠が信頼される前に、システムはその証拠が本当にuser/clientが作ったものだと確信していなければなりません。
おそらくproofCidは、proofへのリンクとして見なされるべきではありません。
それは、そのリンクの裏側にあるproofがすり替えられていないという約束として見るべきです。