 We're coming. The name of this talk is New Application Design Principles from EAD 2.0. But the structure of this talk, first, I'm going to talk about some of the technical limitations that applications evolve for space. And I think that I'm going to try and talk about it in a way that at least added a kind of granularity that isn't usually talked about. And then the second half will focus on solutions that we're seeing in space right now. And then what we're going to see in terms of trends, especially as EAD 2.0 starts rolling around. So what are the big technical challenges? The first one is transactional latency. So this one is fairly obvious. But with Ethereum 1.0 main chain, the block interval is eight seconds. Even with EAD 2.0, the block interval is going to be, at least, a target is around three to six seconds. And three to six seconds, it's good compared to eight. And EAD 2.0 is good compared to, say, 10 minutes. But I would argue that users are accustomed to responsible incies in the hundreds of milliseconds. So there is a code run around saying for Amazon, every 100 milliseconds of latency costs 1% of profit. And you see the same thing when it comes to, say, web search queries and their correlation with ad revenue, or even mobile apps, and the response latency and their correlation with communication. So I would argue that even three to six seconds is just not quite good enough. And it gets even worse if you have to do sequential transactions. So an example of that, as I'm sure a lot of you know, would be approving the allowance for an ERC-20 contract or transferring the ERC-20 contract to the smart contract. You have to do two sequential transactions. And I think that these block intervals 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 engineer's perspective, this seems fairly natural. But I would argue that for most users on the internet, they don't really look this way. Most users, a lot of the complexities are extracted away from them. And 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 nodes in that work have to basically recompute a transaction every single time they want to verify it. Another way of saying this is that it's not possible for a single computer to execute the transaction and then generate a proof that every other node in that work can officially verify. And then the third one is, you can't really do transaction delegation with the tools that are given to us right now. And one consequence here that I'm sure a lot of you are familiar with is that a user can't submit a transaction without paying for it. They have to have ETH on their account in order to submit a transaction. They're not allowed to delegate a payment to someone else. And I think another consequence that we talk about so often is that contracts themselves can 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. And then the last one is that it's just difficult to have two users that get together, sign on a transaction, and then have a set on a contract. It's a lot more natural right now with what's available for a user to only set on a transaction with a smart contract directly. And I think a pretty good example of this would be Uniswap, where despite the fact that it's an exchange, and I think it's fairly natural to think about an exchange in terms of, say, like a decentralized order book where you find a counterparty and then you sell for counterparty, they forget out a way to create an exchange where you only sell a smart contract. And that leads to a better user experience, but unfortunately most applications you can't really design a smart contract that way. So yeah, those are kind of like big technical limitations that I see right now when it comes to designing applications. The first one, high transaction latency. The second one is the gas cost tends to increase with the complexity of a smart contract. And then the third one is also that you can't really delegate the submission of a transaction to someone else. So then in terms of solution, what do we see right now? One, I think there are some few different names for this, but I'm just going to call it the Optimistic Framework. And this is a partial solution to transaction latency. So generally how it works is first, the user makes some kind of assumption. Basically they put some trust in another participant in the contract. And once you make that assumption, then you're able to delay submitting a 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 chain. And then everything else can be pushed off chain. And that means that certain transactions, you're not bound to the blockchain of all the blockchain. And then it just becomes something like a network which now goes back to like hundreds of milliseconds and not three to six seconds or eight seconds. Another one is meta transactions. So if you're not familiar with these are, so the gas station network is a pretty good, we're 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 pay for a transaction. And the general flow here is that user signs a transaction and then instead of submitting that directly to the mempool and by the mempool I'm just talking about the set of transactions that are pending in the theorem network or it's being submitted to the blockchain. Instead of submitting to the mempool, first they submit it or send it to a relayer and they exist outside of the network, right? And then the relayer does some kind of transformation, creates or turns that side message into a real transaction and then they're the ones that submit the transaction to the network and they're the ones that pay for the gas. And there, the reason why they do it is because they're compensated through some kind of pre-funded account and usually a pre-funded account is paid for by maybe the operator's smart contract. So again, this is kind of a partial solution to the delegation problem. So I'm not gonna 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 that are popping up that are kind of tackling those technical limitations that I was talking about. And the critical thing here is that none of these solutions are gonna be layer one solutions. They're all gonna be layer two solutions. They're all gonna require some kind of network structure. And that's probably one of the biggest takeaways that I want to take here, which is that there's going to be an emerging real-life market and they're going to be participants that are economically incentivized to take sign messages and do some kind of transformation on it before it gets submitted to the mem pool. And all of these solutions kind of use the same pattern and talk about the pattern real quick. The first step is the user signs a message and then again, instead of submitting to the mem pool, they're going to send it to a relayer and this relayer is gonna be incentivized to form some kind of computation and then submit it to the mem pool. And the third part is fairly critical and the smart contract or maybe the nodes in the network, they have to be able to efficiently verify the computation. 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 as the smart contracts get more complex is because right now, everyone has to compute the transaction in order to verify that everything was 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 rollups, it's why they have so much potential because depending on the implementation of zero knowledge proof, the proof can be verified in log 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 ETH2. When ETH2 starts executing transactions because beacon nodes have to be able to verify transactions that are happening on the shard chain with their 1,024 shard 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 good reason why a relay market doesn't exist and why it's kind of difficult to set one up right now. The biggest one is that a relay market or some additional piece of infrastructure, it's gonna add complexity to the entire system. It's gonna add more complexity possibly for the developers and then also for the users if we're not able to properly abstract it. And then another one is that right now it's difficult to integrate in a relay market for existing contracts. So the gas station network is a pretty good example of this where right now if you wanna integrate the gas station network to an existing contract, you need to set up some proxy contract in front of it. And that's additional gas costs and another security hole as well. And then the third thing is there's no standardization right now. So I think this is okay. We're still trying to figure out what the best solutions are right now. But I think as we figure out what the best solutions are, there is gonna be some kind of standardization and there's probably gonna be some general relay market anyways. And yeah, this is the last slide, but this is really for the application developers that are thinking about writing a new smart 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 hard. But if you decide that, or if you convince that it's impossible to create a smart contract, look at Layer 2, look at the existing solutions, but then also think about the relay market in a way that's specific to your application and see if there's any efficiency gains there that you can make specifically for your application. And then the third thing is if you do go with the Layer 2 solution, think about what reviews with your Layer 2 solution with other applications and maybe consider creating some kind of comedy structure for that. And that's it. Thank you.