17 anos após o bloqueio de gênese do Bitcoin, o envio de criptomoedas ainda parece uma tarefa do desenvolvedor. Você precisa pedir ao destinatário um endereço de carteira, copiar uma string hexadecimal de 42 caracteres, certificar-se de que está na rede certa e adquirir um token de gás apenas para pagar a taxa. Perca qualquer etapa e os fundos serão perdidos para sempre. Enquanto isso, enviar uma mensagem para alguém leva três segundos – basta digitar o e-mail ou número de telefone.
Essa lacuna de UX não é um pequeno inconveniente – é a maior barreira para a adoção em massa da criptografia. A solução óbvia é mapear esses identificadores diretamente para endereços de blockchain. Mas toda tentativa ingênua de fazer isso descarta algo com que os usuários se preocupam cada vez mais: a privacidade. Qualquer pessoa que conheça seu e-mail pode obter seu endereço e, a partir daí, reconstruir todo o seu histórico financeiro na rede.
Esta postagem discute o HFIPay – um protocolo que preenche essa lacuna sem comprometer a privacidade.
O problema
O envio de criptomoeda ainda exige que o remetente conheça o endereço da carteira. Mesmo com melhorias de UX, o fluxo é: solicitar endereço → copiar string hexadecimal → selecionar a rede correta → adquirir token de gás → enviar.
Identificadores amigáveis – endereços de e-mail, números de telefone, identificadores sociais – já são a forma como as pessoas se identificam online. O objetivo natural é:
enviar criptografia para alice@example.com da mesma forma que você enviaria uma mensagem.
A abordagem ingênua mapeia o identificador para um endereço de forma determinística, por exemplo keccak256(identifier) → address. Isso é simples, mas introduz uma falha crítica de privacidade: qualquer pessoa que conheça o e-mail de Alice pode obter seu endereço na rede e inspecionar seu histórico completo de transações, saldos de tokens e relacionamentos com contrapartes – em todas as cadeias suportadas.
Solução: HFIPay e o que ele faz
HFIPay é um protocolo – não um aplicativo – que qualquer carteira ou aplicativo de pagamento pode integrar. Ele habilita as seguintes propriedades no nível do protocolo:
- Nenhuma configuração de carteira necessária para o destinatário — os fundos podem ser enviados antes
o destinatário já abriu um aplicativo criptográfico - Resistência à enumeração – os dados da rede não revelam nada sobre qual
as intenções pertencem a um e-mail, telefone ou identificador social conhecido - Desvinculação pré-reivindicação — vários pagamentos para o mesmo identificador
não deixe nenhuma etiqueta de destinatário reutilizável na rede - Reivindicação sem custódia — as rotas de retransmissão, mas não podem redirecionar fundos;
somente o destinatário pode autorizar a liberação por meio de uma prova ZK - Independente de identificador — funciona com qualquer identificador verificável: e-mail,
telefone, identificador X ou outros
om o protocolo HFIPay, qualquer pessoa pode:
- Envie criptografia para qualquer pessoa — não há necessidade de saber o endereço da carteira do destinatário,
ou mesmo se eles têm um. - O destinatário reivindica fundos mediante notificação – se eles não tiverem carteira
ainda assim, um pode ser criado instantaneamente no momento da reivindicação. - Reivindicação automática após o primeiro uso — uma vez que um destinatário tenha reivindicado uma vez, futuro
os pagamentos podem ser reivindicados automaticamente sem ação manual. - O remetente pode cancelar dentro de um intervalo de tempo — se o destinatário nunca reclamar,
o remetente pode recuperar os fundos antes do tempo limite. - Transferências não reclamadas são reembolsadas automaticamente – após o vencimento
janela, os fundos são devolvidos ao remetente sem qualquer intervenção manual.
Como isso se compara ao ENS?
ENS é o sistema de nomenclatura mais maduro no ecossistema Ethereum e resolve um problema real: substituir endereços hexadecimais opacos por nomes legíveis por humanos. HFIPay está resolvendo um problema diferente. Aqui está uma comparação neutra de recursos:
| ENS | HFIPay | |
|---|---|---|
| Tipo de identificador | .eth nome (deve registrar) |
E-mail/telefone (já existe, sem configuração) |
| Mapeamento na cadeia | Público, enumerável | Não armazenado na cadeia |
| Modelo de privacidade | O endereço é público por design | Chain vê apenas um valor cego por intenção |
| Configuração do destinatário | Necessário antes de receber | Opcional (integração lenta possível) |
| Enumeração de identificador | Qualquer pessoa pode consultar qualquer nome | O estado da cadeia não revela nenhum identificador |
| Suposição de confiança | Contrato ENS (descentralizado) | Retransmissão (veja modos de confiança abaixo) |
ENS e HFIPay não estão competindo. Um relé HFIPay poderia resolver internamente .eth nomes como um tipo de identificador entre outros. A diferença está nas informações que são comprometidas na rede e nas garantias de privacidade que se seguem.
Como isso se compara ao ERC-5564 (endereços furtivos)?
ERC-5564 esconde onde os fundos chegam à rede: o endereço do destinatário é efêmero e não pode ser vinculado à sua chave pública. HFIPay esconde uma etapa anterior:
como um identificador amigável é mapeado para qualquer destino da rede.
Sender knows: alice@example.com
↓
(Relay: private resolution) ← HFIPay's scope
↓
On-chain: blinded intent
↓
(ZK claim by recipient)
↓
Destination address (could be a stealth address) ← ERC-5564's scope
Os dois mecanismos são complementares. O HFIPay pode encaminhar fundos para um novo endereço furtivo em cada pagamento, combinando privacidade em nível de identificador e em nível de endereço.
O mecanismo HFIPay (informal)
O protocolo separa três preocupações:
1. Roteamento privado (fora da cadeia)
O remetente especifica alice@example.com. Uma retransmissão resolve isso de forma privada para um registro de destinatário registrado e faz uma amostra de um novo intentId. Ele deriva um endereço de depósito único e confirma apenas uma intenção específica encadernação cega ρᵢ juntamente com o ativo cotado e o valor. A cadeia não vê o identificador nem uma etiqueta de destinatário reutilizável.
2. Verificação de cotação do remetente (opcional)
No cotação verificada implantação, o retransmissor retorna um atestado fora da cadeia ligando ρᵢ ao compromisso de chave de ligação oculta do destinatário pretendido. O remetente pode verificar isso antes do financiamento – o retransmissor não pode redirecionar silenciosamente os fundos para um destinatário diferente.
3. Autorização de reivindicação na rede
Para reivindicar fundos, o destinatário prova com conhecimento zero (via ZK-ACE) que a vinculação cega da intenção financiada corresponde a um identificador derivado de sua identidade determinística, autorizando a liberação para um destino de sua escolha. A retransmissão está envolvida no roteamento e na disponibilidade – ela não pode redirecionar fundos depois que a intenção é financiada.
Sender Relay Chain
| | |
|-- pay alice@email --> | |
| | (private lookup) |
|<-- quote (ρᵢ, τᵢ) --- | |
| | |
|-- fund intent --------|---------------------> |
| | |
Recipient
|
|-- ZK claim proof ---> |
|<-- funds released --- |
Propriedades de privacidade
O artigo formaliza duas propriedades:
Resistência de enumeração: Nenhum dado na cadeia permite que um observador determine quais intenções financiadas pertencem a um endereço de e-mail, número de telefone ou identificador social conhecido – mesmo que o observador conheça o identificador e possa ler todo o estado da cadeia.
Desvinculação pré-reivindicação: Vários pagamentos para o mesmo identificador antes de qualquer reclamação não expõem uma etiqueta de destinatário público reutilizável. Cada intenção usa uma vinculação cega independente. Após uma reivindicação bem-sucedida, o endereço de destino e o valor do ativo tornam-se visíveis na cadeia (como acontece com qualquer transação). O artigo caracteriza explicitamente o que se torna vinculável após a reivindicação.
Modos de confiança
O protocolo define dois modos de implantação, distinguindo qual confiança é colocada na retransmissão:
Implantação de linha de base: A retransmissão é confiável para vincular o destinatário correto a cada intenção. Adequado para carteiras integradas onde o retransmissor e o aplicativo compartilham um limite de confiança.
Implantação de cotação verificada: A retransmissão emite um atestado verificável pelo remetente antes do financiamento. Uma camada de ligação separada verifica de forma independente a propriedade do identificador (por exemplo, via e-mail OTP ou OIDC), de modo que a retransmissão não pode substituir um destinatário diferente sem que o remetente o detecte. A ligação é verificável pelo remetente sem um registro de identificador público. O tratamento formal completo está nas Seções 2 a 6 do artigo.
Implementação
Estamos construindo uma implementação aberta em hfi.networkincluindo infraestrutura de retransmissão e circuitos de reivindicação ZK. A exploração inicial da descentralização do relé está em curso. Comentários sobre o design do protocolo e o modelo de confiança são muito bem-vindos.
Artigo completo: arXiv:2603.26970
Fico feliz em discutir as definições formais de segurança, o esquema vinculativo de rotação de época ou a relação com outras propostas de pagamento baseadas em identificadores.
Fontesethresear
