Modulated Trust Algorithm

Interaction Consensus Set (ICS)

ICS is a network-level mechanism to create clusters of nodes, and these clusters are created on-demand, based on the Network Context associated with the interaction participants to form an agreement.

ICS locks the Network Context associated with the interaction participants by including a majority of the nodes associated with the given wallet(s) in its cluster.

The majority (meaning two-thirds and above), if not all the eligible nodes, are added to an ICS cluster. Apart from the eligible nodes, the ICS also consists of random nodes that are not part of the Network Context of the sender/receiver accounts.

In summary, ICS is a weighted cluster of 1/3rd of eligible nodes, and 2/3rd of random nodes, and an additional 10% of observer nodes. This concept is further formalized in the ICS creation section. But first, let us understand the roles of each node in the ICS:

Roles of nodes in the ICS cluster

Nodes in the ICS cluster have different roles, and they are as follows:

Generator	The node which executes an interaction, creates the Tesseract and proposes it in the ICS
Operator	The node which organizes the creation of the ICS cluster and facilitates consensus on the proposed Tesseract
Validator	The node which joins the ICS cluster and verifies the proposed tesseract
Observer	The node which joins the ICS cluster and scrutinizes each validator’s behavior in the ICS

ICS conditions

For the creation of an ICS, here are the conditions:

• Let $E_S$ represent a set of eligible nodes associated with the sender wallet S such that

• $$x_S = α_S \cup β_S \cup Ɣ_S \\ \, \\ \text{Say}, E_S = f( x_S) = \{\{N_m ... N_n\} \cup \{N_{n+1} ... N_o\} \cup \{N_{o+1} ... N_p\}\}$$

• Also let $E_R$ represent a set of eligible nodes associated with the receiver wallet R

  $$x_R = α_R \cup β_R \cup Ɣ_R \\ \, \\ \text{Say}, \ E_R = f( x_R) = \{\{N_q ... N_r\} \cup \{N_{r+1} ... N_s\} \cup \{N_{s+1} ... N_t\}\}$$

• And $E_G$ represents a set of eligible nodes associated with the generator account or the fee collection logic account of the generator G

  $$x_G = α_G \cup β_G \cup Ɣ_G \\ \, \\ \text{Say}, E_G = f( xG) = \{\{N_u ... N_v\} \cup \{N_{v+1} ... N_w\} \cup \{N_{w+1} ... N_x\}\}$$

• Now, let $F_R$ represent a random number of nodes that are not associated with the wallets S and R

  $$\text{Say}, F_R = \{N_{x+1} ... Ny\} , \text{such that},\ F_R ∉ \{E_S \cup E_R \cup E_G\} \ \text{AND\ } F_R ∈ K$$

• B represents a set of observer nodes that scrutinize the validators in the ICS without participating in the voting process

  $$\text{Say}, \ F_B = \{N_{y+1} ... Nz\} , \text{such that},\ F_B ∉ \{E_S \cup E_R \cup E_G \cup F_R\} \ \text{AND\ } F_B ∈ K$$

• Now that $E_S , E_R , E_G , F_R$ , and $F_B$ are available, let ICS represent the combination of all these sets of nodes

Ideal ICS Set

Ideal Eligible Set condition

$$\text{Let Eligible Set,}\ F_E = E_S \cup E_R \cup E_G \\ \, \\ F_E = \{α_S \cup β_S \cup Ɣ_S\} U \{α_R \cup β_R \cup Ɣ_R\} U \{α_G \cup β_G \cup Ɣ_G\}$$

Ideal Eligible Set Cardinality criteria

$$\text{Where Ideal Eligible Set Size} = n(F_E) = n(α_S \cup β_S \cup Ɣ_S \cup α_R \cup β_R \cup Ɣ_R \cup α_G \cup β_G \cup Ɣ_G)$$

Ideal ICS Set condition

$$\text{Now, Interaction Consensus Set}, F = F_E \cup F_R \cup F_B$$

