Ethereum Foundation と Open Anonymity Project は、zkAPI を Ethereum のメインネットに投入しました。これにより、誰かがメーター付きの AI または API アクセスに対して支払いを行いつつ、その入金がどれに対応したものかを提供者に知られずに済みます。分けて考えるべき重要な点は 3 つあります:
1. プライバシーはコンテンツチャネルではなく、課金チャネルに限定されます。提供者は引き続きリクエスト自体は受け取ります。提供者が知れなくなるのは、どの資金提供済みの入金(デポジット)がそれを決済したのか、という点です。発表はこれをはっきりと述べており、このスコープが主張全体です。
2. メータリングは二重支払い問題に変わります。通常の API 課金では、サーバーが減算(デクリメント)していく「残高」を、識別可能なアカウントに紐づけます。ここには識別可能なアカウントがないため、正しさは「入金が存在し、かつまだ使われていないこと」を証明することに依存します。難しい部分は会計から一意性へ移り、一意性はチェーン上で決着します。
3. 証明者(プローバー)はクライアント側に配置されます。今すぐ支払えるかどうかは、課金サーバーが稼働し続けるだけでなく、ユーザーが実行するソフトウェアに依存します。これは停止(アウトエイジ)とは別の故障モードであり、多くの人が最後に気づく部分です。
設計は、Vitalik Buterin と Davide Crapis が 2 月に公開した枠組みに従っています。注目すべきは、プロバイダーが「帰属(アトリビューション)できない支払い」を受け入れるかどうかです。誰もレールとして引用しない支払い経路は、単に非常に洗練された金庫(ヴォルト)に過ぎないからです。
※金融助言ではありません。ご自身で調査してください。
#Ethereum #Web3 #Privacy
1. プライバシーはコンテンツチャネルではなく、課金チャネルに限定されます。提供者は引き続きリクエスト自体は受け取ります。提供者が知れなくなるのは、どの資金提供済みの入金(デポジット)がそれを決済したのか、という点です。発表はこれをはっきりと述べており、このスコープが主張全体です。
2. メータリングは二重支払い問題に変わります。通常の API 課金では、サーバーが減算(デクリメント)していく「残高」を、識別可能なアカウントに紐づけます。ここには識別可能なアカウントがないため、正しさは「入金が存在し、かつまだ使われていないこと」を証明することに依存します。難しい部分は会計から一意性へ移り、一意性はチェーン上で決着します。
3. 証明者(プローバー)はクライアント側に配置されます。今すぐ支払えるかどうかは、課金サーバーが稼働し続けるだけでなく、ユーザーが実行するソフトウェアに依存します。これは停止(アウトエイジ)とは別の故障モードであり、多くの人が最後に気づく部分です。
設計は、Vitalik Buterin と Davide Crapis が 2 月に公開した枠組みに従っています。注目すべきは、プロバイダーが「帰属(アトリビューション)できない支払い」を受け入れるかどうかです。誰もレールとして引用しない支払い経路は、単に非常に洗練された金庫(ヴォルト)に過ぎないからです。
※金融助言ではありません。ご自身で調査してください。
#Ethereum #Web3 #Privacy