Skip to content

Transfer

A transaction is an action initiated by an account that changes the state of the blockchain. In order to perform state changes efficiently, each transaction is broadcast to the entire network.

Any node can broadcast a transaction requesting execution on the blockchain state machine; once this occurs, validators will validate, execute the transaction, and propagate the resulting state change to the rest of the network.

To process each transaction, computing resources on the network are consumed. Thus, the concept of gas emerged as a reference to the computation required by a validator to process a transaction.

Users have to pay for this computation, and all transactions have an associated fee. The fee is calculated based on the gas and gas price required to execute the transaction.

Additionally, transactions need to be signed with the sender's private key. This proves that transactions can only come from the sender and not sent fraudulently.

In short, the transaction life cycle after submitting a signed transaction to the network is as follows:

  • Transaction hashes are cryptographically generated.
  • The transaction is broadcast to the network and added to the pool of all other pending network transactions.
  • A validator has to pick your transaction and include it in a block in order to validate the transaction and consider it "successful".

For a more detailed explanation of the transaction lifecycle, see the corresponding section.

A transaction hash is a unique identifier that can be used to check transaction information, for example, whether the emitted event was successful.

Transactions can fail for various reasons. For example, the gas or fee provided may not be sufficient. Additionally, transaction validation may fail.

Each transaction has specific conditions that must be met in order to be considered valid. A broad verification is that the sender is the transaction signer.

In this case, if you send the transaction where the sender's address is different from the signer's address, the transaction will fail even if the fee is sufficient.

Today, transactions can not only make state transitions on the chain they were committed to, but they can also be transacted on another blockchain.

Inter-chain transactions can be implemented through the Inter-Blockchain Communication Protocol (IBC).

Find a more detailed explanation in the sections below.

Transaction Type

Daodst supports two transaction types:

  1. Cosmos transactions
  2. Ethereum transactions

This is possible because Daodst uses the Cosmos-SDK and implements the Ethereum Virtual Machine as a module.

In this way, Daodst provides the features and functionality of the combined Ethereum and Cosmos chains, and more.

Although most of the information contained in these two transaction types is similar, there are differences between them.

An important difference is that Cosmos transactions allow multiple messages to be sent in the same transaction.

In contrast, Ethereum transactions do not have this possibility.

To bring these two types together, Daodst implements Ethereum transactions as a single sdk.Msg Included in auth.StdTx.

This message contains all relevant Ethereum transaction information.

This includes signatures, gases, payloads, etc.

Find out more about both types in the following sections.

Cosmos Transactions

On the Cosmos chain, transactions are triggered by the metadata held in the context and the sdk.Msg of state changes within the module through the module's Protobuf Msg service composition/message service).

When users want to interact with the application and change state (such as sending coins), they create transactions. A Cosmos transaction can have multiple sdk.Msg. Before a transaction can be broadcast to the network, each of them must be signed with the private key associated with the appropriate account.

A Cosmos transaction includes the following information:

  • Msgs: an array of messages (sdk.Msg)
  • GasLimit: an option chosen by the user to calculate how much gas they need to pay
  • FeeAmount: the maximum amount the user is willing to pay
  • TimeoutHeight: the effective block height of the transaction
  • Signatures: array of signatures from all signers of tx
  • Memo: notes or comments sent with the transaction

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

Ethereum Transactions

An Ethereum transaction refers to an operation initiated by an EOA (externally owned account, managed by a human), not an internal smart contract call. Ethereum transactions change the state of the EVM and therefore must be broadcast to the entire network.

Ethereum transactions also require a fee, called gas. (EIP-1559) introduced the concept of base fees, as well as priority fees, to incentivize miners to include specific transactions in blocks.

Ethereum transactions are divided into several categories:

  • Regular transactions: transactions from one account to another
  • Contract deployment transaction: a transaction without a to address, the contract code is sent in the data field
  • Execution of the contract: a transaction that interacts with the deployed smart contract, where the to address is the smart contract address

An Ethereum transaction includes the following information:

  • recipient: recipient address
  • signature: the sender's signature
  • nonce: a counter from the account's tx number
  • value: Amount of ETH to transfer (in wei)
  • data: Include arbitrary data. Used when deploying smart contracts or making smart contract method calls
  • gasLimit: the maximum amount of gas to consume
  • maxPriorityFeePerGas: mas gas as validator tip
  • maxFeePerGas: the maximum amount of gas paid for tx

For more information on Ethereum transactions and the transaction lifecycle, go here.

Daodst supports the following Ethereum transactions.

📣 Tip : Unprotected legacy transactions are not supported by default. :::

Daodst is capable enough to handle them through the Ethereum transaction package on sdk.Msg. Daodst achieves this by using MsgEthereumTx. This message encapsulates the Ethereum transaction as an SDK message and contains necessary transaction data fields.

A note about MsgEthereumTx is that it implements sdk.Msg and sdk.Tx interfaces at the same time (generally SDK messages only appear in the former, while the latter is a set of messages peeling off.

The reason for this is because MsgEthereumTx cannot be included in auth.StdTx (the SDK's standard transaction type), because it uses Geth's Ethereum send instead of the Cosmos SDK `in token An.

Inter-chain transaction

Cross-chain transactions refer to the transfer of digital assets or data between two or more different blockchain networks.

Each blockchain network has its own unique protocols and data structures, making it difficult to transfer assets or data directly from one blockchain to another. Cross-chain transactions allow assets and data to be transferred between different blockchains by using an intermediary mechanism or protocol.

One such mechanism is a cross-chain bridge, which acts as a connector between different blockchains, enabling the transfer of assets or data.

Cross-chain bridges typically require some form of trust or consensus mechanism to ensure the security and integrity of transactions.

Another possibility is to use the IBC (Inter-Blockchain Communication) protocol.

To use IBC for cross-chain transactions, users need to:

  • Select the source and target blockchain networks between which the user wants to transfer assets or data.
  • Ensure that both blockchain networks implement the IBC protocol
  • Ensure connection and channel between two blockchain networks using IBC
  • Initiate the transfer of assets or data: this is done by sending a transaction from the source blockchain to the target blockchain through the IBC channel

As the number of different blockchain networks and applications continues to grow, cross-chain transactions are becoming increasingly important. They support the interoperability of different blockchain networks, enabling greater flexibility and efficiency in the transfer of digital assets and data.

Transaction Credentials

A transaction receipt shows the data returned by an Ethereum client to represent the outcome of a particular transaction, including the transaction's hash, block number, amount of gas used, and, in the case of a smart contract deployed, the contract address. Additionally, it includes custom information from events emitted in smart contracts.

The receipt contains the following information:

  • transactionHash: The hash of the transaction.
  • transactionIndex: Integer of transaction index position in the block.
  • blockHash: The hash value of the block where the transaction is located.
  • blockNumber: The block number where the transaction is located.
  • from: The address of the sender.
  • to: The recipient's address. null when it is a contract creation transaction.
  • cumulativeGasUsed: The total amount of gas used when executing this transaction in the block.
  • effectiveGasPrice: The sum of the base fee and the tip paid per unit of gas.
  • gasUsed: The amount of gas used by this particular transaction only.
  • contractAddress: the address of the created contract, if the transaction is a contract creation, otherwise it is empty.
  • logs: Array of log objects generated by this transaction.
  • logsBloom: Bloom filter for light clients to quickly retrieve related logs.
  • type: integer of transaction type, 0x00 for old transaction, 0x01 for access list type, 0x02 is for dynamic fees. It also returns.
  • root: transaction state root (pre-Byzantine)
  • status: 1 (success) or 0 (failure)