Ideal ICS Cardinality criteria

$$\text{Ideal ICS Length} = n(F)= n(F_E \cup F_R \cup F_B)\\ \, \\ \text{such that},\ n(F_R) >= 2 * n(F_E) \ \text{AND\ },\\ \, \\ n(F_B) = X_O * n(F_E)$$

, where $X_O$ is the observer co-efficient which sets the minimum percentage of observer nodes to be part of the ICS, say 10%. Over time when the network matures, the observer co-efficient value will be subjected to changes through governance proposals.

Minimum ICS Set

Let the minimum number of eligible nodes required to achieve consensus be Eligible Set minimum $E_{Fmin}$ , represented as:

Minimum Eligible Set condition

$$F_{Emin} = E_{Smin} \cup E_{Rmin} \cup E_{Gmin} \\ \, \\ E_{Fmin} = \{α_{Smin} \cup β_{Smin} \cup Ɣ_{Smin}\} \cup \{α_{Rmin} \cup β_{Rmin} \cup Ɣ_{Rmin}\} \cup \{α_{Gmin} \cup β_{Gmin} \cup Ɣ_{Gmin}\} \\ \, \\ \text{such that}\ n(x_{imin}) >= 2/3 * n(x_i) \ \text{AND\ } x_{imin} ⊆ x_i \text{\ Where\ } x= ( α, β, Ɣ ) \ \text{and\ } i = (S, R, G) \\ \, \\ \text{Which means}, α_{Smin} ⊆ α_S \ \text{AND\ } β_{Smin} ⊆ β_S \ \text{AND\ } Ɣ_{Smin} ⊆ Ɣ_S \ \text{AND\ } \\ \, \\ α_{Rmin} ⊆ α_R \ \text{AND\ } β_{Rmin} ⊆ β_R \ \text{AND\ } Ɣ_{Rmin} ⊆ Ɣ_R \ \text{AND\ } \\ \, \\ α_{Gmin} ⊆ α_G \ \text{AND\ } β_{Gmin} ⊆ β_G \ \text{AND\ } Ɣ_{Gmin} ⊆ Ɣ_G \\ \, \\ \text{Also}, α_{min}, β_{min} of S, R \ and \ G should \ have \ at \ least \ one \ unique \ node$$

Cardinality criteria for Minimum Eligible Set condition

$$n(α_{Smin}) >= 2/3 * n(α_s) \ \text{AND\ } \ n(β_{Smin}) >= 2/3 * n(β_S) \ \text{AND\ } \ n(ƔSmin) >= 2/3 * n(Ɣ_S) \ \text{AND\ } \\ \, \\ n(α_{Rmin}) >= 2/3 * n(α_R) \ \text{AND\ } \ n(β_{Rmin}) >= 2/3 * n(β_R) \ \text{AND\ } n(Ɣ_{Rmin}) >= 2/3 * n(Ɣ_R) \ \text{AND\ } \\ \, \\ n(α_{Gmin}) >=2/3 * n(α_G) \ \text{AND\ } \ n(β_{Gmin}) >= 2/3 * n(β_G) \ \text{AND\ } n(Ɣ_{Gmin}) >= 2/3 * n(Ɣ_G) \\ \, \\ \text{Now, Minimum Eligible Set Size} = n(EFmin)= n \{α_{Smin} \cup β_{Smin} \cup Ɣ_{Smin} \cup α_{Rmin} \cup β_{Rmin} \cup Ɣ_{Rmin} \cup α_{Gmin} \cup β_{Gmin} \cup Ɣ_{Gmin}\}$$

Minimum ICS Set condition

$$\text{Now,\ } F_min = F_{Emin} \cup F_{Rmin} \cup F_{Bmin} \text{Where\ } F_{Rmin} \subset F_R \ \ \text{AND\ } F_{Bmin} \subset F_B$$

Cardinality criteria for Minimum ICS condition

