 Hello, everyone. I am Yuki from Hitachi. Today, I'd like to share my contribution to Hypertrap Fabric. I'm a researcher and I'm working to develop new blockchain applications. I'm now interested in token, so I made a reference implementation of ESC-20 and ESC-71 of Hypertrap Fabric. The code was originally merged in Hypertrap Fabric, so in the session, I want to share the motivation, design, and how to use it. Here's the agenda. The first topic is motivation. As Brian said, as a keynote speech session, token is a very hot topic. Token is expected to transform about the daily life of businesses. There are various tokens like cash, security, property, ticket, etc. A token represents ownership over digital or physical assets, so we can use tokens for many use cases. So token is created by tokenization. Tokenization means the process of transferring life of an existing asset into a digital token. When an owner shows the verification of ownership, the asset is converted into token on blockchain network. We use blockchain for various benefits. If we use blockchain for tokens, we can reduce the intermediaries, and the asset is stored on secure and immutable database, so we can track the history of assets. And we can also spread an asset into more virtual assets, so these features will create new ideas. So we use blockchain for tokens. So how we design tokens? When we design tokens, we design token application and infrastructure. Token application means that we design the specification of tokens, like data model or behavior. For designing tokens, we can use some token type or token standards and customize it. We also need to consider legal compliance or governance or interoperability to satisfy our use case. After designing the token application, we also design the infrastructure to satisfy our requirement. We design security, security and privacy of infrastructure, and we also need identity management system. So these are the stacks of token application and infrastructure. So token became popular in the industry market first. Now, D2B market is also expecting tokens because token will transform their complex business processes, or token will create new business opportunities. There are some use cases like supply chain finance, trade finance, or cover accounting. This graph shows the example of supply chain finance with token. Many stake holders can get benefit from tokens. And this graph shows the typical structure of manufacturers like automotive industries or electronics industries. A large corporate buys some parts from tier one supply A, and the large company provides account receivable to tier one supply A. So tier one supply can get cash in 30 minutes or 60 days. So if tier one supply doesn't have enough cash, they can to pay to tier two supply B. To solve issues, we can use tokens. A large corporate can issue token representing digital payment obligation granted by financial institutions, and the large company can use this token to buy some parts from tier one supply A. Then tier one supply A can use this token to pay to tier two supply B. And these suppliers can also apply financing to financial institutions by using this token. So this is the examples of digital tokens. However, there are some issues in digital tokens because developing token system is beyond developing smart contract. So governor's model is also important. First, clear responsibility is required. B2B transactions need to be approved by legal entities which really exist. And the transaction finality is also important to make the contract effective. And the participating companies need to follow compliance policy and they need to pass order to process. Secondly, confidentiality is important. B2B transactions have many confidential data. So a transaction should be kept among relevant stakeholders. At the same time, we also achieve credibility because the benefit of token is tracking the history of assets. So we need to consider the path between privacy and credibility. Lastly, tokens need to be easy to use. Many stakeholders join this token network. So everyone can understand the token specification correctly. To solve these issues, I implemented ERC-20 and ERC-721 token on hybrid fabric. For clear responsibility, hybrid fabric provides organization-based identity model and endorsement policy. So transactions are signed and agreed by legal entities. Fabric provides a consensus mechanism called Execute Order Violate Model. So transaction finality is guaranteed. For confidentiality, Fabric provides channel and private data collections so we can keep transaction secret. For easy to use, I used ERC-20 and ERC-721 which took on standards. And I will explain it in the later. And the fabric also supports JL token languages like JavaScript, Go, Java so engineers can develop smart contracts easily. So this is the basic idea of my solution. So let me explain the design in detail. So there are two famous token types, fungible token and non-fungible token. Fungible token is interchangeable and indistinguishable from each other. Examples include money, gold, oil, etc. Non-fungible token is unique and distinguishable from each other. We can track the ownership of each one separately. Examples include artifacts, houses, tickets, etc. Various tokens are derived from fungible token or non-fungible token. And some tokens are a combination of these two tokens. In Israel, there are standardized tokens registration for fungible tokens and non-fungible token. ERC-20 is the interface for fungible token and ERC-721 is the interface for non-fungible token. These standards define all these interfaces of smart contracts and the implementation is left for each developer. So it means implementation is left for each blockchain. So I decided to develop the first implementation of ERC-20 and ERC-721 on hybrid fabric because we can reuse these practices of tokens and we can also satisfy the strong governance requirement for B2B tokens. This graph shows the functions of fungible token smart contract. We can issue tokens, then the issue token can be transferred to other users. And we can also reuse the token at the end of the life cycle. And users can also get the balance of each owner and get the total balance. Now these functions are implementations of ERC-20 and also added some functions for operations in the real use cases. So this graph shows the functions of non-fungible token smart contract. Like fungible tokens we can issue token and then we can transfer the token to other owner and we can redeem it. And non-fungible token has an owner on it so it gets the owner of the token and we can also get the balance of each owner and total supply. So the token smart contract uses identity management. User accounts are linked to current entities issued by organizations. Each organization has a certificate authority to register and enroll users. In this graph O1 has a CA and CA issues identity for user one. And the user one has an account in fungible token. And the fungible token has a key value data. The key is the identity of the user and the value is the balance of user. So this is how a user is linked to an account. Token smart contract has access control policy based on MSPID or user identity. All the identities from permitted organizations can issue our real tokens. In this figure O1 is an issuing company. So I1 under this organization can issue a token because it passes the access control. On the other hand all user two at O2 cannot issue a token because it doesn't have valid MSPID. For transfer, only the owner or permission for the party can transfer tokens. Now with that too, he can transfer his or her token because he or she is an owner. So this is just a reference implementation. So you can customize access control policy to satisfy your use case. So when I contributed and called to Fabric committee, I had some discussions with Fabric maintenance. And we made some decisions to improve the quality of smart token smart contract. So looking at some tips for Fabric engineers. The first tips is to make the most of Janko's functionalities as far as we satisfy the original goal of ERC-721 specification. ERC-721 has animation extension. Animation extension is optional and it allows a contract to publish its full list of non-fungible tokens. So smart contract marries a list of tokens owned by all owners. So it has a counter containing all token. So when the number of tokens increases, the counter consumes huge memory. So to avoid the memory shortage, we remove the entity from the token smart contract. We can do it because Janko has an API code get state by partial components to key. So we can get these tokens by calling this function. So we can save the memory space. The other tips is avoiding LVCC conflict. LVCC starts for multi-version concurrency check. It is a common issue in Fabric. And this problem happens when implementing the token. And non-fungible token has a function, Brazil. Brazil returns the number of tokens owned by each owner. So the simple implementation is having a path record for each owner. And when transferring non-fungible token, we can add one or remove one to count the variance. However, when multiple transactions transfer different tokens owned by the one, the transaction tries to update the balance of one at the same time. So at least the LVCC conflicts and the transactions are not committed. So to avoid the issue, we removed the account records. So instead of having an independent case, we count the variance at the create time. So when the balance is called, tokens are searched and it returns as a number of tokens owned by each owner. So this is a reference implementation. So I think you are curious about the difference or relationship between Fabric's token and U.S. token. So my idea is to select a proper token for your use case. And for example, if you need consensus between legal entities or you need clear governance, we can use Fabric's token. Or you need a token accessible to anyone. Or you need a crypto token. You can use U.S. token. In other words, Habitat Fabric is suitable for use case which requires some governance. So the last part is getting started. So this implementation is available at Fabric's samples repository. Each sample contains readme. And the readme explains the test scenario and how to issue transfer token step by step. Interestation, I will work through the most important part. So if you are interested in using it, please check the readme at this link. So this graph shows the system architecture of the token sample. It consists of org1 and org2. And this organization has a PLCA chain code. And this network is launched by a script called TestNetwork. After launching the network, we issue or register entities. There are two users in this test scenario, Minter and CPNT. So org1, CA issues an identity for Minter and org2 CA issues an identity for recipient. And so now we can issue and transfer tokens. So in the test scenario, Minter at org1 issues some tokens to its account. Then the Minter transfers some tokens to recipient at org2. So this is a very basic scenario. So you can add more scenarios. Or this token is just a smart contract. So you can add more data model or behavior as you like. So please try it. Okay, so this is a summary of my presentation. And the motivation was to create tokens for B2B use cases because it requires a thorough governance model. So I used Fabulous Fabric to satisfy the strong governance requirement. I also used the interface of ERC-20 and ERC-721 to use the best practices of tokens. And I also tried to make most of Fabric's functionalities to make simple smart contract. And so implementation is available at FabExample possibly. So please check and try it. This is the end of my presentation. Thank you for everyone. So let's go to that. Just a Q&A session. So before everyone, it may be some technical issues. Sorry. Yuki, there are a couple of questions in the chat window. So maybe you can just use the chat window. Chat window? Okay. Thank you. Okay. Question in the chat. Yeah, so here to share my contribution with you. If you can check who is the card. Oh, yeah. Thank you. Lafayette? Is there a demo of a... Sorry. Is there a demo of... In FabExample, it will go... Oh, sorry. Is it in JavaScript? So, but the tangible token is written in JavaScript. So please check the report story. Next question from Kriji Brescia. My thread is uploaded as a forum. So you can download my slides from the website. And in the slide, I put the link to the repository. So please check the slide and link. So, yeah. So, any did have this tutorial. So it's not a tutorial, but they don't mean maybe some kind of tutorial. So we explained the test scenario and how to set up the FabExample. How to register Unity and how to issue tokens. So it may be such kind. It may... It's not a tutorial, but yeah, you can work through how to use it. So please check the readme. Okay. Okay. So what are the difficulties with creating FabToken compared with ERC 20 and ERC 721? Good question. So the most... The big difference is the programming language. And so as you know, original is a young token and is... And the FabExample contract isn't written in Go or JavaScript. So, yeah, familiar with Go or JavaScript. FabExample token may be a good starting point. And if you are familiar with 3D and you want to use as a cryptic token or instead of tokens, you can start from the Ethereum. Oh, sorry. Next question. Oh, sorry. And I mean, what did CalT do to you for using FabToken for production quality for network? Reaction program. Okay. Yeah, it's a good question. So for production use and I think there's issues. And the first issue is... First issue is the cruelty of smart contract. So as you know, there are some famous instance of the security or back in smart contract. So for production, we need to test the smart contract here free to check if there's no bugs. Or if you find some bugs as a production operation, you need to fix it immediately and to save our assets. So, okay. So now... Okay, it may be the last question. So, thank you, Marcus. To divert a supplier in a FabExample by-chain for good performance, we usually recommend that FabToken watch as a simply virtual ecosystem. If token is 320. Oh, so I'm sorry. I can't catch the context. So I'm sorry you're very long. But I think we can use this token or customized token for supply chain, you know, to represent the ownership of physical assets. So supply chain means transfer assets to stakeholders in the network. So yeah, I think we can apply these tokens to supply chain network. Okay. So, yeah, again, so thank you for everyone. I'll be happy to be here with you today. So I got many good feedback from you. So I appreciate it to you. So, yeah, as I mentioned, the site is available at the Hyperledger Grow Forum site. So please download the site and check the poster. And if you have any feedback, please let me know. Or you can just post it to the GitHub or FabExample. So thank you, everyone. Yeah, so I appreciate it. And please enjoy the other sessions. Thank you. Bye.