2 3 Authorization of messages in contracts

so far we talked about the memory layout anatomy of transaction let's talk about how to authenticate the messages in the contracts and in this lesson I would like to talk about four different categories of authentication first one would be a simple classic authentication with a signature as you recall any event in the ton um blockchain should start with an external message and external message is really not authenticated by itself it's just a bunch of data that arrives as a message into some contract and usually U the external messages land in the wallet contracts that belong

to each user so if you look under the hood what the wallet does is really three things it stores ton coin balance for the user it stores the sequence number uh that it uses to prevent uh replaying of the messages and it stores the public key whenever the external message comes in it reads off 64 bytes of data that is the signature for the rest of the message verifies the signature with its public key and then treats the rest of the message as the instructions to send the messages to other contracts internally inside the blockchain

so that's really the only job of a wallet and you may have some other systems where we have a similar pattern where you receive the raw binary data as a message check it signature and then process the rest of the data one thing to note is that this is uh something that you really want to reserve just for the Wallace because your system becomes more composable and more flexible if you build the rest of the communication between the contracts using internal messages and this is where the second authentication mechanism comes uh into play and the

second mechanism is the authentication of a message sender all the internal messages in ton they are identified by a message sender that is guaranteed to be correct and secure by the ta uh protocol so every time a contract receives an internal message it knows for sure from which other contract the message was received and this is immensely more cheap and powerful than checking the signatures first of all you not limited to uh the humans who could make those messages you could also plug multiple contracts together in a pipeline so for instance you may have a

token that has an owner and this owner is specified not as a public key but as another contract address and now in most situations this contract address could be a wallet address and this means that the token can be updated like its owner could be updated by the message from this wallet but equally this address could be an address of a multi- signature Vault or it could be an address of a decentralized exchange that owns this token so really authenticating your messages by a sender gives you immense flexibility in terms of uh who could like

access your application or your token so how authentication works exactly here well it's pretty simple in the Handler that receives the internal message you simply check the message sender and you know that the rest of the network provided you with accurate and correct message sender so you simply compare it it with whatever address you store in your contract State let's say you have different trolls admin and manager and operator and for each of the those RS you have separate slots in your storage and separate addresses and so you could compare your message sender with one

of them to determine which role um is triggering this message so this is much cheaper than checking signatures and much more flexible so what are the other two interesting ways to do the authentication the third one is building on top of the message sender since uh the addresses in the uh tone ecosystem are not simply unique identifiers of the contracts but they're also cryptographically secure hashes of the contract code and data and more specifically initial code and data so they don't change when the data changes and since those addresses are cryptographic commitments to this code

you could verify what kind of code is talking on the other end by checking the message sender and this allows you to do something uh what I call the DNA check so if you look under the hood of tokens and we'll talk about them in the separate lesson then you will notice that there will be contracts that have identical code but different data and they communicate between each other and the way they authenticate this communication is by checking uh not the exact contract address but they check that whatever data they have um it's attached to

the same codee as the current contract has which means that the contract can trust that the other side the sender of the message executed their part of the protocol correctly so the contract effectively could mix up on its own end some data and the code that they trust computed on the Fly and compare it to with with an actual message sender and this way authenticate that the sender could have any data and maybe any address but they have identical code and and therefore identical DNA and then they therefore they could trust each other so this

is a very powerful pattern that we'll talk about about more in more detail in the next lessons but this kind of shows you what you can do with a message sender in your own contracts and finally the fourth type of authentication is uh something not to forget about it is a lack of authentication at all this is quite interesting isn't it in secure to not authenticate the messages well in certain situations this is where the security actually lies let's say you have a system that must be censorship resistant let's say it's a decentralized uh staking

pool that needs to do payouts every once in a while and someone has to trigger the message to start the payouts if that message was authenticated with a public key or some contract then uh this means that there would be a single op operator that controls the access to the payouts and that would be bad from the censorship point of view now what you could do for such a system you could create a message Handler that doesn't do any authentication by Design and maybe you know protects itself against denial of service in some other ways

for instance the sender of the message needs to pay the fees for the gas but we don't really care about the cender and we allow any computer or human to trigger this message and this is a deliberate design decision in your application to choose when to not authenticate messages and think of this as a way to say anyone in the world can be an author of this message and this is also an important pattern that that comes into play if you build truly decentralized applications so to recap there are four uh types of authentication in

ton there are signatures to authenticate external data external messages from uh actual humans or systems outside the blockchain there are authentication by a message sender in the internal messages to differentiate different trols and this is a more recommended way for complicated contract setups because it's more composable uh third uh type of authentication is the DNA check where you compute the necessary message sender address on the Fly uh by referring to the code and or data that you trust and finally there is lack of authentication at all to provide censorship resistance to your [Music] application