Tipos de Entidad

Una especificación formal que define formatos de mensajes, reglas de enrutamiento y patrones de interacción que permiten a los nodos comunicarse, coordinarse e intercambiar mensajes en un sistema distribuido, sin prescribir cómo se construyen las implementaciones o qué aplicaciones se construyen sobre ella. La especificación existe independientemente de cualquier kit de herramientas, SDK o entorno de ejecución particular — múltiples partes independientes pueden implementarla solo a partir del documento. Se distingue de la Plataforma P2P por la ausencia de un entorno de desarrollo de aplicaciones integrado: un protocolo define lo que los nodos se dicen entre sí, no cómo los desarrolladores construyen software que lo hable. Se distingue del Entorno de Ejecución P2P Integrado por el hecho de que el protocolo es separable de su implementación — el formato de transmisión, la implementación de referencia y cualquier herramienta para desarrolladores son artefactos distintos que pueden evolucionar independientemente. Se distingue de la Infraestructura P2P por el hecho de que un protocolo define reglas de comunicación en lugar de operar una red de nodos en vivo; los servicios de infraestructura ejecutan nodos que implementan protocolos y los exponen a usuarios o aplicaciones. Se distingue de la Red de Almacenamiento Descentralizada por la ausencia de un modelo de incentivo o compensación de almacenamiento — un protocolo puede especificar cómo se enrutan o replican los datos, pero no proporciona por sí mismo capacidad de almacenamiento persistente como servicio. Se distingue del Protocolo de Datos Descentralizado por la capa de contribución: la preocupación definitoria de un Protocolo P2P es cómo los nodos se comunican, enrutan, descubren o coordinan entre sí — la mecánica a nivel de transmisión y mensajería de la interacción distribuida; la preocupación definitoria de un Protocolo de Datos Descentralizado es cómo se nombran, direccionan, sincronizan y concilian los datos una vez establecida la comunicación. Un sistema dado puede implementar ambos, pero las dos contribuciones pueden evolucionar como especificaciones separables, y un Protocolo P2P no se convierte en un DD Pro simplemente por transportar datos. Las características típicas de los miembros conocidos incluyen: un documento de especificación publicable de forma independiente; definiciones de formato de mensaje y serialización; reglas de enrutamiento, descubrimiento o sincronización; y la expectativa de que las implementaciones conformes interoperen sin coordinación entre implementadores.

Un sistema fundacional que proporciona infraestructura reutilizable, herramientas para desarrolladores y servicios de tiempo de ejecución para construir aplicaciones descentralizadas, donde la plataforma misma se construye sobre uno o más protocolos externos en lugar de definir su propio formato de transmisión. El valor de la plataforma está en lo que añade por encima de la capa de protocolo: gestión de identidad, sincronización de datos, abstracciones de almacenamiento, acceso a SDK y servicios componibles que de otro modo requerirían que cada aplicación los implemente de forma independiente. Se distingue del Protocolo P2P por la presencia de una capa de desarrollo de aplicaciones: una plataforma es algo sobre lo que los desarrolladores construyen, no algo que implementan desde cero. Se distingue del Entorno de Ejecución P2P Integrado por la separabilidad de la plataforma respecto de su protocolo subyacente — el protocolo en principio podría ser implementado por otras herramientas, y las abstracciones de la plataforma teóricamente podrían reconstruirse sobre un transporte diferente. En un Entorno de Ejecución P2P Integrado no existe tal separación; el protocolo está definido por y para el entorno de ejecución. Se distingue de la Aplicación Descentralizada por el alcance: el artefacto principal de una plataforma es infraestructura para desarrolladores, no un producto para el usuario final. Las aplicaciones se construyen sobre la plataforma; la plataforma misma no es la aplicación. Las características típicas de los miembros conocidos incluyen: un SDK o API a través del cual los desarrolladores acceden a las capacidades de la plataforma; una pila de protocolos definida que la plataforma implementa en nombre de los desarrolladores; servicios de identidad y/o almacenamiento compartidos entre las aplicaciones construidas sobre la plataforma; y soporte para que múltiples aplicaciones independientes coexistan en la misma red.

