Skip to main content

Participant

Every stakeholder in the network is considered a participant. Each participant holds an account to interact with the MOI network and is uniquely identified by a Krama ID. An account primarily consists of value, context, and logic.

Identity​

Krama ID​

Krama ID is a Zero-Knowledge Proof enabled identity generated for all users and nodes. Before exploring the two types of Krama IDs, let us understand how we identify participant accounts using an InterGalactic Connector:

The InterGalactic Connector is a BIP-0044 6 definition of where the wallet resides. It defines the logical hierarchy for deterministic wallets and defines 5 tiers to resolve a specific path to wallet defined by the BIP-0032 standard. The path is defined as follows:

m / purpose' / coin_type' / account' / change / address_index

m: Master Node in the tree

purpose: A constant value of 44’, as recommended by the BIP-0043 standard 7

coin_type: A designated constant value of 6174 8, also known as Kaprekar’s constant 9

account: Account Path within the same blockchain

change: External (0) or Internal (1)

address_index: Child index which will be incremented each time upon creation of a new address

Note: The apostrophe in the path indicates that BIP-0032 hardened derivation is used. This prevents attackers from retrieving the user’s master private key. 10

Krama User ID​

Krama User ID is a concatenation of MOI ID 11 metadata of the user and their wallet address as shown below:

bird-view

Figure: Krama User ID

  • User MOI ID Metadata: This part of the Krama User ID is derived from the following information:

    • The Public Address of the user’s MOI ID.
    • The InterGalactic Path to the user’s MOI ID.
    • An alias, a string literal acting as a label. For example: “Ganesh’s Main Wallet”.

  • User Wallet Address/ Account ID: This part of the Krama User ID is a specific wallet address used to interact with the MOI network.

Krama Node ID​

Krama Node ID is a concatenation of MOI ID metadata of the node owner and the libp2p peer ID as shown below:

bird-view

Figure: Krama Node ID

  • Node Owner MOI ID Metadata: This part of the Krama Node ID is derived from the following fields:

    • The Public Address of the node owner’s MOI ID.
    • The InterGalactic Path to the node owner’s MOI ID. (IGP)
    • An alias, a string literal acting as a label. For example: “Rahul’s First Validator”.
    • Protocol ID, an unsigned integer that uniquely identifies the P2P protocol used by the node. (1=libp2p, 2=devp2p, etc.).
    • Hashing Algorithm, an unsigned integer that uniquely identifies the hashing algorithm used to generate the node’s peer ID from its public key. (1=SHA-1, 2=SHA-2-256, 3=Keccak-256, etc.)
    • Encoding Algorithm, an unsigned integer that uniquely identifies the encoding algorithm used. (1=base32, 2=base58, 3=base64, etc.).

  • Node Owner Identifier: This part of the Krama Node ID is a libp2p peer ID of the node

Value​

All the interactions in this digital world have some value associated with them either directly or indirectly. In the MOI network, we capture the multi-dimensional values pertaining to every interaction.

In traditional networks, the scope of a digital asset is only limited to the contract its use cases. Whereas in MOI network, participants can hold the digital asset/value locally in their respective accounts as part of a multi-dimensional token set. So, by design, the MOI protocol provides networks the ability to create, persist and manage all digital assets natively.

It captures the multi-dimensional values pertaining to every interaction. More Information on the digital asset standard can be found under the Multi-Dimensional Value section.

Context​

Interactions in the real world always have some context, such as reasons, causes, and effects. Unfortunately, current digital systems are limited by design to persist the entire contextual data of digital interactions taking place on the internet today. Context is defined as the insertion of intelligent action in the interaction, by persisting details that are either derived or obvious about a participant involved in an interaction. This context can be enriched based on several factors including the behavior of the interaction participants, state of the logic, interaction value, and the context of sender and recipient.

While there are several AI-related methods available to extract context as a data point in the current system, they are seldom converted into a unit of value for the participants of the digital interaction. Instead, they are treated as digital oil and sold to third parties such as advertisement agencies without adding any value to the original owners of the contextual data.

