Concepts

• 1: Governance
• 2: Subject
• 3: Roles
• 4: Schema
• 5: Events
• 6: Identity
• 7: Contracts
• 8: Node

1 - Governance

The governance is the set of definitions and rules that establish how the different nodes participating in a network relate to the subjects of traceability and interact with each other. The components of governance are:

• The participating nodes.
• The schema of the attributes of the subjects.
• The contract to apply the events that modify the state of the subject.
• The permissions of each participant to participate in the network.

Members

These are the persons, entities or organizations that participate in governance and therefore may be part of the supported use cases. Each member declares a unique identifier representing the cryptographic material with which it will operate in the network, its identity .

Schemas

Schemas are the data structures that model the information stored in the subjects. Within a governance, different schemas can be defined to support different use cases. When a subject is created, it defines which governance it is associated with and which schema it will use. In addition, each schema has an associated contract that will allow you to modify the state of the subjects.

Roles

Roles represent groups of participants with some kind of common interest in a set of subjects. Roles allow us to assign permissions on these groups of subjects more easily than if we had to assign them individually to each member of the government.

Policies

The policies define the specific conditions under which the life cycle of an event is affected, such as the number of signatures required to carry out the evaluation, approval and validation processes. This is called quorum. The governance configuration allows the definition of [different types of quorum] , more or less restrictive, depending on the need of the use case.

Governance as a subject

The governance is a subject of traceability, since it can evolve and adapt to business needs, and therefore its lifecycle is also determined by a governance, which endows our infrastructure with transparency and trust for all participants.

Hierarchy of relationships

Governance defines the rules to be followed in a use case. However, the owner of a node is not limited to participate in a single use case. Combine this with the governance structure and you get the following hierarchy of relationships:

• One governance:
  • define one or more: members, policies, schemas and roles.
  • A governance: support one or more use cases.
• A participant (person, entity or organization):
  • has an identity , and the identity acts as a member of a governance.
  • runs a node that stores many subjects.
  • Is involved in one or more use cases.
• A subject:
  • depends on a governance.
  • is modeled by a schema.
  • has namespaces.

2 - Subject

Instead of having a single ledger shared by all participants, the information is structured subject by subject. Subjects are logical entities that represent an asset or process within a network.

Each subject complies with the following:

• It contains a single microledger.
• It has a state modeled by a schema.
• It has a single owner.
• Depends on a governance.

Microledger

Each subject internally contains a ledger in which events affecting only that subject are recorded, the microledger. This microledger is a set of events chained together using cryptographic mechanisms. It is similar to a blockchain in that the different elements of the chain are related including the cryptographic fingerprint of the immediately preceding element, but, unlike blockchains where each block may include a set of transactions, possibly from different accounts, in the microledger. each element represents a single event of the subject itself.

Subject State

The state is the representation of the information stored by a subject at a given instant, usually the current time. The state is obtained by applying, one after the other, the different events of the microledger on the initial state of the subject defined in its event-genesis.

Ownership model

Any subject has a single owner, this being the only participant in the network that can make effective modifications on the subject, i.e., add events in the microledger. However, other participants, the senders, can generate event requests. These event requests are signed by the sender and sent to the subject owner.

Belonging to a governance

A subject always exists within a use case. Governance is the definition of the rules by which the use case is governed. What types of subjects can be created or who can create them are some of the rules that are defined in governance. Although a subject can only belong to one governance, a node can manage subjects of different governance, so that the same node can participate simultaneously in different use cases.

Namespace

When a subject is created, certain information is associated with it, such as governance, schema and a namespace. The namespace is associated with the use case and governance, as it is the mechanism by which stakeholders can be segmented. In the same use case, not all participants may be interested in all subjects, but only in a subset of them.

Subject identifier and keys

Each subject, at the time of its creation, is assigned a pair of cryptographic keys with which to sign the events of its microledger. From the public key and other metadata, its Subject Identifier (subjectId) , which uniquely represents it in the network, is generated.

3 - Roles

Each participant in the network interacts with it based on different interests. These interests are represented in Kore as roles

Owner

Owns the traceability subject and is the node responsible for recording events. They have full control over the subject because they own the cryptographic material with permissions to modify it.

Issuer

Application authorized to issue event requests, even if it is not a network node. All it needs to participate in the network is a cryptographic key pair that allows signing events, as well as having the necessary permissions in governance.

