Saltar al contenido principal

Concepts & glossary

Esta página define una vez, en lenguaje llano, cada entidad central de DIG Network, y enlaza cada una al documento que profundiza. Es la columna vertebral legible para humanos de esta documentación — y, dado que cada término también se emite como datos estructurados legibles por máquinas, es el mapa que un agente puede rastrear para aprender el vocabulario de la red. Recórrela para orientarte; sigue un enlace para profundizar.

El capsule​

Un capsule es una generación de store inmutable: el par (storeId, rootHash), escrito canónicamente como storeId:rootHash. Es la unidad atómica de la red — de compilación (un módulo WASM de tamaño fijo), precio (un precio uniforme por capsule para mint o commit, pagado en $DIG), recuperación (una URN nombra un capsule), caché y procedencia. Un store es una secuencia de capsules, uno por cada commit. Esta definición es idéntica en DigStore, el dig RPC y el DIG Browser. → El capsule, en detalle

Store​

Un store es una identidad más su contenido e historial: una secuencia de capsules, uno por commit. Su identidad es un store id de 64 caracteres hexadecimales, que es el launcher id de su singleton de Chia en cadena — el singleton en la cadena es la autoridad para la raíz actual del store. Un store es el equivalente en DIG de un sitio web. → Estructura del store

Generation​

Una generation es un estado confirmado único de un store, identificado por un root hash (una raíz Merkle sobre las hojas por recurso de la generación). Cada commit sella el contenido actual en una nueva generación de solo anexado — lo mismo que nombra un capsule. Las generations crecen monótonamente, como el historial de Git. → Generations y root hashes

URN​

Una URN es la dirección y la clave de DigStore en una sola cadena: urn:dig:chia:<storeId>[:<rootHash>][/<resource>]. A la vez localiza un recurso y deriva la clave que lo descifra — poseer la URN es necesario y suficiente para leer un recurso público. La abreviatura orientada al navegador es el protocolo chia://. → URNs y cifrado

Retrieval key​

La retrieval key es SHA-256(canonical_urn) — la única dirección que sale del cliente. Ella localiza el texto cifrado de un recurso sin revelar su ruta ni su URN. Es independiente de la raíz, así que la misma clave encuentra un recurso a través de las generations; los bytes servidos luego se verifican con Merkle contra la raíz correcta. La decryption key separada se deriva localmente (HKDF) a partir de la misma URN y nunca se envía. → Dos valores, una cadena

Merkle proof​

Cada generation construye un árbol Merkle con una hoja por recurso, comprometiéndose a los bytes exactos de texto cifrado servidos. Una única prueba de inclusión acompaña a un recurso servido y demuestra que esos bytes pertenecen a esa raíz exacta — así el contenido se verifica sin ser jamás descifrado, y nunca se confía en que un nodo haya devuelto bytes genuinos. → Pruebas Merkle

On-chain anchoring​

Todo store es un singleton en la mainnet de Chia. digstore init lo acuña (el launcher id se convierte en el store id) y cada digstore commit ancla en cadena una nueva raíz de generation como una actualización de singleton CHIP-0035. Ambos bloquean hasta la confirmación y gastan fondos reales. La cadena es la autoridad para la raíz más reciente de un store. → Anclaje en cadena

DIG payment​

$DIG es el token de DIG Network (un CAT de Chia). Acuñar un capsule (init) o hacerle commit cuesta un precio uniforme por capsule en $DIG, incluido atómicamente en el mismo gasto en cadena que el anclaje — no hay una transacción separada, y el memo lleva el store id. → Costos

DigStore CLI​

digstore es la herramienta de línea de comandos que crea, hace commit, comparte y lee stores — un flujo de trabajo con forma de Git (init, add, commit, log, clone, push, pull) sobre el formato de store cifrado y en cadena. → Referencia de comandos · Tutorial de la CLI

dig.toml​

dig.toml es el manifiesto de proyecto commiteable en la raíz de un proyecto — store-id, output-dir, build-command, y otra configuración del proyecto, compartida por digstore dev, digstore deploy y las plantillas de scaffolding. No contiene ningún secreto (esos vienen del entorno), así que es seguro commitearlo. → Configuración del proyecto y valores en tiempo de compilación

create-dig-app​

