Almacenamiento tipo Git en blockchain: versionado inmutable y descentralizado

Git y blockchain: cómo dos tecnologías independientes llegaron al mismo diseño

En abril de 2005, un programador finlandés llamado Linus Torvalds estaba furioso. El sistema que utilizaba para gestionar el código fuente de Linux —un proyecto en el que colaboraban miles de desarrolladores repartidos por todo el mundo— acababa de volverse inutilizable por una disputa de licencias. Torvalds tenía un problema muy concreto: necesitaba una herramienta que permitiera a miles de personas modificar millones de líneas de código simultáneamente, sin que nadie pudiera corromper el trabajo de los demás, sin depender de un servidor central que pudiera caerse, y sin que el sistema se volviera insoportablemente lento a medida que el proyecto creciera. En dos semanas —sí, dos semanas— Torvalds construyó la primera versión de Git, un sistema de control de versiones que cambiaría para siempre la forma en que se escribe software.

Tres años después, en octubre de 2008, una persona o grupo bajo el seudónimo de Satoshi Nakamoto publicó un documento de nueve páginas titulado Bitcoin: A Peer-to-Peer Electronic Cash System. El problema que Nakamoto intentaba resolver era completamente distinto al de Torvalds: quería crear dinero digital que funcionara sin bancos, sin gobiernos, sin ninguna autoridad central. Un sistema donde dos desconocidos en extremos opuestos del planeta pudieran intercambiar valor con la misma confianza con la que intercambian un billete en persona, pero sin necesidad de que nadie «garantice» la transacción. En enero de 2009, Nakamoto puso en marcha la red Bitcoin, y con ella nació la primera blockchain funcional.

Aquí es donde la historia se vuelve fascinante. Torvalds y Nakamoto nunca se conocieron. Trabajaban en problemas aparentemente inconexos: uno en gestión de código fuente, el otro en dinero digital. Y sin embargo, cuando examinas las entrañas de Git y las entrañas de Bitcoin, descubres que ambos llegaron a soluciones arquitectónicas casi idénticas. Los dos usan funciones hash criptográficas para identificar datos. Los dos organizan la información en estructuras de árbol que permiten verificar la integridad de enormes volúmenes de datos con operaciones mínimas. Los dos tratan los datos como inmutables: una vez que algo se registra, no se modifica ni se borra, solo se añaden nuevas versiones. Es como si dos ingenieros en continentes distintos, resolviendo problemas diferentes, hubieran descubierto independientemente que existe una forma óptima de organizar información cuando necesitas que sea verificable, resistente a manipulaciones y eficiente a escala.

Esta convergencia no es casualidad. Es consecuencia de las matemáticas subyacentes. Cuando tu prioridad es garantizar que los datos no han sido alterados, las funciones hash son la herramienta natural. Cuando necesitas verificar conjuntos grandes de datos de forma eficiente, los árboles de Merkle emergen como la estructura inevitable. Cuando quieres mantener un historial completo sin posibilidad de reescritura, la inmutabilidad se convierte en requisito, no en opción. Lo que este artículo explora no es la idea simplista de «meter Git dentro de una blockchain», sino algo mucho más profundo: cómo los principios arquitectónicos que hicieron de Git una herramienta revolucionaria —almacenamiento direccionado por contenido, grafos de versiones, instantáneas inmutables— resultan ser exactamente los principios que una blockchain de almacenamiento necesita para funcionar a escala. No es Git en blockchain. Son los principios de Git como arquitectura de blockchain.

¿Qué es un hash? El concepto fundamental explicado desde cero

Antes de hablar de Git, de blockchain o de cualquier estructura de datos sofisticada, necesitamos entender un concepto que es la piedra angular de todo lo que viene después: el hash. Si nunca has oído esta palabra en un contexto técnico, no te preocupes. Vamos a construir la intuición desde lo más básico.

Imagina que eres un notario y tu trabajo consiste en certificar documentos. Cada día llegan a tu despacho cientos de contratos, testamentos y escrituras. Tu misión es garantizar que nadie los altere después de que los firmes. En el mundo físico, usarías sellos de lacre, firmas holográficas y papel especial. Pero imagina que tuvieras una función matemática con las siguientes propiedades: metes un documento por una ranura, y la máquina escupe una cadena de caracteres —digamos, algo como a7f3b9c2e1d4...— que funciona como la «huella dactilar» de ese documento. Esa huella tiene varias características extraordinarias.

Primero, es determinista: si metes el mismo documento cien veces, la máquina produce exactamente la misma huella las cien veces. No hay aleatoriedad ni variación. Segundo, es prácticamente irreversible: dada la huella, es imposible reconstruir el documento original. No puedes meter la huella por la ranura y recuperar el contrato. Es como una picadora de carne: puedes meter un filete y obtener carne picada, pero no puedes meter carne picada y obtener un filete. Tercero, tiene lo que los criptógrafos llaman efecto avalancha: si cambias una sola coma en el documento —una coma, una tilde, un espacio—, la huella resultante es completamente diferente. No «un poco diferente» o «parecida pero no igual», sino radicalmente, irreconociblemente distinta. Es como si al cambiar una letra en tu nombre completo, tu huella dactilar biológica cambiara por completo.

Esa máquina imaginaria es, en esencia, una función hash criptográfica. En el mundo real, las más conocidas se llaman SHA-256 (que es la que usa Bitcoin) y BLAKE3 (que es la opción que nos parece más interesante hoy por ser más moderna y rápida). Las dos hacen lo mismo conceptualmente: toman cualquier cantidad de datos —desde una palabra hasta un archivo de varios gigabytes— y producen una cadena de longitud fija. En el caso de SHA-256, esa cadena siempre tiene 64 caracteres hexadecimales, sin importar si la entrada era un tweet de 280 caracteres o el texto completo de El Quijote.

¿Por qué importa la velocidad? Porque en una blockchain que procesa miles de transacciones por segundo, o en un sistema de archivos con millones de ficheros, calcular hashes es una operación que se repite constantemente. SHA-256 fue diseñado en 2001 y, aunque sigue siendo criptográficamente sólido, no fue optimizado para el hardware moderno. BLAKE3, publicado en 2020, puede ser hasta diez veces más rápido porque aprovecha la capacidad de los procesadores actuales de ejecutar múltiples operaciones en paralelo. Es la diferencia entre un coche fiable de hace veinte años y un modelo nuevo con el mismo motor pero mejor aerodinámica: ambos te llevan al mismo sitio, pero uno lo hace quemando mucha menos gasolina. En sistemas donde se calculan millones de hashes por minuto, esa diferencia de velocidad se traduce directamente en menor consumo de energía, menor coste de infraestructura y mayor capacidad de procesamiento.

El hash es, en definitiva, la herramienta que permite responder a una pregunta fundamental: ¿son estos datos exactamente iguales a los que tenía antes, sin que haya cambiado ni un solo bit? Esa pregunta, aparentemente sencilla, es la base sobre la que se construye todo lo demás.

Content-Addressable Storage: la biblioteca que organiza los libros por lo que dicen, no por dónde están

