 We're at Open Zebulin. Probably you have heard about Open Zebulin because of the security audits we performed. Last year we audited the Solidity compiler. We also audited a lot of projects for Coinbase. We audited back in the days the Serpent language and we broke it by the way. And most recently we audited the well-known Compound and Instagram. You probably also know us because of the Open Zebulin contract repository. One of the most used libraries in this ecosystem that has more than 22k of downloads per week. And probably everyone that has developed an ERC-20 or ERC-721 probably used this library. So, the agenda for today. We're going to go through how we can develop smart contracts using the Open Zebulin SDK. Afterwards we're going to see how we can build dApps super super easy using the Open Zebulin Starter kits. And afterwards we're going to talk about some DX UX admin problems we faced while developing dApps for users. And we're going to talk about the Open Zebulin GSM tools. So the first part of this talk is going to be about DX and the second one about UX. Developer experience, user experience. So let's start with DX. It's super important for us to know what problem we have here. I think that if you as software developers or developers have worked in other ecosystems probably you know that our tools are still super super great compared to those other ecosystems. And us in Open Zebulin basically love to build stuff for you to make your life easier. And that's why we built two super useful tools that are the Open Zebulin SDK and the Open Zebulin Starter kits. Let's begin with the Open Zebulin SDK. The Open Zebulin SDK is a software development tool, basically a CLI that will let you develop your smart contracts, compile them with any version of Solidity you want, deploy them with this only with one command, upgrade them, and we can talk later about that, interact with them in a super easy way, and also start your dApps like in five minutes. How you can use it? Well, it's an MPM package, Open Zebulin CLI, so just run in MPM install at Open Zebulin slash CLI, we'll do the trick. You will probably first want to initialize your project, you can do that using the Open Zebulin init command, it basically will run a lot of stuff that will create your contract folder, it will set up your network configuration file, and a couple of other things for you to track your different contracts within your project. So, basically, we want to develop smart contracts, we have a MyContract contract, which has to do something function that receives something from it or some super super easy to understand. We only have to run Open Zebulin create, specifying the contract name on the network name, so you will have your contract deployed to the main network in this case. But if you forgot about the contract name or the network name, it's fine. All the Open Zebulin contracts are interactive, all the Open Zebulin commands are interactive, and you will be able to just run Open Zebulin create, and the CLI will guide you in the process of deploying your contract. So, for example, here we have a contract, MyContract in mainnet, at the address 1af, the one that starts with 1af. And we probably want to talk with our contracts, right, because we have already deployed them, and we want to, for example, call functions, see the value of our variables, or maybe just do transactions. The Open Zebulin SDK has two super handy commands, which are call and send transaction, called for calling pure and view functions and send transaction to any other public function of our contract that will actually make a transaction. The usage is super, super easy. Interactive commands, if you just run Open Zebulin call or send transaction, it will ask you to pick a network of your network configuration file. It then will list all the instances you can create. Afterwards, it will, I mean, not create, but to call. Afterwards, it will list all the functions that that contract has. For example, here they do something I already showed, and call me maybe function. And just by selecting the something, it will ask you for each parameter the function has. And that's it. That's it. You will see the transaction cache, which you will be probably able to copy and paste in EtherScan and see how it did. Well, we know that software development, contract development is done by developers and developers are persons, people making mistakes every time. We know this. We know what's happening right now in the smart contracts ecosystem. We can just push our broken code and a lot of dollars, billions of dollars can be lost. And it's important to have, like, tools for getting rid of these problems. So probably upgrading our contract is a solution. If we have a MyContractSolution, MyContract, with our doSomething function, which might be broken. We can modify it with this, just modifying the code. We can also add new functionality. And just run the open-setting-upgrade command, which will reupload the new code in the exactly same address. I'm not going to go super-super-deep in this topic. You can afterwards, after the talk, ask me questions, but if you want to just see how it works, you can go to setplane-slash-upgrades. There's documentation for you. Anything else? Well, yeah. We have seen all the left commands. The list that is on the left, you can create a grade call and send transaction. But we also developed a lot of super handy commands. For example, open-setting-complied for compiler contracts with any solider version you want. Open-setting-verified for verifying them in ether scan or ether chain. Open-setting-accounts for listing all your accounts within a network. Open-setting-transfer for transferring not only ether, but also ERC-20 tokens. Open-setting-balance for querying a balance of an account again in ether and in ERC-20 tokens. And open-setting-impact that is bolder. I don't know why it is bolder than you. Okay, okay. So probably Pala, who made this presentation for me because I'm super lazy for making my own presentations, wanted to say me something, right? So basically the open-setting-impact is the command that will let us link the open-setting SDK with the open-setting-storekits. Open-setting-storekits are basically dapps-caffoldings that will let us start our dapps super super easy. They include the well-known open-setting contracts, the open-setting SDK we have been talking about in Fiora for connecting to any blockchain, Ethereum blockchain, a one-liner that will allow us to configure super super easy for three, React and RIML for our front-end components, and also the open-setting-potloader, which is basically a tool we developed for you to modify your contract and see the changes of that contract in your web app just save in the file. So you add a new function, for example, and you are reading the API of that contract, you will be able to buy it, save in the file, see that new functionality within your website. So super easy again to use. With the SDK, we just have to run open-setting-unpack-starter, which is basically an empty version of the starter kit, so you can start your project from scratch, or open-setting-unpack-tutorial, which has a super fancy tutorial we're going to see later, or open-setting-unpack-gsn, and I put here a spoiler alert because we're going to go deeper into gsn in a couple of minutes. But just running mpm-run-start with the trick, you will be able to see the demo. There are two examples for you to learn how to use the open-setting SDK that are on Contra and even in packages. Super easy to understand. If you want to go and see what is this, please go to zeppelin-slash-starter-kits or zeppelin-slash-sdk to see what our total SDK is. And I think that we may have solved the dx problems here. I mean, we have a lot of dx problems, but maybe, you know, now you can start your project, deploy them with only one command, interact with it with other command, upgrade it with other command, verify them with other command. But this doesn't solve... I mean, this is solving our problem as developers. But what about the problem that users, like real people have? People that, every day, sits in their desktops or their laptops, for example, my father, which, by the way, loves to buy stuff on the Internet. I'm from Buenos Aires, Argentina. We don't have Amazon there, but we have a very similar website that is called Mancada Ude. That basically is exactly the same. Whatever you want for, I don't know, food or stuff. And just by adding your credit card, using your credit card, you can get your stuff in your home, like, two days later. But what about... By the way, my dad is 73 years old, so what would happen to him if he's in his computer and he sees these faults? Like, what the fuck? What the fuck is the minimums? What the fuck are the monics? Private keys? What are private keys? Super-conversant for him. Not for us, because we're a developer spot. For a real user, it will be super-conversant. So my dad will be sad because he won't be able to buy his stuff and the folks will troll him. And that's not good. So it's a fact, and it's a well-known fact, by the way, that we lose 90% of our users in the installed MetaVast image. Clearly, what we are missing is user experience. That's why I'm super-happy to introduce you to the gas station network, which is the ultimate onboarding solution for Ethereum applications. Basically, the GSN is a great contract architecture in the blockchain that was first developed by Tavukki and afterwards developed by an alliance of companies, Tavukki opens up the importers pillar, for solving the user-amorting problem. I'm going to give you a brief introduction about this. Basically, the GSN is composed by a centralized group of relayers who are paid for relaying transactions. We're going to go deeper into this later about relaying that are, like, you know, relayers. A single and audited by Open Zepelin contract for coordinating everything that is called the Relay Hub, your jobs will pay for their own transactions. I mean, if I made an app, I would pay for the transactions, not the user, so my dad doesn't have to, or any user doesn't have to, doesn't have to struggle with the funds, which is great. So, let's go and see how does it work. These are our players, my user and my dad, their relayer, their relay hub, and their recipient contract, which is our smart contract that is linked to our dad. We don't know how a regular transaction works. My dad talks to Metamask, and Metamask helps him to talk with the contract in Ethereum blockchain. We also know how Metatransactions work. My dad will talk with our relayer, and the relayer will talk with the blockchain, maybe, or probably using the entity contract, aside from my dad. The GSN Metatransaction solution works slightly different. Basically, my dad will talk to a relayer. This relayer will check whether or not the recipient contract has funds for paying the transaction fees, and to pay the relayer fee, because here we have a relayer fee. If you're a relayer, if you want to start up every layer, which is super easy to do, like another five-minute thing, you will be able to actually get paid for those transactions through relay. If you have 100 relayers, and there are a lot of transactions that you are relaying, you will be earning money. As I was saying, the relayer will check whether or not the recipient contract has funds to pay for this transaction fee and the relayer fee, and if it does, then the relayer will have this contract that is, by the way, deployed by us in every single blockchain and it's unique. There's only one for each blockchain. We'll do several checks, for example, if the relay call is legitimate, and afterwards it will ask the recipient contract whether or not it wants to accept the relay call. If it does, it will actually send the relay call to the contract, to the recipient contract, and the under-rack hub will be able to pay the relayer for that transaction. So basically it's the meta-transactions from Royce because you don't have... When I say you, the smart contract developer, you don't have to think about assigning identity contracts to users and maybe afterwards ask the user to please add his credit card for doing a simple transaction and pressing a button in your website. That's why I told you here that that's paid for their own transactions, which is great, at least for the onboarding problem. And how can we use this stuff? Because I'm taking a lot of technical stuff and maybe you just want to use it. Well, we developed, as a team, the GSM provider. You can install it using MPM. The GSM provider is basically yet another Web3 provider that you will be able to use to transform your regular transactions into meta-transactions, into relay hub, relay GSM transactions. So just by changing your typical HTTP provider to the GSM provider, you will be able to do a call as in the third line. My contract.methods.dosomething, depending on where you were seeing before, and that's all. Instead of doing a regular transaction, it will do a meta-transaction, which is great, right? So you only have to change one line. Also, you have to make your contract GSM payable. And for that, the Open Zeppelin Contracts, or Open Zeppelin Solidity team, created a couple of contracts. For example, the GSM recipient that you will find just installing, Open Zeppelin Contracts, which just inheriting... Yes, if you have your contract, and you inherit from it, you will be able to access to the accept relay call. This function, I told you that checks whether or not the recipient contract wants to receive the transaction or not. Well, you can call that in the accept relay call. And what else? The Open Zeppelin GSM Helper. Maybe it could be for you to set up everything to develop your own GSM capable apps. And we basically developed these GSM Helpers for you to make it, like, in only one command. Just right after installing the GSM Helpers running, if you run all GSM runway layer, this will basically create a relay app in your local network if it's not created. It will download the binary of the relayer. It will then start the relayer. It will associate that relayer to the relay app. And it will fund it so it's capable of receiving transactions relay calls. And if you don't like CLIs, you also can use a programmatic way, which will be basically importing a register relay function and a fund recipient function from the same library. And just with one liner you will be able to or fund a relayer or fund a recipient or whatever you want to do. And we have been talking only about CLIs, code, but we also developed some web tools. You can go to seplin-slash-gsm-tool which will let you see, I mean, if you develop your own contracts and you upload them and you link them to the gas station network, if they are GSM capable, you will be able to see all the information of the DAB tool with the DAB tool and also see information of all their real names. But okay, I know I have like talked a lot about a lot of like, you know, tools, tools, tools, tools, tools. So, spoiler alert ended. You can use the starter kit, the GSM starter kit just by running with the CLI OpenSeplin AMBAP GSM and you will have the OpenSeplin contracts and CLI as you had in the previous starter kits in few organized react renewal again and you will also have within this starter kit the OpenSeplin GSM provider and the GSM helper. So, basically, by running all MPX, this command, OpenSeplin AMBAP GSM, you will be able to just start your GSM cafe capable DAB. And, well, that's all. This is the all, this are all the repositories we have been working on for the last year. The contracts, the CLI, the GSM provider, the GSM helpers, the OpenSeplin network and OpenSeplin test helper for you to test your contracts. You can please go to seplin.com to see all of this and also to seplin.com to see the documentation and, well, thank you very much.