$$\text{Min ICS Length} =n(F_{min}) = n(F_{Emin} \cup F_{Rmin} \cup F_{Bmin}) \\ \, \\ \text{Such that}\ n(F_{Rmin}) >= 2 * F_{Emin}, \ \text{AND\ } \ n(F_{Bmin}) = X_O * F_{Emin}$$

where $X_O$ is the observer co-efficient which sets the minimum percentage of observer nodes to be part of the ICS.

Actual ICS Set

At the time of ICS creation, let the number of eligible nodes required to achieve consensus be called Eligible Set Actual $F_{Eact}$, represented as:

Actual Eligible set condition

$$F_{Eact} = E_{Sact} \cup E_{Ract} \cup E_{Gact} , \\ \, \\ F_{Eact} = \{α_{Sact} \cup β_{Sact} \cup Ɣ_{Sact}\} U \{αR_{act } \cup β_{Ract} \cup Ɣ_{Ract}\} U \{α_{Gact} \cup β_{Gact} \cup Ɣ_{Gact}\}, \\ \, \\ \text{Such that}\ \ n(x_{iact}) >= n(x_{imin}) \ \text{AND\ } \ x_{iact} ⊆ x_i Where \ x= (α, β,Ɣ) \ \text{and\ } \ i =(S,R,G) \\ \, \\ \text{Which Means,} \ \ α_{Sact}⊆α_S \ \text{AND\ } β_{Sact} ⊆ β_S \ \text{AND\ } Ɣ_{Sact} ⊆ Ɣ_S \ \text{AND\ } \\ \, \\ α_{Ract} ⊆ α_R \ \text{AND\ } \ β_{Ract} ⊆ β_R \ \text{AND\ } Ɣ_{Ract} ⊆ Ɣ_R \ \text{AND\ } \\ \, \\ α_{Gact} ⊆ α_G \ \text{AND\ } β_{Gact} ⊆ β_G \ \text{AND\ } Ɣ_{Gact} ⊆ Ɣ_G$$

Cardinality criteria for Actual Eligible set condition

$$n(α_{Sact}) >= n(α_{Smin}) \ \text{AND\ } n(β_{Sact}) >= n(β_{Smin}) \ \text{AND\ } n(Ɣ_{Sact}) >= n(Ɣ_{Smin}) \ \text{AND\ } \\ \, \\ n(α_{Ract}) >= n(α_{Rmin}) \ \text{AND\ } n(β_{Ract}) >= n(β_{Rmin}) \ \text{AND\ } n(Ɣ_{Ract}) >= n(Ɣ_{Rmin}) \ \text{AND\ } \\ \, \\ n(α_{Gact}) >= n(α_{Gmin}) \ \text{AND\ } n(β_{Gact}) >= n(β_{Gmin}) \ \text{AND\ } n(Ɣ_{Gact}) >= n(Ɣ_{Gmin}) \\ \, \\ \text{Where} \ n(F_{Eact}) = n(α_{Sact} \cup β_{Sact} \cup Ɣ_{Sact} \cup α_{Ract} \cup β_{Ract} \cup Ɣ_{Ract} \cup α_{Gact} \cup β_{Gact} \cup Ɣ_{Gact})$$

Actual ICS set condition

$$\text{Now} \, F_{act} = F_{Eact} \cup F_{Ract} \cup F_{Bact}, \\ \, \\ \text{Where} \ F_{Ract} \subset F_R \ \text{AND\ } F_{Bact} \subset F_B$$

Cardinality criteria for Actual ICS set condition

$$\text{Actual ICS length} \ n(Fact) = n(F_{Eact} \cup F_{Ract} \cup F_{Bact}) \\ \, \\ \text{Such that} \ n(F_{Ract}) >= 2 * n(F_{Eact}), n(F_{Bact}) = X_O * n(F_{Eact})$$

ICS adjustment condition

In this section, we understand what measures are taken by MOI, in the case where the total number of nodes currently in the ICS does not fulfill the MTQ conditions.

