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:
- We will support London EVM.
- We will support eth namespace APIs.
- 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
- The v1.8.0 hardfork will be in effect on March 31th, the block number would be 86,816,005.
- 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.
- Toward Ethereum Equivalence #1
- Toward Ethereum Equivalence #2
- Toward Ethereum Equivalence #3
- Toward Ethereum Equivalence #4
- Using Ethereum Tools in Klaytn
- Klaytn v1.8.0 Release Notes
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:
- 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.
- 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.
- 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:
- Contracts deployed prior to the hard fork
- 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:
