We had the pleasure of hosting Colin Kim, Klaytn Core Development Team Leader, for an informative AMA session where he answered the community’s questions about Klaytn implementing support for Ethereum equivalence. Read on for our recap!

Note: Some of the text have been edited for grammar and clarity.

Date & Time: Mar 25th at 4pm SGT / 5pm KST
Platform: Telegram
Speaker: 
Colin Kim from Klaytn Foundation
Host: Sofy, Community Manager at Klaytn Foundation


Introduction

Sofy: A very good afternoon to everyone and Happy Friday! Welcome once again to another AMA session with us. I am Sofy, community manager for Klaytn and I will be your host for today’s session. Thank you so much everyone for taking time to be here.

Today’s session will be divided into 2 parts. We will begin with an introduction from Colin, followed by him answering commonly asked questions.Lastly, we will be opening up the floor to the community. Feel free to drop your questions for the last segment of the AMA.

Please kindly introduce yourself to the community and share with us about your place in the Klaytn network.

Colin: Hi, Sofy. Thanks for having me. I joined Klaytn in 2018. I worked in various layers like platform development, SDK development, API Service development a.k.a Klaytn API Service, and application development such as KrafterSpace. Now I’m leading Klaytn Core Development Team.

Questions

Q1
Sofy: How will Klaytn v1.8.0 supporting Ethereum APIs support the Klaytn 2.0 initiative that the team set out?

Colin: Klaytn 2.0 is basically for metaverse builders. For them to build applications easily on Klaytn, it would be good to utilize massive resources previously built on Ethereum. Since Klaytn is forked from Ethereum, it is possible to support Ethereum APIs. Then many open-source resources can be used on Klaytn. Since Klaytn has many good features for better UI/UX, applications can provide better UI/UX with the abundant resources on Ethereum.

Q2
Sofy: So what are the significant changes? Please summarize that. It’s far too lengthy!

Colin: Okay. Let me summarize:

  1. We will support London EVM.
  2. We will support eth namespace APIs.
  3. We will support new Ethereum transaction types.

Q3
Sofy: When can we use that?

Colin: For Baobab, it will be activated on March 24th. The block number is 86,513,895. The time will be around 12 PM.

For Cypress, it will be activated on March 31th. The block number is 86,816,005. The time will be around 12 PM.

After then, you can use truffle, hardhat, web3.js, ethers.js, etc. as it is.

If you want to experience this before the hardfork, you can use our test network. The URL can be found in this article.

Q4
Sofy: What about the gas price increase?

Colin: Good question. We are also thinking that this can make the community confused. We are trying hard to do our best for the community. Let me make this clear.

For Cypress

  1. The v1.8.0 hardfork will be in effect on March 31th, the block number would be 86,816,005.
  2. The gas price will increase on April 3rd, the block number would be 87,091,200.

Q5
Sofy: Can you share the links to all the related articles?

Colin: Sure. Here are all links related to this topic.

Q6
Sofy: What are some benefits of the new feature that users may look forward to?

Colin: The main benefit is that you can now use Ethereum tools such as Truffle, HardHat, Web3.js, Ethers.js, etc. You can also use the latest Solidity versions.

All features supported by Ethereum’s London EVM are also now supported on Klaytn. Ethereum’s London hard fork is the latest technological update to the Ethereum ecosystem with changes to the EVM.

In other words, every EVM feature will now be available on Klaytn core protocol as well, however it should be noted that there have been some changes made with regard to precompiled contract addresses in the process of supporting London EVM, for which Klaytn developers should take into account. You can read more about this here.

Q7
Sofy: Can you share with us the new transaction types on Klaytn that support Ethereum transaction types?

Colin: Actually, Klaytn has employed transaction types for extensibility. We present the account model and transaction model in ETH Devcon 5, 2019. Ethereum also found that they need to add more fields to the transaction, so they introduced transaction types. Mainly two reasons: access list and dynamic gas price a.k.a. EIP-1559. To support these new Ethereum transaction types, Klaytn also needs to add more transaction types. This is why new transaction types were introduced in Klaytn.

Ethereum’s transaction types AccessList and DynamicFee will be supported. In 2021, Ethereum introduced what is called the transaction types. But varied transaction types are something that Klaytn has had since the launch of its mainnet in 2019, so there was a compatibility issue with Ethereum’s new transaction types. Klaytn v1.8.0 includes fixes to resolve the inconsistencies between transaction types of Klaytn and Ethereum. You can read more about this here.

Q8
Sofy: What are some challenges that users may potentially face with the new features and how may they address or where should they seek help from?

Colin: This is a quite big change towards Ethereum equivalence, but there is not much difference especially for users using Klaytn. Check the above articles. Especially for developers, they need to take care of these three things:

  1. Potential out of gas error: gas cost mechanism is changed slightly. This can cause out of gas error if the fallback function does storage related operation.
  2. Precompiled contract address change: The problematic case is that a newly deployed contract does a delegate call to the old contract. And the old contract needs to perform the execution of the precompiled contracts that are moved to the other address range.
  3. Support new transaction types: Since Ethereum transaction types are newly added to Klaytn, SDKs support the transaction types. Services like KlaytnScope should also process the new transaction types.

Q9
Sofy: How can users streamline when generating and retrieving Ethereum-formatted transactions?

Colin: If they are Ethereum users, and they have their tools to generate Ethereum-formatted transactions, then they just send the transactions to Klaytn via eth_sendRawTransaction().

Q10
Sofy: Klaytn’s existing precompiled contract addresses have been mapped to new addresses in order not to overlap with the existing Ethereum assignments. What is the effect of the precompiled contract address changes?

Colin: We can separate this into two:

  1. Contracts deployed prior to the hard fork
  2. Contracts deployed after the hard fork.

The first ones use the old precompiled contract addresses, so they don’t need to be redeployed. It can be a problem if the first one is called via a delegate call from the second one because this call uses the context of the second one.

The second ones use the new precompiled contract addresses. In this case, it can be a problem if the second one is trying to call old precompiled addresses. In this case the source code needs to be updated to use new precompiled addresses. You can read more about this here.

Q11
Sofy: What are some changes that users have to look out for if they are using `eth` namespace APIs with Geth client and Ethereum development tools?

Colin: 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.) You can read more about this here.

Q12
Sofy: When should users utilise the call method vs the delegate call method when deploying new contracts?

Colin: Please see the details in this article. To summarize this, please do not use delegatecall to the old contract from the new contract. This is the problematic case.

Q13
Sofy: Are there any tips you may give to our users?