Para entender el almacenamiento direccionado por contenido, necesitamos primero entender cómo funciona el almacenamiento «normal» y por qué tiene problemas. Imagina una biblioteca municipal. Una biblioteca grande, con cientos de miles de libros repartidos en cinco plantas. Cuando donas un libro, la bibliotecaria lo examina, le asigna una ubicación —planta 3, estantería 47, balda 2, posición 15— y anota esa ubicación en una ficha del catálogo. Si quieres encontrar ese libro, necesitas consultar el catálogo, obtener la ubicación, subir a la tercera planta, localizar la estantería 47, buscar la balda 2 y contar hasta la posición 15. El libro es su ubicación. Si alguien lo mueve a otra estantería, la ficha del catálogo queda obsoleta y el libro se vuelve «invisible» para el sistema, aunque siga existiendo físicamente.

Este sistema tiene otros problemas menos obvios. Imagina que tres personas diferentes donan el mismo libro —digamos, tres ejemplares idénticos de Cien años de soledad—. La bibliotecaria, siguiendo su protocolo, asigna tres ubicaciones distintas y crea tres fichas en el catálogo. La biblioteca ahora tiene tres copias idénticas ocupando tres espacios, con tres fichas que mantener. Si mañana donan otros dos ejemplares, serán cinco copias. Y si multiplicas esto por los miles de títulos populares que se donan repetidamente, la biblioteca acaba dedicando una cantidad absurda de espacio y trabajo administrativo a almacenar y catalogar duplicados.

Ahora imagina una biblioteca que funciona de forma radicalmente distinta. Cuando llegas con un libro para donar, la bibliotecaria no mira la portada, no busca el autor en el catálogo, no le asigna una estantería. En lugar de eso, introduce el libro en una máquina —nuestra máquina de hashes del apartado anterior— que analiza cada palabra, cada página, cada punto y coma, y produce una huella única: b7e23fa91c.... Esa huella es la dirección del libro. No necesita estantería, ni balda, ni posición. El libro vive en la dirección que su propio contenido genera.

¿Qué ocurre cuando la segunda persona llega con otro ejemplar idéntico de Cien años de soledad? La máquina analiza el contenido, produce la misma huella —recordemos, la función hash es determinista— y la bibliotecaria dice: «Ya tenemos este libro. Su dirección es b7e23fa91c.... No necesitamos almacenar otra copia». Esto es la deduplicación: el sistema elimina automáticamente los duplicados sin que nadie tenga que comparar libros manualmente. En un sistema de archivos empresarial con millones de documentos —donde los mismos contratos plantilla, las mismas presentaciones corporativas y las mismas políticas internas se copian y recopian entre departamentos—, la deduplicación puede reducir el almacenamiento necesario en un 60 o un 70 por ciento.

Pero hay otra ventaja igualmente poderosa: la verificación de integridad gratuita. Imagina que te preocupa que alguien haya alterado un documento almacenado en este sistema. En la biblioteca tradicional, tendrías que sacar el libro, compararlo página a página con una copia de referencia —si es que tienes una— y rezar para no saltarte ninguna diferencia. En la biblioteca direccionada por contenido, la verificación es trivial: tomas el documento, lo pasas por la función hash y comparas la huella resultante con la dirección almacenada. Si coinciden, el documento no ha sido alterado. Si no coinciden, alguien lo ha modificado. La operación tarda milisegundos, no importa si el documento tiene diez páginas o diez mil.

Ahora imagina que esta biblioteca no es un edificio aislado, sino una red de bibliotecas repartidas por todo el país. Cuando alguien en Sevilla quiere un libro que fue donado en Barcelona, no necesita saber en qué biblioteca de Barcelona está, ni en qué planta o estantería. Solo necesita la huella —la dirección derivada del contenido— y cualquier biblioteca de la red que tenga ese contenido puede proporcionárselo. Si la biblioteca de Sevilla ya tiene una copia, perfecto; si no, la descarga de la más cercana que la tenga. Y cuando la recibe, puede verificar instantáneamente que lo que recibió es exactamente lo que pidió, porque la huella del contenido recibido debe coincidir con la dirección solicitada. Esto es, en esencia, lo que hacen tanto Git como las blockchains de almacenamiento, y es el concepto que los criptógrafos y los ingenieros de sistemas llaman Content-Addressable Storage (CAS).

Blobs, Trees y Commits: las tres piezas de Git explicadas para cualquier persona

Blobs: el sobre sellado que solo contiene lo que importa

Imagina que estás organizando un archivo de documentos para una empresa. Tienes un contrato de alquiler que se llama contrato_oficina_madrid.pdf. En un sistema de archivos normal, ese documento es inseparable de su nombre y de su ubicación: vive en la carpeta Contratos/2024/Madrid/, se llama de una forma específica, y si lo mueves a otra carpeta o le cambias el nombre, para el sistema es «otro archivo», aunque el contenido sea idéntico.

Git hace algo diferente. Cuando Git almacena ese contrato, lo primero que hace es separar completamente el contenido del nombre y la ubicación. Toma el contenido puro —los bytes que forman el documento—, calcula su hash, y lo almacena en lo que llama un blob (del inglés binary large object, literalmente «objeto binario grande»). Un blob es como un sobre sellado que contiene un documento, pero en cuyo exterior solo aparece la huella dactilar del contenido. No dice cómo se llama el documento, ni en qué carpeta estaba, ni quién lo creó. Solo contiene el dato puro y su huella.

¿Por qué es esto útil? Porque si tienes diez carpetas distintas con diez copias del mismo contrato —algo muy habitual en entornos empresariales—, Git almacena un solo blob. Los diez «archivos» apuntan al mismo sobre sellado. Cuando alguien modifica una de las copias, Git crea un nuevo blob para esa versión modificada, pero las otras nueve siguen apuntando al blob original. El ahorro de espacio es enorme, pero lo más importante no es el espacio: es la garantía de integridad. Cada blob es inmutable. Una vez sellado, su contenido no puede cambiar sin que la huella —y por tanto su dirección— cambie también. Es como si el sobre tuviera un precinto que se rompe visiblemente al abrirlo.

En el contexto de una blockchain de almacenamiento, los blobs funcionan exactamente igual. Cada fragmento de datos —un documento, una transacción, un registro— se almacena como un blob identificado por su hash. Si dos usuarios en extremos opuestos de la red almacenan el mismo archivo, la red solo necesita guardar una copia. Y cualquier nodo puede verificar que el blob que recibió es auténtico simplemente recalculando su hash.

Trees: el índice que sabe dónde vive cada cosa

Si los blobs son los sobres sellados con documentos, ¿quién lleva la cuenta de cómo se llaman esos documentos y en qué carpetas están organizados? Para eso existen los trees (árboles). Un tree es como el índice de un libro, pero con una particularidad: cada entrada del índice no dice «capítulo 3, página 47», sino que apunta directamente al contenido del capítulo. Es la diferencia entre un índice que te dice «busca en la página 47» y uno que, al señalar la entrada, te materializa el capítulo entero delante.

En términos concretos, un tree es una lista de entradas donde cada entrada contiene tres cosas: un nombre (el nombre del archivo o la subcarpeta), un tipo (si es un blob o es otro tree, lo que equivale a decir «es un archivo» o «es una carpeta que contiene más cosas»), y un hash que apunta al blob o tree correspondiente. Un tree puede contener otros trees dentro, exactamente como una carpeta puede contener subcarpetas. Y lo crucial es que el propio tree tiene su hash, calculado a partir de todo su contenido —es decir, a partir de todos los nombres, tipos y hashes que contiene—.