create-dig-app (npm create dig-app) es la puerta de entrada en JS para iniciar un proyecto DIG: genera un proyecto de partida ejecutable — una app, un dig.toml y (para las plantillas con wallet) el DIG SDK ya conectado — a partir de una de cinco plantillas (static, vite-react, next-static, nft-drop, dapp-window-chia). El scaffolding es gratis — sin mint, sin cadena, sin gasto; pagas el precio uniforme del capsule solo cuando publicas un capsule. Es el equivalente en npm de la CLI en Rust digstore new. → Genera una app

The GitHub deploy Action​

dig-network/deploy-action es la GitHub Action de git-push-to-deploy: instala la CLI de digstore en el runner, ejecuta digstore deploy para avanzar tu store (nunca acuña) y reporta el capsule publicado + las URLs + el costo de vuelta como salidas del paso, un comentario en el PR, un GitHub Deployment y un estado de commit. Con if-changed (por defecto), una build idéntica byte a byte es un no-op — sin gasto. → Deploy desde GitHub Actions

DIG SDK​

El DIG SDK (@dignetwork/dig-sdk) es el paquete npm tipado para desarrolladores de integración: un ChiaProvider (prefiere el window.chia inyectado, recurre a WalletConnect → Sage), un DigClient (lee contenido cifrado y verificado a través del dig RPC), un Paywall (un helper de alto nivel para pago por desbloqueo / acceso restringido por NFT que compone el proveedor con el constructor de gastos), y el constructor canónico de gastos CHIP-0035 reexportado en la subruta /spend. → Construye una dapp en Chia

The dig RPC​

El dig RPC es la interfaz de lectura de toda la red: un servicio JSON-RPC 2.0 sobre HTTPS POST que todo nodo de hospedaje habla de forma idéntica. Sirve texto cifrado + pruebas de inclusión por retrieval key, capsules completos por (storeId, root), y metadatos de descubrimiento — ciego por construcción, verificado y descifrado del lado del cliente. Es la vía de lectura universal: todo capsule publicado es legible aquí por su dirección URN / chia:// en el momento en que se confirma en cadena — sin registro y sin más pago que el de publicar el capsule. El handle *.on.dig.net opcional y amigable es una puerta de entrada sobre esto; el dig RPC en sí siempre está disponible. → ¿Qué es el dig RPC?

The chia:// protocol​

chia:// es el esquema nativo de direcciones de contenido del DIG Browser — el frente escribible de la URN urn:dig:. Pega un enlace chia://<storeId>/ y el navegador obtiene el contenido directamente de la red, direccionado por contenido y verificado criptográficamente. → El protocolo chia://

window.chia​

window.chia es el proveedor de wallet de Chia que el DIG Browser inyecta en cada página. Habla CHIP-0002, así que una app web puede solicitar la dirección, las firmas y los gastos del usuario sin ninguna configuración de WalletConnect — una alternativa lista para usar para apps que ya hablan CHIP-0002. → Usando window.chia · La especificación del proveedor window.chia (normativa, versionada)

DIGHUb​

DIGHUb (hub.dig.net) es la app web para publicar y gestionar capsules sin la CLI — crea un capsule, despliega un frontend y visualiza tus stores en el navegador. También es el plano de control con acceso restringido que gestiona el presupuesto de los costosos trabajos de prueba de ejecución ZK.

dig-node​

Un dig-node es el servidor de contenido de la red — el lado de la oferta. Hospeda capsules, mantiene una caché local .dig y habla el dig RPC de forma idéntica a rpc.dig.net. No necesitas uno para leer contenido de DIG (los consumidores recurren a rpc.dig.net); ejecutar uno hace que las lecturas sean locales por defecto y contribuye con capacidad de servicio. El host es ciego — solo retransmite texto cifrado + pruebas. → Ejecuta un nodo

on.dig.net handle​

Un handle on.dig.net es una dirección web amigable opcional y pagada para un store: <tu-nombre>.on.dig.net. Un store no obtiene una automáticamente — registras el handle (un registro pagado CHIP-54 / on.dig.net en DIGHUb) y ese registro fija el store al nombre. Sin registro no hay dirección *.on.dig.net. Es puramente una puerta de entrada de conveniencia: el store ya es legible a través del dig RPC por su dirección URN / chia:// exista o no un handle. (Los handles de cuenta y los slugs de store son espacios de nombres separados y no exponen automáticamente un subdominio.) → ¿Puedo obtener una dirección *.on.dig.net?

Para agentes y LLMs​

Esta documentación es extraíble por máquinas. Cada página lleva JSON-LD de schema.org (esta, como un conjunto DefinedTerm), y en la raíz del sitio hay dos mapas curados: