Interaction

Interaction structure

Interaction in MOI has four major attributes, and it is defined as follows:

// Interaction represent each interaction in KIPMOI. Interaction in KIPMOI has four dimensions as shown below:
type Interaction struct {
    Input   InteractionInput        `json:"interaction_data_input"`
    Compute InteractionComputeValue `json:"interaction_data_compute"`
    Trust   InteractionTrustValue   `json:"interaction_data_trust"`
    Vec     InteractionVecValue     `json:"interaction_data_vector"`
}

The fields in the Interaction structure, 𝜤, are described below:

I = (I_I,I_C, I_T, I_V)

Input

Input: Input, as the name suggests is a composite structure that contains all the information provided by the user/app while signing the interaction. Interaction Input consists of the following fields:

// InteractionInput captures the input values of the interaction
type InteractionInput struct {
    Type           int                              `json:"interaction_data_input_type"`
    Nonce          uint                             `json:"interaction_data_input_nonce"`
    From           Address                          `json:"interaction_data_input_from"`
    To             Address                          `json:"interaction_data_input_address"`
    Payer          Address                          `json:"interaction_data_input_Payer"`
    TransferValue  map[AssetID]uint                 `json:"interaction_data_input_value"`
    PerceivedValue map[AssetID]map[AssetId]([]byte) `json:"interaction_data_input_real_value"`
    AnuLimit       uint                             `json:"interaction_data_input_anu_limit"`
    AnuPrice       uint                             `json:"interaction_data_input_anu_price"`
    Proof          ProofData                        `json:"interaction_data_input_proof"`
    Payload        InteractionInputPayload          `json:"interaction_data_input_payload"`
}

The fields in the InteractionInput structure, $I_V$ , are described below:

Type: An Integer value that is used to identify the type of interaction. This is formally denoted as $I_T$ .

Value	Type	Description
0	IxnNormalTransfer	This interaction type is used for regular value transfers. Participants can transfer any asset they hold in TDU using this type of interaction. If the specified assets are in enough quantity, the transfer should occur.
1	IxnConditionalTransfer	This interaction type is used for conditional value transfers. In this type, the specified assets are transferred/exchanged between participants only if a group of specified conditions in a stateless logic is met.
2	IxnExecution	This interaction type is used to execute a custom method in stateful logic.
3	IxnNewAsset	This interaction type is used to create a new asset natively. Participants need to specify the max-cap, symbol, and other details after which the asset will show up in the corresponding TDU balance.
4	IxnApproval	This interaction type is used to approve an operator to handle the asset owned by the participant. Participants signing such interactions need to specify the ID and quantity of the asset.
5	IxnRevokeApproval	This interaction type is used to revoke the asset approvals of an operator.
6	IxnWriteFile	This interaction type is used to create new files or write content into existing files. As the content is created or updated, the corresponding metadata will be updated for an existing file, or else a new file will be created with fresh metadata.
7	IxnReadFile	This interaction is used to read existing files, wherein participants can access the file and corresponding metadata that are persisted in the file root.
8	IxUpdateFile	This interaction is used to update file content and its metadata.
9	IxDeleteFile	This interaction is used to delete the file and its associated metadata
10	IxnDeployApp	This interaction type is used to deploy a stateful logic into the MOI network, and correspondingly expect a unique address in return.
11	IxnUpdateApp	This interaction type is used to deploy/upgrade a stateless logic.
12	IxnFeePay	This interaction type is used system-generated interactions that deducts execution fee from the signer’s/Payer’s account.
13	IxnCreateUser	This interaction type is used to register a new participant in the network.

Nonce: The counter value assigned to the given interaction from the signer’s account $I_{IN}$

From: Account address of the sender. This is formally denoted as $I_{IF}$

To: Account address of the receiver. This is formally denoted as $I_{IT}$

Payer: Address of the payer contract, which is expected to pay the execution fee on behalf of the sender. This is formally denoted as $I_{IP}$

TransferValue: Amount and type of the digital asset that needsto be transferred. This is represented using a map which is formally denoted as $I_{IV}$

PerceivedValue: Real-world value which is perceived around the context of this particular Interaction. This is denoted as $I_{PV}$

AnuLimit: Maximum number of units of effort that may be required for executing this interaction. The signer cannot modify this information as MOI uses gas metering at compile time. This is formally denoted as $I_{IAL}$

AnuPrice: Number of dollars paid for each unit of effort. Unlike Ethereum’s GAS Price ¹³ , the signer cannot modify this information as MOI uses a Stable Fee schedule. This is formally denoted as $I_{IAC}$

Proof: Proof is a composite structure that holds the proof of an associated interaction in MOI or a transaction in other protocols.

// ProofData is used to capture the context-related proofs associated with an interaction
type ProofData struct {
    ProtocolID int    `json:"interaction_data_input_proof_protocolid"`
    ProofType  int    `json:"interaction_data_input_proof_type"`
    ProofData  []byte `json:"interaction_data_input_proof_data"`
}

Payload: Extra data related to business logic. If the user/app is signing interaction with a message or a function call to be made, this information is encoded into the Payload field. Interaction Input Payload, $I_IP$ , is defined as follows:

InteractionInputPayload describes the transaction payload data w.r.t. of functions in a smart contract

type InteractionInputPayload struct {
    Init         []byte        `json:"init"`
    Data         []byte        `json:"data"`
    Extra        interface{}   `json:"extra"`
    LogicAddress Address       `json:"logic_address"`
    File         FileDataInput `json:"file_data"`
}

The fields in the InteractionInputPayload structure, $I_{IP}$ , are described below:

