 I'm Sasha, and I'm going to talk about protocols and sort of their technical and philosophical implications. So what I do, I do protocols that I use, which mostly I take scientific research and try to make reasonable protocols available. This track is called BMS Messages, which is all about exploring technical and philosophical implications of the tools we use. So I'm going to talk about the sort of implications of the protocol design. I've been looking at protocols more like an abstract thing, not so much as an actual limitation of what it's in the protocol. And the name of the talk is inspired by a great book by I think it's something out of the way, which is called, A Protocol or Control. This is out of the simplification. So there's one first technical aspect of whatever you want to try to build any sort of open system, you most likely want to get around building a protocol. If you want any sort of interoperable system, it can be done at all, which is sort of a bit one way where the protocol, the code that is written in the middle of the D, can be very explicit by the protocol simplification, and of course there can be discrepancies between aspects and communications. And then there's the social aspect of the systems we're building, sort of produce communities that produce organizations, and so it's very much an important topic to take care of when you try to build a protocol or sort of think of what sort of systems does this enable to build. And also more importantly, what sort of accidents does this new protocol enable? For example, if you build a nice station protocol, and all of a sudden it's quite successful, all of a sudden there are much, much less transactions on chain and much less transaction fees, and they might start behaving differently. And protocols are on every layer of what we're trying to build, an application layer, you want to build an automobile service, you probably want to build a protocol, you want to build a project, you want to build a protocol, you want to build it, it's like an off-chain market maybe, you probably want to build a protocol as well. So you're very welcome. Where does protocol come from? I think most people that I've asked, which are not technical, when I asked them what is the protocol, they had this notion of it's just like a report of things that happened in the meeting, which was also sort of the earliest in which the ancient Greek word first came from. And then later it became this very modematic thing where in diplomacy, you have sheets of protocols and things like that which try to give the social framework to human reaction if you will. And the sport here is sort of really nice because it impacts very well what the protocol is. On a social level, the same thing applies to a technical layer as well. So the protocol is on an end, in itself rather it means that which people who are coaches can relate to each other, the loss of freedom of concentration and the contribution to society or personal and professional, the protocol is, in effect, a frame of the picture rather than content of it. Which in a lot of sense, it basically provides a surface instead of describing the actual content of what's going on. The sort of thing that protocols do is they sort of facilitate network building. So protocols provide the conditions under which networks can be formed and thus they also shape sort of networks that can be built. So what an evenness, like what a protocol provides lack of services. There are instances like implementations of a service. And services, like everybody knows, for example, if you want to call someone voice calling. There's one service and there's also different protocols and implementations. You can voice call for a nightline, you can voice call via voice call IP, different protocols for the same service. And these services sort of define externally visible behavior and protocols that end the black box implementations of this behavior. So let's get a bit more relevant to the sort of blockchain content and talk a bit about what sort of protocols we have. These are sort of an order of first appearance, first recommendation protocols and then read the internet and have cryptographic codes and then in the end we have now cryptographic protocols. Then the interesting thing is that as you move from left to right, it sort of starts internalizing much more of the externalities of sort of implementing these things. Communication protocols, all you assume is a loss of channel. They are not really adversaries. Everything is nice. You're sort of a natural network or like you're an internet warrior and over adversaries. Then cryptographic protocols all of a sudden have this notion of an adversary who wants to, I don't know, interrupt your connection. They want to maybe give strong things like that. And then cryptographic protocols sort of add like the, I guess, economic dimension to it. So people care their direction in monetary incentives on monetary motivations. And what sort of protocols do we have? We have altruistic, rational, Byzantine actors. Altruistic actors, they are more than happy to follow any sort of protocol even if it means losing like a tiny amount of money or whatever or basically, yeah, that's it. So rational actors are the ones who try to sort of be selfish in the sense that they want to have the best body. So if you fit here to the protocol and then you have Byzantine actors who can basically do anything, they're willing to lose money. They will lose money to attack the chain. They will try to, yeah, just, yeah, that's it. So let's get some mechanism in the communication protocols which is, like I said, the nice and easy world where everything is good. The most famous example which is still in use today is probably BGP which is sort of the protocol which controls peering of the internet. Basically, without BGP, the internet doesn't work at the moment. And BGP sort of is a nice happy place where everybody just assumes everybody's good. There's no sort of cryptographic, at least not yet, or even economic incentive for BGP nodes to keep them secure to announce all of the other things. And at least they'll sort of make sequence controls, make an assurance or sequence, for example, by numbering current control with this loss of channel, whatever. Then you come to cryptographic protocols which come in lots of different flavors. But generally it just means any kind of protocol that considers adversary which might be like the Byzantine concept of that is in full control of the concept of protocol, but it might also be any sort of protocol using authentication and providing privacy such as HTTPS or something like that. And not all the things that are listed here on the same level, like accumulators, might use hashing and signatures, might be seen as non-prolucent or whatever, and just give the problem some examples. And then the cryptographic protocols, the interesting thing is that all of a sudden it becomes possible to punish or economically punish any participant in the protocol if they don't enter into the rules of the protocol. Which is really interesting. It wasn't really possible in form. For example, in proper state, the lead election, like if somebody misbehaves double science and you might slash KSA, and also gives you access to a big array of all of a sudden makings in design, like auction markets and things like that. You can incentivize people to behave fresh and lead to a protocol designed or whatever it might be. And it just makes in general behaving not according to the protocol much, much more intensive. It's also a nice thing for security. So the problem is that when you go to the code from a great book which is on architecture, like some architecture we live in, when you build a thing, you really build a thing in isolation but you must also repair the wall around it and within it so that the later wall, the more in case it becomes more coherent, the more hope, the things, the thing which it makes takes its place in the world of nature as you make it. So this is sort of what I think is getting messy because you cannot, even if you want to, build a protocol in isolation. Unfortunately. For example, like the current type which is DeFi applications. All of a sudden, the miners have a very high incentive to, for example, in theory, to mess with the drawing of transactions. Let's say you have an order of transaction coming in that thought they'd surprise you and you try to trade something. You try to trade on a dex, but it suddenly changed. All of a sudden, the miner has a pretty nice incentive to, like, process dex transactions before the order of transactions, for example, things like that. Or, take for example, in the mega-gau, you have a debt position, the price change is rapidly, you try to top off your CDP, basically, and all of a sudden, the miner has a very, like, sort of high incentive to get bribes from you and say, okay, if you're going to bribe me, I'm not going to have to top you off here at CDP, which is sort of a problem which not many people have addressed yet. And then there's also, like, all problems, like front-running transaction regardless, which is, this is one of the more recent papers by Fudai who gave a talk yesterday on something similar, basically, exactly what that, like, in the context of mining, where all of a sudden people realize that miners, if you build, like, any sort of protocol on top of the miners, they'll provide a very high incentive to extract more value than they get from fees or from transaction rewards. Which basically, you know, because basically the protocols which are on the high level assume that their low level is ideal, which is sort of also, like, what happened to us, like, the side channels have actually been useful, and some people realized, oh, there are more things that the CPU does that our program does not know how to deal with, because there was some sort of, like, abstraction in between, which in the end did not ask for it, it leaked into the higher days. And then there's also one of the biggest problems which nobody has really addressed, which is bribery, especially in proof of stake, sort of protocols that would be very interesting to see, or using different chains to bribe people, other chains would be really very interesting. So let's say you have a great idea for a service, you come up with a protocol, then there's resumption and then there's some other implementation. The process, like, of writing a protocol is very much similar to just normal software design, meaning it's higher, if it's very massive, you have often inconsistencies between the implementations and the specification of the writing, and lots of parts that with software are only found after implementing them, and then you sort of get to this, okay, am I going to update the code, or am I going to update specifications, especially if everything like this happens in the open, in the version where people start, like, actually using these things that are more complicated, and it's often, quite often, protocols end up being used in situations that we're never designed for, which makes things even worse. So some sort of, like, guidelines for just design and the model is always simplicity, which is more and more like you do something that's most likely wrong. Exceptions make everything more error-prone because it sort of, like, basically forces you to unwind a lot of states, and you end up in, like, quite often undefined states, which is a mess. And easy features are features both people use. So if you have some sort of, like, complicated features, it will most likely not be used, it will not be tested properly, and you will only catch bugs very, very late in the life cycle of these protocols at all. Which is then, maybe, easy thing to do. This is resistances. In general, like, I think, for a cryptographic protocol, for example, if you write a hash function, you shouldn't, but if you do, or add a hash function, so you have a signature, you really need to be able to nonsense this, and yeah, so try to make the entity doing misuse resistance, like, not real defaults, not automatically some sort of, like, data, beta, beta, whatever it be. Make everything as explicit as you can, because people will not read the form specifications. They will assume things based on what they've read, and which just leads to a lot of problems and be very transparent about the facts that the things that you're trying to, say, have. Another interesting thing, which is not really what, not really a thing yet, and then, like, many, like, blockchain protocols, but is, like, thinking about depreciation, like, what would it look like if all of a sudden everybody decided, okay, this blockchain system is now outdated as we can do to a new one, which is sort of happening from 1.0 to 2.0, but it's usually a very hard process, and there's usually not a thing people think about a lot, because, of course, when you're designing a protocol, you want it to be used in the most definitely. And then minimization, wouldn't think it's on shame, costs lots of money, leaking data is also not nice, and, yeah. So when you actually try to write a specification, like the thing that people are supposed to read, don't try to clever, please don't, repeat words if needed, because otherwise people might think there are different things, maybe just trying to be repetitive in the way you write. State diagrams are amazing. If something looks complicated as a state diagram, it's probably too complicated, and people will get confused. And then I think with sort of the state diagram or representation of other things, it's sort of easier to formalize. And in the end, the thing that you need to be careful is good balance between formalism and abstraction, ideally if you, in an idea of what you could write like a formal specification of a protocol, have it implemented automatically, put it into code, it won't be amazing. But unfortunately, writing formal specifications is really, really hard. Two seconds better, but it's still pain and trying to actually write a formal definition of all the things that you, for example, want to include in a consensus argument is not impossible. So too much formalism makes it much harder to read and implement for people, so that you have to have some sort of like strikes and sort of balance between formalism and abstraction. And probably the most important thing is if it's easy to misunderstand something, then it's a broken aspect. Otherwise you're just not going to be happy. And people will misunderstand you. Yeah, this is the biggest kind of one, it's like what happens once people use this thing, what happens once it's deployed, how do you upgrade things, and people will not upgrade, probably you would like backwards compatibility. This is really really hard, especially if everything of this like happens in the open and you basically have people, just as soon as you write something, people start using this very messy and yeah, it becomes especially like decent lessons or trying to do decent lessons, it gets even worse. Not just taking people also politically, which we've seen quite often in the human self. So to wrap up with somewhere like that research is going to have important consequences for the solution of power, and the composition of delivery cranes, they do not produce a flat or fragmented, well diffused power relations, and where the corporations normally tend to become less asymmetrical over time, instead they result in a specific tangible and enduring configuration of power balance. Meaning that if your protocol ends up being used or ends up trying to incentivize people for any kind of rational behavior, you sort of need to think about what's the long term play out of this behavior. Things are very sticky, if people can extract more information in some way else they will, and you might end up, even if you have good intentions, you quite often might end up just making things worse or just trying, not including people who or let's say people who have an actress who might be disadvantaged already, just making more disadvantage. And that's the end. Thank you.