Adjustments for enforcing correctness

$$\text{The Adjusted MTQ Size,} \ MTQ_{adjusted} = min(MTQ_{user}, MTQ_{max}) \\ \, \\ \text{And, Adjusted ICS Length,} \ FLJ = max(MTQ_{min} * \sigma, MTQ_{adjusted} * \sigma )$$

, where MTQUser is the user-chosen MTQ size, MTQmax is the maximum MTQ size set by the protocol, MTQmin is the minimum MTQ size also set by the protocol.

$$\text{Now} \ F_{final} = F_{act} \cup R’ \\ \, \\ \text{Where,} \ R’ ∉ \{F_{act}\} \ \text{AND\ } R’ \subset K$$

, where R’ is the adjusted node set for min, max, and user-specific MTQ sizes, randomly selected from the network.

Cardinality criteria for ICS adjustment condition

$$\text{Final ICS length,}\ FL_{N} = n(F_{final}) = n(F_{act} \cup R’) \\ \, \\ \text{Such that}\ n(R’) > 0 \ \text{AND\ } n(R’) = FL_{J} – FL_{A}$$

A detailed example of ICS condition

For a better understanding of these conditions, let us consider an example. Let us assume that an interaction enters the MOI network that transfers some MOI tokens from wallet S (the Sender who signed the interaction) to wallet R (the receiver of the MOI tokens).

Let us also assume that the MOI network has 100 nodes, and the minimum MTQ size was set to 10%, meaning that the interaction must be validated in an ICS of 10 or more nodes. Let us also assume that the maximum MTQ size was set to 30%, meaning that the interaction must be validated in an ICS of 30 or fewer nodes. Let us also assume that user S has specified that a minimum of 10% of the network should be present in the ICS which is basically user MTQ.

$$\sigma = 100 \\ \, \\ MTQ_{min} = 10\% * 100 = 10 \\ \, \\ MTQmax = 30\% * 100 = 30 \\ \, \\ MTQuser = 10\% * 100 = 10 \\ \, \\$$

Let us assume that F denotes the set of all the 10 or more nodes that join the ICS to settle the interaction. As explained, ICS is made of eligible nodes, random nodes, and observer nodes denoted as:

$$F = F_E \cup F_R \cup F_B$$

, where $F_E$ is the set representing the eligible nodes belonging to the context of sender S, receiver R, and generator node G. This is denoted as:

$$F_E = E_S \cup E_R \cup E_G$$

, where $E_S$ represents the context nodes of wallet S, denoted as follows:

$$E_S = \{α_S \cup β_S \cup Ɣ_S\} \\ \, \\ \text{Assume} \ E_S = \{N1, N2\}$$

, where $E_R$ represents the context nodes of wallet R, denoted as follows:

$$E_R = \{α_R \cup β_R \cup Ɣ_R\} \\ \, \\ \text{Assume} \ E_R = \{N2, N3\}$$

, where $E_G$ represents the context nodes of generator node G, denoted as follows:

$$E_G = \{α_G \cup β_G \cup Ɣ_G\} \\ \, \\ \text{Assume}\ E_G = \{N3\}$$

Now, we know that $F_E$ is made up of nodes N1, N2, and N3.

$$So, F_E = \{N1, N2, N3\}$$

As per the rules of ICS, random nodes must be at least twice the size of eligible nodes. So, let us assume:

$$F_R = 2 * n(F_E) = \{N4, N5, N6, N7, N8, N9\}$$

Let us assume that the MOI network requires few more nodes that make up the observer nodes in the ICS. These observer nodes are represented as:

$$F_B = Xo * F_E$$

, where XO is observer co-efficient marking the percentage or weight of observer nodes in the ICS.

Let us assume that the MOI network requires 10% more nodes to behave as observer nodes. Let us assume the following:

$$F_B = \{N10\}, \text{where} \ X_O = 10\%$$

, meaning 1 more node was required to join the ICS as an observer node to satisfy the condition.

