Datos enlazados: estructuras arbitrarias verificables por hash

Las cuatro lecciones anteriores han montado las piezas: la recursión que define el grafo, la propiedad de resumen que lo hace comparable, el troceado que fabrica nodos donde solo había bytes y el identificador que se explica a sí mismo. Falta ponerles encima un modelo de datos, porque hasta ahora hemos hablado de nodos con datos y enlaces sin decir nunca de qué tipo son esos datos ni qué es exactamente un enlace. La respuesta que ha terminado imponiéndose consiste en tomar el repertorio de tipos que cualquiera reconocería de un formato de intercambio moderno —nulos, booleanos, números, cadenas, bytes, listas y mapas— y añadirle uno más, el enlace, cuyo valor es un identificador de contenido. Ese añadido, que en la lista parece el menos importante, es el que convierte una serialización cualquiera en un grafo verificable de alcance arbitrario, y esta lección cierra el nivel explicando qué se puede construir con él y qué queda deliberadamente fuera.

El enlace como tipo de primera clase

La tentación evidente al construir esto es no hacer nada: guardar el identificador como una cadena dentro de un mapa y que cada aplicación sepa qué campos son enlaces y cuáles no. Funciona, y falla en cuanto el sistema deja de ser una sola aplicación. Si el enlace no está tipado, ninguna herramienta genérica puede recorrer el grafo, porque no distingue un identificador de una cadena que se le parece; el recolector de basura no sabe qué está referenciado y qué no; el sincronizador no puede calcular el cierre transitivo de lo que hay que transferir; y el verificador no sabe dónde termina un bloque y empieza otro. Todas esas funciones exigen entender la topología sin entender la semántica, y para eso el enlace tiene que ser reconocible por el analizador, no por la aplicación.

// El repertorio del modelo, con el enlace como un tipo mas
const nodo = {
  titulo: "informe",          // cadena
  paginas: 128,               // entero
  revisado: true,             // booleano
  firma: bytesDe("..."),      // bytes opacos
  secciones: [                // lista
    { enlace: "id-de-la-seccion-uno" },   // ENLACE, no una cadena cualquiera
    { enlace: "id-de-la-seccion-dos" },
  ],
  anterior: { enlace: "id-de-la-version-previa" },
};

Hay además una razón de higiene que refuerza el argumento. Si el enlace fuera una cadena, nada impediría construirlo concatenando texto, compararlo con expresiones regulares o guardarlo con la escritura textual que viniera dada, y cada una de esas prácticas introduce una forma distinta de que dos referencias al mismo bloque dejen de parecerse. Con un tipo propio, el analizador decodifica a bytes al leer y vuelve a codificar al escribir, de modo que la identidad canónica está garantizada por el formato y no por la disciplina de quien programa.

Esa distinción tiene una consecuencia conceptual que conviene enunciar. Con el enlace tipado, la frontera entre un bloque y otro deja de ser una decisión semántica y pasa a ser una decisión de empaquetado. Que las secciones del informe estén dentro del mismo bloque o en bloques aparte no cambia lo que el documento significa; cambia cuánto hay que descargar para leer el título, con qué granularidad se deduplica y qué se invalida al editar. El modelo permite mover esa frontera sin tocar el esquema, y esa libertad es lo que hace posible afinar el troceado de la lección anterior sin renegociar el formato.

Rutas: recorrer el grafo como si fuera un documento

Con el enlace tipado, el recorrido se puede expresar de una forma que oculta por completo dónde termina cada bloque. Una ruta es una secuencia de claves e índices, y el resolutor la sigue campo a campo; cuando el valor que encuentra en un paso es un enlace, resuelve el bloque correspondiente, lo verifica contra el identificador que ya tenía y continúa dentro de él como si nunca hubiera cambiado de bloque.

// El resolutor cruza fronteras de bloque sin que la ruta se entere
async function resolver(id, ruta) {
  let bloque = await leerYVerificar(id);
  let valor = bloque;
  for (const paso of ruta) {
    valor = valor[paso];
    if (esEnlace(valor)) {
      bloque = await leerYVerificar(valor.enlace);   // salto de bloque
      valor = bloque;
    }
  }
  return valor;
}

flowchart TB
R[raiz del documento] -->|secciones 2| S[bloque de la seccion tres]
S -->|parrafos 0| P[bloque del parrafo]
P -->|texto| T[valor final]
R -.->|no se descarga| O[resto de secciones]
style T fill:#a6e3a1,color:#11111b
style O fill:#6c7086,color:#cdd6f4

Lo que el diagrama muestra es la lectura parcial verificada, que es la capacidad más útil del modelo y la que separa esto de un simple formato de serialización. Para leer un campo profundo de una estructura de cien gigabytes se descargan únicamente los bloques del camino, y cada uno se autentica al llegar contra el identificador que venía en el bloque anterior, que a su vez se autenticó contra el suyo, hasta la raíz de la que partías. No hace falta confiar en quien sirve los bloques ni descargar nada que no vayas a mirar, y las dos cosas se obtienen del mismo mecanismo.

Merece la pena señalar que el número de saltos de red es la longitud del camino, no su tamaño, y que esos saltos son inevitablemente secuenciales porque no sabes el identificador del siguiente bloque hasta haber leído el anterior. Es la misma latencia acumulada que sufre cualquier estructura enlazada sobre un medio con retardo, y las implementaciones serias la combaten igual: enviando la ruta entera al servidor para que devuelva todos los bloques del camino en una sola respuesta, que el cliente verifica en orden sin haber pagado una ronda por nivel.

