Reenviar el Título Original ‘TeleportDAO:数据验证安全与效率之辔 —— 轻节点设计最新实践’
Nota: Eigen Labs es el desarrollador detrás de los protocolos de Restaking EigenLayer y EigenDA. Eigen Labs ha recaudado actualmente más de 150 millones de dólares estadounidenses de instituciones de capital riesgo conocidas como a16z, Polychain y Blockchain Capital.
TeleportDAO está ubicado en Vancouver, Canadá. Es un proyecto de infraestructura de comunicación entre cadenas centrado en las cadenas públicas de Bitcoin y EVM. El protocolo ha recaudado con éxito $9 millones en una ronda de ventas públicas y financiamiento a través de Coinlist. Esta ronda de financiamiento contó con la participación de varios inversores, incluidos Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across y bitSmiley.
Los nodos completos juegan un papel vital en el mantenimiento de la integridad de la cadena de bloques PoS. Almacenan toda la información de transacciones de bloques, verifican las firmas de consenso, replican una copia completa del historial de transacciones y realizan actualizaciones de estado. Estos procesos requieren muchos recursos informáticos y hardware complejo. Por ejemplo, ejecutar un nodo completo de Ethereum requiere al menos 2 TB de almacenamiento SSD. En contraste, los nodos ligeros reducen los requisitos de recursos informáticos y solo almacenan encabezados de bloques, por lo que solo son adecuados para escenarios en los que se verifican transacciones/estados específicos, como billeteras móviles y puentes entre cadenas. Además, los nodos ligeros dependen de los nodos completos para proporcionar información de bloques al verificar transacciones, pero la cuota de mercado actual de los proveedores de servicios de nodos es relativamente concentrada, por lo que la seguridad, la independencia y la inmediatez no pueden garantizarse completamente. Por lo tanto, este documento explora el compromiso entre el costo de adquisición de datos y la latencia para que los nodos ligeros logren una seguridad óptima.
Por el contrario, las blockchains de PoS obtienen seguridad a través de mecanismos de penalización. El sistema depende de que los participantes del consenso sean racionales y no ataquen la red si el costo de un ataque supera cualquier beneficio potencial. Para reducir los costos de verificación, el protocolo de nodo ligero actual de Ethereum depende de un comité de sincronización que consiste en 512 validadores de Ethereum seleccionados al azar, cada uno de los cuales apuesta 32 Ethereum, pero el proceso de firma no será multado. Este diseño inatacable tiene una gran falla de seguridad, y las firmas deshonestas en el comité de sincronización pueden inducir a los nodos ligeros a aceptar datos inválidos sin ser castigados. Incluso con la introducción de mecanismos de penalización, la apuesta total del Comité de Sincronización sigue siendo pequeña en comparación con la gran cantidad de validadores de Ethereum (a partir de marzo de 2024, el número de validadores de Ethereum ha superado el millón). Por lo tanto, este enfoque no puede proporcionar a los nodos ligeros una seguridad equivalente al conjunto de validadores de Ethereum. Este modelo representa una variante especial de cálculo multipartito en un entorno racional, pero no logra proporcionar garantías basadas en la economía o abordar las amenazas planteadas por proveedores de datos maliciosos e irracionales.
Para abordar los desafíos de seguridad y eficiencia en el proceso de arranque de PoS, PoPoS introduce un juego de segmentación para desafiar efectivamente el árbol de Merkle adversario en el tiempo de PoS. Si bien logran un impacto mínimo y evitan que los clientes siempre estén en línea y con participación, el problema de permitir que los clientes se desconecten sin incurrir en costos significativos para volver a unirse a la red sigue sin resolverse.
Otro enfoque de investigación se centra en el uso de pruebas de conocimiento cero para crear pruebas concisas. Por ejemplo, Mina y Plumo facilitan de manera efectiva la verificación de consenso ligero mediante la composición recursiva de SNARK y pruebas de transición de estado basadas en SNARK. Sin embargo, estos enfoques imponen una carga computacional considerable a los productores de bloques para generar pruebas, y no abordan el problema de compensar a los nodos ligeros por posibles pérdidas. En el contexto de otros protocolos de PoS, como el protocolo Tendermint utilizado en Cosmos, se explora el papel de los nodos ligeros en su protocolo de Comunicación Inter-Blockchain (IBC). Sin embargo, estas implementaciones son específicas de sus ecosistemas respectivos y no son directamente aplicables a Ethereum u otros blockchain de PoS.
Proceso específico de solicitud de datos del nodo ligero:
El nodo ligero obtiene la lista más reciente de proveedores de datos de la red actual y determina un período de desafío. Cabe destacar que este período de desafío es independiente entre los diferentes nodos ligeros, pero el límite superior del período de desafío se aplica a todos los nodos ligeros. El período de desafío es el tiempo más largo para que la red del fiscal verifique la credibilidad de los datos, por lo que cuanto más tiempo, más larga será la demora por transacción.- Después de obtener la lista, el nodo ligero seleccionará un grupo de proveedores de datos y se asegurará de que sus respectivos fondos apostados sean mayores que el valor de la transacción actual. Teóricamente, cuanto más altos sean los fondos apostados, mayor será el costo por mala conducta del proveedor de datos y menor será el costo de confianza del nodo ligero.- El nodo ligero envía la solicitud de datos correspondiente a este grupo de proveedores de datos, que incluye el número de bloque correspondiente y el estado objetivo (la prueba de inclusión de esta transacción).- El proveedor de datos envía el hash de bloque correspondiente y la prueba de inclusión de la transacción, y adjunta una firma.- Después de que el nodo ligero recibe los materiales mencionados anteriormente, los reenvía a la red de fiscales conectados actualmente. Si no se recibe ninguna advertencia de credibilidad de datos después de que termine el período de desafío, el nodo ligero verificará esta firma y pasará la prueba de credibilidad de datos si no hay errores.
Pero si se recibe una advertencia de la red del fiscal, el nodo ligero necesita desechar la firma recibida anteriormente. La red del fiscal presentará la prueba relevante al módulo de penalización del contrato inteligente. Si el contrato inteligente encuentra que efectivamente ocurrió la mala conducta después de verificar los datos, se penalizará la participación del proveedor de datos correspondiente. Dado que parte/todos los proveedores de datos seleccionados han sido penalizados, el nodo ligero necesita volver a obtener una nueva lista de proveedores de datos de la red actual para confirmar que el evento de reducción realmente ha ocurrido.
Otros puntos:
Cualquier nodo completo puede unirse o salir de la red de proveedores de datos iniciando solicitudes de “registro” y “retiro” al contrato inteligente. Existe un umbral mínimo de participación para registrarse y participar en la red de proveedores de datos. Una vez que un nodo completo elige iniciar un retiro, su estado en la red cambiará inmediatamente a “saliendo” y ya no podrán recibir solicitudes de nodos ligeros, para evitar posibles comportamientos maliciosos de entrada y salida rápida. Además, la red de proveedores de datos actualiza la lista de proveedores de datos actualmente activos en ciclos, durante los cuales los proveedores de datos no pueden recibir fondos de retiro. Una solicitud de retiro tendrá efecto en el último bloque del ciclo de actualización actual, y la frecuencia de actualización será mayor que el límite del período de desafío para garantizar que todas las pruebas de disponibilidad de datos de los nodos ligeros se hayan completado. Debido a la actividad de la red de proveedores de datos, los nodos ligeros necesitan volver a obtener la lista de proveedores activos actualmente cada vez que se actualiza la red. Si el ciclo de actualización se extiende, los nodos ligeros pueden disfrutar de un proceso de verificación más simplificado (mediante la estimación de la lista activa actual a través de las solicitudes de “registro” y “retiro” del ciclo anterior), pero los nodos que deseen salir enfrentarán un tiempo de espera más largo.- Una vez recibida la firma de datos, la red del fiscal verifica si la firma pertenece al proveedor de datos y evalúa si los datos han sido "finalmente confirmados" en la red de consenso. Si los datos no aparecen en una cadena razonable, hay dos posibilidades. Primero, los datos aún no han sido finalmente confirmados por la cadena de bloques actual, diferentes cadenas tienen diferentes reglas de finalidad, como el principio de la cadena más larga. Segundo, la transacción está en un bloque de otra cadena razonable. Si se encuentra que los datos anteriores son falsificados, la red del fiscal enviará una solicitud de reducción al contrato inteligente, que incluye la clave pública del proveedor de datos, la firma del proveedor de datos, el número de bloque, y al mismo tiempo envía una prueba del evento de reducción para recordar al nodo ligero. Una vez recibidos estos datos, el contrato inteligente mide si el número de bloque actualmente confirmado finalmente es consistente con los datos recibidos de acuerdo con el principio de finalidad de la capa de consenso. Si son inconsistentes, entonces se desencadena el evento de reducción. Además, si un proveedor de datos elegido por el nodo ligero es reducido debido a otro grupo de solicitudes de datos, la red del fiscal enviará rápidamente el evento de reducción para recordar al nodo ligero que la credibilidad de los datos del proveedor de datos es baja, y luego el nodo ligero volverá a obtener la lista y seleccionará otros proveedores.Evaluar:
Seguridad: El nodo ligero determina el costo del comportamiento malicioso para proveedores de datos racionales e irracionales a través del módulo de participación y la red de fiscales, mejorando la credibilidad de los datos. Sin embargo, dado que todo el protocolo se basa en la red de consenso (este documento se prueba en Ethereum), una vez que la capa de consenso es atacada, el protocolo también puede enfrentar una posible crisis de confianza. Por lo tanto, un mecanismo de reputación puede ser introducido adicionalmente para garantizar el riesgo sistémico en situaciones extremas.- Seguridad a nivel de Nodo Completo: Este esquema tiene como objetivo proporcionar seguridad equivalente a la suposición de PoS de Ethereum, es decir, los nodos completos deben asumir el riesgo de penalización por realizar declaraciones falsas.- Actividad de la red: Si la red actual solo tiene unos pocos proveedores de datos racionales, el nodo ligero enfrentará múltiples rondas de retraso, pero dado que la capacidad de procesamiento de cada proveedor de datos no es cero, cada solicitud siempre se completará. Por lo tanto, siempre y cuando la red tenga un nodo completo racional, puede garantizar que la red pueda seguir funcionando. Al mismo tiempo, como los ingresos de los proveedores de datos están vinculados a la cantidad de participación, esto también anima a los nodos completos a proteger la red apostando más de lo requerido.- Eficiencia: El equipo de autores del artículo predice que los validadores de Ethereum son los principales usuarios que participan en proveedores de datos, ya que los validadores ya están ejecutando nodos completos y pueden obtener ingresos adicionales a través de este protocolo. Las transacciones pequeñas pueden obtener datos creíbles a través de un solo proveedor de datos (el nodo ligero solo necesita verificar una vez), mientras que las transacciones grandes pueden necesitar varios proveedores de datos para obtener datos creíbles (el número de verificaciones aumenta linealmente con el número de proveedores).## Opción 2: Eficiencia PrimeroLa Solución 2 realiza una confirmación rápida de datos al proponer un mecanismo de seguro basado en la Solución 1. En términos simples, después de que el nodo ligero determine el seguro según el monto y la duración de la póliza, parte/toda la garantía del proveedor de datos puede ser reembolsada por las pérdidas posteriores del nodo ligero debido a la malicia de los datos. Por lo tanto, después de que el nodo ligero reciba y verifique la firma de datos proporcionada por el proveedor, puede determinar la credibilidad inicial de los datos.
Proceso específico de solicitud de datos del nodo ligero:

