Saltar al contenido
Financial Context Wiki

Clientes ligeros

Guía sensible a las bifurcaciones sobre el arranque de clientes ligeros de consenso, comités de sincronización, puntos de control de subjetividad débil, cabeceras optimistas y finalizadas, pruebas del estado de ejecución, proveedores RPC, disponibilidad de datos y privacidad.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Un cliente ligero es software de verificación que sigue una cadena de bloques con menos ejecución, estado e historial locales que un nodo completo. Un nodo ligero es un dispositivo o proceso que ejecuta ese software. En Ethereum con prueba de participación, un cliente ligero de consenso arranca desde un punto de control finalizado reciente y de confianza, y verifica actualizaciones de comités de sincronización teniendo en cuenta las bifurcaciones para mantener cabeceras optimistas y finalizadas. No reproduce todas las transacciones de la EVM.

Esa vista de consenso verificada es solo el primer ancla de confianza. Para verificar el valor de una cuenta o del almacenamiento de un contrato, el cliente debe vincular la cabecera beacon autenticada con la cabecera de la carga de ejecución, seleccionar su stateRoot y verificar contra esa raíz una prueba de cuenta o almacenamiento. Una respuesta RPC ordinaria sin la prueba exigida sigue siendo una afirmación del proveedor. Las firmas de consenso no prueban automáticamente el historial de transacciones, los recibos, las trazas, la disponibilidad de datos, el comportamiento de las aplicaciones ni la recuperación a largo plazo.

Cómo funciona

  1. Fijar la red y las raíces de confianza: identidad de la cadena, raíz y hora de los validadores génesis, calendario de bifurcaciones y parámetros preestablecidos, reloj actual, versión del cliente y un punto de control finalizado, reciente y de confianza para la subjetividad débil. Contrastar el punto de control mediante fuentes autenticadas e independientes; el acuerdo entre pares no corrige una raíz inicial maliciosa.
  2. Obtener un LightClientBootstrap para la raíz del bloque de confianza. Verificar la cabecera de arranque, el comité de sincronización actual y su rama de Merkle, e inicializar después el LightClientStore. Rechazar toda cadena, resumen de bifurcación, índice generalizado o esquema de serialización que no coincida con la bifurcación configurada.
  3. Procesar los objetos LightClientUpdate por periodo del comité de sincronización. Antes de rotar los comités, verificar slots, bits de participación, firma BLS agregada y dominio, ramas de los comités actual y siguiente, rama de finalidad y monotonicidad. Las actualizaciones de bifurcación pueden cambiar campos de objetos e índices generalizados; las constantes de Altair no son valores universales permanentes.
  4. Mantener políticas separadas para optimistic_header y finalized_header. Una actualización optimista puede aportar información más reciente con mayor exposición a reorganización o retención; una actualización finalizada tiene un estado de consenso más sólido, pero puede ir rezagada. La aplicación debe elegir expresamente la cabecera apropiada, no volver a etiquetar como final la respuesta más reciente.
  5. Anclar los datos de ejecución. Verificar la cabecera de la carga de ejecución y la rama incluida en la cabecera autenticada del cliente ligero; después, vincular cada consulta de cuenta o almacenamiento con el stateRoot, el hash de bloque y el estado de finalidad de esa ejecución. En Ethereum, eth_getProof puede devolver una prueba de cuenta y las pruebas de almacenamiento solicitadas; los nodos, rutas, valores y la inexistencia deben verificarse localmente.
  6. Inventariar cada superficie no verificada. Una prueba de saldo no autentica un recibo de transacción, consulta de logs, traza, simulación de llamada, mempool, etiqueta de token, oráculo, blob, intervalo histórico ni la afirmación del proveedor de que no omitió resultados. Para cada objeto necesario, definir una prueba, una reconstrucción independiente, una alternativa mediante nodo completo o un supuesto de confianza explícito.
  7. Operar con cierre ante fallos. Registrar punto de control, bifurcación, raíces optimista y finalizada, bloque y raíz de estado de ejecución, nodos de prueba, proveedor y marcas de tiempo. Imponer una antigüedad máxima, diversificar proveedores y rutas de red, proteger la privacidad de las consultas, probar la recuperación frente a eclipses y caídas, y usar un nodo completo u otro sistema de verificación cuando la superficie de pruebas del cliente ligero sea insuficiente.

