 Thanks for sticking around. My name is Jean-Yanise. I'm one of the co-founders at Arjen. And today, actually, I will not be speaking about Arjen, I will be speaking about Upper, which is an open source privacy mincer that we've developed internally. Actually, most of this work was done by only the event of being allowed from our team. This is going to be annoying. I'm going to plug my batteries in. So that should be better. So I was saying I will not be speaking about Arjen, but about Upper, which is what was mostly done by Olivier van den Wigner from our team. So the credit should go to him. And if you have a pretty deep technical question, I will also ask them to him on Twitter. So I just said I will not be speaking about Arjen, but I think there is some value in briefly describing what Arjen is, because it gives some context on why we started working on the privacy mixer. So Arjen is a smart contract based wallet with a lot of cool features. We have seedless recovery. You can block further than transaction. You can freeze your account. There's no abstraction of gas or transaction fees, every user has an ES and so on. So basically what we try to do is abstract most of the complexity of the blockchain and enable an experience similar to what you get on the best mobile banking application today, but in a fully non-custodial way. And the vision for that is that we want to enable actually people which are outside of Crypto Bobo to access the blockchain. And so if you start to build a new financial system for people that actually are not really tech savvy, they have some kind of expectation of what that system or the features that that system should provide. For example, people assume that if you transact, that doesn't give the person you transacted with access to your entire history. For example, I mean in the future I'm just making a transaction to my insurer. I may not be okay for my insurer to know that I just visited an oncologist two weeks ago. This kind of information should not be disclosed and should be private. And of course an Ethereum, which is a public ledger with full transparency, you don't need these properties. There's also an economical argument for privacy, is the fact that you want your token to be fungible. If I send you one Eater, you want that Eater to be worth one Eater. Now if you know where that Eater comes from, actually you may believe that it has this value because it can be tainted. For example, it comes from an exchange being hacked. That token may be worth less than actually one Eater. So these properties are very important. So if you want to be inspirational, you can say that privacy is necessary for an open society in the electronic age. If you're a bit more pragmatic, we actually allowed users saying that they were feeling uncomfortable by linking a hardware wallet on which they had a lot of funds with their urgent buy. And actually this second quote is really the use case we try to solve. So we really asked our question, can we actually address this very simple use case? A user wants to fund his urgent wallet, which has no fund, and send it from hardware wallet. And can we do that? Search that. The two addresses are not linked. The process is fully non-custodial. It is mobile friendly, and actually this point has driven a lot of choices that we've made to design Hopper. And of course it has to be economically viable in terms of gas. If you transfer one Eater, but you pay 0.5 Eater in gas to make that transaction happen, this is not practical. Fortunately, there are solutions to address that use case. And as you probably all know, ZK Snarex can be quite useful for that. We didn't start from scratch, so we should also give some credit to the team of Barry Whiteland and WJ. That was on the panel with me earlier. They've done a great work on Snark Miximus and now SEMA4. And so basically we try to extend what they had done, build on top of what they had done, but really customize it and make it practical for our target use case. So all those Hopper or Miximus works, it's that basically if I want to send a coin to someone, I will need a secret coin, which is a leaf in number 3. And the person that wants to withdraw that coin needs to prove that it knows the secret behind one of the coins and that this coin hasn't been spent yet. So the principle is quite simple. In practice, all those Hopper work, because we do have an iOS application that you guys should try, which is in alpha now, but I think it's a good way to see what it does. So basically the client using the Hopper application will generate a leaf. So we just do a SHA-256 of a secret and the destination address. Using your hardware wallet, you make a deposit to the mixer contract and you attach as data your leaf. Of course, other people will do the same and each transfer is of identical value. As you will see, this is critical. And that results basically in a sea of identical transfer. Of course, the more you wait, the more people will deposit either on the mixer contract and the more your anonymity set increases. I put an asterisk because it is not as simple as that, but it provides the intuition of how we get anonymity. Finally, after a certain time, the person who wants to withdraw the coin, again using the Hopper app, can tell the mixer to send the phone to the destination and you do that by sending a proof. The mixer contract will verify the proof and if the proof is correct, it will send the phone to the destination address. For example, that might need that secret to be transferred and hurried and you receive your 1 liter on your object wallet. The flow and the user experience is actually quite simple. We are always in work-in-practice, so I will not go deep into the ZKSNR framework for mixers, but basically you want to prove that you know a secret behind a leaf in America 3, where the leaf is the SHA-256 of the secret in the destination address, and you want to prove that that coin hasn't been spent yet. So actually you can translate that into mathematical equations and that will give you a circuit. In your case, these are the set of equations that we want to solve. This is the secret inputs that we want to prove we know without revealing them. And of course, there is some public inputs. So using this, you can actually build your circuit and have your verifier, your prover, using libraries such as this one. In terms of smart contracts, this smart contract is quite simple. As far as in terms of the API, we have two main methods, a commit, where you deposit your funds and you attach your leaf as data, and then a withdrawal function where you specify the public input that I just showed, the destination, a nullifier, which proves that there is no double spend, and then the proof that you have constructed using the ZKSNR framework. So that's kind of the general framework. As I mentioned, we are similar to other mixers, but we have different choices that you make for your implementation. So in the case of Uber, we use MIMC for the ashing function of the miracle tree. MIMC stands for minimal multiplicative complexity. The intuition for that is that in the ZKSNR framework, you have your equation, you translate that into a circuit with addition and multiplication gates, and actually the number of constraints that you will have depends on the multiplication gate that you have. So if you use ashing function multiplicative complexities, that means less constraint. That means generating the proof will be easier off-chain and that means that it is more mobile friendly. So we've made that choice so that you could actually generate the proof on the mobile within five or six seconds. Of course, there's a few drawbacks of using MIMCs. As always in engineering, it's a question of compromises. If you use MIMCs, they are more expensive for the EVM because there's no pre-compile and MIMCs, as you will see, there is an idea for that. But as of for now, doing MIMCs on-chain is quite expensive. So actually when you deposit a leaf, you need to update your miracle tree and that requires a lot of gas. And also MIMCs have been less studied. And if you are at IAAS presentation this morning, they highlighted that the Ethereum Foundation is studying research on MIMCs for specifically that reason. So to mitigate the risk associated with MIMCs, we are actually using SHA-256 for the leaf of the tree. We're not going to the cryptography behind it, but the intuition is that even if MIMC turns out to be non-pre-image resistant, you will still have privacy assuming that MIMC of one half of the input is pre-image resistant. The problem is that using SHA-256 means more secret constraints, and so again we increase the generation of the proof. So as I illustrated in our use case we want people being able to transfer one leaf from hardware wallet to a large end wallet that has not been funded yet. So the question is how does the person rejoin the money will pay? There's no leaf, it cannot pay for the gas. And so the idea is to use relayers. And so in our case, we have developed our own relayer. There's work being done by the semaphore team on the gas network station to actually use a network of relayers. And the idea is that the relayer will basically make that withdrawal transaction on your behalf, and it will be repaid the gas that it used by taking a small cut on the deposit. As we discussed on the panel, there is some there's some risk of using relayers because of course you're using a centralized you may not be centralized but using a system with an API, so you're making an API code that means that people can use your IP address to kind of reduce your anonymity. So there's a lot of consideration to take into that and one possible solution is to have a relayer market with built-in torque routing in. Another important question with Mixer is when to withdraw your funds. Because of course if you deposit your funds then you withdraw them immediately then it completely breaks the anonymity. If you deposit your funds but you always withdraw them after 24 hours, it's the same. People naturally tend to have patterns and so this is something that needs to be mitigated by actually the UX of building a Mixer or do you incentivize users to actually behave correctly or in a smart way. The problem is that, yeah, whatever anonymity you use, for example in Hopper we just illustrate the number of other leaves that have been deposited since we deposited so that can be represented anonymity set but again this is not a perfect metric because say my anonymity set is 17 maybe 16 other deposits they come from the same person which is actually trying to target me. So it's really tricky to find proper privacy metrics and so in the next version of Hopper the idea is to basically only enable you to withdraw your funds after a certain time so that all users depositing within one day will be incentivized to withdraw more or less at the same time and so again you kind of increase the anonymity. So I mentioned that we only enable transfer of one leaf again this makes sense if we let people deposit 0.77 Eater for example and then someone withdraws 0.77 there's a good probability that these two people are actually connected and again you've recreated that link that we're trying to break so the idea is to fix the amount that people can deposit so they become indistinguishable. Now the one improvement that we can do because of course if there's only deposit of one leaf it's quite limited so the idea is that we could make a contract for one leaf, a contract for ten leaf and a contract for a hundred leaf but the problem is that you split your anonymity set and again this is not a good idea. There are a solution and this is something that we work on in the future or that you want people to work on is the possibility to use jump speed circuit so basically the idea is that you always deposit a multiple of one leaf and then when you want to withdraw you can actually combine two leaves into one and so you can for example withdraw one then or one hundred without breaking the anonymity. Another limitation of Hopper is that there's only around 32,000 leaf per contract and the reason is that you have numerical three and the more depth you add to your numerical three the more expensive it is in terms of gas and since you wanted to keep this under a million for the deposit and the withdraws it's kind of limiting the number level that you can add in your numerical three and so the number at the level of leaf that you can deposit so we have fixed that at 15 which gives the gas around a million. The problem is that once you fill up your three you need to deploy a new contract. So I've talked about some of the limitations of Hopper fortunately there's a lot of areas for improvement one is around optimization so you could patch the public input into one which would reduce the number of more strain. You can optimize the contract for the moment the contract is in clean solidity there's some step that could be written in assembly that would reduce the consumption by 15 to 20% and again that enables you to increase the depth of your three and so the possible deposit that can be on a single contract and there is work on the new EIP 1108 Radia SD which is a pre-compiled from MC so that would greatly reduce the gas of computing MCs that means updating the Merkle 3 would be much cheaper so again we can use a much bigger Merkle 3 Another functional improvement that is part of the next iteration for Hopper is to store a buffer of the recent Merkle rules because now when you want to create your proof you need to have a Merkle path to the EIP that you want the problem is that by the time you compute your proof that may take 5 to 6 seconds and then you submit your transaction to the blockchain again it may take 15 30 or 1 minute to be mined it is possible that someone deposits a new leaf in between which will update your three and then suddenly a Merkle path is no longer valid so by keeping a mystery of 3, 4, 5 Merkle routes actually you can improve the number of withdrawals that will succeed as I mentioned we can allow custom withdrawals using John's clip and then we can work on a linear market so that's it that was kind of brief but I hope you guys enjoy if you are interested by Hopper you can check us on Github the project is fully open source and the idea for us is to build a tool for the community so this is not to be an urgent project so feel free to contribute if you have questions you can ping us on Twitter or Telegram and if you are interested by Arjun you can download a wallet right now using the link that is there and that's it for me thank you do you have any questions? how much gas does it cost? so we limited it to a million so a million to deposit and around a million to improve can you elaborate more on what is this? yes, expertly the idea is we need to make a proof that we combine two Merkle leaves so say I have a Merkle leaf which has one eater another one that has one eater I do a Jones leaf and suddenly I have one leaf which contains two eater and one that contains none so if I withdraw the one with two eater suddenly I can actually withdraw different amounts yes, this way but again you can combine the Jones leaf with the withdrawal with the specificity we kind of see like that but we need the ideas to enable custom amounts because we still need to know the secret behind discount so it's not like you can transfer with someone else unless you transfer them the secret but the idea is more to be able to join the amounts thank you