Construyendo Helios: acceso totalmente confiable a Ethereum

Una de las principales razones por las que usamos blockchains es la falta de confianza. Esta propiedad promete permitirnos un acceso soberano a nuestra riqueza y datos. En su mayor parte, las cadenas de bloques como Ethereum han cumplido esta promesa: nuestros activos son realmente nuestros. 

Sin embargo, hay concesiones que hemos hecho por conveniencia. Una de esas áreas es nuestro uso de servidores RPC (llamada a procedimiento remoto) centralizados. Los usuarios suelen acceder a Ethereum a través de proveedores centralizados como Alchemy. Estas empresas ejecutan nodos de alto rendimiento en servidores en la nube para que otros puedan acceder fácilmente a los datos de la cadena. Cuando una billetera consulta sus saldos de tokens o verifica si una transacción pendiente se ha incluido en un bloque, casi siempre lo hace a través de uno de estos proveedores centralizados. 

El problema con el sistema existente es que los usuarios deben confiar en los proveedores y no hay forma de verificar la corrección de sus consultas.

Participar Helios, un cliente ligero de Ethereum basado en Rust que desarrollamos y que brinda acceso totalmente confiable a Ethereum. Helios, que utiliza el protocolo de cliente ligero de Ethereum, posible gracias a la cambio reciente a prueba de participación — convierte los datos de un proveedor de RPC centralizado que no es de confianza en un RPC local verificable y seguro. Helios trabaja junto con RPC centralizados para que sea posible verificar su autenticidad sin ejecutar un nodo completo. 

La compensación entre portabilidad y descentralización es un problema común, pero nuestro cliente, que hemos puesto a disposición del público para desarrollar y más, se sincroniza en aproximadamente dos segundos, no requiere almacenamiento y permite a los usuarios acceder a datos de cadena seguros desde cualquier dispositivo (incluidos teléfonos móviles y extensiones de navegador). pero que son los peligros potenciales de confiar en una infraestructura centralizada? Cubrimos cómo podrían desarrollarse en esta publicación, repasamos nuestras decisiones de diseño y también describimos algunas ideas para que otros contribuyan a la base de código.

Las trampas de la infraestructura centralizada: criaturas teóricas en el "bosque oscuro" de Ethereum

Una criatura (teórica) acecha en el bosque oscuro. Este no busca a su presa en el mempool de Ethereum, sino que coloca sus trampas imitando la infraestructura centralizada en la que confiamos. Los usuarios que quedan atrapados en esta trampa no cometen ningún error: visitan su intercambio descentralizado favorito, establecen una tolerancia de deslizamiento razonable y compran y venden tokens como de costumbre... Hacen todo bien, pero aún así son víctimas de un nuevo tipo de ataque sándwich, una trampa meticulosamente colocada en la entrada misma del bosque oscuro de Ethereum: proveedores de RPC.

Antes de entrar en detalles, veamos cómo funcionan las transacciones en los intercambios descentralizados. Cuando los usuarios envían una transacción de intercambio, proporcionan varios parámetros al contrato inteligente: qué tokens intercambiar, el monto del intercambio y, lo que es más importante, la cantidad mínima de tokens que un usuario debe recibir para que se realice la transacción. Este último parámetro especifica que el intercambio debe satisfacer una "salida mínima" o revertir. Esto a menudo se conoce como "tolerancia de deslizamiento", ya que establece efectivamente el cambio de precio máximo que puede ocurrir entre el momento en que la transacción se envía al mempool y cuando se incluye en un bloque. Si este parámetro se establece demasiado bajo, el usuario acepta la posibilidad de recibir menos tokens. Esta situación también puede dar lugar a un ataque sándwich, en el que un atacante intercala la oferta entre dos intercambios maliciosos. Los intercambios elevan el precio al contado y obligan a que la operación del usuario se ejecute a un precio menos favorable. El atacante luego vende inmediatamente para obtener una pequeña ganancia.

Siempre que este parámetro de salida mínimo se establezca cerca del valor justo, estará a salvo de los ataques tipo sándwich. Pero, ¿qué sucede si su proveedor de RPC no proporciona una cotización de precio precisa del contrato inteligente de intercambio descentralizado? Luego, se puede engañar a un usuario para que firme una transacción de intercambio con un parámetro de salida mínimo más bajo y, para empeorar las cosas, envía la transacción directamente al proveedor de RPC malicioso. En lugar de transmitir esta transacción al mempool público, donde docenas de bots compiten para realizar el ataque sándwich, el proveedor puede retenerlo y enviar el paquete de transacciones de ataque directamente a Flashbots, asegurando las ganancias para ellos.

