Getting Started

• 1: Concepts
• 1.1: Governance
• 1.2: Subject
• 1.3: Roles
• 1.4: Schema
• 1.5: Events
• 1.6: Identity
• 1.7: Contracts
• 1.8: Node
• 2: Advanced concepts
• 2.1: Event approval process
• 2.2: Event evaluation process
• 2.3: Event validation process
• 3: Glossary

1 - Concepts

1.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.

1.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.

1.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.

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

1.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

1.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

1.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

1.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.

2 - Advanced concepts

2.1 - Event approval process

The approval phase involves asking the approvers to vote for or against the application of an event. This process can be automated but tends to be manual. The response requires interaction with the Kore API if it’s set to manual, so it requires a user who can interact with it and therefore generally takes longer than the other phases.

The approvers are defined by the governance, so they must possess it in order to carry out the evaluation, otherwise they would not have access to the contract, which in turn is stored in the state of the governance.

The approvers will only carry out the evaluation if the version of the governance that the subject’s owner has coincides with that of the approver. If it is lower or higher, an appropriate message for each case is sent to the subject’s owner.

The approval process consists of the following steps:

• The subject owner checks whether the event request requires approval by looking at the response of the evaluators.
• If the request requires it, an approval request is sent to the different approvers.
• Once each approver has the request, they will be able to vote, both for and against, and will send it back to the owner of the subject.
• Every time the owner receives a vote, he will check the following:
  • There are enough positive votes for the application to be accepted.
  • There are so many negative votes that it is impossible to get the application approved. In both cases, the owner will generate an event. In the case that the vote has not been successful, the event will be generated but it will not produce changes in the state of the subject, remaining merely for informational purposes.

sequenceDiagram
    %% Comentarios pendientes a que este la invocación externa
    %% actor Invocador
    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 - Event evaluation process

The evaluation phase consists of the owner of th subject sending an evaluation request to the evaluators, just after the issuer generated an event request with the event type and its content. Currently, evaluation is only present in Fact type events, in the other types it’s skipped. These events affect a certain subject to establish a fact that may or may not modify the subject’s state. A context is also sent containing the necessary information for the evaluators to execute the contract that contains the evaluation logic for our subject, such as previous state, whether the issuer is the owner of the subject, etc. This is the case because the evaluators do not necessarily have a copy of the subject, so they need this data, which includes everything necessary for the execution of the contract.

The evaluators are defined by the governance, so they must possess it in order to carry out the evaluation, otherwise they would not have access to the contract, which in turn is stored in the state of the governance.

The result of applying the event to the subject in terms of property modification is carried out by the evaluators. They have the ability to compile and execute contracts compiled in web assembly.

The Fact event request contains the necessary information to execute one of the functions of the contract (or not, in which case a failed evaluation occurs and the subject owner is notified). The response includes whether the evaluation was successful or failed, if it is necessary to go through the approval phase and the JSON patch that, when applied to the subject’s state, will produce the state change, as well as the hash of the updated state.

The evaluators response is signed by them so that the witnesses can verify that quorum has been reached in the evaluation phase and that the correct evaluators have signed.

The evaluators will only carry out the evaluation if the version of the governance that the subject’s owner has coincides with that of the evaluator. If it is lower or higher, an appropriate message for each case is sent to the subject’s owner.

For issuers, when the governance to which the subject is assigned is updated, the process must be restarted from the beginning of the evaluation, whether you were still in the evaluation phase or already in the approval phase. This is because events must be evaluated/approved with the latest version of governance available.

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 - Event validation process

The validation process is the last step before achieving a valid event that can be joined to the subject’s chain. The aim of this phase is to ensure the uniqueness of the subject’s chain. It is based on the collection of signatures from the validators, which are defined in the governance. It does not produce a change in the event itself, as the signatures are not included in the event, but they are necessary to validate it in the eyes of the witnesses. It is noteworthy that for the uniqueness of the chain to be fully effective, the validation quorum needs to consist of the majority of validators. This is because if not, several chains could be validated with different validators for each one if the sum of the signature percentage for all quorums does not exceed 100%.

Proof of validation

What the validators sign is called proof of validation, the event itself is not directly signed. This is done to ensure the privacy of the event’s data and at the same time add additional information that allows the validation process to be safer. In turn, when the owners of the subjects send the proof to the validators, it is also signed with the subject’s cryptographic material. It has this form:

pub struct ValidationProof {
    /// The identifier of the subject being validated.
    pub subject_id: DigestIdentifier,
    /// The identifier of the schema used to validate the subject.
    pub schema_id: String,
    /// The namespace of the subject being validated.
    pub namespace: String,
    /// The name of the subject being validated.
    pub name: String,
    /// The identifier of the public key of the subject being validated.
    pub subject_public_key: KeyIdentifier,
    /// The identifier of the governance contract associated with the subject being validated.
    pub governance_id: DigestIdentifier,
    /// The version of the governance contract that created the subject being validated.
    pub genesis_governance_version: u64,
    /// The sequence number of the subject being validated.
    pub sn: u64,
    /// The identifier of the previous event in the validation chain.
    pub prev_event_hash: DigestIdentifier,
    /// The identifier of the current event in the validation chain.
    pub event_hash: DigestIdentifier,
    /// The version of the governance contract used to validate the subject.
    pub governance_version: u64,
}

Data such as the governance_version, which is used to verify that the vote should only be returned if it matches the subject’s governance version for the validator, and the subject_public_key is the one used to validate the owner’s signature of the next proof of validation that reaches the validator.

