Klaytn supports eth namespace APIs, so developers using Ethereum based SDKs or tools now can easily migrate their existing projects to Klaytn. (e.g. You can replace the endpoint URL in the Ethereum tools to point to a Klaytn node.)
But due to the fundamental design differences existing between Klaytn and Ethereum, some APIs cannot be fully supported. (e.g. some fields have always zero value)
This document describes the limitations of those APIs.
Since Block contains fields of Header and header has already been covered above, this section describes the remaining fields of the block except for header.
Please read the description ⚠️ carefully.
The ✅ icon in the description denotes that the field used in the same way as in Ethereum.
There are lots of transaction types in Klaytn, and fields of data structure vary based on the type.
So you have to check how various types of Klaytn transaction are converted as Ethereum transaction because during converting process some fields are omitted or added with zero or dummy values. That means Some important information(in terms of Klaytn) will be lost during converting.
Please note that we define EthereumLegacyTransaction in this document as the Ethereum transaction format before EIP-2718.
When you try to query Klaytn transactions via eth namespace JSON-RPC apis, Klaytn transactions will be return as Ethereum Legacy Transaction type.
This document describes the details of converting process (Klaytn transactions -> Ethereum Legacy Transaction).
Please read the description ⚠️ carefully.
The ✅ icon in the description denotes that the field used in the same way as in Ethereum.
Common Fields
Regardless of various Klaytn transaction type, there are common fields. This section describes how that common fields are served as Ethereum Legacy Transaction.
Ethereum Legacy Transaction Field
Klaytn Transaction Field
Description
blockHash
blockHash
blockNumber
blockNumber
from
from
gas
gas
gasPrice
gasPrice
hash
hash
input
(covered in below sections)
The description of this field is covered in the detailed transaction items below.
Regardless of various Klaytn FeeDelegation transaction type, there are common fields. This section describes how that common fields for feeDelegation(except for the common fields covered above) are served as Ethereum Legacy Transaction.
Regardless of various Klaytn PartialFeeDelegation transaction type, there are common fields. This section describes how that common fields for partialFeeDelegation(except for the common fields covered above) are served as Ethereum Legacy Transaction.
Ethereum Legacy Transaction Field
Klaytn PartialFeeDelegation Transaction Field
Description
feeRatio(omitted)
Different fields for each transaction type
LegacyTransaction
Ethereum Legacy Transaction Field
Klaytn LegacyTransaction Field
Description
input
input
to
to
value
value
Klaytn LegacyTransaction is served as Ethereum Legacy Transaction like below.
By default, the fields in the Klaytn Transaction Receipt are different depending on the transaction type. Because there are lots of transaction types in Klaytn, fields of transaction receipt vary based on the transaction type.
When you try to query Klaytn transaction receipts via eth namespace JSON-RPC apis, Klaytn TransactionReceipt will be returned as Ethereum Transaction Receipt.
This document describes the details of converting process (Klaytn Transaction Receipt -> Ethereum Transaction Receipt).
Please read the description ⚠️ carefully.
The ✅ icon in the description denotes that the field used in the same way as in Ethereum.
Common Fields
Regardless of various Klaytn transaction type, there are common fields. (Please remind that fields of Klaytn Transaction Receipt are various based on transaction types.)
This section describes how that common fields are served as Ethereum Transaction Receipt.
Regardless of various Klaytn FeeDelegation transaction type, there are common fields. (Please remind that fields of Klaytn Transaction Receipt are various based on transaction types.)
This section describes how that common fields for feeDelegation(except for the common fields covered above) are served as Ethereum Transaction Receipt.
Regardless of various Klaytn PartialFeeDelegation transaction type, there are common fields. (Please remind that fields of Klaytn Transaction Receipt are various based on transaction types.)
This section describes how that common fields for partialFeeDelegation(except for the common fields covered above) are served as Ethereum Transaction Receipt.
Ethereum Transaction Receipt Field
Klaytn PartialFeeDelegation Transaction Receipt Field
Description
feeRatio(omitted)
Different fields for each transaction type
LegacyTransaction Receipt
Ethereum Transaction Receipt Field
Klaytn LegacyTransaction Receipt Field
Description
input(omitted)
to
to
value(omitted)
Klaytn LegacyTransaction Receipt is served as Ethereum Transaction Receipt like below.
This field always has the value 0x0 because Klaytn does not have a baseFeePerGas scheme.
This field corresponds to blockScore in the Klaytn header, which is fixed to 0x1. This is because Klaytn's consensus mechanism is not based on PoW, indicating the technical concept of block difficulty is not applicable to Klaytn core.
This field always has the value 0x indicating the empty value. Owing to the fact that Klaytn's extraData contains consensus data such as validators addresses, validators signatures, and proposer signature, it is not applicable to eth namespace API.
This field always has the value 0xe8d4a50fff(=999999999999 in decimal), which is an arbitrary figure since Klaytn has no GasLimit. At the time of writing, this figure is 30 times higher than the block gas limit of Ethereum. Please refer to Computation Cost for more details.
A scalar value equal to the total gas used in transactions in this block.
This field is omitted because this field does not exist in Ethereum Block Header.
A hash of the block.
The bloom filter for the logs of the block. null when it is pending block.
This field returns the block proposer's address, because Klaytn's consensus mechanism is PBFT, which has a block proposer instead of miners.
This field always has zeroHash (0x00...) because Klaytn's consensus mechanism is not based on PoW.
This field always has zeroNonce (0x00...) because Klaytn's consensus mechanism is not based on PoW.
The block number.
The hash of the parent block.
the root of the receipts trie of the block.
This field is omitted because this field does not exist in Ethereum Block Header.
This field always has 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, which is the Keccak256 hash of the RLP-encoded bytes of the list containing empty block header because there are no uncles blocks on Klaytn.
The size of this block in bytes.
The root of the final state trie of the block.
The unix timestamp for when the block was collated.
This field is omitted because this field does not exist in Ethereum Block Header.
The total difficulty of the chain until the querying block.
The root of the transaction trie of the block.
This field is omitted because this field does not exist in Ethereum Block.
This field always has the value [] because there is no technical concept of uncles block in Klaytn core.
Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter.
Block hash.
Block number.
Address of the sender.
Gas provided by the sender.
Also known as Unit Price in Klaytn's context, this value is determined in the system via the governance processes.
Transaction hash.
The number of transactions made by the sender prior to this one.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
Almost same with Ethereum but unlike Ethereum, Klaytn returns integer as it is when its pending.
In Klaytn, type returns the transaction type in string (e.g. "LegacyTransaction"), but it has been converted to hexadecimal (e.g. 0x0) to match Ethereum. Transaction types that are only valid in Klaytn always return 0x0.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
Klaytn supports MultiSig so transaction in Klaytn can have more than one signature. signatures[0].V is used as the value of the field v.
Klaytn supports MultiSig so transaction in Klaytn can have more than one signature. signatures[0].R is used as the value of the field r.
Klaytn supports MultiSig so transaction in Klaytn can have more than one signature. signatures[0].S is used as the value of the field s.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
The data sent along with the transaction.
Address of the receiver. null when its a contract creation transaction.
Value transferred in Peb.
This field always has value 0x which means empty input because this field does not exist in Klaytn ValueTransfer transaction.
Address of the receiver.
Value transferred in Peb.
The data sent along with the transaction.
Address of the receiver.
Value transferred in Peb.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
The data sent along with the transaction.
Address of the receiver. This field always has value null because this transaction is a contract creation transaction.
Value transferred in Peb.
The data sent along with the transaction.
Address of the smart contract.
Value transferred in Peb.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field always has value 0x which means empty input because this field does not exist in Klaytn AccountUpdate transaction.
This field always has same address with from because this field does not exist in Klaytn AccountUpdate transaction and giving a value of this field as from address is most meaningful.
This field always has value 0x0 because this field does not exist in Klaytn AccountUpdate transaction.
This field always has value 0x which means empty input because this field does not exist in Klaytn Cancel transaction.
This field always has same address with from because this field does not exist in Klaytn Cancel transaction and giving a value of this field as from address is most meaningful.
This field always has value 0x0 because this field does not exist in Klaytn Cancel transaction.
The data sent along with the transaction.
This field is omitted because this field does not exist in Ethereum Legacy Transaction.
This field always has same address with from because this field does not exist in Klaytn ChainDataAnchoring transaction and giving a value of this field as from address is most meaningful.
This field always has value 0x0 because this field does not exist in Klaytn ChainDataAnchoring transaction.
Block hash.
Block number.
The contract address created, if the transaction was a contract creation, otherwise - null.
The total amount of gas used when this transaction was executed in the block. It is provided with the same meaning as the Ethereum field.
Since Klaytn uses a fixed gas price policy, the gasPrice value is returned. gasPrice(also called Unit Price) is set in the system by the governance.
Address of the sender.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
the amount of gas used by this specific transaction alone.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Array of log objects generated by transactions.
Bloom filter for light clients to quickly retrieve related logs.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Either 1(success) or 0(failure).
The transaction hash.
Almost same with Ethereum but unlike Ethereum, Klaytn returns integer as it is when its pending.
Value and data type of this field is converted. The type of this field is a string(e.g. "LegacyTransaction") in Klaytn but it is converted and served as hexadecimal(e.g. 0x) just like Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Address of the receiver. null when its a contract creation transaction.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Address of the receiver.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Address of the receiver.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt
Address of the receiver. This field always has value null because this transaction is a contract creation transaction.
This field is omitted because this field does not exist in Ethereum Transaction Receipt
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
Address of the smart contract.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field always has same address with from because this field does not exist in Klaytn AccountUpdate transaction receipt and giving a value of this field as from address is most meaningful.
This field always has same address with from because this field does not exist in Klaytn Cancel transaction receipt and giving a value of this field as from address is most meaningful.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field is omitted because this field does not exist in Ethereum Transaction Receipt.
This field always has same address with from because this field does not exist in Klaytn ChainDataAnchoring transaction receipt and giving a value of this field as from address is most meaningful.