Cliente ligero de Ethereum Helios: acceso a la cadena de bloques sin necesidad de confianza
El 8 de noviembre, un nuevo cliente ligero de Ethereum llamado Helios fue lanzado oficialmente. Este cliente está desarrollado en el lenguaje Rust y tiene como objetivo proporcionar acceso a Ethereum completamente sin necesidad de confianza.
Uno de los principales objetivos de utilizar la cadena de bloques es lograr la desconfianza. A través de la cadena de bloques, podemos tener control sobre nuestra riqueza y datos. En la mayoría de los casos, cadenas de bloques como Ethereum realmente cumplen con esta promesa: nuestros activos realmente nos pertenecen.
Sin embargo, para buscar conveniencia, también hemos hecho algunos compromisos. Uno de ellos es el uso de la llamada remota RPC( centralizada. Los usuarios generalmente acceden a Ethereum a través de proveedores centralizados. Estas empresas ejecutan nodos de alto rendimiento en servidores en la nube, ayudando a todos a obtener fácilmente datos en la cadena. Cuando una billetera consulta el saldo de tokens o verifica el estado de una transacción, casi siempre se utilizan estos proveedores centralizados.
El problema actual del sistema es que los usuarios necesitan confiar en estos proveedores y no pueden verificar si los resultados de las consultas son correctos.
Helios es un cliente ligero de Ethereum basado en Rust, capaz de proporcionar acceso a Ethereum completamente sin confianza. Utiliza el protocolo de cliente ligero implementado tras la transición de Ethereum a PoS, y puede convertir datos de proveedores RPC centralizados no confiables en RPC locales seguros y verificables. Combinado con RPC centralizados, Helios puede verificar la autenticidad de los datos sin necesidad de ejecutar un nodo completo.
Este cliente puede completar la sincronización en aproximadamente dos segundos y no requiere almacenamiento. Los usuarios pueden acceder de manera segura a los datos en la cadena a través de cualquier dispositivo ), incluidos teléfonos móviles y extensiones de navegador (. Pero, ¿cuáles son los riesgos potenciales de depender de una infraestructura centralizada? A continuación, se analizarán estos riesgos, se presentará el diseño de Helios y se ofrecerán algunas ideas para ayudar a mejorar la biblioteca de código.
Riesgos potenciales de la infraestructura centralizada
Un tipo de ataque teórico acecha en el "bosque oscuro" de Ethereum. No se trata de buscar objetivos en el pool de memoria de transacciones, sino de establecer trampas imitando la infraestructura centralizada de la que dependemos. Los usuarios, incluso sin cometer errores, pueden caer en la trampa: simplemente están comerciando en un DEX como de costumbre, estableciendo un deslizamiento razonable... pero aún pueden ser víctimas de un nuevo tipo de ataque de sándwich, que es una trampa cuidadosamente configurada en el proveedor de RPC.
Al operar en un intercambio descentralizado, los usuarios deben proporcionar varios parámetros al contrato inteligente: los tokens a intercambiar, la cantidad a intercambiar y, lo más importante, la cantidad mínima de tokens que el usuario está dispuesto a aceptar. El último parámetro indica el "mínimo requerido" que debe alcanzarse para el intercambio; de lo contrario, la transacción será cancelada. Esto se conoce comúnmente como "slippage", que establece efectivamente la diferencia de precio máxima que podría ocurrir entre el envío de la transacción y el registro de la transacción en la cadena. Si el slippage se establece demasiado bajo, el usuario puede recibir menos tokens y también puede ser víctima de un ataque de sándwich.
Siempre que el parámetro de producción mínima esté configurado dentro de un rango razonable, no se verá afectado por ataques de sándwich. Pero, ¿qué pasa si el proveedor de RPC no proporciona una cotización precisa del contrato inteligente DEX? Esto puede llevar a que los usuarios sean engañados para firmar transacciones de intercambio con parámetros de producción mínima más bajos. Peor aún, los usuarios también pueden enviar transacciones directamente a un proveedor de RPC malicioso. El proveedor puede no difundir la transacción al pool de memoria público, sino que retenerla en privado y enviar el paquete de transacciones atacadas directamente a instituciones específicas para obtener ganancias.
La causa fundamental de este ataque es confiar en otros para obtener el estado de la Cadena de bloques. Para resolver este problema, los usuarios experimentados suelen ejecutar su propio nodo de Ethereum, pero esto requiere una gran cantidad de tiempo y recursos, al menos un dispositivo que esté en línea continuamente, cientos de GB de espacio de almacenamiento, y aproximadamente un día para sincronizar desde cero. Aunque ahora el umbral para ejecutar un nodo se ha reducido, sigue siendo muy difícil para la mayoría de los usuarios, especialmente para aquellos que utilizan dispositivos móviles.
Es importante tener en cuenta que, aunque los ataques de proveedores RPC centralizados son totalmente posibles, generalmente son solo ataques de phishing simples; el tipo de ataque que describimos aún no ha ocurrido. A pesar de que el historial de proveedores de renombre es confiable, siempre es una buena idea investigar un poco más antes de usar proveedores RPC desconocidos.
Helios: implementación de acceso a Ethereum sin necesidad de confianza
Ethereum lanzó el protocolo de cliente ligero, abriendo nuevas posibilidades para interacciones rápidas en la cadena de bloques y la verificación de puntos finales RPC con los mínimos requisitos de hardware. Un mes después de The Merge, varios clientes ligeros independientes se lanzaron sucesivamente, utilizando diferentes enfoques, pero con un objetivo común: lograr un acceso eficiente sin necesidad de confianza sin ejecutar nodos completos.
Helios es un cliente ligero de Ethereum que puede completar la sincronización en aproximadamente dos segundos, sin necesidad de almacenamiento, y proporciona acceso a Ethereum completamente sin confianza. Al igual que todos los clientes de Ethereum, Helios incluye la capa de ejecución y la capa de consenso. Pero a diferencia de la mayoría de los clientes, Helios acopla estrechamente las dos capas, lo que permite a los usuarios instalar y ejecutar un solo software.
El funcionamiento de Helios es el siguiente: la capa de consenso utiliza un hash de bloque de cadena de señales conocido y se conecta a un RPC no confiable para sincronizar de manera verificable con el bloque actual. La capa de ejecución combina estos bloques de cadena de señales verificados con un RPC de capa de ejecución no confiable para verificar varios tipos de información sobre el estado en cadena, como el saldo de cuentas, el almacenamiento de contratos, los recibos de transacciones y los resultados de llamadas a contratos inteligentes. Estos componentes trabajan en conjunto para proporcionar a los usuarios un RPC completamente sin necesidad de confianza y sin tener que 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ñales, utilizando el comité de sincronización de la cadena de señales. El comité de sincronización es un subconjunto de 512 validadores seleccionados al azar, con un ciclo de servicio de aproximadamente 27 horas.
Los validadores firmarán todos los encabezados de bloques de cadena de bloques de balizas que vean después de entrar en el comité de sincronización. Si más de 2/3 de los miembros del comité firman un encabezado de bloque, es muy probable que el bloque esté ubicado en la cadena de balizas conforme. Si Helios entiende 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 agregación de firmas BLS, se puede completar la verificación de un nuevo encabezado de bloque con una sola consulta. Siempre que la firma sea válida y más de 2/3 de los miembros del comité hayan firmado, se garantiza que el bloque se ha incluido en la cadena. Por supuesto, rastrear la finalización del bloque puede proporcionar una garantía más sólida.
Este estrategia también necesita resolver el problema de cómo encontrar el comité de sincronización actual. Primero, hay que obtener una raíz de confianza llamada punto de verificación de debilidad subjetiva. Esto representa un hash de bloque antiguo que se puede garantizar que fue incluido en la cadena en algún momento en el pasado. En cuanto al tiempo de existencia del punto de verificación, el análisis teórico muestra que el peor caso es de aproximadamente dos semanas, mientras que la estimación real puede llegar a ser de varios meses.
Si el punto de verificación es demasiado antiguo, teóricamente existe la posibilidad de un ataque que puede engañar a los nodos para que sigan una cadena incorrecta. En este caso, obtener un punto de verificación de subjetividad débil excede las capacidades del protocolo. La solución de Helios es proporcionar un punto de verificación inicial, que se codifica de forma rígida en el repositorio de código ### y puede ser fácilmente sobrescrito (, que guardará localmente el último hash de bloque final para ser utilizado como punto de verificación durante la sincronización de nodos.
A través de operaciones de hash, los bloques de la cadena de señal pueden generar fácilmente un hash de bloque de señal único. De esta manera, se puede consultar fácilmente el bloque de señal completo y luego demostrar la validez del contenido del bloque mediante comparación de hashes. Helios utiliza esta propiedad para obtener y verificar los campos clave dentro de los bloques de puntos de control de subjetividad débil, incluyendo 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 revisar rápidamente la historia de la cadena de bloques.
Con el punto de control de debilidad subjetiva, podemos obtener y verificar el comité de sincronización actual y el siguiente. Si la cabeza de cadena actual y el punto de control están dentro del mismo ciclo de comité de sincronización, podemos usar inmediatamente el encabezado del comité de sincronización firmado para verificar el nuevo bloque. Si el punto de control está despué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.
Utilizar este nuevo bloque para obtener el próximo comité de sincronización.
Si el punto de control aún está detrás, regresa al paso 1.
A través del proceso mencionado, podemos revisar rápidamente la historia de la cadena de bloques en unidades de 27 horas, comenzando desde el hash de cualquier bloque pasado hasta sincronizarnos con el hash del bloque actual.
) Capa de ejecución
El objetivo del cliente ligero de la capa de ejecución es combinar el encabezado del bloque de señal que ha sido verificado por la capa de consenso con RPC de la capa de ejecución no confiables, proporcionando datos de la capa de ejecución verificados. Luego, estos datos se pueden acceder a través de un servidor RPC alojado localmente por Helios.
A continuación se presenta un ejemplo simple de cómo obtener el saldo de una cuenta, primero se introduce 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 Merkle-Patricia ajustado, llamado árbol de estado. Siempre que se conozca la raíz del árbol de estado, se puede verificar la prueba Merkle para demostrar si existe alguna cuenta en el árbol. Esta prueba no puede ser falsificada.
Helios obtiene la raíz de estado verificada de la capa de consenso. Al aplicar esta raíz de estado y la prueba de Merkle a través de RPC de la 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, lo que nos permite validar todos los datos que provienen de RPC no confiables. RPC no confiables pueden negarse a proporcionar acceso a los datos, pero no pueden ofrecer resultados erróneos.
Perspectivas de aplicación de Helios
Es un problema común difícil de abordar la conveniencia y la descentralización. A través del cliente ligero Helios, los usuarios pueden acceder a datos en la cadena de bloques de manera segura desde cualquier dispositivo ###, incluidos teléfonos móviles y complementos de navegador (. Esto permitirá que más personas accedan a datos de Ethereum sin necesidad de confianza, sin importar qué hardware utilicen. Los usuarios pueden usar Helios como proveedor RPC en su billetera para acceder a varias DApps sin necesidad de confianza, y todo el proceso no requiere 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 necesidad de confianza en la infraestructura centralizada.
La comunidad puede contribuir a Helios de varias maneras, además de mejorar el repositorio de código, también puede construir software que integre Helios para aprovechar sus ventajas. A continuación se presentan algunas direcciones de desarrollo potenciales:
Soporta obtener datos de cliente ligero directamente de la red P2P, en lugar de depender de RPC
Implementar los métodos RPC que faltan
Desarrollar 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, incrustar Helios en un sitio web que utiliza WebAssembly para obtener datos.
Desplegar API de motor, conectar la capa de consenso Helios a los nodos completos de la capa de ejecución existente.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
13 me gusta
Recompensa
13
2
Republicar
Compartir
Comentar
0/400
FUDwatcher
· 08-06 03:54
Rust es realmente poderoso
Ver originalesResponder0
shadowy_supercoder
· 08-06 03:47
El rendimiento de Rust es realmente impresionante.
Helios cliente ligero: implementación de acceso a datos en Ethereum sin necesidad de confianza
Cliente ligero de Ethereum Helios: acceso a la cadena de bloques sin necesidad de confianza
El 8 de noviembre, un nuevo cliente ligero de Ethereum llamado Helios fue lanzado oficialmente. Este cliente está desarrollado en el lenguaje Rust y tiene como objetivo proporcionar acceso a Ethereum completamente sin necesidad de confianza.
Uno de los principales objetivos de utilizar la cadena de bloques es lograr la desconfianza. A través de la cadena de bloques, podemos tener control sobre nuestra riqueza y datos. En la mayoría de los casos, cadenas de bloques como Ethereum realmente cumplen con esta promesa: nuestros activos realmente nos pertenecen.
Sin embargo, para buscar conveniencia, también hemos hecho algunos compromisos. Uno de ellos es el uso de la llamada remota RPC( centralizada. Los usuarios generalmente acceden a Ethereum a través de proveedores centralizados. Estas empresas ejecutan nodos de alto rendimiento en servidores en la nube, ayudando a todos a obtener fácilmente datos en la cadena. Cuando una billetera consulta el saldo de tokens o verifica el estado de una transacción, casi siempre se utilizan estos proveedores centralizados.
El problema actual del sistema es que los usuarios necesitan confiar en estos proveedores y no pueden verificar si los resultados de las consultas son correctos.
Helios es un cliente ligero de Ethereum basado en Rust, capaz de proporcionar acceso a Ethereum completamente sin confianza. Utiliza el protocolo de cliente ligero implementado tras la transición de Ethereum a PoS, y puede convertir datos de proveedores RPC centralizados no confiables en RPC locales seguros y verificables. Combinado con RPC centralizados, Helios puede verificar la autenticidad de los datos sin necesidad de ejecutar un nodo completo.
Este cliente puede completar la sincronización en aproximadamente dos segundos y no requiere almacenamiento. Los usuarios pueden acceder de manera segura a los datos en la cadena a través de cualquier dispositivo ), incluidos teléfonos móviles y extensiones de navegador (. Pero, ¿cuáles son los riesgos potenciales de depender de una infraestructura centralizada? A continuación, se analizarán estos riesgos, se presentará el diseño de Helios y se ofrecerán algunas ideas para ayudar a mejorar la biblioteca de código.
Riesgos potenciales de la infraestructura centralizada
Un tipo de ataque teórico acecha en el "bosque oscuro" de Ethereum. No se trata de buscar objetivos en el pool de memoria de transacciones, sino de establecer trampas imitando la infraestructura centralizada de la que dependemos. Los usuarios, incluso sin cometer errores, pueden caer en la trampa: simplemente están comerciando en un DEX como de costumbre, estableciendo un deslizamiento razonable... pero aún pueden ser víctimas de un nuevo tipo de ataque de sándwich, que es una trampa cuidadosamente configurada en el proveedor de RPC.
Al operar en un intercambio descentralizado, los usuarios deben proporcionar varios parámetros al contrato inteligente: los tokens a intercambiar, la cantidad a intercambiar y, lo más importante, la cantidad mínima de tokens que el usuario está dispuesto a aceptar. El último parámetro indica el "mínimo requerido" que debe alcanzarse para el intercambio; de lo contrario, la transacción será cancelada. Esto se conoce comúnmente como "slippage", que establece efectivamente la diferencia de precio máxima que podría ocurrir entre el envío de la transacción y el registro de la transacción en la cadena. Si el slippage se establece demasiado bajo, el usuario puede recibir menos tokens y también puede ser víctima de un ataque de sándwich.
Siempre que el parámetro de producción mínima esté configurado dentro de un rango razonable, no se verá afectado por ataques de sándwich. Pero, ¿qué pasa si el proveedor de RPC no proporciona una cotización precisa del contrato inteligente DEX? Esto puede llevar a que los usuarios sean engañados para firmar transacciones de intercambio con parámetros de producción mínima más bajos. Peor aún, los usuarios también pueden enviar transacciones directamente a un proveedor de RPC malicioso. El proveedor puede no difundir la transacción al pool de memoria público, sino que retenerla en privado y enviar el paquete de transacciones atacadas directamente a instituciones específicas para obtener ganancias.
La causa fundamental de este ataque es confiar en otros para obtener el estado de la Cadena de bloques. Para resolver este problema, los usuarios experimentados suelen ejecutar su propio nodo de Ethereum, pero esto requiere una gran cantidad de tiempo y recursos, al menos un dispositivo que esté en línea continuamente, cientos de GB de espacio de almacenamiento, y aproximadamente un día para sincronizar desde cero. Aunque ahora el umbral para ejecutar un nodo se ha reducido, sigue siendo muy difícil para la mayoría de los usuarios, especialmente para aquellos que utilizan dispositivos móviles.
Es importante tener en cuenta que, aunque los ataques de proveedores RPC centralizados son totalmente posibles, generalmente son solo ataques de phishing simples; el tipo de ataque que describimos aún no ha ocurrido. A pesar de que el historial de proveedores de renombre es confiable, siempre es una buena idea investigar un poco más antes de usar proveedores RPC desconocidos.
Helios: implementación de acceso a Ethereum sin necesidad de confianza
Ethereum lanzó el protocolo de cliente ligero, abriendo nuevas posibilidades para interacciones rápidas en la cadena de bloques y la verificación de puntos finales RPC con los mínimos requisitos de hardware. Un mes después de The Merge, varios clientes ligeros independientes se lanzaron sucesivamente, utilizando diferentes enfoques, pero con un objetivo común: lograr un acceso eficiente sin necesidad de confianza sin ejecutar nodos completos.
Helios es un cliente ligero de Ethereum que puede completar la sincronización en aproximadamente dos segundos, sin necesidad de almacenamiento, y proporciona acceso a Ethereum completamente sin confianza. Al igual que todos los clientes de Ethereum, Helios incluye la capa de ejecución y la capa de consenso. Pero a diferencia de la mayoría de los clientes, Helios acopla estrechamente las dos capas, lo que permite a los usuarios instalar y ejecutar un solo software.
El funcionamiento de Helios es el siguiente: la capa de consenso utiliza un hash de bloque de cadena de señales conocido y se conecta a un RPC no confiable para sincronizar de manera verificable con el bloque actual. La capa de ejecución combina estos bloques de cadena de señales verificados con un RPC de capa de ejecución no confiable para verificar varios tipos de información sobre el estado en cadena, como el saldo de cuentas, el almacenamiento de contratos, los recibos de transacciones y los resultados de llamadas a contratos inteligentes. Estos componentes trabajan en conjunto para proporcionar a los usuarios un RPC completamente sin necesidad de confianza y sin tener que 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ñales, utilizando el comité de sincronización de la cadena de señales. El comité de sincronización es un subconjunto de 512 validadores seleccionados al azar, con un ciclo de servicio de aproximadamente 27 horas.
Los validadores firmarán todos los encabezados de bloques de cadena de bloques de balizas que vean después de entrar en el comité de sincronización. Si más de 2/3 de los miembros del comité firman un encabezado de bloque, es muy probable que el bloque esté ubicado en la cadena de balizas conforme. Si Helios entiende 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 agregación de firmas BLS, se puede completar la verificación de un nuevo encabezado de bloque con una sola consulta. Siempre que la firma sea válida y más de 2/3 de los miembros del comité hayan firmado, se garantiza que el bloque se ha incluido en la cadena. Por supuesto, rastrear la finalización del bloque puede proporcionar una garantía más sólida.
Este estrategia también necesita resolver el problema de cómo encontrar el comité de sincronización actual. Primero, hay que obtener una raíz de confianza llamada punto de verificación de debilidad subjetiva. Esto representa un hash de bloque antiguo que se puede garantizar que fue incluido en la cadena en algún momento en el pasado. En cuanto al tiempo de existencia del punto de verificación, el análisis teórico muestra que el peor caso es de aproximadamente dos semanas, mientras que la estimación real puede llegar a ser de varios meses.
Si el punto de verificación es demasiado antiguo, teóricamente existe la posibilidad de un ataque que puede engañar a los nodos para que sigan una cadena incorrecta. En este caso, obtener un punto de verificación de subjetividad débil excede las capacidades del protocolo. La solución de Helios es proporcionar un punto de verificación inicial, que se codifica de forma rígida en el repositorio de código ### y puede ser fácilmente sobrescrito (, que guardará localmente el último hash de bloque final para ser utilizado como punto de verificación durante la sincronización de nodos.
A través de operaciones de hash, los bloques de la cadena de señal pueden generar fácilmente un hash de bloque de señal único. De esta manera, se puede consultar fácilmente el bloque de señal completo y luego demostrar la validez del contenido del bloque mediante comparación de hashes. Helios utiliza esta propiedad para obtener y verificar los campos clave dentro de los bloques de puntos de control de subjetividad débil, incluyendo 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 revisar rápidamente la historia de la cadena de bloques.
Con el punto de control de debilidad subjetiva, podemos obtener y verificar el comité de sincronización actual y el siguiente. Si la cabeza de cadena actual y el punto de control están dentro del mismo ciclo de comité de sincronización, podemos usar inmediatamente el encabezado del comité de sincronización firmado para verificar el nuevo bloque. Si el punto de control está despué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.
Utilizar este nuevo bloque para obtener el próximo comité de sincronización.
Si el punto de control aún está detrás, regresa al paso 1.
A través del proceso mencionado, podemos revisar rápidamente la historia de la cadena de bloques en unidades de 27 horas, comenzando desde el hash de cualquier bloque pasado hasta sincronizarnos con el hash del bloque actual.
) Capa de ejecución
El objetivo del cliente ligero de la capa de ejecución es combinar el encabezado del bloque de señal que ha sido verificado por la capa de consenso con RPC de la capa de ejecución no confiables, proporcionando datos de la capa de ejecución verificados. Luego, estos datos se pueden acceder a través de un servidor RPC alojado localmente por Helios.
A continuación se presenta un ejemplo simple de cómo obtener el saldo de una cuenta, primero se introduce 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 Merkle-Patricia ajustado, llamado árbol de estado. Siempre que se conozca la raíz del árbol de estado, se puede verificar la prueba Merkle para demostrar si existe alguna cuenta en el árbol. Esta prueba no puede ser falsificada.
Helios obtiene la raíz de estado verificada de la capa de consenso. Al aplicar esta raíz de estado y la prueba de Merkle a través de RPC de la 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, lo que nos permite validar todos los datos que provienen de RPC no confiables. RPC no confiables pueden negarse a proporcionar acceso a los datos, pero no pueden ofrecer resultados erróneos.
Perspectivas de aplicación de Helios
Es un problema común difícil de abordar la conveniencia y la descentralización. A través del cliente ligero Helios, los usuarios pueden acceder a datos en la cadena de bloques de manera segura desde cualquier dispositivo ###, incluidos teléfonos móviles y complementos de navegador (. Esto permitirá que más personas accedan a datos de Ethereum sin necesidad de confianza, sin importar qué hardware utilicen. Los usuarios pueden usar Helios como proveedor RPC en su billetera para acceder a varias DApps sin necesidad de confianza, y todo el proceso no requiere 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 necesidad de confianza en la infraestructura centralizada.
La comunidad puede contribuir a Helios de varias maneras, además de mejorar el repositorio de código, también puede construir software que integre Helios para aprovechar sus ventajas. A continuación se presentan algunas direcciones de desarrollo potenciales: