 So, hello everyone. I'm here to introduce EDM 93 Quarters. Let's start. I'm Wansuk, and I'm working for Nuns, which is a crypto community in Seoul, where 70 people are living and working together. And recently, I like a college there. And recently, I organized a local community developer conference, which name is EDCOM. So, first, the 70 people in Nuns are all the crypto-related people. But, including me, we do not use MetaMask and Die to split the bill after we have dinner together. It is because it is really hard to find my friend using MetaMask and Die. So, actually, in Korea, we use Kakao Pay, which is equivalent to Venmo to split the bill, because those services are providing the features to find my friend using the Messenger feature. So, however, as the UX continuously enhances, it is easy to send my crypto to my friend using the ENS. So, how many are using ENS here? Yeah, so many people are using ENS. Then, how many Hashtags to use ENS? How many Hashtags to use ENS? Yes, yeah, not many, but people who use ENS frequently definitely feel that it is really privacy-less. So, if I know your ENS, then I can very easily know how much ETH you have and how much Die you have lent from MakerDAO, or even how much you have got liquidated from the MakerDAO by just typing your ENS into the ETH scan. So, ETH comes up as a lightweight 5-bit transaction solution. So, would you please figure out what does this ETH mean? It's kind of a Harry Potter. So, it's a gateway to the magical world where we can use the Mimble almost all. So, let's see how it works. The users can enter into the magical world by depositing ETH to any tokens, and then they go into the magical world. And using the Mimble input spell, they can make some confidential transactions each other, and the relayer can aggregate the Mimble input transactions and submit the transaction to the Ethereum using ZK-Rollup. And the important thing is that the relayer also aggregates the fees. And finally, the users can withdraw their money back to the Mimble world, submitting a valid proof. This is just a brief explanation of how it works. And now we're going to talk about the deep technical details about Ethereum in three quarters. So, the first priority of the design was how much ZK-Rollup is friendly. And the second one was how much ZK-Rollup is friendly. And the third one was how much ZK-Rollup is friendly. So, I started to use the Mimble first because Mimble-Mimble is one of the lightest forms of building confidential transactions. So, its transaction consists of a randomness and a value. And it expresses the TSO as a point on the audit curve using a business commitment. So, it can't hide those secrets while it allows the homomorphic cultural issues. So, it is hidden like this electric point on the curve. Therefore, using this homomorphic hiding features, we can verify that the sum of the input values and the sum of the output values equals. So, you can see that the coefficient of the base point h equals 0, becomes 0. Consequently, so we can also construct a transaction using this equation, but it's not enough to make a robust transaction. Therefore, first, because the zero sum verification works on a cyclic group to prevent the overflow and the underflow inside the homomorphic calculation, we need to restrict the range of the value inside the TSO. Secondly, we also add some metadata. In our case, we concatenate the ES training address of the token we want to send and the expiration height. So, the expiration height means that the contract will not accept if the block number exists the expiration height. And finally, to make sure this transaction is confirmed by the board party, we as a snore signature by the center of the recipient. But the problem is that actually it's not prevent the tracking of the transaction flow. So, actually green, which is the most popular member implementation secures the privacy by having no account and cut through it. But on interview, we cannot prevent the track of the transition graph. So, therefore, 93 quarters uses Zcash's commitment nullifier scheme to hide the input TSOs. So, with the commitment nullifier scheme, Zcash snores allow us to generate an inclusion proof without revealing the commitment and also prevent the double spending by using the nullifier, which is deterministically derived from the commitment. Finally, so, we append two more Zcash snore proof. The first one is inclusion proofs of the span text, which are inclusion proofs of the nullifiers. And the second is that the mimble mimble proof. Because it is because we hide the input TSO values, so it's not anymore able to verify the mimble mimble using the homomorphic calculation. So, we need to make some Zcash snores proof that just guarantees that all the hidden values are following the mimble mimble protocol correctly. The next part. So, this part is Zcash's role of friendly data structure. So, Peter Todd proposed Merkel mountain range for an efficient pan-on-mimble Merkel tree data structure, and Green is now using that. In interim 93 quarters, it uses a slightly tweaked version of Merkel mountain range that uses identity curve cryptography to compute the old nodes. So, most of all, in Peterson-Merkel mountain range, every node is the point on the baby choo choo curve. So, we calculate the leaf node by the scalar multiplication of the leaf position and the leaf item. And we calculate the branch node. The branch node value becomes the left node y value and the right node. The multiplication of the left node y value and the right node. Finally, the root value becomes the scalar multiplication of the width of the Merkel mountain range and the point of all peaks. We call this peak bay in Merkel mountain range. So, with this construction, a 16-bit Peterson-Merkel tree, which has 65,000 leaves, achieved 10 million constraints while rolling up 64 items at once. Additionally, because from Istanbul, the gas cost for electrical calculation reduces a lot. So, it will be able to verify around 256, running up 256 items at once. So, finally, we can jump up to the total performance of the wall-up with the optimistic wall-up. Just like plasma, we can use a challenge system to skip the ZK-SNAR computation. So, therefore, we can reduce a lot of gas costs to verify the ZK-SNAR computation in the on-chain computation. Therefore, in Peter'sburg version, rolling up costs around 3 million gas per transaction. But optimistic wall-up only costs about 147,000 gas per transaction. And in Istanbul, it only costs around about 50,000 gas per transaction. We need to...actually, it's much expensive than the general wall-up. It's because it contains a lot of ZK-SNAR's proof to make the transaction as some confidential transaction. But it is still very reasonable because the original, the Bayer ES-20 token transaction costs around 50,000 gas to 100,000 gas. So, as a result, what we can expect through Ethereum 93 cores is a DAO and some defined product using that. So, first, anyone can be a relayer and they can decide their own transaction fee policy. But to submit the optimistic wall-up, the relay should depart some stakes to secure the products, to... to the stakes for the challenge system. Since being...therefore, being a relayer can be considered as a kind of a financial product. Which gives some revenue for the transaction...aggregated transaction fee against...regarding to the deposit stakes. Therefore, we can also make a kind of a DAO system, like delegating some stakes to receive some dividends of the transaction fee revenue. So, the future work is...first one is optimization and the second is relayer client and mobile client. And because if we...we can also get some instant finality if we roll up without the optimistic wall-up. I mean, it means that if we compute all the ZK-SNAR computation, then we can get that instant finality. But if we use optimistic wall-up, we need to give some challenge period, so we lose the instant finality. Therefore, if we can construct a network of the relayers, then we can...not a instant... not exactly an instant finality, but we can provide some security of instant finality with the stakes of the relayers' network. And what we have to do is...definitely destroying the heart process. Destroying the toxic base. So, here's the summary. In the remaining three cores, it uses Memo-Wimbo-Puricle and Kamimbo-Noli-File-Skim together. And it uses Peter's Worker-Mountain range for an efficient ZK-roll. Therefore, it can...is able to pan up to 256 items at once. And the optimistic wall-up provides deterministic front-proof without any DA-DA problem. And also, it reduces the cost cost down to 50,000, yes, per transaction. So, this is the implementation. So, if you like that, please give me some Github stars. Or...thank you. Or, if you like that, I'm looking for teammates or teams who can support this project. So, if you're interested in this project, please let me know. So...thank you. So, you can have temperature if you want. We have four minutes, so you can go up. In terminal version? Yeah, show the demo. Only in terminal version. Here, there are generated proofs...generated proofs. And some sample transactions. Puzzling some year's training. And roll-up some transactions. So, the first round is roll-up two people with both transactions, which spend one coin base. So, we can make some coin base by puzzling some year's trainees. And the second round is spending two hidden transaction outputs, which is right throughout by the first round. So, it means we can use two input TXOs at one transaction. So, if you have some removal of the transaction outputs, then you can aggregate them to use for a one member of the transaction. So, as I know many, some protocol uses two inputs and two outputs. So, there was only 64 items at once. So, this is the result. Maybe roll-ups, 32 removal of the transaction at once. In Petersburg version. How long did it take to build? How long did it take you to build it? I started to design from the June, and finished the specification around July, and started to build from August. Full time? Almost full time. Thank you so much.