Una tecnología en la que el modelo de datos, el protocolo de sincronización, la arquitectura de seguridad y el entorno de desarrollo de aplicaciones se co-diseñan como un todo único e inseparable. El protocolo no existe independientemente de su entorno de desarrollo — no hay forma de separar el formato de transmisión del kit de herramientas que lo implementa, porque ambos fueron diseñados juntos y cada uno presupone al otro. Los desarrolladores no construyen aplicaciones que usan el entorno de ejecución; construyen aplicaciones que se ejecutan dentro de él, con el entorno de ejecución gobernando la estructura de datos, la interacción entre pares y las garantías de seguridad como un todo unificado. Se distingue del Protocolo P2P por la presencia de un entorno de desarrollo inseparable: un Protocolo P2P puede ser implementado por cualquier parte que trabaje solo a partir de un documento de especificación, y las implementaciones resultantes interoperan. Un Entorno de Ejecución P2P Integrado no puede separarse de su implementación — el kit de herramientas no es una capa de conveniencia sobre el protocolo, sino una parte constitutiva de lo que el protocolo es. Se distingue de la Plataforma P2P por la direccionalidad de la relación entre protocolo y plataforma: una Plataforma P2P se construye sobre un protocolo externo que no definió; un Entorno de Ejecución P2P Integrado posee y define su protocolo como una consecuencia intrínseca de su diseño, de modo que ningún otro entorno de ejecución podría implementar "el mismo protocolo" en ningún sentido significativo. Se distingue de la Aplicación Descentralizada por el hecho de que un Entorno de Ejecución P2P Integrado es infraestructura para desarrolladores, no un producto para el usuario final — su artefacto principal es un entorno en el que se construyen aplicaciones, no una aplicación en sí misma. Se distingue de la Aplicación Descentralizada Extensible por el hecho de que la contribución definitoria de un Entorno de Ejecución P2P Integrado es la arquitectura unificada de protocolo-más-entorno, no la extensibilidad de ninguna aplicación particular que se ejecute dentro de él. Los compromisos característicos entre los miembros conocidos incluyen: propiedad de datos soberana del usuario, lo que significa que los datos del usuario le pertenecen por garantía arquitectónica y no por política; desacoplamiento de la lógica de la aplicación del almacenamiento de datos, de modo que los datos persisten y permanecen accesibles independientemente de si alguna aplicación específica continúa existiendo; y un modelo de identidad integrado incorporado en la capa de protocolo en lugar de añadido encima, de modo que la identidad no es un servicio que la aplicación invoca sino una propiedad de cada objeto de datos en el sistema.

Un producto de software para el usuario final diseñado para realizar tareas específicas y acotadas utilizando protocolos descentralizados, con un límite definido entre la aplicación y la infraestructura sobre la que se ejecuta. Los usuarios consumen la funcionalidad de la aplicación; no la extienden, componen ni reprograman como parte del uso ordinario. La arquitectura descentralizada permite que la aplicación funcione sin depender de un único servidor u organización controladora, pero esta arquitectura es una decisión de implementación más que una superficie expuesta con la que el usuario interactúa. Se distingue de la Aplicación Descentralizada Extensible por la presencia de una separación significativa entre usar la aplicación y construir sobre ella: una Aplicación Descentralizada tiene usuarios de un lado y desarrolladores del otro, y la extensión o personalización, si se soporta, requiere cruzar deliberadamente ese límite. Se distingue de la Plataforma P2P por el hecho de que el artefacto principal es un producto para el usuario final en lugar de infraestructura para desarrolladores — una Aplicación Descentralizada no proporciona un SDK, una capa de protocolo compartida ni servicios para que aplicaciones de terceros construyan sobre ella. Se distingue del Entorno de Ejecución P2P Integrado por el hecho de que la aplicación se construye sobre un protocolo o plataforma externos en lugar de ser inseparable de uno. Las características típicas de los miembros conocidos incluyen: una función definida orientada al usuario (compartir archivos, mensajería, publicación, coordinación); un despliegue que funciona para los usuarios finales sin requerir que comprendan el protocolo subyacente; y una distinción clara entre la capa de aplicación y la capa de protocolo o plataforma debajo de ella.