Further to generating values, the context of all participants associated in settling an interaction will be used to achieve Modulated Trust, a customizable trust model based on the personalization needs of the participants.

Concepts of modulated trust and context locking will be explained in the Context-Aware Trust section.

Logic​

Real-world interactions are conditional in nature. Meaning, that interactions are possible if one or the other conditions are met. MOI protocol also supports conditional interactions between participants.

The state of the participants involved in an interaction can be changed based on the execution of some conditional logic, like many other open networks that use smart contracts 12. To execute this logic, participants need to pay some fees in runtime. These fees remain stable as MOI protocol is designed in such a way that there are two tokens i.e., the Native MOI token and the MUSD stable coin. The MOI token can be used as a measure of value and used as a value of privilege in the decision-making process of the network. The MUSD stable coin can be used for payment of execution fees. By segregating the tokens as mentioned above, developers can be refrained from paying high transaction fees, hence achieving stable gas costing.

In addition to MUSD, developers can facilitate fee payment in any other digital assets approved by the network through governance. In this case, the number of tokens paid must be equivalent in economic value to the MUSD tokens needed to perform the execution of a given logical operation.

Unlike traditional digital systems such as blockchains, logic in MOI operates on the participants' data which is persisted in their respective lattices. Due to this design change, we are able to decouple logic and state; enable truly upgradable business logic.

MOI protocol primarily supports three types of logic:

  • Asset-based logic
  • Stateless logic
  • Stateful logic

Participants can associate a default logic with every asset/value they own, and these logics are termed asset logic. Asset logic is triggered whenever an interaction involving this asset is executed.

In some cases, logic may hold globally referred data, and such logic is called Stateful logic. They are similar to smart contracts and by default, these logics are not upgradable.

A logic that doesn’t hold any global data or state is called State-less logic and this type of logic may be used by the participants of the networks to perform conditional asset transfers.

These logic classifications are further explained with examples in the Context-aware Compute section.

Finally, the state of participant account in MOI is represented as follows:

π[A]={ρ,χ,ο,Z,T,ι}χ≡(EA,PA)\pi[A]=\{\rho, \chi, \omicron, \Zeta, \Tau, \iota\} \\ \chi ≡ (E_A, P_A)

, where EAE_A is a set of eligible nodes and PAP_A are other network preferences set by arbitrary account A.

Following is the in-memory representation of the participant account:

// Account defines all the attributes of an MOI account
type Account struct {
    AccType        int                            `json:"acc_type"`
    ID             kramaID                        `json:"id"`
    Nonce          uint                           `json:"nonce"`
    Balance        TDU                            `json:"balance"`
    AssetApprovals map[Address](map[AssetID]uint) `json:"asset_approvals"`
    ContextHash    []byte                         `json:"context_hash"`
    StorageRoot    []byte                         `json:"storage_root"`
    CodeRoot       []byte                         `json:"code_hash"`
    FileRoot       []byte                         `json:"File_root"`
}

Coalescence​

Coalescence is the ability to form patterns in a Value Space 5. Unlike how the blockchain persists the state of all accounts in one single linear chain, MOI persists the latest state of each participant in a separate linked list-like structure called Tesseract Lattice. Each Tesseract Lattice is made up of a cryptographically linked list of Tesseracts that depicts the changes made to the participant’s account from its inception. To know more about how cryptographic security is maintained, please visit the Tesseract section.

Similar to how traditional systems like blockchains maintain account details such as balance, Tesseracts persist participant’s context, value, and behavior in the network.

The fundamental change between Blockchain and Tesseract Lattice is represented in the diagram below:

bird-viewbird-view

Figure: Comparison of account state management between blockchains and MOI network

As you can see from the above figure(left), the states of all the non-involving accounts are forced to fit into one block, thereby limiting the users A, B, and C to perform their business, having each node agree to each account state. However, with the help of a Tesseract Lattice (right), users A, B and C now have the autonomy to manage their account states without needing confirmation from all nodes in the network by contextually securing their individual states. This fundamental separation is enabled by context, which is explained in the next section.