La causa principal de este ataque es confiar en otra persona para obtener el estado de la cadena de bloques. Los usuarios experimentados han resuelto tradicionalmente este problema ejecutando sus propios nodos de Ethereum, un esfuerzo intensivo en tiempo y recursos que, como mínimo, requiere una máquina constantemente en línea, cientos de gigabytes de almacenamiento y alrededor de un día para sincronizar desde cero. Este proceso es ciertamente más fácil de lo que solía ser; grupos como Ethereum en ARM han trabajado incansablemente para que sea posible ejecutar nodos en hardware de bajo costo (como una Raspberry Pi con un disco duro externo conectado). Pero incluso con estos requisitos relativamente mínimos, ejecutar un nodo sigue siendo difícil para la mayoría de los usuarios, especialmente para aquellos que utilizan dispositivos móviles.

Es importante tener en cuenta que los ataques de proveedores de RPC centralizados, aunque totalmente plausibles, generalmente son simples ataques de phishing – y el que describimos aún no ha sucedido. Aunque los antecedentes de proveedores más grandes como Alchemy nos dan pocas razones para dudar de ellos, vale la pena investigar un poco más antes de agregar proveedores de RPC desconocidos a su billetera.

Presentamos Helios: acceso totalmente confiable a Ethereum

Al presentar su protocolo de cliente ligero (que fue posible gracias al cambio reciente a Prueba de participación), Ethereum abrió nuevas y emocionantes posibilidades para interactuar rápidamente con la cadena de bloques y verificar los puntos finales de RPC con requisitos mínimos de hardware. En el mes desde La fusión, hemos visto surgir una nueva cosecha de clientes ligeros de forma independiente unos de otros (Estrella polar, Nimboy el basado en JavaScript Kevlar) que han adoptado diferentes enfoques al servicio del mismo objetivo: acceso eficiente y sin confianza, sin utilizar un nodo completo.

Nuestra solución, Helios, es un cliente ligero de Ethereum que se sincroniza en aproximadamente dos segundos, no requiere almacenamiento y brinda acceso totalmente confiable a Ethereum. Como todos los clientes de Ethereum, Helios consta de una capa de ejecución y una capa de consenso. A diferencia de la mayoría de los otros clientes, Helios combina estrechamente ambas capas para que los usuarios solo necesiten instalar y ejecutar una sola pieza de software. (Erigón también se está moviendo en esta dirección, al agregar un cliente ligero de capa de consenso integrado directamente en su nodo de archivo). 

¿Entonces, cómo funciona? La capa de consenso de Helios utiliza un hash de bloque de cadena de balizas previamente conocido y una conexión a un RPC que no es de confianza para sincronizar de manera verificable con el bloque actual. La capa de ejecución de Helios utiliza estos bloques de cadena de balizas autenticados junto con un RPC de capa de ejecución no confiable para probar información arbitraria sobre el estado de la cadena, como saldos de cuentas, almacenamiento de contratos, recibos de transacciones y resultados de llamadas de contratos inteligentes. Estos componentes trabajan juntos para brindar a los usuarios una RPC totalmente confiable, sin la necesidad de ejecutar un nodo completo.

…En la capa de consenso

El cliente ligero de la capa de consenso se ajusta al cliente ligero de la cadena de balizas especificación, y hace uso de los comités de sincronización de la cadena de balizas (introducidos antes de la fusión en la bifurcación alta de Altair). El comité de sincronización es un subconjunto seleccionado al azar de 512 validadores que sirven por períodos de ~27 horas. 

Cuando un validador está en un comité de sincronización, firma cada encabezado de bloque de cadena de balizas que ve. Si más de dos tercios del comité firman un encabezado de bloque determinado, es muy probable que ese bloque esté en la cadena de balizas canónicas. Si Helios conoce la composición del comité de sincronización actual, puede rastrear con confianza al líder de la cadena solicitando a un RPC que no sea de confianza la firma del comité de sincronización más reciente. 