Una aplicación descentralizada en la que el límite entre aplicación y plataforma se disuelve por diseño: usar la aplicación y construir sobre ella son el mismo acto en lugar de actividades separadas. La aplicación no es meramente configurable o capaz de aceptar plugins — la extensión, composición y personalización son intrínsecas a su arquitectura, de modo que el camino de usuario final a desarrollador es un continuo en lugar de un umbral que cruzar. El modelo de datos, los bloques de construcción y las superficies de interacción de la aplicación están expuestos por defecto, no habilitados como una función secundaria para desarrolladores. Se distingue de la Aplicación Descentralizada por la presencia de extensibilidad diseñada a nivel arquitectónico: una Aplicación Descentralizada tiene un límite significativo entre usarla y construir sobre ella, y ese límite es intencional — la arquitectura de la aplicación no invita a los usuarios a extenderla. Una Aplicación Descentralizada Extensible trata ese límite como un fallo de diseño que debe eliminarse. Se distingue de la Plataforma P2P por la primacía de la aplicación funcional: el artefacto principal de una Plataforma P2P es infraestructura para desarrolladores, y las aplicaciones se construyen sobre ella como cosas separadas; una Aplicación Descentralizada Extensible es en sí misma la aplicación funcional, y sus propiedades similares a una plataforma emergen desde dentro de ella en lugar de preexistir debajo. Se distingue del Entorno de Ejecución P2P Integrado por el nivel de la contribución: la característica definitoria de un Entorno de Ejecución P2P Integrado es una arquitectura unificada de protocolo-más-entorno a nivel de infraestructura; la característica definitoria de una Aplicación Descentralizada Extensible es una aplicación orientada al usuario que resulta disolver el límite usuario/desarrollador. Una Ext D App típicamente se ejecuta sobre un protocolo, plataforma o entorno de ejecución — no define uno. Las características típicas de los miembros conocidos incluyen: bloques de construcción componibles por el usuario que permiten a no desarrolladores ensamblar nueva funcionalidad dentro de la propia interfaz de la aplicación; un modelo de datos expuesto que otras aplicaciones o agentes pueden leer, escribir o construir sobre él sin requerir acceso al código fuente de la aplicación; una filosofía de diseño en la que no se traza un límite estricto entre consumir y crear dentro del mismo entorno; y un artefacto principal que es inmediatamente útil para los usuarios finales mientras simultáneamente sirve como plataforma de extensión.

Redes de nodos operativas que proporcionan servicios fundacionales de transporte, enrutamiento, privacidad o acceso sobre los que se construyen otros protocolos, plataformas y aplicaciones. La característica definitoria es que la Infraestructura P2P es un servicio en ejecución más que una especificación: consiste en nodos en vivo operados por voluntarios o participantes incentivados, y su valor se entrega por la existencia de la red más que por el documento que la describe. Típicamente diseñada para funcionar bajo condiciones adversas — censura, vigilancia, análisis de tráfico o bloqueo dirigido — como un requisito de diseño central en lugar de una idea tardía. Se distingue del Protocolo P2P por la capa de operación: un Protocolo P2P especifica reglas que las implementaciones siguen; la Infraestructura P2P ejecuta esas reglas como un servicio siempre activo al que otros sistemas se conectan. Una pieza dada de infraestructura típicamente implementa uno o más Protocolos P2P, pero el protocolo y la red operativa son artefactos distintos. Se distingue de la Red de Almacenamiento Descentralizada por la función principal entregada: la Infraestructura P2P proporciona transporte, retransmisión, enrutamiento o elusión de acceso — el movimiento de datos más que su custodia persistente. Una DSN almacena datos en nombre de los usuarios para su recuperación posterior; la Infraestructura P2P mueve datos entre puntos finales sin necesariamente retenerlos. Se distingue de la Plataforma P2P por la ausencia de una capa de desarrollo de aplicaciones: la Infraestructura P2P no proporciona SDKs, servicios de identidad ni abstracciones para desarrolladores — proporciona un sustrato sobre el que los desarrolladores pueden construir, pero no facilita esa construcción. Las características típicas de los miembros conocidos incluyen: una red en vivo de nodos voluntarios o incentivados de retransmisión/enrutamiento; diseño para resistencia a la censura u ofuscación de tráfico; operación como un recurso compartido consumido por diversas aplicaciones en lugar de un producto de propósito único; y comportamiento degradado pero funcional bajo interferencia activa de la red.

