Context-Aware Initiations

Unlike how the traditional blockchain systems are initiated using the genesis ceremonial event, MOI handles initiation differently. We call this initiation ceremony as Sarga. Unlike Genesis, Sarga is not a blocking initiation process and hence allows other existing participants to carry out their interactions without any interruptions.

Sarga can occur at two levels: At the network-level, and the participant level.

Network-level Sarga

Network-level Sarga occurs only once in the entire lifecycle of an MOI network, during the inception of the network. This is made possible by sharing a Sarga.json file with the MOI client of all the guardian nodes . Here’s a sample of the Sarga.json file which is supplied to the MOI client of the guardian nodes to form the MOI network:

{
    "net_mode": 0, // 0 - Test Net, 1 - Main Net
    "net_name": "StringValue", // Any unique string name
    "net_id": 1, // Any unsigned integer value should be allowed
    "net_guardian_nodes": [ // A minimum of 30 guardian nodes nodes will be hardcoded
        {
            "KramaNodeId": "KramaNodeId1", // Pre-generated Node ID for guardian validators
            "balance": 100 // No. of KIP tokens to be deposited into the validator's wallet
        },
        {
            // ... 10 more entries, summing up to 11 genesis validators (fathers of the network)
        }
    ],
    "allocations": [ // Allocation of KIP tokens to non-validating actors (TBD)
        {
            "account": "0xAnantha", // Wallet address generated by MOI ID
            "balance": 1, // Mention the balance as approved by the board/council resolution
            "context": [ // Mention the Krama Node IDs of the guardian nodes who must be added as context nodes of the wallet
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        },
        {
            // ... Allocations for all KIP stakeholders approved by the board
        }
    ],
    "system_contracts": [
        {
            "name": "Staking contract",
            "version": "v0.0.1",
            "source": "https://gitlab.com/kip/staking-contract",
            "context": [
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        },
        {
            "name": "Validator reward contract",
            "version": "v0.0.1",
            "source": "https://gitlab.com/kip/validator-reward-contract",
            "context": [
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        },
        {
            "name": "Identity contract",
            "version": "v0.0.1",
            "source": "https://gitlab.com/kip/identity-contract",
            "context": [
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        },
        {
            "name": "Fee governance contract",
            "version": "v0.0.1",
            "source": "https://gitlab.com/kip/fee-governance-contract",
            "context": [
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        },
        {
            "name": "Guardian registry contract",
            "version": "v0.0.1",
            "source": "https://gitlab.com/kip/guardian-registry-contract",
            "context": [
    KramaNodeId1,
    KramaNodeId2,
    KramaNodeId3
            ]
        }
    ],
    "extra_data": {
        // Byte array / Hex data representing the purpose of the network
    }
}

Figure: Sample structure of Sarga file

When the above Sarga file is sent for execution, all the guardian validator nodes are connected to each other forming an MOI network. Further, all accounts under the allocations are created with the appropriate balance amount. This results in the creation of a Tesseract with respective context nodes mentioned in the context attribute of each account. Finally, the system contracts are deployed and the consensus is achieved on those accounts as well, per the context defined under each contract. As per the design of GIS and ICS criteria, a minimum of 30 guardian nodes must be specified in the Sarga file.

Participant-level Sarga

As each participant in the MOI network gets an individual chain called Tesseract Lattice. These accountspecific chains are initiated while processing the genesis interaction of the wallet. This genesis interaction is processed using Genesis Interaction Set (GIS).

Since GIS is also a special-purpose ICS, it also consists of eligible nodes and random nodes. The 1/3rd of the GIS is made of up eligible nodes and the remaining 2/3rd of the nodes are made up of random nodes. The random nodes in the GIS are community-hosted, whereas the eligible nodes in the ICS are made up of 2/3rd of guardian nodes and 2/3rd of the sender’s context nodes.

On successful execution of a genesis interaction and its tesseract generation, the context of the participants is updated as stated below:

1. The Sender’s behavioral context will be updated with the Krama ID of Operator, and the random context will be updated with the Random Nodes of the GIS
2. The Receiver’s behavioral context will be updated with the Krama ID of Operator and the random context will be updated with the Random Nodes of the GIS

Apart from the updates to the participant’s context, a new Context Signature will be generated by the guardian nodes and this signature will be bundled in the Tesseract.

Guardian Nodes

Guardian nodes are special-purpose validator nodes used in Sarga. Any node can become a guardian node by firing a registration interaction to the Guardian Registry Contract (GRC). The probability of a node getting picked up as a guardian node is directly proportional to its stakes.

The rules to be followed by a guardian node:

1. Stake a minimum of 100008 MOI tokens and maintain a verifiable identity
2. Maintain the complete state of the network
3. Process only the genesis interactions from new participants

Handling Guardian Registry Contract Interactions

When nodes are registering themselves as a guardian, these contract interactions are handled by the protocol differently to avoid deadlocks. When a GRC interaction is received, an ICS is created using the context of the MOI ID wallet of the Krama Node ID of the registering node and the context of the Guardian Registry Contract. Once the ICS is formed, the leader is elected only from the existing set of Guardian Nodes.

On successful execution of GRC interaction and its tesseract generation, the context is updated as stated below:

1. The behavioral context of the MOI wallet of Krama Node ID of the newly registered node is updated with Operator’s Krama Node ID. And the random context is updated with the random nodes of the ICS.
2. The behavioral context of the Guardian Registry Contract is updated with the Krama Node ID of the registered node.

GIS selection criteria for guardian nodes

50% of the selected guardian node shall be hosted directly by the foundation whereas the remaining 50% are hosted by vested parties of the network such as investors, advisors, partners, and so on.