Créditos de uso da API ZK: LLMs e além – Página 2 – Aplicativos

eu não vejo isso. você pode compartilhar o link certo?

zeko-labs/developer_demos/tree/main/agent_coordenation_protocol-financial_intelligence

Excelente design de protocolo para a camada de uso anônimo. A abordagem de acumulação de reembolso RLN + resolve com elegância a desvinculação da solicitação.

No entanto, uma lacuna que notei é o próprio depósito. O exemplo inicial mostra um usuário depositando 100 USDC no contrato inteligente. Esse depósito é uma transação pública em cadeia que vincula o endereço do usuário (e a identidade, por meio de trilhas KYC de troca) ao contrato. Os observadores da cadeia sabem que o usuário está usando serviços privados de IA antes de fazer uma única consulta.

Isso piora com os padrões de uso de IA. Ao contrário das transferências de pessoa para pessoa, onde os usuários podem depositar com bastante antecedência e sacar em intervalos imprevisíveis, o faturamento da IA ​​é de alta frequência e imediato. Um desenvolvedor deposita 100 USDC e, em poucos minutos, o sistema mostra a atividade de um novo compromisso de identidade. A correlação temporal entre o depósito e o primeiro uso é trivialmente vinculável, especialmente para valores de depósito menores com conjuntos de anonimato esparsos.

Também existe o risco no nível dos ativos. A função de lista negra administrativa do USDC já foi usada para congelar fundos em contratos adjacentes à privacidade, o que significa que a garantia de privacidade depende da cooperação contínua de um emissor centralizado.

Duas direções possíveis que valem a pena explorar:

1. Um mecanismo de depósito protegido onde os valores dos depósitos ficam ocultos dentro de um comprovante ZK e o vínculo do depositante com seu compromisso de identidade é quebrado no momento do depósito, não apenas no momento do uso. Se os fundos “nascerem” dentro do ambiente protegido (por exemplo, cunhados contra garantias excessivas em vez de depositados como um token existente), o ataque de correlação temporal desaparece completamente.

2. Integrar prova de inocência (de acordo com o modelo de grupos de privacidade de Buterin/Soleimani/Illum) para que os usuários possam demonstrar voluntariamente a conformidade regulatória sem quebrar a privacidade em nível de protocolo, abordando a preocupação W-9/KYC levantada em outro comentário.

Pessoas que desejam privacidade podem simplesmente executar em uma máquina local; daqui a alguns anos, qualquer PC será capaz de executar o LLM

Eu simplesmente não vejo o caso de uso, parece ser um produto desenvolvido por PhDs em CS para PhDs em CS.

É uma matemática fantástica, não me entenda mal, mas quem a usaria e por quê? Não quero ser desagradável, apenas realista.

Não creio que ainda tenhamos qualquer evidência de que isso necessariamente será verdade. Parece provável que modelos equivalentes aos modelos SOTA atuais serão executados em hardware de consumo no futuro, mas o que é muito menos claro é se você não conseguirá executar um melhorar modelo em hardware em escala. Enquanto hardware maior produzir IA melhores/mais inteligentes/mais rápidas, haverá demanda por aluguel de acesso.

Além disso, mesmo que os LLMs estabilizem e se esquivem, esse protocolo pode ser usado para qualquer outra coisa parecida com o Steam pela qual alguém queira pagar. Eu adoraria algo assim para ignorar os captchas, por exemplo.

Obrigado pela proposta!

Parece-me que o depósito RLN aqui tenta cumprir dois propósitos ao mesmo tempo: participação reduzível para desencorajar o mau comportamento e pagamento pela prestação de serviços. Concordo que o RLN cumpre o primeiro requisito funcional, mas não tenho certeza sobre o último.

Concretamente, podemos ver aqui a mecânica de pagamento como um canal de pagamento. (Isenção de responsabilidade: estou vendo canais de pagamento em todos os lugares porque já trabalho no Lightning há alguns anos.) Ainda assim, acho que o modelo mental do canal é aplicável. Queremos transferência de valor do usuário para o provedor proporcionalmente à quantidade de serviço prestado, sem transação on-chain por cada solicitação. O provedor deve ter certeza de que a qualquer momento poderá reivindicar na rede a parte justa do depósito do usuário, proporcional aos serviços prestados.

Imagine depósito D paga 100 solicitações antecipadamente. Para simplificar, assuma um custo igual para cada solicitação e nenhuma mecânica de reembolso. Quando o provedor reivindica D? Não deveria ser imediato – isso significaria que o provedor pode aceitar o depósito e fugir sem prestar qualquer serviço. Também não deveria ocorrer após cada solicitação – isso seria equivalente a uma interação na cadeia por solicitação, o que queremos evitar. Portanto, o provedor irá reivindicar de vez em quando, por exemplo, a cada 10 solicitações.

Mas então, e se o usuário fizer 9 solicitações e, em seguida, assinar duas vezes deliberadamente e tentar reduzir seu próprio depósito? (Cf. preocupação de “auto-corte” mencionada por @4aelius.) Isso introduziria uma condição de corrida com alguma probabilidade diferente de zero de que o usuário acabe com seu próprio depósito e serviço fornecido. Racionalmente (e considerando o anonimato do usuário), esta deveria ser uma estratégia dominante, certo?

De forma mais geral: RLN é adequado para limitação de taxa, mas também é um bom pagamento mecanismo?