Empezando

• 1: Conceptos
• 1.1: Gobernanza
• 1.2: Sujeto
• 1.3: Roles
• 1.4: Esquema
• 1.5: Eventos
• 1.6: Identidad
• 1.7: Nodos
• 1.8: Contratos
• 2: Conceptos avanzados
• 2.1: Proceso de aprobación del evento
• 2.2: Proceso de evaluación de eventos
• 2.3: Proceso de validación de eventos
• 3: Glosario

1 - Conceptos

1.1 - Gobernanza

La gobernanza es el conjunto de definiciones y reglas que establecen cómo los diferentes nodos participantes en una red se relacionan con los sujetos de la trazabilidad e interaccionan entre si. Los componentes de las gobernanza son:

• Los nodos participantes.
• El esquema de los atributos de los sujetos.
• El contrato para aplicar los eventos que modifican el estado del sujeto.
• Los permisos de cada participante para participar en la red.

Miembros

Estas son las personas, entidades u organizaciones que participan en la gobernanza y por tanto pueden ser parte de los casos de uso que se soportan. Cada miembro declara un identificador único que representa el material criptográfico con el que operará en la red, su identidad .

Esquemas

Los esquemas son las estructuras de datos que modelan la información almacenada en los sujetos. Dentro de una gobernanza, se pueden definir diferentes esquemas para admitir diferentes casos de uso. Cuando se crea un sujeto, define a qué gobierno está asociado y qué esquema utilizará. Además, cada esquema tiene asociado un contrato inteligente que permitirá modificar el estado de los sujetos.

Roles

Los roles representan grupos de participantes con algún tipo de interés común en un conjunto de sujetos. Los roles nos permiten asignar permisos sobre estos grupos de sujetos más fácilmente que si tuviéramos que asignarlos individualmente a cada miembro del gobierno.

Políticas

Las políticas definen las condiciones específicas bajo las cuales se afecta el ciclo de vida de un evento, como el número de firmas necesarias para llevar a cabo los procesos de evaluación, aprobación y validación. A esto se le llama quórum. La configuración de gobernanza permite la definición de [distintos tipos de quórum] , más o menos restrictivos, dependiendo de la necesidad del caso de uso.

La gobernanza como sujeto

La gobernanza es un sujeto de trazabilidad, dado que puede evolucionar y adaptarse a las necesidades de negocio, y por tanto su ciclo de vida también esta determinado por una gobernanza, lo que dota a nuestra infraestructura de transparencia y confianza para todos los participantes.

Jerarquía de relaciones

La gobernanza define las reglas a seguir en un caso de uso. Sin embargo, el titular de un nodo no está limitado a participar en un único caso de uso. Combine esto con la estructura de gobernanza y obtendrá la siguiente jerarquía de relaciones:

• Una gobernanza:
  • definir uno o varios: miembros, políticas, esquemas y roles.
  • admite uno o varios casos de uso.
• Un participante (persona, entidad u organización):
  • tiene una identidad , y la identidad actúa como miembro de una gobernanza.
  • ejecutar un nodo que almacena muchos sujetos.
  • está involucrado en uno o varios casos de uso.
• Un sujeto:
  • depende de una gobernanza.
  • está modelado por un esquema.
  • tiene espacios de nombres.

1.2 - Sujeto

En lugar de tener un único libro de contabilidad compartido por todos los participantes, la información se estructura sujeto por sujeto. Los sujetos son entidades lógicas que representan un activo o proceso dentro de una red

Cada sujeto cumple con lo siguiente:

• Contiene un único microledger.
• Tiene un estado modelado por un esquema.
• Tiene un solo dueño
• Depende de una gobernanza.

Microledger

Cada sujeto contiene internamente un libro de contabilidad en el que se registran los eventos que afectan únicamente a ese sujeto, el microledger. Este microledger es un conjunto de eventos encadenados mediante mecanismos criptográficos. Es similar a una blockchain en que los diferentes elementos de la cadena se relacionan incluyendo la huella criptográfica del elemento inmediatamente anterior, pero, a diferencia de las blockchains en las que cada bloque puede incluir un conjunto de transacciones, posiblemente de diferentes cuentas, en el microledger. cada elemento representa un único evento del propio sujeto.

Estado del Sujeto

El estado es la representación de la información almacenada por un sujeto en un instante determinado, normalmente el momento actual. El estado se obtiene aplicando, uno tras otro, los diferentes eventos del microledger sobre el estado inicial del sujeto definido en su evento-génesis.

Modelo de propiedad

Cualquier sujeto tiene un único propietario, siendo este el único participante de la red que puede realizar modificaciones efectivas sobre el sujeto, es decir, agregar eventos en el microledger. Sin embargo, otros participantes, los emisores, pueden generar solicitudes de eventos. Estas solicitudes de eventos son firmadas por el emisor y enviadas al propietario del sujeto.

