Klaytn Usability Improvement Series #4: Supporting Role-Based Keys on the Platform-Level

See the list of articles here.
🇰🇷: Klaytn 사용성 개선 #4: 플랫폼에서의 role-based key 지원

Improving the usability of the blockchain platform has been one of Klaytn’s priorities. In this series of posts, we will walk you through the journey of improving the usability.

1. Separating Keys and Addresses
2. Introducing Multisig on the Platform-Level
3. Fee Delegation
4. Supporting Role-Based Keys on the Platform-Level
5. Implementing Explicit Types for Accounts and Transactions

In our last article, we took a look at a feature called Fee Delegation, which could enable blockchain services that offer the same level of user experience as existing services. In this post, we will be talking about role-based keys.

An account on Klaytn fulfills the following functions:

• KLAY transfer
• Smart contract deployment
• Smart contract execution
• Account information update
• Fee delegation

What if we could use different keys for different functions? If we allow separate keys for features added on Klaytn, there could emerge new, diverse use cases. It was to this end that Klaytn designed and implemented role-based keys. We assigned roles for each function and designed so that different keys could be used for different roles. For a more in-depth explanation on Role-Based Keys, please refer to KlaytnDocs.

A Key Just For Fee Delegation

A service developer can consider paying for the user’s transaction fees using the Fee Delegation feature on Klaytn. But doing so would require that the operator of the Fee Delegation be given rights to transfer balances from the account, but you can’t just leave your account with a lot of balances to the operator. So, the simplest solution would be to manage a separate Fee Delegation account and continuously have it filled in with the necessary amount.

But this approach has its downside; namely that you need to manage a separate account and check account balances on a regular basis for refill. Using Role-Based Key on Klaytn solves this problem by allowing the management of a Fee Delegation account with just one account. Here is a picture for clarification:

The administrator of the account first takes the key for RoleTransaction. This key gives him the right to transfer balances of the account. The key for RoleFeePayer is given to the operator of the Fee Delegation. Since this key can let you pay for a transaction fee on others’ behalf, it can allow the operator to receive the users’ transactions and pay for their transaction fees. But since the key doesn’t allow transfer of balances, you can’t send it to another person. With this solution, you are spared of the inconveniences of owning a separate account, nor have to regularly check balances.

Recovering User Account

A big obstacle in using blockchains is the private management of keys. But with Role-Based Keys, we can create scenarios where the users can recover their accounts. Let’s take a deeper look with the image below.

The service developers first take RoleAccountUpdate key while issuing the accounts of individuals. The users are given a key for RoleTransaction. Users can send tokens, execute smart contracts using the RoleTransaction key. And if the key gets lost, service developers can reissue the RoleTransaction using RoleAccountUpdate key.

With the new key, the user can seamlessly continue using the services, as if nothing happened.

If you provide the new keys to the user, he or she can continue using the services with the account.

In this article we looked at two cases using role-based keys. We hope role-based keys encourage the development of more services that make using blockchain easier. We expect more use cases in various service areas using this feature.

In our next article of the usability improvement series, we will take a look at the improvement implemented for Klaytn account and transaction types. Thank you for reading, and stay tuned!