Una arquitectura de comunicación en la que los usuarios se conectan a servidores operados de forma independiente (instancias), y esos servidores mantienen relaciones directas entre pares para enrutar mensajes, compartir contenido o coordinar actividad en nombre de sus usuarios. La portabilidad de la identidad y el contenido entre los límites de los servidores es un objetivo de diseño: los usuarios de un servidor pueden interactuar con usuarios de otro sin ningún intermediario central. Se distingue del Protocolo P2P por la presencia de una capa de servidor persistente entre el protocolo y el usuario final — los clientes no hablan el protocolo directamente con todos los pares, sino que delegan en su servidor de origen, que habla el protocolo en su nombre. Se distingue de las plataformas centralizadas con APIs por el requisito de que cualquier implementación de servidor conforme pueda federarse con cualquier otra, sin permiso de una autoridad central. Se distingue de la Red de Almacenamiento Descentralizada por el enfoque en la comunicación y la interacción social en lugar de la capacidad de almacenamiento de datos persistente. Las características típicas de los miembros conocidos incluyen: un protocolo servidor-a-servidor distinto del protocolo cliente-a-servidor; instancias operadas de forma independiente que implementan la misma especificación; identidad de usuario anclada a un servidor (con o sin mecanismos de portabilidad); y un modelo de gobernanza en el que ningún operador único controla quién puede participar en la federación.

Una especificación formal para describir, estructurar o enlazar datos de maneras interpretables entre sistemas, aplicaciones y organizaciones sin requerir una implementación compartida. El artefacto principal no es un mecanismo de comunicación sino una capa de significado compartida: vocabularios, ontologías, esquemas o modelos de grafos que dan a los datos una semántica portátil e inequívoca sin importar dónde se almacenen o qué sistema los lea. Se distingue del Protocolo P2P por el hecho de que un Protocolo Semántico y de Datos no define cómo se comunican los nodos — define qué significan los datos que intercambian. Un Protocolo P2P puede adoptar un Protocolo Semántico y de Datos para su modelo de datos sin convertirse él mismo en uno. Se distingue del Protocolo de Identidad por el alcance: un Protocolo de Identidad define cómo se establecen, verifican e intercambian los identificadores y credenciales; un Protocolo Semántico y de Datos define cómo se estructuran e interpretan los datos en general — incluidos los datos de identidad — y no es específico del dominio de la identidad. Se distingue de la Aplicación Descentralizada por la ausencia de un artefacto para el usuario final: un Protocolo Semántico y de Datos es consumido por desarrolladores y diseñadores de protocolos, no directamente por usuarios. Las características típicas de los miembros conocidos incluyen: una especificación de vocabulario o esquema que puede adoptarse independientemente de cualquier implementación particular; definiciones legibles por máquina que permiten la interpretación o inferencia automatizada; diseño para la interoperabilidad entre sistemas heterogéneos; y uso como una capa compartida bajo múltiples protocolos o aplicaciones de nivel superior.