Gracias a BLS firma agregación, solo se requiere una verificación para validar el nuevo encabezado. Si la firma es válida y ha sido firmada por más de dos tercios del comité, es seguro asumir que el bloque se incluyó en la cadena (por supuesto, se puede reorganizar fuera de la cadena, pero el seguimiento de la finalidad del bloque puede proporcionar garantías más estrictas).

Sin embargo, hay una pieza obvia que falta en esta estrategia: cómo encontrar el comité de sincronización actual. Esto comienza con la adquisición de una raíz de confianza llamada punto de control de subjetividad débil. No dejes que el nombre te intimide, solo significa un antiguo blockhash que podemos garantizar que se incluyó en la cadena en algún momento del pasado. Hay algunas matemáticas interesantes detrás de la antigüedad exacta del punto de control; El análisis del peor de los casos sugiere alrededor de dos semanas, mientras que las estimaciones más prácticas sugieren muchos meses. 

Si el punto de control es demasiado antiguo, hay ataques teóricos que puede engañar a los nodos para que sigan la cadena incorrecta. Adquirir un punto de control de subjetividad débil está fuera de banda para el protocolo. Nuestro enfoque con Helios proporciona un punto de control inicial codificado en el código base (que se puede anular fácilmente); luego guarda localmente el blockhash finalizado más reciente para usarlo como punto de control en el futuro, siempre que se sincronice el nodo. 

Convenientemente, los bloques de cadena de balizas se pueden codificar para producir un hash de bloque de baliza único. Esto significa que es fácil pedirle a un nodo un bloque de baliza completo y luego probar que los contenidos del bloque son válidos haciéndolos hash y comparándolos con un blockhash conocido. Helios usa esta propiedad para obtener y probar ciertos campos dentro del bloque de punto de control de subjetividad débil, incluidos dos campos muy importantes: el comité de sincronización actual y el próximo comité de sincronización. De manera crítica, este mecanismo permite que los clientes ligeros avancen rápidamente a través de la historia de la cadena de bloques.

Ahora que tenemos un punto de control de subjetividad débil, podemos buscar y verificar los comités de sincronización actuales y siguientes. Si el encabezado de la cadena actual se encuentra dentro del mismo período del comité de sincronización que el punto de control, inmediatamente comenzamos a verificar nuevos bloques con los encabezados del comité de sincronización firmados. Si nuestro punto de control está varios comités de sincronización por detrás, podemos:

1. Utilice el siguiente comité de sincronización después de nuestro punto de control para buscar y verificar un bloque que origine un comité de sincronización en el futuro.
2. Utilice este nuevo bloque para obtener el nuevo comité de próxima sincronización.
3. Si todavía está atrasado, regrese al paso 1.

Cada iteración de este proceso nos permite avanzar rápidamente a través de 27 horas del historial de la cadena, comenzar con cualquier blockhash en el pasado y sincronizar con el blockhash actual.

…En la capa de ejecución

El objetivo del cliente ligero de la capa de ejecución es tomar encabezados de bloque de baliza que son verificados por la capa de consenso y usarlos junto con un RPC de capa de ejecución que no es de confianza para proporcionar datos de capa de ejecución verificados. Luego se puede acceder a estos datos a través de un servidor RPC alojado localmente por Helios.

Aquí hay un ejemplo simple de cómo obtener el saldo de una cuenta, comenzando con una introducción rápida sobre cómo se almacena el estado en Ethereum. Cada cuenta contiene un par de campos, como el hash del código del contrato, el nonce, el hash de almacenamiento y el saldo. Estas cuentas se almacenan en un gran archivo modificado Árbol Merkle-Patricia llamado árbol de estado. Si conocemos la raíz del árbol de estado, podemos validar pruebas merkle para probar la existencia (o exclusión) de cualquier cuenta dentro del árbol. Estas pruebas son efectivamente imposibles de falsificar.

Helios tiene una raíz de estado autenticada de la capa de consenso. Usando esta raíz y solicitudes de prueba de merkle a la capa de ejecución no confiable RPC, Helios puede verificar localmente todos los datos almacenados en Ethereum.

Aplicamos diferentes técnicas para verificar todo tipo de datos utilizados por la capa de ejecución; usados ​​juntos, estos nos permiten autenticar todos los datos recuperados del RPC que no es de confianza. Si bien una RPC que no es de confianza puede denegar el acceso a los datos, ya no puede brindarnos resultados incorrectos.

Usando Helios en la naturaleza

