 My name is Zhang Yan, I'm building a blockchain platform in GroundX. In this presentation, I want to talk about how we extend Ethereum jargon and tension borders in blockchain. Have you ever heard about a blockchain before? Okay, I'm going to read it to you. Thank you. I want to talk about what blockchain needs. This is a blockchain platform built by GroundX. GroundX is the blockchain subsidiary of Kakao, which is Korea's largest mobile platform. KakaoTalk is another Kakao service, and this is the number one messenger service in South Korea. It has more than 96% of user penetration. So this is very good, services in Korea. And this is a project called Ethereum. This is an Ethereum-based project, and we launched it in June this year. As you can see on the left-hand side, this is an open source project, so you can check out the source code used via this Github.com. You can get some applications via this Github.com. We now have to support enterprise-grade services as a blockchain platform. In this presentation, I want to talk about high usability. So there are some user limitations. First and foremost one is immutable private key. When you create a key pair in Ethereum, the Ethereum address is determined. So if you create another key pair, it means you create another Ethereum account. So what if your private key explodes accidentally? Only you can do this to create another account, but it involves more additional problems. So you should tell your address to your friend to make sure that those are your friends to the same Ethereum to the old address. In any shot, you should transfer your old assets of the old addresses to the new address if you use any decentralized applications. If you expose your private key accidentally once again, you should follow this process again. So these are very inconvenient and unexpected user experiences. Let's compare to the end of time. You can think of an Ethereum address as a bank account number. Also, you can think of an Ethereum private key as a password of your bank account. What if you expose your password? Only you need to do this to change your password. You don't need to create a bank account. So this immutable private key involves much more usability limitation. The second thing is your multi-sync mechanism. If you use your account security, you can use a multi-sync mechanism, but on Ethereum, you cannot use multi-sync mechanism on the platform itself. You should create a multi-sync smart contract and you should know how to use it. So this is very inconvenient. So it should be better if you have multi-sync mechanism on the platform. The third one is Ethereum does not have type information for accounts and transactions. So it is very hard to extend new functionalities. The first one is there is no transaction type, so there are some necessary fields that should be included in the transaction. For example, think of a private transfer. If you transfer value, if you transfer some email to your friends, you don't need to set their field, but you should always because there is a single transaction program. And there is no field delegation mechanism. Field delegation means that you can pay transaction fee instead of a center. There is no such thing as implemented on Ethereum. So let's think about these scenarios. First one is what if you as a user should pay whenever you twist? This is very uncommon, right? But all the decentralized application requires you to pay some transaction fee. Second one is what if you as a software developer, a software developer, want to give users free trial period? This is very common service strategies, but it is not possible on the platform level on Ethereum. So if you provide a key delegation mechanism on the platform level, those scenarios will be solved very easily. So let's talk about what we design new features of Haiti. First, we provide a change of private key. To do this, you can change your private key if you expose your private key once, then you can use your account number continuously. And also we suffer a lot of private key on the platform level, so you don't need to know how to create and how to use a smart contract for the decentralized mechanism. And also we found that there are several rules in an account when you design this account model. So you can assign keys to each role and you can control the account more specifically. And in terms of traditional model, we provide multiple traditional types so that you can easily extend new features on the traditional type or so you can remove some unnecessary fees. And also we provide key delegation mechanism on the traditional model. But one thing I want to emphasize is that we preserve compatibility with Ethereum, which means Ethereum transactions can be executed on Clayton without any problem. So for those extensions, we use common techniques. First one is introduce type. So we design three data structures, account key and transaction. So for those data structures, we have type information. And we use double encoding function. So we encode the data at first, then the encoded data is encoded once again with type information. So when we decode this type of structure, we first decode type information and then we decode once again based on the type information. So let's talk about a little more about account model. In Ethereum, there's a single account type here. So there's no type information. And we have, you can see we have four fields here. But Ethereum has a, it distinguishes two account types. Smart country accounts and its own accounts or EOA. But as of September of this year, more than 8% of Ethereum accounts are EOA's. In EOA's, there's no information required for route and footage. So for EOA's, these are search overheads. So to remove this kind of search overhead, we design account model in the account type. So we have two account types here and you can see in the EOA, there's no route and code hash build. So we can just search code. In addition, we have a key field as you can see here and this account key field also has type information. So key field can be configured on of those four key types. Let's get types, it works for live on Ethereum account which has no key. This is provided for compatibility with Ethereum. And also you can set a public key in the key field. In this case, the traditions of this account can be signed by the private key that corresponds to this public key. So you can change any keys attached to the account. So we provide participant accounts on the platform itself so you can set multiple public keys into this key field. The last one I want to talk about is our longest keys. We have found three rules. First one is transaction and second one is account update and the last one is prepare. Keys for the transition rule are used for very transparent, transparent, smart object deploying and smart object execution. And keys for the account update rule is used to update account key. And the last one, prepare rule is used to transfer fee only. So if you have only keys for this fee payer rule then you can just pay transfer fee only. If you want to transfer value then you need to know you need to have keys for the transition rule. And let's talk about the transition rule. Similar to the account model, Ethereum does not have type information from the transition model. But it has three functions, very transparent, smart object deploying and smart object execution. In our transaction we introduced four more fields. First one is sender address. This is required due to the change of private key so we should explicitly specify the sender address. And on the platform that we provide, the sender signatures can add multiple signatures. And also fee payer address and fee payer signatures are related to the free relationship mechanism but they are not required for all transition types. This slide shows the Ethereum transition verification mechanism. As you can see, we can get signatures from the transaction and then we can get public key from the signature and we can get the address from the public key. But in Clayton we changed account model and transition model. And we can get some more tasks to verify the transition. So for the Ethereum transition, we can use the same mechanism but for other newly introduced transition types, we can follow the right hand side. So we can get signature from the transition and we can get public key from the signature. So we can get public key from this side and we can get account key from the sender address of the transition. So we get two public keys. And you can compare both keys. And if they are matched, then you can say that this is better transition. If they are not matched, then you can say that the transition is invalid. This slide shows two examples of our transition types. Left one shows better transfer and right one shows easily better transfer. Better transfer transaction does not have a fee delegation mechanism so it does not have to have fee payer address and fee payer signatures. So when we skip the better transfer transaction, the transition fee will be charged by a charge to the sender address and the amount of tokens will be transferred from sender address to the recipient. And when we skip the better transfer, the transition fee will be charged to the fee payer and the amount of tokens will be transferred from the sender address to the recipient. And this slide shows some of our collecting transition types and the second column shows basic transition types which has no fee delegation and the third column shows fee delegation transition types which provides fee delegation mechanism. And each of those shows different functionalities. First one is better transition. This is provided for compatibility. So all internal transactions will be mapped to this better transition. And those functions are also provided in Ethereum but we separate the transition types. And we also have the functions such as account update and so on. So if you are interested in the transition types, you can find more information in our documentation site. And let's talk about the performance. In this chart, on the XFTC shows the functionalities better transfer, smart content deploying, and smart content execution. And the Y-axis shows the relative execution time over legacy. As you can see, our new transition type performance is slightly slower than the legacy. It means Ethereum transaction less than about 10%. This is due to the doubling coding and transition verification. But we have more benefits. First one is usability enhancement which means we provide a change of credit key and purchasing mechanism and low risk key. So there are much more visibility in this one. And due to the type information, we can answer to all that on this cover. So if we have more types or functions required in the future, we can easily implement those kind of types without incurring severe hard work. And we also got a strategic reduction. As a time when we get the data, we, as of September of this year, we found that there are 75 billion users, billion accounts in Ethereum. So if we have high information into that, then we get one dive over it for all accounts. This takes 75 megabytes, but we can reduce 64 bytes for EOAs. As you can see, we use root and code cache. For those, it takes 64 bytes. If we assume that EOAs takes a very percent total annual account, then we can reduce 3.8 gigabytes of storage cost. You can see this is obvious. We can get much more storage reduction. So let's summarize my presentation. We found several iterative limitations, such as the immutable fire key and the logistic mechanism and so on. And we find solutions by extending account model and transaction model. Also due to the change of these kind of models, we should change the transaction verification mechanism to a slightly overhand compared to Ethereum. But we get trade-off. There's slightly negligible performance degradation, but we can get more benefits, improve visibility and insensitability, and we also reduce storage cost. So I hope that this extension and these new models can be applicable to other Ethereum popular blowchains or Ethereum standards. Okay, we always welcome to contribute our open source project, Clayton. As you can see, you can check out our source code in the GitHub side and you can also find some more information about Clayton in the documentation side. And you can see the right-hand side, there's a QR code. I don't know what it is, but the organizers should want it to be visited in the last slide. If you have any more questions, then please ask me this email address. What's your name? Another thing I'll talk about is that there are some Clayton stickers and bags just in front of the entry. If you're interested in it, you can take some. Okay, thank you for listening to my presentation.