Esto crea una propiedad extraordinaria. Si cambias el contenido de un solo archivo en lo más profundo de una estructura de carpetas, el blob de ese archivo cambia (nuevo contenido, nuevo hash). Pero como el tree que lo contiene ahora apunta a un hash diferente, el propio tree también cambia de hash. Y el tree que contiene a ese tree también cambia. Y así sucesivamente, hacia arriba, hasta llegar al tree raíz —el tree que representa la carpeta principal de todo el proyecto—. Es como una cadena de fichas de dominó: al caer la primera, todas las demás caen en secuencia. En la práctica, esto significa que el hash del tree raíz funciona como un resumen de todo el estado del sistema de archivos. Si dos personas tienen el mismo hash raíz, puedes estar absolutamente seguro de que tienen exactamente los mismos archivos, con los mismos nombres, en las mismas carpetas, con el mismo contenido, bit por bit. Una sola diferencia en cualquier punto produciría un hash raíz completamente distinto.

Commits: la foto instantánea firmada y fechada

Imagina que eres fotógrafo forense y tu trabajo consiste en documentar escenas para que nadie pueda negar cómo estaban las cosas en un momento dado. Llegas a un despacho, colocas tu cámara y tomas una foto que captura cada papel sobre la mesa, cada carpeta en el archivador, cada post-it en la pantalla del ordenador. Después, sellas la foto con tu firma, la fecha y hora exactas, y una descripción: «Estado del despacho del director financiero, 14 de marzo de 2026, 09:47. Reorganización de documentos tras auditoría externa». Además —y esto es clave— pegas en la esquina de tu foto una miniatura de la foto anterior que tomaste, de modo que cualquier persona puede seguir la cadena de fotos hacia atrás y reconstruir la evolución completa del despacho.

Eso es exactamente lo que hace un commit en Git. Un commit contiene cuatro cosas: un puntero al tree raíz (la «foto» del estado completo en ese momento), un puntero al commit anterior (la «miniatura de la foto previa»), metadatos (quién hizo el commit, cuándo, y un mensaje describiendo qué cambió), y su propio hash, calculado a partir de todo lo anterior. Cada commit es, por tanto, una instantánea inmutable del estado completo del sistema en un momento dado, enlazada con la instantánea anterior, formando una cadena que permite recorrer toda la historia hacia atrás.

En una blockchain, los bloques funcionan de forma análoga a los commits. Cada bloque contiene un conjunto de transacciones (el equivalente al tree con los cambios), un puntero al bloque anterior (el hash del bloque precedente), metadatos (marca temporal, información del validador), y su propio hash. La cadena de bloques —la blockchain, literalmente— es una cadena de instantáneas enlazadas, donde cada eslabón valida al siguiente y cualquier intento de alterar un eslabón pasado rompe toda la cadena desde ese punto en adelante.

La propagación de cambios que describimos en la sección de trees cobra aquí todo su sentido. Cuando un solo archivo cambia, se crea un nuevo blob, que provoca un nuevo tree, que provoca un nuevo tree padre, que provoca un nuevo tree raíz, que queda registrado en un nuevo commit. Es como una cadena de fichas de dominó perfectamente alineadas: al empujar la primera —el archivo modificado—, la onda se propaga inevitablemente hasta la última —el commit—. Y esa propagación es lo que garantiza que cualquier alteración, por pequeña que sea, queda reflejada de forma visible e inequívoca en el hash raíz.

Merkle Patricia Trie: cómo verificar millones de registros sin revisar ninguno

Hasta aquí hemos visto cómo los hashes permiten identificar datos y cómo los trees organizan esa información en estructuras jerárquicas. Pero hay un problema que todavía no hemos abordado: la escala. Imagina una base de datos con cien millones de registros —las cuentas de todos los usuarios de una red blockchain, por ejemplo—. Si quieres verificar que un registro concreto no ha sido alterado, ¿tienes que revisar los cien millones? Obviamente, eso sería inviable. Necesitas una estructura que te permita verificar cualquier registro individual examinando solo una fracción minúscula del total. Esa estructura es el Merkle Patricia Trie.

Para entender cómo funciona, piensa en un árbol genealógico. No un árbol genealógico cualquiera, sino uno con propiedades especiales. Imagina una familia con millones de miembros repartidos por todo el mundo. El patriarca original está en la cima del árbol. Debajo de él, sus hijos. Debajo de cada hijo, sus nietos. Y así sucesivamente, generación tras generación, hasta llegar a los miembros actuales de la familia, que son las «hojas» del árbol. Ahora imagina que cada miembro del árbol lleva una pulsera con un código especial. El código de cada persona se calcula a partir de los códigos de todos sus hijos. Si un hijo cambia su código, el código del padre cambia automáticamente. Y si el código del padre cambia, el código del abuelo también. Esta cascada de cambios se propaga hacia arriba hasta llegar al patriarca. Resultado: el código del patriarca resume, en una sola cadena de caracteres, el estado de toda la familia. Si un solo miembro, en cualquier rincón del árbol, modifica su información, el código del patriarca cambia.

Esa es la idea fundamental de un árbol de Merkle, inventado por Ralph Merkle en 1979. Pero una blockchain como Ethereum necesita algo más sofisticado que un árbol de Merkle básico. Necesita poder buscar registros eficientemente (no solo verificarlos), actualizar registros individuales sin reconstruir todo el árbol, y demostrar que un registro no existe (no solo que existe). Para todo esto, Ethereum usa una variante llamada Merkle Patricia Trie, que combina las propiedades de verificación del árbol de Merkle con la capacidad de búsqueda de una estructura llamada «trie» (que, pese a pronunciarse como try, viene de retrieval, «recuperación»).

El Merkle Patricia Trie tiene tres tipos de nodos, y cada uno cumple una función específica. Los nodos hoja son los que contienen los datos reales —en Ethereum, por ejemplo, el saldo de una cuenta, su código si es un contrato inteligente, o su número de transacciones—. Son las personas actuales de nuestro árbol genealógico, los miembros vivos de la familia. Los nodos rama son los puntos de bifurcación, los ancestros que tuvieron varios hijos. Cada nodo rama puede tener hasta 16 hijos (uno por cada carácter hexadecimal: 0-9 y a-f), y su hash se calcula a partir de los hashes de todos sus hijos, exactamente como el código de la pulsera del patriarca. Los nodos extensión son un atajo inteligente: cuando una secuencia de nodos rama solo tiene un hijo cada uno (una cadena de ancestros con un solo descendiente), el sistema los comprime en un solo nodo que dice «salta directamente desde aquí hasta allá», ahorrando espacio y acelerando las búsquedas.

Pero quizá la propiedad más elegante del Merkle Patricia Trie es lo que los ingenieros llaman structural sharing, que se entiende mejor con una analogía. Imagina que nuestro árbol genealógico tiene un millón de miembros, y uno de ellos —un primo lejano en la rama más remota— cambia de dirección. En un sistema ingenuo, tendrías que reimprimir todo el árbol genealógico para reflejar ese cambio. Pero con structural sharing, solo necesitas actualizar al primo, a su padre, a su abuelo, y así hacia arriba hasta el patriarca. El resto de la familia —todas las demás ramas, todos los demás primos, tíos y sobrinos— permanecen exactamente igual y no necesitan tocarse. En un árbol con un millón de hojas, actualizar un registro requiere modificar unos 20 nodos (la profundidad del árbol), no un millón. Es la diferencia entre reparar una sola rama de un árbol sin tocar las demás y talar el árbol entero para plantar uno nuevo. En términos técnicos, eso se expresa diciendo que las operaciones tienen complejidad «logarítmica»: el esfuerzo crece proporcionalmente al número de niveles del árbol, no al número de hojas. Duplicar el número de registros solo añade un nivel más de profundidad.

