a16z Crypto lanza el cliente ligero Helios: acceso a Ethereum realmente sin necesidad de confianza
El 8 de noviembre de 2023, a16z Crypto lanzó el cliente ligero de Ethereum Helios, una herramienta desarrollada en el lenguaje Rust que tiene como objetivo proporcionar acceso a la red Ethereum sin necesidad de confianza.
Uno de los valores fundamentales de la tecnología blockchain es permitir a los usuarios no depender de la confianza de terceros, lo que les permite tener verdadero control sobre su riqueza y datos. Blockchains como Ethereum han logrado en gran medida esta promesa, asegurando que nuestros activos realmente nos pertenezcan.
Sin embargo, para mayor conveniencia, la mayoría de los usuarios hacen algunos compromisos al usar la blockchain. Uno de los compromisos más evidentes es la dependencia de servidores de llamadas remotas RPC( centralizados. Los usuarios generalmente acceden a la red Ethereum a través de ciertos proveedores de servicios centralizados. Estas compañías ejecutan nodos de alto rendimiento en servidores en la nube, ayudando a los usuarios a obtener fácilmente datos en la cadena. Cuando una billetera consulta el saldo de un token o verifica el estado de una transacción, casi siempre se hace a través de estos servicios centralizados.
El principal problema del sistema actual es que los usuarios deben confiar en estos proveedores y no pueden verificar de forma independiente la exactitud de la información obtenida.
Helios: cliente ligero y completamente verificable
Como cliente ligero de Ethereum basado en Rust, Helios es capaz de proporcionar un acceso conveniente a la cadena de bloques sin sacrificar la seguridad. Aprovecha el protocolo de cliente ligero implementado después del cambio de Ethereum a PoS para convertir datos de proveedores de RPC centralizados no confiables en RPC nativos seguros y verificables. Al trabajar con RPC centralizado, Helios puede verificar la autenticidad de los datos sin ejecutar un nodo completo.
Este cliente ligero puede completar la sincronización en aproximadamente dos segundos, sin necesidad de espacio de almacenamiento adicional. Los usuarios pueden acceder de forma segura a los datos en la cadena a través de cualquier dispositivo ), incluidos teléfonos móviles y extensiones de navegador (.
Riesgos potenciales de la infraestructura centralizada
En el "bosque oscuro" de Ethereum acechan riesgos teóricos. Este riesgo no proviene de un ataque de ejecución en el frontend en el Mempool) de la transacción, sino de trampas establecidas a través de la simulación de la infraestructura centralizada de la que dependemos.
Los usuarios que enfrentan este tipo de ataques pueden no haber cometido ningún error: simplemente accedieron a un DEX común, establecieron un deslizamiento razonable y realizaron transacciones de tokens normales. Sin embargo, aún pueden enfrentarse a un ataque de sándwich especial que se oculta en la entrada de acceso a Ethereum: el proveedor RPC.
Cuando los usuarios realizan transacciones en DEX, se proporcionan varios parámetros al contrato inteligente: el token de transacción, la cantidad de transacción y la cantidad mínima de tokens que el usuario está dispuesto a aceptar (, es decir, el deslizamiento ). Si el deslizamiento se establece de manera razonable, teóricamente el usuario no sufrirá ataques de sándwich. Pero, ¿qué pasa si el proveedor de RPC no proporciona cotizaciones precisas del contrato DEX? Los usuarios pueden ser engañados al firmar transacciones con una cantidad mínima de recepción más baja. Peor aún, los usuarios pueden enviar directamente la transacción a un proveedor de RPC malicioso, quien puede retener estas transacciones en privado y enviarlas directamente a los productores de bloques a través de canales específicos para obtener ganancias.
La causa principal de este tipo de ataque es la necesidad de que los usuarios dependan de un tercero para el estado de la cadena de bloques. Para resolver este problema, los usuarios experimentados a menudo optan por ejecutar su propio nodo Ethereum, pero esto requiere una inversión significativa de tiempo y recursos: al menos un dispositivo que esté constantemente en línea, cientos de gigabytes de almacenamiento y aproximadamente un día para sincronizarse. Si bien este proceso es mucho más simple de lo que solía ser, sigue siendo difícil para la mayoría de los usuarios, especialmente para los usuarios móviles.
Es necesario señalar que, aunque los ataques de proveedores de RPC centralizados son teóricamente completamente posibles, hasta el momento no se ha encontrado que grandes y conocidos proveedores hayan llevado a cabo tales acciones. No obstante, antes de agregar un proveedor de RPC desconocido a la billetera, sigue siendo muy necesario realizar una investigación adecuada.
Funcionamiento de Helios: Análisis profundo
Después de que Ethereum lanzó el protocolo de cliente ligero, se crearon nuevas posibilidades para una interacción rápida con la blockchain y la verificación de puntos finales RPC con los requisitos de hardware mínimos. Un mes después de la fusión (The Merge), varios proyectos de clientes ligeros independientes (Lodestar, Nimbus y Kevlar basado en JavaScript ) aparecieron uno tras otro, cada uno adoptando diferentes enfoques, pero todos dedicados al mismo objetivo: proporcionar acceso eficiente y sin confianza sin ejecutar nodos completos.
Helios, al igual que todos los clientes de Ethereum, se compone de una capa de ejecución y una capa de consenso. Pero a diferencia de la mayoría de los clientes, Helios combina estas dos capas de manera estrecha, permitiendo a los usuarios instalar y ejecutar un único software.
( capa de consenso
El cliente ligero de la capa de consenso de Helios sigue la norma del cliente ligero de la cadena de balizas, utilizando el comité de sincronización de la cadena de balizas ) introducido en la bifurcación dura Altair. El comité de sincronización está compuesto por un grupo de 512 validadores seleccionados aleatoriamente, con un período de servicio de aproximadamente 27 horas.
Los validadores firman todos los encabezados de bloques de la cadena de baliza que ven en el comité de sincronización. Si más de dos tercios de los miembros del comité firman el encabezado del bloque, entonces el bloque casi seguramente se ubicará en la cadena de baliza normativa. Una vez que Helios conoce la composición actual del comité de sincronización, puede rastrear de manera confiable la cabeza de la cadena consultando las firmas recientes del comité de sincronización.
Gracias a la tecnología de agregación de firmas BLS, se puede completar la verificación del nuevo encabezado de bloque con solo una consulta. Siempre que la firma sea válida y más de dos tercios de los miembros del comité hayan firmado, se garantiza que el bloque ha sido incluido en la cadena.
El sistema primero necesita obtener un weak subjectivity checkpoint ### como raíz de confianza. Este es un hash de bloque que se garantiza que se incluyó en la cadena en algún momento en el pasado. Utilizando este checkpoint, Helios puede obtener y verificar el comité de sincronización actual y el siguiente, lo que permite revisar rápidamente la historia de la blockchain y sincronizarse hasta el bloque más reciente.
( capa de ejecución
El objetivo del cliente ligero de la capa de ejecución es combinar el encabezado del bloque de referencia 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. Luego, se accede a estos datos a través de un servidor RPC alojado localmente por Helios.
Ethereum almacena la información de las cuentas a través de un árbol de estado, que incluye el hash del código del contrato, un número aleatorio, el hash de almacenamiento y el saldo. Siempre que se conozca la raíz del árbol de estado, se puede verificar la prueba de Merkle, que demuestra si existe alguna cuenta en el árbol, y esta prueba no puede ser falsificada.
Helios obtiene la raíz de estado verificada de la capa de consenso y la combina con la solicitud de prueba Merkle de la capa de ejecución no confiable RPC, logrando la verificación local de todos los datos almacenados en Ethereum. De esta manera, el RPC no confiable puede negarse a proporcionar acceso a los datos, pero no puede proporcionar resultados incorrectos.
Aplicaciones prácticas de Helios
El diseño ligero de Helios permite a los usuarios acceder de manera segura a los datos en la cadena desde cualquier dispositivo ), incluidos teléfonos móviles y complementos de navegador (. Los usuarios pueden configurar Helios como proveedor RPC en MetaMask, accediendo a varias DApps sin necesidad de ningún otro cambio.
Además, el buen 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 la dependencia de la infraestructura centralizada.
La comunidad puede contribuir a Helios de varias maneras, incluyendo:
Soporta obtener datos del cliente ligero directamente de la red P2P
Implementar los métodos RPC que faltan
Construir una versión de Helios que se pueda compilar a WebAssembly
Integrar Helios directamente en el software de billetera
Construir un panel de red para ver el saldo de tokens
Conectar la capa de consenso Helios a un nodo completo de la capa de ejecución existente
El código de este proyecto ya está abierto, y se invita a los desarrolladores interesados a contribuir.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
14 me gusta
Recompensa
14
10
Compartir
Comentar
0/400
CryptoCross-TalkClub
· hace13h
La cadena no confía en las personas, confía en el servidor.
a16z lanza el cliente ligero Helios: nueva solución de acceso a Ethereum sin necesidad de confianza
a16z Crypto lanza el cliente ligero Helios: acceso a Ethereum realmente sin necesidad de confianza
El 8 de noviembre de 2023, a16z Crypto lanzó el cliente ligero de Ethereum Helios, una herramienta desarrollada en el lenguaje Rust que tiene como objetivo proporcionar acceso a la red Ethereum sin necesidad de confianza.
Uno de los valores fundamentales de la tecnología blockchain es permitir a los usuarios no depender de la confianza de terceros, lo que les permite tener verdadero control sobre su riqueza y datos. Blockchains como Ethereum han logrado en gran medida esta promesa, asegurando que nuestros activos realmente nos pertenezcan.
Sin embargo, para mayor conveniencia, la mayoría de los usuarios hacen algunos compromisos al usar la blockchain. Uno de los compromisos más evidentes es la dependencia de servidores de llamadas remotas RPC( centralizados. Los usuarios generalmente acceden a la red Ethereum a través de ciertos proveedores de servicios centralizados. Estas compañías ejecutan nodos de alto rendimiento en servidores en la nube, ayudando a los usuarios a obtener fácilmente datos en la cadena. Cuando una billetera consulta el saldo de un token o verifica el estado de una transacción, casi siempre se hace a través de estos servicios centralizados.
El principal problema del sistema actual es que los usuarios deben confiar en estos proveedores y no pueden verificar de forma independiente la exactitud de la información obtenida.
Helios: cliente ligero y completamente verificable
Como cliente ligero de Ethereum basado en Rust, Helios es capaz de proporcionar un acceso conveniente a la cadena de bloques sin sacrificar la seguridad. Aprovecha el protocolo de cliente ligero implementado después del cambio de Ethereum a PoS para convertir datos de proveedores de RPC centralizados no confiables en RPC nativos seguros y verificables. Al trabajar con RPC centralizado, Helios puede verificar la autenticidad de los datos sin ejecutar un nodo completo.
Este cliente ligero puede completar la sincronización en aproximadamente dos segundos, sin necesidad de espacio de almacenamiento adicional. Los usuarios pueden acceder de forma segura a los datos en la cadena a través de cualquier dispositivo ), incluidos teléfonos móviles y extensiones de navegador (.
Riesgos potenciales de la infraestructura centralizada
En el "bosque oscuro" de Ethereum acechan riesgos teóricos. Este riesgo no proviene de un ataque de ejecución en el frontend en el Mempool) de la transacción, sino de trampas establecidas a través de la simulación de la infraestructura centralizada de la que dependemos.
Los usuarios que enfrentan este tipo de ataques pueden no haber cometido ningún error: simplemente accedieron a un DEX común, establecieron un deslizamiento razonable y realizaron transacciones de tokens normales. Sin embargo, aún pueden enfrentarse a un ataque de sándwich especial que se oculta en la entrada de acceso a Ethereum: el proveedor RPC.
Cuando los usuarios realizan transacciones en DEX, se proporcionan varios parámetros al contrato inteligente: el token de transacción, la cantidad de transacción y la cantidad mínima de tokens que el usuario está dispuesto a aceptar (, es decir, el deslizamiento ). Si el deslizamiento se establece de manera razonable, teóricamente el usuario no sufrirá ataques de sándwich. Pero, ¿qué pasa si el proveedor de RPC no proporciona cotizaciones precisas del contrato DEX? Los usuarios pueden ser engañados al firmar transacciones con una cantidad mínima de recepción más baja. Peor aún, los usuarios pueden enviar directamente la transacción a un proveedor de RPC malicioso, quien puede retener estas transacciones en privado y enviarlas directamente a los productores de bloques a través de canales específicos para obtener ganancias.
La causa principal de este tipo de ataque es la necesidad de que los usuarios dependan de un tercero para el estado de la cadena de bloques. Para resolver este problema, los usuarios experimentados a menudo optan por ejecutar su propio nodo Ethereum, pero esto requiere una inversión significativa de tiempo y recursos: al menos un dispositivo que esté constantemente en línea, cientos de gigabytes de almacenamiento y aproximadamente un día para sincronizarse. Si bien este proceso es mucho más simple de lo que solía ser, sigue siendo difícil para la mayoría de los usuarios, especialmente para los usuarios móviles.
Es necesario señalar que, aunque los ataques de proveedores de RPC centralizados son teóricamente completamente posibles, hasta el momento no se ha encontrado que grandes y conocidos proveedores hayan llevado a cabo tales acciones. No obstante, antes de agregar un proveedor de RPC desconocido a la billetera, sigue siendo muy necesario realizar una investigación adecuada.
Funcionamiento de Helios: Análisis profundo
Después de que Ethereum lanzó el protocolo de cliente ligero, se crearon nuevas posibilidades para una interacción rápida con la blockchain y la verificación de puntos finales RPC con los requisitos de hardware mínimos. Un mes después de la fusión (The Merge), varios proyectos de clientes ligeros independientes (Lodestar, Nimbus y Kevlar basado en JavaScript ) aparecieron uno tras otro, cada uno adoptando diferentes enfoques, pero todos dedicados al mismo objetivo: proporcionar acceso eficiente y sin confianza sin ejecutar nodos completos.
Helios, al igual que todos los clientes de Ethereum, se compone de una capa de ejecución y una capa de consenso. Pero a diferencia de la mayoría de los clientes, Helios combina estas dos capas de manera estrecha, permitiendo a los usuarios instalar y ejecutar un único software.
( capa de consenso
El cliente ligero de la capa de consenso de Helios sigue la norma del cliente ligero de la cadena de balizas, utilizando el comité de sincronización de la cadena de balizas ) introducido en la bifurcación dura Altair. El comité de sincronización está compuesto por un grupo de 512 validadores seleccionados aleatoriamente, con un período de servicio de aproximadamente 27 horas.
Los validadores firman todos los encabezados de bloques de la cadena de baliza que ven en el comité de sincronización. Si más de dos tercios de los miembros del comité firman el encabezado del bloque, entonces el bloque casi seguramente se ubicará en la cadena de baliza normativa. Una vez que Helios conoce la composición actual del comité de sincronización, puede rastrear de manera confiable la cabeza de la cadena consultando las firmas recientes del comité de sincronización.
Gracias a la tecnología de agregación de firmas BLS, se puede completar la verificación del nuevo encabezado de bloque con solo una consulta. Siempre que la firma sea válida y más de dos tercios de los miembros del comité hayan firmado, se garantiza que el bloque ha sido incluido en la cadena.
El sistema primero necesita obtener un weak subjectivity checkpoint ### como raíz de confianza. Este es un hash de bloque que se garantiza que se incluyó en la cadena en algún momento en el pasado. Utilizando este checkpoint, Helios puede obtener y verificar el comité de sincronización actual y el siguiente, lo que permite revisar rápidamente la historia de la blockchain y sincronizarse hasta el bloque más reciente.
( capa de ejecución
El objetivo del cliente ligero de la capa de ejecución es combinar el encabezado del bloque de referencia 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. Luego, se accede a estos datos a través de un servidor RPC alojado localmente por Helios.
Ethereum almacena la información de las cuentas a través de un árbol de estado, que incluye el hash del código del contrato, un número aleatorio, el hash de almacenamiento y el saldo. Siempre que se conozca la raíz del árbol de estado, se puede verificar la prueba de Merkle, que demuestra si existe alguna cuenta en el árbol, y esta prueba no puede ser falsificada.
Helios obtiene la raíz de estado verificada de la capa de consenso y la combina con la solicitud de prueba Merkle de la capa de ejecución no confiable RPC, logrando la verificación local de todos los datos almacenados en Ethereum. De esta manera, el RPC no confiable puede negarse a proporcionar acceso a los datos, pero no puede proporcionar resultados incorrectos.
Aplicaciones prácticas de Helios
El diseño ligero de Helios permite a los usuarios acceder de manera segura a los datos en la cadena desde cualquier dispositivo ), incluidos teléfonos móviles y complementos de navegador (. Los usuarios pueden configurar Helios como proveedor RPC en MetaMask, accediendo a varias DApps sin necesidad de ningún otro cambio.
Además, el buen 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 la dependencia de la infraestructura centralizada.
La comunidad puede contribuir a Helios de varias maneras, incluyendo:
El código de este proyecto ya está abierto, y se invita a los desarrolladores interesados a contribuir.