Pertenecer a una gobernanza

Un sujeto siempre existe dentro de un caso de uso. La gobernanza es la definición de las reglas por las que se rige el caso de uso. Qué tipos de sujetos se pueden crear o quién puede crearlos son algunas de las reglas que se definen en la gobernanza. Aunque un sujeto sólo puede pertenecer a una gobernanza, un nodo puede gestionar sujetos de diferente gobernanza, de modo que un mismo nodo pueda participar simultáneamente en diferentes casos de uso.

Espacio de nombres

Cuando se crea un sujeto, se le asocia cierta información, como la gobernanza, el esquema y un espacio de nombres. El espacio de nombres está asociado con el caso de uso y la gobernanza, ya que es el mecanismo mediante el cual se pueden segmentar las partes interesadas. En el mismo caso de uso, no todos los participantes pueden estar interesados ​​en todos los sujetos, sino sólo en un subconjunto de ellos.

Identificador del sujeto y claves

A cada sujeto, en el momento de su creación, se le asigna un par de claves criptográficas con las que firmar los eventos de su microledger. A partir de la clave pública y otros metadatos se genera su Identificador de Asunto (subjectId) , que lo representa de forma única en la red.

1.3 - Roles

Cada participante de la red interactúa con ella en función de diferentes intereses. Estos intereses están representados en Kore como roles

Propietario

Posee el sujeto de trazabilidad y es el nodo responsable de registrar los eventos. Tienen control total sobre el sujeto porque posee el material criptográfico con permisos para modificarlo.

Emisor

Aplicación autorizada a emitir peticiones de eventos, aunque no sea un nodo de la red. Todo lo que necesita para participar en la red es un par de claves criptográficas que permita firmar los eventos, además de tener los permisos necesarios en la gobernanza.

Evaluador

Los evaluadores asumen un papel crucial dentro del marco de gobernanza, siendo responsables de llevar a cabo el proceso de evaluación. Este proceso realiza la ejecución de un contrato, que generalmente resulta en un cambio en el estado del sujeto.

Aprobador

Para que ciertas solicitudes de eventos obtengan aprobación y se agreguen al microledger de un sujeto, es necesaria una serie de firmas. La adquisición de estas firmas depende del resultado de la evaluación. Durante la evaluación de un contrato, se toma una decisión sobre la necesidad de aprobación, que puede verse influenciada por las funciones del emisor solicitante.

Validador

Nodo que valida el orden de los eventos para garantizar la inmunidad a la manipulación. Esto lo consigue no firmando eventos con el mismo ID del sujeto y número de secuencia.

Testigo

Nodos interesados en mantener una copia del registro, aportando también resiliencia.

1.4 - Esquema

El esquema es la estructura del estado contenido en un sujeto.

Los esquemas se definen dentro de una gobernanza y, por tanto, se distribuyen junto con ella. Diferentes gobernanzas pueden definir esquemas equivalentes, sin embargo, para todos los efectos, dado que pertenecen a diferentes gobernanzas, se consideran esquemas diferentes.

Los esquemas se componen de 2 elementos:

• Un identificador único. Cada esquemas tiene un identificador que permite referenciarlo dentro de la gobernanzas en la que está definido. Se pueden definir diferentes esquemas dentro de una misma gobernanzas. Además, siempre que tengan identificadores diferentes, podrás crear esquemas con el mismo contenido.
• Un contenido. Es la estructura de datos utilizada para validar el estado de los sujetos.

{
    "id": {"type":"string"},       
    "content": {"type": "object"}  
}

1.5 - Eventos

Los eventos son las estructuras de datos que representan los hechos que se deben rastrear durante la vida de un sujeto. Estas estructuras constituyen el micrologger, es decir, la cadena de acontecimientos.

Cada evento se compone de lo siguiente:

• La solicitud que generó el evento.
• La huella criptográfica del evento anterior para formar la cadena.
• Una serie de metainformación relacionada con el sujeto y el evento.
• Un grupo de firmas diferentes que se agregan a medida que el evento avanza en su ciclo de vida.

Ciclo de vida

La gobernanza determina el procolo por el que los eventos son incorporados al ciclo de vida del sujeto de trazabilidad. El ciclo de vida del evento se compone de 6 etapas, desde su solicitud de generación hasta su distribución.

1. Solicitud

Para cambiar el estado de un sujeto es necesario agregar un evento a su microledger. Para ello, el primer paso es generar una solicitud de evento . En Kore sólo el propietario del sujeto puede generar eventos sobre el mismo . Sin embargo, estos eventos pueden generarse por solicitudes de otros participantes, conocidos como emisores . De esta forma, el titular actúa como organizador de las solicitudes de eventos, que pueden ser generadas por él mismo o por otros participantes.