Namespaced Merkle Trees: cuando cada departamento necesita su propia verificación

Antes de explicar qué es un Namespaced Merkle Tree, necesitamos entender un concepto previo: los namespaces. La palabra es inglesa y significa literalmente «espacios de nombres», pero la idea es mucho más intuitiva de lo que el término sugiere. Piensa en un gran edificio de oficinas que alberga a veinte empresas diferentes. Todas comparten el mismo edificio, el mismo ascensor, el mismo vestíbulo. Pero cada empresa tiene su propia planta, su propia recepción y sus propias llaves. Un empleado de la empresa de la tercera planta no puede acceder a los archivos de la empresa de la séptima planta, ni necesita hacerlo. Cada empresa opera en su propio «espacio» dentro del edificio compartido. Eso es un namespace: una partición lógica que permite a múltiples entidades coexistir en un sistema compartido sin interferir entre sí.

En las blockchains modulares como Celestia, los namespaces son esenciales. Celestia no es una blockchain «todo en uno» como Ethereum; es una capa especializada que solo se encarga de almacenar datos y garantizar que están disponibles. Múltiples aplicaciones —cada una como una de las empresas de nuestro edificio de oficinas— publican sus datos en Celestia, y cada aplicación tiene su propio namespace. La aplicación de pagos publica sus transacciones en el namespace de pagos. La aplicación de identidad digital publica sus registros en el namespace de identidad. Comparten la misma infraestructura, pero sus datos están lógicamente separados.

Ahora, ¿por qué no basta con un árbol de Merkle normal para esto? Porque un árbol de Merkle normal te permite verificar que un dato concreto existe en el árbol, pero no te permite pedir «dame todos los datos del namespace X y demuéstrame que no te has dejado ninguno». Imagina que eres la empresa de la tercera planta y quieres auditar tus propios archivos. Con un árbol de Merkle normal, podrías verificar que cada archivo individual es auténtico, pero no podrías estar seguro de que no hay archivos ocultos que deberían estar en tu espacio y no te han mostrado. Un Namespaced Merkle Tree (NMT) resuelve este problema añadiendo a cada nodo del árbol información sobre los namespaces que contiene: cada nodo registra el namespace mínimo y máximo de los datos que cuelgan de él. Esto permite una propiedad llamada completitud: puedes solicitar todos los datos de un namespace específico y obtener una prueba criptográfica de que la respuesta es completa, de que no se ha omitido nada.

¿Y por qué importa esto? Por los light clients, un concepto crucial que merece explicación. Cuando piensas en una red blockchain, probablemente imaginas ordenadores potentes ejecutando software complejo las veinticuatro horas del día. Esos son los «nodos completos», y efectivamente necesitan descargar, almacenar y verificar cada dato de la red. Pero no todo el mundo puede o quiere ejecutar un nodo completo. Tu teléfono móvil, por ejemplo, no tiene la capacidad de almacenar terabytes de datos blockchain. Un light client es una versión ligera que no descarga todo, sino que pide solo los datos que necesita y confía en pruebas criptográficas para verificar que esos datos son correctos. Es como la diferencia entre un auditor que revisa todos los libros de contabilidad de una empresa (nodo completo) y uno que pide solo las facturas de un trimestre específico junto con un certificado firmado por el auditor principal que garantiza que esas facturas son todas las que hay (light client con prueba de completitud).

Los NMT son especialmente relevantes en el contexto de Data Availability Sampling (DAS), una técnica que permite a los light clients verificar que los datos de un bloque están realmente disponibles sin descargar el bloque entero. La idea es elegantemente simple: en lugar de descargar todo un bloque de, digamos, un megabyte, el light client descarga unas pocas muestras aleatorias y verifica que son consistentes. Es como comprobar que una sandía está madura probando unos pocos trocitos en lugar de cortarla entera. Para que las pruebas matemáticas de DAS funcionen, los datos se codifican usando una técnica avanzada llamada compromisos KZG, que permite demostrar propiedades de los datos sin revelar los datos mismos —una especie de sobre cerrado que puedes pesar para verificar que contiene el número correcto de páginas sin necesidad de abrirlo—. Esta combinación de NMT, DAS y KZG es lo que permite a blockchains como Celestia escalar a volúmenes de datos que serían imposibles si cada participante tuviera que descargar y verificar todo.

Almacenamiento híbrido local + IPFS: el archivo, el despacho y el almacén

Antes de hablar de almacenamiento híbrido, necesitamos entender qué es IPFS, porque es una pieza fundamental del rompecabezas. IPFS (InterPlanetary File System, o Sistema de Archivos Interplanetario —un nombre ambicioso, sin duda—) es una red descentralizada para almacenar y compartir archivos. La idea central es que, en lugar de acceder a un archivo pidiéndoselo a un servidor específico («descarga este archivo del servidor de Google»), lo pides a la red entera usando el hash de su contenido («quiero el archivo cuyo hash es Qm7x3f..., me da igual quién me lo envíe»). Cualquier nodo de la red que tenga ese archivo puede proporcionártelo, y tú puedes verificar que lo que recibiste es auténtico simplemente recalculando el hash.

Es como la diferencia entre comprar un libro en una librería específica de la ciudad (modelo centralizado: si la librería cierra, te quedas sin libro) y pedirlo en una red de trueque donde cualquier persona que tenga un ejemplar puede hacértelo llegar (modelo descentralizado: mientras alguien en la red tenga el libro, puedes obtenerlo). Además, como usas el hash para identificar el libro, no importa quién te lo envíe: si el hash coincide, el contenido es correcto.

Ahora bien, ni el almacenamiento puramente local ni el almacenamiento puramente en IPFS son óptimos por sí solos. El almacenamiento local es rápido pero vulnerable: si tu disco duro falla, tus datos desaparecen. El almacenamiento en IPFS es resiliente pero lento: pedir un archivo a la red puede tardar segundos, lo cual es inaceptable para una blockchain que procesa miles de operaciones por segundo. La solución es un modelo híbrido que combina lo mejor de ambos mundos, y para entenderlo, sirve una analogía extendida.

Imagina que diriges un despacho de abogados. Tienes tres niveles de almacenamiento de documentos. Primero, el escritorio: los expedientes en los que estás trabajando ahora mismo, a mano, accesibles en un segundo. Es rápido, pero el espacio es limitado —tu escritorio solo cabe una cierta cantidad de carpetas—. Segundo, el archivo del despacho: un armario con los expedientes del último año, accesibles en un par de minutos. Tiene más capacidad que el escritorio, pero menos velocidad. Tercero, el almacén externo: un depósito en las afueras de la ciudad donde guardas todos los expedientes históricos. Prácticamente infinito en capacidad, pero recuperar un expediente puede llevar horas o incluso un día.

