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
  • As we shared in our Bot Transaction Analysis Report, the Klaytn mainnet has been experiencing sudden and sustained surges in transactions recently. This has caused great inconvenience to Klaytn users by congesting the network, misleading them to believe that the network was down or not operating correctly, when in fact the network was producing blocks as normal but the elevated transaction load was slowing down processing times . In this article, we would like to share the progress on our technological efforts to overcome this problem.

    The Spam Throttler implementation

    The Spam Throttler was created as a response to bot transactions around the end of 2021. It was found that these bot transactions were generated by a few entities, who almost took over the entire network for a few hours. While they used various sender addresses, the number of recipient addresses were limited. Over 99% of the transactions were intentionally being manipulated to be reverted. The Spam Throttler limits the speed at which the recurrently reverted transactions are propagated, thereby giving more opportunities for normal transactions to be included in a block.

    Instead of “blacklisting”, whereby transactions from accounts and addresses are precluded from using the network with this centralized way of processing, we opted for a method by which a PN can analyze the newest blocks via an algorithm. We wanted the network resources to be decentralized and distributed evenly to a large number of users, instead of being concentrated on a few creating another layer of centralization. The criteria for spam transactions have also been defined to only cover substantial amounts of reverted transactions.

    How the Spam Throttler works

    Such a solution that involves limiting system performance bears the risk of being exploited by malicious actors. To prevent such an ill-intentioned user from using the Spam Throttler for crippling the network, we also have put in place the following measures which will curb any unintended side effects of the Spam Throttler.

    1. The Spam Throttler only limits propagation speed during periods of transaction overload on the Klaytn network
    2. A certain level of TPS is guaranteed for Throttle Lists (Current: 100 TPS)
    3. Non-faulty services can be whitelisted in case of emergency
    Number of reverted transactions from Dec 2021 to Jan 2022

    The Spam Throttler was applied on the mainnet in early January 2022, which immediately led to a dramatic drop in reverted transactions. It also succeeded in regulating excessively occurring reverted transactions, decongesting the network by reducing these spam reversion transactions. However, while this feature was successful in handling the reverted transaction spam, it ultimately was not sufficient alone to completely eliminate bot-generated spam transactions. Since the introduction of the Spam Throttler feature, the bots have found a way to bypass reverted transactions by adjusting their logic to return gracefully instead of reverting outright. In sum, the Spam Throttler did reduce the number of reverted transactions, but did not alleviate the total number of bursty transactions.

    Problems caused by bot transactions and technical solutions

    Besides the Spam Throttler, the Klaytn Team is also testing out various technological solutions to mitigate the problem of transaction overload. To this end, we categorized the users’ inconvenience into three groups to implement the technological solutions suitable for each.

    1. Error or transactions deployment failures when using Endpoint Nodes (ENs)
      This problem occurs when transactions suddenly increase to more than what an EN can accommodate. ENs are the primary transaction submission and gossip handling nodes within the Klaytn network. If you’ve ever seen the error message “Txpool is full” on Kaikas, a congested transaction pool on the EN was the cause. In order to mitigate this problem, the Klaytn Team is working on a solution to restrict the number of transactions received externally when each node stores transactions. At the beginning of January in 2022, many other experimental features have been applied to some ENs including the Kaikas EN. The number of users experiencing “Txpool is full” on Kaikas EN have significantly decreased. Through various experiments, this feature will evolve so that an appropriate number of external transactions can be manually set per EN by the operator.
    2. Network monopoly of certain users/services
      This problem is what the Spam Throttler is intended to help mitigate, and is also the most technologically complex one to solve. For the long-term, we are working on ways to increase network throughput in terms of TPS and scaling solutions. We are also finding ways to advocate and enforce a fair utilization of network resources. Other solutions currently under consideration include first-come-first-served basis propagation and block inclusion, and fair management of multiple users’ transactions by nodes. Adjustments on the policy level such as transaction fee adjustments are also being taken into account.
    3. Inability to prioritize transactions during network overload
      Klaytn’s policy of maintaining a fixed gas price, and in turn the deterministic gas fees, offers many advantages to developers. However, a critical downside is that the transactions cannot be prioritized during network congestion. The Klaytn Team is aware of this problem, and is contemplating an adjustment to the current price model. Possible options include a more flexible fee model, differentiated fee model, or fee burning model. Since this is a change that can greatly impact the ecosystem, we will make sure to base any decisions substantiated with sufficient preparations, research, real world data and communication.

    The Klaytn Team also intends to collaborate with our ecosystem in solving these problems. We are aware that these issues have several add-on effects such as transaction freezes on exchanges, and bot transactions during NFT/DeFi project launches, which could cause Klaytn users great inconvenience. Since these are issues that cannot be considered only in the context of the Klaytn protocol layer alone, but affect the ecosystem as a whole, we will work jointly with the support and help from our ecosystem and community members. Klaytn ecosystem development is truly open-source and as such we welcome any contributions to the Klaytn ecosystem and communities via GitHub, Discord, or our developer forum.

    We are recently noticing massive numbers of transactions on the Klaytn network. The below graph shows the network status during a prolonged instance of large numbers of transactions at 18:30PM (EST), December 9. During this period, the Klaytn Cypress mainnet processed approximately 4.5 million transactions (mostly complicated smart contract executions) in 3 hours, at a rate of 1 block per second.

    Transactions processed per second
    New Block Generation

    Inconveniences Arising From Massive Transaction Loads

    Although the Klaytn mainnet have been creating blocks as expected, deployments of large amounts of transactions can cause following inconveniences:

    1. It may take more time for a transaction to be included in a block.
      When there are more transactions than what the network can handle, new transactions may have to wait until they are added in the block. The time it takes for a transaction to be processed may become longer.
    2. Deployments of new transactions using apps like Kaikas may be rejected. There is a limit of what a Klaytn node can hold in transactions. When the number of transactions exceeds that limit, the node will reject new transactions and wait until the existing ones are processed. In this case, we recommend you give it some time before trying again.
    3. The data shown on Scope may not be up to date with the actual network.

    Scope displays a processed version of the data generated on the Klaytn network. When a large number of transactions are created, the data processing on Scope may slow down due to the overload. The developers of Scope are also aware of this issue and are working to fix it.

    Klaytn Team’s Position to the Large Transactions Loads

    Most of the bulk transactions recently are requests for smart contract execution. Most of them are being reverted. These transactions use up more node or KlaytnScope resources compared to a KLAY transfer, and they cannot be seen as anything meaningful. Klaytn Team are working on technical plans and policies to counter these kinds of transactions. We will update you on this in the near future.

    Additionally, we are providing an alternative to KlaytnScope where you can check the real-time network status of Klaytn network in the link below. It shows the status of some of the nodes operated by GroundX. Data such as the block creation status (Head Block Num), transactions per second (TPS), and the number of transactions submitted to the network (TxPool-pending) are available. A website providing data on more Klaytn nodes will officially be launched in the near future.

    You can check the Klaytn Network Status at: https://status.klaytn.com

    Kaikas?

    Kaikas is a digital wallet that allows you to manage accounts, sign transactions, send tokens, and search transaction history. It is currently available as a browser extension and mobile application. You can download the browser extension here, and the mobile app in App Store or Google Play.

    About the mobile app

    Kaikas is currently available as a browser extension and mobile application. You can manage your account using both of them, but token transfers for the mobile version are temporarily disabled at the moment due to policy issues, and you can only store/send NFTs. The mobile version is undergoing renewal and is planned to be launched later in the year.

    User Features

    Safe Account Management

    The name “Wallet” can be pretty misleading as one is led to imagine a physical space that stores assets, but is more like an account manager than a wallet. It stores the address and keys. Your assets are actually in the blockchain. The keys merely grant you access to them.

    Kaikas uses HD (hierarchical deterministic) addresses, which allows you to create multiple keys using a single seed. If you keep your seed phrase safely, you won’t have to remember each key for your accounts. The seed phrase is also used to recover your accounts, so take good care.

    Below is what a seed phrase actually looks like. It is from an actual account, so go ahead and see what it feels like to hack an account. 😘

    Another thing you have to keep safely is your Wallet Key, which includes your Private Key and Klaytn Wallet Key. You can find the Wallet Key in Account Details as shown below.

    Your Wallet Key is also used to import accounts, so if you lose it, your account may not be recovered. Be careful!

    Token Transfers

    You can also send tokens using Kaikas. More specifically, a token transfer happens by submitting a transaction to the blockchain, which requires a signature. And what do you give the signature with? Your Private Key! Since Kaikas stores your address and Private Key, you can send and receive KLAY, KIP-7, KIP-17, KIP-37, and NFTs or view transaction status or history.

    FYI: NFTs are not “visible” in the browser extension as of now. You can view them on Kaikas Mobile or KlaytnScope.

    Custom Tokens

    You can also add Klaytn-based custom tokens as shown below. To do this, simply click on [Token List] and you will see the [Add Token]. You can browse and add KCTs (Klaytn Compatible Tokens) used in different BApps.

    It’s also possible to add your own custom tokens. Below, a token called G1 which was minted on Baobab Testnet using KAS Console has been added to the list.

    Integration with BApps

    Many BApps emerging on Klaytn lately have integrated Kaikas. Kaikas acts like an interface at the front end between the users and the service. The features we have seen earlier, like logging in, signing transactions, using KLAY etc. can be implemented easily with Kaikas.

    Let’s look at a couple of examples where Kaikas is used. First, there is the DeFi service KLAYSwap. You can use Kaikas to stake or exchange KLAY and KCTs via KLAYSwap. If you want to use KLAYSwap with assets from a different blockchain, you have to convert them into KCTs using Orbit Bridge, which also involves Kaikas.

    Klaytn’s very own NFT minting service KrafterSpace also uses Kaikas. Below you see the pop-up window for logging in. You can see that you are required to sign.

    The NFTs not seen on the web extension are now visible on KrafterSpace as shown below. You also sign the transaction using Kaikas when sending NFTs.

    Network

    Using Baobab network allows you use Kaikas without spending actual KLAY. You can receive play money (test KLAY) to test out the different features. TO do that, select Baobab Testnet in the top left corner of the Kaikas window and click on the link under the [Send] button, or just visit https://baobab.wallet.klaytn.com/faucet, where you will be asked to provide your Private Key or Klaytn Wallet Key.

    Developer Features

    Klaytn Provider

    If you are a blockchain developer, you can also integrate the Kaikas to your service to introduce various features as seen above. For this purpose, Kaikas acts as a Klaytn Provider.

    Klaytn Provider means that with Kaikas, you can use the JavaScript global object window via window.klaytn. This allows you to create various interactions on the browser, just as in the BApps that have integrate Kaikas we saw earlier. More specifically, there are properties that allow you to check the current network or address of the user, and whether Kaikas is installed or not, as well as methods for granting access, registering tokens, and automatically refreshing pages. For more details on Klaytn Provider, please refer to this link.

    Let’s take a closer look at one of the properties mentioned above. The klaytn.networkVersion property checks which network the user is currently on. It returns the following information:

    ‘1001’: Baobab Test Network
    ‘8217’: Cypress Main Network

    Below you see an actual implementation. It is the pop-up window during login on KrafterSpace, indicating that you are on the Baobab Testnet.

    Caver

    Kaikas allows you to interact with the network in place of a Klaytn Node, which also makes Klaytn’s SDK Caver accessible. You can either download Caver yourself and wrap it with Klaytn Provider, or use Caver 1.4.0 provided by Kaikas in the form of (window.)caver.xxx. For more information on Caver, please refer to caver documentation. If you want to use Caver in the form of window.caver.xxx, refer to this link.

    Custom RPC

    RPC (Remote Procedure Call) is a protocol for network communication, and acts like an interface that enables interaction with the blockchain. In the course of developing an app, you may have to configure your own network on your local device for testing purposes. And these custom networks can also be added on Kaikas.

    Below is an example of adding a such network. More specifically, for a private local EN (Endpoint Node).

    |Network Name
    Enter a desired name.

    |New RPC URL
    Default value is http://localhost:8551, but you can change it.

    |Chain ID
    Since we are connecting a Klaytn EN to Kaikas, you should enter the network chain ID supported by that EN. If you are using Cypress the ID is 8217, and with Baobab, 1001. You can also set up a separate network, in which case you would enter the chain ID designated for that network.

    |Symbol
    You enter the token symbol for the network, like KLAY.

    |Block Explorer URL
    The Block Explorer for Cypress is scope.klaytn.com, and for Baobab baobab.scope.klaytn.com. If you set up a separate network, enter the URL of the Block Explorer for that network.

    If you want to see a tutorial of how Kaikas can actually be implemented, go check out this link: https://github.com/klaytn/kaikas-tutorial.

    Further details about using Kaikas for development can be found here: https://docs.kaikas.io/. If you come across any problems or have questions, feel free to ask for help in the Klaytn Developer Forum!