Me encanta que se esté investigando más sobre la privacidad a nivel de RPC. Es una parte poco investigada y subestimada de la privacidad de Ethereum que merece una solución. Desafortunadamente, rotar los RPC no es esa solución, al menos en la forma descrita aquí. He aquí por qué 🧵

Problema 1: Ningún proveedor debería poder asociar su dirección Ethereum con su dirección IP. Problema 2: Ningún proveedor debería poder asociar dos de sus direcciones de Ethereum entre sí. Particularmente importante en el contexto de los discursos sigilosos.

La primera solución propuesta no resuelve ninguno de los dos problemas. De hecho, empeora el problema 1: en lugar de un proveedor que conoce sus direcciones IP y Ethereum, ahora varios de estos proveedores las conocen a ambas.

La segunda solución resuelve el problema 1 introduciendo un middleware en un TEE. Es esencialmente un proxy ciego, para el cual la ceguera es proporcionada por el TEE. Pero el problema 2 sigue sin resolverse: los proveedores aún pueden asociar sus direcciones de Ethereum entre sí.

Los TEE no son a prueba de balas. Pero incluso si asumimos que funcionan según lo previsto, el cliente aún necesita verificar que el middleware con el que está hablando se esté ejecutando realmente en un TEE. De lo contrario, el cliente (billetera) no puede estar seguro de que el middleware no esté registrando todo.

El cliente puede comprobarlo realizando una danza de atestación de carga de trabajo. Es posible, pero complicado de implementar. No he visto una implementación real de esto en la práctica, y no me queda claro si eso sería más fácil de implementar que simplemente integrar una red mixta real.

Un proxy debe estar ciego a lo que atraviesa. La criptografía resuelve esto sin la necesidad de suposiciones de confianza TEE. Las redes mixtas como Tor/Nym/HOPR funcionan de esta manera: Encripta la carga útil en múltiples capas de cifrado, donde cada salto pela una capa de cifrado de la cebolla.

¿Por qué no se usan mixnets hoy en día? - Los usuarios no piden privacidad a nivel de RPC a los desarrolladores de su billetera. Walletbeat soluciona esto. - Expectativas de UX de RPC de <100 ms. Las redes mixtas / middleware agregan latencia. - La integración en las billeteras del navegador requiere volver a implementar TLS en JS para cifrar el último salto.

Las redes mixtas por sí solas tampoco resuelven el problema 2. El problema sigue siendo que rotar los RPC ingenuamente (proveedor aleatorio en cada solicitud) es en realidad peor para la privacidad: significa que varios proveedores obtienen una vista de varias de sus direcciones a lo largo del tiempo.

Mejor solución: para un RPC sobre 'dirección', envíelo siempre al proveedor #'hash(address) modulo num_providers'. En otras palabras, las consultas sobre la misma dirección van al mismo proveedor de RPC. Esto garantiza que ningún proveedor conozca su conjunto completo de direcciones.

También es mejor tener más proveedores que direcciones. De esta manera, cada proveedor aprende una de sus direcciones o ninguna; nunca múltiples. ¿Pero la verdadera solución? - ¡Ejecuta tu propio nodo! - Pídele al desarrollador de tu billetera que comience a preocuparse por la privacidad a nivel de RPC.

Cosas que no cubrí pero que también importan: - Ataques de correlación de sincronización RPC. - Billeteras que buscan el saldo de varias direcciones en un solo RPC. - Solicitudes que no son de Ethereum que filtran datos similares. Las billeteras de hoy están llenas de esos; pregúntame cómo lo sé. - L2 con puntos finales centralizados. (ja)

Incluso si este hilo parece crítico con el trabajo de @jimouris, quiero enfatizar que no pretende ser una volcada. Respeto mucho a cualquiera que realmente dé un paso al frente para abordar este problema. Esto no se ha investigado lo suficiente y necesita más atención, por lo que es alentador ver a la gente trabajando en ello.