 So we have a couple of questions here. Like I said, for the presenters, if you guys could think of potential questions to ask each other, that would be great. The general question was any application examples that could use BEC? Yeah, so the way I came to presenting eventual consistency along with Heidi was coming from collaboration software. So I work on sort of Google doc style collaboration software where several people can work on a document at the same time. And one question that came up there is, well, even if we have several people who don't mutually trust each other working on the same document, can we ensure that nevertheless all of the collaborators will converge to the same state? And we realized that, yes, we can do that and we don't require any consensus to do that. Collaboration is where I came from, but I think the set of apps that you can implement with BEC is much broader. So I would say all sorts of social networking and messaging apps where you have several people contributing to some kind of discussion thread or some kind of structure or liking updates or posting stuff and so on. All of those things should be invariant, confluent. There's no particular constraints that need to be upheld there, other than basic permissions that's like access permissions are fine under BEC as well. Also, there's a whole class of sort of enterprise apps. So the types of systems that companies will use maybe internally or maybe for coordination with suppliers or clients in a customer relationship management enterprise resource planning, all that sort of stuff, recruitment systems and so on. All of those are at the moment implemented with a centralized database. And I believe most of those would also be amenable to BEC so they don't really have any invariants that are not confluent, as far as I can tell, apart from sort of like, there's basic stuff like uniqueness of primary keys and stuff like that. You can easily get around that by using hashes as primary keys, for example. So then the need to maintain uniqueness through some kind of constraint goes away. Good question. For Martin, maybe you said it, but I missed it. So I'm actually not entirely sure what you mean by Byzantine eventual consistency, do you? Have a definition for that? Yes, I try to put a definition in the talk. It's defined in terms of five or six properties. So what one property is the liveness property that I talked about, which is that an update is eventually received by all non-crashed clients. There's a convergence so that any two clients or any two nodes that have received the same set of updates will converge to the same state. And then this preservation of invariants and then a few more technical updates. We actually have a causality property in there as well. So you can ensure a causally ordered broadcast, essentially. Right. So it's similar to eventual consistency, which actually, frankly, I've never really completely understood the definition of, so this applies to the Byzantine nodes or the non-Bizantine nodes, the correct nodes? Yes, because we can't make any statement about what the Byzantine nodes are going to do. So we can't say what their state is. So all we can do is make statements about what the correct nodes do in the presence of arbitrarily many Byzantine nodes. Byzantine nodes could still propose values that could get accepted by the correct nodes. There's also not much you can do about that, I guess. Exactly. So Byzantine nodes can generate updates like anybody else because you don't know if a node is Byzantine 40s, so. Okay. And those updates will propagate through the network just like any other updates. The key thing we want to ensure is that, for example, if a Byzantine node is Eve is syncing with Alice and Eve is syncing with Bob, if Eve is Byzantine and Alice and Bob are honest, Eve should not be able to make Alice and Bob inconsistent with each other. So the Byzantine nodes should not be able to somehow mess up the state of the honest nodes. So what makes a good witness? And then also, are there any results with regard to battery life impact on the Android prototype? I mean, so yeah, what makes a good witness? And this is a tricky question. So I guess it depends a lot on the application and each witness brings a certain amount of trust in that that block is gonna be maintained. And now witnesses may be independent of one another. If those witnesses are independent of one another, you can simply add the various levels of trust and you get the total amount of trust. If they are, however, suffer from dependent failures, maybe they collude if they're malicious, then that computation is not so simple. So one thing that we've been experimenting with is like the notion of like sort of real life witnesses. Like what makes a real life witness? Well, the person has to be in the same place at the same time as the event that's being witnessed. So if the events like in a digital farm situation involve sensor readings, maybe they're simply nearby sensors. Of course they have also then more likely you would be having dependent failures. Something that another thing we're looking at is that's maybe orthogonal is using secure trusted execution environments like arm trust zone, which we've experimented with but haven't integrated into the VECSR prototype yet. We have done pretty extensive measurements of battery life with our protocols and it's in the paper draft that we have. There are various graphs that, well, at least one that I know of that deals with like the drain on the battery for the protocols that we use. We compared a little bit with sort of other kinds of more traditional blockchain algorithms, but it could be argued that that's not exactly an apples to apples comparison. But we have those graphs, like the longer the transmission range, the more you reconcile, the more updates there are, all that costs power. A lot of it is negligible compared to the amount of power that your screen on that device draws. So it might be a much cheaper than having your screen on. Patrick, how does your analysis compare to the great key IS and Leonardo's thing I pronounced and that's probably wrong, Bitcoin backbone and then he learned to the paper and then Marco proceeds to say, they say regarding VA, we observe that Nakamoto's suggestion falls short of solving it. Patrick, I know you say it's been a while since you've read their argument, would you mind expanding up on a little bit what you wrote in the chat? Basically that paper was the, I know the first one to give a very convincing model of here's what Bitcoin is doing and that was very good and that's a 2014 paper. My concern with this paper is that as Marco said, it doesn't actually, it says that Bitcoin is not solving VA but then it kind of is almost solving VA. My concern is that this is not the turn we should be taking. Actually, if we want to keep the nice properties that Bitcoin offers and we don't, I would argue we don't exactly know what those are but these are very desired in today's world as is evidenced by how things are. We should be going in the other direction and actually try not to be accidentally solving atomic broadcast because that comes with a bag of technical theoretical problems. And one thing that deserves me in the papers that they're actually doing the opposite even a step further because they then implement an atomic broadcast algorithm using their protocol, their model of the Bitcoin protocol. About the witnesses, I didn't quite catch the purpose that they served. Is it to make sure that an update that has been added to the system cannot be removed again or something like that? That's exactly the purpose of a witness. Yeah, so each witness brings you a little extra guarantee that the update won't disappear. And it's an application question and how much is enough? And this is not completely dissimilar from the finalization question in Bitcoin. How many blocks does another block to be buried before you trust it? So we leave that as an application specific issue although I think it's actually pretty interesting issue in general and I don't actually have a great answer to what makes a good witness but we have some ideas. That makes sense, thank you. Thank you, Robert. Thank you for all of our presenters today for this session that wraps it up.