Las solicitudes de eventos contienen lo siguiente:

• El tipo de evento a generar.
• La información a incluir en el microledger, por ejemplo, para modificar el estado del sujeto.
• La firma del emisor, que puede ser el propietario del sujeto u otro participante con permisos suficientes.

2. Evaluación

En Kore existen diferentes tipos de eventos y no todos comparten el mismo ciclo de vida. En el caso de los eventos Fact existen 2 pasos adicionales: evaluación y aprobación.

La fase de evaluación corresponde a la ejecución del contrato. Para ello, el titular del sujeto envía la siguiente información a los evaluadores:

• el estado actual del sujeto, ya que los evaluadores no necesitan presenciarla, y por lo tanto pueden no conocer su estado;
• los metadatos del sujeto, como su esquema y espacio de nombres.

Después de recibir la información, el evaluador ejecuta el contrato y devuelve el estado del sujeto modificado al propietario del sujeto, la necesidad o no de aprobación y su firma. El propietario debe recoger tantas firmas de evaluadores como dicta la gobernanza.

3. Aprobación

La evaluación de algunos contratos puede determinar que el resultado, incluso si se ejecuta correctamente, requiere aprobación. Esto significa que, para ser aceptado por los demás participantes, es necesario incluir una serie de firmas adicionales de otros participantes, los aprobadores. Estos aprobadores firman a favor o en contra de una solicitud de evento. Las reglas definidas en la gobernanza indican qué firmas son necesarias para que una petición de evento sea aprobada y, por tanto, para que se genere un evento a partir de esta solicitud.

La decisión de aprobar o no una solicitud puede depender de la participación de un individuo o puede depender de algún sistema de TI, como un proceso de inteligencia empresarial.

4. Generación

El siguiente paso es la generación efectiva del evento. El evento se compone incluyendo la solicitud, la evaluación del contrato, las firmas de los evaluadores y aprobadores, el hash del evento anterior y una serie de metadatos asociados al evento. Luego, el evento se firma con el material criptográfico del sujeto, lo que garantiza que solo el propietario del sujeto pudo generar el evento.

5. Validación

Un evento generado no se puede distribuir directamente. La razón es que los demás participantes en la red no tienen garantía de que el propietario no haya generado versiones diferentes del evento y las haya distribuido según sus propios intereses. Para evitarlo surge la fase de validación. Varios participantes de la red, los validadores, proporcionan su firma al evento, garantizando que existe un único evento. No todas las materias requieren las firmas de los mismos validadores. La gobernanza define qué participantes deben proporcionar sus firmas y cuántas firmas se requieren. El número de firmas dependerá del caso de uso y de la confianza de la red en los miembros que actúan como validadores.

6. Distribución

Una vez que haya suficientes firmas de validación, el evento estará completo y podrá distribuirse al resto de participantes de la red. El propietario envía el evento junto con las firmas de validación a los testigos. Los testigos, una vez comprobada la validez del conjunto, incorporarán el evento al microledger, y borrarán las firmas de validación que tenían almacenadas para el evento anterior.

Tipos de eventos

En cuanto a la estructura y los contenidos de los actos, nos hemos basado en soluciones de diseño reconocidas por la industria ¹. El enfoque habitual es estructurar el evento en una cabecera, con una estructura común para todos los eventos, incluyendo sus metadatos, y una carga útil con información específica para cada evento.

Ejemplo

Diagrama generado un evento tipo Fact.

sequenceDiagram
    actor Emisor
    actor Propietario
    actor Evaluador
    actor Aprobador
    actor Validador
    actor Testigo
    Note over Propietario: 1 - Fase de Petición
    Emisor->>Propietario: Solicitud de evento
    Note over Propietario: 2 - Fase de Evaluación
    alt Evento Fact
      Propietario->>Evaluador: Solicitud de evaluación
      Evaluador->>Propietario: Respuesta de evaluación
    end
    Note over Propietario: 3 - Fase de Aprobación
    alt La evaluación del contrato dice que se requiere aprobación
        Propietario->>Aprobador: Solicitud de aprobación
        Aprobador->>Propietario: Respuesta de aprobación
    end
    Note over Propietario: 4 - Fase de composición
    Propietario->>Propietario: Generación de eventos
    Note over Propietario: 5 - Fase de validación
    Propietario->>Propietario: Generación de pruebas de validación
    Propietario->>Validador: Solicitud de validación
    Validador->>Propietario: Respuesta de validación
    Note over Propietario: 6 - Fase de distribución
    Propietario->>Testigo: Evento
    Testigo->>Propietario: ACK

Diagrama generado un evento tipo State.

sequenceDiagram
    actor Emisor
    actor Propietario
    actor Evaluador
    actor Aprobador
    actor Validador
    actor Testigo
    Note over Propietario: Fase 1 - Solicitud de cambio de estado(Evento State)
    Emisor->>Propietario: Solicita cambio de estado en el sujeto
    Note over Propietario: Fase 2 - Evaluación de la solicitud
    Propietario->>Evaluador: Solicita evaluación de la solicitud
    Evaluador->>Propietario: Devuelve evaluación (positiva o negativa)
    alt Evaluación positiva
        Note over Propietario: Fase 3 - Aprobación (si es necesario)
        alt Aprobación requerida
            Propietario->>Aprobador: Solicita aprobación
            Aprobador->>Propietario: Devuelve aprobación (positiva o negativa)
        end
        Note over Propietario: Fase 4 - Incorporación del evento
        Propietario->>Propietario: Incorpora el evento al registro de eventos
        Note over Propietario: Fase 5 - Validación del evento
        Propietario->>Validador: Solicita validación
        Validador->>Propietario: Devuelve respuesta de validación
        Note over Propietario: Fase 6 - Distribución del evento
        Propietario->>Testigo: Envía evento a testigos
        Testigo->>Propietario: Confirma recepción del evento
    else Evaluación negativa
        Note over Propietario: La solicitud es rechazada
    end

Referencias

1.6 - Identidad

Cada participante de una red Kore Ledger tiene un identificador único y una clave privada que le permite firmar las transacciones realizadas. Además, dependiendo de su interés en cada sujeto y su nivel de implicación con la red, cada participante tendrá uno o varios roles diferentes.

Dada la fuerte influencia de KERI¹ en nuestro proyecto,la reflexión sobre el modelo de referencia para establecer los identificadores en nuestro protocolo parte del triángulo de Zooko². Se trata de un trilema que define tres propiedades deseables deseables en los identificadores de un protocolo de red, de las cuales sólo dos pueden estar simultáneamente. Estas propiedades son:

• Con sentido humano: Nombres significativos y memorables (de baja entropía) a los usuarios.
• Seguro: La cantidad de daño que una entidad maliciosa puede infligir al sistema debe ser lo más bajo posible.
• Descentralizado: Los nombres se resuelven correctamente a sus respectivas entidades sin utilizar una autoridad o servicio central.

Aunque ya se han propuesto varias soluciones al trilema, hemos priorizado la descentralización y la seguridad para aplicar en breve un diseño equivalente al Ethereum Name Service . En concreto, en nuestro enfoque hemos considerado tres tipos de identificadores, que a su vez representan tres tipos de material criptográfico:

• Clave pública, el identificador de los roles participantes en la red.
• Resumen de mensajes, el identificador del contenido de los mensajes resultantes de aplicar una función hash a este contenido.
• Firma criptográfica, identificador de las firmas realizadas por los roles en los mensajes, que sirve como prueba verificable.

Este material criptográfico son grandes números binarios, lo que representa un desafío cuando se utilizan como identificadores. La mejor manera de manejar identificadores es a través de una cadena de caracteres y, para la conversión, hemos adoptado la codificación Base64 , que codifica cada 3 bytes de un número binario en 4 caracteres ASCII. Como el material criptográfico que se gestiona no es múltiplo de 3 (32 bytes y 64 bytes), se rellena con un carácter adicional (32 bytes) o dos (64 bytes). Al igual que en KERI, hemos aprovechado estos caracteres adicionales para establecer un código de derivación para determinar el tipo de material, colocando el o los caracteres de derivación al principio.

La siguiente tabla detalla los códigos de derivación admitidos actualmente :

Ya se han incorporado nuevos tipos de material criptográfico en la hoja de ruta, pensando en dispositivos limitados a operaciones con RSA³ o P256⁴, y la criptografía post-cuántica, como Crystal-Dilithium⁵. En el caso de RSA o Crystal-Dilithium, estamos tratando con un tamaño binario del material criptográfico que es demasiado grande para ser representado como identificadores, por lo que tendremos que incorporar un mecanismo de derivación diferente.

Referencias

1.7 - Nodos

Bootstrap

Son los nodos que con los que establecer conexión de la red de trazabilidad si se dispone de una licencia de acceso. También proporcionan circuitos seguros para comunicar con los nodos efímeros.

Direccionables

Nodos que requieren de una dirección pública. Se puede crear la governanza en ellos para que el efímero emita los eventos correspondientes.

Efímeros

Estos (que normalmente estarán detrás de un NAT/Firewall) serán los encargados de emitir eventos a los nodos Bootstrap.

1.8 - Contratos

Definición

Un contrato en Kore Ledger son las reglas, acuerdos y acciones derivadas de dichos acuerdos que se ejecutan en cada solicitud de evento del ciclo de vida de un sujeto. Del mismo modo que un sujeto tiene siempre un esquema asociado, que define el conjunto de propiedades de su estado, dicho esquema tiene siempre un contrato asociado. Los cambios en su ciclo de vida se producen exclusivamente a través de la ejecución de este contrato.

Estructura

Trabajos futuros

En su definición, nos limitamos exclusivamente al término “contrato”, frente a la denominación utilizada en las tecnologías blockchain de “contrato inteligente”, para ofrecer una mayor precisión sobre su intencionalidad. Los denominados “contratos inteligentes” no son contratos inteligentes y son sólo programas que se ejecutan bajo ciertas condiciones preestablecidas. En nuestro caso, el objetivo es ofrecer una estructura de contrato basada en un lenguaje formal inspirado fundamentalmente en la propuesta FCL (Formal Contract Language) ¹.

Referencias

2 - Conceptos avanzados

2.1 - Proceso de aprobación del evento

La fase de aprobación consiste en pedir a los aprobadores que voten a favor o en contra de la aplicación de un evento. Este proceso puede automatizarse, pero tiende a ser manual. La respuesta requiere interacción con la API de Kore si está configurada como manual, por lo que requiere un usuario que pueda interactuar con ella y, por lo tanto, suele llevar más tiempo que las otras fases.

Los aprobadores están definidos por la gobernanza, por lo que deben poseerlo para realizar la evaluación, de lo contrario no tendrían acceso al contrato, que a su vez se almacena en el estado del gobierno.

Los aprobadores sólo realizarán la evaluación si la versión de la gobernanza que posee el propietario del sujeto coincide con la del aprobador. Si es inferior o superior, se envía al propietario del sujeto un mensaje adecuado a cada caso.

El proceso de aprobación consta de los siguientes pasos:

• El propietario del sujeto verifica si la solicitud de evento requiere aprobación observando la respuesta de los evaluadores.
• Si la solicitud lo requiere, se envía una solicitud de aprobación a los diferentes aprobadores.
• Una vez que cada aprobador tenga la solicitud, podrá votar, tanto a favor como en contra, y la enviará de vuelta al propietario del sujeto.
• Cada vez que el titular reciba un voto comprobará lo siguiente:
  • Hay suficientes votos positivos para que la solicitud sea aceptada.
  • Hay tantos votos negativos que es imposible que se apruebe la solicitud. En ambos casos, el propietario generará un evento. En el caso de que la votación no haya sido exitosa, se generará el evento pero no producirá cambios en el estado del sujeto, quedando con fines meramente informativos.

sequenceDiagram
    actor Owner
    actor Evaluator
    actor Approver 1
    actor Approver 2
    actor Approver 3
    %% Invocador->>Owner: Submit an event request
    Note over Evaluator: Evaluation phase
    alt Need for approval detected
      Owner->Approver 3: Transmit approval request to all approvers
      Approver 1-->>Owner: Receive
      Approver 2-->>Owner: Receive
      Approver 3-->>Owner: Not receive
      Note over Owner: Wait
      Approver 1->>Owner: Vote yes
      Approver 2->>Owner: vote no
      Note over Owner: Receive vote request
      Owner->>Approver 3: Transmit request
      Approver 3-->>Owner: Receive
      Note over Owner: Wait
      Approver 3->>Owner: Vote yes
      Note over Owner: Receive vote request
    end
    alt Positive quorum
      Owner->>Owner: Generate event and update subject
    else Negative quorum
      Owner->>Owner: Generate event
    end
    Owner->Approver 3: Event goes to the validation phase

2.2 - Proceso de evaluación de eventos

La fase de evaluación consiste en que el propietario del sujeto envía una solicitud de evaluación a los evaluadores, justo después de que el emisor generó una solicitud de evento con el tipo de evento y su contenido. Actualmente, la evaluación sólo está presente en eventos de tipo Fact, en los otros tipos se omite. Estos acontecimientos afectan a un determinado sujeto para establecer un Fact que puede modificar o no el estado del sujeto. También se envía un contexto que contiene la información necesaria para que los evaluadores ejecuten el contrato que contiene la lógica de evaluación de nuestro sujeto, como el estado anterior, si el emisor es el propietario del sujeto, etc. Este es el caso porque los evaluadores no necesariamente tienen una copia del sujeto, por lo que necesitan estos datos, que incluyen todo lo necesario para la ejecución del contrato.

Los evaluadores están definidos en la gobernanza, por lo que deben poseerlo para poder realizar la evaluación, de lo contrario no tendrían acceso al contrato, que a su vez se almacena en el estado del gobierno.

El resultado de aplicar el evento al sujeto en términos de modificación de propiedad lo realizan los evaluadores. Tienen la capacidad de compilar y ejecutar contratos compilados en WebAssembly.

La solicitud de evento de Fact contiene la información necesaria para ejecutar una de las funciones del contrato (o no, en cuyo caso se produce una evaluación fallida y se notifica al propietario del sujeto). La respuesta incluye si la evaluación fue exitosa o fallida, si es necesario pasar por la fase de aprobación y el JSON patch que, aplicado al estado del sujeto, producirá el cambio de estado, así como el hash del estado actualizado.

La respuesta de los evaluadores es firmada por ellos para que los testigos puedan verificar que se ha alcanzado el quórum en la fase de evaluación y que han firmado los evaluadores correctos.

Los evaluadores sólo realizarán la evaluación si la versión de la gobernanza que tiene el propietario del sujeto coincide con la del evaluador. Si es inferior o superior, se envía un mensaje adecuado a cada caso al propietario del sujeto.

Para los emisores, cuando se actualiza la gobernanza al que está asignado el sujeto, se debe reiniciar el proceso desde el inicio de la evaluación, ya sea que aún se encontrara en la fase de evaluación o ya en la fase de aprobación. Esto se debe a que los eventos deben evaluarse/aprobarse con la última versión de gobernanza disponible.

sequenceDiagram
actor Owner as Owner
actor Evaluator1 as Evaluator 1
actor Evaluator2 as Evaluator 2
actor Evaluator3 as Evaluator 3

Owner->>Evaluator1: Generate Evaluation Request
Owner->>Evaluator2: Generate Evaluation Request
Owner->>Evaluator3: Generate Evaluation Request

alt Governance Access Granted and Governance Version Matches
    Evaluator1->>Evaluator1: Check Governance and Execute Contract
    Evaluator2->>Evaluator2: Check Governance and Execute Contract
    Evaluator3->>Evaluator3: Check Governance and Execute Contract
    alt Evaluation Successful
        Evaluator1->>Owner: Return Evaluation Response and Evaluator's Signature
        Evaluator2->>Owner: Return Evaluation Response and Evaluator's Signature
        Evaluator3->>Owner: Return Evaluation Response and Evaluator's Signature
    else Evaluation Failed
        Evaluator1->>Owner: Return Evaluation Response (with failed status) and Evaluator's Signature
        Evaluator2->>Owner: Return Evaluation Response (with failed status) and Evaluator's Signature
        Evaluator3->>Owner: Return Evaluation Response (with failed status) and Evaluator's Signature
    end
else Governance Access Denied or Governance Version Mismatch
    Evaluator1->>Owner: Send Appropriate Message
    Evaluator2->>Owner: Send Appropriate Message
    Evaluator3->>Owner: Send Appropriate Message
    Owner->>Owner: Restart Evaluation Process
end

2.3 - Proceso de validación de eventos

El proceso de validación es el último paso antes de lograr un evento válido que pueda incorporarse a la cadena del sujeto. El objetivo de esta fase es asegurar la unicidad de la cadena del sujeto. Se basa en la recogida de firmas de los validadores, que están definidas en la gobernanza. No produce un cambio en el evento en sí, ya que las firmas no están incluidas en el evento, pero son necesarias para validarlo ante los ojos de los testigos. Cabe señalar que para que la unicidad de la cadena sea plenamente efectiva, el quórum de validación debe estar formado por la mayoría de validadores. Esto se debe a que de no ser así se podrían validar varias cadenas con validadores diferentes para cada una si la suma del porcentaje de firmas para todos los quórumes no supera el 100%.

Prueba de validación

Lo que firman los validadores se llama prueba de validación, el evento en sí no está firmado directamente. Esto se hace para garantizar la privacidad de los datos del evento y al mismo tiempo agregar información adicional que permita que el proceso de validación sea más seguro. A su vez, cuando los propietarios de los sujetos envían la prueba a los validadores, ésta también es firmada con el material criptográfico del sujeto. Tiene esta forma:

pub struct ValidationProof {
    /// El identificador del sujeto que está siendo validado.
    pub subject_id: DigestIdentifier,
    /// El identificador del esquema utilizado para validar el sujeto.
    pub schema_id: String,
    /// El espacio de nombres del sujeto que está siendo validado.
    pub namespace: String,
    /// El nombre del sujeto que está siendo validado.
    pub name: String,
    /// El identificador de la clave pública del sujeto que está siendo validado.
    pub subject_public_key: KeyIdentifier,
    /// El identificador del contrato de gobernanza asociado con el sujeto que está siendo validado.
    pub governance_id: DigestIdentifier,
    /// La versión del contrato de gobernanza que creó el sujeto que está siendo validado.
    pub genesis_governance_version: u64,
    /// El número de secuencia del sujeto que está siendo validado.
    pub sn: u64,
    /// El identificador del evento previo en la cadena de validación.
    pub prev_event_hash: DigestIdentifier,
    /// El identificador del evento actual en la cadena de validación.
    pub event_hash: DigestIdentifier,
    /// La versión del contrato de gobernanza utilizado para validar el sujeto.
    pub governance_version: u64,
}

Datos como la versión de la gobernanza(que denominaremos sn), que se usa para verificar que el voto solo debe devolverse si coincide con la versión de la gobernanza del sujeto para el validador, y la clave_pública(que denominaremos subject_id) es la que se usa para validar la firma del propietario de la próxima prueba de validación que llegue al validador.

Si el validador tiene la prueba anterior, puede validar ciertos aspectos, como que el prev_event_hash del nuevo coincida con el event_hash del anterior. La base de datos de los validadores siempre almacenará la última prueba que firmaron para cada sujeto. Esto les permite nunca firmar dos pruebas para el mismo suject_id y sn pero con otros datos diferentes (excepto la sn). Esto garantiza la unicidad de la cadena. La capacidad de cambiar la versión de la gobernanza se debe a lo que discutimos anteriormente: si un validador recibe una prueba con una versión de gobernanza diferente a la suya, no debe firmarla. Por lo tanto, ante actualizaciones de la gobernanza en medio de un proceso de validación, el propietario deberá reiniciar dicho proceso, adaptando la versión de la gobernanza de la prueba a la nueva.

Otro punto interesante es el caso en el que los validadores no cuentan con la prueba anterior para validar la nueva. No existe un escenario donde los validadores siempre tengan la prueba anterior, ya que incluso cuando el quórum requiere el 100% de las firmas, si un cambio de gobernanza agrega un nuevo validador, no tendrá la prueba anterior. Es por esto que cuando se solicita una validación se debe enviar:

pub struct ValidationEvent {
    pub proof: ValidationProof,
    pub subject_signature: Signature,
    pub previous_proof: Option<ValidationProof>,
    pub prev_event_validation_signatures: HashSet<Signature>,
}

La prueba anterior es opcional porque no existe en el caso del evento 0. El hashset de firmas incluye todas las firmas de los validadores que permiten que la prueba anterior haya alcanzado el quórum. Con estos datos, el validador puede confiar en la prueba previa que se le envía si no la dispone previamente.

La comunicación para solicitar validación y enviar validación es directa entre el propietario y el validador y se realiza de forma asíncrona.

Cadena correcta

Como mencionamos anteriormente, la fase de validación se centra en lograr una cadena única, pero no en si esta cadena es correcta. Esta responsabilidad recae en última instancia en los testigos, que son los interesados ​​del sujeto. Los validadores no necesitan tener la cadena actualizada del sujeto para validar la siguiente prueba, ya que las pruebas son autocontenidas y como máximo requieren información de la prueba anterior. Pero nada impide que un propietario malicioso envíe datos erróneos en la prueba, los validadores no se darán cuenta porque no tienen el contexto necesario y firmarán como si todo estuviera correcto. Los testigos, sin embargo, sí tienen el sujeto actualizado, por lo que pueden detectar este tipo de engaños. Si algo así sucediera, los testigos son los encargados de denunciarlo y el sujeto sería bloqueado.

Sequence Diagram

sequenceDiagram
actor Owner as Owner
actor Validator1 as Validator 1
actor Validator2 as Validator 2
actor Validator3 as Validator 3
actor Witness as Witness

Owner->>Validator1: Send ValidationEvent
Owner->>Validator2: Send ValidationEvent
Owner->>Validator3: Send ValidationEvent

alt Governance Version Matches and Proofs are Valid
    Validator1->>Validator1: Inspect Governance, Check Last Proof and Signatures
    Validator2->>Validator2: Inspect Governance, Check Last Proof and Signatures
    Validator3->>Validator3: Inspect Governance, Check Last Proof and Signatures
    Validator1->>Owner: Return ValidationEventResponse with Validator's Signature
    Validator2->>Owner: Return ValidationEventResponse with Validator's Signature
    Validator3->>Owner: Return ValidationEventResponse with Validator's Signature
else Governance Version Mismatch or Proofs are Invalid
    Validator1->>Owner: Send Appropriate Message (if applicable)
    Validator2->>Owner: Send Appropriate Message (if applicable)
    Validator3->>Owner: Send Appropriate Message (if applicable)
    Note over Validator1,Validator3: End Process (No Response)
end

Owner->>Owner: Collect Enough Validator Signatures
Owner->>Witness: Create Event in Ledger and Distribute

3 - Glosario

A

Aprobador

Algunas solicitudes de eventos requieren una serie de firmas para ser aprobadas y pasar a formar parte del microledger del sujeto. Esta recogida de firmas es un proceso de votación donde los participantes pueden votar a favor o en contra. Estos participantes, definidos en la gobernanza, son los aprobadores.

