 Our first session speaker is Bennett Yee from Oasis Labs, and Bennett will be discussing shades of finality and commit chain scaling. Slight modification, we're talking about validating bridges since that's what is checking what the commit chain or what often is called the commit chain. So this is your work with Don Song, Patrick Macquarie and Chris Bucklin. So some of this stuff is, everybody understands pretty well. So the question is what is finality, right? So Bitcoin, Ethereum B1 is final when it's committed on chain, but that means what? It means it's not gonna be on the short branch, right? And the reason that we care about this is, so users can depend on its effects on the state of the blockchain, right? How much money I've spent, how much money's to be deposited, affects whether I can propose another transaction. So what is finality? Well, proof of work blockchains, usually 60, but we have two colors here, but really it should kind of, probability it should kind of fade in and out or whatever is probabilistic because you don't know if you're on a short chain until you've had more blocks included. For proof of stake blockchains, as soon as the consensus committee have reached agreement and extended the chain using threshold signatures, people talk about instant finality, right? If it's on the chain, everybody can verify signatures and we can rely on the results. For layer two virtual machines, what's going on is there's a bridge contract that is verifying state transitions. And so these off-chain compute is getting their state transitions verified and that is final when the transaction for the bridge contract reaches finality. It decides it's accepted and it reaches finality. That sounds great, but what happens, from a more systems viewpoint, what happens when there is something like a zero date, right? Whether it is a core contract or in the underlying blockchain code itself, right? Often a heart fork is needed to address this, right? Sometimes we can just beg people to return the tokens that was misdelivered when it's not a core contract. But if it's catastrophic, there's not much we can do other than something like a heart fork. You know, governance type of decisions are needed and things tend to get kind of messy. Because heart forks can undo transactions, right? So it can change state arbitrarily. So that's a different thing that's going on. So some background, right? Blockchains is a pen only log, well-defined virtual machine. Bitcoin puts in the log entries just to transactions. The state of the virtual machine is implicit, right? Everybody has to figure it out for themselves. Ethereum contains both the transactions and what's the state route. And the state route summarizes the VM state. So that's pretty, everybody understands that stuff. Layer two virtual machines have some differences, right? So arbitrand's optimistic rollup does decoupled explicit state. So transactions are logged on the underlying blockchain in Ethereum before they're executed. And then the virtual machines compute the result in state and the bridge contract, the verifying bridge contract is going to say yay or nay, right? There's disputation periods and all that stuff. Eventually it says it's accepted and that is when the state is decided. And so that's the couple because it happens later. Other ones like ZK rollups, the transaction ordering is decided by entities on the layer two and the ordering is part of the proof. In OASIS network, we use discrepancy detection and agreement is on a single value that has both the transaction order and the results in state. So state is pretty important. And of course, in the past, Bitcoin has had checkpointing. This is wiring in the client where a particular block number essentially has a certain given state. So we don't have to go all the way back to Genesis. Tightly coupled is useful. It's okay when the layer two is fast and it's cheap. But decoupling has some of the advantages. And it allows the transactions to be committed at a faster rate than or at the average rate at which compute can happen. You can actually allow expensive compute that as long as it doesn't happen too frequently. What we're looking at is these different notions of finality. Log finality is what's in the log. So there are rules for what kind of data can be appended to the log. And of course, who can append a new block? The idea of course is once an entry is made, nobody can distribute it. However, the meaning of the data in the log entry depends on other semantic rules that are in many ways independent of the fact that the entry was made. What we're separating out here is this notion of transaction order finality. Once the sequence of transactions, these are transactions are basically queried functions that map from virtual machine state to a new virtual machine state. Once the order of transactions have been determined and we can in principle compute the state from the Genesis block, right? All the way to whatever is the last committed transaction. We've named the state. We may not have computed it yet. We don't have to, right? It's fully determined in a mathematical sense. This means that like an Ethereum, the state route is not really necessary, right? But it's a useful optimization. Of course, state is useful. And so state finality is, it can also be a different part of the message, a different type of message being logged. We use consensus for that too, right? We want to agree on the state because, you know, users really want to know what the state is of supposed having to compute it themselves. They want to use block-explores and figure out what the analysis are and so forth. But the observation here is just like in optimistic rollups, right? In general, state doesn't have to be logged in the same block as the transactions. And that's very important if we want to allow the compute and the VM to process large amounts of data or do anything that might be slow. When things are fast, then having them be tightly coupled is fine. So lastly, check point finality, right? Checkpoints is a way of allowing fast syncs. So the idea here is we can fix a state as everybody has agreed to it and it's been around long enough that the likelihood that there can be a zero day that nobody has discovered is extremely low. So it codifies this notion from, well, really, of a statute of limitation, right? If a zero day occurs and it was taken advantage of but the effect is way in the past because of the cascading nature of cross and effect, it's really hard to handle and of course, you know, record keeping and so forth. The, you know, how good the evidence is, preservation of evidence, that's also a problem, right? And from a machine viewpoint, there's storage reclamation and things like that. That's very useful. To summarize, the four shades of finality are log finality, right? This is what we're mostly dealing with in this workshop, right? The consensus is deciding on transaction order finality which is determining the state without necessarily computing it. And state finality is actually reaching agreement on that state. And of course, checkpoint finality is knowing when you can garbage collect so that people don't have to grow storage, you know, linearly on time and transaction processing, which matters. It's pretty obvious, right? So state because it's implicitly named can be recomputed. So transaction order finality is more important, right? You can derive state from transaction order. The thing about checkpointing is consensus algorithms deal with independent faults, right? Byzantine Journal does not make an honest general become faulty or corrupt. But that's exactly how viruses and worms work, right? They have a zero day, they can infect all the machines and those are common-mode faults and cannot be handled by BFT type of mechanism. So we need some other mechanism to try to handle that. And checkpointing is a principled way of allowing us to say once a fault is identified how do we determine what should be the case? We want to identify a past state that is before the zero day has been exploited and maybe replay transactions from there through bug-fixed code. This is a governance issue. Of course, you may want to skip some of the code, I mean some of the transactions. Anyways, so to wrap up, what we're presenting is kind of trying to crystallize and provide a more nuanced view of finality. And I look forward to the discussions, thank you.