Adoro que mais pesquisas estejam a ser feitas sobre a privacidade a nível de RPC. É uma parte da privacidade do Ethereum que é pouco pesquisada e pouco apreciada, e que merece uma solução. Infelizmente, rotacionar RPCs não é essa solução, pelo menos na forma descrita aqui. Aqui está o porquê 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Nenhum fornecedor deve ser capaz de associar o seu endereço Ethereum ao seu endereço IP. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Nenhum fornecedor deve ser capaz de associar dois dos seus endereços Ethereum entre si. Particularmente importante no contexto de endereços furtivos.

A primeira solução proposta não resolve nenhum dos problemas. Na verdade, torna o problema 1 𝙬𝙤𝙧𝙨𝙚: em vez de um único fornecedor que conhece o seu IP e endereços Ethereum, agora 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 desses fornecedores os conhecem ambos.

A segunda solução resolve o problema 1 ao introduzir um middleware em um TEE. É essencialmente um proxy cego, cuja cegueira é fornecida pelo TEE. Mas o problema 2 permanece sem solução: os provedores ainda podem associar os seus endereços Ethereum uns com os outros.

As TEEs não são à prova de balas. Mas mesmo que assumamos que funcionam como pretendido, o cliente ainda precisa verificar se o middleware com o qual está a falar está realmente a correr num TEE. Caso contrário, o cliente (carteira) não pode ter certeza de que o middleware não está a registar tudo.

O cliente pode verificar isso realizando uma dança de atestação de carga de trabalho. É possível, mas complicado de implementar. Não vi uma implementação real disso na prática, e não está claro para mim se isso seria mais fácil de implementar do que apenas integrar uma mixnet real.

Um proxy deve ser cego ao que passa. A criptografia resolve isso sem a necessidade de suposições de confiança em TEE. Mixnets como Tor/Nym/HOPR funcionam dessa forma: Encriptar a carga útil em múltiplas camadas de encriptação, onde cada salto remove uma camada de encriptação da cebola.

Por que os mixnets não são usados hoje? - Os utilizadores não pedem privacidade a nível de RPC aos desenvolvedores das suas carteiras. O Walletbeat resolve isso. - Expectativas de UX de RPCs <100ms. Mixnets/middleware adicionam latência. - A integração em carteiras de navegador requer a reimplementação do TLS em JS para encriptar o último salto.

As redes de mistura sozinhas também não resolvem o problema 2. O problema permanece que rotacionar RPCs de forma ingênua (fornecedor aleatório em cada solicitação) é na verdade 𝙜𝙤𝙨𝙩𝙤 para a privacidade: isso significa que múltiplos fornecedores têm uma visão de múltiplos dos seus endereços ao longo do tempo.

Solução melhor: para um RPC sobre `endereço`, envie sempre para o provedor #`hash(endereço) módulo num_providers`. Em outras palavras, consultas sobre o mesmo endereço vão para o mesmo provedor RPC. Isto garante que nenhum provedor aprenda o seu conjunto completo de endereços.

É também melhor ter mais fornecedores do que endereços. Desta forma, cada fornecedor aprende um dos seus endereços, ou nenhum; nunca múltiplos. Mas a verdadeira solução? - Execute o seu próprio nó! - Peça ao desenvolvedor da sua carteira para começar a se preocupar com a privacidade a nível de RPC.

Coisas que não cobri, mas que também importam: - Ataques de correlação de tempo RPC. - Carteiras que consultam o saldo de vários endereços em um único RPC. - Pedidos não-Ethereum que vazam dados semelhantes. As carteiras de hoje estão cheias disso; pergunte-me como eu sei. - L2s com pontos finais centralizados. (lol)

Mesmo que este tópico pareça crítico em relação ao trabalho de @jimouris, quero enfatizar que não é uma crítica destrutiva. Eu respeito muito quem realmente se dispõe a enfrentar este problema. Este assunto é pouco pesquisado e precisa de mais atenção, por isso é encorajador ver pessoas trabalhando nisso.