El almacenamiento híbrido local + IPFS funciona con una lógica similar, y las estrategias más comunes se pueden mapear directamente a esta analogía. La primera estrategia es el almacenamiento en caliente: los datos de los últimos bloques (las últimas horas o días) se mantienen localmente, en el «escritorio», para acceso instantáneo. La segunda es el archivado progresivo: a medida que los datos envejecen, se mueven al «archivo del despacho» (un almacenamiento local comprimido) y eventualmente al «almacén externo» (IPFS), donde quedan disponibles para quien los necesite pero no ocupan espacio local. La tercera es la replicación selectiva: no todos los nodos de la red almacenan todo. Los nodos especializados en un namespace concreto almacenan localmente los datos de ese namespace, y para el resto consultan IPFS. Es como un despacho de abogados especializado en derecho laboral que mantiene a mano los expedientes laborales pero guarda los de otras áreas en el almacén. La cuarta estrategia es el pinning incentivado: en IPFS, los datos solo permanecen disponibles mientras algún nodo los «pinea» (los retiene activamente). La blockchain puede crear incentivos económicos —recompensas en tokens— para que ciertos nodos mantengan pineados los datos históricos, garantizando su disponibilidad a largo plazo.

¿Por qué es este modelo superior a usar solo almacenamiento local o solo IPFS? Porque equilibra tres requisitos que están en tensión permanente: velocidad (acceso instantáneo a datos recientes), resiliencia (los datos no desaparecen si un nodo falla) y eficiencia económica (no pagas por mantener localmente datos que rara vez se consultan). Es la misma lógica que aplica cualquier organización sensata: no guardarías todos los documentos de los últimos treinta años encima de tu escritorio, pero tampoco mandarías al almacén externo el contrato que necesitas firmar esta tarde.

Versionado no destructivo: el cuaderno donde nunca arrancas páginas

Imagina un cuaderno muy especial. Es el cuaderno donde un científico registra todos sus experimentos. Cada día escribe lo que hizo, qué resultados obtuvo, qué conclusiones sacó. Pero este cuaderno tiene una regla inquebrantable: nunca se arranca una página. Si el científico comete un error, no lo tacha ni lo borra. En lugar de eso, escribe una nueva entrada que dice: «La entrada del martes 12 contenía un error en la columna de temperatura. Los valores correctos son los siguientes...». La entrada errónea sigue ahí, legible, pero la nueva entrada la corrige. Si alguien quiere saber qué decían los datos antes de la corrección, solo tiene que ir a la página original. Si quiere saber los datos actuales, va a la última corrección. Toda la historia está ahí, completa, sin borrones ni vacíos.

Este cuaderno es mucho más que una anécdota: es una práctica real y obligatoria en laboratorios de investigación, y por una razón fundamental. Si permites borrar o sobrescribir datos, pierdes la capacidad de reconstruir lo que ocurrió realmente. Un hallazgo de hace tres años puede resultar crucial hoy, y si los datos originales fueron sobrescritos, es imposible verificar si eran correctos. Lo mismo ocurre en contabilidad (los asientos contables nunca se borran; los errores se corrigen con contraasientos), en derecho (las escrituras públicas se modifican con escrituras complementarias, no borrando las anteriores) y en medicina (el historial clínico de un paciente es acumulativo: las entradas se añaden, no se sustituyen).

El versionado no destructivo aplica esta misma filosofía al almacenamiento digital. En un sistema con versionado no destructivo, cuando modificas un archivo, el sistema no sobrescribe la versión anterior. En lugar de eso, crea una nueva versión con un nuevo hash, y registra un enlace entre la versión nueva y la anterior. La cadena de versiones es como la cadena de entradas en el cuaderno del científico: cada versión apunta a la anterior, y puedes recorrer la cadena hacia atrás hasta llegar a la primera versión. Git hace exactamente esto con su cadena de commits. Cada commit es una instantánea completa del estado del proyecto, enlazada con la instantánea anterior. Si quieres saber cómo estaba un archivo hace seis meses, recorres la cadena de commits hasta esa fecha. El archivo actual y todas sus versiones anteriores coexisten en el repositorio.

En el contexto de una blockchain de almacenamiento, el versionado no destructivo no es solo una buena práctica: es una propiedad estructural. La inmutabilidad de la blockchain garantiza que, una vez que un dato se registra, no puede ser borrado ni alterado. Cada actualización es un nuevo registro que referencia al anterior, formando una cadena cronológica indestructible. Y esta propiedad tiene implicaciones prácticas enormes, especialmente en el ámbito del cumplimiento normativo y la auditoría.

Imagina este escenario: un regulador financiero sospecha que una empresa de inversión manipuló datos de clientes hace tres años para ocultar operaciones irregulares. En un sistema de almacenamiento tradicional, donde los datos pueden sobrescribirse, la investigación es una pesadilla. La empresa podría haber alterado los registros después del hecho, y demostrar que lo hizo requiere análisis forenses costosos y a menudo inconclusivos. Pero si los datos de la empresa estuvieran almacenados en un sistema con versionado no destructivo respaldado por blockchain, el regulador tendría un camino claro: recorrer la cadena de versiones hasta el momento en cuestión y obtener una copia verificable de los datos tal como existían en esa fecha. No como la empresa dice que existían, no como una reconstrucción a partir de copias de seguridad que podrían haber sido manipuladas, sino como existían realmente, con una prueba criptográfica irrefutable de que esos datos no han sido alterados desde que se registraron. El hash de cada versión, enlazado con el hash de la versión anterior y registrado en la blockchain, forma una cadena de custodia digital que un tribunal puede verificar matemáticamente.

DAG de consenso: la autopista que permite circular en paralelo

Hasta ahora hemos hablado de «cadenas» de bloques como si fueran una secuencia lineal: bloque 1, luego bloque 2, luego bloque 3, uno detrás de otro, como los vagones de un tren. Y de hecho, así funcionan Bitcoin y muchas otras blockchains. Pero esta linealidad tiene un problema serio: es un cuello de botella. Si solo puedes añadir un bloque a la vez, la velocidad del sistema está limitada por el tiempo que tarda en producirse y validarse cada bloque. Es como una carretera de un solo carril: no importa cuántos coches quieran circular, solo puede pasar uno a la vez.

Para entender la alternativa, primero necesitamos un concepto nuevo: el DAG, siglas de Directed Acyclic Graph, o grafo acíclico dirigido. «Grafo» suena intimidante, pero la idea es simple. Un grafo es un conjunto de puntos (nodos) conectados por líneas (aristas). Piensa en un mapa de carreteras: las ciudades son los nodos, las carreteras son las aristas. «Dirigido» significa que las conexiones tienen dirección, como calles de un solo sentido: puedes ir de A a B, pero no necesariamente de B a A. «Acíclico» significa que no hay ciclos, no hay rutas circulares: si sales de un punto, es imposible volver a él siguiendo la dirección de las flechas. Es como un río con afluentes: el agua fluye siempre hacia abajo, los afluentes se unen al cauce principal, pero el agua nunca vuelve hacia arriba.

Ahora imagina que, en lugar de una carretera de un solo carril, tienes una autopista con múltiples carriles. Varios coches pueden circular simultáneamente, cada uno en su carril. De vez en cuando, los carriles convergen en un peaje donde se registra qué coches pasaron. Pero a diferencia de una autopista normal, donde los coches son independientes entre sí, en esta autopista especial cada coche lleva una nota que dice «vi al coche azul y al coche rojo antes de entrar a mi carril». Esas notas crean una red de referencias cruzadas que permite reconstruir el orden aproximado en que los coches entraron a la autopista, sin necesidad de que circularan en fila india.