Now, the complete ICS set F is represented as follows:

$$F = F_E \cup F_R \cup F_B = \{N1, N2, … N10\} \\ \, \\ \text{Now, we understand actual ICS size is} \ n(F) = 10, \\ \, \\ \text{Adjusted MTQ Size,} \ MTQ_{adjusted} = min(MTQ_{user}, MTQ_{max} ) = min (10, 30) = 10, \\ \, \\ \text{Adjusted ICS length} = max(MTQ_{min} * \sigma , MTQ_{adjusted}* \sigma ) = max(10, 10) = 10, \\ \, \\ \text{Since deficit is zero,} \ R’ = \{\}, \ \text{and}\ n(R’) = 0, \\ \, \\ \text{Now, Final ICS length} = n(F_{final}) = n(F_{act} \cup R’) = 10 + 0 = 10.$$

ICS Creation Algorithm

Following are the steps to create an ICS:

1. Operator node $N_i$ extracts the wallets associated with the Interaction
2. Node $N_i$ queries the Super State Manager (SSM) to identify all the nodes associated with the interaction participants
3. SSM queries the latest context hash of the interaction participants and returns a list of eligible nodes, random nodes, and also the observer nodes
4. Node $N_i$ will send ICS_Request messages to all the eligible nodes of the sender, receiver and sets the occupancy state to busy
5. Node $N_j$ on receiving the ICS_Request, verifies current state, context hash, and proof of binary hash sent by node $N_i$ with its own context hash and binary hash. If both context hashes are the same and the occupancy state is free, then $N_j$ responds with the ICS_Response message and starts the timer while setting its occupancy state to busy (It also performs various checks in the background to overcome attacks which are outlined in the Attack Vectors section)
6. On receiving ICS_Response messages, if the majority of the eligible set responded and if ICS conditions are met, the operator node then elects a leader/generator node from one of the joined nodes, as per the leader election criteria in the PoXt algorithm
7. Once the leader/generator node is elected, the operator node now queries the SSM for the context nodes of the Generator and sends the ICS_Request to these nodes as well as the random nodes and the observer nodes returned by SSM in step 3
8. On receiving the ICS_Response message from a majority of nodes in each set, the Operator again checks for the Quorum conditions. If all conditions are meet it publishes an ICS_Success message and starts the PoXt consensus service in $N_i$
9. If Node $N_j$ receives the ICS_Success message before the timeout, it verifies the validator set, elected leader, and also starts the PoXt consensus service
10. Once the ICS is formed successfully, the elected leader (i.e., Generator node) will execute the interaction, propose the tesseract, and achieves consensus based on the PoXt consensus algorithm

The message formats for the above algorithm can be found in the code snippet below:

type ICS_Request struct {
    Ics_ID             string
    ContextHash        [][]byte
    PoBHash            []byte
    ParticipantAddress []Address
}
type ICS_Response struct {
    Ics_ID string
    Status string
}
type ICS_Success struct {
    Ics_ID        string
    ValidatorSet  []Address
    LeaderAddress Address
}
type ICS_Dismiss struct {
    Ics_ID string
    Msg    string
}

Where, each attribute is defined as follows:

• ICS_ID: is a hex-encoded string of a 256-bit hash of sender and receiver address
• ValidatorSet: it is a list of MOI Node Ids which are participating in this ICS
• LeaderAddress: A 256-bit address of the Node which serves as a leader for this respective ICS
• Status: A Boolean value that denotes the availability of the node which received the ICS request
• ParticipantAddress: A list of interaction participant addresses i.e., sender, and receiver address
• PoBHash: A 256-bit hash of the binary which the operator is running
• ContextHash: Latest context hash of both interaction participants
• Msg: The arbitrary messages sent among nodes in the ICS

Once the final ICS is formed Modulated Trust Engine will achieve finality of the interaction state transitions using Proof of Context (PoXt) consensus algorithm locally, while persisting the state transitions globally.