Otros puntos:
Los tokens de seguro apostados del proveedor de datos son independientes entre sí entre diferentes solicitudes de nodos ligeros para evitar el riesgo de múltiples reembolsos de seguros. Después de que el nodo ligero selecciona al proveedor de datos, el contrato inteligente bloqueará los tokens correspondientes comprometidos para el seguro, y otros nodos ligeros no podrán asignar esta parte de la fianza antes del final del período de seguro. Si las transacciones son independientes, la cantidad de seguro es la misma que la cantidad máxima de transacción. De lo contrario, la cantidad de seguro es la misma que la cantidad total de transacción. Bajo la misma cantidad de fianza, los nodos ligeros eligen generalmente tantos proveedores de datos como sea posible para garantizar la eficiencia de verificación.- Aunque el proveedor de datos puede iniciar una solicitud de “retiro” antes del final del período de seguro, el monto del retiro solo se recibirá después del final del período de seguro.- Estrictamente hablando, el período de la póliza de seguro debería ser mayor que el tiempo de confirmación del bloque final + período total de desafío + retraso de comunicación + retraso de cálculo/verificación. Cuantos más proveedores de datos elijas, más largo será el período de la póliza de seguro basado en el período total de desafío.Evaluar:
Escalabilidad: La escalabilidad de la Opción 2 está determinada por la cantidad total de tokens que los proveedores de datos están dispuestos a apostar para el seguro.- Costo de la póliza: Debido a que los niveles de seguridad más altos están vinculados al ciclo de desafío, esto significa que el proveedor de datos debe apostar por un período mayor o igual al ciclo de desafío. Por lo tanto, a mayores requisitos de seguridad, mayor es el ciclo de apuesta y mayor es la tarifa pagada por el nodo ligero. Según la fórmula, el costo de la apuesta del proveedor de datos se calcula dividiendo los ingresos del nodo del proveedor de datos entre (la utilización promedio de la apuesta a lo largo del año multiplicado por el número total de bloques por año). El precio que el nodo ligero necesita pagar es el costo de la apuesta multiplicado por el período de la póliza y el tamaño de la póliza.

