Sharding From A Dapp Developer's Perspective by Dieter Shirley (Devcon5)

I wanted to talk a little bit today about what it's like as a DAP developer to think about Charlotte block chains in particular asynchronous communication between smart contracts so you know from the introduction you know that I'm one of the co-creators of cryptic ad so I was also the original author of ER C 721 I contributed quite a bit on the upcoming Chi's Wizards game and will 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 a through an arbitrary weighted graph and 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 mouths it's quite amazing but but we have these these problems because the problems themselves are so abstract that they're hard for ourselves they're hard for us to reason about and so we create these these stories these toy 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 Assyrian community or at least that's where I saw it first it's called the Train and hotel problem and it's if you search on e3 Searchers there's a bunch of great articles about people having ideas on how to solve the trainer 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 travelling to a city and you need a train ticket in order to get there and you need a hotel a 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 and but you don't want to book a hotel room unless you're gonna 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 in 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 you've got one without the other and you know there's there's a few interesting solutions to this problem some of the more interesting are you know the ability to actually move smart contracts from one shard to another which you know has the potential problem of leading to denial of service attacks the idea of of mining two shards are synchronizing to shards so that the validators are are trying to solve the two blocks on to 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 hakka to 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 you know more or less put a reservation in for the train that is cancelable and then you go in you book the hotel and if that's successful you you follow through on the train reservation if it's unsuccessful then you can cancel the train reservation so that toilet problem I think is useful but 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 he's 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 Krypto kitties and it let you put cool hats and other paraphernalia on your 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 any special hooks for them to be able to do this stuff and it really you know showed the team and how one of the properties of watching that we weren't really expecting when we started building crypto kitties 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 a stable coin instead of just eath so if a user wants to go and buy a hat to put on their cat the they go through this the single transaction where they they send their requests 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 crypto kitty 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 head can't put a hat on somebody else's kitty that would that would just be absurd it makes it transfers the the stable coin over which you know will fail if the funds are not available and then finally it'll put the cat the Hat on the cat which also could fail potentially if the 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 you just seamlessly gets unwound as that as the transaction reverse but what if we had that same scenario where we had these you know 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 in the 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 involves locking up the assets that were involved in the transaction before the transaction took place so you see say that see they're in block one the user is locking up their cat making sure that that cat can't be transferred well the rest of the transaction is there 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 these things are locked up they can't change their state or or change their ownership then it can go to the sales contract and say okay it's safe that to send a message to all these other contracts and allow these these transfers to go through and you'll see here and I haven't explained all of the 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 threat achill you know you you I'm sure everyone in this room is familiar with all of the awesome projects in the dphi space and compound can't exist without die 0x 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 want to talk about another revolution that happened and sort of the peak of that revolution the open source revolution was in the year 2000 and in 2000 everyone was really excited about open source and it was gonna 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 was gonna replace Microsoft Office and Photoshop and 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 there they're significant but what the power of them is that they're not solving a particular user problem it's that they're consists of a set of it's there 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 you know 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 training hotel problem I want you to imagine in your head well you know came maybe we've solved the train and hotel problem but have they solved the Train hotel restaurant reservation movie tickets to or bus a problem because I think that in reality smart contracts it's very rarely won smart contract meaning talk to another it's it's a multiple and that term that has come to Express this is his composability and and I truly believe that composability could is the superpower of smart contracts you see here a quote from Jessie Walden of andreessen horowitz and he wrote a great piece talking about composability and I think the you know 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 [Music] [Applause] with that visit cheese wizard calm to summon today thank you so that was cool and all but what the heck doesn't have to do with smart contracts and composability the team at dapper labs was so inspired by the example of kitty cats that when we built our new game cheese wizards 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 kick-start the the the community's creation of some amazing tools and there's a couple of it's one of the highlight right here so on the right my mark Pereira did a mobile version of our of our of our battle game it's a you know she's was just a game where you buy Wizards and you fight them and there's it's a you know 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 is cheese now 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 dhow multiple doubts if they want and it's an interesting sort of down where the voting power in those doubts is not based on whose contribute 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 that's what I think is the the 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 super power of blockchain that sharding and in particular asynchronous forcing asynchronous communications between smart contracts could be its kryptonite thank you you [Applause] you