The German poet Goethe once wrote: “Enjoy what pain has left behind for you! With hardship past, the same hardships are sweet.” No matter the external circumstance, if we persevere in what we believe to be right, we will look back and smile at what has passed.

Klaytn has also been focusing on strengthening our fundamentals in pursuit of the values we espouse. So we proudly announce the release of v1.8.4, which includes extensive improvements in our ServiceChain, an integral element in Klaytn’s Metaverse Package. FYI, the release only pertains to the ServiceChain, so CNs or PNs don’t need to update.


# Improvements
The name of the VT_RECOVERY option changed to SC_VT_RECOVERY. The option VT_RECOVERY is still usable with the update and is the same option. The option SC_VTRECOVERY_INTERVAL has also been added, which configures the cycle for Value Transfer Recovery. The default value is 5 seconds. (#1271)

Two APIs for the Subbridge namespace subbridge_getChildBridgeContractBalance and subbridge_getParentBridgeContractBalance have been added that return the balance for the respective contracts. (#1254)

We added a logic to check the address type, which is a parameter for the setBridge() function used for setting up a bridge in a token contract. If the address is not of a contract, it cannot be set up as a bridge. (#1299)

The option SC_KAS_ANCHOR_REQUEST_TIMEOUT has been added. Using this option, you can set the timeout for KAS API requests. (#1284)

You can now change the default gas price for ServiceChain. (#1287)

In previous versions, the gas limit for SCN node operators was fixed to 10000000. Transactions that used more gas such as contract deployment would not be processed with the fixed gas limit. So with the update, you can now set your own gas limit for each chain. (SC_PARENT_OPERATOR_GASLIMIT and SC_CHILD_OPERATOR_GASLIMIT). You can also GET and SET the current gas limit for your node using the four new APIs. (subbridge_setChildBridgeOperatorGasLimit subbridge_setParentBridgeOperatorGasLimit, subbridge_getChildBridgeOperatorGasLimit, subbridge_getParentBridgeOperatorGasLimit). (#1353 #1344)
We added the chaindatafetcher option for SEN nodes. This node functions in the same way as the chaindatafetcher option in existing EN nodes. (#1347)

# Fixes
There was a bug in which the URI value when sending ERC-721 tokens were set as an empty string. To solve this, some changes regarding a new event structure as well as a new logic to handle the event have been added. (#1321 #1378)


# Miscellaneous
You can now find out the location of the imported account file when importing accounts using the node command account import. (#1285 #1262)

For more details, please check out this link. Subscribe to our official Medium to not miss anything! Thank you!

Hello, this is Klaytn Team!

Recently, there has been a lot of false information circulating regarding Klaytn’s technology and the mainnet’s stability, so we would like to take this opportunity to set the record straight. This article does not intend to deny the inconvenience experienced by users, but rather to clarify the core causes of the issue, and to help users decide for themselves whether technological improvements for Klaytn and the Klaytn ecosystem would be possible.

Q. Klaytn network fails frequently due to stability issues?
In the 3 years of Klaytn’s existence, there have been 2 cases when the Klaytn mainnet actually experienced an outage. The causes as well as the patch for the network delay have been explained at depth immediately after the measures.

These incidents are not uncommon even for other promising projects. According to an article by Coin Telegraph from May 2nd, there have been seven such incidents just this year alone. Nevertheless, there isn’t much criticism that it “stops often” as there is of Klaytn. So the comments from our communities that Klaytn “stops often” must not simply refer to these two incidents. We will get back to this after explaining the extended network delay.

Q. There have been times when blocks have not been created for an extended period of time. Is it due to a fault in the consensus mechanism?
The extended block creation delay is actually proof that Klaytn’s consensus mechanism works in a stable manner. A transaction bug was identified, and it did not go unnoticed by the consensus algorithm, which then put block creation and processing on hold.

Q. What do you mean that the consensus mechanism worked as expected when the block creation stopped?
The mainnet was designed to halt block creation upon detecting a bug due to its distinct philosophy. Klaytn’s consensus mechanism is based on a philosophy that is architecturally different from Bitcoin or Ethereum. Bitcoin or Ethereum can continue to process transactions even with incidents, but a transaction already processed may get reverted. On the other hand, Klaytn waits for the incident to be resolved. Transactions will not get reverted.

For example, an EVM bug found last year on Ethereum creates a fork, but Klaytn stops the creation of blocks altogether rather than skipping over the problematic block or allowing a fork to happen. When a fork happens in the presence of a bug, the receipt of a coin or the processing of a contract may be reverted. To alleviate this problem, you can wait for multiple blocks to be validated, but not reverting already processed transactions is the approach that emphasizes stability more.

The aforementioned architecture of Klaytn also guarantees quick processing of transactions with 1-second finality, which enables excellent usability. Unlike other coins that need to wait for additional blocks to be created when withdrawing from exchanges, Klaytn works immediately. When blockchain technology is more integrated into our daily lives, this instant finality and usability will prove themselves to be even more valuable.

Q. Why do people say that Klaytn “stops often”?
1) During network congestions, there could be delays due to the clogging of transactions waiting to be processed, or 2) the ecosystem services are not handling the overload well, which leads the ecosystem participants and users to think that the network stopped. Without accurate knowledge of the cause, communities have been speaking of “Klaytn’s network failure” which led to these misunderstandings, but the Klaytn mainnet did not stop. And these services have regained stability through increased throughput and a massive expansion of resources.

We recall that these incidents happened frequently from the end of 2021 till early 2022, causing users inconvenience. At the time, the transactions in the network have increased to more than what it can process, or the usage of a certain service exploded temporarily following the events below.

1) Incessant deployment of a large amount of transactions for arbitrage
As we explained in the Klaytn’s Network Status, more transactions than what can be processed in a given amount of time were being created, and with high frequency. If there are more transactions than what the network can process, users may experience some delay until their transactions are handled. It may have been different from the 1-3 second which the users were used to. And due to the large number of transactions, the internal processing for Klaytnscope the block explorer was also being delayed, giving users the impression that no more blocks are being created.

2) NFT airdrops in the rapidly growing NFT ecosystem
Early 2022, Klaytn had a lot of NFT projects with airdrops. Most NFT airdrops used Kaikas, and during the actual mintings the usage of Kaikas skyrocketed within a short amount of time. Since the Kaikas Team is not aware of the airdrop schedules for each team nor the size, it was difficult to respond flexibly.

As explained in the Klaytn’s Network Status published shortly afterwards, what users thought of as “stopping often” is not attributable to the stability of Klaytn’s network, but rather services not being able to handle the sudden increase in transactions. Klaytnscope and Kaikas later recovered through throughput improvement and resource expansion. At the same time, we also felt the need for improvements in Klaytn’s policies for not being able to prevent the occurrence of the bursts in transactions.

Q. What had to be improved in Klaytn’s transaction policies?
We saw the need to improve the way that the transactions were being processed:
1. Transaction ordering
2. Gas fee policy

For transactions that attempt arbitrage, the most important thing is to be included in the blocks as quickly as possible. In Klaytn, we used to include the transactions in a block in a random way without providing a logic for determining a priority. This led some arbitrageurs to send a large amount of transactions to increase the likelihood of their transactions being selected to be included in the block. Arbitrages constitute an important part of a DeFi ecosystem, but sending too many transactions can cause inconvenience for other users, because their transactions will be delayed.

After communicating with our communities, the Klaytn Team has come up with two ways for improvement. The first is to get rid of the cause that leads arbitrageurs to send out excessive amounts of transactions. Specifically, we decided to introduce the First-Come, First-Serve mechanism, whereby the transactions that arrived first would be processed first, which disincentivizes the arbitrageurs to create too many transactions. The second is to financially impose a burden when the transaction bursts happen for whatever reason, raising the cost for such behavior. To this end, Klaytn plans to introduce a dynamic gas fee, instead of the current fixed model.

Q. What is the background of the gas price increase?
Here is the timeline of events leading up to the gas price increase.

The surge in transactions at the time was not an organic outcome in the course of the growth of the Klaytn ecosystem, and thus it has led to many unwanted side effects. We think that the biggest cause of the phenomenon is that the cost for monopolizing or freezing the network was so low. This is something that can be abused by malicious actors to attack DeFi services. Furthermore, there were also cases where some services couldn’t keep up with Klaytn’s high throughput. For block explorers or exchanges, their internal system must be able to check all the transactions, for which they weren’t ready. From node operation perspective, the required resources have increased along with blockchain data. And these problems have been misleadingly simplified as “Klaytn stops often”, which harms the credibility of the network’s stability.

Q. What is going to happen with the gas price policy moving forward?
May 12: Baobab Gas Price Adjusted to 250 ston

*The schedule for dynamic gas price policy may be adjusted according to the development progress.

Gas price was first introduced as a measure to prevent network stoppage, and many blockchains alleviate excessive transactions using gas fees. Especially, Klaytn uses a fixed gas price, which called for a steeper increase in the gas fee. The Klaytn Team therefore aimed to solve network issues by raising the gas price in the short-run, and consider introducing a dynamic gas price in the long-run. Fixed gas fee policy is easy to use for services and offers many advantages including convenient price calculation. Since there are more services on the Klaytn network, it would have to evolve in a way that it can withstand network monopolies or stoppages.

The decision to increase the gas price was a process that involved a great deal of communication with the communities, but the effectiveness left a lot to be desired. As expected, it did stop excessive transactions from being sent, but it also had a dampening effect on the whole ecosystem. That is why the Klaytn Team saw it necessary to implement a dynamic fee policy to stabilize the network and minimize gas price burden.

With the Klaytn v1.8.3 upgrade, the transaction processing mechanism will be improved, after which the gas price will be cut back to 250 ston, because the incentive to create excessive transactions has been eliminated to a certain extent. Afterwards, we will introduce a dynamic gas price as a more fundamental solution. In most cases, the gas price will remain low, and when the network is using a lot of gas, the gas price will be adjusted to a higher level accordingly. For more details, please refer to the Klaytn Forum and KIP and feel free to share your thoughts.

Greetings from Klaytn Team!

The Klaytn team has been working hard at all fronts to realize the vision for Klaytn 2.0 and it’s goals for becoming “The Metaverse Blockchain for All”. In this post, we will share the 2022 roadmap for Klaytn’s technology development. The roadmap serves as a plan for Klaytn’s tech team and is subject to change in accordance with the external and internal factors but is intended to be used as our progress map. Nevertheless, in the spirit of transparency, we are sharing with youall of the interesting and exciting details of our upcoming technology roadmap.

2022 Q1 Roadmap

2022 Q2 Roadmap

2022 Q3 Roadmap

2022 Q4 Roadmap

The following table is a summary of the 2022 Quarterly Tech Roadmap.

Moving forward, we will be sharing at the end of each quarter a review and plans for the following quarter. We are thankful for each and every one of you that stood by us and showed love for the Klaytn ecosystem. We will be communicating with you more often in the future. Thank you!

TL;DR:


It has been almost a month since Klaytn’s gas price was adjusted to combat the extreme network congestion caused by bot spam and DoS attacks. We have been actively monitoring the mitigation measures, and in our decision to adjust gas price to 750 ston, we’ve managed to remove more than 99% of bot activities associated with ​​empty transactions.

As part of our initial plans to reduce the impact of this gas price increase on Klaytn ecosystem participants, we will be burning the net difference due to the increase, to maintain the level of KLAY tokens in circulation and preserve the value for KLAY hodlers.

The burn is scheduled to take place on the first week of each month, where the amount of KLAY to be burnt will be calculated from the previous month and sent to 0x000000000000000000000000000000000000dead.

In the first week of May, over 1 million KLAY from the month of April will be burnt. For transparency, the Klaytn Foundation will share the final amount of KLAY burnt and the transaction hash after each burn.

This monthly burn will be in place until the new dynamic gas fee mechanism with automated fee burning is implemented.

Further optimization measures to reduce gas price

As part of our continual efforts to optimize these mitigation measures, we’ve found a potential root cause of the network congestion. Before, there wasn’t a way to prioritize the transactions, which incentivized arbitrage bots to submit as many transactions as possible to maximize the probability of their transactions entering the block.

With the Klaytn v1.8.3 update, we’ve implemented a First-Come, First-Served (FCFS) transaction ordering algorithm that will queue transactions to be included in the block according to submission time. This should remove the reason to submit multiple transactions, and is expected to help prevent a significant amount of network congestion.

With the FCFS algorithm in place, and after a round of gathering the community’s feedback, we’ve decided to bring down the gas price to benefit the community. Hence, we will be reducing the gas price to 250 ston and carefully monitoring the impact. The gas price adjustment will be implemented on Baobab Testnet on May 12th, 2022, and Cypress Mainnet on May 22nd, 2022.

Future plans to implement dynamic gas price mechanism

As part of our long term strategy, we are also simultaneously working on a dynamic gas price mechanism with automated fee burning, in which gas price fluctuates according to network demands and any increase in gas price will be automatically burned. With a dynamic gas price mechanism in place, it will allow us to further reduce the gas fees when the network traffic is low.

You can find out more and discuss the new policy here for EN and here for KR.

There’s something I always say: being consistently good beats occasionally great, which is actually a description that fits perfectly to the weather here in Singapore. It’s sipping-on-coconut-on-the-beach kind of temperature all year round. But perhaps just as impressive as the climatic consistency, there are some things that just keep getting better. Like what, you ask? We are proud to introduce the release of Klaytn v1.8.3, packed with new features and improvements!

What’s New

Improvements

Fixes

Miscellaneous

The upgrades will be applied to Baobab at the end of April, to Cypress in mid-May. For more information, please refer to this link.

Don’t miss any updates by subscribing to our mailing list. Thank you!

In this post we want to explain to you about the overall architecture of Klaytn. Klaytn is a project that started as a fork of Ethereum in June 2018. It has been an open source project since the mainnet launch in June 2019, and is accessible on Github. The complete development process of Klaytn takes place in the repository, so feel free to drop by when you want to know more about it 😀 We also welcome code contributions!

First, here is a complete picture of the Klaytn architecture.

The following sections have short descriptions of each of these layers in more detail.

Application Layer

The application layer includes modules that run on top of Klaytn. This layer does not have anything to do with the actual blockchain core. Currently, it only consists of the contracts module, which contains the smart contract code for various integral purposes like Klaytn’s L2 ServiceChain and mainnet interaction or precompiled contract usage examples. To check out all standard smart contracts supported in the Klaytn ecosystem, please refer to klaytn-contracts.

Wallet Layer

The Wallet Layer includes modules related to wallet management on the Klaytn nodes themselves. With the wallet function nodes can manage private keys and give signatures on transactions, which is useful when individuals are operating nodes. Wallet management is tricky business, beware of vulnerabilities when you are using the same wallets to manage multiple nodes. Unlike Ethereum and other chains, Klaytn allows you to store multiple private keys attached to a single account giving developers to manage accounts through Role Based Access, or on-chain multi-signature account control. Key management and transaction signature features have changed to support this functionality. For more details on the newly added keystore v4, please refer to KIP-3 and to understand the Klaytn Account Model see our documentation here.

Interface Layer

The Interface Layer includes modules related to node execution and API calls.

Execution Layer

The Execution Layer is where the core blockchain functionalities sit. In the blockchain/types module, data structures such as account, transaction, block, receipt are stored. Klaytn has designed and implemented a new account and transaction model for higher performance and scalability. For more details, please refer to Klaytn Docs.

Governance Layer

The Governance Layer is where the governance features are implemented.

Consensus Layer

The consensus layer provides three possible algorithms: PoW, Clique, Istanbul BFT. Klaytn mainnet uses the Istanbul BFT algorithm, while the first two contain the exact same code originally forked from Ethereum and are not currently being maintained by Klaytn.

Cryptography Layer

The Cryptography layer includes various modules related to cryptography. Cryptography is an integral part of the blockchain system, it is used for merkle hashing and fast data verification as well as transaction signing and transaction authentication. Klaytn uses a safe, and widely verified cryptography system based on the ECDSA secp261k1 curve: same as Ethereum, Bitcoin and others blockchains.

Synchronization Layer

The Synchronization Layer provides a data fetcher, and a downloader for syncing with other nodes along with chaindatafetcher, which is used to stream block data effectively.

Network Layer

The Network Layer enables grpc, p2p, rpc network communications. The components of this layer uses the code forked from Ethereum without active maintenance on the part of the Klaytn Team. Compared to other layers, the Network Layer has been validated and optimized over a long period of time. It requires a long-term approach instead of immediate improvements to its performance.

Storage Layer

The Storage Layer provides the data structure and related features to store the blockchain data in the disc. We have implemented an interface to support various types of database using the database module. Currently, levelDB is being used.

In this article, we introduced the various modules in Klaytn in layers for developers and the community to better understand what is going on under the hood of the Klaytn blockchain. To further this understanding, we will go over each module in more detail in future posts. If you are curious about a specific module, please let us know in the comment section. Thank you!

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
  • Staying true to our mission of moving towards greater decentralization, we are happy to announce that Klaytn Docs is now open source. Klaytn Docs is where you can find everything you need about Klaytn, from our history, vision, and key concepts, to technical instructions, explanations, tutorials, and more.

    What this means is that you — or anyone else for that matter — can now contribute to Klaytn Docs. Whether it’s an entire in-depth tutorial or correcting a tiny mistake that triggers your inner grammar pedant, you can now play a part in shaping up Klaytn Docs!

    To be more specific, you will need to submit an Issue before making your contribution through a pull request on GitHub. Please follow these steps in the Contribution Guideline. Just to give you a heads-up, we currently only accept pull requests for the English version of Klaytn Docs. But if you have anything to say about the Korean version of Klaytn Docs, you are welcome to create an Issue and our maintainers will handle it.

    As an open source project, the support from our community is of paramount importance. Your contributions are what have been driving the Klaytn ecosystem forward. We look forward to your active participation!

    They say one human-year is equivalent to seven dog-years, and a similar ratio goes for crypto and the traditional industries. That being said, we are so thrilled to finally release Klaytn v.1.8.0 after five months since our last big update. We will explain what has changed, and what the changes mean for you.

    Klaytn v1.8.0 contains a protocol upgrade which results in backwards incompatible changes, like the Ethereum hard forks. All nodes would thus have to be upgraded to v1.8.0 or higher before the target block number.

    The planned hard fork schedule is as follows:

    Baobab Testnet (Baobab block number 86513895, planned date: March 24)

    Cypress Mainnet: Block number 86816005, estimated time is 12:30 ~ 13:30 (UTC+9), 31st March 2022.

    Note: Istanbul EVM hard fork includes changes in the gas cost for the EVM opcode as well as in using the APIs. The existing contracts may not function as expected due to these changes, so please refer to the [Cautions on the Protocol Update] section of this article.

    Protocol Upgrade Features

    – Introduced EthTxType hard fork that enables new transaction types to support Ethereum transaction formats: TxTypeEthereumAccessList and TxTypeEthereumDynamicFee (#1142 #1158)

    What’s New in v1.8.0

    – EthereumTxTypeEnvelope has been defined (#1171)

    – You can use the EIP-2930 signer and London signer for the new transaction types (#1142 #1158)

    – eth namespace APIs are now available to support Ethereum API format (#1076 #1077 #1083 #1088 #1093 #1095 #1121 #1123 #1124 #1127 #1129 #1130 #1134 #1172)

    – Added new klay namespace APIs: klay_maxPriorityFeePerGasklay_createAccessList, and klay_feeHistory (#1156)

    – With the rpc.eth.noncompatible flag, you can disable Ethereum API format compatibility (#1072)

    – Added baseFeePerGas field in the block header API return values (#1183)

    – Implemented State Snapshot (#1112 #1116 #1152 #1154 #1155 #1173 #1174)

    – Implemented auto-restart daemon for crash tolerance (#1101)

    Improvements

    – Adjusted account manager unlock timing when a node starts (#1141)

    – Allowed add/remove multiple validators in a single vote (#1110)

    – Enhanced the validation logic of governance voting API (#1109)

    – Unified mutexes in blockchain.go (#1099)

    Fixes

    – Fixed a governance cache initializing bug (#1168)

    – Fixed klay_gasPrice API to return proper gas price values (#1211)

    – Fixed race condition issues triggered by transaction fields update (#1091)

    – Fixed call tracer panic caused by deep return objects (#1203)

    ETC

    – Set hard fork block numbers for Cypress network (#1230)

    – IstanbulEVM hard fork: 86816005

    – LondonEVM hard fork: 86816005

    – EthTxType hard fork: 86816005

    – Set a hard fork block number for Baobab network (#1230)

    – EthTxType hard fork: 86513895

    Cautions regarding the hard fork

    The new version is going to affect Klaytn DApps currently in service, so if you are a service operator or a developer, we recommend you also read the series Toward Ethereum Equivalence #1 #2 #3 #4 along with the instructions below.

    For DApp Services Providers

    You may experience Out of Gas errors with old smart contracts.

    The IstanbulEVM hard fork EVM includes changes in the gas cost for the opcode (Please refer to “Protocol Upgrade Features” in the Klaytn v1.7.0 Release Notes). If your contract had a lot of functions that require limited gas cost like fallback, the change in gas cost may cause an Out of Gas error. So far we have determined these cases for upgradeable contracts that inherited OpenZeppelin’s BaseAdminUpgradeabilityProxy.sol and BaseUpgradeabilityProxy.sol implementing a fallback function identical to Proxy.sol. Please check if your functions are implemented in a similar way. Also keep in mind that gas costs are subject to constant change, so please refrain from using actions with heavy loads in the fallback except for printing logs (reference).

    Some Precompiled Contract addresses will be changed.

    The addresses vmLog(0x09)feePayer(0x0a)validateSender(0x0b) will be transferred to ensure compatibility with Ethereum’s precompiled contracts. It only applies to contracts deployed after the hard fork; contracts deployed before that will remain usable. For more details, please refer to Toward Ethereum Equivalence #2 — Changes in Precompiled Contract Addresses.

    Update your caver to v1.8.0 or higher to support the new transaction types

    You will be able to use the new transaction types with the EthTxType hard fork. If you need the new transaction formats for services that require accessing the transactions of other accounts, make sure to update your caver to v1.8.0 (jsjava) or higher. For more details on the new types, please refer to Toward Ethereum Equivalence #4 — Ethereum transaction types.

    For EN Operators

    New return values for eth and klay APIs

    Before, you could make an API call using the eth namespace and it worked the same as klay namespace. But starting with v1.8.0, the eth namespace APIs will adopt Ethereum API return formats. You can find out more in Toward Ethereum Equivalence #3 — Supporting Ethereum API formats. If you want to stick to the behaviors of the old version and use eth like klay, just add the — rpc.eth.noncompatible init option.

    Add eth in the EN’s default allowed API list.

    eth namespace APIs are supported for ENs, and eth has been added to the default allowed list. You need to add eth to the configurations of RPC_API and WS_API in the kend.conf file in order to use eth APIs. netweb3 APIs used with Ethereum tools like hardhat have also been added to the list. To sum up, the default API white list in v1.8.0 includes: RPC_API=”klay,net,eth,web3″, WS_API=”klay,net,eth,web3″

    v1.8.1 Release Notes (Added March 18)

    This version contains a fix that enhances MetaMask compatibility. It affects the return format of block header APIs. So, it is recommended that you update the ENs using the eth_getHeader-related APIs to this version.

    v1.8.2 Release Notes (Added March 23)

    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: ...,
    });