 So welcome back everyone. This is the last block of our event today. If you're only joining us now, again, if you want to ask questions, we do have a Slack channel for the events. You can also ask them on Zoom. If you would like to write in your questions you can, you can also ask them live at the end. If you don't, if you do ask them live, you will be in the recording. So if you don't want that to happen just submit them in writing and add the notes that you don't want to read them out. And that said, I think we can move on to our final speaker of the day, not the last session, but the last speaker. And that is Victor Ruchanko. Victor is a principal operations researcher at Algorithms where he works on protocols and languages for blockchains. He's a co-author of the art of multiprocessor programming and a recipient of the 2022 bike surprise in distributed computing. Before joining Algorithms, he worked at Oracle Labs and Sunlabs in the opposite order, I suppose, where he worked on concurrent algorithms and data structures for shared memory multiprocessors and the fortress programming language. He has authored over 50 papers and holds more than 40 patents. And he received the doctor in science, a doctor in science, a SID, well, a doctor CNCA in computer science from MIT with a dissertation on models for weekly consistent memories. Today, he'll be telling us about speculative smart contracts in the Algorithm blockchain, which move some of the work off-chain celestial accommodate applications with greater storage and computation requirements than those typically supported by L1 smart contracts. Welcome, Victor. And the floor is yours. Thanks a lot. Yeah, so this is a work that we've been doing in the research group at Algorithm, theory research group at Algorithm for a while. Now, Jing Chen leads the group and Morris, her to he, and Louis Schreer are visiting professors with us. And other people on the team that competes on this are John, Janari, and Zach Langley, and Rio Levine. So anyway, so that I'm going to tell you about this project that we've been working on, basically, as far as to move some of the work off the chain to speculative smart contracts. It's over here. Okay, so let me just quickly put things in context because I'll have to talk about this a little later. But I'll grant, as I guess most of you know, it's a permissionless blockchain that uses a proof of stake, a pure proof of stake mechanism that gives us interest in transaction finality. It's fast. It's every four and a half seconds. We're planning to get it down to every two and a half seconds soon. But I'm not sure. And it's efficient. And there's no proof of work puzzles and we hope to go carbon negative. But I'm not going to try and elaborate on all the advantages of Algorithm itself. What I'm here to say today, to tell you about more is this new thing that we're trying to do where we don't want to have to do all the work on the Algorithm blockchain. We're going to do a lot of it off it. To do that, I have to tell you a little bit about what Algorithm already supports. First of all, we, like everyone else, we have a native token and you can transfer money, these algos from one person to another. So here's like a little sample transaction of that. The little Alice on the side, that's like the signature. So basically, here's the transaction and Alice signs it. It's like on my notation for that. In addition, you can actually use defined tokens on Algorithm that's the kind of, there's native support for this. And so same thing, then you can transfer, let's say you have defined a USDC token. So Alice can transfer that to Bob and again she would sign it. Algorithm allows you to do something called atomic transactions or in the code they're called transaction groups where you can group several of these transactions together and either all happen or nothing will happen. So this makes it easy to do atomic transfer, for instance. So Alice wants to give $2 for 5,000 micro algos, then to Bob, then they can put these two transactions together. Alice signs the part where she's giving 5,000 micro algos to Bob and Bob starts the part where he's giving two USDC to Alice. And this will either both happen or not happen together. We also support something called S-Core accounts, which is where you can make an account who's governed by a little program of predicate that says if your transaction meets the following criteria, then it'll be approved. And if not, then it won't. And the sender, the name of the account is basically the hash of the predicate that it controls it. And so in the little box over here in the signature box, it's kind of like the predicate. It's really written in a different language. I'll get into that a little bit. But the language is not really that interesting for our perspective or what we're talking about here. So you just think it's just any predicate. It's a predicate just on the transaction, by the way, not on the state of the blockchain. So it can be done. So it can be checked outside, not knowing what the state of the blockchain is. It can be checked just by looking at the transaction. With these predicates, we call them smart signatures, you can actually do what's called delegation. That is an account owner, like a normal signature account, can actually sign one of these predicates and say, okay, if you have this predicate with me signing it, you can attach this to a transaction, and that will cause the transaction to be approved. So for instance, Alice will sign the predicate over here, and then she'll give this to whomever, and then Bob can take it actually and put it on this transaction, which even though it says the sender's Alice, it's actually Bob who creates it and puts the signature here. It's authorized because Alice signed the predicate for which this transaction meets. Okay, then the next thing you can do is we actually do have kind of layer one smart contracts. They're called applications on the blockchain. And these are basically, yeah, just like just what you normally think of, it's actually a just a small program that and invoking these contracts is just another transaction. Okay, so in Ethereum, all of these things except for the native transfers are handled by smart contracts. But as I mentioned earlier in Algorand, these first two are really handled by have native support for them. And this follows our general idea, which is that we should make native support for things that are common to make them those things easy, and actually just these two features alone eliminated a whole bunch of things that people use smart contracts for, like hash time logs and stuff like that, just to do atomic transfers. Those are all just atomic transfers. It can be done trivially with these transactions. ERC-20 tokens can be mostly done by user defined tokens in Algorand, so you don't have to roll your own basically. However, we do have these other three things are, you know, there's kind of native support and there's an AVM that runs these things, but you do have to write the particular programs for them, just like you would in EVM. And so because the predicates you get to specify with the R, so you get a richer language to do them in uses, as I said, this language called Teal. And there's two versions of it. There's one that runs stateless, that is just looks at the transaction or the transaction group, if it's in part of a group. And then there's another stateful version, which is what the smart contracts actually run. Yeah, applications actually run. Okay. And as I think I alluded to earlier, there's actually pretty stringent storage and computation limitations on what can run in the AVM because we don't want this to impact the rest of the chain, and as I'll describe right now. So what happens when smart contracts are executed on normally, like in EVM, for instance, in Ethereum, right, is you have a whole bunch of transactions. I'll make small ones for the simple payment or the native kind of transactions, and then these larger kind of smart contract calls. And in Ethereum, they're just all mixed together. And you just send them all to the committee. And the committee just makes up blocks consisting of a mix of whatever it gets. And everyone has to execute all of these transactions. And the simple payments must wait for the, you know, if the contracts come before them, they must wait for them to execute. And these contracts can be pretty expensive. And that's comes sometimes comes up with why gas prices are expensive and all that kind of stuff. So all stuff I think you guys are very familiar with. And here the state of application is done by everyone re executing all the contracts. What we say is we don't want to do all this work. We can do some of the work off chain, right? And what sort of work should we do? Well, you know, basically, not all smart contracts need to be then layer one, they might be too big, right? That's a huge problem. We keep a lot of state on the chain. They might, they might run for too long. And so again, you're dealing a lot of things behind it. They might be so esoteric that we don't actually want to kind of run them by the time, you know, they're going to come for a little bit and not go away. So we don't want to put a lot of native support for these things. And they might just be too complex. I mean, writing in fear or in AVM is, you know, writing a stack based language fairly low level thinking. And it'd be nice to have a higher kind of level language to write these things in. So these are all reasons you might not want to run your smart contracts at layer one. So what we propose is a speculative off chain smart contract execution. The idea is to move arbitrary large user defined code out of the critical path of the consensus protocol, and instead execute them basically off chain. So the high level idea here, and I'll go into more detail as we go on. But the high level idea here is that you write smart contract in some higher level language. And we actually have a variant of the clarity language from block stack. But as I'll tell you later, as I'll mention later, it's fairly orthogonal. You can, you know, choose whatever language and it just wants you to be for that language, you can implement it, you could put in the place here. And this contract, this language actually lets you read and write the actual legislate that's the state on the blockchain. And so that's a bit tricky with speculation. So that will be a lot of what I talk about. And it also, of course, you can maintain your own storage, and that's maintained by the off chain nodes that actually do this. Okay, and then when you would actually want to invoke a transaction, what you do is you put a call a contract call transaction on the chain, say please invoke this transaction. And then there are separate sets of nodes, these contract execution committee nodes, who are just watching the blockchain to see these call looking for these call transactions. And they basically look at the contract and say, Oh, here's one, and then they execute it. And I'll talk more about how we do that in a bit. After they execute it, there's going to be some effects on the local store on the storage of that contract and possibly if the contract calls other contracts on those contracts as well. Right. But that all off chain storage. But there's, as I said, the contracts are allowed to read and write the ledger state. And so there might be effects on the ledger state. And right now they're all just doing it on their own local thing. They're not touching the ledger state because we're doing it off chain. So they have to write them back. And so we call these things that they're writing back, we call this the effects transaction. And a single contract might actually make multiple changes to the ledger state. At the same time, the state on the blockchain at the same time might make multiple transactions basically. But that's okay, we can make sure they all happen together because as I mentioned, all the grants supports atomic transactions. So you can say these are all either all go in or all don't go in. Okay, so let me just give a high level picture of that because maybe there's a lot of words. So basically you can imagine that these little yellow orange dots around orange things are contract call transactions. And then the little squares are regular transactions. And everyone just sending them into the content, the consensus committee as normal and the consensus committee just fills up blocked with them just as normal. So contract call transactions, it just use them as normal transactions. Okay. These are just calls. It's not actually executing these calls. It doesn't even know the language that these contracts are written in necessarily. Instead, we've got a contract execution committee that's watching for these contract call transactions. And it executes in this virtual machine that the contract committee has. And then in order to execute it, remember it can read the blockchain state. So what state does it do read? Well, we don't want it to have a moving basis. It wants to have a consistent view of the world. So basically we take a single snapshot at the basically where we start executing the block of the contract calls. And we say, okay, we snapshot the blockchain at that point and we run these contract calls with respect to that snapshot. As I'll discuss later, we can actually run multiple ones. We can batch them. And then the later ones will see the effects of the earlier ones. Okay. And then after they've done this, they produce basically a set of effects transactions. One for every contract call that they executed. Now, I say effects transaction. Remember, each one of these effects transaction could have multiple effects because they're effectively an atomic transaction or a transaction group that can have multiple effects. And there's one of these for every call that you do. Okay. So that's the basic set up. And then you write these effects transactions into the block, into like, say, maybe block five is now when it's ready. And the consensus committee, which puts them in, which just views them as any ordinary transactions and puts them in the block. Okay. So that's the basic story, the high level story. If you take anything away from this, that's the story we're going with. But there are a number of issues. It was just that simple, then we'd be done. But there are several challenges that arise because of this. Okay. What are they? One is speculation chooses the possibility of inconsistency. And that inconsistency can come up in the legislature or in the contract storage. I'll discuss each of these points later in more detail. But let's go quickly over them. Another is discussion authorization. How, why do we trust the transaction contract execution committee? And how do we know that when, you know, the contract execution committee sends an effect transaction to the consensus committee, how does consensus committee know that this is actually from the contract execution committee? And another kind of more subtle question perhaps is how do I know, I mean, the contract committee is saying transfer money from Alice the Bob, but Alice needs to sign transactions that transfer money from her to Bob. So why are the transactions that the contract committee tests to, why are they valid? Okay. Then we want to talk about the cost of executing off-chain in this way. What are the overheads introduced by this whole scheme that we're proposing? And also very briefly, how do we, how do the users pay for this off-chain execution? So let's go through each of these points. Okay. So kind of the main problem we're struggling with is basically this inconsistency speculation, right? So why is there this inconsistency? Well, let's just suppose that Alice, you know, one of these calls has the effect that Alice has to pay Bob 10 USDC. And at the end of block two, where we took the snapshot, Alice had 20 USDC. So the contract says you can do this. We've got 20 USDC, she has to pay 10, no problem. But somewhere between block two and five, Alice puts an ordinary transaction to pay Charlie 15 USDC. Okay. So now when the effects transaction of Alice reaches the blockchain in block five, Alice only has five USDC. And so the transaction saying pay Bob 10 has to fail. There's just not enough money to it. There's nothing you can possibly do to make that succeed. So, so it's going to fail. And remember during speculation, it was all being done off-chain. So there's no record on the chain that Alice is supposed to pay Bob 10 USDC. And so there's nothing to prevent the $15 transfer from Alice to Charlie from happening. Okay. So this speculation has to fail. Okay. So this introduces a window of vulnerability. And what do we do about this? Well, our policy is just fail the entire contract call. We don't want part of the contract call to be done, right? Because then there would be inconsistency. But if we fail the whole thing, you know, going back to the whole transactional system idea, right? If you fail the whole thing, then the execution state is fine. We just have to note that this guy has failed. Okay. Well, that might seem pretty bad. You know, what about progress, right? You're going along and, and it failed. Well, our view is that, you know, you shouldn't, you should, this kind of problem happened in real life all the time, you know, like, for instance, you write checks, you know, check personal checks can bounce. Just don't write the sum of your personal checks should not exceed your balance, right? Just make sure they don't bounce. And the same thing that actually happens with the blockchain already, right? For instance, when I look and I say, I'm going to send $10 or, you know, I'm going to have Alice send me $10, I look at seems fine, right? But by the time it actually gets the blockchain, there is some delay. And so if that delay is big enough, there might, maybe some other transactions happen in the meantime. So already this kind of speculation happens. And we deal with it just fine. And the reason we deal with it is because at a higher level, we know that we're, if we're honest players, then, you know, all the transactions we've issued together should be consistent no matter what order they happen in. That's, that's something that you as a user should generally satisfy. Okay. So as you said, the speculation already happened to the blockchain. And when the chain is slow, and there's not too many transactions, we don't really notice it. But when the chain is very fast, or there's congestion, then we might really notice the speculation. But the solution is just to make the users, you know, users should just be good players, right? They should be honest players. So they shouldn't write bad checks, they shouldn't depend on highly volatile state. And if necessary, if there's like, yes, I'm going to depend on this person giving me this money, then I should escrow to make sure we put that money in escrow so that it's guaranteed to be there at the later time. So basically, our our policy, our feelings that these most of these speculation players are easy to avoid, and just require the user to actually avoid them. And so in that case, we just failed the entire transaction. And as I said, we'll discuss later what happens when we do that. Okay, so the second kind of a decision can happen is in the local store in the contract store, the storage of each contract itself, right? And one question you might ask is, you know, there's many nodes executing this, you know, I'll talk more about that in a bit, but there's many nodes executing the contract call. How do they know that each of them has the right storage? They're working for the same thing, maybe they got grew up, or maybe they came up later and they say, I now need the storage, someone please give it to me. How do they have the right storage? Well, the way we ensure that is we actually keep a commitment to the storage state, basically on the chain itself. So therefore, of course, if they don't have this, the storage, the correct storage, they can't generate it. But if someone gives it to them, they can verify it's the correct one, it's the one they're supposed to have. By looking at the blockchain, for every each contract will have a little commitment in the blockchain. We'll have commitment to the storage in the blockchain. Okay, what about contract calls whose effects transactions fail to commit on the blockchain? Well, that's an interesting question. This actually means we have to have speculative storage and let me just show you a picture for this. Okay, so if I'm not doing speculation, then as soon as I'm done a contract call, I write basically back to the contract storage and I just keep on writing this way directly. But with speculation, what happens is I'm writing to a speculative cache. But I don't actually know that these effects transactions are going to go through. So what I have to do is I'm writing to this cache and while I'm executing in speculative mode, then I'm assuming they're all done, all these rights happen. And I want to write the speculation cache in order to be able to read the rights of earlier contract calls in my same speculation batch. And then when the corresponding effects transaction appears on the chain, then I write that particular, the right set corresponding to that particular contract into the actual contracts state. And this again introduces a sort of speculation kind of failure possibility, because it might be that contract call one and contract call two, you know, contract call two depends on contract call one. And if contract call one fails for, you know, because it was by a bad player, then contract call two will fail not because it was bad, but because contract one who stated was depending on was bad. This, we still need contract two to fail. But this should not cause, this should not be kind of blame contract call two should not be blamed for it. It's just it's the fault of contract call one. Okay, so again, we need to kind of have this watch out for this application, we have to make sure we do this right. Okay, another question you can ask is we asked earlier or two questions, you asked this, why is it contract, why do we trust the contract committee execution committee? And how do we know that a particular effects transaction is approved by that committee? And our idea for this is to elect nodes to the contract committee, just as we do for the consensus protocol, we, that is, we use the VRF to do cryptographic certification to randomly select participants, right from a large group, so that and we select a fairly large committee, like 150 or so. And, and, you know, we did some probabilistic analysis to show that that's good enough to give us kind of good very good guarantees about the safety and liveness of the of the committees. The reason they don't need to be as big as in the consensus, actually, if, if you know the algorithms consensus about 2000 nodes, but the reason this one can be quite a bit smaller is because they don't actually, they don't have to, like, what they have to agree on the result, but the result is deterministic, because all of the contracts are run deterministically. So they don't actually have to do agreement in the same way they know what the results are, they just have to make sure that they're actually computing it correctly. Okay, well, so each selected node certifies the result, and then if you get enough certifications, then that constitutes certificate, and then these certificates are validated by the layer one node. So they know that if they get a certificate, then they know that they have valid transaction that's from the contract execution committee, and they trust the contract execution committee because it was elected in the same way that the consensus committees are elected, just with a lower, smaller number than because the, the the guarantees are different, are there, because we have stronger guarantees up front to it, so, so we can have fewer committee members to get to guarantee the certificates correct. Okay, this certificate validation is expensive, and, and we advertise this by batching, which as we saw earlier, we do actually multiple calls for one, at one time, for one speculation, do multiple calls, so that we can basically advertise the cost of the certificate validation and all the generation of all the committees that we're doing. Okay, the other question I asked was, how do the, how can the contract committee, execution committee actually authorize transactions from other accounts, and this is where we use the delegation that I mentioned earlier, right, Alice signs a predicate saying, okay, the contract execution committee is allowed to post transactions on my behalf, basically, and they can actually specify, you know, maybe they can even put more rules about what kind of transactions they're going to do. This is akin to if, you know, the operating system's idea of capabilities, this is kind of like that, Alice gives the capability to the contract execution committee saying, you're allowed to do these things, and because Algram, the layer one blockchain supports these delegation, then this whole thing works. Yeah, these capabilities that I just mentioned, they are actually included, so the sender includes them in the contract call transaction when they make the call, they say, and here's the capabilities you might need to actually execute, you know, to actually authorize the transaction effects that are going to come out of this transaction. Okay, so let's talk a little bit about overhead. The overhead, there's two kinds of overhead, this is kind of the direct overhead of, basically, you're now making two transactions for every contract call, right, one to say, please make this contract call, and then one that instantiates the effects. If the contract that you wanted to execute is very simple, very small, very cheap to execute, then it's just cheaper to implement than layer one, that's what we have layer one contracts for, just do that layer one. But if it's going to be more complex, or you want, you know, to have more control over things, or yeah, if it's going to be more complex in this way, then the point is that it should be cheaper to do those two single call, those two transactions, then it will be to do the more expensive contract itself, at least many of the things that you want to do that contract will be more expensive. So the cheap ones with layer one applications, but otherwise, that should be no problem. But the strategic validation is pretty expensive. We estimate you need about 150 certificate certifications, 150 nodes to certify every batch of transactions, right, and a single certification involves signature check and a VRF check. So, you know, that's about like one transaction worth of things, maybe a little bit more. So you have to do 150 of those, that's pretty expensive. But the idea, again, is if these things are expensive enough, and we batch several of them together, then we amortize the cost of doing that kind of, and also, you know, the community has to do kind of gossip messages amongst themselves. It's just a single round of gossiping, so it's cheaper again than the consensus, but they need to do it. So the hope is that batching will make up for this expense. We are in the state right now where we have a prototype invitation, but it's not at the point where we actually can produce performance results. So we're working on that. Okay, batching introduces, we kind of have to go back a little bit, batching actually introduces a new kind of failure, which I alluded to earlier, which is that if contract call two depends on the result of contract call one, then if contract call one fails, then contract call two will also fail, because not because it was bad, but because it was depending on the results of something that it had no reason to believe was bad. So in that case, we actually will say contract one call one actually failed, but contract call two, we say that we put on a list to retry, because it didn't fail for its fault. It failed because of our batching, basically, because contract call one was bad. So we actually retry those ones. But notice that because you only fail if someone else failed before you, we get progress, sorry, answering the question I asked earlier, what about progress? You're still getting progress, because every time you go through batch, there's at least one bad guy who, if anyone fails, because there's at least one bad guy who you no longer have to do it in, because if you fail before, you're not going to run them again. This should probably fail again. Okay, the last kind of topic to discuss here, there's many things we could discuss, but in looking at the time is kind of how do we pay for these things? You know, like in Ethereum, you basically say, here's my gas that I'm going to, you know, here's a budget I'm going to give you in a gas, but Ethereum charges you basically exactly what you're going to pay right up front, because it does the contract right then and there, but we can't do that because we're doing it speculatively. So instead, what we do is we say, every time you make a contract call transaction, that is you're saying, please do this contract call for me, you're required to put money down, basically, you put money in escrow as a deposit that the execution uses to see that you have enough money to pay it. And then when you're executing, just like in Ethereum or any other smart contract system, every instruction is the cost that's deterministic, right? And so you just accumulate that cost. If the cost every goes over your deposit, then you say, this contract call failed, you say, it's failed, you put a failure, I'm not retrying it, and you just take the whole deposit. But if it succeeds, then you refund whatever you didn't spend. So now if the contract call fails, as I said earlier, for any reason, either because it fails in this kind of mode, because you ran over the deposit or you did something that it could tell was illegal right away, or because the transaction, the effects transaction itself fails, you know, like it looked good at speculation time, but when it gets to the blockchain, the world has changed and it's no longer good. In either of those cases, we say the transaction fails and we just kind of skip the entire deposit. So again, by kind of seeing the entire deposit, we're basically pushing the onus back onto the caller to say, make sure your call is going to be good. Now, if you want to write a contract that you want to give the caller more confidence, like, you know, to be able to do it without being worried that their entire deposit is going to be kind of skipped, and that's a deal between you and the contract writer that you have to kind of mediate to figure out who pays for that. But we charge whoever it is that makes the call. Okay, so that's all there I was going to say about this thing. I guess really the last thing I'm going to say about it is some issues we ran into for implementation of this whole system. As I said, we're working on prototype implementation. As I already alluded to, many of these things are already enabled by features that already exist in the blockchain. For instance, we're using layer one apps and delegation scripts to the capabilities and also to manage the commitment storage that I mentioned earlier, where we're storing commitments to the contract storage in there. And also, we're actually also managing how we tell which of the contract we were sending whole batches of effects transactions to the blockchain. And so we have to say which one which effects transactions we're authorizing, and so we also use an app for that kind of stuff. We did have to add some layer one support, some of which we want anyway, Metro, which we want any way actually. One is for instance, we didn't use to have layer one support for VRF verification. So this which we need for the election for the specific validation. This is a functionality that many people want. So we're going to add it anyway. But one nice thing about this whole project aside from that we hope that the speculative execution is itself a great contribution. But one nice thing about also is it's a kind of a needy application. So we're trying to do everything in layer two. So it says, look, we want to do this in layer two, we need some supported layer one in order to do it and this VRF verification is one of them. And another thing is we need a kind of transaction try. We're going to say, look, I want to try this transaction, but it doesn't work. Don't just throw it away. Instead, put this other transaction on. Do something simpler. And that's what we need to do the confiscation. We say, if the effects transaction fail, don't just throw it away. I mean, do throw that one away. But instead put it in a transaction that says take all the money in the deposit that was deposited. So we need this operation and this, yeah, that's an operation we need for our current approach. This said, these are not yet in layer one and we hope that they will be sometimes soon. The last point I want to note about the implication is that it's actually very modular. I didn't emphasize that I was going through, but if you kind of followed along what we're doing, I didn't even talk at all about what the VM, the contract, the layer two contract VM is like, because it doesn't matter. It's just, it's something that's run, you know, the layer one doesn't even care. It's just, you know, text for it, right? It's just sent to the layer two nodes who have to know what their own language that they're running are. We have a specific language in mind. The language does have to meet certain characteristics that are necessary for blockchains, but atypical for standard programming languages, like it's got to be completely deterministic and it has to specify the exact cost for everything, the price you're going to charge, whether that's the actual cost or not is a separate question, but you know, you have to specify a cost for everything. So it's atypical requirements for regular programming languages, but for smart contract languages, as you know, they're pretty standard. You know, that's completely orthogonal to all the things we're talking about. And even this complicated scheme, I said of doing certificate validation to authorize the contract execution committee, that's pretty orthogonal to, if you wanted to say, look, there's just this guy I trust, you know, to, to run all these contracts, you know, maybe it's, you know, Citibank or something like that. I'm not sure I trust Citibank to do it, but you know, supposing you trust someone to do it, you know, and they could just sign it and you say, hey, that's fine. I just accept that if they sign it, it's good, right? Because I trust them for whatever reasons I do, you could have that and that would be completely orthogonal piece, everything else would just work the same, except you wouldn't need all the certificate validation should be much cheaper. Same thing with the speculative, I mean, all of these are kind of independent of the speculations, the thing that I spent most time discussing. And also, I haven't really talked about it, but you can imagine that the contract storage, we're hoping can also be kind of is also largely orthogonal. We haven't, there are some issues there that we haven't completely worked out. So, so right now we have that tied in with the speculation framework. But it's mostly orthogonal. And I think we can make it more fully orthogonal. I'm going forward. So that's still work in progress. Okay, that's really it, actually. So in sum, I describe a solution, we say basically for very simple contracts, you should just use our layer one smart contract story. But for more complex user defined, you know, computation, we have this story for doing off chain speculatively, in a way that we think preserves basically the integrity of the underlying blockchain by not putting these heavyweight transactions, you know, gating that will cause other things that will to be blocked by them. So these other things are expensive, but they're done off chain. And just when the results are ready, they're put on chain. Yeah, I think I've said all of this. All right. So that's it. If you have any questions, I think we have a few minutes. Indeed, we do have a few minutes this time. Thank you, Victor. We do have a couple of questions already in spec from Marco. So I think we can start with those. Yeah, if you could read them, I can actually look at my slack while this is displayed. So yeah, Marco will read them. I will paraphrase them. So assuming that contracts can call other contracts once you fail a contract, do things get messy? It's a very, very vague question, but I hope you see where I'm going. Yeah, that's right. If contracts call other contracts, then right now we have a very simple scheme in mind, which is just that you have to have the guy that's done before you succeed. No, I'm sorry. I take that back. There's two different things. We do actually execute them in order, although that we can actually relax too. But every contract has its own commitment and storage. So if one contract fails, but the contract after contract call after it doesn't access the state of the contract call that failed before it, then it never looks at that contract call state. And so it succeeds just fine. But if the contract, so if I have contract call one and contract call two, if two access the state of contract call one, then it and contract call one changed the state. Then contract call two, when it runs, it will say, the first thing it will do is say, let me check all the commitments of all the guys that I'm expecting that I'm going to touch, that I'm going to read. So I'm going to check that their commitments are what I expect them to be. And if they are what I expect them to be, then I know they're good. It doesn't matter whether they did something else, if they changed whatever, as long as their commitments are the same as I expect, I just say, that's great. And I go on. So you'll succeed in this way. So you'll only fail if the thing that you, if the thing that failed was something you actually depended on. So it's, it's, it's kind of exactly what you'd hope for in that, in that regard. Now, what we don't do is it might be that inside the contract state, you know, some part of the contract state changed, but not the part I was touching. And right now we treat that monolithically, you could imagine that we'd have a more richer story of how we store the commitments for every contract storage for every contract to allow you to kind of say, yes, I'm actually only actually in this part of your storage, you know, please just tell me where that part failed, where that part changed or not. We don't currently have that story, but that's just a more elaborate commitment story. We could easily incorporate that if we had it. If someone said what they wanted in that regard, but you'd have to write the contract to do it. Thanks, thanks. And one question, if an off-chain transaction failed because of this off-chain on-chain concurrency, basically it's what happens to an off-chain transaction? Is it retried? Is it up to the user? No, generally speaking, you fail because your effects transaction is now invalid where it was valid speculation time. Generally speaking, we say that's your fault. That's like double spending, you know, like it's issued more checks, so we fail and we take your money, basically. We're like, be better and manage your accounts, basically. You know, that's a policy choice. You could have a different policy choice. That policy choice makes things simpler for us. You could imagine you'd want to have a different policy choice, but we'd have to think about, you know, it's not even the technical aspect of it. I would say it's more like what the policy aspect of it is, what I really want to think about. I think almost any policy you want, we could probably enforce. You know, if you wanted to like not confiscate all your money at that point, we could probably do that. We just have to say how it is that what you want to do instead. Okay. And maybe the last question, which is not a question, but the request, if you can post the, I guess you have a paper describing this, maybe I missed the title of the paper. If you can just post it after the discussion to the select, that would be great. I'm sorry, can you say it again? I don't have, we don't have a paper of this yet, so. Okay, I see. Yeah, it's still kind of work in progress. Okay, so basically no other specific documentation, specification apart from what you just told us today. Yeah, I mean, I mean, Jing has given a talk about this somewhere else. So there's another like talk fragments hanging about in some places. But, but yes, there's no, you know, we have internal documentation, but nothing that we've written up for external consumption. We will soon, I think. But you know, we're, as I said, we're trying to get this prototype implementation kind of going, then we can start to do a performance kind of evaluations and, you know, all performance evaluations are somewhat suspect until they're running the actual chain, but at least we can kind of do kind of preliminary sort of like, okay, at least in proof of concept, you know, it's, it's viable, right? Like so, thanks to that. Yeah. Thanks. So yeah, let's go with the other question. Yeah, so there's a question. Giuliano has a hands. Yeah. My question is, so if you understand correctly, this allows you a fluid computation from the main chain, but as for any storage that is not transient, it's still going to end up on the main chain, right? I'm sorry. No, no, storage is not transient. I mean, there's, there's storage that, like, you can manipulate storage on the main chain, but you can also keep storage that's not transient off chain. It's just kept by the nodes that are doing contract execution. They're the only ones who do it. And as I said, I think we'd like to have a story that's even better than that, in which you actually can say there's a third party storage for it. But there are some trickiness with third party storage that, you know, we haven't worked out completely. So I don't want to commit to it. But I think we'd like to eventually have such a thing. I see. So the state is actually partitioned in two. That's right. On chain storage and off chain storage. And the off chain storage, our only representation of that is a single commitment on the blockchain. So it's represented on the blockchain, but just in this kind of, like, as a, you know, hash, basically, some kind. And like I said to Marco, it could be that you'd have a more sophisticated thing. So it'd be like multiple hashes, because you could kind of say, you know, you could ask for parts of it have changed without asking whether, you know, anything changed, or, you know, could be a Merkle route, and then you could do Merkle paths or something like that. There's some state that has to be there explicitly, if it's going to be accessed by native operations, right? Oh, well, so native guys can access the the contract, the layer two contract state, they cannot do this, generally speaking, they can only look at the commitment, which is, you know, opaque to them pretty much, you know, but are they so they do look at the commitment because they need to check the commitment to make sure that it's what they're what you're expecting. So the native guys are doing that stuff. But that's all they can do, unless they actually been tracking the, you know, it's all public. So in principle, they could all run the things and do it, but without actually executing the contracts, they can't tell what the contract storage state is at all. That's just not available to them. Okay. And so they are two guys can do the other can look at both things because they are executing all the contracts. Okay. And could you imagine having several contract execution committees? Yes, we definitely do. In fact, they could be running concurrently. If they're running on separate disjoint sets of contracts, no problem. And then there's no problem at all, because these are just all they are two solutions. So you just in your land of contracts, and I'm in my land of contracts, if we wanted them to interoperate, it's a little bit trickier. So then we have to talk about how we do that. That's too open a question, I think, for me to give a kind of a core here and answer to, but yes. Cool. Thank you. We definitely want to support that. Okay. Fantastic. We have one final question, even though we're already at time, I'll let Matai ask the question. Just please avoid many wrong things. We can continue in swag. Yes. Yeah. Thank you, George. And hi, Victor. It's been a long time. Yeah. I want to once more return to the, to the mis-speculations. I'm wondering whether it's really always possible to blame the user in a way for mis-speculation or whether there can, whether you can imagine a legitimate case where, where in best faith, the user submits a transaction and it just gets mis-speculated for, I don't know, network asynchronous. And then there's, this transaction gets lost in the network and or delayed for, for 10 years. And then it shows up and then, and then the user gets the money. Well, I, I think it's possible to imagine some circumstances, but it's a question of what we believe about, about users. So people should not write contracts that have that kind of properties, what I'd say, roughly speaking, shouldn't use contracts that have that property. They should instead escrow stuff or things like that. So that, that doesn't happen. That, that should be the mode that people use them in, right? So is it possible to write such things? Yes. I think there are legitimate applications that sort of made the most naive way you'd write them would have that property, but you shouldn't write them in that naive way, right? Like you should write them in a more sophisticated way. But as I said, you could want to have a different policy. And then the contract themselves could say, yeah, we'll refund you your fees or whatever, just like, you know, various different things to, you know, like if you would say, I'm going to do this, I'm going to send you some money, right? A lot of things would say, well, we'll send your money back. And it turns out that you didn't like it, even if it's not our fault, whatever, right? So you could have such things. And so we're saying, we're putting that on the, on the contract writers to do. We could implement a different policy. And I'm not opposed to thinking about such a policy. We just thought that it wasn't clear what that other policy would be. It's a little bit hard to know, you know, so you tell me, here's the policy actually, we could probably implement that. It's not that hard to imagine, it's just hard to know how we're going to get the contracts to tell us what their policy they want is, if it's not this policy. Right on. That makes complete sense. I was just wondering whether, if my transaction gets stuck in the network, and then I actually don't. Yeah, I mean, also, it's not likely to actually get stuck, because all of the grant basically has a validity window for transactions. They can't be valid for more than a certain amount of time. So after that amount of time, they're just going to drop. Okay, yeah, that actually. So it can't be stuck for years. It can only be stuck for a thousand rounds, which is by an hour. Yeah, okay, that makes perfect sense. Thank you. Thank you. Yeah. Thanks for the question. All right, fantastic. Thank you all for the questions. Thank you, Victor, for your great presentation.