Skip to main content

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=(II,IC,IT,IV)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, IVI_V, are described below:

Type: An Integer value that is used to identify the type of interaction. This is formally denoted as ITI_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 IINI_{IN}

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

To: Account address of the receiver. This is formally denoted as IITI_{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 IIPI_{IP}

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

PerceivedValue: Real-world value which is perceived around the context of this particular Interaction. This is denoted as IPVI_{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 IIALI_{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 IIACI_{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, IIPI_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, IIPI_{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 IIPII_{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 IIPDI_{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 IIPEDI_{IPED}

  • TotalSupply: Total allowed supply of the digital asset in the network. This is formally denoted as IIPETI_{IPET}

  • Symbol: Symbol of the digital asset chosen by the owner. This is formally denoted as IIPESI_{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 IIPEOI_{IPEO}

  • Approvals: A map of assetID and the approved amount. This is formally denoted as IIPEAI_{IPEA}

  • LogicAddress: Address of an account that holds the logic, that needs to be executed to accomplish the interaction. This is formally denoted as IIPELI_{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 IIPEFNI_{IPEFN}

  • Hash: Content Id of the file, this is usually an IPFS CID14. This is formally denoted as IIPEFHI_{IPEFH}

  • Nodes: Address of the nodes which hold this file or the nodes which pinned this file. This is formally denoted as IIPEFPI_{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 IIPEFFI_{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, ICI_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 ICCI_{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 ICNI_{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 ICHI_{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, ITI_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 ITNI_{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 ITMI_{TM}

Vec​

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

The fields in the InteractionTDUValue structure, IVI_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 IVVI_{VV}