Фонд Ethereum и проект Open Anonymity Project запустили zkAPI в основной сети Ethereum. Он позволяет кому-то оплачивать тарифицируемый доступ к ИИ или API без того, чтобы провайдер узнавал, какой депозит это оплачивал. Три вещи, которые стоит разделить:
1. Конфиденциальность ограничена каналом биллинга, а не каналом контента. Провайдер все равно получает запрос. Он перестает узнавать лишь то, какой именно депозит с финансированием закрыл/погасил этот запрос. В объявлении это сказано прямо, и это ограничение — весь заявленный смысл.
2. Тарификация превращается в проблему двойного расходования. Обычный биллинг API — это баланс, который сервер уменьшает на основании операций по аккаунту, который он может идентифицировать. Здесь нет идентифицируемого аккаунта, поэтому корректность должна обеспечиваться доказательством того, что депозит существует и еще не был использован. Самая сложная часть сходит с учета на уникальность, и уникальность подтверждается в блокчейне.
3. Проставитель доказательств находится на стороне клиента. Возможность оплатить сейчас зависит от программного обеспечения, которое запускает пользователь, а не только от того, что биллинговый сервер остается в сети. Это другой тип отказа по сравнению с просто аварией/отключением, и это та часть, которую большинство людей замечают последней.
Дизайн следует рамке, опубликованной Виталика Бутерина и Давиде Краписа еще в феврале. На что стоит обратить внимание: примут ли провайдеры платеж, который они не смогут связать (атрибутировать) с собой, потому что «рельс», который никто не цитирует как гарантированный, — это просто очень изящный сейф (vault).
Это не финансовый совет. Проведите собственное исследование.
#Ethereum #Web3 #Privacy
1. Конфиденциальность ограничена каналом биллинга, а не каналом контента. Провайдер все равно получает запрос. Он перестает узнавать лишь то, какой именно депозит с финансированием закрыл/погасил этот запрос. В объявлении это сказано прямо, и это ограничение — весь заявленный смысл.
2. Тарификация превращается в проблему двойного расходования. Обычный биллинг API — это баланс, который сервер уменьшает на основании операций по аккаунту, который он может идентифицировать. Здесь нет идентифицируемого аккаунта, поэтому корректность должна обеспечиваться доказательством того, что депозит существует и еще не был использован. Самая сложная часть сходит с учета на уникальность, и уникальность подтверждается в блокчейне.
3. Проставитель доказательств находится на стороне клиента. Возможность оплатить сейчас зависит от программного обеспечения, которое запускает пользователь, а не только от того, что биллинговый сервер остается в сети. Это другой тип отказа по сравнению с просто аварией/отключением, и это та часть, которую большинство людей замечают последней.
Дизайн следует рамке, опубликованной Виталика Бутерина и Давиде Краписа еще в феврале. На что стоит обратить внимание: примут ли провайдеры платеж, который они не смогут связать (атрибутировать) с собой, потому что «рельс», который никто не цитирует как гарантированный, — это просто очень изящный сейф (vault).
Это не финансовый совет. Проведите собственное исследование.
#Ethereum #Web3 #Privacy