Init: The Init field is used as a flag to define if the interaction signed is pertaining to the creation of a new application. This is formally denoted as $I_{IPI}$
Data: The Data field consists of actual data that needs to be passed along a deploy a new application or call a function in an existing application. In case of a deployment of a new application, the Data field consists of the Wasm bytecode and the ABI. But in the case of execution of a function call, it may consist of function name and its input parameters. This is formally denoted as $I_{IPD}$ .
Extra: An interface which can be of typessetDataInput , ApprovalDataInput, or FileDataInput.

AssetDataInput: is a composite structure that contains all the information required to create a new digital asset in MOI is defined as follows:

type AssetDataInput struct {
    Dimension   int    `json:"asset_data_input_total_dimension"`
    TotalSupply uint   `json:"asset_data_input_total_supply"`
    Symbol      string `json:"asset_data_input_symbol"`
}

Dimension: Dimension to which this digital asset belongs to. This is formally denoted as $I_{IPED}$
TotalSupply: Total allowed supply of the digital asset in the network. This is formally denoted as $I_{IPET}$
Symbol: Symbol of the digital asset chosen by the owner. This is formally denoted as $I_{IPES}$

ApprovalDataInput is a composite structure that contains all the information required to approve a different user to spend their digital asset is defined as follows:

type ApprovalDataInput struct {
    Operator     Address          `json:"asset_data_input_operator"`
    Approvals    map[AssetID]uint `json:"asset_data_input_approvals"`
    LogicAddress Address
}

Operator: Address of a different account that is allowed to spend a digital asset on behalf of this account. This is formally denoted as $I_{IPEO}$
Approvals: A map of assetID and the approved amount. This is formally denoted as $I_{IPEA}$
LogicAddress: Address of an account that holds the logic, that needs to be executed to accomplish the interaction. This is formally denoted as $I_{IPEL}$

FileDataInput is a composite structure that contains all the information required to read/write files in MOI, is defined as follows:

type FileDataInput struct {
    Name  string   `json:"file_data_input_name"`
    Hash  string   `json:"file_data_input_hash"`
    Nodes []string `json:"file_data_input_nodes"`
    File  []byte   `json:"file_data_input_file"`
}

Name: Name of the file, this is formally denoted as $I_{IPEFN}$
Hash: Content Id of the file, this is usually an IPFS CID¹⁴. This is formally denoted as $I_{IPEFH}$
Nodes: Address of the nodes which hold this file or the nodes which pinned this file. This is formally denoted as $I_{IPEFP}$
File: Byte stream of the file, this field is used when the file needs to be operated at the network level. This is formally denoted as $I_{IPEFF}$

Compute

type InteractionComputeValue struct {
    ComputeMod         int      `json:"interaction_data_compute_mode"`
    ComputationalNodes []PeerID `json:"interaction_data_compute_value_nodes"`
    ComputationalHash  []byte   `json:"interaction_data_compute_value_hash"`
}

The fields in the InteractionComputeValue structure, $I_C$ , are described below:

ComputeMode: An integer that is used to identify the type of execution verification mechanism opted by the participant. This is formally denoting as $I_{CC}$ .

If the value is 0, All validators will perform the required operation again and verifies the output with the one sent by the execution node.
If the value is 1, All validators will verify the cryptographic proof/signature of the output sent by the execution node, if the signature is valid and trusted then they will update the state.
If the value is 2, All validators will verify the zero-knowledge proof sent by the execution node, if the zk-proofs are valid then the state is updated.

Currently, we allow only applications to decide the behavior of compute mode, since the user may not wish to be aware of all the intricacies or the limitations of the logic that they might use. This may change in the upcoming versions of MOI.

ComputationalNodes: List of peer IDs of nodes specified by the user/developer as part of Modulated Trust Preferences (MTP). If the mentioned nodes are eligible to execute the interaction, MOI mandates that these nodes be mandatorily present for the execution of the interaction in the ICS. This is formally denoted as $I_{CN}$

ComputationalHash: While signing the interaction, this field will be empty. However, this field will be updated with the cryptographic proof which can be used to verify whether each node specified in the above field has completely executed the interaction. This is formally denoted as $I_{CH}$

Trust

type InteractionTrustValue struct {
    ConsensusNodes []PeerID `json:"interaction_data_compute_value_consensus_nodes"`
    MTQ            uint     `json:"interaction_data_compute_value_mtq"`
}

The fields in the InteractionTrustValue structure, $I_T$ , are described below:

ConsensusNodes: List of peer IDs of nodes specified by the user/developer as part of Modulated Trust Preferences (MTP). If the mentioned nodes are eligible to verify the validity of the outputs of an executed interaction, MOI mandates that these nodes be mandatorily present for consensus in the ICS. This is formally denoted as $I_{TN}$

MTQ: Modulated Trust Quotient (MTQ) is defined by the user/developer as part of Modulated Trust Preferences (MTP). MTQ represents the minimum percentage of nodes in the MOI network that must be engaged in the MOI network to achieve consensus over an interaction. This is formally denoted as $I_{TM}$

Vec

type InteractionVecValue struct {
    Vectors []byte `json:"interaction_vec_value"`
    //TODO: Fields are yet to be finalized
}

The fields in the InteractionTDUValue structure, $I_V$ , are described below:

Vectors: A byte array of app-level information, network-level information, and any other metadata used to generate TDU points. Represented using $I_{VV}$

Interaction structure​

Input​

Compute​

Trust​

Vec​

Interaction structure

Input

Compute

Trust

Vec