Una especificación formal que define las reglas, formatos y patrones de interacción mediante los cuales se crean y resuelven identificadores descentralizados, se emiten y verifican credenciales, se realiza la autenticación o se establece confianza entre las partes — sin prescribir cómo se implementan esas reglas en software. Al igual que un Protocolo P2P, un Protocolo de Identidad es principalmente un documento que partes independientes pueden implementar desde cero; su valor está en permitir la interoperabilidad entre implementaciones en lugar de proporcionar una herramienta específica. Se distingue del Kit de Herramientas / Plataforma de Identidad por el nivel de abstracción: un Protocolo de Identidad define lo que los sistemas conformes deben hacer; un Kit de Herramientas de Identidad proporciona el software que lo hace. Un desarrollador lee un Protocolo de Identidad para entender el estándar; instala un Kit de Herramientas de Identidad para implementarlo. Se distingue del Sistema / Diseño de Identidad por el alcance y la novedad: un Protocolo de Identidad es típicamente una especificación formal presentada a, o surgida de, un proceso de estandarización (W3C, IETF, DIF, ToIP), mientras que un Sistema / Diseño de Identidad propone una arquitectura novedosa de extremo a extremo — una nueva forma de pensar los problemas de identidad — que puede o no tener aún una especificación formal correspondiente. Se distingue del Protocolo Semántico y de Datos por la especificidad de dominio: un Protocolo de Identidad se preocupa por quiénes son las partes y cómo se establece eso; un Protocolo Semántico y de Datos se preocupa por lo que significan los datos, aplicable a cualquier dominio, incluyendo pero no limitado a la identidad. Las características típicas de los miembros conocidos incluyen: un documento de especificación que define la sintaxis de identificadores, los mecanismos de resolución, los formatos de credenciales o los flujos de intercambio; un modelo de conformidad contra el cual pueden probarse las implementaciones; un enfoque en la interoperabilidad entre emisores, titulares y verificadores independientes; y diseño para operar sin una autoridad central que controle el registro de identificadores o la validez de las credenciales.

Infraestructura para desarrolladores que implementa uno o más Protocolos de Identidad y expone sus capacidades a través de SDKs, APIs o frameworks, permitiendo a los desarrolladores de aplicaciones construir funciones habilitadas para identidad sin implementar las especificaciones subyacentes desde cero. El artefacto principal es software funcional para desarrolladores — bibliotecas, servicios o plataformas — en lugar de un documento de especificación o una arquitectura de identidad novedosa. Se distingue del Protocolo de Identidad por la capa entregada: un Protocolo de Identidad es una especificación; un Kit de Herramientas / Plataforma de Identidad es su implementación, empaquetada para su reutilización. Un único Protocolo de Identidad puede tener múltiples implementaciones de Kit de Herramientas en competencia. Se distingue del Sistema / Diseño de Identidad por la ausencia de novedad arquitectónica como contribución principal: un Kit de Herramientas de Identidad principalmente hace que los estándares existentes sean accesibles y utilizables, en lugar de proponer un nuevo modelo de cómo debería funcionar la identidad. Un Sistema / Diseño de Identidad puede incluir herramientas, pero su contribución definitoria es la arquitectura novedosa; las herramientas son secundarias. Se distingue de la Plataforma P2P por la especificidad de dominio: un Kit de Herramientas / Plataforma de Identidad está construido específicamente para casos de uso de identidad, credenciales y autenticación, incluso si en principio pudiera soportar otros tipos de datos. Las características típicas de los miembros conocidos incluyen: una superficie de SDK o API que expone resolución de DID, emisión de credenciales, verificación o autenticación; conformidad con uno o más Protocolos de Identidad publicados; guías de integración dirigidas a desarrolladores de aplicaciones más que a investigadores de protocolos; y reutilización entre múltiples aplicaciones y contextos de despliegue sin modificación.

