Skip to main content

Transactions

In the context of blockchain technology, an action that alters the state of the network is referred to as a transaction. Once initiated, the transaction is broadcasted to every node on the network, and a validator must validate and execute it. This process consumes computational resources, which are measured in units of gas. To cover the cost of gas, users must pay a fee, which is calculated based on the amount of gas required for the transaction and the gas price.

Before a transaction can be executed, it must be signed with the sender's private key. This signature verifies the authenticity of the transaction and ensures that it hasn't been tampered with.

The lifecycle of a transaction, from submission to execution, can be summarized as follows:

  • A unique transaction hash is generated.
  • The transaction is broadcasted to the network and added to a pool of pending transactions.
  • A validator selects the transaction and includes it in a block for verification.
  • The transaction is considered successful once it's been validated and included in the block.

The transaction hash serves as a unique identifier and can be used to check the status of the transaction, such as whether it was successful or not, and to access information about any events that were emitted during its execution.

Transactions can fail for various reasons, such as insufficient gas or fees, or if the transaction validation conditions are not met. For instance, if the sender's address does not match the signer's address, the transaction will not be considered valid.

Modern blockchain technology allows for the execution of transactions on multiple chains, thanks to the Inter-Blockchain Communication protocol (IBC). This enables interchain transactions, which can be explained in more detail in the following section.

Transaction Types​

Humans.ai supports two types of transactions:

  1. Cosmos transactions
  2. Ethereum transactions

Humans.ai leverages the Cosmos-SDK and incorporates the Ethereum Virtual Machine as a module, thereby enabling the convergence of Ethereum and Cosmos chain features and functionalities within a single platform, with additional capabilities.

Cosmos transactions allow for multiple messages to be included in a single transaction, whereas Ethereum transactions do not have this capability. However, Humans.ai implements Ethereum transactions as a single sdk.Msg contained in an auth.StdTx, which includes all relevant information such as signature, gas, payload, and more.

If you need more information about these two transaction types, you can find it in the following sections.

Cosmos Transactions​

On Cosmos chains, transactions are comprised of metadata held in contexts and sdk.Msgs that trigger state changes within a module through the module's Protobuf Msg service.

When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Cosmos transactions can have multiple sdk.Msgs. Each of these must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network.

A Cosmos transaction includes the following information:

  • Msgs: an array of msgs (sdk.Msg)
  • GasLimit: option chosen by the users for how to calculate how much gas they will need to pay
  • FeeAmount: max amount user is willing to pay in fees
  • TimeoutHeight: block height until which the transaction is valid
  • Signatures: array of signatures from all signers of the tx
  • Memo: a note or comment to send with the transaction

To submit a Cosmos transaction, users must use one of the provided clients.

Ethereum Transactions​

Instead of internal smart contract calls, Ethereum transactions refer to operations started by EOAs (Externally Owned Accounts). Since Ethereum transactions alter the EVM's state, they must be broadcast to the whole network.

A cost known as gas is also charged for Ethereum transactions. A base charge and a priority fee were proposed in (EIP-1559), and they work as incentives for miners to include particular transactions in blocks.

Ethereum transactions fall into a number of categories:

  • regular transactions: transactions from one account to another
  • contract deployment transactions: transactions without a to address, where the contract code is sent in the data field
  • execution of a contract: transactions that interact with a deployed smart contract, where the to address is the smart contract address

An Ethereum transaction includes the following information:

  • recipient: receiving address
  • signature: sender's signature
  • nonce: counter of tx number from account
  • value: amount of ETH to transfer (in wei)
  • data: include arbitrary data. Used when deploying a smart contract or making a smart contract method call
  • gasLimit: max amount of gas to be consumed
  • maxPriorityFeePerGas: mas gas to be included as tip to validators
  • maxFeePerGas: max amount of gas to be paid for tx

Visit this link for further details on Ethereum transactions and the transaction lifecycle.

The following Ethereum transactions are supported by Humans.ai.

tip

Note: Legacy transactions that are not protected are not supported by default.

Ethereum transactions can be processed by Humans.ai by being wrapped in an sdk.Msg. This is accomplished by Humans.ai utilizing the MsgEthereumTx. The required transaction data elements are included in this message, which is an SDK message that encapsulates an Ethereum transaction.

