 like making predictions about the subjective futures date of a remote chain. It's complex. It's a little redirect or get around, but it might actually be possible and pretty fast. Another alternative is just to let free markets solve the problem. So if I want to send a message to A, I could have someone else send that message on A, on behalf of using their own money, and then pay them back using the cross-sharp communication via another mechanism. So for example, if you have money on A, I could pay you slow cross-sharp F in order to put up your money immediately. So you could re-collaborate my CDP for me, and then I will pay you back with F that comes through a slow mechanism. So I would be topping up my CDP by entering into a new debt to someone else. There's a couple of pros here. It's instant. The cons are that it's incredibly complex to implement. It relies on a bunch of market actors just showing up. You're going to have to pay some amount of spread because they're giving up liquidity on your behalf, even though they have a strong guarantee that you will pay them back. So there's going to be slippage in cross-sharp. The price you pay, you will pay more than one shard B ether for each shard A ether you consume. So you're going to pay for this service. And the creditors can actually extort you a little bit, depending on how this is structured. They know your CDP is going to get liquidated, and they know that you're going to pay up to that amount, up to the amount you lose. And so that the opportunity to charge you higher rates based on the use case that you're transferring E for. And it doesn't work for some state. If there's any secrets here, you can't give away private keys or hash pre-images that are important to your creditors. So you actually can't use this for some types of contracts. OK, now we're getting away from things that I think could actually be easily implemented. And we're getting into stuff that is a little more wiggly-woply depending on future research. I've only got a couple of these, and then we're going to break for questions for the last five minutes. So we've talked about shards. We have to do asynchronous communication across shards. The idea has been proposed to synchronize shards temporarily. So to take A and B and just move them into the same place and have a period of time where there's synchronous. And I did not do a very good job on these errors here, huh? Don't worry about it. So for a period of time, we're going to have shared validators between A and B. And then anyone on A or on B can interact with the other shard instantly in a single transaction without any waiting period. So it would let me use my ether on shard B in a CDP on shard A. One of the ideas is that we re-randomize these pairings regularly. However, this is kind of what we invented sharding to fix. Each one, part of the reason it doesn't scale is because it has synchronous transactions. It's because all the contracts can interact with all the other contracts. So we want to shard things to get away from this model because it prevents scaling. So if we do synchronous shards or if we have synchronous periods among different shards, we're giving up a huge portion of these scaling advantages of sharding. For example, if we pair two shards, that's 512 pairs. So we've given up half the scale of our chain. And then L2 state, we're just going to very briefly touch on this because nobody has proposed a decent concrete model for it that I know of. There's a lot of interesting ideas about moving contract state into plasma chains or state channels or similar constructions. One of the main pushes in ETH2 is to have what's called stateless clients, where the entire chain state of any given shard lives with the nodes that are actually using it rather than in the consensus process. Where we can come to consensus on updates to the group hash of the state rather than updates to the state. It's a bit of a difficult concept to talk about. But generally speaking, this would involve taking contracts from shard A and shard B and ether from both of them and putting them into a shared layer two system that could settle for those shards. We don't know what this would look like. A lot of people are very excited about it. And I would think that getting a concrete design is a couple years off at least. OK, so this is the end of my slides for now. Do we have any questions about cross-shard communication? No questions? Oh, there we go. Would there be any strategic way to kind of think about for a given that they should be being that sharp together with the CP or the dial, for example, compound, and say, hey, we're making pretty smart contracts that's chuffed the same shot and suddenly everybody prints out the same shot? Yeah, so you're asking whether there's a risk that contracts will want to be on the same shard as other contracts so that they can interact directly. And I think there's definitely that risk. One of the reasons we have all got involved in Ethereum is because we have a whole smart contract is because CDPs and compound can interact. Sharding breaks that guarantee and makes it asynchronous interaction. So you have weaker guarantees about how the interaction affects the user. So compound and maker are particularly interesting because compound relies on a shared liquidity pool. Your compound's rate is dependent on how much of each asset is in compound right now. And in a shard of ecosystem, there have to be 1,024 different compounds deployed with different liquidity pools. So yeah, there are some pretty concrete advantages to having a chain with all of the smart contracts on it. Unfortunately, that's what we invented sharding to get rid of because it prevents scale. Yes? With this new state coming in, does it give any kind of you privacy about the chains or data segregation? Is that in the family? There is. OK, so do any of these models give privacy or data segregation across chains? No. And data segregation on a public chain is an impossible task. For a concrete example in Ethereum, we can always load the state tree as a Merkle tree in a smart contract to inspect private state variables. So any sort of on-chain public chain privacy is kind of an illusion. We can make it more difficult to read specific state, but we can't make it impossible to read that state. If you're talking about user-oriented privacy, like ZKPs or Zcash GIFs, that's kind of orthogonal to cross-track communication. Yes? So any kind of L2 state in order to verify it on a different shard, would that be like a slope model? Yeah. All of L2 requires some amount of waiting period, usually measured in days. One of the nice things about the cross-links is that they should finalize remote state much quicker than that. The reason we have a multi-date waiting period for L2 is to provide better security for users, because one of the security assumptions of all L2 constructions is that a user can get a transaction on chain in the waiting period. So a longer waiting period means that's a safer assumption. It's likely that that part of it will be much more significant than the cross-shard communication part of set-up on L2 state. All right, we're time's up. You can come find me afterwards. Thanks, guys.