Esto es lo que hace un DAG de consenso. En lugar de producir bloques secuencialmente, múltiples validadores producen bloques simultáneamente, cada uno en su propio «carril». Cada bloque referencia a uno o más bloques anteriores de otros validadores, creando una red de dependencias que forma un DAG. El resultado es un sistema que puede procesar muchas más transacciones por unidad de tiempo, porque no tiene el cuello de botella de la secuencialidad.

Dos protocolos que implementan esta idea son Narwhal y Bullshark, desarrollados por ingenieros que trabajaron en el proyecto Diem de Meta (antes Facebook). Para entenderlos sin entrar en complejidades matemáticas, piensa en una asamblea parlamentaria. Narwhal es el sistema de distribución de documentos: se encarga de que cada parlamentario reciba las propuestas de todos los demás de forma ordenada y verificable. No decide qué propuestas se aprueban; solo garantiza que todos han visto las mismas propuestas. Bullshark es el sistema de votación: toma los documentos que Narwhal distribuyó y establece un orden definitivo mediante un protocolo de votación que funciona incluso si algunos parlamentarios son malintencionados o están desconectados. La separación de responsabilidades —Narwhal distribuye, Bullshark ordena— es lo que hace al sistema tan eficiente.

¿Por qué un DAG es más rápido que una cadena lineal? Volvamos a la analogía de la autopista. En una carretera de un solo carril, si un coche se detiene, todos los que vienen detrás se detienen también. En una autopista de seis carriles, un coche detenido en el carril 3 solo afecta al carril 3; los demás siguen circulando. Del mismo modo, en un DAG, si un validador es lento o se desconecta, los demás validadores siguen produciendo bloques en sus propios «carriles». El sistema degrada su rendimiento de forma proporcional al número de validadores afectados, en lugar de detenerse por completo como ocurriría en una cadena lineal. En pruebas reales, protocolos basados en DAG han demostrado capacidades de procesamiento de más de 100.000 transacciones por segundo, frente a las 7 de Bitcoin o las 15-30 de Ethereum en su capa base.

Snapshots: la partida guardada que te ahorra empezar desde el principio

Si alguna vez has jugado a un videojuego largo —un RPG de cincuenta horas, por ejemplo—, conoces el concepto de «partida guardada». Cuando guardas la partida, el juego captura el estado completo en ese instante: tu posición en el mapa, tu inventario, tus puntos de vida, las misiones completadas, las decisiones que tomaste. Si mañana quieres continuar, cargas la partida guardada y retomas exactamente donde lo dejaste, sin necesidad de volver a jugar las cincuenta horas anteriores.

Ahora imagina que no existieran las partidas guardadas. Cada vez que enciendes la consola, tendrías que empezar desde el principio y volver a jugar todo, decisión por decisión, batalla por batalla, hasta llegar al punto donde estabas. Absurdo, ¿verdad? Pues eso es exactamente lo que le pasa a un nodo nuevo que se une a una red blockchain sin snapshots.

Cuando un nodo nuevo se conecta a la red Bitcoin, por ejemplo, necesita descargar y verificar todos los bloques desde el primero, el llamado «bloque génesis» de enero de 2009. Eso son más de quince años de transacciones, cientos de gigabytes de datos, y días o incluso semanas de procesamiento. Es como decirle a un nuevo jugador: «Para jugar con nosotros, primero tienes que rejugar toda la historia del juego desde el primer segundo». A medida que la blockchain crece, este problema se agrava: cada año hay más historia que reproducir, y el coste de unirse a la red aumenta continuamente.

Un snapshot (instantánea) resuelve este problema de la misma forma que una partida guardada. Periódicamente, la red produce una instantánea del estado completo: los saldos de todas las cuentas, el código de todos los contratos, los datos de todos los registros. Esa instantánea se comprime (el equivalente a que el juego guarde la partida en un archivo pequeño en lugar de grabar un vídeo de las cincuenta horas de juego), se verifica criptográficamente (el hash de la instantánea se registra en la blockchain para que cualquiera pueda confirmar que es auténtica) y se distribuye por la red.

Cuando un nodo nuevo se une, descarga la última instantánea en lugar de reproducir toda la historia. Es lo que los ingenieros llaman fast sync: en lugar de tardar días o semanas, el nodo puede estar operativo en minutos u horas. El nodo confía en la instantánea porque puede verificar su hash contra el consenso de la red —si la mayoría de los validadores están de acuerdo en que ese hash es correcto, la instantánea es legítima—. Y si alguien necesita los datos históricos anteriores al snapshot, puede obtenerlos de nodos archivadores o de IPFS, pero no necesita procesarlos para empezar a operar.

La compresión de los snapshots merece una mención especial. Un estado que «en crudo» podría ocupar cientos de gigabytes se puede comprimir significativamente eliminando redundancias. Recordemos que, gracias al structural sharing del Merkle Patricia Trie, gran parte del estado está compartido entre versiones sucesivas. Un snapshot inteligente aprovecha esta propiedad para almacenar solo la «diferencia neta» desde el snapshot anterior, más un mapeo completo del estado actual. Es como un videojuego que guarda la partida almacenando solo «qué cambió desde la última vez» en lugar de grabar todo el estado del mundo virtual desde cero.

Casos de uso: cinco historias reales de almacenamiento tipo Git en blockchain

Auditoría financiera: el banco que no podía esconder nada

María es inspectora del regulador financiero. Su trabajo consiste en investigar bancos sospechosos de prácticas irregulares. Hasta ahora, cada investigación era una batalla: los bancos entregaban montañas de documentos en formatos dispares, faltaban registros clave que misteriosamente se habían «perdido» durante una migración de sistemas, y los análisis forenses de bases de datos costaban cientos de miles de euros sin garantía de resultados concluyentes. Los abogados de los bancos se escudaban en la imposibilidad técnica de demostrar cuándo se habían modificado ciertos registros.

Ahora imagina que el regulador exige a los bancos almacenar ciertos registros en un sistema con versionado no destructivo sobre blockchain. Cada transacción, cada modificación de datos de un cliente, cada aprobación de un crédito queda registrada como un commit en una estructura tipo Git, con su hash, su marca temporal y su enlace a la versión anterior. Cuando María investiga una irregularidad que supuestamente ocurrió hace tres años, no necesita confiar en lo que el banco le entrega. Recorre la cadena de commits hasta la fecha en cuestión y obtiene el estado exacto de los datos en ese momento, verificado criptográficamente. Si el banco alteró datos después del hecho, la cadena de hashes lo revela: los hashes de los nodos modificados no coinciden con los que se registraron en la blockchain en la fecha original.

La investigación, que antes tardaba meses y costaba una fortuna, se resuelve en días. Y lo más importante: el resultado es matemáticamente verificable. No es la opinión de un perito informático contra la de otro. Es una prueba criptográfica que cualquier tribunal puede verificar independientemente, ejecutando las mismas funciones hash sobre los mismos datos y comprobando que los resultados coinciden.

Cadena de suministro: del campo al supermercado sin puntos ciegos

