Endereços furtivos interativos sem aceitação – Privacidade

Um aviso para evitar confusão, esta é uma ideia diferente dos endereços furtivos ERC-5564, onde um remetente calcularia um endereço furtivo para um receptor não interativo.

Resumo

• Nessa ideia, o destinatário calcula o endereço e compartilha com o remetente (não integrado à privacidade, usa sistemas legados como metamask, exchanges, carteiras públicas).

• Este é um aplicativo que pode ser desenvolvido com base em um esquema de privacidade existente.

• Para poder permanecer privado, as pessoas com quem você faz transações não precisam usar uma carteira baseada em privacidade. Mas você precisa que o esquema de privacidade subjacente tenha um conjunto de anonimato suficientemente grande.

• É possível que o aplicativo seja interoperável com outros esquemas de privacidade usando ERC-6538, fazendo com que funcione com usuários que usam seu próprio esquema de privacidade, nenhum esquema de privacidade e, potencialmente, outros esquemas de privacidade também.

Motivação

A maioria das soluções de endereço furtivo são de aceitação do usuário, ou seja, ambos os usuários precisam seguir o mesmo protocolo ou conjunto de regras. E existem muitos protocolos. Aztec, ERC-5564, Railgun, Tornado Nova, zkBoB e muitos mais.

Portanto, se uma pessoa A quiser pagar a pessoa B, ambas as personas deverão estar inscritas no mesmo protocolo. Se assumirmos isso, então são flores e arco-íris, mas na prática a maioria das pessoas não usa nenhum protocolo de privacidade e, se alguns usarem, pode não ser o que você possui.

Soluções atuais:

• O usuário adere a vários protocolos de privacidade populares para ser compatível com qualquer um lá fora.

• O usuário apenas permanece no Ethereum público enquanto cria vários endereços de carteira onde todas as nossas transações são públicas. Embora os fundos sejam fragmentados para evitar que as pessoas descubram o seu verdadeiro saldo, o usuário pode receber fundos de qualquer um. Mas é preciso tomar cuidado para que os endereços não se conectem diretamente entre si e usem coisas como dinheiro tornado.

• Basta manter os fundos em uma bolsa centralizada para receber depósitos de qualquer um.

Um enorme desafio na adoção da privacidade para pagamentos é a exigência de que tanto o remetente quanto o destinatário dos participantes usem um software que suporte o mesmo protocolo. Isso causa inscrições em protocolos de privacidade devido à novidade, mas o usuário acaba fazendo transações públicas principalmente porque as pessoas com quem interage não se inscreveram, a menos que tenham a sorte de ter colegas que se inscreveram no mesmo sistema.

Resumo

Esta postagem é sobre uma solução potencial que pode permitir que um usuário opte por manter seus saldos razoavelmente privados, ao mesmo tempo que permite enviar ou receber fundos de e para endereços públicos de Ethereum. Esta solução é um aplicativo que pode ser construído sobre qualquer esquema de privacidade baseado em UTXO existente, semelhante ao tornado nova. Está tudo bem se o aplicativo estiver integrado por pelo menos uma carteira. O usuário pode gerar vários endereços EVM sozinho. Eles interagem com um remetente, fornecendo-lhes um novo endereço. Este endereço é pré-calculado usando CREATE2. Assim que os fundos são recebidos, o software da carteira os coleta usando um retransmissor para o esquema de privacidade subjacente, criando um UTXO que o usuário pode gastar em transações futuras.

Esta solução é interativa. Na maioria dos casos de uso diário, como pagamentos a amigos ou clientes, a interação está envolvida, pois as pessoas ainda perguntam “você quer na rede principal ou em algum L2 específico? prefere ETH ou DAI ou USDC?”. Aqui o próprio usuário irá gerar um novo endereço e fornecê-lo ao remetente, essa é a interação. O endereço stealth CREATE2 não precisa ser um EIP/ERC, pois é um aplicativo e os outros usuários não precisam aceitar seguir algum novo protocolo.

Como funciona?

