# 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 interactiontype 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$.

ValueTypeDescription
0IxnNormalTransferThis 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.
1IxnConditionalTransferThis 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.
2IxnExecutionThis interaction type is used to execute a custom method in stateful logic.
3IxnNewAssetThis 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.
4IxnApprovalThis 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.
5IxnRevokeApprovalThis interaction type is used to revoke the asset approvals of an operator.
6IxnWriteFileThis 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.
7IxnReadFileThis interaction is used to read existing files, wherein participants can access the file and corresponding metadata that are persisted in the file root.
8IxUpdateFileThis interaction is used to update file content and its metadata.
9IxDeleteFileThis interaction is used to delete the file and its associated metadata
10IxnDeployAppThis interaction type is used to deploy a stateful logic into the MOI network, and correspondingly expect a unique address in return.
11IxnUpdateAppThis interaction type is used to deploy/upgrade a stateless logic.
12IxnFeePayThis interaction type is used system-generated interactions that deducts execution fee from the signer’s/Payer’s account.
13IxnCreateUserThis 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 13 , 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 interactiontype 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 CID14. 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}$