Ejemplos desarrollados

  • Límite entero del comité de sincronización. Para un comité de 512 miembros, la prueba de supermayoría de la especificación es participants * 3 >= 512 * 2. Con 341 participantes, 341 / 512 = 66.6015625% y 1,023 < 1,024, por lo que la prueba falla. Con 342, 342 / 512 = 66.796875% y 1,026 >= 1,024, por lo que se supera. Esto verifica la regla configurada para la actualización; no demuestra que todos los miembros del comité o todas las implementaciones sean honestos.
  • Relojes de las cabeceras. Un punto de control didáctico está en el slot 10,000, una cabecera atestiguada está en 10,064 y su cabecera finalizada está en 10,032. A 12 seconds/slot, la cabecera atestiguada queda 64 * 12 = 768 seconds = 12 minutes 48 seconds después del punto de control, mientras que la finalidad queda 32 * 12 = 384 seconds = 6 minutes 24 seconds por detrás de la cabecera atestiguada. El tiempo de los slots no garantiza entrega de red ni finalidad con un SLA fijo de reloj real.
  • Rama compacta, afirmación limitada. En un árbol equilibrado ideal con 2^20 hojas, la rama de una sola hoja contiene 20 hashes hermanos. A 32 bytes/hash, suma 640 bytes; frente a un objeto de 8 MiB = 8,388,608 bytes, la rama supone el 0.00762939453125% del tamaño, una reducción del 99.99237060546875%. La rama solo prueba la relación de su hoja con la raíz, no la disponibilidad de los demás bytes.
  • Prueba frente a RPC sin prueba. Para un stateRoot de ejecución finalizado, una prueba de cuenta verificada arroja 3.25 ETH, mientras que una respuesta RPC sin prueba indica 3.30 ETH. La discrepancia es de 0.05 ETH y la respuesta sin prueba es 0.05 / 3.30 = 1.5151515152% superior. Debe aceptarse el valor probado bajo la raíz elegida, pero no deducirse de esa prueba un saldo posterior, un recibo, un resultado histórico ni la identidad del token.

Riesgos

  • Configurar una cadena, raíz de validadores génesis, hora génesis o conjunto de parámetros incorrectos.
  • Arrancar desde un punto de control malicioso, obsoleto o no finalizado.
  • Usar una única fuente no autenticada para el punto de control o aceptar una bifurcación de largo alcance.
  • Que una desviación del reloj local provoque decisiones erróneas sobre slots, periodos, dominios o antigüedad.
  • Ejecutar un calendario de bifurcaciones, esquema de objetos o índice generalizado obsoleto.
  • No validar la participación del comité de sincronización, las firmas BLS o los dominios.
  • Omitir la rotación del comité o aceptar un comité actual o siguiente inválido.
  • Tratar la cabecera optimista como cabecera finalizada.
  • Vincular una cabecera beacon, carga de ejecución o hash de bloque de ejecución incorrectos.
  • Verificar una prueba de cuenta o almacenamiento contra el stateRoot equivocado.
  • Aceptar nodos de trie, rutas, codificaciones o pruebas de inexistencia malformados.
  • Tratar como verificado un método RPC no compatible o carente de prueba.
  • Recibir respuestas obsoletas, censuradas, incompletas o fabricadas por el proveedor.
  • Sufrir fallos de eclipse, Sybil o control común entre proveedores aparentemente distintos.
  • Perder disponibilidad cuando los nodos completos que sirven pruebas podan datos o dejan de prestarlos.
  • Confundir la validez del consenso con la reproducción de la ejecución o la corrección de la aplicación.
  • Confundir una prueba válida con disponibilidad de datos o recuperabilidad permanente.
  • Carecer de recibos, logs, trazas, cuerpos o historial necesarios para la aplicación.
  • Sufrir fallos de implementación, dependencia, binario o actualización de bifurcación del cliente.
  • Exponer a proveedores o pares consultas, IP, cuentas y transacciones.

Errores comunes

  • Un cliente ligero es simplemente un nodo completo más pequeño o un endpoint RPC remoto con otro nombre.
  • Una cabecera verificada por el comité de sincronización vuelve fiable cualquier respuesta RPC.
  • La cabecera optimista más reciente equivale a una cabecera finalizada.
  • Una prueba de Merkle o una firma de consenso demuestra la disponibilidad de datos y el historial completo.
  • Usar un cliente ligero aporta automáticamente la privacidad, disponibilidad y resistencia a la censura de un nodo completo.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...