The MsgEthereumTx is noteworthy since it implements both the sdk.Msg and sdk.Tx interfaces (typically, SDK messages only implement the former, whilst the latter is a collection of messages packed together). The MsgEthereumTx must not be included in a auth.StdTx (the SDK's standard transaction type) because it performs gas and fee checks using Ethereum logic from Geth rather than checks made by the Cosmos SDK on the AnteHandler auth module.

Ethereum Tx Type​

Humans.ai employ three different types of transaction types.From Ethereum Improvement Proposals (EIPs), ai implemented Go Ethereum:

  1. LegacyTxType (EIP-155): The LegacyTxType represents the initial transaction format used in Ethereum before the implementation of Ethereum Improvement Proposal (EIP) 155. These transactions lack a chain ID, making them vulnerable to replay attacks. EIP-155 was introduced to address this issue by incorporating a chain ID, which uniquely identifies a specific Ethereum chain and prevents cross-chain replay attacks.

  2. AccessListTxType (EIP-2930): The AccessListTxType was unveiled as part of the Berlin upgrade, alongside EIP-2930. This innovative transaction type empowers users to delineate an access list encompassing addresses and storage keys the transaction intends to access. The primary objective of access lists is to curtail the gas cost augmentations instigated by EIP-2929, which elevated gas costs for state access operations to fortify denial-of-service (DoS) attack resilience. By enumerating an access list, users can circumvent paying increased gas costs for subsequent accesses to identical addresses and storage keys within a single transaction.

  3. DynamicFeeTxType (EIP-1559): The DynamicFeeTxType was introduced as part of the London upgrade, accompanying EIP-1559. This transaction type brought significant changes to Ethereum's fee market, with the aim of making gas fees more predictable and improving the user experience. EIP-1559 transactions consist of two main components: a base fee and a priority fee (or tip). The base fee is determined by the network's algorithm, while the priority fee is set by users to incentivize miners to include their transaction. The base fee is burned, effectively reducing the overall ETH supply, while the priority fee goes to miners as a reward for their work. DynamicFeeTxType transactions allow for more predictable and efficient gas fee management.

These transaction types show how Ethereum's network is constantly evolving and getting better, assisting with issues with scalability, security, and user experience.

Interchain Transactions​

Transactions that occur across multiple blockchain networks are referred to as interchain transactions. These transactions involve the transfer of digital assets or data between two or more distinct blockchain networks.

Every blockchain network has its own protocol and data structure, making direct transfer between blockchains difficult. Interchain transactions overcome this obstacle by utilizing intermediary mechanisms or protocols to facilitate the transfer of assets and data between various blockchains.

One such intermediary mechanism is a cross-chain bridge, which acts as a connector between different blockchains, enabling asset or data transfer. Cross-chain bridges typically require a trust or consensus mechanism to ensure the security and integrity of the transaction.

Alternatively, the IBC (Inter-Blockchain Communication) protocol can be used for interchain transactions.

Another possibility is to use the IBC (Inter-Blockchain Communication) protocol. A user must, in order to perform an interchain transaction using IBC, do the following:

  • Select the blockchain networks that the user wants to move assets or data between at the source and destination.
  • Verify that the IBC protocol has been implemented on both blockchain networks - Verify that an IBC connection and channel have been established between the two blockchain networks
  • Start the transfer of assets or data by sending a transaction via the IBC channel from the source blockchain to the destination blockchain.

Interchain transactions are becoming increasingly important as the number of different blockchain networks and applications continues to grow. They enable the interoperability of different blockchain networks, allowing for greater flexibility and efficiency in the transfer of digital assets and data.

Transaction Receipts​

A transaction receipt displays information that an Ethereum client has delivered to indicate the outcome of a specific transaction. This information includes the transaction's hash, block number, gas cost, and, in the case of the deployment of a smart contract, the address of the contract. It also contains unique data from the events released by the smart contract.

The following details are found on a receipt:

  • transactionHash : hash of the transaction.
  • transactionIndex: integer of the transactions index position in the block.
  • blockHash: hash of the block where this transaction was in.
  • blockNumber: block number where this transaction was in.
  • from: address of the sender.
  • to: address of the receiver. null when its a contract creation transaction.
  • cumulativeGasUsed : The total amount of gas used when this transaction was executed in the block.
  • effectiveGasPrice : The sum of the base fee and tip paid per unit of gas.
  • gasUsed : The amount of gas used by this specific transaction alone.
  • contractAddress : The contract address created, if the transaction was a contract creation, otherwise null.
  • logs: Array of log objects, which this transaction generated.
  • logsBloom: Bloom filter for light clients to quickly retrieve related logs.
  • type: integer of the transaction type, 0x00 for legacy transactions, 0x01 for access list types, 0x02 for dynamic fees. It also returns either.
  • root : transaction stateroot (pre Byzantium)
  • status: either 1 (success) or 0 (failure)