Una lectura por capas del ciclo de atribución y resolución de ARK, las APIs de dARK, la blockchain privada, la preservación distribuida de metadatos y la arquitectura multisitio.
Cómo funciona el flujo
La atribución comienza con la reserva de una identidad. Continúa con el envío de la URL y los metadatos, su preservación descentralizada y la publicación del ARK.
El Minter atribuye una nueva identidad dentro de un NAAN habilitado.
Se envían la URL y los metadatos; dARK los preserva en varios nodos y registra el ARK.
La API confirma el estado Publicado; el Resolver ofrece URL y metadatos, y Minter recibe cambios posteriores.
Si el recurso cambia de plataforma, la institución actualiza el destino y conserva el mismo ARK.
Autoridades y NAAN
dARK denomina autoridad a una institución —o a su representante definido por la gobernanza— habilitada para registrar identificadores. Cada autoridad se vincula con uno o más NAAN, los prefijos que representan sus espacios institucionales de identificación.
En la primera etapa de LA Referencia, los nodos nacionales actúan como autoridades designadas. Una etapa posterior permitirá que las propias instituciones realicen minting mediante la API.
La gobernanza reconoce a la institución o al nodo nacional que la representa.
Cada prefijo delimita los espacios institucionales sobre los que puede operar.
Minter valida la autoridad y el NAAN antes de reservar o actualizar un ARK.
El ciclo dentro de Minter
El estado permite a quien envía la información conocer el avance del minting. El recorrido principal va de Reservado a Borrador y finalmente a Publicado. Selecciona cada estado para ver qué ocurre.
Minter generó el identificador y conserva su reserva mientras espera la URL y los metadatos.
Minter recibió la información y los procesos internos preparan su preservación y registro.
Los metadatos fueron preservados y el registro quedó confirmado en blockchain para su resolución pública.
Minter recibió una nueva URL o versión de los metadatos y repite el proceso de preservación y registro.
La autoridad propietaria desactivó el ARK. Es una operación irreversible y el registro no puede modificarse.
Detrás de los estados
La reserva y el envío de información se realizan mediante Minter. Luego los procesos internos preservan los metadatos, registran el ARK y actualizan su estado.
APIs de dARK
Minter y Resolver son las dos interfaces de uso. Detrás de ellas, Admin, los workers, dark-core-lib y Store coordinan las operaciones con blockchain e IPFS.
Permite reservar, completar y actualizar ARK, además de consultar su estado.
Permite abrir el destino vigente, consultar información y recuperar los metadatos preservados.
Admin registra autoridades en blockchain. Minter mantiene el estado local, coordina la preservación y publica el registro mediante los contratos. Resolver consulta la cadena y, cuando se solicitan metadatos, los recupera mediante Store API.
Tecnología base · Blockchain
La blockchain privada de dARK registra las autoridades, sus permisos y cada creación o actualización de un ARK. El mismo historial ordenado se mantiene entre los nodos validadores, aportando confianza y trazabilidad al servicio. Un nodo blockchain es un equipo que conserva una copia del registro y participa en la red; los nodos validadores, además, intervienen en la confirmación de los bloques.
No es Proof of Work. A diferencia de las criptomonedas que hacen competir a participantes anónimos por resolver cálculos, dARK identifica previamente a sus validadores y utiliza su acuerdo para incorporar operaciones al registro.
Referencia externa: documentación de Hyperledger Besu sobre QBFT ↗.
Tecnología base · IPFS
Los metadatos se preservan en dos niveles. L1 reúne en un JSON los metadatos básicos y los datos internos que dARK necesita para gestionar el ARK, e incluye el CID de L2 para mantener el vínculo con el registro original. L2 conserva el registro de metadatos original. El CID de L1 queda asociado al ARK en blockchain.
Arquitectura multisitio
El modelo distribuye aplicaciones, nodos blockchain y almacenamiento entre sedes conectadas por redes privadas. Cada sede aporta infraestructura al mismo servicio dARK, de modo que la red puede continuar aunque temporalmente solo una sede permanezca operativa.
La arquitectura está pensada para distribuir las sedes entre infraestructuras públicas y privadas de distintos países. Esa diversidad permite mantener copias y servicios disponibles ante la pérdida temporal de una sede y favorece la supervivencia de la información en el tiempo. Store API trabaja con los nodos de almacenamiento locales y la propagación remota ocurre dentro del único clúster IPFS global.
Cómo funciona el Resolver de dARK
El Resolver consulta el registro y responde de tres maneras. Selecciona cada opción para conocer su recorrido.
dARK dentro de la resolución global de ARK
El registro global de ARK mantiene una regla N2T —Name to Thing— para cada NAAN. En los espacios administrados por dARK, esa regla dirige la consulta hacia el Resolver de dARK. N2T indica qué servicio responde; no almacena los metadatos.
GET /api/v1/arks/ark:/12345/abc123Consulta la dirección registrada y abre el recurso en su repositorio actual.
GET /api/v1/arks/ark:/12345/abc123?infoPresenta la información pública asociada con el ARK.
GET /api/v1/arks/ark:/12345/abc123?metadataRecupera la versión original de los metadatos preservados.
El resultado
dARK coordina atribución, preservación descentralizada, registro verificable y resolución pública mediante servicios especializados.
Documentación técnica
dARK se encuentra en constante evolución. La documentación describe los componentes, contratos, APIs, estados, preservación de metadatos y operación de la infraestructura. La versión estable y el código completo estarán disponibles para la comunidad a finales de 2026.