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

Problema 1: Nenhum provedor deve ser capaz de associar seu endereço Ethereum ao seu endereço IP. Problema 2: Nenhum provedor deve ser capaz de associar dois de seus endereços Ethereum um ao outro. Particularmente importante no contexto de endereços furtivos.

A primeira solução proposta não resolve nenhum dos problemas. Na verdade, isso piora o problema 1: em vez de um provedor que conhece seus endereços IP e Ethereum, agora vários desses provedores conhecem os dois.

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

Os TEEs não são à prova de balas. Mas mesmo se assumirmos que eles funcionam conforme o esperado, o cliente ainda precisa verificar se o middleware com o qual está falando está realmente sendo executado em um TEE. Caso contrário, o cliente (carteira) não pode ter certeza de que o middleware não está realmente registrando tudo.

O cliente pode verificar isso executando uma dança de atestado de carga de trabalho. É possível, mas complicado de implementar. Eu 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 um mixnet real.

Um proxy deve ser cego para o que passa. A criptografia resolve isso sem a necessidade de suposições de confiança TEE. Mixnets como Tor/Nym/HOPR funcionam desta maneira: criptografe a carga útil em várias camadas de criptografia, onde cada salto descasca uma camada de criptografia da cebola.

Por que as mixnets não são usadas hoje? - Os usuários não pedem privacidade no nível RPC de seus desenvolvedores de carteira. O Walletbeat corrige isso. - Expectativas de UX de RPCs de <100ms. Mixnets/middleware adicionam latência. - A integração em carteiras de navegador requer a reimplementação de TLS em JS para criptografar o último salto.

Mixnets sozinhos também não resolvem o problema 2. O problema é que a rotação ingênua de RPCs (provedor aleatório em cada solicitação) é realmente pior para a privacidade: significa que vários provedores obtêm uma visão de vários de seus endereços ao longo do tempo.

Melhor solução: para um RPC sobre 'endereço', sempre envie-o para o provedor #'hash(address) módulo num_providers'. Em outras palavras, as consultas sobre o mesmo endereço vão para o mesmo provedor de RPC. Isso garante que nenhum provedor aprenda seu conjunto completo de endereços.

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

Coisas que não abordei, mas também importam: - Ataques de correlação de tempo RPC. - Carteiras que procuram o saldo de vários endereços em um único RPC. - Solicitações não Ethereum que vazam dados semelhantes. As carteiras de hoje estão cheias dessas; pergunte-me como eu sei. - L2s com endpoints centralizados. (risos)

Mesmo que este tópico pareça crítico ao trabalho de @jimouris, quero enfatizar que ele não pretende ser uma enterrada. Eu respeito muito qualquer um que realmente se apresente para resolver esse problema. Isso é pouco pesquisado e precisa de mais atenção, por isso é animador ver as pessoas trabalhando nisso.