 Our next presenter is Robert Van Rens from Cornell University. My apologies if I pronounce your name wrong. Tampa Prove Providence Aware Storage for Mobile Ad Hoc Networks. Thank you very much. Pleasure to be here. So this actually joined work with Danny Adams, Guar, Ruvanbisa, Shenwen Wang, and Hakim Wetterspoon at Cornell University. None of them could make it today. So I'm the lucky one to present this talk and I'm happy about it. Let me see if I can, yes, there we go. So the main idea is actually similar to what we've heard from Martin and actually also relate to what Victor was talking about before that. Want to support decentralized applications in an ad hoc mobile network when there's no reliable network infrastructure, no reliable power source. And so settings like these occur like an emergency response when maybe the internet goes out, digital agriculture types of applications and applications we're looking at right now on farms and in general, the internet of things. So for example, might have an application where you have a medic that needs to have access to medical records, but want to be privacy aware. So we don't want the medic to just look at any particular record that he or she or they want to look at, but somehow provide secure access. Of course when the network is down, that's tricky. And so one thing we do is provide accountability by logging any request in a temper-proof log. Then provide that record from some database that should be stored on the medics device, but not usually accessible until that request is logged. And then after an emergency over these logs may be reviewed. But how do we implement these temper-proof logs? In an ad hoc network, there might not be access to the cloud or the internet, not all those, but maybe trusted. Traditional blockchains might sound like an option, but they're not really, because tend to be quite compute intensive, particularly if they use proof of work or something like that or proof of some resource. And also they require high network connectivity. So miners typically need to broadcast their blocks as quickly as possible to all the participants. And but in our situation, notes may be disconnected from the network or there may be significant network petitions. And also all this wasted work from creating blocks that then later pruned can lead to significant security issues. So then there's the whole area of permission blockchains which don't need proof of resource, they're based on voting and secure certificates and maybe other crypto techniques, but we cannot do majority voting when there is no network. So that's not really an option to either. And so we've been looking at a structure that allows branching. So Vecfuser is the name of our project, it's Icelandic for Wayfinder. And so in our case, we have a directed acyclic graph of blocks instead of a linear chain of blocks. So this DAC maintains a full causal history of events but it's maybe not super appropriate for cryptocurrencies and that's not really what we designed it for in the first place. So we do want some important properties. We do like in a normal blockchain, we want that if a block is added that you cannot remove it later, right? We wanna use it for accountability, like in that example, we cannot have blocks once added being disappearing. And for integrity, we also, that's pretty simple. Each block is actually gonna be signed by an authorized principal. So if a node is correct, here's a picture with maybe four nodes, blue, green, yellow, and red that add blocks to the blockchain needs, sign their blocks, if a node is correct, they all need end to what they think is the end of the blockchain. And so it should never be the case that blocks from the same node should be on different paths in this DAC because that means they would add them to concurrent paths in this DAC. So this is a, here's an example of a valid DAC but if you, for example, have this situation where the red node has created blocks on different branches of this different paths in this DAC, concurrent paths in this DAC, then that's the proof of misbehavior. In order to make sure the blocks don't disappear, we have also something called the proof of witness that can take on many forms. So for example, the proof of witness maybe that at least K plus one nodes have seen a block. And that would protect you against situation where there are K malicious nodes that then remove the block from the blockchain. So block will survive if they're more than K what we call witnesses. So different applications can use different policies as far as that is concerned similar to how many blocks or how much block needs to be buried in the Bitcoin blockchain. But basically it's application dependent and once a block is witnessed, all its answers to blocks are also witnessed. So there is a good research question around, what really makes a good witness in this case? And I'm not gonna answer that right now. So when you have a DAC like this, you can count how many devices have seen a particular block and I've labeled them here, the left most block can be seen by all four devices, whereas the right mode block at the moment only be seen by one device, the red device. So you can count how many witnesses a block has and based on that you can set a policy on whether you trust the data in the block or not or trust it to remain to persist. So the different devices may have different views of what this block DAC looks like. And so they're gonna gossip with one another, opportunistically when different devices are within communication range, they're gonna try and reconcile their block DACs much in the same way that Martin does described. And we have very similar protocols with Bloom filters and actually a few others that we've tried out in order for devices to efficiently merge their, there are DACs here, there's three DACs on the left that are then merged into the DAC on the right. When those say those three devices are in contact with one another. I have on the left, if you could just a little hard to see those dash boxes, those are the blocks that are the same, the other blocks are unique. And then when you merge them, you end up with the DAC on the right and here on the right also there's a new block added that the green device has witnessed all those three versions of the blockchain and merged them. Okay, but it's a DAC. So we have a little bit of a problem, it's not a chain in the chain. If you have sequential, some kind of sequential specification of what your operations do, you can compute what the state is, how does that work in Vecfusur? People have mentioned it over and over again in the session about where he is in CRDTs. So CRDTs require that concurrent updates can mute essentially, it's a little more complicated than that, but that's the basic idea. And so it allows separate notes to be updated independently. And then when these reconciliations happen, we can come up with a semantics for what the merged state is. So here's an example of a CRDT to PSET, which is a set from which you can add elements to it, you can remove elements to it, but removes when over at, if you remove something, it can never be added back in. So the state of the two-piece set is the add set minus the remove set. When you put that in Vecfusur, you actually get this graph of these two-piece sets. And then you can actually do a little better, that is concurrent removes when over adds. But if somebody adds causally after a remove, then that add will actually win over the remove. So you can add things back in. So we have add and remove, and with the well-defined semantics, set semantics that makes sense in the system. So just a few words about Vecfusur itself. So it's the blockchain and then there's a state machine that's similar to the EVM, I guess, but it operates on CRDTs. And the operations are applied to the state machine, once there is a satisfactory proof of work of witness. We have a special two-piece plus set that maintains membership in this system. So you can add members. And this is on the first CRDT basis usually. So you can tell, you know, you can add members to do certain operations on a CRDT or remove them. And this is more or less a capability-based system. Some other nice properties. So yes, you get a cyclic growth. We can limit branching. So the deck is more or less, you know, it's pretty thin. That's because of the proof of misbehavior. So we do temper-proving using the proof of witnesses. We also have a checkpointing system. You can read about that in the paper. I have a draft of a newer paper if you're interested. I know we submit it to this conference. And then there's also a rate limiting protocol in place to deal at least partially with the Nile of Service attacks. And so that's where I'll conclude. So, you know, this, I think dovetails very well with the two prior talks you heard about. It's a Vecvis or is a blockchain-like system that works in network constrained environments where there may be petitions. It's not, we didn't introduce a DAG in order to get high throughput like some other blockchain systems. We introduced the DAG because we wanted to allow for petition operation. That's the only reason we have a DAG. We have the proof of witness and proof of misbehavior, causal CRDTs that give you nice semantics over the data that's in the Vecvis here. And we have a prototype available if you want to experiment with it and run some Android devices. That's where I'll stop.