Carlos compra en el supermercado una bolsa de café que dice «origen: cooperativa de comercio justo en Colombia». ¿Cómo puede saber si es verdad? Hoy, la respuesta honesta es: no puede. Las certificaciones de origen dependen de cadenas de custodia documentales donde cada intermediario —el agricultor, el procesador, el exportador, el importador, el distribuidor, el supermercado— emite sus propios certificados. Un fraude en cualquier eslabón es difícil de detectar porque cada intermediario solo ve su parte de la cadena.

Con almacenamiento tipo Git sobre blockchain, cada paso de la cadena de suministro se registra como un commit en un repositorio compartido. El agricultor en Colombia registra la cosecha: fecha, cantidad, finca de origen. El procesador registra la recepción del grano, el proceso de tostado, el peso resultante. El exportador registra el envío, el número de contenedor, la fecha de salida. Y así hasta que el café llega al supermercado. Cada registro tiene su hash, enlazado con el anterior, formando una cadena de custodia digital inmutable. Además, cada participante opera en su propio namespace, de modo que puede verificar la información relevante para su eslabón sin necesidad de acceder a datos confidenciales de otros participantes.

Carlos, con su teléfono móvil, escanea un código QR en la bolsa de café. Su teléfono, funcionando como un light client, solicita la prueba de Merkle correspondiente a ese lote y verifica, en segundos, que la cadena de custodia es coherente y completa desde la finca en Colombia hasta la estantería del supermercado. No necesita confiar en ningún intermediario. Las matemáticas le garantizan que los datos son auténticos.

Propiedad intelectual: la canción que existía antes del litigio

Elena es compositora. Escribe canciones en su habitación y las comparte con productores que, a veces, las modifican sustancialmente antes de publicarlas. En dos ocasiones, productores publicaron versiones de sus canciones sin darle crédito ni pagarle royalties. Cuando Elena reclamó, los productores alegaron que las similitudes eran «coincidencia» y que habían compuesto las canciones independientemente. Elena no tenía forma de demostrar que sus versiones originales existían antes que las versiones publicadas. Los registros de propiedad intelectual tradicionales son lentos y caros, y registrar cada borrador de cada canción es impracticable.

Con un sistema de almacenamiento tipo Git sobre blockchain, Elena registra cada versión de cada canción como un blob, con su hash calculado a partir del contenido musical. Cada vez que modifica una canción —cambia una melodía, reescribe una letra, ajusta un arreglo—, crea un nuevo commit que enlaza con la versión anterior. La marca temporal de cada commit queda registrada en la blockchain, creando una prueba cronológica irrefutable. Cuando el productor publica su versión «independiente», Elena puede demostrar que su versión original existía —con un hash verificable en la blockchain— meses antes de que el productor tuviera acceso a ella. No es su palabra contra la del productor: es una prueba criptográfica con marca temporal inmutable.

Pero el sistema va más allá de la protección reactiva. Elena puede compartir borradores con productores a través de la red, manteniendo un registro inmutable de quién accedió a qué versión y cuándo. Si un productor modifica la canción, las modificaciones quedan registradas como nuevos commits que referencian al commit original de Elena, creando un árbol de derivaciones que documenta con precisión quién contribuyó qué a la versión final. La atribución de autoría deja de ser una cuestión de buena fe y se convierte en un hecho verificable.

Datos científicos: el experimento que cualquiera puede reproducir

La crisis de reproducibilidad es uno de los mayores problemas de la ciencia contemporánea. Estudios publicados en revistas prestigiosas resultan ser irreproducibles cuando otros investigadores intentan replicarlos. Las causas son múltiples: datos perdidos, protocolos experimentales descritos de forma ambigua, análisis estadísticos que fueron ajustados retrospectivamente para obtener resultados más «publicables». En algunos casos, el problema es fraude deliberado; en otros, es simplemente la acumulación de pequeñas decisiones no documentadas durante el análisis.

Imagina un equipo de investigación que almacena todos sus datos experimentales en un sistema tipo Git sobre blockchain. Cada medición se registra como un blob en el momento en que se toma. Cada paso del análisis —limpieza de datos, selección de muestras, elección de tests estadísticos, ajuste de parámetros— se registra como un commit con un mensaje que explica la decisión. El dataset original permanece inmutable, y cada transformación crea una nueva versión enlazada con la anterior. Cuando el equipo publica sus resultados, incluye el hash del commit correspondiente al análisis final. Cualquier investigador del mundo puede descargar la cadena completa de commits, verificar que los datos originales no han sido alterados, examinar cada decisión analítica en orden cronológico, e incluso bifurcar el análisis desde un punto intermedio para explorar qué habría ocurrido con decisiones diferentes.

Este nivel de transparencia transforma la revisión por pares. Los revisores ya no dependen de la buena fe de los autores ni de las descripciones textuales en la sección de «métodos». Tienen acceso al historial completo, verificable criptográficamente, de cada decisión que condujo a los resultados publicados. La ciencia deja de depender de la confianza y empieza a depender de la verificación, que es, después de todo, el principio fundacional del método científico.

Colaboración descentralizada: el proyecto que nadie controla pero todos verifican

En 2023, un grupo de periodistas de investigación de doce países trabaja en una filtración masiva de documentos que revela prácticas de evasión fiscal por parte de multinacionales. El problema logístico es formidable: miles de documentos en múltiples idiomas, decenas de periodistas que necesitan acceso simultáneo, y la necesidad absoluta de garantizar que ningún documento se altera, se pierde o se filtra prematuramente. Además, los periodistas trabajan en países con distintos marcos legales y distintos niveles de protección de la libertad de prensa, por lo que confiar en un servidor centralizado en una sola jurisdicción es un riesgo inaceptable.

Un sistema de colaboración basado en almacenamiento tipo Git sobre blockchain resuelve estos desafíos. Los documentos se almacenan como blobs distribuidos entre los nodos de los participantes, con copias en IPFS para resiliencia. Cada periodista trabaja en su propio namespace, añadiendo anotaciones, transcripciones y análisis como nuevos commits enlazados con los documentos originales. Los commits de todos los participantes convergen en un DAG compartido que permite reconstruir quién trabajó en qué, cuándo y en qué orden, sin que ningún participante individual tenga el control exclusivo del sistema.

Si las autoridades de un país confiscan los equipos de un periodista local, los datos no se pierden: están replicados en los nodos de los demás participantes y en IPFS. Si alguien intenta alterar un documento —ya sea para falsificarlo o para eliminarlo—, la cadena de hashes hace que la alteración sea detectable por cualquier otro participante. Y cuando el proyecto está listo para la publicación, el hash raíz del DAG funciona como un sello de integridad que certifica que los documentos publicados son exactamente los documentos que fueron analizados, sin alteraciones de última hora.

Git vs Git-on-Blockchain: qué cambia realmente cuando llevas estos principios a una blockchain

Es tentador pensar que «Git en blockchain» es simplemente Git con más pasos. Pero las diferencias son sustanciales. La siguiente tabla compara ambos sistemas en dimensiones clave, con una explicación de lo que cada diferencia implica en la práctica.

