Me encanta que se esté investigando más sobre la privacidad a nivel de RPC. Es una parte de la privacidad de Ethereum que ha sido poco investigada y poco apreciada, y que merece una solución. Desafortunadamente, rotar los RPCs no es esa solución, al menos en la forma descrita aquí. Aquí está el porqué 🧵
Idea simple: un servidor entre la billetera y los proveedores de RPC. El servidor utiliza aleatoriamente un RPC diferente para cada solicitud. ¡Ejecuta esto en un TEE 🔒! La nube no ve tus solicitudes (¡cuidado, todavía ven los metadatos!) - y el RPC no ve tu IP (ven la de la nube)
𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Ningún proveedor debería poder asociar tu dirección de Ethereum con tu dirección IP. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Ningún proveedor debería poder asociar dos de tus direcciones de Ethereum entre sí. Particularmente importante en el contexto de direcciones sigilosas.
La primera solución propuesta no resuelve ninguno de los problemas. De hecho, empeora el problema 1: en lugar de un proveedor que conoce tu IP y direcciones de Ethereum, ahora múltiples proveedores conocen ambas.
Veo dos formas de implementar RPCs rotativos: ➡️ 1. Implementar esta funcionalidad directamente en las carteras. Ventajas 👍 • Rápido • Desventajas 👎 • No se puede adaptar a ninguna cartera ya que tendría que implementarse cada vez. • **Más importante** los RPCs aún ven la IP del usuario.
La segunda solución resuelve el problema 1 al introducir un middleware en un TEE. Es esencialmente un proxy ciego, cuya ceguera es proporcionada por el TEE. Pero el problema 2 sigue sin resolverse: los proveedores aún pueden asociar tus direcciones de Ethereum entre sí.
Idea simple: un servidor entre la billetera y los proveedores de RPC. El servidor utiliza aleatoriamente un RPC diferente para cada solicitud. ¡Ejecuta esto en un TEE 🔒! La nube no ve tus solicitudes (¡cuidado, todavía ven los 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 como se pretende, el cliente aún necesita verificar que el middleware con el que está hablando realmente se está ejecutando en un TEE. De lo contrario, el cliente (billetera) no puede estar seguro de que el middleware no esté registrando todo.
El cliente puede verificar esto realizando un baile 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 sería más fácil de implementar que simplemente integrar una red de mezcla real.
Un proxy debería ser ciego a lo que transmite. La criptografía resuelve esto sin necesidad de suposiciones de confianza en TEE. Las mixnets como Tor/Nym/HOPR funcionan de esta manera: Encriptar la carga útil en múltiples capas de encriptación, donde cada salto quita una capa de encriptación de la cebolla.
¿Por qué no se utilizan las mixnets hoy en día? - Los usuarios no piden privacidad a nivel RPC a sus desarrolladores de billeteras. Walletbeat soluciona esto. - Expectativas de UX de RPCs de <100ms. Las mixnets/middleware añaden latencia. - La integración en billeteras de navegador requiere reimplementar TLS en JS para cifrar el último salto.
Los mixnets por sí solos tampoco resuelven el problema 2. El problema sigue siendo que rotar los RPC de manera ingenua (proveedor aleatorio en cada solicitud) es en realidad 𝙒𝙊𝙍𝙎𝙀 para la privacidad: significa que múltiples proveedores obtienen una vista de múltiples de tus direcciones a lo largo del tiempo.
Mejor solución: para un RPC sobre `address`, siempre envíalo al proveedor #`hash(address) módulo num_providers`. En otras palabras, las consultas sobre la misma dirección van al mismo proveedor de RPC. Esto asegura que ningún proveedor aprenda tu conjunto completo de direcciones.
También es mejor tener más proveedores de los que tienes direcciones. De esta manera, cada proveedor aprende una de tus direcciones, o ninguna; nunca múltiples. ¿Pero la verdadera solución? - ¡Ejecuta tu propio nodo! - Pide a tu desarrollador de billetera que comience a preocuparse por la privacidad a nivel RPC.
Cosas que no cubrí pero que también importan: - Ataques de correlación de tiempo RPC. - Monederos que consultan el saldo de múltiples direcciones en un solo RPC. - Solicitudes que no son de Ethereum que filtran datos similares. Los monederos de hoy están llenos de esos; pregúntame cómo lo sé. - L2s con puntos finales centralizados. (lol)
Incluso si este hilo parece crítico con el trabajo de @jimouris, quiero enfatizar que no está destinado a ser un ataque. Respeto mucho a cualquiera que realmente se atreva a abordar este problema. Está poco investigado y necesita más atención, así que es alentador ver a personas trabajando en ello.
Mostrar original
3,11 mil
25
El contenido de esta página lo proporcionan terceros. A menos que se indique lo contrario, OKX no es el autor de los artículos citados y no reclama ningún derecho de autor sobre los materiales. El contenido se proporciona únicamente 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 vinculado para obtener más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. El holding de activos digitales, incluyendo stablecoins y NFT, implican un alto grado de riesgo y pueden fluctuar en gran medida. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti a la luz de tu situación financiera.