Colin: I think one of the things that was not propagated well was that we also employed gas cost changes (EIP-1844), so SLOAD, SSTORE gas cost is changed. The problematic case here happens when the fallback function uses storage. Please take a look at our release notes to learn more.

Q14
Sofy: What is the progress on Klaytn’s product development? Is Klaytn on track with its roadmap?

Colin: I think yes. We are also planning to show the detailed tech roadmap that we want to achieve. Please stay tuned on Medium.

Q15
Sofy: What are some similarities and difference Klaytn has in comparison to Ethereum?

Colin: It’s a very good question. For similarity, we try to be similar as much as possible so that any applications running on Ethereum can be directly run on Klaytn.

For the differences, we can think of this as a UI/UX enhancement. We achieve 4000 TPS and 1-second block finality. This means you can make an application similar to a mobile application. The transaction is finalized in 2 or 3 seconds including transaction propagation time.

Also we’ve developed the account model and transaction model. With this, we can easily build a fee-delegation mechanism. Also we can improve security by making it possible to map multiple private keys to the account.

Q16
Sofy: Overall, what do you think is the greatest advantage for our community — dev, users etc., with the latest towards Ethereum equivalence?

Colin: As I discussed, we can embrace all Ethereum ecosystem tools and services very easily. We know that not many applications or services are onboard on Klaytn. By ourselves or with the Klaytn community, we can easily migrate or port applications first. Then we can build more on this.

By doing this, I think we can give better user experience even though the source code is exactly the same.

Many thanks to Colin Kim for taking time out of his busy schedule for our AMA! To find out more about Klaytn and join our growing global community, please follow these links below:

Website | Twitter | Discord | Telegram

From joining conferences to launching a highly-anticipated blockchain gaming ecosystem, it’s been a crazy month here at Klaytn! Here’s a quick take of our top highlights and latest happenings.

Highlights from this month

New integrations and listings

Want Klaytn’s latest news delivered straight to your inbox? Subscribe to our mailing list now!

It’s been months of tweaking and upgrading Klaytn’s network, but our team of experts here is leveling up!

Our Cypress hard fork will occur at:

After this network upgrade, our Cypress gas price adjustment will come into effect at:

WHAT IT ALL MEANS?

Hard fork refers to the upgrading of the core protocol running on the Klaytn blockchain. All nodes constituting the blockchain have to implement the upgrade. Since Klaytn chains do not allow forking at the consensus level, the term “hard fork” often used in the crypto jargon is meant here as “protocol upgrade”.