Una arquitectura novedosa de extremo a extremo que propone un enfoque fundamentalmente nuevo para uno o más problemas centrales de identidad — cómo se establece la personalidad, cómo se delega la confianza, cómo se estructuran las credenciales, o cómo persiste la identidad a través de contextos — en lugar de implementar o extender un estándar existente. La característica definitoria es que la contribución principal es una idea arquitectónica: un nuevo modelo de cómo debería funcionar la identidad, que puede o no estar aún formalizado como especificación o implementado como kit de herramientas. Se distingue del Protocolo de Identidad por la naturaleza de la contribución: un Protocolo de Identidad opera dentro de un paradigma establecido (métodos DID, formatos VC, flujos OAuth) y define reglas precisas de interoperabilidad; un Sistema / Diseño de Identidad cuestiona o reemplaza el paradigma mismo, proponiendo por qué los enfoques existentes son insuficientes y cómo se vería una estructura mejor. Un Sistema de Identidad novedoso eventualmente puede producir Protocolos de Identidad a medida que sus ideas maduran, pero en el punto de clasificación, la propuesta arquitectónica precede o reemplaza a la especificación. Se distingue del Kit de Herramientas / Plataforma de Identidad por la primacía: el valor principal de un Kit de Herramientas de Identidad es el software que los desarrolladores usan; el valor principal de un Sistema / Diseño de Identidad es la perspectiva arquitectónica, que las herramientas pueden o no encarnar aún. Se distingue del Protocolo P2P por el dominio y la intención: un Sistema / Diseño de Identidad se preocupa específicamente por la identidad, la confianza y la personalidad, no por la comunicación o el intercambio de datos en general. Las características típicas de los miembros conocidos incluyen: un white paper, tesis o documento arquitectónico que articula el enfoque novedoso; crítica explícita o alejamiento de los paradigmas de identidad existentes; mecanismos propuestos para la verificación de personalidad, el establecimiento de confianza o la gestión del ciclo de vida de credenciales que no son reducibles a extensiones de estándares existentes; y la expectativa de que las implementaciones, estándares y herramientas seguirán a la perspectiva arquitectónica en lugar de precederla.

Una especificación formal cuya realización principal es uno o más contratos desplegables en cadena o registros de aplicación criptográfica, de modo que, una vez desplegado, el estándar y su mecanismo de aplicación se convierten en el mismo artefacto. A diferencia de un Protocolo P2P — que es una especificación que partes independientes implementan por separado —, un Estándar de Contrato Inteligente se vuelve operativo mediante el despliegue: el contrato en ejecución no es una implementación del estándar sino el estándar mismo, instanciado como estado compartido sin permiso en una blockchain que cualquier participante puede leer o escribir según las reglas del contrato. Se distingue del Protocolo P2P por el modelo de despliegue: un Protocolo P2P es implementado por muchas partes independientes que ejecutan sus propios nodos; un Estándar de Contrato Inteligente se despliega una vez (o como un pequeño número de instancias canónicas) y a partir de entonces existe como un artefacto compartido en cadena. Se distingue de la Aplicación Descentralizada por el nivel de abstracción: un Estándar de Contrato Inteligente define infraestructura compartida — registros, interfaces o estructuras de datos — sobre la que otras aplicaciones se construyen, en lugar de entregar funcionalidad para el usuario final por sí mismo. Una Aplicación Descentralizada puede implementar o interactuar con un Estándar de Contrato Inteligente sin ser uno. Se distingue de la Red de Almacenamiento Descentralizada por la ausencia de capacidad de almacenamiento como oferta principal: un Estándar de Contrato Inteligente aplica reglas y mantiene estado compartido; no proporciona almacenamiento distribuido para datos arbitrarios del usuario. Las características típicas de los miembros conocidos incluyen: un documento de especificación EIP, ERC o equivalente que define la interfaz, el diseño de almacenamiento y las reglas de comportamiento; una implementación de referencia desplegable en una blockchain compatible; acceso de lectura y escritura sin permiso por cualquier participante conforme; y diseño como infraestructura compartida en lugar de una aplicación independiente — el estándar es más valioso cuando múltiples aplicaciones o agentes independientes lo adoptan como una capa común.

