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é 🧵
Idea simple: un servidor entre la billetera y los proveedores de RPC. El servidor utiliza aleatoriamente una RPC diferente para cada solicitud. ¡Ejecuta esto en un TEE 🔒! La nube no ve tus solicitudes (¡cuidado, todavía metadatos!) - y el RPC no ve tu IP (ven la de la nube)
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.
Veo dos formas de implementar RPC rotativos: ➡️ 1. Implemente esta funcionalidad en las billeteras directamente. Ventajas 👍 •Rápido •Desventajas 👎 • Esto no se puede adaptar a ninguna billetera, ya que tendría que implementarse cada vez. • **Lo que es más importante**, los RPC siguen viendo la IP del usuario
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í.
Idea simple: un servidor entre la billetera y los proveedores de RPC. El servidor utiliza aleatoriamente una RPC diferente para cada solicitud. ¡Ejecuta esto en un TEE 🔒! La nube no ve tus solicitudes (¡cuidado, todavía metadatos!) - y el RPC no ve tu IP (ven la de la nube)
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.
Mostrar original
3.09 K
25
El contenido al que estás accediendo se ofrece por terceros. A menos que se indique lo contrario, OKX no es autor de la información y no reclama ningún derecho de autor sobre los materiales. El contenido solo se proporciona con fines informativos y no representa las opiniones de OKX. No pretende ser un respaldo de ningún tipo y no debe ser considerado como un consejo de inversión o una solicitud para comprar o vender activos digitales. En la medida en que la IA generativa se utiliza para proporcionar resúmenes u otra información, dicho contenido generado por IA puede ser inexacto o incoherente. Lee el artículo enlazado para más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. Los holdings de activos digitales, incluidos stablecoins y NFT, suponen un alto nivel de riesgo y pueden fluctuar mucho. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti según tu situación financiera.