1つの証明、複数の宛先 🌐

$LINK は、ブロックチェーンと外部情報の間の接続性がいかに重要かを示す一助となりました。

しかし、注目に値するインフラ上の問題がもう一つあると思います。

暗号学的証明を複数の異なるアプリケーションで検証する必要がある場合、どうなるでしょうか？

たとえば、ある貸付プロトコルが、借り手が特定の要件を満たしているか検証する場面を想像してみてください。

証明が検証されます。

その結果を利用したい別のアプリケーションが現れます。

そのアプリケーションは、検証プロセス全体をもう一度実行する必要があるのでしょうか？

必ずしもそうではありません。

zkVerifyは、証明集約によってこの問題に取り組みます。

対応する証明がそれぞれ独立して検証された後、その結果を集約バッチにまとめることができます。

ネットワークは、検証済みの証明を表すレシートを生成します。

その後、アプリケーションは適切な暗号学的包含証明を利用して、特定の検証結果がそのバッチに含まれているかを確認できます。

つまり、宛先のコントラクトは、元の検証計算をすべて再現することなく、検証証拠を利用できます。

ここで区別しておくべき点があります。

レシートによって、その証明が検証されたことは確認できます。

しかし、それによってすべてのアプリケーションがその主張を自動的に受け入れることになるわけではありません。

各アプリケーションは、引き続き独自の要件を適用する必要があります。

ZKアプリケーションが複数のエコシステムへと広がるにつれて、このアーキテクチャの重要性はますます高まると思います。

本当の可能性は、単により多くの証明を検証することではありません。

検証済みの結果を、ほかのシステムがより簡単に利用できるようにすることです。

#インフラ #アルトコインシーズン#