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:

$$x_{w}= {α_W \cup β_W \cup Ɣ_W}$$

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

$$n(α_W \cup β_W \cup Ɣ_W) = max( L_O, L_U )$$

where $L_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 $L_U$ is the ceiling value of the Liveness, for example, 5% of Network Size. Both $L_o$ and $L_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 = 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$ is populated with the Krama Node ID of the Guardian Interaction Set’s Operator, and the $β_W$ is populated with nodes provided by the Context Randomizer. Any changes to $Ɣ_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:

$$\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. $N_d$ is the network depth determined by $log_{10}(N_k)$, where $N_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 $N_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 > 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 $N_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