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ê 🧵
Ideia simples: um servidor entre a carteira e os provedores de RPC. O servidor usa aleatoriamente um RPC diferente para cada solicitação. Execute isso em um TEE 🔒! A nuvem não vê suas solicitações (cuidado, eles ainda metadados!) - e o RPC não vê seu IP (eles veem o da nuvem)
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.
Vejo duas maneiras de implementar RPCs rotativos: ➡️ 1. Implemente essa funcionalidade diretamente nas carteiras. Vantagens 👍 •Rápido •Desvantagens 👎 • Isso não pode ser adaptado a nenhuma carteira, pois precisaria ser implementado todas as vezes. • **Mais importante** RPCs ainda veem o IP do usuário
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.
Ideia simples: um servidor entre a carteira e os provedores de RPC. O servidor usa aleatoriamente um RPC diferente para cada solicitação. Execute isso em um TEE 🔒! A nuvem não vê suas solicitações (cuidado, eles ainda metadados!) - e o RPC não vê seu IP (eles veem o da nuvem)
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.
Mostrar original
3,1 mil
25
O conteúdo desta página é fornecido por terceiros. A menos que especificado de outra forma, a OKX não é a autora dos artigos mencionados e não reivindica direitos autorais sobre os materiais apresentados. O conteúdo tem um propósito meramente informativo e não representa as opiniões da OKX. Ele não deve ser interpretado como um endosso ou aconselhamento de investimento de qualquer tipo, nem como uma recomendação para compra ou venda de ativos digitais. Quando a IA generativa é utilizada para criar resumos ou outras informações, o conteúdo gerado pode apresentar imprecisões ou incoerências. Leia o artigo vinculado para mais detalhes e informações. A OKX não se responsabiliza pelo conteúdo hospedado em sites de terceiros. Possuir ativos digitais, como stablecoins e NFTs, envolve um risco elevado e pode apresentar flutuações significativas. Você deve ponderar com cuidado se negociar ou manter ativos digitais é adequado para sua condição financeira.