 I wanted to talk a little bit today about what it's like as a daft developer to think about sharded blockchains, in particular asynchronous communication between smart contracts. So from the introduction, you know that I'm one of the co-creators of CryptoKitties. I was also the original author of ERC721. I contributed quite a bit on the upcoming Cheese Wizards game, and we'll actually have a little bit more information about that in the middle of this presentation. And then I'm the chief architect of the upcoming Flow blockchain. In computer science, we like to have these toy versions of abstract problems, because it makes it easier for us to think through them. I'm sure everyone in this room is familiar with the Byzantine generals problem. It's probably the most famous one is the traveling salesman problem, as a way of thinking about how to build a spanning path through an arbitrary weighted graph. And then my personal favorite is the dining philosophers problem that asks you to imagine that a group of philosophers is eating dinner together, and not only can they not eat unless they're holding a fork in each hand, but they're actually sharing their forks after they've gone into each other's mouth. It's quite amazing. But we have these problems because the problems themselves are so abstract that they're hard for us to reason about. And so we create these toys stories that are maybe a little bit disconnected from reality, but they let us use our human intuition about how to solve them. And there's a common one that comes up in the Ethereum community, or at least that's where I saw it first. And it's called the train and hotel problem. And if you search on E3search, there's a bunch of great articles about people having ideas on how to solve the train and hotel problem. And it's fundamentally how to solve the problem of asynchronous communications between smart contracts that live on different shards. And so the toy version of the problem says, hey, you're traveling to a city and you need a train ticket in order to get there. And you need a hotel room when you get there. And you don't want to pay for a train ticket until you know that you've got a hotel room, but you don't want to book a hotel room unless you're going to be able to get a train ticket. And so if the train was on a smart contract on one shard and the hotel was a smart contract on another shard, how do you go about solving the problem of booking both of those things without potentially being in a situation where you've got one without the other? And there's a few interesting solutions to this problem. Some of the more interesting are the ability to actually move smart contracts from one shard to another, which has the potential problem of leading to denial of service attacks. The idea of mining two shards or synchronizing two shards so that the validators are trying to solve the two blocks on two shards at the same time to allow synchronous communication between the smart contracts on those two shards, which doesn't scale if you want to have three smart contracts talking to each other. And so usually most people think that the best way to solve this is just to have some sort of state locking mechanism where you can more or less put a reservation in for the train that is cancelable and then you go and you book the hotel and if that's successful you follow through on the train reservation. If it's unsuccessful then you can cancel the train reservation. So that toy problem I think is useful, but I think it's limited because it's so simple. And so I want to talk about something that maybe seems even more simple, but is actually a little bit more basis in reality and that's kitty hats. So kitty hats is a project that was created outside of Dapper as an extension to CryptoKitties and it let you put cool hats and other paraphernalia on your cats. And it was a set of smart contracts that leveraged our smart contracts, but we didn't even know they were doing it, let alone have any special hooks for them to be able to do this stuff. And it really showed the team and how one of the properties of blockchain that we weren't really expecting when we started building CryptoKitties and that's this idea of extensibility or composability. So this is sort of what a kitty hats implementation would look like if you imagine that kitty hats used stable coin instead of just ETH. So if a user wants to go and buy a hat to put on their cat, they go through this single transaction where they send a request to the kitty hat sales contract and that contract through a series of synchronous calls to other smart contracts is able to verify that all the things that need to happen can happen. So the first thing it does is it checks the CryptoKitties smart contract to ensure that the kitty exists and that the person who's trying to put a hat on it is actually the owner of it because you can't put a hat on somebody else's kitty. That would just be absurd. It transfers the stable coin over, which will fail if the funds are not available and then finally it'll put the hat on the cat which also could fail potentially if the kitty already had a hat and there was a conflict there. But the nice thing about a single atomic transaction is even if that last part fails everything just seamlessly gets unwound as the transaction reverts. But what if we had that same scenario where we had these four smart contracts working together but each of them was on a different shard? Well it suddenly becomes a much more complicated solution. So in this solution that I've shown here and it's not necessarily the only solution but it was frankly the best I could come up with it involved locking up the assets that were involved in the transaction before the transaction took place. So you'll see they're in block one the user is locking up their cat making sure that that cat can't be transferred while the rest of the transaction or the rest of the interaction is taking place. They're locking up their stable coin and they're locking up that hat. And then once they have like sort of a receipt from each of those other shards saying hey these things are locked up they can't change their state or change their ownership then it can go to the sales contract and say okay it's safe to send a message to all these other contracts and allow these transfers to go through. And you'll see here and I haven't explained all of the bits and bobs here but what was a single transaction on a single shard is when it's across four shards it's now 11 transactions and it's taking seven blocks possibly much more if those cross shard interaction calls can't happen in subsequent blocks which many designs don't allow. And this kind of interaction between smart contracts is hardly theoretical. I'm sure everyone in this room is familiar with all of the awesome projects in the DeFi space and Compound can't exist without dye. Zero X is not interesting unless it's talking to a bunch of ERC-20 tokens. And all of these projects are building on top of each other and most of them would be difficult if not intractable to build if they had to deal with asynchronous communication with those other smart contracts. So I wanna talk about another revolution that happened and sort of the peak of that revolution open source revolution was in the year 2000. And in 2000 everyone was really excited about open source and it was gonna completely transform software and it did but not the way people thought. In 2000 people expected that Linux on the desktop was we're gonna replace Windows and software like OpenOffice and the GIMP was gonna replace Microsoft Office and Photoshop. And that's not what happened at all. The open source revolution was real and it completely changed the way that we think about and make software but it looks like this. It's a bunch of little tiny components that are built on top of each other and some of those components aren't so tiny, right? They're significant but the power of them is that they're not solving a particular user problem. It's that they're a set of tools that different people can create different solutions out of. And I believe that the real power of smart contracts if we think of them in that way as building blocks that are each building on the next and working together to create lots of solutions and not just these monolithic things that are just replacing one institution at a time with replacing one institution with one smart contract. And so if you ever see people talking about the train and hotel problem I want you to imagine in your head well yeah okay maybe they've solved the train and hotel problem but have they solved the train, hotel, restaurant reservation, movie tickets, tour bus problem because I think that in reality smart contracts it's very rarely one smart contract needing to talk to another, it's a multiple. And that term that has come to express this is composability and I truly believe that composability is the superpower of smart contracts. You see here a quote from Jesse Walden of Andreessen Horowitz and he wrote a great piece talking about composability and I think the key phrase in there is compounding innovation. The fact that it's not one person or one team that needs to make one giant step of innovation it's that everybody can contribute a little bit and that compounds over time and as we all know compounding growth is exponential and there's no more powerful force in the world. Rated R for Ridiculous, Cheese Wizardz. Visit cheesewizard.com to summon today. So that was cool and all what the heck does it have to do with smart contracts and composability? The team at Dapper Labs was so inspired by the example of Kitty Hats that when we built our new game, Cheese Wizardz we were bought into the notion of composability and extensibility on day one. And so over the last six weeks or so we've been running a hackathon with a bunch of community support and prizes because we wanted to kickstart the community's creation of some amazing tools and there's a couple of them I just wanted to highlight right here. So on the right, Mark Pereira did a mobile version of our battle game. It's a, you know, Cheese Wizardz is a game where you buy wizards and you fight them and it's the land of Highlander, there can be only one and whoever wins the big cheese will take home a big old pot of ether. And you know, our team didn't have the time to build a native mobile app and so Mark took it upon himself to build one which is amazing. There's Cheese DOW over there which I think is incredible. I don't know if we would have thought of that ourselves. It's the ability for anyone to create a DOW, multiple DOWs if they want. And it's an interesting sort of DOW where the voting power in those DOWs is not based on who's contributed the most tokens but who's been the most successful in the game. And so this is the kind of thing that is possible when you are building platforms that don't have platform risk and that's what I think is the real power of smart contracts. And so I think we've seen this in a bunch of places and I think that this is going to be the story of smart contract platforms in the future if we let it. But I get real worried because I fear that if composability is the superpower of blockchain that sharding and in particular forcing asynchronous communications between smart contracts could be its kryptonite. Thank you.