 So Anka will be talking about stateless cryptocurrencies. So this is a really short high-level overview and very simplified in order to understand another application of vector commitments, stateless cryptocurrency. So we are in the setting of a distributed ledger that uses some blockchain. And in this setting, we have new blocks with a bunch of transactions that come into the system and have to be approved before the ledger state will change. So in order to approve a new block, we have to look at all the transactions, which transfer coins from users, one user to another, here from A to B. And make sure that these transactions are consistent and coherent with respect to the state of the ledger. So with all the list of the balances of those users. So here we have a user A who has 20 coins and it was to transfer five coins in the first place. So it makes sense because it has the required balance in order to send five coins. And even later after it transfers this and this is approved, user A will transfer again five coins and this is still approved as a transaction. So some validators in the system need to look at the block, compare it with the state, and see if that is valid with respect to it. Okay. So this requires at each time to look at all the state, make a update of the state. And this validators either have to store all the state of the system or download each time they need to validate new blocks this state. And also the state will grow with new users joining the system with new coins and new balances adding up here. So a solution to make it scale better are vector commitments. And how does it work? Let's just recap what vector commitments are doing. We have a long vector, we commit to it into a concise commitment. And then later on we can open just one position, the value of one of the position in the vector and prove it correct with respect to the initial commitment to the long vector. So at any point we don't have to read again the vector, we just check with respect to the commitment. So in transaction validation, what we needed to do when we look at the state is that we check that A, user A here, indeed has a value that is bigger than five coins, the amount they want to spend in the transaction. And then we validate this. Okay, this is using state, meaning that we need to store or to download all this list, all this long vector of balances of all the users in the system. And then validate the transaction and this takes time. So instead of this, we will use commitments in order to take all the states and commit to it into a very concise way. And the validator will just look at the commitment in order to value. So how does it work? When a user in a system wants A, for example, wants to transfer five coins, it needs to convince the validator that will not look at the state anymore, that it has enough coins to transfer that. So it needs to convince the validator that it has 20 coins. And this is exactly what vector commitments allow us to do. We will just prove with a short proof PI that in the first, in the position A, we have 20 coins. So this transaction should be valid. And each user instead of just storing all the states, will store the proof with respect to the commitment to the state of their own balance. So each user here will store their proof, PAPB. So a transaction will just show the value it has to transfer and the opening of one position with the proof of that opening with respect to the initial commitment to the old state. Okay? A validator now just has to check this proof of the value, the claim value 20 with respect to the initial commitment that they store and never will look again or download the whole state of the system. So that's a lot cheaper, but still there are other requirements for this solution to hold in this setting. So as we said, after the transactions happen, we have to update to a new state. And update to a new state means that we need to do a new commitment to a new list of balances because the list have had change. But as you can see the list changes only in few position after one transaction only in two position here. So we can do better. We can just take the old commitment and use the update properties for commitments and that will just look at the position that changed and make a computation on the old commitment in order to update it to the new one. And we've seen this in previous talks. And that's a nice problem. But we also need to update the proofs. So each user was storing a proof of their balance with respect to the commitment of the state. Now the commitment of the states change, some balances change and actually all users have to change their proof with respect to the new commitment. So those are valid proofs with respect to the commitment that commits to the new state. So this is also possible with the updateability property of vector commitments that comes in these different flavors we were discussing today. The least convenient one is the hint updates which for example, the user C has to also look at proofs for A and for B in order to be able to update their proof for the value C because this needs the hints of the changes that happen in the vector. While the key updates need only a static key for the respective position that we want to update for this proof. And we hope even for better keyless commitments where we need no specific key or just some fixed key in the beginning with respect to any position for updating the proof. So that's a property that we require in this setting and another property that is useful is aggregation. And why aggregation? Because a new block means a bunch of transaction in each transaction here comes with their own proof with respect to some commitment. Commitment was even updated in between. So our proofs with respect to different commitments. So some aggregation nodes can simplify the life of the validators. So instead of reading all these proofs and have to check all them separately, a validator can just receive an aggregation of all those proofs with respect to the statements. So the opening values of those positions that are proven there. So we saw in the talks before there exists a lot of techniques to aggregate vector commitment proofs. And that is very useful for this application. And this comes in different flavors as we saw. Either the proofs are aggregated if they come from the same commitment. We ideally want to aggregate proofs that come from different commitments. So from different vectors, they can be one whole. So you aggregate and then you cannot we continue aggregating aggregated proofs or unbounded, you keep coming. Or even incremental, as Dario explained the incremental aggregation allows even to desegregate the proof and split it in smaller proof. For example, here in a proof for P, A and P, C and the different proof for P, B and continually reorganizing and re-aggregating this proof. Okay. So a little bit overview of some schemes that were dedicated for this use case for stateless cryptocurrencies. Those, there is a lot of them with nice properties. But as we can see, none of them is green all over and with really nice parameters in every single property that I listed here. So there is still some work to do in the field in order to achieve more practical constructions that will be useful for this application. And those are references. And I'm happy to take questions, quick questions if there are some. Anka, what is the CNRZ-22 reference? Oh, sorry. Yeah, I can come back. Do I have it here? I don't see it here. There was a CNRZ-22. Oh, it's the paper that Aransha presented this morning. It's the paper we have with Mateo, Kaila, yeah, and Aransha. Oh, is it Aransha? Not yet, but we are very motivated to have it in person. Yeah.