 Okay, hello guys. Well, first of all, thank you for being here today and also thanks to the organizers for taking care of such an amazing event. So today we're going to talk about upgradeability and EVM packages and it is to learn some things about these concepts and of course, to see how we can leverage these concepts using Sublin OS. But before we begin, I would like to talk a little bit about us. We are at Sublin and at Sublin we build key technology and infrastructure to build, develop and manage smart contract systems. My name is Fago Spagnolo. I'm a core developer and security researcher at Sublin and currently I'm leading the efforts of Sublin OS. Maybe some of you may know us because of OpenSublin. OpenSublin is a community-driven open source framework of reusable modules of smart contracts that you can install and start using directly in your own projects. You also do security audits. A few weeks ago we finished the the audit for the Solidity compiler. We received a grant from the Ethereum Foundation. It was really great. And as I said before, we're here today to talk a little bit about Sublin OS. Sublin OS is an open source platform to help you build, develop and manage smart contract systems. So let's begin with the first topic, upgradability. So of course, that upgradability is one of the main features of Ethereum. However, software qualities really much depends on a development that needs to be iterative and incremental. And this means that we need to have the chance to update or patch our code if we need to. And we're not just talking about bugs. We may need to optimize our solutions. We may need to provide new functionality because the community is requiring it or whatever. And the thing is that we've seen many other projects building their own implementations of upgradability. And Sublin OS is providing a standard and really flexible way to do this. So I would like to introduce an example of how we can easily have upgradable smart contracts in our projects using Sublin OS. So the first thing we'll need to do is to install Sublin OS, in this case, we're using NPM. And Sublin OS comes with a command line tool. And in this case, for example, we have a need command that we can use to start a new project, just passing the name of our project. And let's say that we start writing our first smart contract. In this case, a wallet. As you can see, it has an owner. It has an initialization function where you receive the owner in order to set the owner of the contract. It has a withdrawal function in order to withdraw some funds from the contract and so on. So let's see how we can deploy an upgradable instance of this smart contract using Sublin OS. So the command line tool has some commands that are pretty much similar to the ones we use in Git. So I think it will sound familiar to you. In this case, we're running the first command. The add command, it's the way we tell Sublin OS in order to add a new smart contract in our project. In this case, we're telling Sublin OS that we want to add the main wallet contract that we wrote before. And the second step is the push command. This is how we upload the backup of our contract to the network. In this case, for example, we're pushing the source code of the might wallet contract to the roughs the network. And finally, we have the create command. The create command will create an upgradable instance of the might wallet contract. And the others that we receive there is the new instance that we have just created. And maybe some of you may be wondering why do we need to run these three steps in order to create an upgradable instance. Well, the thing is that this is not a regular instance, obviously. This is an upgradable instance. And the thing is that we can run the create command as many times as we want. And we'll be always reusing the same logic that we uploaded just once. So it's great. And let's say that after we created the first instance, upgradable instance of my wallet contract, we found the back. As you can see, the need wallet function can be called by anyone. And this means that, for example, an attacker can call the need wallet function to withdraw some funds from it. Any resemblance with reality here is per coincidence. And let's say that we want to fix this back. So let's see how we can do this with SablonOS. I promise it's really simple. So the first thing we'll need to do is just to edit the source code of our contracts. For example, in this case, we're adding an only owner modifier in order to restrict the person that can call this function. And once again, as we did it before, we just need to run the add command to tell SablonOS to add the new fixed my wallet contract. We're pushing that fix to the network. And finally, we're running a new command here. The update command is the way to tell SablonOS to upgrade the real-world instance that we created before. And it will be as simple as that. As you can see, an attacker cannot call anymore. They need wallet function, and our back has been fixed. So it was pretty simple. We didn't have to modify our source code in order to make our contracts upgradeable. As you can see, we're using the same address. It was an upgrade per se. We didn't have to migrate data from the previous wallet contract to the new one. We're really upgrading it. So how is that possible? I think that many of you may know already this, but we're using Proxy in order to make it happen. And the way a proxy works is it's a particular contract that basically delegates every college receives to another contract that is called logic contract. And the thing is that the others of the logic contract can be changed. And this is how upgradeability works. As you can see, the storage layer is always kept in the proxy contract. And this is why we don't need to migrate or pay any like expensive migrations of data when we want to do an upgrade of a contract. We're not going to so much deep in the proxy stuff, but you can read more about it in our documentation if you want. So something things up, Sublin OS provides a standard way in order to have upgradeable smart contracts in your projects that will basically allow you to fix bugs or add functionality, for example. So let's move to the second topic, EVM packages. EVM packages, this is a new concept we introduced some weeks ago. EVM packages are upgradeable on-chain packages of smart contracts code. And this means code that is already on chain deployed by another developer team, that it's being maintained by another developer team, that then any application can link directly through your own projects in order to reuse it directly on-chain. And it comes, of course, with opt-in upgrades. And this means that if that developer team that is developing an EVM package comes with a new version of the EVM package, you can decide where to upgrade your code to use the new version that they're providing or not. So why do we need EVM packages? We do think that this is a way in order to encourage modular development. You can start focusing on what you do best and start reusing the work that your colleagues have done. So we just don't need to build everything if we want to build something. We can start reusing some code that is already deployed on-chain. And as I said before, EVM packages are upgradeable by definition. And this means that their developers can provide new versions of those EVM packages. And you can opt-in decide where you want those upgrades in your projects or not. It's like any other dependency management system. And of course we're saving a lot of gas costs because we're reusing some logic that is already deployed on-chain by those developer teams. And we don't have to redeploy that logic every time if we want to reuse it. Let's take a look at another example. Let's say that we have a deck contract in our project. And as you can see, it has an ERC721 dependency. It has an idealized function in order to receive the ERC721 dependency. And it has another function called pick that will basically allow any users to pick cards from the contract. And you will be minting new ERC721 tokens every time a user picks a new card. So how we can create an upgradeable instance of this contract? Reusing an EVM package for the ERC721 dependency using Sublant OS. So it will be reasonable once again. The first thing we should do is, and here is when it comes to the new part, the link command will allow you to link to any other EVM package that is already deployed on-chain. In this case we're linking our projects to the open Sublant ETH EVM package. And this package is the EVM package that the open Sublant team has provided on-chain. In this case we're linking to the 2.0 version. And as we did before we just need to push those changes to the network. And finally we can run the create command. And as you can see here we're creating an instance reusing the logic of the ERC721 that has been already deployed by the open Sublant team. We haven't added that contract in our projects. We're reusing the same logic that the open Sublant team has provided on chain for us. And it will receive of course the address of our upgraded instance of the ERC721 there. So let's now create, let's use this new ERC721 instance in order to create an instance of our contract, the DEC contract. As we did before in this case we do need to add the DEC contract. So we're running there the app command. Then we're pushing the the source code of the DEC contract to the network. And finally we're running the create command in order to create a new instance of the DEC contract. And passing here the address of the ERC721 instance that we created before. And we will receive there the address of our a great little instance of the DEC contract. So as you can see we can start reusing the DEC contract. And it will be, we can start picking out we will be minting ERC721 tokens. It will be as simple as that. So this is amazing. We didn't have to deploy an ERC721 contract in order to reuse it. We're just reusing the one that the Open Supplement Team has provided for us. And this is really cool. So I said before that EVM packages are upgradeable by definition. And let's see an example of what does it mean. Let's say that the Open Supplement Team comes with a new version of their EVM package. In this case the Open Supplement ETH as I said before. And let's say that we want to use it in our project. And as you can see this is an opt-in decision I said before. So in order to tell Supplement ETH that we want to use that upgrade, that new version in our project we need to tell Supplement ETH that we want to link our project to the new version. As you can see here we're linking our project to the 2.1 version of the Open Supplement ETH EVM package. Once again we're pushing those changes to the network. And finally we can run in this case the update command in order to update the upgradeable instance that we created before of the ERC721 contract. And as you can see we'll be picking new cards again with the same deck contract that we created before. The address of the deck contract hasn't changed. And we'll be using this new version of the ERC721. It will be as simple as that once again. And as you can see we didn't have to update our deck contract. We just need to update the dependency that we're using in our project. In this case the ERC721. So some of the things up. EVM packages allows us to reuse code that is already deployed on-chain. That we don't have to redeploy it every time we want to use it. And of course we can as we saw before we can obtain update our dependencies if the developers of those EVM packages that we're linking to provide new versions. So this is really good. And let's go a little bit further on the EVM packages thing. Maybe some of you may be wondering how we can actually make sure that the code that we're sharing and reusing on-chain directly is actually safe. How we can trust the code that it's already deployed on-chain. So before we answer that let's think how we should how we probably do this these days. We may for example hire an auditor in order to audit code that was deployed on-chain and the auditor may raise some findings on that code and we will tell the developer team to fix those backs or to improve the things that we found there. And it will be kind of expensive in order to hire an auditor to do that every time we want to use a new dependency. And that's why we decided to start working on the on the vouching system of Sablin OS. This is a way to decentralize those decisions and this is our first step towards the token mechanics that we've been announcing since we started this project. The first implementation of the vouching system we have it announced that it's already included in the second version of Sablin OS we launched this week. So let's see what do we have to say about this. So the vouching system basically allows users to debug the quality of an EVM package that is already deployed. As you can see this is something complementary to the EVM packages thing. It doesn't mean that you need to use the vouching system in order to create an EVM package but this is the way that this is the way that you can use in order to signal your the security of an EVM package that is already deployed. As you can see this is our first step towards a greater list of secured EVM packages. And let's see a quick sample of the things that we can do with the vouching system. For example we're using here a way to register a new EVM package on the vouching system of Sablin OS. It's pretty much very simple. You just need to pass the name of your EVM package and the others where it's deployed and it will be as simple as that. And of course that you can also start vouching some amounts for EVM packages that are already registered in the in the vouching system. And the amounts that we are vouching here are not just numbers and this is where the SEP token is born. The SEP token is the native token of the vouching system and it's basically what allows us to align the incentives in order to create a healthy ecosystem of secure smart contracts projects. And it was also launched with the second version of Sablin OS along with the vouching system. And one more thing where we're not alone there's a lot of amazing projects that already decided to start building their own EVM packages and many of them are already on chain. They're already on the main net so you can start reusing their code in your own projects through Sablin OS. And you can be one of them too. So that's why we decided to start a private beta period. This is a way to that we decided to gather a small group of people in order to validate all these ideas and all the partners that all the projects that I mentioned before are going to receive some set tokens in order to start testing the vouching system and you can be one of them too. Just a quick clarification here. This doesn't mean that Sablin OS is not available for everyone. Sablin OS as I said before is open source and you can use it right now if you want. It just means that the beta participants are the only ones that are going to be allowed to start testing the vouching system. Those are the ones that will receive some set tokens that the ones that can start vouching for some EVM packages that are already deployed, the ones that will be allowed to register EVM packages on our batching system and so on. And you can follow this link where you will find a registration form in order to sign up for the beta period. As I said before, it's open for everyone. So feel free to apply and we hope you do. And the registration is finishing by mid-November. So please come and join us. Thank you so much, guys, for hearing me today.