Primero, en cuanto a la eficiencia computacional del nodo ligero, ambas soluciones de nodo ligero demuestran eficiencia de verificación a nivel de milisegundos (los nodos ligeros solo necesitan verificar los datos una vez).
En segundo lugar, en cuanto a la latencia del nodo ligero, en diferentes escenarios de configuración experimental (ver la figura a continuación), la latencia está en el nivel de milisegundos. Cabe destacar que la latencia aumenta linealmente con el número de proveedores de datos, pero siempre se mantiene en el nivel de milisegundos. Además, en la Solución 1, dado que el nodo ligero necesita esperar los resultados del período de desafío, la latencia es de 5 horas. Si la red del inspector es lo suficientemente confiable y eficiente, esta latencia de 5 horas también se puede reducir significativamente.

En tercer lugar, en cuanto a los costos del nodo ligero, en realidad, hay dos costos para los nodos ligeros: la tarifa de gas y la prima de seguro, ambos aumentarán a medida que aumente la cantidad de la póliza de seguro. Además, para los inspectores, el gas involucrado en la presentación de datos se reembolsará con la cantidad de la multa para garantizar incentivos de participación suficientes.
Nota: Los bloques propuestos eventualmente se finalizarán o se convertirán en bloques huérfanos.- Costos y tarifas: Para la red del fiscal, necesitan apostar una cierta cantidad de tokens (mayor que el gas) para enviar pruebas al contrato inteligente. Además, el costo de esta parte de la prueba se puede reducir a través del método zkp. Además, bajo el mecanismo de seguro, las primas enviadas por los nodos ligeros se darán a los proveedores de datos, mientras que la red del fiscal extraerá parte de los ingresos por penalizaciones de los proveedores malintencionados.- Disponibilidad de datos: Los proveedores de datos son esencialmente nodos completos. Además de participar en la red de capa de consenso, también pueden verificar la disponibilidad de datos. Hay dos tipos de esquemas para verificar la disponibilidad: modelo Pull y modelo Push. El primero se refiere al nodo ligero extrayendo aleatoriamente datos obtenidos del nodo completo. El segundo se refiere al productor de bloques distribuyendo bloques diferentes a los proveedores de datos. Para los proveedores de datos que adoptan el modelo Pull, son responsables de devolver las solicitudes de muestreo. Después de recibir los datos, el nodo ligero los reenvía al nodo/validador de confianza, y tratan de restaurar el bloque. Si fallan, al proveedor de datos se le impondrá una multa. El protocolo de nodo ligero en este artículo propone un mecanismo de seguro sobre esta base, proporcionando una nueva dirección de exploración para la investigación de la disponibilidad de datos.## Conclusión y EvaluaciónLa solución de nodo ligero propuesta en este artículo proporciona “seguridad programable” para cumplir con los requisitos de seguridad en diferentes situaciones. La Opción 1 intercambia mayor latencia por alta seguridad, mientras que la Opción 2 proporciona servicios de “confirmación instantánea” para nodos ligeros al introducir un mecanismo de seguro. Estas soluciones se pueden utilizar en escenarios donde la finalidad de las transacciones necesita ser confirmada, como transacciones atómicas e intercadenas.