Dimensión	Git tradicional	Git-on-Blockchain
Descentralización	Opcional (depende de dónde alojes el repositorio)	Estructural (inherente al diseño)
Inmutabilidad	Convencional (se puede reescribir el historial)	Criptográfica (garantizada por consenso)
Escala de datos	Optimizado para código fuente (archivos de texto pequeños)	Diseñado para datos arbitrarios a gran escala
Consenso	Humano (el mantenedor decide qué se fusiona)	Algorítmico (protocolo de consenso automático)
Confianza	En el servidor y los mantenedores	En las matemáticas (verificación criptográfica)
Disponibilidad	Depende de que alguien aloje el repositorio	Garantizada por la red mientras haya nodos activos
Incentivos	Ninguno (la gente contribuye voluntariamente)	Económicos (tokens que recompensan almacenar y validar datos)
Privacidad	Público o privado, según la configuración	Configurable por namespace, con pruebas de conocimiento cero

Descentralización. Git es técnicamente descentralizado: cada desarrollador tiene una copia completa del repositorio en su máquina. Pero en la práctica, la mayoría de los proyectos de Git dependen de un servidor central —GitHub, GitLab, Bitbucket— que funciona como fuente de verdad. Si GitHub se cae (algo que ha ocurrido), los equipos pueden seguir trabajando localmente, pero no pueden compartir cambios. En una blockchain, no hay servidor central. La red es la fuente de verdad, y funciona mientras queden nodos activos, sin importar cuáles.

Inmutabilidad. En Git, el historial es inmutable por convención, no por diseño. Los comandos git rebase y git push --force permiten reescribir el historial de commits, eliminando o modificando commits pasados. En equipos disciplinados esto no ocurre, pero técnicamente es posible y no hay mecanismo criptográfico que lo impida. En una blockchain, la inmutabilidad está garantizada por el protocolo de consenso: para alterar un dato pasado habría que convencer a la mayoría de los validadores de la red de que acepten la alteración, lo cual es computacionalmente inviable en una red suficientemente grande.

Escala de datos. Git fue diseñado para código fuente: archivos de texto relativamente pequeños donde lo que importa son las diferencias entre versiones. No maneja bien archivos binarios grandes (imágenes, vídeos, datasets) porque almacena cada versión completa en lugar de solo las diferencias. Las blockchains de almacenamiento tipo Git están diseñadas desde el principio para manejar datos arbitrarios a escala, con técnicas como chunking (dividir archivos grandes en fragmentos), codificación por borrado (añadir redundancia para tolerar pérdidas) y almacenamiento híbrido.

Consenso. En un proyecto Git, la pregunta «¿qué versión es la oficial?» se resuelve mediante autoridad humana: el mantenedor del proyecto decide qué pull requests se aceptan y qué commits forman parte de la rama principal. Es un sistema que funciona bien para el desarrollo de software, pero no escala a escenarios donde millones de participantes desconocidos necesitan ponerse de acuerdo. En una blockchain, el consenso es algorítmico: protocolos como Bullshark establecen automáticamente qué datos son válidos y en qué orden, sin necesidad de que nadie tome decisiones manuales.

Confianza. Cuando clonas un repositorio de GitHub, confías en que GitHub no ha alterado el código. Esa confianza está justificada en la mayoría de los casos, pero no es verificable criptográficamente: si GitHub quisiera servir una versión modificada de un repositorio a un usuario específico, podría hacerlo sin que el usuario lo supiera (a menos que comparara hash por hash con otra copia). En una blockchain, la confianza no se deposita en ninguna entidad, sino en las matemáticas: puedes verificar la integridad de cualquier dato recalculando hashes y comprobando pruebas de Merkle, sin confiar en quien te lo proporcionó.

Disponibilidad. Si el mantenedor de un repositorio Git decide borrarlo, o si la empresa que aloja el servidor cierra, el repositorio desaparece (salvo que alguien tenga una copia local). En una red blockchain, los datos están replicados en múltiples nodos y, si se usa IPFS, en nodos de almacenamiento distribuido. No hay un solo punto de fallo que pueda hacer desaparecer la información.

Incentivos. Nadie te paga por alojar un repositorio Git. El hosting depende de la generosidad de empresas (GitHub ofrece almacenamiento gratuito) o del altruismo de individuos. En una blockchain, hay incentivos económicos explícitos: los nodos que almacenan datos y validan transacciones reciben tokens como recompensa. Esto crea un mercado donde la disponibilidad de los datos está respaldada por incentivos financieros, no por buena voluntad.

Privacidad. Git ofrece repositorios públicos o privados, pero la privacidad de un repositorio privado depende de la seguridad del servidor que lo aloja. Las blockchains con namespaces pueden ofrecer privacidad selectiva: los datos de un namespace pueden ser visibles solo para ciertos participantes, y técnicas como las pruebas de conocimiento cero permiten demostrar propiedades de los datos (por ejemplo, «este saldo es mayor que cero») sin revelar los datos mismos.

Para saber más: referencias y lecturas recomendadas

Si este artículo ha despertado tu curiosidad y quieres profundizar en los conceptos técnicos, las siguientes referencias son un buen punto de partida, ordenadas de menor a mayor complejidad.

• Pro Git de Scott Chacon y Ben Straub. El libro de referencia sobre Git, disponible gratuitamente en línea. Los capítulos sobre los internals de Git (capítulo 10) explican con detalle cómo funcionan blobs, trees y commits, y son sorprendentemente accesibles para un libro técnico.
• Bitcoin: A Peer-to-Peer Electronic Cash System de Satoshi Nakamoto (2008). El documento fundacional de Bitcoin. Solo tiene nueve páginas y, aunque incluye fórmulas matemáticas, la prosa que las rodea es clara y directa. Es el punto de partida para entender cómo la blockchain original usó árboles de Merkle para verificar transacciones.
• Ethereum Patricia Merkle Trie — la documentación oficial de Ethereum sobre su implementación del Merkle Patricia Trie. Incluye diagramas y ejemplos que hacen más tangible la estructura teórica.
• Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus de Danezis et al. (2021). El paper que introdujo Narwhal. Describe cómo separar la diseminación de datos del ordenamiento de consenso puede multiplicar el rendimiento de una blockchain. La sección de arquitectura es comprensible sin formación especializada.
• What is Celestia? — la introducción oficial a Celestia, la blockchain modular que usa Namespaced Merkle Trees y Data Availability Sampling. Explica en lenguaje accesible por qué la disponibilidad de datos es un problema fundamental y cómo los NMT lo resuelven.
• IPFS Documentation: Concepts — la documentación conceptual de IPFS, que explica el almacenamiento direccionado por contenido en el contexto de una red distribuida real. Los diagramas de cómo se resuelven las direcciones CID son especialmente ilustrativos.
• Bullshark: DAG BFT Protocols Made Practical de Spiegelman et al. (2022). La evolución de Narwhal hacia un protocolo más práctico. Explica las mejoras en latencia y las condiciones bajo las cuales el sistema mantiene su rendimiento incluso con validadores defectuosos.
• Mastering Ethereum de Andreas Antonopoulos y Gavin Wood. Un libro completo sobre Ethereum que dedica capítulos enteros al Patricia Trie, al almacenamiento de estado y a los mecanismos de consenso. Disponible gratuitamente en GitHub.

Las estructuras de datos que hacen funcionar Git y blockchain no son invenciones arbitrarias. Son respuestas inevitables a un problema universal: cómo garantizar la integridad de la información en sistemas donde no puedes confiar en ningún participante individual. Los hashes, los árboles de Merkle y el versionado inmutable no son tecnologías de moda; son las matemáticas de la confianza, y sus aplicaciones apenas están empezando.