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, contratos inteligentes).

• 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 alguém

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?

Em uma carteira como a metamask que gera vários endereços, existe a noção de mudar para contas diferentes para ver o saldo de cada conta.

Nesse tipo de carteira haveria uma consolidação de todos os seus ativos juntos. Da mesma forma que você recebeu 100 USDC na conta um e 200 USDC na conta dois, 300 USDC na conta três. A carteira deve exibir 600 USDC. E se você quiser gastar 550 USDC você pode fazê-lo. Além disso, durante o envio, você pode decidir se deseja enviar anonimamente (diretamente do pool de mixagem) ou por meio de uma de suas identidades de endereço furtivo (por exemplo, para interações com estado no DeFi).

Conceitualmente, é exatamente o mesmo que metamask múltiplas contas + pool de mixagem, onde o usuário faz manualmente os depósitos no pool de mixagem e gerencia muitos endereços. Mas é a complexidade que pode ser facilmente abstraída na camada do aplicativo. Receber dinheiro em um endereço e usar outra identidade de endereço para usá-lo (como DeFi ou apostas) pode ser feito tecnicamente usando um mixer, mas as pessoas acabam não fazendo isso porque são muitas etapas.

As implementações de endereços furtivos do Iirc já lidam com a complexidade de criação de endereços e agregação de saldos. Por exemplo, Fluidkey, você pode dar às pessoas um ENS (andyguzman.fkey.eth) para o qual as pessoas podem enviar dinheiro, mas toda vez que é usado, ele muda para um novo endereço. Acredito que Curvey e Umbra Cash têm propriedades semelhantes

Iiu. o que vejo de novo aqui é a integração de endereços furtivos que enviam automaticamente para mixers/pools, o que combina ambos e fornece sigilo de encaminhamento