QuantovaQstampby Quantova
ES
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Empezar a desarrollar →
Qstamp / Flujos de datos
Flujos de datos

Qué se mueve y hacia dónde, y qué nunca sale de sus sistemas.

Todos los productos de la familia Qstamp siguen los mismos tres flujos. Un registro se sella dentro de los sistemas de su titular, un compromiso criptográfico con sal se ancla en la red Quantova, y cualquier parte puede verificar posteriormente el registro frente a su recibo. Esta página describe cada flujo paso a paso e indica exactamente qué datos cruzan cada límite.

Live flow

The three flows in motion.

Each step lights in turn as a record moves through it. Steps inside your systems never send content out. Only the anchor reaches the Quantova network, and only chain facts are public on QVMScan.

Live flowQstamp, from your application to the explorer
  1. Your systemsYour applicationCreates a record, a decision, a model or a document
  2. Your systemsQstamp SDKSHA3 256 fingerprint bound to a fresh random salt
  3. Your systemsBatch treeUp to 1,048,576 records in one RFC 9162 tree
  4. Quantova networkQstamp contractCommitment anchored in a transaction signed with ML DSA 65
  5. Quantova networkFinalityValidator committee finalises the block in about 0.2 seconds
  6. PublicQVMScanAnchor public, record content private
  7. PublicAny verifierProves the record existed unchanged at that time
Inside your systemsQuantova networkPublic and verifiable
Límites

Tres zonas, y los datos permitidos en cada una.

La regla de diseño de la familia es que el contenido de los registros nunca sale de la zona de su titular. Solo los compromisos criptográficos de longitud fija cruzan hacia la red, y solo los hechos de la cadena son públicos.

Zona 1

Dentro de sus sistemas

  • El registro y sus documentos
  • Claves de firma y sales
  • Datos personales y comerciales
  • Sobres firmados y recibos
Zona 2

Enviado a la red

  • Un compromiso criptográfico con sal de 32 bytes por lote
  • El tipo de registro, como QTax
  • Una transacción firmada con ML DSA 65
  • Nada que pueda invertirse para obtener el contenido
Zona 3

Público en QVMScan

  • El compromiso criptográfico y la dirección del firmante
  • El bloque, su hora y su firmeza
  • El tipo de registro y el tamaño del lote
  • Ningún registro, documento ni identidad
Flujo 1

Sellado de un registro, dentro de sus sistemas.

El sellado ocurre allí donde se crea el registro, sin necesidad de acceso a la red.

  1. 01Captura

    La aplicación crea el registro en el momento en que ocurre el evento, como una acción de un agente, una declaración o un pago.

  2. 02Codificación canónica

    El registro se codifica en una forma binaria fija, de modo que el mismo registro siempre produce los mismos bytes y ningún campo puede reinterpretarse.

  3. 03Firma

    El registro se firma con ML DSA bajo una cadena de contexto propia del producto, utilizando una clave que solo posee su titular.

  4. 04Huella digital

    Se calcula una huella digital SHA3 256 sobre el registro codificado y su firma, con una etiqueta de dominio propia del producto.

  5. 05Hoja con sal

    La huella digital se combina con una sal aleatoria nueva, de modo que nada de lo publicado pueda utilizarse para confirmar una conjetura sobre el registro.

  6. 06Árbol del lote

    Las hojas se agrupan en un árbol de Merkle conforme a RFC 9162, de modo que un solo compromiso criptográfico pueda abarcar miles de registros.

Flujo 2

Anclaje de un compromiso criptográfico en la red Quantova.

El anclaje fija el compromiso criptográfico en el tiempo. Puede ejecutarse conforme a un calendario, a través de una puerta de enlace controlada, desde una única cuenta con fondos.

  1. 01Compromiso

    La raíz del árbol del lote se vincula a la red, al contrato, al firmante, al tipo de registro y al tamaño del lote.

  2. 02Transacción

    El compromiso criptográfico se envía al contrato oficial de Qstamp en una transacción firmada con ML DSA 65.

  3. 03Firmeza

    Un comité de validadores que firma con ML DSA 65 finaliza el bloque, por lo general en aproximadamente 0,2 segundos.

  4. 04Evento

    El contrato emite un evento que contiene el firmante, el compromiso criptográfico y el tipo de registro, visible en QVMScan.

  5. 05Recibo

    Cada registro recibe su propio recibo con su ruta de inclusión, su sal y la transacción, que se almacena junto con el registro.

  6. 06Recuperación

    Si la conexión falla después del envío, se conserva un sellado pendiente y el anclaje se completa más adelante, de modo que ningún registro se ancla dos veces.

Flujo 3

Verificación de un registro, por cualquiera, en cualquier momento.

La verificación necesita el registro, su sobre, su recibo y la clave pública del firmante. No necesita el software de Quantova ni los sistemas del productor.

  1. 01Firma

    El verificador comprueba la firma ML DSA frente a la clave pública indicada en el registro y frente a las claves de confianza que espera.

  2. 02Vínculos

    Cuando el registro depende de registros anteriores, se comprueba que cada registro vinculado sea exactamente el indicado y esté firmado válidamente.

  3. 03Normas

    Se aplican las normas propias del producto, como la separación de funciones, los totales acumulados, el orden temporal y los límites del retraso de anclaje.

  4. 04Inclusión

    La hoja se vuelve a calcular y se comprueba su ruta hasta la raíz comprometida.

  5. 05Cadena

    El verificador confirma en la red que la transacción es firme y que el contrato emitió el compromiso criptográfico.

  6. 06Resultado

    El resultado es válido, no válido o indeterminado, con todas las comprobaciones enumeradas. La ausencia de evidencia nunca produce un resultado válido.

Por caso de uso

Los mismos flujos, aplicados a registros reales.

Caso de usoRegistro selladoVinculado aQué puede demostrar un verificador
Agentes de IACada llamada a una herramienta, cambio de modelo y decisiónLa entrada de registro anterior y el mandato del agenteEl agente actuó dentro de su mandato y no se eliminó ninguna acción
Pagos de agentesCada intención de pago y su reciboEl mandato y sus límites de gastoLos pagos se mantuvieron dentro de los límites autorizados
FiscalidadDeclaraciones, facturas, liquidaciones y devolucionesLa declaración, la liquidación y las devoluciones anterioresNinguna devolución supera el importe debido y ningún registro se fechó retroactivamente
Contratación públicaCompromisos criptográficos de ofertas, puntuaciones y adjudicacionesEl anuncio de licitación y las puntuaciones firmadasNinguna oferta se añadió ni se sustituyó después del plazo
EleccionesActas de los colegios electorales y operaciones de escrutinioFuncionarios registrados y softwareEl resultado declarado coincide con las actas certificadas
Contenido de IAContenido, modelos y conjuntos de datosLos ingredientes y el titular del modeloEl origen y el historial del contenido son los declarados
Claves

Custodia de claves en cada flujo.

Generadas localmente

Las claves se generan a partir de la fuente aleatoria segura del propio sistema del operador y nunca se transmiten a Quantova.

Asignadas por función

Se mantienen claves distintas para funciones distintas, de modo que una misma persona o sistema no pueda crear y aprobar el mismo registro.

Eliminadas tras su uso

Los SDK eliminan el material de claves de la memoria después de cada operación, y los archivos de claves de la línea de comandos deben ser legibles únicamente por su propietario.