 Hello. Whoa, it works. OK, everyone, thank you for being here. Thanks for coming, especially on the face of a mega-telephone coming our way. I especially appreciate it. My name is Santiago Paladino. I'm a software developer at OpenZebulin. At OpenZebulin, we perform security audits for decentralized systems. And we also build open source, smart contact libraries, and developer tools. But I'm not here today to share our work here. I hope our workers have a great work space sharing that. We had to talk about a personal project that ended up over a year ago. I wrote a book to onboard Web 2.10 developers to the space and on how to develop decentralized applications. The book, fortunately, has been published this week. You can head over there with this discount code and get it. Thank you. Thank you. The thing is, while working on this, for a person, I think that one of the best ways to learn something is to try to teach it. I also managed to squeeze a lot in that thing, which is awesome. The best way to learn something is to actually try to research it, try to teach and share it with others. And one of the biggest insights I got from the book is that labs are actually much more tricky than they seem. There are many things that we take for granted that we assume that they are easy to develop. And when you start digging, you start to realize that it's not exactly that way. And to share that with you, I want to present a short challenge, basically some very, very simple application, for instance, showing the knowledge of tokens of a specific address, and see how it can become actually tricky pretty soon. We'll go a little bit technical just for a couple of minutes. Not many. It's a bit of a talk after all, so bear with me. But the idea will be just to get the current tokens of the user, money for new ones, and that's it. Don't seem to write. We'll assume we have two building blocks. This is an oversimplification of the standard, but an example, something that lets us know, OK, given address has these tokens and an event to listen for new ones. Step one, listing the current tokens. Should be fairly easy, right? The user has received token A, token B. We just ask for the current tokens. We get the list with both, right? But what we don't get is when we receive those tokens, when they were allocated to the particular address. For instance, token B could have received last block, which means it's not confirmed. It's subject to being removed. And it's not information to actually get. So if we want to get a picture, we need to query the state a couple blocks back, let's say half a dozen, one dozen blocks, depending on the number of confirmations. But now we have a gap on the past six blocks, which we're not sure how to feel, maybe getting the past events, holding constant to see if something has changed. But OK, let's leave that out for a second, try to focus on the second problem. How we subscribe, how we see for new tokens. This is probably easy. As you may have it, what's the connection to the node, not on nodes exposed one. We can just issue a subscribe method also from the current block onwards. We have a notification on holding a transfer, some of the new events for new tokens that the user receives. Well, hopefully from the current one, the subscription might get installed later, but that's yet another problem. So, OK, let's just focus on the subscription. The user receives two tokens, that's a token alpha, token beta. We get events for that, pretty easy. We only need to display them on user interface. Well, there is a review, or the subscription will also take care of this for us, and we'll let us know, you know, token beta was removed due to reorganization, token delta appeared instead. But this requires actually the subscription to be alive. Subscription is something that runs over what's up with it, and HD connection, remote connections break. They may actually break while the rear is taking place, which means that node loses the state of all the information it has been sending us, and we actually lose track that the reorganization happened, and we ended up with the first version on the chain client side. So, we may end up displaying false information to the user. Again, this is a pretty edge case, but if connections break, and if we lose connectivity there, we are screwed. We can go another approach. We can go back to basics, just polling, go with a simple algorithm that just requires checking block hashes continuously, seeing if they have changed at the given rate, changing the block hash means a reorg. We can react to that. It means we need to undo all the previous events, so we also need to keep them mapping from block to events. Again, don't want to go in depth, but it's a bit cumbersome. It's not definitely not as easy as installing a subscription. Actually, using this approach, we can also solve the six block window and a few other things, but since I only have five minutes, the point I wanted to complete and the thing I wanted to share with you is that these things are more difficult than we think. If we start digging and we start looking for edge cases, foreign stable connections, for organizations, for stuff that is outside a happy path, things get carried pretty quickly. We need to be in the lookup for this. We need to do more work to have better plans and libraries, better support for handling this. Big shout out to the ThermJS BlockStream library out there which handles exactly this case, and by the way, hardly anyone uses it. And especially, we need better testing tools. I mean, it's really difficult to code an application that's going to be resilient to these situations if we cannot test it. There is no way for us to test an organization. There are hardly any tools for testing spotty connections. We should develop, assuming that we will have a grant difference as part of SOC when we don't always do. So we need to make sure that our testing framework, the testing tools we use, accommodate for supporting all of these cases. So, I'm going back to the challenge I shared a couple of minutes before. I'm super interested in knowing how you would tackle it. I've created an internet forum. It would be great if you could join. Share your thoughts there. I mean, the polling approach I shared is only one option, and I'm super interesting to know on how you guys would solve it. So that's it. Thank you so much.