Una red descentralizada en la que operadores de nodos distribuidos proporcionan capacidad de almacenamiento de datos persistente a usuarios o aplicaciones como función principal de la red, con la participación de los nodos sostenida mediante incentivos criptoeconómicos, contribución voluntaria o gobernanza cooperativa. La característica definitoria es la custodia persistente: una DSN acepta datos, los almacena en múltiples nodos para durabilidad, y los hace recuperables más tarde — el valor central de la red es que los datos colocados en ella continúan existiendo y permanecen accesibles con el tiempo, no meramente que puedan enrutarse o retransmitirse en tránsito. Se distingue de la Infraestructura P2P por la función principal entregada: la Infraestructura P2P proporciona transporte, enrutamiento o elusión de acceso — mueve datos entre puntos finales sin necesariamente retenerlos. Una DSN retiene los datos como su servicio central. Ambas pueden coexistir — una DSN puede usar Infraestructura P2P para la comunicación nodo a nodo —, pero el compromiso definitorio de la DSN es con la persistencia de datos, mientras que el de la Infraestructura P2P es con el movimiento de datos. Se distingue del Protocolo P2P por la realidad operativa: un Protocolo P2P especifica cómo debería funcionar el almacenamiento o la recuperación; una DSN es la red operativa que ejecuta esas especificaciones, con nodos en vivo, modelos económicos y garantías de almacenamiento. Se distingue de la Aplicación Descentralizada por la orientación a infraestructura: una DSN proporciona capacidad de almacenamiento consumida por otras aplicaciones y protocolos, en lugar de entregar funcionalidad para el usuario final por sí misma. Las características típicas de los miembros conocidos incluyen: un rol de operador de nodo distinto del usuario final, con incentivos o mecanismos de gobernanza para sostener la participación; mecanismos de prueba o auditoría de almacenamiento que aseguran que los operadores realmente retienen los datos que dicen tener; garantías de recuperación que van desde la aplicación criptoeconómica hasta el mejor esfuerzo; un modelo de compensación o incentivo (recompensas en tokens, pagos fiduciarios, dotación única o voluntario) como una preocupación de diseño de primer nivel; y diseño como infraestructura compartida en lugar de una aplicación de propósito único.

Una especificación formal que define cómo se nombran, direccionan, replican, sincronizan y recuperan los datos estructurados a través de una red entre pares, donde la contribución principal del protocolo es a la capa de datos — direccionamiento por contenido, semántica de mutabilidad, algoritmos de sincronización, resolución de conflictos y el ciclo de vida de los datos una vez que existen — en lugar de a la capa de transporte, comunicación o coordinación debajo de ella. La especificación existe independientemente de cualquier kit de herramientas, SDK o entorno de ejecución particular, y múltiples partes independientes pueden implementarla solo a partir del documento. Se distingue del Protocolo P2P por la capa de contribución: un Protocolo P2P define cómo los nodos se comunican, enrutan, descubren o intercambian mensajes en la capa de transporte o mensajería; un Protocolo de Datos Descentralizado define cómo los datos — una vez establecida la comunicación por algún otro medio — se estructuran, nombran, versionan y concilian entre pares. Un sistema dado puede implementar ambos tipos de protocolo, pero las contribuciones son artefactos separables que evolucionan en calendarios independientes. Se distingue del Protocolo Semántico y de Datos por el alcance y la preocupación operativa: un Protocolo Semántico y de Datos define una capa de vocabulario o esquema que da a los datos un significado portátil entre sistemas heterogéneos independientemente del transporte o almacenamiento; un Protocolo de Datos Descentralizado se preocupa por la mecánica operativa de cómo los datos viven y se mueven en un sustrato entre pares — replicación, direccionamiento por contenido, sincronización, mutabilidad — independientemente de lo que los datos signifiquen a nivel semántico. Ambos son complementarios: un Protocolo de Datos Descentralizado puede transportar datos semánticamente tipados definidos por un Protocolo Semántico y de Datos sin convertirse él mismo en uno. Se distingue de la Red de Almacenamiento Descentralizada por la ausencia de infraestructura operativa como artefacto principal: una DSN ejecuta nodos en vivo que proporcionan capacidad de almacenamiento persistente a los usuarios, con gobernanza criptoeconómica, voluntaria o cooperativa que sostiene la participación; un Protocolo de Datos Descentralizado es la especificación que cualquier parte puede implementar para participar en dicha red, pero no constituye una en sí mismo ni requiere un modelo de incentivos. Se distingue del Entorno de Ejecución P2P Integrado por la separabilidad de la especificación respecto de su implementación: un Protocolo de Datos Descentralizado es un documento a partir del cual pueden escribirse implementaciones conformes de forma independiente, y las implementaciones resultantes interoperan; un Entorno de Ejecución P2P Integrado co-diseña el modelo de datos, el protocolo de sincronización y el entorno de desarrollo como un todo único e inseparable. Las características típicas de los miembros conocidos incluyen: un esquema de nombrado por direccionamiento de contenido o autocertificante; un algoritmo de sincronización o replicación definido (reconciliación de conjuntos basada en rangos, gossip, fusión CRDT, propagación de eventos basada en DAG, árboles de búsqueda Merkle); semántica de mutabilidad explícita (solo-anexar, mutable mediante versionado, fusionable por CRDT, el último escritor gana); independencia de cualquier blockchain, modelo de incentivo de almacenamiento o protocolo de transporte específico; y adopción entre múltiples aplicaciones independientes como sustrato de datos compartido.

