- Tema
21k Popularidad
5k Popularidad
15k Popularidad
4k Popularidad
5k Popularidad
9k Popularidad
11k Popularidad
44k Popularidad
136k Popularidad
1815k Popularidad
- Anclado
21k Popularidad
5k Popularidad
15k Popularidad
4k Popularidad
5k Popularidad
9k Popularidad
11k Popularidad
44k Popularidad
136k Popularidad
1815k Popularidad
Helios: implementación de cliente ligero de Ethereum para acceso a datos on-chain sin confianza.
Cliente ligero de Ethereum Helios: acceso a datos en cadena sin confianza
El 8 de noviembre, una conocida firma de capital de riesgo lanzó el cliente ligero de Ethereum Helios. Este cliente, escrito en el lenguaje Rust, tiene como objetivo proporcionar un acceso a Ethereum completamente sin confianza.
Una de las grandes ventajas de la tecnología blockchain es que no requiere confiar en terceros. A través de la blockchain, los usuarios pueden tener el control de su propia riqueza y datos. Blockchain como Ethereum, en la mayoría de los casos, realmente ha cumplido con esta promesa: nuestros activos realmente nos pertenecen.
Sin embargo, para buscar conveniencia, también hemos hecho algunas concesiones. Una de ellas es el uso de servidores RPC (llamada remota) centralizados. Los usuarios suelen acceder a Ethereum a través de proveedores centralizados. Estas empresas ejecutan nodos de alto rendimiento en servidores en la nube, ayudando a los usuarios a obtener fácilmente datos on-chain. Cuando una billetera consulta el saldo de tokens o verifica si una transacción pendiente ha sido empaquetada, casi siempre utiliza los servicios de estos proveedores centralizados.
El problema actual del sistema es que los usuarios necesitan confiar en estos proveedores, y no pueden verificar la precisión de los resultados de las consultas.
Helios es un cliente ligero de Ethereum basado en Rust, que puede proporcionar acceso a Ethereum completamente sin necesidad de confianza. Utiliza el protocolo de cliente ligero implementado tras la transición de Ethereum a PoS, que puede convertir los datos de proveedores de RPC centralizados no confiables en RPC local seguro y verificable. Combinando RPC centralizado, Helios puede verificar la veracidad de los datos sin necesidad de ejecutar un nodo completo.
Es un punto de dolor común la dificultad de equilibrar la conveniencia y la descentralización. Este nuevo cliente (abierto al público para su desarrollo continuo) puede completar la sincronización en aproximadamente dos segundos y no requiere espacio de almacenamiento, permitiendo a los usuarios acceder de manera segura a los datos on-chain a través de cualquier dispositivo (incluidos móviles y extensiones de navegador). Entonces, ¿cuáles son los riesgos potenciales de depender de infraestructuras centralizadas? Este artículo explorará en detalle estos riesgos, presentará el diseño de Helios y ofrecerá algunas recomendaciones para ayudar a los desarrolladores a contribuir al código.
Riesgos potenciales de la infraestructura centralizada: amenazas teóricas en el ecosistema de Ethereum
En el ecosistema de Ethereum, acecha una amenaza teórica. No busca objetivos en el pool de memoria de transacciones (Mempool), sino que establece trampas imitando la infraestructura centralizada de la que dependemos. Los usuarios que caen en esta trampa no han hecho nada malo: simplemente acceden a un DEX familiar como de costumbre, establecen un deslizamiento razonable y realizan transacciones de tokens... Sus operaciones no tienen ningún problema, pero podrían enfrentarse a un nuevo tipo de ataque sandwich, una trampa cuidadosamente dispuesta en la entrada del ecosistema de Ethereum - el proveedor de RPC.
Antes de detallar, veamos cómo DEX maneja las transacciones. Cuando los usuarios realizan un intercambio de tokens, proporcionan varios parámetros al contrato inteligente: el token a intercambiar, la cantidad a intercambiar y, lo más importante, la cantidad mínima de tokens que el usuario está dispuesto a aceptar. Este último parámetro determina el "mínimo de salida" que debe alcanzarse para que la transacción sea válida, de lo contrario, la transacción será revertida. Esto se conoce comúnmente como "slippage", ya que limita efectivamente la oscilación de precios máxima que puede ocurrir desde que la transacción se envía a la memoria hasta que se empaqueta en un bloque. Si el slippage se establece demasiado bajo, el usuario puede recibir menos tokens. Esta situación también puede dar lugar a ataques de sándwich, donde un atacante puede intercalar la transacción del usuario entre dos transacciones maliciosas. Estas transacciones elevarán el precio de mercado, obligando al usuario a ejecutar la transacción a un precio desfavorable. Posteriormente, el atacante venderá inmediatamente los tokens para obtener una pequeña ganancia.
Siempre que el parámetro de producción mínima esté configurado dentro de un rango razonable, los usuarios no se verán afectados por ataques de sándwich. Pero, ¿qué sucede si el proveedor de RPC no ofrece un precio exacto del contrato inteligente de DEX? En este caso, los usuarios pueden ser engañados para firmar transacciones de intercambio con parámetros de producción mínima más bajos. Peor aún, los usuarios pueden enviar transacciones directamente a proveedores de RPC maliciosos. Los proveedores pueden optar por no transmitir esta transacción a la memoria pública (donde hay muchos bots compitiendo en ataques de sándwich), sino que la retienen en privado y envían el paquete de transacciones atacadas directamente a plataformas específicas para obtener beneficios.
La raíz de este ataque radica en confiar en otros para ayudar a obtener el estado de la blockchain. Para abordar este problema, los usuarios experimentados suelen optar por ejecutar su propio nodo de Ethereum. Esto requiere una gran inversión de tiempo y recursos, al menos un dispositivo que esté en línea de forma continua, cientos de GB de espacio de almacenamiento y alrededor de un día para sincronizar desde cero. Aunque este proceso se ha simplificado mucho en comparación con el pasado, algunos equipos han estado trabajando para ayudar a los usuarios a ejecutar nodos con hardware de bajo costo, como una Raspberry Pi con un disco duro externo. Sin embargo, a pesar de que los requisitos se han reducido drásticamente, para la mayoría de los usuarios, especialmente aquellos que utilizan dispositivos móviles, ejecutar un nodo sigue siendo una tarea ardua.
Es importante tener en cuenta que, aunque es completamente posible que se produzcan ataques por parte de proveedores de RPC centralizados, actualmente sigue siendo un riesgo teórico y no ha ocurrido en la práctica. A pesar de que el historial de proveedores de renombre es confiable, se recomienda realizar una investigación exhaustiva antes de agregar proveedores de RPC desconocidos a la billetera.
Introducción a Helios: acceso a Ethereum completamente sin confianza
El protocolo de cliente ligero lanzado por Ethereum abre posibilidades emocionantes para interacciones rápidas en la cadena y la verificación de puntos finales RPC con los requisitos de hardware más bajos. En el mes siguiente a la fusión, aparecieron varios clientes ligeros independientes, que adoptaron diferentes enfoques, pero todos con el mismo objetivo: acceso eficiente sin confianza, sin necesidad de utilizar nodos completos.
Helios es un cliente ligero de Ethereum que puede completar la sincronización en aproximadamente dos segundos, sin necesidad de espacio de almacenamiento, y proporciona acceso a Ethereum completamente sin confianza. Al igual que todos los clientes de Ethereum, Helios se compone de una capa de ejecución y una capa de consenso. Pero a diferencia de la mayoría de los otros clientes, Helios combina estas dos capas de manera estrecha, permitiendo a los usuarios instalar y ejecutar un solo software.
Su funcionamiento es el siguiente: la capa de consenso de Helios utiliza un hash de bloque de cadena de señal conocido y se conecta a un RPC no confiable para sincronizar de manera verificable con el bloque actual. La capa de ejecución de Helios combina estos bloques de cadena de señal verificados con un RPC de capa de ejecución no confiable para validar diversas informaciones sobre el estado en cadena, como el saldo de cuentas, el almacenamiento de contratos, los recibos de transacciones y los resultados de las llamadas a contratos inteligentes. Estos componentes trabajan en conjunto para proporcionar a los usuarios un RPC completamente libre de confianza, sin necesidad de ejecutar un nodo completo.
capa de consenso
El cliente ligero de la capa de consenso sigue las especificaciones del cliente ligero de la cadena de señal y utiliza el comité de sincronización de la cadena de señal (introducido en la bifurcación dura Altair antes de la fusión). El comité de sincronización está compuesto por un subconjunto de 512 validadores seleccionados al azar, con un período de servicio de aproximadamente 27 horas.
Los validadores firmarán todos los encabezados de bloque de la cadena de balizas que vean una vez que entren en el comité de sincronización. Si más de dos tercios de los miembros del comité firman un encabezado de bloque, entonces es muy probable que ese bloque se encuentre en la cadena de balizas estándar. Si Helios entiende la composición actual del comité de sincronización, puede rastrear el encabezado de la cadena con alta certeza consultando firmas recientes del comité de sincronización a través de RPC no confiables.
Gracias a la agregación de firmas BLS, se puede completar la verificación del nuevo encabezado de bloque con una sola consulta. Siempre que la firma sea válida y más de dos tercios de los miembros del comité hayan completado la firma, se puede garantizar que el bloque está incluido en la cadena (por supuesto, también podría ser reestructurado fuera de la cadena, y el seguimiento de la finalización del bloque puede proporcionar una garantía más fuerte).
Pero en esta estrategia claramente falta un elemento: cómo encontrar el comité de sincronización actual. Primero, se necesita obtener una raíz de confianza llamada punto de verificación de debilidad subjetiva. Este es simplemente un hash de bloque antiguo que se puede garantizar que fue incluido en la cadena en un momento pasado. Hay algunos cálculos matemáticos interesantes detrás del tiempo exacto de existencia del punto de verificación: el análisis del peor de los casos muestra aproximadamente dos semanas, mientras que estimaciones más prácticas indican que puede ser de varios meses.
Si el punto de control es demasiado antiguo, en teoría existe un ataque que puede engañar a los nodos para que sigan una cadena incorrecta. En este momento, obtener un punto de control de debilidad subjetiva está más allá de las capacidades del protocolo. La solución de Helios es proporcionar un punto de control inicial, codificado en el repositorio de código (fácilmente sobreescribible), que guardará localmente el hash del bloque final más reciente para ser utilizado como punto de control al sincronizar los nodos.
A través de la operación de hash, los bloques de la cadena de señal pueden generar fácilmente un hash único de bloque de señal. De esta manera, se puede consultar fácilmente el bloque de señal completo a los nodos y luego, mediante la operación de hash y la comparación con el hash de bloque conocido, probar la validez del contenido del bloque. Helios utiliza esta característica para obtener y verificar ciertos campos dentro de los bloques de puntos de control de subjetividad débil, incluidos dos campos cruciales: el comité de sincronización actual y el próximo comité de sincronización. Lo más importante es que el cliente ligero puede utilizar este mecanismo para verificar rápidamente la historia de la cadena de bloques.
Con el punto de control de débil subjetividad, podemos obtener y verificar el comité de sincronización actual y el siguiente. Si la cabeza de la cadena actual y el punto de control están dentro del mismo ciclo de comité de sincronización, podemos comenzar a usar la cabeza del comité de sincronización firmada para validar nuevos bloques. Si nuestro punto de control está detrás de varios comités de sincronización, entonces podemos:
Utilizar el siguiente comité de sincronización después del punto de control para obtener y verificar el bloque que generará un comité de sincronización en el futuro.
Utiliza este nuevo bloque para obtener el próximo comité de sincronización.
Si el punto de control aún está detrás, vuelve al paso 1.
A través de este proceso, podemos revisar rápidamente la historia de esta cadena de bloques en unidades de 27 horas, comenzando desde cualquier hash de bloque pasado hasta sincronizarnos con el hash de bloque actual.
capa de ejecución
El objetivo del cliente ligero de la capa de ejecución es combinar el encabezado del bloque de beacon validado por la capa de consenso con RPC de la capa de ejecución no confiable, proporcionando datos de la capa de ejecución verificados. Estos datos se pueden acceder a través de un servidor RPC alojado localmente por Helios.
Tomemos como ejemplo la obtención del saldo de la cuenta para introducir brevemente cómo Ethereum almacena el estado. Cada cuenta contiene varios campos, como el hash del código del contrato, un número aleatorio, el hash de almacenamiento y el saldo. Estas cuentas se almacenan en un gran árbol de Merkle-Patricia modificado, llamado árbol de estado. Siempre que se conozca la raíz del árbol de estado, se puede verificar la prueba de Merkle para demostrar si existe alguna cuenta en el árbol. Esta prueba no se puede falsificar.
Helios obtuvo la raíz de estado verificada de la capa de consenso. Al aplicar esta raíz de estado y la solicitud de prueba de Merkle a un RPC de capa de ejecución no confiable, Helios puede verificar localmente todos los datos almacenados en Ethereum.
Utilizamos diferentes tecnologías para verificar los diversos datos utilizados por la capa de ejecución. De esta manera, podemos validar todos los datos provenientes de RPC no confiables. Un RPC no confiable puede negarse a proporcionar acceso a los datos, pero no puede ofrecer resultados incorrectos.
Usar Helios en entornos complejos
La dificultad de equilibrar la conveniencia y la descentralización es un problema común. A través del cliente ligero Helios, los usuarios pueden acceder de manera segura a los datos en cadena desde cualquier dispositivo (incluidos teléfonos móviles y extensiones de navegador). Esto permitirá que más personas accedan a los datos de Ethereum sin necesidad de confianza, sin restricciones de hardware. Los usuarios pueden configurar Helios como proveedor RPC en ciertos monederos, logrando así un acceso sin confianza a diversas DApps, todo el proceso sin ningún otro cambio.
Además, el soporte de Rust para WebAssembly permite a los desarrolladores de aplicaciones integrar fácilmente Helios en aplicaciones JavaScript (como billeteras y DApp). Estas integraciones mejorarán la seguridad de Ethereum y reducirán nuestra dependencia de la infraestructura centralizada.
La reacción de la comunidad ante esto es emocionante. Hay múltiples formas de contribuir a Helios, además de aportar al repositorio de código, también se puede construir software que integre Helios para aprovechar sus ventajas. Aquí hay algunas ideas emocionantes: