Conceptos

• 1: Gobernanza
• 2: Sujeto
• 3: Roles
• 4: Esquema
• 5: Eventos
• 6: Identidad
• 7: Nodos
• 8: Contratos

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.

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.

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.

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"}  
}

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

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

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.

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