Evaluator

Evaluators assume a crucial role within the governance framework, being responsible for carrying out the evaluation process. This process performs the execution of a contract, which generally results in a change in the subject’s status.

Approver

In order for certain event requests to obtain approval and be added to a subject’s microledger, a number of signatures are required. The acquisition of these signatures depends on the outcome of the evaluation. During the evaluation of a contract, a decision is made on the need for approval, which may be influenced by the roles of the requesting issuer.

Validator

Node that validates the order of events to guarantee immunity to manipulation. This is achieved by not signing events with the same subject ID and sequence number.

Witness

Nodes interested in keeping a copy of the log, also providing resilience.

4 - Schema

The schema is the structure of the state contained in a subject.

The schemas are defined within a governance and are therefore distributed together with it. Different governances may define equivalent schemas, however, for all intents and purposes, since they belong to different governances, they are considered different schemas.

The schemas are composed of 2 elements:

• A unique identifier. Each schema has an identifier that allows it to be referenced within the governance in which it is defined. Different schemas can be defined within the same governance. In addition, as long as they have different identifiers, you can create schemas with the same content.
• A content. It is the data structure used to validate the status of the subjects.

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

5 - Events

Events are the data structures that represent the facts to be tracked during the life of a subject. These structures constitute the micrologger, i.e. the chain of events.

Each event is composed of the following:

• The request that generated the event.
• The cryptographic fingerprint of the previous event to form the chain.
• A set of meta-information related to the topic and the event.
• A set of different signatures that are added as the event progresses through its lifecycle.

Life cycle

The governance determines the process by which events are incorporated into the life cycle of the traceability subject. The event lifecycle is composed of 6 stages, from its request for generation to its distribution.

1. Request

To change the state of a subject it is necessary to add an event to its micro-ledger. To do this, the first step is to generate an event request . In Kore only the owner of the subject can generate events on the subject. However, these events can be generated by requests from other participants, known as issuers . In this way, the owner acts as the organizer of event requests, which can be generated by himself or by other participants.

Event requests contain the following:

• The type of event to generate.
• The information to be included in the microledger, e.g., to modify the subject status.
• The signature of the sender, which may be the owner of the subject or another participant with sufficient permissions.

2. Evaluation

In Kore there are different types of events and not all of them share the same life cycle. In the case of fact events there are 2 additional steps: evaluation and approval.

The evaluation phase corresponds to the execution of the contract. For this, the subject holder sends the following information to the evaluators:

• the current status of the subject, since the evaluators do not need to witness it, and therefore may not know its status;
• the subject’s metadata, such as its schema and namespace.

After receiving the information, the evaluator executes the contract and returns the modified subject state to the subject owner, the need or not for approval and his signature. The owner must collect as many evaluator signatures as governance dictates.

3. Approval

The evaluation of some contracts may determine that the result, even if properly executed, requires approval. This means that, in order to be accepted by the other participants, it is necessary to include a number of additional signatures from other participants, the approvers. These approvers sign for or against an event request. The rules defined in the governance indicate which signatures are necessary for an event request to be approved and, therefore, for an event to be generated from this request.

The decision to approve or disapprove a request may depend on the participation of an individual or it may depend on some IT system, such as a business intelligence process.

4. Generation

The next step is the actual generation of the event. The event is composed including the request, the contract evaluation, the signatures of the evaluators and approvers, the hash of the previous event and a series of metadata associated with the event. The event is then signed with the subject cryptographic material, which ensures that only the owner of the subject was able to generate the event.

5. Validation

A generated event cannot be distributed directly. The reason is that the other participants in the network have no guarantee that the owner has not generated different versions of the event and distributed them according to his own interests. To avoid this, the validation phase arises. Several network participants, the validators, provide their signature to the event, guaranteeing that a single event exists. Not all subjects require the signatures of the same validators. Governance defines which participants must provide their signatures and how many signatures are required. The number of signatures will depend on the use case and the network’s trust in the members acting as validators.

6. Distribution

Once there are enough validation signatures, the event is complete and can be distributed to the rest of the network participants. The owner sends the event along with the validation signatures to the tokens. The witnesses, once the validity of the set has been verified, will incorporate the event into the microledger, and will delete the validation signatures they had stored for the previous event.

Types of events

