 So I'm going to be presenting you a new Deerun V1.5 features. So these, if not yet, it's mainnet for Deerun, but they are being tested and testnet. So maybe a quick reminder, Deerun stands for Distributed Randomness, and it is an open source software we've been developing, just like a lot of other open source software we're developing. And Deerun is used by the League of Entropy to run a free public randomness service so that anybody can query public verifiable randomness from the League of Entropy network running Deerun. And so just like you know, you have DNS servers, NTP servers, certificate transparency logs, and so on. You have Deerun that can provide random becomes. And the nice thing about Deerun is that it's fully decentralized. So you only need a threshold of nodes to be working as intended for it to work properly and for the whole randomness to be safe and predictable, as well as bias-resistant. And the very nice thing as well is that it's very stable. So you can take the Deerun becomes, and there is a very easy way of verifying them by just checking a BLS signature against a given public key for the League of Entropy. If that signature verifies, you can be sure that Deerun is valid and has been properly generated by the League of Entropy working together with a threshold of nodes collaborating to produce it. So that is a few nice properties. And as I said, it's open source written in Go. And it's using a lot of fancy cryptography behind the hood, such as variable stable secret sharing, distributed key generation. But a pretty important thing here is that it's based on BLS signatures, which stands for Benel in Chacham signatures. And more precisely, these BLS signatures are instantiated on the BLS-12381 elliptic curve, which is a pairing-friendly curve. And that is quite important for what comes next. Because BLS-12381 is an elliptic curve where you have two groups on the pairing operation from these two groups, G1 and G2, onto a target group GT. And an important thing about these groups is that group G1 is a regular group of size 381 bits. But G2 is a bit bigger. It's an extension field of dimension 2. And so it has two coordinates of size 381 bits. And GT is even much bigger. It's a 12th extension field of G1. So it's like 12 coordinates. But this is not too important because we're never storing GT values. We're always storing G1 or G2 values. And currently, Deer Run works by having its public key on G1. So it means the public key for the group is 48 bit bytes. And signatures for each beacon are on G2. So each signature is 96 bytes. But there is actually no good reason for it to be like that. And that just means we have pretty big signatures and small public keys. And usually people do that because they have a lot of transactions being signed by many public keys. And they want to include them in the block. And you can aggregate all signatures into a single signature pretty easily with BLS. But you cannot do so with the public keys because you want to know which address corresponds to which transaction. You need it to do verification, basically. So what people usually do is that they have short public keys and big signatures because at the end of the day, they will aggregate all the signatures into a single one. But that is not how Deer Run works. Each beacon has its own signature. And we never aggregate signatures in Deer Run. So for Deer Run, it would make more sense to have a big public key, just one. And then a lot of small signatures for each beacon. And this is exactly what we've done. So here is the anatomy of a Deer Run beacon as it was previously. So the signature Run G2 is encoded as a compressed point in hexadecimal. So it's taking 192 bytes, which is pretty big. And it even sometime was storing the previous signature, which is also a hundred and ninety-two bytes. And then we also have the randomness value, which could be derived from the signature. So in theory, we could just give the run number and the signature. And that should be enough for anybody to verify a Deer Run beacon and use the Deer Run beacon to produce the randomness they need. So that was how it looked previously. Now, with our new scheme, using G1 for signatures, everything is much more compact. Because now we have the signatures, which are only taking 48 bytes, which encoded in X is only 96 bytes. And that is much nicer for our HTTP realize because it's taking less bandwidth to transmit to the clients. And it's also much nicer to store. And this means we could save at least 37% of space on bandwidth just by switching to a new scheme using G1 for signatures and G2 for public keys. But we didn't just stop there. And so because using swapped groups also has other signification for many people that will be very interesting, it is that the fact of verifying a BLS signatures on G2 is quite expensive. As you can see here, the gas costs, as estimated, if it was running on Ethereum, the gas costs of verifying a signature on G2 would be roughly 226,000 gas. And now with the swapped groups, since G1 signatures are much smaller, they are faster to verify on Ethereum and on any blockchain that is supporting BLS actually. And so now it would only cost like 156,000 gas roughly. And these are estimates because Ethereum hasn't shipped native BLS support yet. So it's taking brain of soul there. Anyway, we also didn't stop there because we noticed, well, we want to launch a new network for DRUN to use these new signature schemes. But if we were to launch a new network, we thought we could do more things. One feedback we had from DRUN users was that 30 seconds is long. While filecoin block time is exactly 30 seconds, and it's fine for most filecoin users, people were running applications that need randomness that is verifiable in a more frequent manner or a bit constrained by the 30 seconds frequency of the DRUN network. Like if you are, I don't know, a casino, you might want to be able to run a new draw every three or five seconds. So we were planning on increasing the frequency of the new main network to five or three seconds. And that increased frequency would mean we would need to store maybe 10 times more beacons. So we looked at, oh, we were storing beacons and we realized it was not very efficient because we were storing them just like we were serving them under HTTP relays. That means we were storing them in XZSML encoding, which is twice the size of plain binary encoding. And we were also including the previous signature in each beacon. But that previous signature is actually already stored since it's just the previous beacon's signature. So you could just query the previous beacon and you would get that previous signature. So we are currently storing signatures twice. And that is not great because it's, yeah, storage, we don't need to waste. And everything was being stored in a bold DB file. And bold DB is a plain key value database written in Go and everything is stored in a single file. And one thing we noticed is that bold DB is not super charting and it's pretty slow when you have a big file. Like if you have a database that is waiting a few gigabytes, you are talking about hundreds or even hundreds of milliseconds or even seconds to perform one get or put operation. And that is pretty slow. And the bigger the database, the slower it gets. And we also have people asking us if they could store maybe the beacons in a MySQL or PostgreSQL database. And so we decided to rewamp our wall storage backends for Giren. So we optimized the existing bold DB backend. We are now using binary representation for the signatures. So that is as compact as it's possible. And we are also, we've tweaked our bold DB settings to use a few percent of a hundred percent because bold DB is using a B3 implementation. And basically, since Giren is only happening new data at the end, we never need to put them in the middle of the database. So we can just fill the database as compactly as we want. And that has allowed us to get a very nice, like a very nice performance increase. So currently storing or getting data from our bold DB backend is almost a hundred times faster, which is great. We're talking about the tens of milliseconds now instead of hundreds or even seconds. And also it allowed us to significantly shrink the existing database size by a factor of almost five, going under a gigabyte for all the past data Giren has been storing for the past two and a half year. And then we also, since we were working on storage, we thought we could just add a few new backends. And that's what we did. So we added a PostgreSQL backend which allows a node to connect to a PostgreSQL database and store the beacon there. So they don't need to care about backups and data integrity is the database administrator that need to care about that. And also we added an in-memory backend because at the end of the day, we want as many partners to participate in the League of Entropy. And we don't want the partners to leave the League of Entropy because it's taking too much disk or whatsoever. The most important thing being that we have a lot of people that are participating to the threshold network to increase the trust we can put in that threshold network. Because the idea behind Giren's threshold network is that you trust that there is never threshold amount of malicious nodes. Also you trust that the current members are not corrupt. And so the more members we have, if you can see a couple of people you know in there, it increases the trust people would put in the system. And so that is a win for us. And so the in-memory backend allows you to skip storing beacons to disk and you would just throw maybe the thousand or 2000 last beacons, which are anyway the ones people are most interested in using, you know, and the one that are getting queried from the relays most often. And that's it. That's what we are launching in Giren v1.5. The League of Entropy is actually going to be launching a new main network using the new cryptographic scheme as well as the new backend, the new storage backends in March on the 1st of March. This is very cool because it will enable us to do time lock encryption on Giren mainnet, which is a super excited feature we're very excited about here. And that we're hoping to bring to FVM and to, yeah, like to have more people using time lock encryption very soon. And finally, yeah, you can check the blog if you want to learn more about it. We will be publishing blog posts about the new cryptographic scheme, the storage backend, time lock, and so on in the upcoming weeks. And if you want a quick demo, I can show you the testnet implementation. So currently I told you we launched on testnet. So we have the HTTP relay here. You can see we have three chains. And if I go to the oldest chain, we can see it's a Pedersen BLS chain, the scheme. And so it's, if we look at the beacons, also I looked, we can look at the latest beacon. We can see we have a short, relatively short randomness encoded as X. Then we have a pretty big signature as well as a pretty big preview signature. If we look at the new network, it's using the BLS Unchained on G1 scheme instead. So it has a much bigger public key compared to the old network, if we compare them. But instead, if we go to the latest signature, the latest beacon we can see now we're not providing the previous signature because this is an unchained scheme. So we don't need the previous signature to verify the beacons. And the signature is also much smaller. That's it I guess for my demo. Thank you for watching. If you're in Tokyo next month for Real World Crypto, a quick shout out. We are organizing a randomness summit. So if you attend the Real World Crypto, don't hesitate to check out the randomness summit link. It's a free event. It will be in the same venue as Real World Crypto. And yeah, I'm looking forward to questions or seeing yous early.