Find out more about how we’re moving into supporting Ethereum equivalence!

  • Toward Ethereum Equivalence #1 — Introducing Klaytn v1.8.0
  • Toward Ethereum Equivalence #2 — Changes in Precompiled Contract Addresses
  • Toward Ethereum Equivalence #3 — Supporting Ethereum API Formats
  • Toward Ethereum Equivalence #4 — Supporting Ethereum Transaction Types
  • The Klaytn Team has picked out some of the most well-known, and widely used Ethereum tools to test on Klaytn. Here we will explain some things to consider when you are using Ethereum tools on Klaytn.

    Define the fields related to `GasPrice`

    Klaytn fixed its gas price (Baobab 750ston, Cypress 25ston at the time of writing).

    If the fields relating to gas price, such as `gasPrice` or `max_priority_fee_pef_gas`, `max_fee_per_gas`, are not defined, Ethereum tools will create a transaction using values randomly generated by the library. But as mentioned above, since Klaytn uses a fixed `gasPrice`, so a value generated by the library will result in a transaction failure. That is why the fields relating to `gasPrice` have to be defined when you are using Ethereum development tools.

    Below we would like to demonstrate how to set the `gasPrice` for the four tools: web3.js ethers.js, Truffle, and Hardhat. The `gasPrice` value used in the code samples are all 25ston. Remember that the `gasPrice` is different for each network.

    web3.js

    When you want to create a legacy transaction, add the `gasPrice` field.

    const url = `provider url`
    const privateKey = `privateKey`
    const web3 = new Web3(url)

    const tx = await web3.eth.accounts.signTransaction({
    to: `0x8a726c5d1b9b7796df6836f24ef9ea50ab5178c6`,
    value: 90000000000,
    gasPrice: 25000000000,
    gas: 21000,
    }, privateKey)

    const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction)

    If you want to create a dynamicFee transaction, add the fields `maxFeePerGas` and `maxPriorityFeePerGas`.

    const url = `provider url`
    const privateKey = `privateKey`
    const web3 = new Web3(url)

    const tx = await web3.eth.accounts.signTransaction({
    to: `0x8a726c5d1b9b7796df6836f24ef9ea50ab5178c6`,
    value: 90000000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    gas: 21000,
    }, privateKey)

    const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction)

    ethers.js

    If you want to create a legacy transaction, add the field `gasPrice`.

    const url = `provider url`
    const provider = new ethers.providers.JsonRpcProvider(url)
    const wallet = new ethers.Wallet(privKey, provider)

    const tx = await wallet.sendTransaction({
    to: account,
    value: 90000000000,
    gasPrice: 25000000000,
    gasLimit: 21000,
    })

    const receipt = await tx.wait()

    If you want to create a dynamicFee transaction, add the fields `maxFeePerGas` and `maxPriorityFeePerGas`.

    const url = `provider url`
    const provider = new ethers.providers.JsonRpcProvider(url)
    const wallet = new ethers.Wallet(privKey, provider)

    const tx = await wallet.sendTransaction({
    to: account,
    value: 90000000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    gasLimit: 21000,
    })

    const receipt = await tx.wait()

    Hardhat

    There are two ways to set `gasPrice` on Hardhat.

    1. Define `gasPrice` to be used as the default value for all transactions in Hardhat.config.js
    2. Define the `gasPrice` fields in the transaction code

    1. Defining the values in Hardhat.config.js

    In networks options of Hardhat.config, you can define and use the options to be used when you are connecting to the blockchain network. For more details, please refer to the official documentation.

    //Hardhat.config.jsmodule.exports = {
    networks: {
    Hardhat: {
    ...............
    }
    },
    klaytn: {
    url: "provider url",
    gasPrice: 25000000000,
    account: [...],
    }
    },

    2. Defining the values in the transaction code

    Hardhat supports both web3.js and ethers.js. You can use a library that you prefer. For the instructions for each library, refer to the explanations above.

    Tips on network forking

    You can fork archive mode nodes with Hardhat. For full mode nodes, you have to set an appropriate block number that corresponds to the state storage cycle. (For default setting, a multiple of 128).

    Truffle

    Just as with Hardhat, there are two ways to set `gasPrice` with Truffle.

    1. Define `gasPrice` to be used as the default value for all transactions in Truffle-config.js
    2. Define the `gasPrice` fields in the transaction code

    Warning: If you want to use migration contracts that manage contract deployment history, we recommend using the first method (Truffle-config.js). The second method cannot control the gas price at the time of calling the function that records history on the migration contract, which may prevent it from functioning normally.

    1. Defining the values in Truffle-config.js

    In the networks options in Truffle-config.js, you can define and use the options to be used when you are connecting to the blockchain network via Truffle. Unlike Hardhat, you can differentiate between `gasPrice` and `maxFeePerGas`, `maxPriorityFeePerGas` used in `DynamicFee`. Please refer to the documentation for more information.

    If you want to create legacy transactions every time, add the `gasPrice` field.

    module.exports = {
    networks: {
    development: {
    host: "127.0.0.1",
    port: 7545,
    network_id: "*"
    },
    klaytn: {
    provider: () =>
    new HDWalletProvider({
    providerOrUrl: "provider url",
    privateKeys: [],
    }),
    gas: 50000000,
    gasPrice: 25000000000,
    network_id: "*"
    }
    },
    };

    If you want to create dynamicFee transactions every time, add the fields `maxFeePerGas` and `maxPriorityFeePerGas`.

    module.exports = {
    networks: {
    development: {
    host: "127.0.0.1",
    port: 7545,
    network_id: "*"
    },
    klaytn: {
    provider: () =>
    new HDWalletProvider({
    providerOrUrl: "provider url",
    privateKeys: [],
    }),
    gas: 50000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    network_id: "*"
    }
    },
    };

    2. Defining the values in the transaction code

    Truffle abstracts contracts, so you can easily deploy and call them. For more information, please refer to the official documentation.

    If you look at the contract APIs provided on Truffle, you will see that you can add the transaction parameters. Here you can add the fields related to `gasPrice`.

    If you want to create legacy transactions, add the `gasPrice` field.

    deployer.deploy(MetaCoin, {gasPrice: 25000000000,
    from: ...,
    gas: ...,
    });

    If you want to create DynamicFee transactions, add the fields `maxFeePerGas` and `maxPriorityFeePerGas`.

    deployer.deploy(MetaCoin, {
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    from: ...,
    gas: ...,
    });

    With the v.1.8.0 changes, Klaytn now supports the following features for Ethereum Equivalence.

    The Klaytn Team has picked out some of the most well-known, and widely used Ethereum tools to be used on Klaytn without any significant modifications. But Klaytn, unlike Ethereum, has a fixed gas price model. This means developers should take extra care when using Ethereum native tooling to be sure they have to set the right amount of gas when creating a transaction. This article will briefly explain some gas price related considerations when you are using Ethereum tools on Klaytn. As such, below we will explain how to set a Klaytn compatible gas price in web3.js, ethers.js, Hardhat and Truffle.

    Background

    With the introduction of EIP-1559 and the London hard fork, the gas price in Ethereum is flexibly determined in accordance with the base fee of the block. On the other hand, Klaytn has a fixed gas price (Baobab 750ston, Cypress 25ston at the time of writing).

    If the fields relating to gas price, such as `gasPrice` or `max_priority_fee_per_gas`, `max_fee_per_gas`, are not defined, Ethereum tools will create a transaction using the default values generated by the library being used (usually web3.js or ethers.js). But as mentioned above, since Klaytn uses a fixed `gasPrice`, any default values generated by the library (which is set by matching the dynamic pricing model of Ethereum) will result in a transaction failure. This is why any fields relating to `gasPrice` must be explicitly defined when using Ethereum native development tools.

    Below we would like to demonstrate how to set the `gasPrice` for the four tools: web3.js ethers.js, Truffle, and Hardhat. The `gasPrice` values used in our code samples are all 25ston, but remember that the fixed `gasPrice` may vary between networks.

    web3.js

    When you want to create a `legacy` Ethereum formatted transaction (a pre-EIP 1559 formatted transaction), explicitly include the `gasPrice` field.. and set it to the connecting network’s fixed gas price.

    const url = `provider url`
    const privateKey = `privateKey`
    const web3 = new Web3(url)

    const tx = await web3.eth.accounts.signTransaction({
    to: `0x8a726c5d1b9b7796df6836f24ef9ea50ab5178c6`,
    value: 90000000000,
    gasPrice: 25000000000,
    gas: 21000,
    }, privateKey)

    const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction)

    If you want to create a `dynamic fee` formatted transaction (post EIP-1559, Ethereum Type 1 or Type 2 transaction), explicitly add the fields `maxFeePerGas` and `maxPriorityFeePerGas`, then set both to the connecting network’s fixed gas price.

    const url = `provider url`
    const privateKey = `privateKey`
    const web3 = new Web3(url)

    const tx = await web3.eth.accounts.signTransaction({
    to: `0x8a726c5d1b9b7796df6836f24ef9ea50ab5178c6`,
    value: 90000000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    gas: 21000,
    }, privateKey)

    const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction)

    ethers.js

    Similar to the web3 case, if you want to create an Ethereum `legacy` formatted transaction, explicitly add the field `gasPrice` and populate with a fixed gas price value for the connected network.

    const url = `provider url`
    const provider = new ethers.providers.JsonRpcProvider(url)
    const wallet = new ethers.Wallet(privKey, provider)

    const tx = await wallet.sendTransaction({
    to: account,
    value: 90000000000,
    gasPrice: 25000000000,
    gasLimit: 21000,
    })

    const receipt = await tx.wait()

    If you want to create a `dynamic fee` transaction, explicitly add the fields `maxFeePerGas` and `maxPriorityFeePerGas` and populate with fixed gas price rates.

    const url = `provider url`
    const provider = new ethers.providers.JsonRpcProvider(url)
    const wallet = new ethers.Wallet(privKey, provider)

    const tx = await wallet.sendTransaction({
    to: account,
    value: 90000000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    gasLimit: 21000,
    })

    const receipt = await tx.wait()

    Hardhat

    There are two ways to set `gasPrice` on Hardhat.

    1. Define `gasPrice` to be used as the default value for all transactions in Hardhat.config.js
    2. Define the `gasPrice` fields in the individual transaction code itself.

    1. Defining the values in `hardhat.config.js`

    In the `networks` options of the `hardhat.config.js`, you can define and use the options to be used when you are connecting to the Klaytn blockchain network explicitly. For more details, please refer to the official hardhat documentation.

    //Hardhat.config.jsmodule.exports = {
    networks: {
    Hardhat: {
    ...............
    }
    },
    klaytn: {
    url: "provider url",
    gasPrice: 25000000000,
    account: [...],
    }
    },

    2. Defining the values in the transaction code

    Hardhat supports both web3.js and ethers.js. You can use whichever library you prefer. For the instructions for each library, refer to the explanations above. If you define gas price directly within your transactions, these definitions will overwrite any values defined in the config.

    Tips on network forking

    You can fork archive mode nodes with Hardhat at any block. However, when forking full mode nodes, you have to set an appropriate block number that corresponds to the state storage cycle. By default full mode nodes set their state storage cycle at blocks at a multiple of 128. How you set a block when forking depends on what kind of node you are connecting to with your config assigned RPC URI.

    Truffle

    Just as with Hardhat, there are two ways to set `gasPrice` with Truffle.

    1. Define `gasPrice` to be used as the default value for all transactions in Truffle-config.js
    2. Define the `gasPrice` fields in the transaction code

    Warning: If you want to use migration contracts that manage contract deployment history, we recommend using the first method (truffle-config.js). The second method cannot control the gas price at the time of calling the function that records history on the migration contract, which may prevent it from functioning normally.

    1. Defining the values in truffle-config.js

    In the `networks` options in `truffle-config.js`, you can define and use the options to be used when you are connecting to the blockchain network via Truffle. Unlike Hardhat, in Truffle, you must assign values for both pre and post EIP 1559 functionality by exclusively setting the `gasPrice`, `maxFeePerGas`, and `maxPriorityFeePerGas` fields. Please refer to the documentation for more information.

    If you want to exclusively create `legacy` Ethereum formatted transactions in Truffle, explicitly add the `gasPrice` field with the network fixed gas price.

    module.exports = {
    networks: {
    development: {
    host: "127.0.0.1",
    port: 7545,
    network_id: "*"
    },
    klaytn: {
    provider: () =>
    new HDWalletProvider({
    providerOrUrl: "provider url",
    privateKeys: [],
    }),
    gas: 50000000,
    gasPrice: 25000000000,
    network_id: "*"
    }
    },
    };

    If you want to exclusively create `dynamic fee` formatted transactions, explicitly add the fields `maxFeePerGas` and `maxPriorityFeePerGas` fields with the network fixed gas price.

    module.exports = {
    networks: {
    development: {
    host: "127.0.0.1",
    port: 7545,
    network_id: "*"
    },
    klaytn: {
    provider: () =>
    new HDWalletProvider({
    providerOrUrl: "provider url",
    privateKeys: [],
    }),
    gas: 50000000,
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    network_id: "*"
    }
    },
    };

    2. Defining the values in the transaction code

    Truffle abstracts contracts, so you can easily deploy and call them. For more information, please refer to the official documentation.

    If you look at the contract APIs provided on Truffle, you will see that you can add the transaction parameters. Here you can add the fields related to `gasPrice`.

    If you want to create `legacy` Ethereum formatted transactions, add the `gasPrice` field.

    deployer.deploy(MetaCoin, {gasPrice: 25000000000,
    from: ...,
    gas: ...,
    });

    If you want to create `dynamic fee` formatted transactions, add the fields `maxFeePerGas` and `maxPriorityFeePerGas`.

    deployer.deploy(MetaCoin, {
    maxFeePerGas: 25000000000,
    maxPriorityFeePerGas: 25000000000,
    from: ...,
    gas: ...,
    });

    With the above changes, and the activation of Klaytn v1.8.0, Ethereum tooling will now work effortlessly with the Klaytn ecosystem. However, it should be noted that usage of the above tooling will strictly support the submission and processing of Ethereum formatted transactions within the `eth` namespace API offered by Klaytn.

    With Klaytn v1.8.0, we have added new Klaytn transaction types to support the existing Ethereum transaction types. In this article, we will explain the definition, the purpose, and some things to consider when using these new transaction types.

    Purpose of supporting Ethereum transactions types

    In the past, Ethereum used to support only one transaction type `LegacyTransaction`, whereas Klaytn has always supported various different transaction types from its inception. However, with the introduction of the EIP-2718 Typed Transaction Envelope, Ethereum has also now begun support for different types of transactions. This change in the way Ethereum handles its own transaction types, gave rise for the need to encompass both chains’ transaction types within Klaytn and at the same time distinguish between them. As such, for Klaytn v1.8.0, we have added transaction types that are compatible with Ethereum transaction formats.

    We will start with an explanation of some of the things that you need to consider when using Ethereum formatted transactions on Klaytn, and then introduce Ethereum transaction types and Klaytn’s new transaction types.

    Ethereum formatted transactions on Klaytn

    First and foremost, it is important to take into account that some fields may not function as expected due to inherent differences between Klaytn and Ethereum. For example, as Klaytn has a fixed gas price, `GasTipCap` (`maxPriorityFeePerGas`) and `GasFeeCap` (`maxFeePerGas`) in `DynamicFeeTx` would only be processed when the gas price is set to the value as determined by the governance (currently at 25 ston).

    To help Ethereum developers easily migrate their projects to Klaytn with minimum adjustments, Klaytn `eth` namespace APIs have adopted Ethereum transaction formats, meaning they will behave and process the same on Klaytn just as they do on Ethereum. The RLP serialization for the signature of the transaction hash is the same for both the `eth` namespace and the `klay` namespace. However, Klaytn has a different Raw Transaction RLP serialization rule specifically for the `klay` namespace interface, so as to process all transactions for Klaytn and Ethereum without there being conflicts between the existing transaction types of the two. For more details, please refer to Ethereum Tx Type and Klaytn New Tx Type. Below you will find explanations on the different RLP serializations for each respective namespace.

    `eth` namespace API

    You can use the exact transaction formats as defined in Ethereum with `eth` namespace APIs. Therefore, the RLP procedure for the signature, transaction hash and Raw Transaction are the same as on Ethereum.

    SigHashRLP = EthereumTransactionType || TransactionPayloadTxHashRLP = EthereumTransactionType || TransactionPayloadRawTx = EthereumTransactionType || TransactionPayload

    If you are using the `eth` namespace APIs while using a Geth client and Ethereum development tools (ethers.js, web3.js, Hardhat, Truffle, …), you can use Ethereum transactions on Klaytn without making any changes.

    `klay` namespace API

    The RLP procedure for the signature or transaction hash with the `klay` namespace is the same as with the `eth` namespace, however, there is one exception applied to Raw Transactions, as it requires the identifier `EthereumTxTypeEnvelope`.

    SigHashRLP = EthereumTransactionType || TransactionPayloadTxHashRLP = EthereumTransactionType || TransactionPayloadRawTx= EthereumTxTypeEnvelope || EthereumTransactionType || TransactionPayload

    Hence, if you are using the `klay` namespace APIs with a Klaytn Client, and Klaytn development tools (caver-js, caver-java, …), then you have to use the Ethereum transaction types following the instructions outlined above.

    Ethereum Tx Type and Klaytn New Tx Type

    With Klaytn v1.8.0, the transaction types `TxTypeEthereumAccessList` and `TxTypeEthereumDynamicFee` have been added to support Ethereum transactions AccessListTxType and DynamicFeeTxType. The table below shows the Ethereum transaction types and the corresponding transaction types for Klaytn.

    The new Klaytn transaction types have been added for the sake of Ethereum compatibility. They have the same fields and format as Ethereum transactions, with the same RLP process. Below you can see the RLP encoding methods to obtain the hash for a signature in each case. You can see that Ethereum and Klaytn transactions are subject to the same procedure.

    // AccessListTxType (Ethereum Tx)
    sigRLP = 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList])
    sigHash = keccak256(sigRLP)

    // TxTypeEthereumAccessList (Klaytn Tx)
    sigRLP = 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList])
    sigHash = keccak256(sigRLP)

    // DynamicFeeTxType (Ethereum Tx)
    sigRLP = 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list])
    sigHash = keccak256(sigRLP)

    // TxTypeEthereumDynamicFee (Klaytn Tx)
    sigRLP = 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list])
    sigHash = keccak256(sigRLP)

    The RLP encoding scheme for the transaction hash is also the same for Ethereum and Klaytn transactions.

    // AccessListTxType (Ethereum Tx)
    TxHashRLP = 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signature_y_parity, signature_r, signature_s])
    TxHash = keccak256(TxHashRLP)

    // TxTypeEthereumAccessList (Klaytn Tx)
    TxHashRLP = 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signature_y_parity, signature_r, signature_s])
    TxHash = keccak256(TxHashRLP)

    // DynamicFeeTxType (Ethereum Tx)
    TxHashRLP = 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])
    TxHash = keccak256(TxHashRLP)

    // TxTypeEthereumDynamicFee (Klaytn Tx)
    TxHashRLP = 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])
    TxHash = keccak256(TxHashRLP)

    However, as noted, different rules apply for Ethereum and Klaytn when it comes to Raw Transactions. In Klaytn you will have to attach an additional `EthereumTxTypeEnvelope` type to Raw Transactions in order to distinguish the Ethereum transaction formats.

    The table below shows these transaction types.

    To differentiate the existing Klaytn transaction types from Ethereum transaction types, `EthereumTxTypeEnvelope` (`0x78`) will be used to designate these transactions on Klaytn. Using this identifier, it is possible to accommodate both current and future Ethereum transaction types on Klaytn.

    The identifier `EthereumTxTypeEnvelope` is also used within Raw Transactions for the ‘klay’ API and interface namespace. As you can see below, Klaytn adds the identifier for Raw Transactions, unlike Ethereum.

    (NOTE: `eth` namespace APIs still use the Ethereum formats without `EthereumTxTypeEnvelope`)

    // AccessListTxType (Ethereum Tx)
    RawTx = 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signature_y_parity, signature_r, signature_s])

    // TxTypeEthereumAccessList (Klaytn Tx)
    RawTx = EthereumTxTypeEnvelope || 0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signature_y_parity, signature_r, signature_s])

    // DynamicFeeTxType (Ethereum Tx)
    RawTx = 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])

    // TxTypeEthereumDynamicFee (Klaytn Tx)
    RawTx = EthereumTxTypeEnvelope || 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])

    In this article we explained Ethereum transaction types and Klaytn’s new transaction types to help you understand the purpose of this change, as well as how to use them. For more details on the new transaction types, please refer to Klaytn Docs.

    Article Series

    Starting with the Klaytn v1.8.0 release, the `eth` namespace (`eth_`) APIs will be supported in the same format as Ethereum APIs (in addition to the existing klay namespace APIs). In this article, we explain the purpose of supporting Ethereum APIs, as well as some points to take note of while using this new feature.

    For more details on these changes, please refer to Klaytn Docs — eth.

    Purpose

    Klaytn v1.8.0 supports Ethereum APIs in order to ensure compatibility with the Ethereum interface, as part of the Klaytn 2.0 initiative the Klaytn team set out earlier — supporting Ethereum equivalence,so that Ethereum dApp developers can seamlessly build on Klaytn by allowing for the same tooling, workflows, and interaction, they are accustomed to within the Ethereum environment.

    The eth namespace APIs (`eth_`) provided on Klaytn nodes prior to Klaytn v1.8.0 functioned in the same way as their klay namespace API (`klay_`) counterparts. They were invoked in the same way and responded in the same way as their `klay` equivalents. These earlier versions of the `eth` APIs were intended to enable the use of Ethereum development tools on Klaytn; however, due to divergent data structures between Klaytn and Ethereum there were still interoperability problems with much of the Ethereum tooling and interfacing of third party software.

    To solve this problem, the `eth` namespace APIs included in the latest Klaytn v1.8.0 release, have been calibrated to support the same request and response formats as those of the native Ethereum APIs. With the update of the eth namespace APIs and Klaytn v1.8.0 release, Ethereum development tools are now usable on Klaytn with immediate effect, and Ethereum dApps can now be migrated to Klaytn with minimal modification.

    Below we have outlined some potential considerations for different types of API users.

    Users of eth namespace APIs

    If you are using `eth` namespace APIs with Geth client and Ethereum development tools (ethers.js, web3.js, hardhat, truffle, …), there are some considerations to be aware of regarding some changes in the features. In this document we are giving you a brief outline of the things to consider. You can find the details in Klaytn Docs — eth — Caution.

    When you are using `eth` namespace APIs, some of the fields that are not used in Klaytn will return adjusted values.

    The fields `mixHash`, `difficulty`, `nonce`, `gasLimit`, `sha3Uncles` and `uncles` are not used in Klaytn because Klaytn is not a PoW based chain, nor does it have uncle blocks produced in its consensus mechanism. Instead these fields will return fixed default values. Therefore, depending on the purpose, you may have to make some accommodations while using these fields because using them in your dApps may not be valid for some specific scenarios.

    However, all other block fields not mentioned above will return values as expected. For more details on the return values of block fields, please refer to Klaytn Docs — eth — Block.

    There are some other usage behaviors to consider for each data type commonly used in dApps:

    When creating transactions

    When you are generating and retrieving Ethereum-formatted transactions, you can use the `eth` namespace APIs the same way as you would in Ethereum. This is only true if you are dealing with transactions which are Ethereum-formatted (read more about Klaytn’s Ethereum format support at Klaytn Legacy Transaction format). In this case, you can use the `eth` namespace APIs to utilize the various Ethereum development tools on Klaytn and migrate Ethereum dApps to Klaytn with minimal changes.

    However, please be aware that if you build and submit any non-Legacy Klaytn-formatted transactions (i.e., those transactions which are not specifically Ethereum-formatted) then there may be unexpected behaviors and incomplete data returned through the `eth` namespace API as explained in the next section below.

    The full list of Klaytn transaction formats and comprehensive documentation of the Klaytn Transaction model can be found here.

    When retrieving externally created transactions

    Klaytn uses a robust transaction model which includes (but is not limited to) Ethereum-formatted transactions. Users should be aware that when using the `eth` namespace APIs, not all Klaytn transaction type data can be represented. When retrieving any Klaytn transaction data via the `eth` namespace APIs, that data will be returned in the Legacy Tx format. This means fields related to Klaytn-specific features (Fee DelegationAccount Key UpdateKlaytn Transaction Types etc.) will not be included in `eth` namespace API responses.

    Additionally, some fields may not be used when building certain Klaytn transactions (like `to`, `input` or `value`) and may return adjusted/default values for those missing fields in `eth` API responses depending on the transaction type. For more details, please refer to Klaytn Docs — eth — Transaction.

    For the above reasons, when using a dApp to retrieve externally created transactions, it is recommended to use the namespace `klay` API to maintain consistent behaviors.

    In cases where the developer is certain that all involved transactions are Ethereum-formatted, they could choose to use the `eth` API for data retrieval; however, be aware that on a decentralized network you may not have control over the format users would use to submit transactions to your contracts and you may need to handle non-Ethereum-formatted transaction cases.

    Users of klay namespace APIs

    Support for Ethereum APIs applies only to `eth` namespace APIs. If you are using `klay` namespace APIs via the Klaytn Client, or the Klaytn development tools (caver-js, caver-java, etc.), you can continue using all the features provided by Klaytn using the `klay` namespace APIs as normal.

    The Klaytn team are excited to introduce these new features in the latest release of Klaytn v1.8.0 and can’t wait for the Klaytn community to use them. For more technical details regarding the contents of this article, please refer to Klaytn Docs — eth. Stay tuned to our social media for more updates and future Klaytn progress:

    Twitter | Telegram | Discord

    Article Series

    Precompiled contracts have changed with Klaytn v1.8.0. In this post, we will explain the reasons for these changes as well as their effect on the existing contracts utilizing precompiled contracts.

    TL;DR

    Purpose of precompiled contract changes

    In order to support the precompiled contracts that have been newly added to Ethereum, Klaytn’s existing precompiled contract addresses have been mapped to new addresses in order not to overlap with the existing Ethereum assignments.

    Precompiled contracts to be changed

    In the above table, the address of Klaytn’s vmLog has been changed because it overlaps with Ethreum’s Blake2F. Klaytn’s other precompiled contracts like feePayer and validateSender do not yet overlap with Ethereum’s precompiled contracts, however they have also been modified to prevent future overlaps.

    Effect of the precompiled contract address changes

    To minimize the impact of the precompiled contract address changes, Klaytn also stores the latest hard fork (protocol upgrade) version data when storing a contract reference in the chaindata of the mainnet. This allows users to know whether a contract has been deployed prior to the Istanbul hard fork.

    Hard fork refers to the upgrading of the core protocol running on the Klaytn blockchain. All nodes constituting the blockchain have to implement the upgrade. Since Klaytn chains do not allow forking at the consensus level, the term “hard fork” often used in the crypto jargon is meant here as “protocol upgrade”.

    When Klaytn runs a contract, it checks whether the contract was deployed before the Istanbul hard fork. If it is deployed before the hard fork, it uses the Constantinople precompiled contract map, which is the same one from the time of deployment. That way, the deployed contract can function the same way even after the hard fork.

    However, a contract calling a precompiled contract utilizing delegateCall could potentially be problematic. This command executes a contract not from the callee but the caller’s perspective. If a precompiled contract’s caller is an Externally Owned Account (EOA), it does not have access to the hard fork version data and will always use the latest version of the precompiled contract map. Therefore if an EOA was to use DelegateCall to call a precompiled contract and its expected behavior to be in-line with the pre-Istanbul precompiled address map, an error will occur.

    When using call for precompiled contracts

    If you are using calls for precompiled contracts in a contract deployed before the hard fork, you won’t have any problems. It will work as expected even if the precompiled contract address changes following the hard fork. (The code below is a sample calling a feepayer precompiled contract.)

    Even if the precompiled contract address has changed, the called contract can tell “at which hard fork it was deployed”, so it can use a precompiled contract address map that matches the hard fork version to call the precompiled contract.

    The image below demonstrates a contract using feePayer(0x0a), a precompiled contract deployed before the Istanbul hard fork.

    Let’s assume that we called a function in Contract A that calls feePayer after the hard fork (address change). Contract A is still using the old address 0x0a to call feePayer. The caller (msg.sender) of the precompiled contract feePayer is Contract A, and since we know that Contract A was deployed before the hard fork, we can use a corresponding precompiled contract map to make a call to feePayer.

    To sum up, if you are calling a precompiled contract using the call method, your smart contracts and related codebase will not be affected by the address change.

    When using delegateCall for precompiled contracts

    Most of the contracts deployed before the hard fork implementation will work the same as before. However, if the contract intends to call precompiled contracts 0x09, 0x0a or 0x0b using delegateCall, you may encounter an error. (Refer to some examples in Klaytn Docs using the call methods in different inline assembly functions)

    To help explain the source of error, we will use our previous Example contract, but this time using delegatecall method instead of a direct call method. Let’s say that we deployed this Example contract which sends delegateCalls to the feePayer with the address 0x0a; 0x0a was the assigned feePayer address before the hard fork. (The code below is a sample that makes a delegateCall to a feePayer precompiled contract.)

    Then what would happen if we call the feePayer function in the Example contract after the precompiled contract map has been updated after the hard fork? This answer depends on the context of the calling account assigned to msg.sender.

    The feePayer function in the Example Contract is executed and makes a delegateCall to the precompiled contract. If the Example calling address (msg.sender) is an EOA, it will always use the latest precompiled contract map, since EOAs do not store any hard fork data, as previously mentioned.

    In this Example contract, the delegatecall call is made within the EOA’s context instead of contract A’s. The EOA’s context is based on when the transaction is executed, whether 0x0a is a feePayer contract or not depends on the implementation of the hard fork for the block number at which the transaction is executed.

    In such cases, behavior will work in a way that is different from the initial behavior of the deployed Example contract due to the fact that the address 0x0a is no longer the address of a feePayer precompiled contract at the time of the call, and the msg.sender context of EOA accounts only recognizes the latest precompiled contracts map.

    Similarly, if our Example contract (delegatecall) was to be called by another contract, for instance, Contract A calls Example Contract (rather than an EOA account), then the msg.sender context is that of Contract A. If Contract A was deployed before the Istanbul hard fork, its context would dictate the same result as an EOA call. That is to say, a contract deployed before the hard-fork has a context that still assumes that feePayer is at address 0x0a.

    However, if a calling contract is deployed after the Istanbul hard fork then its context dictates that the latest precompiled map is used, and therefore the call will resolve correctly.

    Conclusion

    If you are using the call method to call a precompiled contract in a contract deployed before the hard fork, it won’t be affected by the change.

    But if you are using the delegateCall method, there could be issues depending on the caller’s context. Please be mindful of this and redeploy your contract if necessary. For such situations we have two recommendations:

    Article Series

    As mentioned in the Klaytn 2.0 Light Paper, Klaytn has committed to support Ethereum Equivalence. Klaytn v1.8.0 is a major milestone towards this initiative of compatibility which will enable seamless integration of Ethereum development tools with the Klaytn ecosystem. Given the potential impact of this major upgrade on the existing services running on the Klaytn ecosystem, the Klaytn team will be providing an article tetralogy — Toward Ethereum Equivalence for technical explanations on Medium, Klaytn Docs updates, as well as a temporary test network for users to test out the new features included in the Klaytn v1.8.0 release.

    Important Changes on the Klaytn Mainnet with v1.8.0

    1. Supporting London EVM

    All features supported by Ethereum’s London EVM are now supported on Klaytn. Ethereum’s London hard fork is the latest technological update to the Ethereum ecosystem with changes to the EVM.

    In other words, every EVM feature will now be available on Klaytn core protocol as well, however it should be noted that there have been some changes made with regard to precompiled contract addresses in the process of supporting London EVM, for which Klaytn developers should take into account. More on this will be covered in our second article in the Toward Ethereum Equivalence series.

    2. Supporting Ethereum API Format (eth namespace)

    Ethereum development tools will now be applicable for use within the Klaytn ecosystem. Klaytn and Ethereum have divergent data structures which have given rise to compatibility issues with the tooling. From Klaytn v1.8.0 onwards, making an API request using the klay namespace (e.g. klay_getBlockByNumber) will return results in the Klaytn data format exactly the same as what one would retrieve in previous Klaytn versions, whereas the eth namespace (e.g. eth_getBlockByNumber) will return values in Ethereum data format. Due to this additional data format support developers will be able to more readily utilize various development tools like Hardhat and Truffle within the Klaytn ecosystem.

    However, given the structural differences between Klaytn and Ethereum, the return values of some of the data fields have been adjusted. For instance, since Klaytn’s consensus mechanism is not based on PoW, the `difficulty` field in the block header has been adjusted to return a different value. We will share such notable differences in Toward Ethereum Equivalence #3 in more detail.

    3. New Transaction Types on Klaytn to Support Ethereum Transaction Types

    Ethereum’s transaction types AccessList and DynamicFee will be supported. In 2021, Ethereum introduced what is called the transaction types. But varied transaction types are something that Klaytn has had since the launch of its mainnet in 2019, so there was a compatibility issue with Ethereum’s new transaction types. Klaytn v1.8.0 includes fixes to resolve the inconsistencies between transaction types of Klaytn and Ethereum.

    Notably, since Klaytn has a different gas fee policy from Ethereum (namely its fixed gas fee structure), the introduction of Ethereum transaction types will not further reduce any transaction fee as they did in Ethereum. More on this will be shared in the upcoming article Toward Ethereum Equivalence #4.

    Temporary Test Network for v1.8.0

    We are excited to present our test network for Klaytn v1.8.0-rc version currently under QA process. Ecosystem developers can test out the changes of the new version, as well as partaking in the QA process.

    ​​HTTP Endpoints

    Websocket Endpoints

    Faucets

    Notes

    Timeline for v1.8.0

    Klaytn v1.8.0 will proceed with the following suggested timeline. From the changes listed above, “Supporting Ethereum API format will be applied to each endpoint node (EN) when it is upgraded to Klaytn v1.8.0. Other changes will be effective at the block number where the hard fork upgrade will be applied. The exact block number will be announced in the official release note and covered in our technical articles on Medium.

    Timeline


    Article Series

    It all started with an e-mail from Devcon5 that our Junghyun, the leader of Platform & SDK Team, received:

    Junghyun had believed that the rigorous demands of taking care of blockchain user account addresses, which typically associate with randomly generated character strings, stand as one of the biggest barriers that hinders blockchain mass adoption. In order to overcome such usability limitations, specifically within the Ethereum sphere, Junghyun, together with the Klaytn team, focused on extending account and transaction models while preserving compatibility, which were successfully incorporated into the Klaytn mainnet, launched this past June.

    He believed that Klaytn’s new account and transaction models are applicable to other Ethereum-compatible blockchain platforms to increase usability and performance. He thus proposed to introduce this system at this year’s Devcon, and he was officially invited to speak at this year’s Devcon, with a comment from the Devcon Team: “the Ethereum community should see this.”

    And we were off to Osaka, Japan.

    Devcon 5 at ATC Hall in Osaka, Japan

    Devcon is the annual Ethereum developers conference held by the Ethereum Foundation. With a mission to educate and empower the community to bring decentralized protocols, tools, and culture, Devcon invites builders of all kinds: developers, designers, researchers, community organizers, social economists, and artists.

    The first day of the conference started with the opening ceremony of the Ethereum Magicians, which is a self-organized fellowship, initiated by James Pitts and Greg Colvin in order to maximize technical opportunities, share ideas, and work together effectively across boundaries. With a mission to keep Ethereum “the best it can technically be,” the fellowship seeks to nurture community consensus on the technical direction and specification of Ethereum. In doing so, the fellowship invites any interested person to participate in improving the Ethereum improvement process, which can be submitted to the Ethereum Improvement Proposals, aka the EIPs. The EIPs describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards, which can be proposed by any Ethereum community member.

    The opening ceremony also introduced the Ethereum Cat Herders, a global grassroots community dedicated to improving the Ethereum protocol and community by improving underlying practices. The Cat Herders are in a sense ‘project managers,’ dedicated to facilitating and coordinating tasks required to achieve specific project outcomes within the Ethereum ecosystem and so assist with moving Ethereum forward.

    It was no surprise that Devcon 5 kick-off emphasized the power of community, which is often overlooked when we discuss blockchain. Community is the group of people, companies, and other organizations that together support and maintain the blockchain. It can include the core developers who work on building the network itself, the miners who own and operate the nodes that constitute the network, the larger ecosystem of developers and entrepreneurs who are developing applications on the network, the users who enjoy a variety of applications built on the network, and other researchers, participants, advisors, etc.¹ To run, maintain, and support a project, especially if it is decentralized, the communication, coordination, and facilitation among the productive community of dedicated members stand as key components.

    Klaytn, the Ground for All Blockchain Services

    We Klaytn also believe that building a strong community is one of the key elements in running our project. Committed to facilitating the creation of readily-usable blockchain applications (BApps), we are a 100% open source project to which we invite all the community to participate as a partner, a contributor, and a supporter of the project. You can visit our GitHub page at https://github.com/klaytn/klaytn to find more about the official Go implementation of the Klaytn protocol. For more details on Klaytn design, node operation guides, and application development resources, please visit the official Klaytn Docs, which recently released its Korean version as well. Further, you can also visit our Community at Klaytn Medium page to find more information about our efforts towards community building.

    After the Opening Ceremony, our team enjoyed a variety of inspiring sessions including Ethereum Roadmap 2020: EEA Meets with the Ethereum Community, which called for the protocol standardization, How Two Microsoft Engineers Build Blockchain Apps on Ethereum Networks featuring Microsoft’s Azure, Ethereum Roadmap 2020: Ethereum 1.0 and Eth1.x with Vitalik, State of Ethereum 2019, which explored the network’s growth based on Google Analytics data, Preventing Disaster: Advances in Smart Contract Vulnerability Detection, featuring MythX, and many more.


    After the first day of the conference, we attended the Global Coin Research x Decrypt Media Founder Happy Hour in the evening to see our partner, Joyce, the Founder and Editor-in-Chief of GCR. Joyce earlier participated in a discussion session with our Jason at the Consensus 2019 in New York. GCR’s recently published e-book, “The Small Handbook to Asia Crypto: on Local Ecosystems, Trends and Regulations,” also features Klaytn, which you can access via here.

    Sam introducing Klaytn’s vision and technology at KryptoOsaka Meetup

    Later, we participated in the KryptoOsaka Meetup: BUIDLing projects of East and West, hosted by Erica of KryptoSeoul. Our Sam, the Head of Technology, introduced Klaytn’s vision and technology, and engaged in a discussion session with other great panelists from CoinMarketCap, HyperLedger, Cosmos, Terra, Zcash, and BlockStack. We were also excited to see some of our community members including the 1st place winner of the past Klaytn Hackathon!

    Junghyun presented on the 2nd day on Klaytn’s extension of Ethereum’s account and transaction models. He first introduced some of Klaytn’s features that support enterprise usability and mass user adoption: immediate finality, high performance, high scalability, hybrid network architecture, and high usability.

    He then identified some of Ethereum’s usability limitations that include immutable private key, lack of multisig mechanism, difficulty of extending functionalities, unnecessary transaction fields, and lack of fee delegation.

    In efforts to improve such limitations, Klaytn has adopted some of new features. First, Klaytn has added account management functions to offer better flexibility in empowering users: changeable private keys, support of multiple private keys, and support of role-based keys, i.e. breaking down permissions based on signing transactions, updating accounts’ key, paying transaction fee on behalf of users. The native support of multi-sig and role-based keys, which is demanded by industry, will hopefully accelerate the blockchain mass adoption and build trust with users.

    Junghyun presenting ‘Extending Ethereum’s Account and Transaction Models in Klaytn’ at Devcon5

    Klaytn also refined the transaction model so that each transaction type serves a specific function. This separation of concerns gives more opportunities for performance, usability enhancement, and storage optimization (i.e. 64B reduced for EOAs by adding 1B overhead for type per account) as well as makes it easy to add or extend platform features. Utilizing this design, we introduce several new transaction types without breaking backward compatibility to support the transaction-fee delegation and the extended account management features mentioned above.

    Klaytn’s new account and transaction models are also applicable to other Ethereum-compatible blockchain platforms, and we hope that our system can trigger the mass adoption of blockchain experiences for millions of users across the globe.

    It truly was a meaningful opportunity for us to be able to share our efforts towards enhancing usability at this year’s Devcon. We are very grateful for all the attendees, including the Tokyo FinTech’s wrap-up on Junghyun’s presentation!

    In addition to our sessions and meetups, we also met with several teams and projects that could potentially work together with us in the future. We are dedicated to continually offering high-quality and user-friendly blockchain services, and together with our partners, we will further strengthen our ecosystem.

    Devcon 5 was full of inspiring sessions and exhibitions, plus great rest zones, giveaways, and treats. We also look forward to seeing the newly proposed Ethereum 2.0 moving forward.

    More updates on our technology and business to be shared on our Medium page.

    Thank you.

    About Klaytn

    Klaytn is a public blockchain focused on the metaverse, gamefi, and the creator economy. Officially launched in June 2019, it is the dominant blockchain platform in South Korea and is now undergoing global business expansion from its international base in Singapore.

    These business expansion activities are supported by the Klaytn Growth Fund, which aims to grow the ecosystem of companies built on Klaytn. The fund is managed and disbursed by Klaytn Foundation, a Singapore-based non-profit organization established in August 2021.

    Klaytn Official Community
    https://klaytn.oas.asia/
    http://twitter.com/klaytn_official
    https://www.facebook.com/klaytn.official/
    https://www.linkedin.com/company/klaytn
    https://www.facebook.com/groups/klaytndevelopers/


    [1] Josh Stark, “Building the Foundations for a Scalable Ethereum Community” CoinDesk: https://www.coindesk.com/building-foundations-scalable-blockchain-ethereum-community