B

Bootstrap

Es parte del protocolo Kademlia. Es el nombre del nodo que se utiliza para todos los nodos de noticias que quieren unirse a la red P2P para ser descubiertos por todos los demás.

Blockchain

Blockchain es un subtipo de DLT, y por tanto podemos decir que es fundamentalmente una base de datos distribuida, descentralizada, compartida e inmutable.

C

Criptografía

Es la práctica y el estudio de técnicas para la comunicación segura en presencia de conductas adversas.

D

DLT

• Inmutable y resistente a manipulaciones. Implementa mecanismos de seguridad criptográfica que evitan que su contenido sea alterado, o al menos, si algún nodo intenta modificar la información, puede ser detectado y bloqueado fácilmente. Significa “Tecnología de contabilidad distribuida”. Una DLT no es más que una base de datos que actúa como un libro mayor pero que además tiene, en mayor o menor medida, las siguientes características:

• Está distribuido y descentralizado.
• Compartido.
• Inmutable y resistente a manipulaciones.

Dispositivos perimetrales

Un dispositivo que proporciona un punto de entrada a las redes centrales de la empresa o del proveedor de servicios.

E

Evento

El incidente que se produce cuando se pretende modificar el estado de un sujeto.

F

Fog Computing

Es una arquitectura que utiliza dispositivos periféricos para llevar a cabo una cantidad sustancial de computación, almacenamiento y comunicación localmente y enrutada a través de la red troncal de Internet.

Fog GateWay

Sinónimo de dispositivos perimetrales. Un dispositivo que proporciona un punto de entrada a las redes centrales de la empresa o del proveedor de servicios.

G

Gobernanza

La gobernanza es una estructura a través de la cual un participante o usuario de un sistema acepta utilizar el sistema. Podemos decir fácilmente que hay tres principios que dictan la gobernanza. Estos principios incluyen:

• Gobernando
• Reglas
• Participantes

k

Kademlia

Es un DTL que define la estructura de la red y cómo se intercambia la información mediante búsquedas de nodos. Las comunicaciones se realizan mediante UDP y, en el proceso, se crea una red superpuesta de nodos identificados por una ID. Esta ID no solo es útil para identificar el nodo sino también para determinar la distancia entre dos nodos para que el protocolo pueda determinar con quién debe comunicarse.

Kore

Significa “Seguimiento (autónomo) de eventos de procedencia y ciclo de vida”. Kore es una solución DLT autorizada para la trazabilidad de activos y procesos.

Kore Node

Cliente oficial para crear un Nodo Kore. Es la forma más sencilla de trabajar con Kore, ya que es una aplicación de consola simple que proporciona todo lo necesario para construir un nodo (Kore Base, API Rest y diferentes configuraciones de mecanismos).

Kore Base

Es la biblioteca que implementa la mayor parte de la funcionalidad de Kore (creación y gestión de temas y sus microledgers asociados, implementación del protocolo P2P para la comunicación entre nodos y persistencia de la base de datos). Cualquier aplicación que quiera formar parte de una red Kore deberá hacer uso de esta biblioteca desde la API que expone.

Kore Network

Es la red P2P creada por todos los nodos de Kore en funcionamiento.

L

Ledger

Un libro mayor es un concepto contable que básicamente define un libro mayor en el que siempre se agrega información, generalmente en forma de transacciones.

M

Microledger

El microledger es un conjunto de eventos encadenados entre sí mediante mecanismos criptográficos.

Multiaddr

Una multiaddress (a menudo abreviada multiaddr) es una convención para codificar múltiples capas de información de direcciones en una única estructura de ruta “preparada para el futuro”. Ofrece codificaciones legibles por humanos y optimizadas para máquinas de protocolos de superposición y transporte comunes y permite combinar y utilizar juntas muchas capas de direccionamiento.

N

Nodo

Es una computadora conectada a otras computadoras que sigue reglas y comparte información.

P

P2P

Es una arquitectura de aplicación distribuida que divide tareas o cargas de trabajo entre pares igualmente privilegiados y participantes equipotentes en la red que la conforman.

S

Sujeto

Los sujetos son una entidad lógica o proceso que almacena todos los datos necesarios para definirse y que emite eventos a lo largo de su ciclo de vida con un orden de emisión determinado por él mismo.

T

Transacción

Es un acuerdo o comunicación entre 2 entidades diferentes para aceptar un cambio en el estado de un sujeto.

Testigo

Participante interesado en tener una copia del sujeto y la información que almacena.

V

Validador

El validador es un participante de la red que proporciona la firma de seguridad al sujeto. El validador mantiene una copia completa de los sujetos que valida y se compromete con la red a no aceptar más de una versión del mismo evento.