 Okay. So, hi everybody. My name is David. I'm from Orbs, which is a company based in Israel. And I will talk today about DKG, Distributed Key Generation. So, a core cryptographic primitive that we use in Orbs is Threshold Signatures, in which, so in a threshold, the signature scheme you have N participants, and any large enough subset should be able to produce a valid signature, but a small subset of the participants should not be able to produce a valid signature. And this is quite similar to a multi-signature, but not just quite, right? Because we have a one signature. So, as you can probably understand, if you want to have such a scheme, you need the participants' keys to be related mathematically. So, the participants cannot just generate their keys locally and expect them to somehow work together. So, option A, the way to address this is to use a trusted dealer that would distribute the keys to the participants, but of course in a decentralized environment that would not be desired, right? You don't want a single entity to know everything. So, what you can do is you can use a distributed key generation protocol, which would indeed reduce the need of a trusted dealer, but it would introduce some challenges. So, first of all, a lot of communication, right? All the participants are going to have to communicate with all the participants. So, this is expensive, and then computationally it's going to be hard on participants. They're going to have to run many computations to validate that everything is correct. And then there's still this trust assumption where we're trusting that the majority of the participants are following the protocol correctly. And if this assumption breaks, then the protocol breaks. So, we're going to use Ethereum in order to justify or relax this assumption in red. That's the main purpose of using Ethereum. So, how is it going to work? Basically, it's going to be a smart contract, right? A DAP that does the DKG. And the participants are going to start by enrolling to the smart contract. They're going to send a deposit, and then they're formally a part of this DKG. And after this is over, the actual DKG can start. So, first communication, they're going to communicate by sending transactions to the smart contract, which would basically be data that they're trying to distribute between one another. That's the information available for everybody, or private information that is tested into a specific participant, and then they just encrypt their data. After the communication is over, the participants are going to execute local computations. And then if everything is fine, then basically the DKG is over. And everybody, every participant has their keys, and it's good to go. However, if there's a problem, then any participant that detects a problem with another participant's data, can basically complain. They can file a complaint to the smart contract, which would then re-execute the reported computation, and would find whoever is faulty, and would slash that participant. Okay? So, what we were able to do is we were able to find valid complaints for every way that a participant can divert from the instructions, from the original instructions of the protocol. And what this means is that if you're a participant and you care about the deposit that you put, you would have to follow the protocol instructions correctly, or else you're going to be complained against and slashed. So, this is exactly what we wanted, which is great. But let me just finish up by giving you a taste as to how we actually solve the technical problems, because the leakage is very computation and communication expensive, as I said before. So, first, our general approach is to do as much as we can off-chain. So, what does that mean? So, in terms of communication, except for a 32-byte commitment that the participants have to include in their enrollment transaction, basically all the communication can be done off-chain. Secondly, in terms of the interactive of the dispute mechanism, so if any participant files a complaint, this really expensive computation has to be done on-chain to verify who was correct and who was faulty. And this is very expensive, this cannot be done over with here. So, what we use is we use an interactive protocol between the participant who is complaining and the participant who's being complained against. Okay? And the spirit of true bit. So, this is really great because it lets us arrive to a situation where there's only one on-chain operation has to be done in order to find out who is faulty. But this is still too expensive to run over with here, because this is typically going to be an elliptic curve operation. Okay? So, the way to address this is to use one of the pre-compiled contracts that actually do elliptic curve operations, and this will allow us to not to pass the gas limit. So, what we were able to do is we were able to take the original DKG protocol and restrict it to only use the curves and the operations that are backed by these pre-compiled contracts. Even though these pre-compiled contracts were originally introduced to Ethereum just to use ZK Snarks, so we were able to use them for a completely different use case. And we're using them for this DKG and then for BLS threshold signatures to be done over Ethereum. So, this is pretty cool that we were able to do this. We proved that our variant of the DKG is safe and it works. And so, all of these things together were actually able to make the DKG run efficiently over Ethereum with a very large number of participants. So, there is a prototype implementation that you can find in our GitHub. It's a proof of concept. It's not production ready or anything. And there is a paper coming, which you can also check out. And I encourage you to come and ask me a question if you have. Thank you very much.