La compensación entre portabilidad y descentralización es un problema común, pero dado que Helios es tan liviano, los usuarios pueden acceder a datos de cadena seguros desde cualquier dispositivo (incluidos teléfonos móviles y extensiones de navegador). La capacidad de ejecutar Helios en cualquier lugar hace posible que más personas accedan a datos de Ethereum sin confianza, independientemente de su hardware. Esto significa que los usuarios pueden usar Helios como su proveedor de RPC en MetaMask y acceder sin confianza a las dapps sin ningún otro cambio. 

Además, el soporte de Rust para WebAssembly hace posible que los desarrolladores de aplicaciones integren fácilmente Helios dentro de aplicaciones Javascript (como billeteras y dapps). Estas integraciones harían que Ethereum fuera más seguro y reducirían nuestra necesidad de confiar en una infraestructura centralizada.

No podemos esperar a ver qué se le ocurre a la comunidad. Pero mientras tanto, hay muchas maneras de contribuir a Helios: si no está interesado en contribuir con el código base, también puede crear software que integre Helios para aprovechar sus beneficios. Estas son solo algunas de las ideas que nos entusiasman:

• Admite la obtención de datos de clientes ligeros directamente desde la red P2P en lugar de a través de RPC
• Implementar algunos de los métodos RPC que faltan
• Cree una versión de Helios que se compile en WebAssembly
• Integre Helios directamente en el software de billetera
• Cree un panel web para ver sus saldos de tokens que obtenga datos de Helios incrustados en el sitio web con WebAssembly
• Implemente la API del motor para que la capa de consenso de Helios se pueda conectar a un nodo completo de la capa de ejecución existente

Echa un vistazo a la base de código para comenzar: agradecemos sus informes de errores, solicitudes de funciones y código. Y si construyes algo más, compártelo con nosotros en Twitter, Telegram, o Teleyector @a16zcrypto.

***
Las opiniones expresadas aquí son las del personal individual de AH Capital Management, LLC ("a16z") citado y no son las opiniones de a16z o sus afiliados. Cierta información contenida aquí se ha obtenido de fuentes de terceros, incluso de compañías de cartera de fondos administrados por a16z. Si bien se tomó de fuentes que se consideran confiables, a16z no ha verificado de forma independiente dicha información y no hace declaraciones sobre la precisión actual o duradera de la información o su idoneidad para una situación determinada. Además, este contenido puede incluir anuncios de terceros; a16z no ha revisado dichos anuncios y no respalda ningún contenido publicitario incluido en ellos.

Este contenido se proporciona solo con fines informativos y no debe considerarse como asesoramiento legal, comercial, de inversión o fiscal. Debe consultar a sus propios asesores sobre estos asuntos. Las referencias a cualquier valor o activo digital son solo para fines ilustrativos y no constituyen una recomendación de inversión ni una oferta para proporcionar servicios de asesoramiento de inversión. Además, este contenido no está dirigido ni destinado a ser utilizado por ningún inversionista o posible inversionista, y bajo ninguna circunstancia se puede confiar en él al tomar una decisión de invertir en cualquier fondo administrado por a16z. (Una oferta para invertir en un fondo a16z se realizará solo mediante el memorando de colocación privada, el acuerdo de suscripción y otra documentación relevante de dicho fondo y debe leerse en su totalidad). Cualquier inversión o compañía de cartera mencionada, referida o descritos no son representativos de todas las inversiones en vehículos administrados por a16z, y no puede garantizarse que las inversiones serán rentables o que otras inversiones realizadas en el futuro tendrán características o resultados similares. Una lista de inversiones realizadas por fondos administrados por Andreessen Horowitz (excluyendo inversiones para las cuales el emisor no ha otorgado permiso para que a16z divulgue públicamente, así como inversiones no anunciadas en activos digitales que cotizan en bolsa) está disponible en https://a16z.com/investments /.

Los cuadros y gráficos proporcionados en el interior tienen únicamente fines informativos y no se debe confiar en ellos al tomar cualquier decisión de inversión. El rendimiento pasado no es indicativo de resultados futuros. El contenido habla sólo a partir de la fecha indicada. Todas las proyecciones, estimaciones, pronósticos, objetivos, perspectivas y/u opiniones expresadas en estos materiales están sujetas a cambios sin previo aviso y pueden diferir o ser contrarias a las opiniones expresadas por otros. Consulte https://a16z.com/disclosures para obtener información adicional importante