 Good evening everyone. Our topic is enhance privacy ID in hyperledger efficient knowledge proof comparison and implementation focused on skills signature and test case stars. We are researching the information security rep of Professor Lee Myung-ri at Sungcheon University from South Korea. I'm Gyeongjin-la, a Ph.D. student. I will announce first part one, two, three part. Tim Kim is a Ph.D. student also. He is going to present second part four, five, six part. Okay. First, we are talking about introduction. On the internet, centers and this first communicate, communicate, secure through user and message authentication. Authentication server issues tokens to arbitrate users to access data. But traditional methods were centralized. It has a single point of parallel. Since then distributed and federated methods have issued. However, users don't want their identity information spread at internet. In addition, it is difficult for users to control or verify their information. So, decentralized ledgers such as blockchain provides public validate data and credibility via tamper resistance. So, let's think about it. For example, user at least wants to use the service. So, the service provider request at least two qualification. But we are curious. One is if this is just others authentication or at least need to over the age 18. So, this is situation at least should some sensitive information such as social security number or actual addresses where someone collects user information through public networks and blockchain ledgers. So, we need to consider two things. One is the set range of information delivered through cryptography method. At the same time, it prevents that participants profile from at least information. So, the other is the information provider issues at least credential for unconnect at least identity capability. So, in other words, the information is stored outside blockchain and is recorded only peer-to-peer secure connection values. On the left side, the XSTAT 509 system use the same and literally public key signature. So, user tracking is possible. On the right side, the identity mixer of the hyperrature in the project unconnects user identity key by issuing different transactions certificates for each person over the user relying party. However, it preserves autonomy through a single credential package. So, each DID is associated with a method and a DID method specifies the rules for how a DID is registered, verified, updated and revoked on that network. As you know, attribute-based credentials that is our form of authentication mechanism that allows to flexibly and authenticate different attributes about entity without revealing additional information about the entity. Serial knowledge proof allows to create logical operation in the form of true workforce proof. The user creates proofs by mixing secret and public values known only one. So, the validator verifies that it matches the received message without secreting through isomorphism. So, we take a look at ZK Snacks, also known as CL Signature and Zcash, which are popular in INDI and DID project. Actually, the symbol of general knowledge proof in the blockchain is not just security. The message of the blockchain must confirm three things. First, does the data exist in the blockchain? Second, is the owner of the data correct? That is, do you have a private key? Finally, is the data not duplicated? In this case, general knowledge proof provides a simple verification system by keeping the credential value secret. Therefore, it has scalability. So, blockchain and general knowledge proofs are a very good combination. Existing transaction records are converted to proof. The size is reduced and verification time is reduced too. So, our contribution is as follows. First, we propose a DID system with enhanced privacy. Like hyper-indic project is suppressed members' identification and the secure connection of the transaction certificate. Second, we implementation representative general knowledge proof, sales execution and ZK Snacks. Because the traditional INDI project considers only CL Signature, so our ZK Snacks application is a new challenge. Finally, we comparative analyze performed in various simulations, we're going to change this in the number of users and validator. So, DID communicates with the following three objects. You look at the left picture, users are the original owners of attribute information. We can call this object our holder. Issue is a credential issues that guarantees user information or credential to an institution or company. Brass validators are reliant parties, usually service provider. In this case, the issue provides the secure connection value that the actual information called the credential. User stores their credentials and submit them in multiple bundles. In this case, selective information exposure and general knowledge proof are used. Therefore, DID is unique identification address pointing to a credential. For example, Alice corresponding DID123 column ABC document contains actual information. You can see that Alice ID ABC name Alice, public ID 001, time and signature and so on. It is not uploaded to the blockchain and is stored in the form of general knowledge proof. The receiver bar verifies the credential and is submitted by a blockchain. So, if the prover has to repeatedly respond to Alice's challenge without revealing his general knowledge and Jetkin Snacks generates a challenging polynomial through preset streams so that bar validator can communicate and verify only one round. Except for the secret value of the prover, the rest are public values. Change the following polynomial to perform gate operation through an arithmetic circuit. First step is a parameter setup based on elliptic carbocryptography. This computation gives the prover and valid pile the same function. But this value is destroyed after setting. And then it transforms the polynomial into a function form. Then it is broken down into a single calculation that is black code and arithmetic circuit steps. And then it is to adjust the form of Charmille's secret calculation so that it is divided by 0. Finally, the validator efficient 3 validates whether it is divided by 0. In other words, otherwise, your signature binds and tribute to a single validation method through pairing the isomeric computations. The issuer issues the user credentials by these two signature multiple clamps with their private key. So, next step is Taeyong Kim. We'll make the next announcement. Thank you. Hello, my name is Taeyong Kim. I start the presentation. First, I will describe objects. The user is an information provider. At the same time, this is the subject of requesting the issuance of credentials. All participants are a term that refers to all objects participating in this project. Route CA is the time-level object, and this manages ICA. ICA is divided into registers and issuance, and each role is registered and issued. Failure is the service provider, and this belifies the user's credentials and provides provides services. The overall system flow is shown in the following figure. It is objects include user, registration server, issue server, and service provider. The flowchart steps consist of a total of three steps. The first step is registration and token issuance. User registers themselves and requests a token to issue an anonymous certificate. The second step is to issue an anonymous certificate. The user sends the token to the issuing server after that, the issuing server verifies the token, and then if it is a valid token, it issues an anonymous certificate to the user. The final step is the credential verification step. The user sends an anonymous certificate to the verifier, and then the verifier verifies the failures required for generalized proof. If who is a legitimated user, service provider provides services. This is page implementation class diagram. As shown in the figure below, there are Route CA, ICA, User TF, and PayFire. User runs this project using TF. Route CA registers ID and password of all participants. ICA issues participants' key pairs, tokens, and anonymous certificates. Chain code offers two methods, JKSnacks and CLSignature. The following is the configuration of the development system environment for this project. Route CA, ICA, and TF were implemented using Google Cloud. Hyperletter fabric samples used further 1.4. Hyperletter fabric samples were used because they are each to develop. And we developed it by modifying fears, odors, and channels. Other than that, the specifications are as follows. Next, this page is the description of the function. This project consists of 12 steps. It provides function from user registration to anonymous certificate verification function. Here is the implementation result. This project implemented the app in the form of a website. First, this is step of the logoing screen using the wallet. Second, when a user logs in, the anonymous certificate issued by the user is as follows. And the user who receives it stores it in their wallet. It includes various transactions, such as transaction ID, channel ID, token value, and flow page value. Next, verifier needs to trace the transaction to verify the anonymous certificate. Verifier used token values to track transactions. The following is an anonymous certificate using shell signature. The contents are as follows. The transaction ID, channel ID, and timestamp are the same. It consists of X, Y, and Z values that can be disclosed. Also, anonymous certificates using shell signature are tracked using the Q value. Next, I will explain the efficiency analysis. This project uses JKSNUX and shell signature for JKP. In addition, the verifier is fixed to one first, and the comparison is made when the number of users gradually increases. The following was compared when the number of verifiers and users gradually increases. When the number of users increases by one and the number of users increases by one. The average delay time of shell signature is short and loss put is high. Still, JKSNUX are more efficient when the number of users increases. When there are many users, shell signature is generally slightly faster than JKSNUX. However, as the numbers of verifiers and users increase, JKSNUX are faster than shell signature. When the numbers of users and verifiers increase by one, the generation time of JKSNUX and shell signature are shown. In addition, the maximum delay time, minimum average delay time, and loss put results are also shown in figures. As shown in figures, if the number of users increases, the average latency of JKSNUX and shell signature to scratch and loss put increases. Similarly, latency and loss put are the same as JKSNUX. With the first user accessing the blockchain network source, the application resulting in relatively high latency and low loss put. However, it can be seen that the number of verifiers increases, average delay time, and loss put decrease. Also, when the number of users is small, the average delay time of shell signature is short, and the loss put is high. However, and the number of users increases, it can be seen that JKSNUX are more efficient. Comparison and comparison and analysis of JKSNUX and shell signature confirm that the average delay time is increased and loss put increases as the number of users increases. Also, it was confirmed that average delay time increases and loss put decreases as the number of verifiers increases. By contrast, according to differential research analysis of JKSNUX and shell signature, when the number of user increases and the verifier is fixed to 1, the average delay time of shell signature is short, and loss put is high. Also, when the number of users increases by 1 and the number of users increases by 1, the average delay time of shell signature is short, and loss put is high. JKSNUX is more efficient when the number of users increases, when there are many users, shell signature is generally sliced faster than JKSNUX. However, as the numbers of verifiers and users increase JKSNUX is faster than shell signature. If more than 4 verifiers exist, some fears will be down. In other words, if more than 4 fears are operating the hyperlinked fabric network, it cannot be processed and will be down. In the future, a protocol with enhanced spec-spec security will be developed by applying it to a concrete environment. Continuous research to improve the speed of change Kp and blockchain performance is required. This is I have prepared for you today. Thank you for your time. Thank you. Thank you. Any questions? Thank you. If you have any questions, please contact us by email. We will write your, write what we are our email address in the chat box. If you have any questions, let me know any email.