Skip to main content

Krama Context Engine

The context of a participant in the MOI network is managed by the Krama Context Engine, which is responsible for the creation of context and its growth.


Figure: Krama Context Engine

Context Populator

Context Populator is responsible for the creation and growth of the participant context. This component of the engine manages the Network Context of a Participant.

The Network Context is comprised of 3 parts namely:

  • Behavioral Nodes: It consists of Krama Node IDs which are chosen based on the behaviour and participation of the wallet in the network.

  • Random Nodes: This context consists of Krama Node IDs which are randomly updated for every interaction. This is made possible by using the Context Randomizer.

  • User Nodes: This context consists of Krama Node IDs which are chosen by the user.

Hence, the Network Context of a participant’s wallet W is defined as shown below:

xw=αWβWƔWx_{w}= {α_W \cup β_W \cup Ɣ_W}

Where αWα_W is the set of Behavioral nodes, βWβ_W is the set of Random nodes, and ƔWƔ_W is the set of User specified nodes, such that αWα_W, βWβ_W, and ƔWƔ_W belongs to the global set of all nodes in the MOI network, and elements in αWα_W,βWβ_W, ƔWƔ_W are mutually exclusive, such that the following condition should be met:

n(αWβWƔW)=max(LO,LU)n(α_W \cup β_W \cup Ɣ_W) = max( L_O, L_U )

where LoL_o is the Liveness floor value, which is the minimum number of nodes that must be present in the wallet’s context say 5 nodes; and LUL_U is the ceiling value of the Liveness, for example, 5% of Network Size. Both LoL_o and LuL_u are customizable during the genesis of the network. These values are defined at the protocol level.

Context Creation

When a wallet with a null Network Context attempts to interact with the network, the Interaction is executed by a Guardian Interaction Set. A wallet may have a null context because it is either a new wallet or has had its context reset.

The Guardian Interaction Set is a special-purpose ICS formed for the inception of a wallet’s context. The composition of this ICS is uniquely determined based on a guardian co-efficient which decays over time as the network matures and stabilizes.

The guardian co-efficient is the minimum percentage of guardian nodes prescribed by the protocol to participate in the Guardian Interaction Set. It is denoted by the symbol gA with a default value of 66 %. Meaning, a non-dominant majority of the nodes in the Guardian Interaction Set will be comprised of nodes hosted by the MOI foundation and vested stakeholders such as early investors, core developers, and so on. The remainder of the nodes in the Guardian Interaction Set are randomly picked from the network. A decay time will be proposed once the network is operational with the critical mass of users who can vote on the decay time proposal. The mathematical notations of the conditions to form Guardian Interaction Set are:

G=ac,where:aA, such that: n(a)=gAn(G) andcC, such that: n(c)=n(G)n(a) and ca=G = a \cup c, \text{where:} \\ \, \\ a \subset A, \ \text{such that:}\ n(a) = gA * n(G) \ \text{and} \\ \, \\ c \subset C, \ \text{such that:}\ n(c) = n(G) - n(a) \ \text{and}\ c \cap a = ∅

Where G is the Guardian Interaction Set, a is a subset of A , a global set of nodes operated by the foundation and vested stakeholders, and c is a subset of C , the total set of nodes in the network apart mutually exclusive from A. The size of the Guardian Interaction Set is determined just like a regular ICS.

After the Interaction has been executed, αWα_W is populated with the Krama Node ID of the Guardian Interaction Set’s Operator, and the βWβ_W is populated with nodes provided by the Context Randomizer. Any changes to ƔWƔ_W are also populated at this time.

Upon context creation, the context signature is created by the guardian validators and added to the tesseract.

Context Growth

The network context of the participants grows as they continue to interact in the network. After successfully achieving consensus for each interaction, the Network Context of the participant will be updated as shown below:

Context Growth (αW,βW,ƔW)=(αW,βW,ƔW),where αW=αWNO, andβW=NewRandomSet(βW) such that βWβW, andƔW=AddUserNode(ƔW) such that ƔW!=ƔW\text{Context Growth}\ (α_W , β_W , Ɣ_W) = (α_W’, β_W’ , Ɣ_W’), \\ \, \\ \text{where} \ α_W’ = α_W \cup N_O , \ \text{and} \\ \, \\ β_W’ = NewRandomSet(β_W) \ \text{such that} \ β_W’ ⊈ β_W , \ \text{and} \\ \, \\ Ɣ_W’ = AddUserNode( Ɣ_W) \ \text{such that} \ Ɣ_W’ != Ɣ_W

Upon context creation, the context signature is created by the operator and added to the tesseract.

Context Randomizer

The Context Randomizer is responsible for providing the protocol with random nodes from across the network. These random nodes are used by the Optimized Network Clustering Engine when forming the ICS cluster as it requires a set of random nodes to join the cluster. It is also used by the Context Populator when it requires a set of random nodes for context creation and growth.

Random Node Pool

The randomizer maintains a set of random nodes in a node pool. This pool contains N number of tables each with S number of nodes. NdN_d is the network depth determined by log10(Nk)log_{10}(N_k), where NkN_k is the total number of nodes in the network and 10 is the average number of connections maintained by a peer. S is a number determined from the minimum sampling ratio based on NkN_k.

When the pool is queried for n number of random nodes if n < S, a table from the pool is consumed and n number of nodes from that table are returned. If n > S, the number of tables required will be consumed. If n>SNdn > S*N_d, then all nodes from all tables will be consumed and the randomizer will start a random walk for new nodes until n is reached and returns it.

The entire pool is refreshed at a regular interval by starting a random walk for each value between 1 and Nd corresponding to each table in the pool. The pool is also refreshed if 2/3rd of the tables in it is consumed. The unconsumed tables will be available while the random walk completes populating the other tables with new nodes.

When enough nodes for a table have been collected, the table becomes available again and any other nodes that are received after the table is full are queued up for subsequent iterations of the table.

Random Walk

A random walk is a process by which the Random Node Pool is populated. It does this by starting a Gossip topic and subscribing to it. It then picks a random number from 1 to NdN_d. A random node J hops away from it chosen and added to the table and a message i sent to the node to return a node J distance away from it as well. Each node will propagate this message forward while publishing the chosen peer to the topic. This random walk will have a decay counter corresponding to the S number of nodes required for that table. If the table is not complete when the walk ends, a walk for that J will be restarted with a smaller decay until the table is completed.


Figure: Pictorial representation of the random walk