 How many of you have built an app that's been used by thousands of users? Okay, amazing. Got a good developer crowd. Keep your hands up if you built a decentralized app, web-free app that's been used by thousands of users. Great, we still have a few hands, that's great. This talk is designed for developers who may be new to web-free space and I wanna share some of the lessons we've learned from building. Origin, so for those of you who are not familiar, Origin is a decentralized marketplace on the blockchain for enabling peer-to-peer commerce without any metal man or intermediaries. We've been working on it for about two years now. Our team includes people like one of the founders of PayPal, the first engineer in YouTube, one of the engineering managers from Google and Dropbox. And we've got, as of today, we have 16,000 unique wallets that are using the marketplace. And so I'm going to share some of the tips and tricks that we've learned from building that and I'll rely heavily on my experience there for some of the examples on how you can apply these design patterns to your own applications. So what's unique about building on Ethereum? Well, some of these are quite obvious, gas is not something you have if you've got a new Ruby on Rails application. You don't have to worry about immutability. As developers, one thing we know for sure is you're not gonna get a thing right when you first try, but how do you deal with that in a world where you can't change anything? In fact, it's written to the blockchain for all eternity. And how do we deal with some of the unfamiliar usability challenges of the blockchain? Of course, like, why do we need gas, right? Well, it's fairly to allocate scarce resources. It gives miners an incentive to secure the network. And this is deterrent for abuse. So it's actually a really important concept. But it also really sucks. Users aren't used to paying for gas. You've got things like Tether and tryptokitties or Fairwind clogged up the network and making your app really expensive or broken to use. And then most people on this planet don't have a ferry. So how do you deal with that? And when we look at what we've spent most of our time working on at Origin over the last two years, it's all related to, or one of the, a lot of these problems are related to this concept of gas. How do we minimize the gas costs or how do we get rid of it altogether? So the first thing you can do is just don't store as much data on chain. What you can do here is instead store a content hash. This is a very basic technique, which we use for storing all of the data that our application needs. We store it on IPFS, which is a content addressable peer-to-peer file system. And this is still secure, because if you change one byte of that content, then you'll get a completely different hash. And so it allows us to save a lot of money on gas costs by storing just content hashes instead. Now you do have to worry about the data surviving, right? You have a lot of risk of data loss. If you're not replicating that data, there's no risk of that data being tampered with. It's still secure. So take a quick look at what our data looks like. So this is the Origin marketplace. This is live on a mainnet, on a very mainnet has been forwarded quite some time. You can see you can buy or rent all sorts of different items on this marketplace. And all these systems are being fetched from Ethereum, blockchain, and from IPFS. So here's my apartment. In San Francisco, you're all welcome to come stay anytime. You can look us on the blockchain. And you just go on some home. What's that? And you just go on some home. Well, it's quite a discounted price, actually, if you've ever rented an apartment in San Francisco, it's actually quite cheap. You can pay with Ethereum or die. And you can see there's, you know, it's a really nice apartment to show up and stay. And so behind the scenes, this is the data that represents that listing. It's just a big blob of JSON that has all the details about this apartment. It's got some links to, you know, the pictures here on IPFS. But what we actually store on chain is just this little part of the URL right here. 42 characters of an IPFS hash. And if you change one character of this JSON blob, all of that goes away. So this saves us a lot of money by storing an IPFS instead of doing it, storing all this raw data on there. So we actually put some numbers to this. You actually look at how much gas it costs to store data. It costs 20,000 gas to store 32 bytes for a 32 slot, 32 bytes slot on Ethereum. Even modifying data costs 5,000 gas. If you delete data, it costs 5,000 gas, but then you get a 15,000 gas refund from when you first stored it. But one thing you'll notice here on the right, we have log. And so it's way cheaper for us to write to logs as to store data on a chain. So one of the tricks that we've leaned on very heavily at Origin is just emitting events instead of actually storing data into variables. So Pro is pretty obvious, you save a lot of gas. It's far more gas efficient to use events. The only problem is the smart contract can't read the logs. So you have a nice database of all the different events, but you have to have some other way to be able to index those events from the logs and things like if you're out, you have to pay extra for it. If you have your full node, you're running, you have to have some way of indexing those to make sense of it, but it's worth doing if you can. Another trick, if you are storing data on the blockchain, it's helpful to understand how the EVM is storing data on the recover. So those 32 bytes slots actually matter. So you can do things like variable packing, where you take the order on which you initialize these variables actually matters. So if you've got AB and C, these three variables, two of them are 128 bit, one is 256 bit. Now you can either pack it into two slots or three slots depending on the order of those variables. And that's the difference of 20,000 gas just by swapping the order of how you might be cloning. How many of you know what event sourcing is? Have you heard of this term? So some of you, okay? So I guarantee even if you don't know the term, all of you know this concept. It's essentially what the blockchain does. If you were to fire up a full node and start a genesis block and work your way to today to get the current state of how much money we all have, well that's the event sourcing where you're actually building up the state based on a list of events instead of doing it as the current state and just storing a snapshot of the current state. So this is a native concept to blockchains. It's also something that's really helpful when you're actually designing an app. So here's how we do it at Ordin. So here's the admin view. So this is a tool we built that lets you sort of go under the covers of our marketplace and actually look at all of the IPFS hashes and the app transactions and all the data that we want to generally hide away from the users. And so you can see here this list of all the events that have been happening on my apartment. So you can see when I first created it in the blob of JSON that was created and then I updated it out a few times and then someone made an offer on it and then I accepted that offer and then they left a review after the offer was complete, after the booking was completed. We got some more offers coming in and I accepted those as well. And so instead of storing a calendar on the blockchain about which days my apartment is available, can you think about doing that in Solidity? The amount of complexity of writing that code? Like, or if you want to come in and block off the month of July, well, do you put that in the forlip? I mean, do you pay, like, how expensive is that going to be to update that all of your storing all that data in the blockchain is crazy. So instead what we do is we don't even try. We just emit these events with each of the offers that come in when I accept them and then you can use JavaScript. You can, it's very easy to walk through this list of events in JavaScript and rebuild the state of the world. So if you want to know if my apartment is available or not, the only way to do it is go back to the start, walk through all of them, see which offers I accepted, which ones I've turned down and now you've got the sense of the state of the world and it's way, way cheaper, it's way, way easier than trying to do everything on chain. So name registries is another concept you should be aware of. E&S is probably the best known example, right? You can take some, when you want to map two things together. So you can take JoshPhaser.E for some nice friendly name and you can map it to an address. Origin has one. We have an identity contract where we publish identity access stations for all of the users on our marketplace. But as you might guess by now, we don't actually store that data, we just emit events. And what might be the simplest smart contract you can have, basically two functions, emit identity updated. It's the message job sender of your wallet and an IPFS hash with the attestations on your profile. And then we have identity deleted, which if you ask nicely, we will delete or we will unpin your data if you ask us to for an IPFS. Factory contracts. So these are super useful and another way to save on gas costs. They allow you to basically clone an existing smart contract and use that as a template for the code that you want to have run. A great example of this is a RENOSIS multi-seg lives. So you can deploy your own multi-seg with your own funds and patrol it. But it uses all of your code and you can deploy that in a very cost efficient way. And we do this for deploying our proxy contracts, which we'll get into in a little bit. The code is really simple. You just use this master copy, you pass in the master copy of the contract you want to clone, and then you use some magical assembly code here and you have a copy of that smart contract which you can use. One of the tricks that you can use here is predictable smart contract addresses. And so you can actually know the address of a smart contract reliably before it's even aligned on the blockchain. And so you can know it before it exists. And this is really useful for eliminating the need for a name registry. So what you can do is pass the owner of a proxy contract and an optional nonce to create two and then that will give you the address of where that proxy contract is going to live. So for origin, we create a proxy contract for each of our users and then we deterministically figure out where that contract is going to live and that way we don't have to use a name registry at all for doing that lookup and figuring out where our proxy contract will actually live. And so you can see that code right here on how you do that. So MetaTransactions, I mentioned it in the last talk. MetaTransactions, the high level is just a way for you to sponsor the gas on behalf of your users. And this is something that we rolled out at Origin because we want our first time users to be able to get up and create a listing without having to have a few pennies of gas in their wallet. The challenge is Ethereum says that the person who signs a transaction is the person who has to pay the gas. You can't have two different signatures on a transaction. And so you have to jump through all these crazy hoops in order to do something as simple as paying the gas for someone else. And so that's what we use our proxy contracts for. You sign a transaction, you send it to our real-air, then deploys that proxy contract if it doesn't already exist, and then sends that your signed transaction to the proxy contract and then relays it on to the destination contract where you want that code to actually be executed. And so the end result is a pop-up that looks like this. It says your signature is being requested, but there's no gas associated with it. So now you can actually write data to the blockchain or you can execute code. And yes, you need to sign it to prove that you control that wallet. You don't have to pay any gas. So let's talk a little bit about different options for upgrading your code, right? We don't have this problem in centralized applications. It's very easy to upgrade your code. But in this world, everything is immutable. So one option, some goes by different names. We call it master-slave. You have one smart contract, and it's just the dummy and proxy contract to tell everyone, hey, here's our proxy, here's our code, and then you just update a variable with the smart contract that's actually being called behind the scenes. Problem with this, of course, is your users have to trust that you're not going to be malicious and swap in malicious smart contract in place of it. And you also have this problem where data gets fragmented because every time you update your smart contract, the data starts living on those other smart contracts instead. It's not a great model. Another way you can do it is store your data and your logic separately. So we take a proxy contract, and it's okay, but we'll keep all the data on this contract, but we'll just bring in new smart contracts for the logic. And that helps quite a bit. But we still have a problem with, what if we change the data structure? So how do you do that? Well, you can use a key value type structure where you just say, okay, we can just add on new fields at any time. That works pretty well. The only downside is that it costs a lot more gas to do all that sort of computation and remapping stuff. Do it all the other day. You can just pause the contract and just start over, pour everything over, and just do it again. And depending on your scenario, sometimes that makes sense. So how we do it at origin is we say, like a lot of things, we'll just do it in JavaScript instead. Key bar to smart contracts is dumb and as simple as possible, and instead we'll write adapters. They know how to transform between each of the different versions of our smart contract, and you can apply these adapters recursively. So every version knows how to get back to the previous version, and you can very simply adapt your DAP across these different versions of your smart contract. So let's talk a little bit about UX. How many of you have seen this type of pop-up on MetaMask before? What the what? This makes no sense to me, let alone the average user. What is this? Why is this popping out the minute? I'm trying to use any sort of decentralized exchange. And so the reason you're seeing this is because of the fact that you have to move an ERC20 token or for a smart contract to move an ERC20 token. It first has to have approval from the user. That makes sense. It needs to have an allowance on how many tokens it's allowed to move. So the problem is is that you have two different MetaMask pop-ups that you have to do to do anything related to tokens. One, you have this crazy thing, and then you have a second one which actually pokes a smart contract to actually move the tokens to where they need to be. And the reason you're seeing this crazy pop-up is they only want to show us to you once. And so we just go ahead and ask for basically an infinite amount of tokens that they want to be able to move. But it's a very confusing user experience. And now when we were looking at building origin, we're like, how do we get rid of that? How do we move our tokens from our marketplace contract without having to show that MetaMask pop-up every time? And so it looks like there's prior work around this first. ERC827, which proposed combining these into a single step, approve and call. Let's just do them both at the same time. And we say, great, this is awesome. This is what we're looking for. And then we started reading the comments on it and it's susceptible to re-intensity attacks. We realized that the only problem, but you can't use that with any untrusted smart contract. But if you have your own trusted smart contract, you can actually lock this down and you can actually have approve and call WebSinger. And so what we do at Origin and this is live on our ERC20 contract has been audited by Trilobits. You can actually safely combine those two into one step. And so the user is only prompted one time to both approve and call, whenever we use Origin tokens on Origin's marketplace. And here is the code on how you do that. It's very simple. The only thing we really added to this was just the white list. And so I think I'm pretty much out of time here, but last thing I'll say, Origin's 100% open source and we do all the work in public. So come join us in our Discord. We have over 160 contributors to our code base and we'd love to have more. So thanks for your time and hope to see you guys around.