Una especificación formal que define cómo se emite, contabiliza, valora y hace circular el valor entre los participantes de una red descentralizada, donde la contribución definitoria del protocolo es la lógica monetaria misma — las reglas que gobiernan la emisión, acumulación, liquidación, valoración y federación — en lugar del sustrato de comunicación, datos, identidad o contrato inteligente sobre el cual pueda implementarse. La especificación existe independientemente de cualquier implementación particular, y múltiples sustratos (libros de crédito mutuo, entornos de ejecución centrados en agentes, contratos de blockchain, redes de servidores federados, infraestructura institucional) pueden realizar el mismo protocolo. Se distingue del Estándar de Contrato Inteligente por la independencia de sustrato: un Estándar de Contrato Inteligente se realiza mediante despliegue en cadena, de modo que el contrato en ejecución y el estándar son el mismo artefacto; un Protocolo Monetario Descentralizado define lógica monetaria que puede implementarse en cadena, fuera de cadena, centrada en agentes o institucionalmente, y las implementaciones en distintos sustratos pueden interoperar a nivel de la lógica monetaria. Un Estándar de Contrato Inteligente como ERC-3643 puede instanciar aspectos de un Protocolo Monetario Descentralizado, pero el protocolo es conceptualmente anterior e independiente del sustrato. Se distingue del Protocolo P2P por la capa de contribución: un Protocolo P2P define cómo los nodos se comunican, enrutan y se descubren entre sí; un Protocolo Monetario Descentralizado define cómo fluye el valor una vez establecida la comunicación. Un protocolo monetario dado puede ejecutarse sobre cualquier Protocolo P2P o transporte federado. Se distingue del Protocolo de Datos Descentralizado por la preocupación principal: un Protocolo de Datos Descentralizado gobierna cómo se nombran, direccionan, replican y concilian los datos; un Protocolo Monetario Descentralizado gobierna cómo se emiten, transfieren, valoran y acotan las reclamaciones de valor — la capa de datos es incidental más que constitutiva. Se distingue del Protocolo de Identidad por el dominio: los protocolos de identidad gobiernan quiénes son los participantes y cómo se resuelven los identificadores; los protocolos monetarios gobiernan cómo se mueve el valor entre participantes identificados, y típicamente dependen de, pero no definen, la infraestructura de identidad. Las características típicas de los miembros conocidos incluyen: una especificación de cómo se emiten las unidades de cuenta (entre pares, algorítmica, deliberativa, agrupada por compromiso, u otra); reglas que gobiernan la acumulación, decaimiento o convertibilidad; un mecanismo de coordinación o valoración definido; lógica de federación explícita donde múltiples instancias interoperan; y diseño como una especificación neutral de sustrato que múltiples implementaciones independientes pueden realizar.