Leer un campo profundo de una estructura de cien gigabytes

  bloques del camino ....... uno por nivel, del orden de cinco a diez
  bytes descargados ........ los de esos bloques, no los del subgrafo
  verificaciones ........... una por bloque, encadenadas desde la raiz
  confianza requerida ...... solo el identificador de raiz que ya tenias

  el servidor puede ser hostil y el resultado sigue siendo correcto

Esa última línea es la que conviene retener, porque describe una propiedad poco común. En una interfaz convencional, pedir un campo concreto a un servidor implica confiar en que el servidor devuelva el campo correcto, y no hay forma de comprobarlo desde el cliente sin descargar lo suficiente para recalcularlo. Aquí no hay nada que confiar: el servidor puede negarse a responder, puede responder despacio o puede mandar basura, y las tres cosas se detectan, pero no puede mandar un valor falso que pase la verificación. La distinción entre negar el servicio y falsificar la respuesta se vuelve nítida, y solo la primera sigue siendo posible.

Lo que el modelo habilita

Con el enlace tipado y las rutas encima, aparecen cuatro capacidades que ninguna de ellas por separado da. La primera ya está dicha: leer una parte de una estructura enorme con verificación de extremo a extremo. La segunda es la compartición estructural entre versiones, que ahora funciona sobre datos con esquema y no solo sobre ficheros: una versión nueva de un documento reutiliza todos los subárboles intactos y escribe únicamente los nodos del camino modificado, exactamente como en la primera lección pero con campos, tipos y significado.

La tercera es la interoperabilidad hacia atrás. Cualquier sistema anterior que ya nombrara sus objetos por el hash de su contenido resulta ser, mirado desde aquí, una instancia de este modelo con un códec propio: un sistema de control de versiones cuyos objetos apuntan a otros objetos por hash, una cadena de bloques donde cada bloque referencia al anterior, un fichero de bloqueo de dependencias que fija cada paquete por su resumen. Reservarles un código de códec los incorpora al grafo sin migrar nada, y esa es la razón práctica de que el códec esté dentro del identificador.

La cuarta es que las herramientas genéricas se vuelven posibles. Un recolector de basura que marque desde las raíces, un sincronizador que calcule el cierre transitivo de lo alcanzable, un validador de esquema que compruebe la forma de un nodo, un explorador que permita navegar el grafo a mano: todos ellos se escriben una sola vez y funcionan sobre cualquier aplicación, porque operan sobre la topología y no sobre el significado.

Ese último punto merece insistencia porque marca la diferencia entre un formato y un ecosistema. En una arquitectura convencional, cada aplicación reimplementa su propio recorrido, su propia recolección y su propia sincronización, y ninguna de esas piezas se puede reutilizar porque todas dependen del esquema concreto. Aquí la separación entre topología y semántica es explícita y está en el tipo de dato, de modo que la infraestructura se escribe contra la primera y las aplicaciones contra la segunda. Es exactamente la misma división de trabajo que hace útil a un sistema de ficheros, donde el núcleo entiende directorios sin entender qué hay dentro de los ficheros.

Los límites, que son tan importantes como las capacidades

Conviene enumerarlos sin suavizarlos, porque son los que decidirán si este modelo encaja en un problema concreto o si lo estás forzando. Cuatro de ellos son estructurales y no se arreglan con una implementación mejor: la ausencia de mutación, la ausencia de tiempo y autoría, la imposibilidad de consultar por valor y la separación entre nombrar y tener. Los cuatro tienen soluciones conocidas que viven fuera del esquema, y en los cuatro casos el trabajo de diseño consiste en decidir dónde poner esa capa de fuera y qué garantías vas a exigirle.

El primero y el que más consecuencias arrastra: aquí no hay mutación. Cambiar algo significa escribir nodos nuevos y obtener una raíz nueva, y nada dentro del grafo indica que esa raíz sustituya a la anterior. Todo sistema real necesita por tanto una capa de indirección mutable —un nombre estable que apunte a una raíz cambiante— y esa capa vive fuera del esquema, con sus propios problemas de autoridad, concurrencia y consenso. Es la frontera exacta donde este nivel entrega el testigo a los relojes lógicos, a los CRDT y a los motores de sincronización del resto del track.

El segundo es la ausencia de tiempo y de autoría. El grafo dice qué contiene cada nodo y nada más: no dice quién lo escribió, ni cuándo, ni en qué orden se produjeron dos raíces distintas. Todo eso hay que añadirlo como datos dentro de los nodos —firmas, marcas causales, referencias a los padres— y esos datos serán verificables como contenido, pero su semántica la aporta la capa de arriba, no el hash.

Merece la pena señalar que ese puntero mutable concentra, él solo, casi todos los problemas difíciles que el grafo elimina. Quién tiene derecho a moverlo, qué ocurre si dos escritores lo mueven a la vez, cómo se propaga su nuevo valor y cómo sabe un lector que el valor que ve es el último son exactamente las preguntas de un sistema distribuido con estado compartido. El Merkle DAG no las resuelve, pero hace algo valioso: las reduce a un único dato diminuto, de modo que todo el aparato de consenso, firmas o convergencia se aplica sobre unas decenas de bytes en lugar de sobre la estructura entera.

El tercero es que no se puede consultar por valor. Con un identificador vas del nombre al contenido en un paso; con un criterio sobre el contenido no vas a ninguna parte, porque el hash destruye toda relación entre valores parecidos. Preguntar qué nodos tienen el campo autor igual a cierto valor exige un índice construido aparte, y ese índice es a su vez una estructura que hay que mantener, versionar y sincronizar. La estructura de índice que se acaba usando —un árbol de búsqueda cuyos nodos son bloques enlazados por hash— es en sí misma un ejercicio interesante, y el motivo de que existan bibliotecas dedicadas a ello.