A transaction refers to an action initiated by an account which changes the state of the blockchain. To effectively perform the state change, every transaction is broadcasted to the whole network. Any node can broadcast a request for a transaction to be executed on the blockchain state machine; after this happens, a validator will validate, execute the transaction and propagate the resulting state change to the rest of the network.
To process every transaction, computation resources on the network are consumed. Thus, the concept of "gas" arises as a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation, all transactions require an associated fee. This fee is calculated based on the gas required to execute the transaction and the gas price.
Additionally, a transaction needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.
In a nutshell, the transaction lifecycle once a signed transaction is submitted to the network is the following:
- A transaction hash is cryptographically generated.
- The transaction is broadcasted to the network and added to a transaction pool consisting of all other pending network transactions.
- A validator must pick your transaction and include it in a block in order to verify the transaction and consider it "successful".
For a more detailed explanation of the transaction lifecyle, see the corresponding section.
The transaction hash is a unique identifier and can be used to check transaction information, for example, the events emitted, if was successful or not.
Transactions can fail for various reasons. For example, the provided gas or fees may be insufficient. Also, the transaction validation may fail. Each transaction has specific conditions that must fullfil to be considered valid. A widespread validation is that the sender is the transaction signer. In such a case, if you send a transaction where the sender address is different than the signer's address, the transation will fail, even if the fees are sufficient.
Nowadays, transactions can not only perform state transitions on the chain in which are submitted, but also can execute transactions on another blockchains. Interchain transactions are possible through the Inter-Blockchain Communication protocol (IBC). Find a more detailed explanation on the section below.
Evmos supports two transaction types:
- Cosmos transactions
- Ethereum transactions
This is possible because Evmos uses the Cosmos-SDK and implements the Ethereum Virtual Machine as a module. In this way, Evmos provides the features and functionalities of Ethereum and Cosmos chains combined, and more.
Although most of the information included on both of these transaction types is similar,
there are differences among them.
An important difference, is that Cosmos transactions allow multiple messages on the same transaction.
Conversely, Ethereum transactions don't have this possibility.
To bring these two types together, Evmos implements Ethereum transactions as a single
contained in an
All relevant Ethereum transaction information is contained in this message.
This includes the signature, gas, payload, etc.
Find more information about these two types on the following sections.
On Cosmos chains, transactions are comprised of metadata held in contexts and
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
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 (
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 refer to actions initiated by EOAs (externally-owned accounts, managed by humans), rather than internal smart contract calls. Ethereum transactions transform the state of the EVM and therefore must be broadcasted to the entire network.
Ethereum transactions also require a fee, known as
introduced the idea of a base fee, along with a priority fee which serves as an incentive
for miners to include specific transactions in blocks.
There are several categories of Ethereum transactions:
- regular transactions: transactions from one account to another
- contract deployment transactions: transactions without a
toaddress, where the contract code is sent in the
- execution of a contract: transactions that interact with a deployed smart contract,
toaddress 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
For more information on Ethereum transactions and the transaction lifecycle, go here.
Evmos supports the following Ethereum transactions.
Note: Unprotected legacy transactions are not supported by default.
- Dynamic Fee Transactions (EIP-1559)
- Access List Transactions (EIP-2930)
- Legacy Transactions (EIP-2718)
Evmos is capable of processing Ethereum transactions by wrapping them on a
Evmos achieves this by using the
This message encapsulates an Ethereum transaction as an SDK message and contains the necessary transaction data fields.
One remark about the
MsgEthereumTx is that it implements both the
(generally SDK messages only implement the former, while the latter is a group of messages bundled together).
The reason of this, is because the
MsgEthereumTx must not be included in a
(SDK's standard transaction type) as it performs gas and fee checks using the Ethereum logic
from Geth instead of the Cosmos SDK checks done on the auth module
Interchain transactions refer to the transfer of digital assets or data between two or more different blockchain networks.
Each blockchain network has its own unique protocol and data structure, making it difficult to directly transfer assets or data from one blockchain to another. Interchain transactions allow for the transfer of assets and data between different blockchains by using intermediary mechanisms or protocols.
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 the transaction.
Another possibility is to use the IBC (Inter-Blockchain Communication) protocol. To make an interchain transaction using IBC a user needs to:
- Choose the source and destination blockchain networks that the user wants to transfer assets or data between.
- Ensure that both blockchain networks have implemented the IBC protocol
- Ensure there's a connection and channel established between the 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 destination blockchain through the IBC channel
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.
A transaction receipt shows data returned by an Ethereum client to represent the result of a particular transaction, including a hash of the transaction, its block number, the amount of gas used, and, in case of deployment of a smart contract, the address of the contract. Additionally, it includes custom information from the events emitted in the smart contract.
A receipt contains the following information:
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)