New Application Design Principles in Ethereum 2.0 by Yutaro Mori (Devcon5)

[Applause] come in the native clock is new application design principles we need 2.0 but the structure this talk first I'm going to talk about some of the technical organizations that application vault for space and I think I'm gonna try and talk about it in a way that Ellie's time you can granularity yeah is it usually puffed up and then the second half will focus on kind of solutions that we're seeing in space right now and then what we're gonna see in terms of trends especially as you start scrolling around so what are the big technical challenges the first one is transact transaction latency so it's what is fairly obvious but with the theory on 1.0 main chain we block their balls eight seconds even with e 2.0 the block interval is going to be at least some target is from three to six seconds in three to six seconds it's good compared to eight the natives of alligator compared to say ten minutes but I would argue that users are accustomed to responsibly and see hundreds of all sizes so there is a coke but around saying or Amazon every 100 milliseconds of latency a possible percent profit come to the same thing to say web search queries and their correlation a trek views or even mobile apps and a response latency in their correlation with education so I'd argue that you have three six seconds which is not quite good enough and it gets even worse if you have to do sequential transactions so an example that as I'm sure a lot of you know the along with spur DRC a contract before transferring your asset to any contract for this one contract you have to do to support intersections and I think that deep black holes are not fast enough another one is as the complexity of a smart contract increases the gas transaction fees also increase with it and from an engineering perspective it seems fairly natural but I would argue that for most users on the internet they don't really like them this way most users a lot of the complexities abstracted away they're accustomed to say free applications or low-cost applications and I think one of the key reasons for this dissonance is that with smart contract applications all the dough's in that work can have to Lou basically recompute offense action every single time they want to verify it another way of saying this is that it's not possible for a single computer to Mexican transaction and then generate or prove that every other no time a network official verify and then the third point is you can't really do transaction valuation with the tools that are given to us right now and one consequence here electrolyzer you're familiar with is a user and submit a transaction without paying for it great they have to have Eve under account in order to submit a transaction they're not allowed to delegate from Haven to someone else and I think another consequence that we talk about so often is that contracts themselves can't really initiate transactions if you think about a traditional application developers are pretty accustomed to things like cron jobs that are able to execute a transaction on some kind of set interval to maintain the state of the server you can't really do that with smart contracts or them and then the last one is that it's just difficult to have two users that get the other side of the transaction and then how a contract it's a lot more natural right now with what's available or a user to only settle transaction with a smart contract directly and I think a pretty good example this would be you swap where despite the fact that it's an exchange and I think it's fairly natural to think about exchange in terms of sale like a decentralized border book where you find a counterparty and then you sell the counterparty they figured out a way to create exchange where you only sell with smart contract and that leads to a better user experience but then unfortunately most applications you can't really design a smart contract that way so yeah those are kind of like a big technical limitation that I see right now when it comes to designing applications the first one high transaction latency the second one is the gas cause tend to increase with the complexity of the smart contract and then the third one is also that you can't really delegate a submission of a transaction with someone else then in terms of like solution what we see right now one I think there is some different names for this but I'm just gonna call it the optimistic framework and this is a partial solutions transaction latency so generally how it works is first the user makes some kind of sumption basically they put some trust and another participant in the contract it once you make that assumption then you're able to delay submitting the transaction because you don't really need the guarantees of the smart contract or sorry the blockchain to secure the transaction and then once you're able to make that assumption you're able to just you're able to only submit the most economically relevant transactions on tape and everything else can be pushed off shape and that means that certain transactions you're not bound to the block your whole watching and then it just becomes something like like network round trip which now goes back to like the hundreds of milliseconds and now 36 seconds or eight seconds another one is meta transactions so I pronounced Malay what these are so the gas station network is pretty good or a well-known implementation that's live right now and this solves or at least is a partial solution to the delegation problem and they're specifically attacking the issue where users sometimes don't want to or can't be every transaction and the general flow here really is that user sends a transaction and then instead of submitting that directly to the mempool and what amendable I'm just talking about a set of transactions that are pending into their network or it's a submitted the blockchain instead of somebody well first they submit it or send it to a relay and they exist outside of the network point right and then the relay er does some kind of transformation create some are turns outside message into a real transaction and then they're the ones that submit the transaction to the network and they're the ones that make the videos and they're the reason why they do it is because they're compensated through some pre-funded account and usually every funding account is paid for by maybe the operators smart contract so again this is kind of partial solution to the evaluation problem somehow I I'm not going to go through all these but the point that I'm trying to make by the way if some of these words don't make sense that's okay but the point I'm trying to make is that there are all these solutions are popping up that are kind of tackling those technical limitations that I was talking about and the critical thing here is that no these solutions are you layer one solutions they're all going to be layer two solutions they're all going to require some kind of network infrastructure and that's probably one of the biggest takeaways that I want to take here which is that there's going to be the merging of a target market and they're going to be parts of spins that are economically incentivize to take side messages and do some time transformation on it before it gets submitted to the middle and all of these solutions kind of use the same pattern and spot pattern go quick the first step is the user signs message and again instead of spinning to the mempool they're going to send it to every layer and this real layer is going to be incentivized to perform some kind of computation and then submit full and the third part is fairly critical and the smart contract or maybe the nose in the network they have to be able to efficiently verify the computations and this kind of goes back to what I was talking about earlier where one of the reasons why the transactions are so expensive especially the smart contracts get more complex is because right now everyone has to compute the transaction in order to verify that everything is correct but if you can kind of separate that and if the verification is cheaper than the computation that's a very powerful pattern that's also why if you've heard of like ZK roll-ups that's why they have so much potential because depending on the implementation of terminology proof deep in the roof can be verified and lock n where n is like the number of steps to perform a calculation and then I'll also comment that this is very relevant for Phase two of each to one each to starts executing transactions because Beacon knows have to be able to verify transactions that are happening on the char chain for their 1,024 char chains which means that there has to be some kind of efficiency gain when we're verifying transactions but on the flip side or at least taking a step back there is the reason why market doesn't exist and why it's kind of difficult someone up right now the biggest one is that a relayer market or some additional piece of infrastructure it's gonna retire system it's gonna add more complexity possibly for the developers and then also for the users that we're not able to properly absorb for existing contracts so the gas station networking pretty good example this where right now if you want to integrate the gas station network to an existing contract needs set up some proxy contractor part of it and that's additional gas costs and another security pool as well another third thing is there's no standardization right now so I think this is okay we're still trying to figure out the best solutions all right now but I think as we figure out what the best solutions are there is going to be some kind of standardization there's probably gonna be some general new labor market anyways yeah this is the last slide but it's really poor the application developers are thinking about writing in use of our contract right now and I would say try and keep the smart contract as simple as possible but there's a caveat which is that writing a simple contract that's also useful is really really really large but if you decide that or if you you they're convinced that it's impossible it's great smart contract look at layer two look at these facing solutions but then also think about the real a market in a way that's specific to your app and see if there's any efficiency games there that you can make specifically for application I mean the third thing is if you do go with the layer 2 solution think about what you use with your layer 2 solution with all their applications and maybe consider create some kind of accommodate researcher yeah that's it [Applause] you