Construção do tipo “comprove uma vez, monitore para sempre” para limites de equilíbrio sem revelar o endereço da garantia? – Privacidade

A questão central da pesquisa

Estamos tentando entender se existe uma construção com este formato:

Configuração de usuário única (ou muito rara) produz um identificador/credencial privado.
Depois disso, os verificadores podem verificar continuamente “ainda ≥ limite” em relação a um estado da cadeia pública em evolução sem aprender o endereço colateral A e sem que o usuário precise regenerar provas a cada época.

Dito de outra forma: podemos obter um cheque “gasto/não gasto” semelhante ao Tornado para elegibilidade limitesem revelar o endereço subjacente?

Caso de uso

Uma prova de fundos primitiva que preserva a privacidade. Isso pode ser usado para coisas como benefícios escalonados (por exemplo, níveis de cartão de crédito criptografado) e também empréstimos (prova de subscrição de ativos substanciais). Como isso idealmente funcionaria:

• O usuário mantém garantias (tokens) em carteira A.

• O provedor do cartão vincula níveis/benefícios a um carteira de gastos B (mais tarde o usuário pode mudar para carteira C).

• Queremos que o provedor conceda/mantenha um nível para B/C sem nunca aprender a carteira Ae, de preferência, sem que terceiros aprendam A.

• O nível deve permanecer válido apenas enquanto a garantia permanecer acima de um limite (ou pelo menos dentro de alguma janela de atualização).

Procuramos uma construção que atinja o máximo possível:

1. Privacidade de endereço: o verificador (provedor do cartão) não pode aprender o endereço colateral A e, idealmente, nenhum operador aprende A também.

2. Elegibilidade/revogação contínua: verificador pode verificar se o usuário está ainda elegível (garantia ainda ≥ limite) ao longo do tempo.

3. Baixa carga do usuário: o usuário não deve ter que gerar constantemente novas provas (de preferência, configuração única e, em seguida, monitoramento/verificação passiva).

4. Portabilidade da carteira: o usuário pode mudar a “carteira de benefícios” B → C sem revelar A.

5. Intransferibilidade/anti-aluguel: um terceiro não deve ser capaz de reutilizar/roubar credenciais para reivindicar um nível para sua própria carteira.

6. Funciona com cadeias ERC-20/EVM existentes (de preferência sem modificar o contrato do token).

Construções que consideramos (e suas desvantagens)

O usuário gera provas ZK a partir do estado da cadeia (nenhum operador aprende A)

O usuário comprova conhecimento de um endereço A (oculto) cujo valor de saldo/armazenamento em uma prova de estado é ≥ X.
Emitir: o frescor requer a repetição de provas (a cada época / periodicamente / sob demanda), porque a raiz do estado da cadeia muda.

O que estamos pedindo à comunidade

1. Existe um primitivo/papel/protocolo conhecido que permite a elegibilidade de limite no estilo “provar uma vez, monitorar para sempre” para saldos mantidos externamente sem revelar o endereço e sem provas de usuário recorrentes?

2. Se a resposta for “não”, alguém pode formalizar a intuição de obstrução/impossibilidade sob suposições razoáveis ​​(modelo de conta estilo EVM, sem modificações de token, sem operador confiável)?

3. Existem relaxamentos que tornam isso possível e ao mesmo tempo prático? Por exemplo:

   • permitir modificar o contrato de token/staking para manter compromissos

   • permitir um observador baseado em MPC/TEE que aprenda A, mas seja criptograficamente restrito

   • aceitar atualizações de usuário muito pouco frequentes (semanal/mensal) em vez de a cada época

Esclarecimentos sobre o modelo de ameaça

• O o provedor/verificador do cartão não é confiável com identidade colateral.

• Também nos preocupamos com os observadores da cadeia que correlacionam A ↔ B/C.

• Provavelmente precisaremos intransferibilidade para evitar o aluguel de níveis para carteiras de terceiros (portanto, “credencial de portador” não é aceitável, a menos que seja explicitamente delegada).