As for the structure and contents of the events, we have relied on industry-recognized design solutions ¹. The usual approach is to structure the event in a header, with a common structure for all events, including their metadata, and a payload with specific information for each event.

Example

Diagram generated an event type Fact.

sequenceDiagram
    actor Issuer
    actor Owner
    actor Evaluators
    actor Approvers
    actor Validators
    actor Witnesses
    Note over Owner: Request phase
    Issuer->>Owner: Event request
    Note over Owner: Evaluation phase
    alt Is a Fact Event
      Owner->>Evaluators: Evaluation request
      Evaluators->>Owner: Evaluation respond
    end
    Note over Owner: Approval phase
    alt Contract evaluation says that approval is required
        Owner->>Approvers: Approval request
        Approvers->>Owner: Approval respond
    end
    Note over Owner: Composition phase
    Owner->>Owner: Event generation
    Note over Owner: Validation phase
    Owner->>Owner: Validation proof generation
    Owner->>Validators: Validation request
    Validators->>Owner: Validation response
    Note over Owner: Distribution phase
    Owner->>Witnesses: Event
    Witnesses->>Owner: ACK

Referencias

6 - Identity

Each participant in a Kore Ledger network has a unique identifier and a private key that allows him/her to sign the transactions made. In addition, depending on their interest in each subject and their level of involvement with the network, each participant will have one or more different roles.

Given the strong influence of KERI¹ in our project, the reflection on the reference model to establish the identifiers in our protocol starts from Zooko’s triangle². This is a trilemma that defines three desirable properties desirable in the identifiers of a network protocol, of which only two can be simultaneously. These properties are:

• Human Meaningful: Meaningful and memorable (low entropy) names to users.
• Secure: The amount of damage a malicious entity can inflict on the system should be as low as possible.
• Decentralized: Names are correctly resolved to their respective entities without using a central authority or service.

Although several solutions to the trilemma have already been proposed, we have prioritized decentralization and security to shortly implement a design equivalent to the Ethereum Name Service . Specifically, in our approach we have considered three types of identifiers, which in turn represent three types of cryptographic material:

• Public key, the identifier of the roles participating in the network.
• Message digest, the identifier of the content of messages resulting from applying a hash function to this content.
• Cryptographic signature, the identifier of the signatures made by the roles on the messages, which serves as verifiable proof.

This cryptographic material is large binary numbers, which presents a challenge when used as identifiers. The best way to handle identifiers is through a string of characters and, for conversion, we have adopted the Base64 encoding, which encodes every 3 bytes of a binary number into 4 ASCII characters. As the cryptographic material to be managed is not a multiple of 3 (32 bytes and 64 bytes), it is filled with an additional character (32 bytes) or two (64 bytes). As in KERI, we have taken advantage of these additional characters to establish a derivation code to determine the type of material by placing the derivation character(s) at the beginning.

The following table details the currently supported derivation codes:

New types of cryptographic material have already been incorporated into the roadmap, thinking of devices limited to operations with RSA³ or P256⁴, and post-quantum cryptography, such as Crystal-Dilithium⁵. In the case of RSA or Crystal-Dilithium, we are dealing with a binary size of cryptographic material that is too large to be represented as identifiers, so we will have to incorporate a different derivation mechanism.

References

7 - Contracts

Definition

A contract in Kore Ledger is the rules, agreements and actions derived from those agreements that are executed on each event request in the life cycle of a subject. Just as a subject always has an associated schema, which defines the set of properties of its state, such a schema always has an associated contract. Changes in its life cycle occur exclusively through the execution of this contract.

Structure

Future work

In its definition, we limit ourselves exclusively to the term “contract”, as opposed to the denomination used in blockchain technologies of “smart contract”, in order to provide greater precision on its intentionality. So-called “smart contracts” are not smart contracts and are just programs that are executed under certain pre-set conditions. In our case, the goal is to offer a contract structure based on a formal language fundamentally inspired by the proposed FCL (Formal Contract Language) ¹.

References

8 - Node

Bootstrap

These are the nodes with which to establish a connection to the traceability network if an access license is available. They also provide secure circuits to communicate with the ephemeral nodes.

Addressable

Nodes that require a public address. Governance can be created on them so that the ephemeral emits the corresponding events.

Ephemeral

These (which will normally be behind a NAT/Firewall) will be in charge of emitting events to the Bootstrap nodes.