昨年、私は軽い手術を受けました。手術の前に、私は同意書に署名し、外科チームが私の医療履歴にアクセスすることを許可しました。手術の後、私は病院に対して、私の記録が他の誰かと共有されたのかどうかを尋ねました。受付の人は、まるで奇妙な質問をされたかのような顔をして、「あなたの担当に関わる医師だけが、必要な範囲で、必要なときに。ほかは見ません」と言いました。
その答えが強く心に残りました。私の医療データは、既定でプライベートになるシステムに存在していました。病院は、血液型をすべての部署に向けて公開したりしません。でも、特定の医師が仕事をするために特定の情報を必要とするときは、私が承認した範囲で、必要以上でもそれ以外でもなく、まさにその情報だけにアクセスできるのです。
ほとんどのブロックチェーンは、そのようには機能しません。完全に公開で、すべての取引や残高が誰にでも見えるタイプか、完全に非公開で、規制当局を含む誰も何も見られないタイプのどちらかです。どちらのモデルも、プライバシーと説明責任が共存する必要がある金融には適しません。
@Dusk_Foundation は、プロトコルレベルでゼロ知識証明を用いて、「既定のプライバシー、必要なときの監査可能性」を実現する仕組みです。取引は、その取引が有効であること、送信者に十分な資金があること、コンプライアンスのチェックが通ったことを、金額や身元をより広いネットワークに開示せずに証明できます。さらに、法的権限を持つ規制当局は、必要なときに限り、私の外科医が同意によって私の履歴にアクセスできたのと同じように、具体的な内容を監査できます。
自己批評:病院には、「私の記録を見ることが“authorized(許可された)”に当たるのは誰か」を何十年もかけて定義する規制がありました。しかしプロトコルのレベルで、「いつ必要か」を監査可能性の条件として定義するのは、はるかに難しいことです。監査を発動させる閾値を低く設定しすぎると、プライバシーがパフォーマンスになってしまいます。逆に高すぎると、規制当局が「プロトコルはそもそも非コンプライアンスだ」と判断する可能性があります。技術的な実装は機能します。では誰が「required(必要)」を定義するのかというガバナンスの問題が、依然としてより難しい課題です。
$DUSK は、暗号技術がプライバシーと開示の双方に対応できるかどうかだけでなく、監査可能性のトリガー条件がどれだけ明確で、どれだけ不変に定義されているかに基づいて評価されるべきです。
#dusk $PORTAL $APR
その答えが強く心に残りました。私の医療データは、既定でプライベートになるシステムに存在していました。病院は、血液型をすべての部署に向けて公開したりしません。でも、特定の医師が仕事をするために特定の情報を必要とするときは、私が承認した範囲で、必要以上でもそれ以外でもなく、まさにその情報だけにアクセスできるのです。
ほとんどのブロックチェーンは、そのようには機能しません。完全に公開で、すべての取引や残高が誰にでも見えるタイプか、完全に非公開で、規制当局を含む誰も何も見られないタイプのどちらかです。どちらのモデルも、プライバシーと説明責任が共存する必要がある金融には適しません。
@Dusk_Foundation は、プロトコルレベルでゼロ知識証明を用いて、「既定のプライバシー、必要なときの監査可能性」を実現する仕組みです。取引は、その取引が有効であること、送信者に十分な資金があること、コンプライアンスのチェックが通ったことを、金額や身元をより広いネットワークに開示せずに証明できます。さらに、法的権限を持つ規制当局は、必要なときに限り、私の外科医が同意によって私の履歴にアクセスできたのと同じように、具体的な内容を監査できます。
自己批評:病院には、「私の記録を見ることが“authorized(許可された)”に当たるのは誰か」を何十年もかけて定義する規制がありました。しかしプロトコルのレベルで、「いつ必要か」を監査可能性の条件として定義するのは、はるかに難しいことです。監査を発動させる閾値を低く設定しすぎると、プライバシーがパフォーマンスになってしまいます。逆に高すぎると、規制当局が「プロトコルはそもそも非コンプライアンスだ」と判断する可能性があります。技術的な実装は機能します。では誰が「required(必要)」を定義するのかというガバナンスの問題が、依然としてより難しい課題です。
$DUSK は、暗号技術がプライバシーと開示の双方に対応できるかどうかだけでなく、監査可能性のトリガー条件がどれだけ明確で、どれだけ不変に定義されているかに基づいて評価されるべきです。
#dusk $PORTAL $APR