Saltar al contenido
Financial Context Wiki

Prueba de validez

Guía orientada a la verificación sobre pruebas de validez, entradas públicas, testigos, supuestos del sistema de prueba, transiciones de estado de rollups, disponibilidad de datos, finalidad y fallos operativos.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. Una prueba de validez solo es tan fiable como su afirmación, la vinculación de entradas públicas, el sistema de prueba, el verificador, la ruta de disponibilidad de datos, los contratos, operadores, gobernanza y cadena de liquidación.

Respuesta directa

Una prueba de validez es evidencia criptográfica de que un cálculo declarado satisface una relación definida con precisión. Un verificador comprueba la prueba frente a una clave de verificación y entradas públicas. En un rollup, esas entradas suelen vincular una raíz de estado anterior, una nueva raíz propuesta y compromisos de un lote de transacciones. Si la verificación tiene éxito, el contrato de liquidación puede aceptar la nueva raíz sin volver a ejecutar cada transacción.

La garantía es más limitada que «el sistema es correcto». Depende de criptografía sólida, del programa o circuito previsto, de una codificación correcta de las entradas públicas, de una clave de verificación auténtica y de contratos correctos de verificación y actualización de estado. Verificar no demuestra por sí solo que los usuarios puedan obtener los datos, que el probador siga activo, que el bloque de liquidación sea final, que una actualización sea benigna o que funcione la retirada. Puede usarse un sistema de conocimiento cero, pero validez no implica privacidad.

1
Ejecutar

El probador ejecuta un lote o cálculo y registra la transición de estado.

Cómo funciona

  1. Fijar el despliegue exacto: ID de las cadenas L1 y L2, versión del rollup, contrato de actualización, dirección y bytecode del verificador, hash de la clave, sistema de prueba, versión del circuito o programa, modo de disponibilidad, poderes administrativos, pausa y política de finalidad. validity proof no es una especificación común a todos los sistemas.
  2. Definir la relación probada antes de interpretar el resultado. Bajo los supuestos de solidez, Verify(vk, x, proof) = 1 debe implicar que existe un testigo w tal que R(x, w) = 1. vk es la clave de verificación, x la entrada pública completa y R las reglas codificadas. La prueba solo demuestra esa relación.
  3. Reconstruir de forma independiente las entradas públicas. Confirmar que la raíz anterior es la aceptada por el contrato; derivar de datos canónicos el compromiso del lote o de datos, identificadores, raíz posterior, raíces de mensajes o retiradas y parámetros. Una prueba válida vinculada a cadena, raíz, programa o lote equivocados demuestra la afirmación equivocada.
  4. Verificar la prueba y la ruta contractual. Ejecutar un verificador independiente compatible y revisar llamada onchain, recibo, evento, número de lote aceptado y cambio de almacenamiento. Confirmar que el contrato invocó al verificador previsto y no eludió, simuló o sustituyó el resultado mediante actualización o rama privilegiada.
  5. Verificar por separado la disponibilidad de datos. Obtener transacciones, diferencias de estado, blob sidecars o datos certificados por comité exigidos por el protocolo; comprobar compromisos y reproducir transición o testigo de salida. Una prueba válida puede coexistir con datos no disponibles, sobre todo en validium o con un comité externo.
  6. Separar estados del ciclo de vida: generado, enviado, incluido, prueba verificada, estado aceptado, liquidación segura, liquidación finalizada y retirada completada. Medir cola y coste de pruebas, actividad de secuenciador y probador, inclusión L1, reorganizaciones, demoras del puente, inclusión forzada y escape en vez de llamar «final» a todo.
  7. Conservar evidencia reproducible: direcciones y hashes de código, hashes de clave y programa, entradas públicas completas, bytes de prueba o referencia duradera, datos del lote, comando y versión del software, recibo, bloque finalizado y prueba de salida exitosa. Repetir tras cada actualización.

Ejemplos calculados

  • Afirmación del lote. Un rollup procesa 8,192 transfers. La prueba vincula raíz antigua R0, nueva R1 y compromiso B7. Verificar respalda: «existe un testigo que satisface este circuito de R0 a R1 para B7». No prueba que puedan obtenerse los bytes de B7, que el secuenciador incluyera todo ni que R1 sea final.
  • Agregación recursiva. Un agregador verifica 16 child proofs en un circuito padre y envía una prueba padre. Si pasa, se aceptan la relación de agregación y los compromisos hijos vinculados. Aun así hay que comprobar que el circuito revisa cada hijo, el orden y el mapeo de entradas públicas; el número de pruebas no crea esa vinculación.
  • Libro de gas hipotético. La reejecución usaría 24,000,000 gas, verificar la prueba 600,000 gas y publicar datos 180,000 gas. La ruta suma 600,000 + 180,000 = 780,000 gas, reducción modelada de (24,000,000 - 780,000) / 24,000,000 = 96.75%. Se excluyen hardware, agregación, envíos fallidos, almacenamiento, puentes y retención.

Riesgos

  • Comprobar cadena, despliegue, lote, verificador, clave o circuito equivocados.
  • Que un sistema sólido pruebe fielmente un circuito incompleto o erróneo.
  • Entradas públicas que omiten o codifican mal ID, raíz, lote, dominio de mensaje o parámetro.
  • Fallo del verificador, precompilado, biblioteca insegura o implementación incompatible.
  • Material de configuración comprometido o supuestos criptográficos vulnerados.
  • Contratos actualizables o gobernanza que sustituyen verificador, clave, programa o regla.
  • Elusiones privilegiadas, emergencia, pausas o listas permitidas que debilitan la ruta.
  • Fallos al generar pruebas, no determinismo o testigos distintos entre clientes.
  • Centralización, censura, caída, cola o fallo de hardware del probador detienen actualizaciones.
  • Faltan transacciones, diferencias de estado, blobs, preimágenes o historial archivado.
  • Confundir firmas de comité o compromiso de datos con recuperación actual.
  • Aceptar una prueba de un bloque inseguro, reorganizado o no canónico.
  • Confundir aceptación de prueba con retirada inmediata o finalidad económica.
  • No reproducir de forma independiente transición, saldo, mensaje o testigo de salida.
  • Subestimar gas, tarifas de datos, latencia, demoras del puente o recuperación.
  • Aplicar el modelo de prueba, disponibilidad y actualización de un rollup a otro.

Errores comunes

  • Una prueba verificada demuestra todos los detalles de implementación y saldos visibles.
  • Toda prueba de validez es de conocimiento cero y oculta transacciones.
  • Las pruebas eliminan riesgos de disponibilidad, actividad del secuenciador y censura.
  • Verificar vuelve la liquidación inmediatamente final y retirable.
  • Una prueba menor o verificador más rápido hace el sistema automáticamente más seguro o barato.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...