Los DVNs de LayerZero verifican los mensajes entre cadenas; los Executors automatizan su entrega en la cadena de destino. Los DVNs obligatorios deben atestar todos, mientras que los DVNs opcionales satisfacen un umbral independiente. Un Executor no puede reemplazar una atestación obligatoria faltante, por lo que los fallos de verificación y los fallos de entrega requieren pasos de recuperación diferentes.
Ese último punto a menudo desaparece tras una lista de logotipos de proveedores. La seguridad del activo depende de qué proveedores requiere realmente el contrato, en cada ruta, en el momento de la transferencia.
A qué atesta un DVN
Una Red de Verificadores Descentralizados (DVN) comprueba el mensaje de la cadena de origen y envía una atestación asociada con su carga útil. La biblioteca de mensajes receptora evalúa las atestaciones obligatorias antes de que un mensaje sea elegible para su entrega. Cada DVN puede utilizar su propio método de verificación. Pila de seguridad del DVN.
La "red" en el nombre no debería sustituir la investigación sobre el operador. Aún necesitas comprender su infraestructura, claves y modos de fallo. Dos proveedores pueden tener nombres diferentes mientras dependen de la misma fuente de datos o entorno operativo.
La aplicación elige una combinación. Un único proveedor obligatorio crea una suposición de confianza diferente a la de varios proveedores obligatorios independientes. La elección cambia lo que un atacante necesitaría comprometer y lo que una interrupción podría interrumpir.
Una interrupción y un compromiso afectan esa elección de manera diferente. Un verificador fuera de línea puede impedir que un mensaje legítimo progrese. Un verificador comprometido puede atestar uno falso. Una política debe evaluarse frente a ambas situaciones.
Los verificadores deciden la aceptación. Los Executors entregan.
Este ejemplo separa la política de seguridad de la transacción de destino.
Ejemplo de política DVN
A obligatorio + B obligatorio + al menos una atestación opcional
Su atestación es obligatoria.
Las atestaciones opcionales adicionales no pueden reemplazarlo.
Cualquiera de los dos puede satisfacer el umbral opcional ilustrado.
Política ilustrativa, no es una configuración de producción recomendada ni una afirmación sobre la independencia del operador.
Obligatorio significa obligatorio
Un DVN requerido debe atestiguar. Añadir DVNs opcionales no otorga automáticamente a la aplicación una forma de omitir uno requerido que falte. Las atestaciones opcionales satisfacen su propio umbral configurado.
Por ejemplo, una política puede requerir A y B más un proveedor de un conjunto opcional que contenga C y D. Si B está fuera de línea, el hecho de que C y D atestiguen simultáneamente seguirá sin satisfacer la política. Si D está fuera de línea, C puede satisfacer la parte opcional mientras A y B siguen siendo necesarios. Esta es una configuración hipotética que demuestra la regla. Modelo de verificación de LayerZero.
Esa distinción tiene un costo operativo. Más testigos requeridos independientes pueden fortalecer la regla de aceptación, al tiempo que crean más dependencias para una entrega exitosa. Un equipo necesita planificar en torno a la disponibilidad de cada componente obligatorio.
La pregunta correcta es qué necesita proteger el activo. Un mint falsificado para un token de garantía ampliamente utilizado puede afectar a otras aplicaciones de préstamo o de trading. Esas exposiciones derivadas pueden justificar requisitos más estrictos que un mensaje de aplicación de bajo valor.
La diversidad debe sobrevivir a un fallo real
Diferentes nombres de proveedores son un comienzo. Una comprobación más sólida pregunta si los proveedores comparten fuentes de datos, sistemas en la nube, infraestructura de firma o tuberías de despliegue. Un fallo compartido puede anular el propósito de utilizar múltiples testigos.
La guía de producción de LayerZero analiza la diversidad de operadores e infraestructura junto con los métodos de verificación. También advierte contra el tratar los ajustes de muestra como una política de seguridad de producción. Configuración de DVN de producción.
Considera proveedores que lean todos los mismos datos de cadena de origen defectuosos. Sus firmas pueden ser independientes mientras que la observación detrás de ellas sea incorrecta. Un diseño más sólido reduce esa dependencia compartida en lugar de simplemente añadir otra firma.
Para un usuario, esta información puede ser difícil de establecer de forma independiente. Eso hace que las divulgaciones explícitas del emisor sean valiosas. Un proyecto que nombre los proveedores requeridos, explique la política y publique su configuración en vivo ofrece más para evaluar que una declaración genérica de "asegurado por LayerZero".
Los ejecutores gestionan la transacción de destino
Después de la verificación, alguien debe enviar y financiar una transacción en la cadena de destino. Un Executor automatiza ese trabajo bajo las opciones de ejecución del mensaje. Los mensajes verificados también pueden ejecutarse a través de llamadas a endpoints sin permiso. Documentación de Executor.
Una interrupción en la entrega puede, por lo tanto, retrasar un mensaje legítimo sin dar al servicio de entrega permiso para inventar uno válido. Las comprobaciones de verificación siguen siendo una puerta separada. Esa distinción es útil al interpretar una transferencia estancada.
No hace que la entrega sea irrelevante. La aplicación puede depender de que el gas, el valor adjunto o las llamadas posteriores se manejen correctamente. Un mensaje verificado todavía necesita suficientes recursos y una lógica de destino compatible para completar su acción prevista.
Un proceso de recuperación debe indicar a los operadores cómo identificar la etapa fallida y ejecutar un mensaje pendiente legítimo. También debe distinguir un fallo de ejecución de una política de verificación no cumplida. Pagar más gas de destino no puede sustituir una atestación requerida que nunca llegó.
Las confirmaciones reducen el riesgo a costa de velocidad
La verificación necesita una regla para determinar cuándo un evento de la cadena de origen está lo suficientemente liquidado como para ser confiable. Esperar confirmaciones adicionales puede ralentizar la experiencia mientras se reduce la exposición a una reorganización de la cadena.
Una acción de destino basada en un evento de origen que luego desaparece crea un problema de contabilidad. Para una transferencia de tokens, el destino puede haber acreditado un valor cuyo débito de origen ya no existe en el historial canónico. Por lo tanto, los supuestos de finalidad deben pertenecer a la descripción de seguridad del activo.
El ajuste correcto depende de la red y de la ruta. Un número de confirmación copiado de un ejemplo de desarrollo no establece una política de producción segura. La guía de producción y el propio modelo de finalidad de la cadena deben informar la elección. Guía de producción de LayerZero.
Para un producto financiero, la pregunta es qué retraso pueden aceptar sus usuarios en relación con la pérdida potencial. Una interfaz debe establecer las expectativas en consecuencia. Llamar a una transferencia más lenta como "rota" puede presionar a los equipos para debilitar un ajuste que existe por una razón.
La administración se sitúa por encima de la política
El propietario o la autoridad delegada pueden afectar a los pares de la aplicación y a la configuración. Incluso una política de verificación cuidadosamente elegida depende de la seguridad y la gobernanza de la cuenta que puede alterarla. Referencia técnica de OApp.
Pregunta quién controla esa autoridad y cómo se hacen visibles los cambios. Una política multisig solo ayuda en la medida en que sus firmantes y procedimientos operativos proporcionen un control independiente. Un retraso de tiempo solo ayuda si alguien supervisa el cambio pendiente y puede responder.
Los límites de transferencia y las pausas de emergencia pueden contener ciertos incidentes. También otorgan a los operadores poderes que los usuarios deben comprender. Una pausa puede proteger el suministro mientras evita que un titular complete una transferencia o salida planificada.
Para los activos RWA, esos poderes interactúan con las obligaciones del emisor y las restricciones del inversor. La verificación cross-chain comprueba un mensaje; no liquida los derechos legales vinculados al token. La introducción de RWA cubre esa reclamación independiente.
Inspecciona la ruta que estás utilizando
Registra los contratos de origen y destino, su relación de pares y los requisitos de verificador efectivos. Comprueba la política de confirmación, el proveedor de entrega y cualquier límite de transferencia. Luego, identifica quién puede cambiar esos ajustes.
Dejar un valor por defecto en su lugar sigue siendo una elección de configuración. Algunas rutas incluyen un marcador de posición Dead DVN y no pueden verificar mensajes hasta que la aplicación seleccione proveedores operativos. La documentación actual recomienda ajustes de producción explícitos y un verificador requerido independiente de LayerZero Labs. Inspecciona la configuración efectiva en lugar de asumir que un valor por defecto está listo para tu activo. Guía de configuración por defecto.
Haz esto para la dirección real de la transferencia. Una configuración que parece segura en una ruta no demuestra que todas las demás rutas tengan la misma política. Una afirmación de soporte en toda la red tampoco demuestra que todos los proveedores estén disponibles para tu activo.
Si tu interés es la contabilidad de tokens en torno a estos controles, lee la explicación del suministro de OFT. Si estás comparando proveedores de la infraestructura más amplia, LayerZero vs Chainlink CCIP utiliza el mismo enfoque específico por ruta.