A Ethereum Foundation e o Open Anonymity Project colocaram o zkAPI no ar na rede principal (mainnet) do Ethereum. Ele permite que alguém pague por acesso a IA ou API com medição (metered) sem que o provedor saiba qual depósito pagou por isso. Três coisas que vale separar:
1. A privacidade é limitada ao canal de cobrança (billing channel), não ao canal de conteúdo (content channel). O provedor ainda recebe a solicitação. O que ele deixa de saber é qual depósito financiado a liquidou. O anúncio afirma isso com clareza, e esse escopo é a reivindicação inteira.
2. A medição vira um problema de double-spend. A cobrança comum de APIs é um saldo que um servidor debita em relação a uma conta que ele consegue identificar. Aqui não existe uma conta identificável, então a correção precisa vir de provar que um depósito existe e ainda não foi usado. A parte difícil muda de contabilidade para unicidade, e a unicidade é resolvida on-chain.
3. O provador fica com o cliente. Conseguir pagar agora depende do software que o usuário executa, não apenas de um servidor de cobrança permanecer ativo. Esse é um modo de falha diferente de uma indisponibilidade (outage), e é a parte que a maioria das pessoas descobre por último.
O design segue um framework publicado por Vitalik Buterin e Davide Crapis em fevereiro. O que observar é se os provedores aceitarão um pagamento que eles não conseguem atribuir, porque um trilho (rail) que ninguém cotou contra é só um cofre (vault) muito elegante.
Não é aconselhamento financeiro. Faça sua própria pesquisa.
#Ethereum #Web3 #Privacy
1. A privacidade é limitada ao canal de cobrança (billing channel), não ao canal de conteúdo (content channel). O provedor ainda recebe a solicitação. O que ele deixa de saber é qual depósito financiado a liquidou. O anúncio afirma isso com clareza, e esse escopo é a reivindicação inteira.
2. A medição vira um problema de double-spend. A cobrança comum de APIs é um saldo que um servidor debita em relação a uma conta que ele consegue identificar. Aqui não existe uma conta identificável, então a correção precisa vir de provar que um depósito existe e ainda não foi usado. A parte difícil muda de contabilidade para unicidade, e a unicidade é resolvida on-chain.
3. O provador fica com o cliente. Conseguir pagar agora depende do software que o usuário executa, não apenas de um servidor de cobrança permanecer ativo. Esse é um modo de falha diferente de uma indisponibilidade (outage), e é a parte que a maioria das pessoas descobre por último.
O design segue um framework publicado por Vitalik Buterin e Davide Crapis em fevereiro. O que observar é se os provedores aceitarão um pagamento que eles não conseguem atribuir, porque um trilho (rail) que ninguém cotou contra é só um cofre (vault) muito elegante.
Não é aconselhamento financeiro. Faça sua própria pesquisa.
#Ethereum #Web3 #Privacy