Posso vincular o código de um PoC do ano passado para expressar alguns detalhes.

1. O usuário ingressa neste sistema

O usuário instala software que segue o protocolo descrito. Ele gera um segredo de 32 bytes e o armazena para uso futuro.

2. O usuário deseja receber dinheiro de um cliente

O usuário gera um novo endereço furtivo, que é gerado da seguinte forma:

1. Hash de duas palavras: segredo de 32 bytes e um nonce de 32 bytes (pode ser incremental)

2. O hash é um sal de 32 bytes usado com CREATE2 para obter um endereço https://github.com/ultralane/contracts/blob/b8e17ce7099ffb358488579927308d5f73716dc3/contracts/MixerPool.sol#L162-L166

3. O usuário (destinatário) interage com o remetente enviando-lhe um endereço EVM.

4. O remetente pode enviar dinheiro para este endereço da maneira que desejar, através de metamask, retirada de exchange ou retirada de esquema de privacidade.

3. O usuário recebe dinheiro de um cliente

1. Esse dinheiro é enviado para um endereço pré-computado que é/será um contrato. https://github.com/ultralane/contracts/blob/b8e17ce7099ffb358488579927308d5f73716dc3/contracts/StealthAddress.sol

2. Software de carteira do usuário, uma vez online e percebe saldo no endereço furtivo:

   1. Ele gera uma nota secreta com base na especificação do esquema de privacidade subjacente. Normalmente, essas notas são secretas, juntamente com o valor e uma ligação aleatória para evitar colisões. https://github.com/ultralane/circuits/blob/42e39cd95345c6c47ee8b363854262ab03f29731/lib/src/note.nr#L3-L7

   2. Prova localmente que o usuário conhece a pré-imagem do sal.

   3. Ele também adiciona o compromisso da nota para que um retransmissor não possa adulterá-lo (esta parte não está presente no PoC).

   4. Essa carga útil é então dada a um retransmissor que chama uma função no pool que faz uma transação pública movendo os fundos para o pool de privacidade que pode ser gasto pelo usuário. https://github.com/ultralane/contracts/blob/b8e17ce7099ffb358488579927308d5f73716dc3/contracts/MixerPool.sol#L133-L160

   5. Além disso, o endereço furtivo também pode registrar-se no registro ERC-6538. Para que futuras transferências para este endereço de alguns usuários de privacidade optantes possam usar uma rota eficiente.

O usuário deseja enviar dinheiro

Conclusões

• Esta solução não funciona diretamente no caso de recebimento de doações de pessoas desconhecidas de forma não interativa. Como colocar um endereço no seu leia-me do GitHub para qualquer financiamento. Já que todas as transações para o mesmo endereço ficarão visíveis. É exatamente aqui que o ERC-5564 brilha, pois o remetente cria um novo endereço aqui, mas exige que o remetente aceite. Para doações. Nos repositórios, as pessoas geralmente listam muitos endereços como BTC, ETH, Monero, eles poderiam listar outro endereço x do esquema de privacidade Railgun ou mais, em vez de um endereço eth (porque é provável que o usuário não tenha ideia sobre endereços furtivos ou esteja usando um software de carteira desatualizado).

• Pode ser possível combinar endereços furtivos CREATE2 com ERC-5564 usando ERC-6538 e mais esquemas de privacidade. Basicamente, durante a coleta de fundos, o endereço furtivo CREATE2 pode registrar-se no registro com vários esquemas de privacidade. Sei que o ERC-6538 é realmente muito poderoso e pode possibilitar que uma carteira interopere com vários esquemas de privacidade.

• O endereço furtivo CREATE2 é indistinguível de outros EOAs até que os fundos nele contidos sejam coletados, o que acontecerá em algum momento. Portanto, é possível que alguém escaneie a cadeia para encontrar facilmente endereços furtivos usados ​​e rastrear fundos enviados para pools de privacidade.

• As questões de revelar IP aos retransmissores são óbvias.

Qual a diferença entre isso e uma carteira que apenas gera um novo EOA para cada destinatário?