If the validator has the previous proof, they can validate certain aspects, such as the prev_event_hash of the new one matches the event_hash of the previous one. The validators’ database will always store the last proof they signed for each subject. This allows them never to sign two proofs for the same subject_id and sn but with different other data (except for the governance_version). This guarantees the uniqueness of the chain. The ability to change the governance_version is due to what we discussed earlier: if a validator receives a proof with a different governance version than theirs, they should not sign it. Therefore, facing updates of the governance in the middle of a validation process, the owner must restart said process, adapting the governance_version of the proof to the new one.

Another interesting point is the case where validators do not have the previous proof to validate the new one. There is no scenario where validators always have the previous proof, since even when the quorum requires 100% of the signatures, if a change in governance adds a new validator, they will not have the previous proof. This is why when a validation is requested, it should send:

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

The previous proof is optional because it does not exist in the case of event 0. The hashset of signatures includes all the signatures of the validators that allow the previous proof to have reached quorum. With this data, the validator can trust the previous proof sent to them if they do not previously have it.

The communication to request validation and to send validation is direct between the owner and the validator and is carried out asynchronously.

Correct Chain

As we mentioned earlier, the validation phase focuses on achieving a unique chain, but not on whether this chain is correct. This responsibility ultimately falls on the witnesses, who are the subject’s stakeholders. The validators do not need to have the subject’s updated chain to validate the next proof, as the proofs are self-contained and at most require information from the previous proof. But nothing prevents a malicious owner from sending erroneous data in the proof, the validators will not realize it because they do not have the necessary context and will sign as if everything was correct. The witnesses, however, do have the updated subject, so they can detect this kind of tricks. If something like this were to happen, the witnesses are the ones responsible for reporting it and the subject would be blocked.

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 - Glossary

A

Approver

Some event requests require a series of signatures to be approved and become part of a subject’s microledger. This signature collection is a voting process where participants can vote in favor or against. These participants, defined in governance, are the approvers.

B

Bootstrap

It is part of the Kademlia protocol. It is the name of the node that is used for all news nodes that want to join the P2P Network to be discovered by all others.

Blockchain

Blockchain is a subtype of DLT, and therefore we can say that it is fundamentally a distributed, decentralized, shared, and immutable database.

C

Cryptography

It is the practice and study of techniques for secure communication in the presence of adversarial behavior.

D

DLT

• Immutable and tamper-resistant. It implements cryptographic security mechanisms that prevent its content from being altered, or at least, if any node tries to modify the information, it can be easily detected and blocked. Stands for “Distributed Ledger Technology”. A DLT is nothing more than a database that acts as such a ledger but also has, to a greater or lesser extent, the following characteristics:

• It is distributed and decentralised.
• Shared.
• Immutable and tamper-resistant.

E

Edge Devices

A device that provides an entry point into enterprise or service provider kore networks.

Event

The incident that occurs when the state of a subject is intended to be modified.

F

Fog Computing

It is an architecture that uses edge devices to carry out a substantial amount of computation, storage and communication locally and routed over the internet backbone.

Fog GateWay

Synonym for Edge Devices. A device that provides an entry point into enterprise or service provider kore networks.

G

Governance

Governance is a structure through which a participant or user of a system agrees to use the system. We can easily say that there are three principles that dictate governance. These principles include:

• Governing
• Rules
• Participants

K

Kademlia

It is a DTL that defines the structure of the network and how the information is exchanged through node lookups. The communications it’s done using UDP and in the process, an overlay network of nodes identified by an ID is created. This ID is not only to useful to identify the node but also useful to determine the distance between two nodes so the protocol can determine with whom it should communicate.

Kore

Stands for “Tracking (Autonomous) of Provenance and Lifecycle Events​”. Kore is a permissioned DLT solution for traceability of assets and processes.

Kore Node

Official client to create a Kore Node. It is the easiest way to work with Kore as it is a simple console application that provides everything needed to build a node (Kore Base, API Rest and different mechanisms settings).

Kore Base

It is the library that implements most of the Kore functionality (creation and management of subjects and their associated microledgers, implementation of the P2P protocol for communication between nodes and database persistence). Any application that wants to be part of a Kore network must make use of this library from the API it exposes.

Kore Network

It is the P2P network created by all the Kore nodes in operation.

L

Ledger

A ledger is an accounting concept that basically defines a ledger in which information is always being added, usually in the form of transactions.

M

Microledger

The microledger is a set of events chained together using cryptographic mechanisms.

Multiaddr

A multiaddress (often abbreviated multiaddr), is a convention for encoding multiple layers of addressing information into a single “future-proof” path structure. It human-readable and machine-optimized encodings of common transport and overlay protocols and allows many layers of addressing to be combined and used together.

N

Node

It is a computer connected to other computers that follows rules and shares information.

P

P2P

It is a distributed application architecture that partitions tasks or workloads between peers equally privileged and equipotent participants in the network that make up.

S

Subject

Subjects are a logical entity or process that stores all the data necessary to define itself and that emits events throughout its life cycle with an order of emission determined by itself.

T

Transaction

It is an agreement or communication between 2 different entities to accept a change in the state of a subject.

V

Validator

The validator is a network participant who provides the security signature to the subject. The validator maintains a complete copy of the subjects it validates and commits to the network not to accept more than one version of the same event.

W

Witness

Participant interested in having a copy of the subject and the information it stores.