 Thanks everyone for coming we'll have now a workshop on formal verification of smart contracts and maybe before you jump into the topic so how many people have done any form of verification of contract so far maybe raise the hands so very few so I guess all the remaining ones will attract it by the last part that's supposed to be easy and hopefully by the end of this workshop everybody manages to you will have a hands-on exercise and everybody should be able to verify some formal properties on contracts so the people that will be doing the workshop we have a dimeter there is a student is joining change security now backgrounds in a form of verification and problem analysis then we have also until primitive so here's the developer of the very far that we'll be using today in the workshop also Hubert was sitting back there city of chain security and myself as well so who we are we are a chain security we are a spin-off from ETH Zurich ETH the University of the Foundation based in Zurich Switzerland and we focus on the blockchain security we have worked with many blockchain products so far we have done over 80 audits not only smart contract audits but also protocol audits platform audits as well as a couple of very visible EIPs I think many people are recognize the chain security name from you know some of those EIPs that we have reviewed in the past and so yeah we also have quite a few R&D security products with platforms such as Ethereum Foundation, Polkadot, Zilliqa and few other blockchains where we focus on building security tools you know tools for finding bugs as well as form of verification tools for these platforms all right so as far to do our work we have done quite a couple of systems so far so I have listed some of those some of them on this slide here and so this is the aim to achieve different goals we typically combine techniques from various different domains such as static analysis dynamic analysis we also use quite a lot of data-driven techniques for machine learning to you know to build these systems so some of you are familiar with the Securify this was the first system that we built back in 2017 it's a system for finding generic vulnerabilities in smart contracts and yeah so that's was basically addressing all these bugs that were popping up regularly every couple of weeks in 2017 in all these you know parity audits and many other contracts so this is what that system was addressing and so this system along with other system I think they made a difference in the sense that 2018 we actually saw much fewer hacks because of such generic like really simple boxing contracts so another system we have built is we have a fuzzing system that addresses the problem of ensuring functional correctness so we're going to talk a little bit more about what functional correctness actually means and we have a fuzzing system that's essentially generates transactions and tries to find violations of the specific security properties that we're trying to check for the smart contracts and the main system that we will be talking about today is the Verac system which is the first automated verifier for verifying smart contracts this we have a demo on Verac.ch we have set up a few other instances of this system that we will be using for the exercise later today and for people that are interested really in depth on how that system works what guarantees it provides so we also have a research paper which will appear at the IEEE symposium of security and privacy so that's one of the main security conferences one of the main academic security conferences so if you go on our web page www.chainseq.com and go to research you can download the PDF and read all the details about the verification technique that is being used in that system so before we actually do I will you know go into the hands-on exercises it's important also to mention why are we actually doing this and the main reason is that's I mean when I initially asked how many people have verified contracts I think there were about two three hands and the reason this is that you know formal verification used to be this very difficult time-consuming task where you have to be really an expert in formal verification have a PhD in logics and so on to prove that a contract is correct and if we are to make formal verification mainstream you know a lot of developers also adopting that approach then you have to be building assistance we have to be building systems that allow people without this background to write functional specifications and prove the contracts correct and that's exactly what this very very very far aims to do so it eliminates this necessary needs to know in-depth knowledge of formal verification and takes down this reduces also significantly the verification time because as we will see it's really not a very hard task to verify contracts with such systems so with such a system if you take something like a standard ERC-20 token which will look in-depth in the exercise you can literally do a full formal verification for all the main properties you would care about a token in a in a matter of couple of hours and be done with the verification effort. So I have listed here some of us some some of them that we have verified we have more on our main web page www.jensivirid.com or you can find some of some of these reports where we have done proper full verification of those. Alright so the workshop will continue as follows so we'll start with some very more high-level introduction to what functional correctness means and why is it challenging to formally verify properties with functional properties and what are different techniques that's different tools that are introduced in that space what how they different guarantees then so also we'll cover here of course the break system and then in the second half we'll switch to a hands-on exercise where Dimitar will walk you through how do we specify properties and verify them with a verify like verix and so we also have many other people from the chain security team back there so they will be assisting you while doing this exercise and then in the last part depending on time we'll try to get into some more detail about the actual verification methods and how this is being automated by the verix verifier. Alright so let's get started and functional correctness so what is functional correctness so usually when people think about security tools they're these kind of tools where you just paste the codes and then they show you a bunch of on the reasons are found so this is not what we're talking about here so we're not looking for generic vulnerabilities we're talking about functional correctness and what this means is that the problem of functional correctness has two parts so one is you have the smart contract that you want to prove that you want to make sure is correct and then the second piece of information that you need is the functional specification of a smart contract so what the functional specification is that this is the thing that this defines what is what is the intended correct behavior of that smart contract okay so to make this a little bit more concrete here on the left imagine you have a smart contract a typical year C20 contract so you have all these standard fields like balances, total supply, owner, a couple of functions that would allow users to transact for the contract and then the functional specification typically consists of requirements such as the sum of all balances equals the total supply okay so to give you this specification says that all the tokens are assigned to users somehow there are no missing tokens on a site to not assigned to any user another common example is that often tokens are invincible meaning that you can increase issue more tokens and often you want to ensure that only certain users can exercise this functionality and you want to make sure that if the total supply increases then that was triggered by a transaction issued by the owner of the contract okay and then typically you will have a huge list of those requirements that you will have to you will have to check that whatever the implementation these functions is it is correct with respect to these functional requirements okay so technically how does how do we actually check that the code is correct and they're roughly speaking two steps so the first step is well to essentially transform these English description of correct behavior into something that's to take them down and to specify them at the level of the source code okay so for instance if we take the first requirement that says that the sum of balances has to be equal to the total supply then this is written in the specification language that we'll be using later in the exercise of the very self specification language and this is how it will look in the actual specification language so fairly intuitive there's a seed some keyword point to the mapping that we're trying to sell and then we have a quality with the total supply okay so that's that number one it's inevitable you know we have to be able to transform any state what the property means and once we have formalized it then if we have a particular state of the smart contract then we can check the whether this property holds or not all right so for instance if we look at the state where we have two users having balance 50 each and we have total supply 100 and then the property holds that's that's what it says and here would be an example where the property doesn't hold because the sum of these two balances actually exceeds the total balance specified in the content okay it is clear so that's step number one define the property step number two is to actually check that this property holds for all possible states that your contract could reach okay now what does this again technically mean well once you deploy the smart contracts on the blockchain it is always initialized by the deployment script so it would end up in being some specific initial stage so that's what these days and you would have to make sure that the property goes there so for instance you deploy and then for that initial state the sum of balances will have to be called the total supply okay that's one then the next thing is that once deployed the users could send would send a transaction to the smart contracts and each transaction would modify the state of the smart contract so they can for example submit a min transaction with different you know different values as arguments and so on and let's get a little bit more precise what these arrows and boxes here represents so what these boxes represent is the actual state of the contract and the arrows are the transitions that are triggered by the transactions submitted by the users and how are how is how are these transitions defined this is defined by the implementation of the of the functions in the contract so for example if we have here the issue we start from a state where total supply is a hundred we have an owner user with address X10 and then we have two users with balances 50 tokens each and then main function is defined such that it would increment the total supply by the number of tokens we want to mint and then it will assign the new tokens to the to the owner to the owner of the contract so here if we have this mint 100 tokens issued by the user basically the total supply would be incremented as defined by the function and then the balance of the owner who has address 0x10 would be incremented from 50 to also 100 because that's how many additional tokens were issued okay so that's what these arrows here mean all right so here comes immediately the first in all immediate challenge when you talk about functional correctness is that even if we want to consider whether the property would hold after one single transaction after the first transaction sent to the contract that already gives you so many different transactions that you could that would be that would have to be accounted for that it becomes infeasible to brute force it's not possible to ignore these transactions and to actually check that in all these states the property would always hold and that's challenge number one and we cannot stop here because after the first transactions the user would send it second third and so on transaction and in fact there's not a predefined bounds on how many transactions this contract would process in this lifetime so we would have to consider unbounded number of transactions if we are to formally verify that this property would always hold okay so there are two fundamental challenges here so let's very quickly go over what are different techniques that could be used to address this problem of checking these formal properties and how they different types of guarantees and so I ordered a basic unreliability so starting from least reliable going towards more lab more reliable techniques well the bottom we have the manual review so always a human can look at the codes understand what it does and try to find violations so this is basically penetration testing we have the property and try to try to have the contracts and the disadvantage here fairly well known so it's a time-consuming problem even if you have especially if you have big contracts that would take a while for for the security expert to understand exactly how these things how how the functionality of the contract is then let's move over to more automated techniques so next level would be to do some form of automated testing and then primarily in general for software but also in the space of contracts to techniques for testing contracts so one is based on buzzing and the second major technique is tools based on symbolic execution so let's briefly see what this what these techniques would do to this problem of checking functional correctness and so starting for fun with fuzzing here's basically what's happening so fuzzing is a testing technique or a fuzzer would generate random transactions and then it will execute the transactions on the contract and by doing so it the fuzzer would observe different different states of the smart contract all right and by doing so we can for all the states that have been observed after processing these transactions that we generate we could check whether the property is violated or not if it happens that we reach a state where you get a violation then the fuzzer could also return that sequence of transaction that triggered the violation and the developer could see you know reproduce the buck and try to fix it there are many many fuzzer have been deployed that are available online that do exactly this this thing the challenge here typically is how to generate transactions in a smart way so you get very high coverage over at least a very high code coverage over the contract which is already pretty challenging and contracts which tend to be very stateful have complex preconditions and so on. So what fuzzing would not give you it would not give you this full guarantee that's why it's a testing technique because inevitably there will be some states that you would not not observe simply because the fuzzer did not generate that specific sequence of transaction that would transition the contract to that state so it's a testing technique essentially. Now symbolic execution that's something different symbolic technique that it is based on this symbolic execution technique it simply would not scale to reason about such depth of transaction so typically if you use a symbolic symbolic tool you would give it a timeout so it would run for maybe 30 minutes one hour and then you would stop and then it would reach certain depth so it is better at this kind of breadth exploration and but if the bugs are hidden deeper like after 5-10 transactions which could happen even in simple contracts like crowd sales where you have to transition to for example do some refund phase where you exercise and refund functionality but these typically tend to be somewhere lower that are harder to explore with symbolic tools. So I have listed here some of the open tools that are available that's to do this. Okay if this clears so far if there are any questions just raise your hand and then we can also go into a bit more detail. Alright so that's testing and then the highest level would be the conformal verification what this workshop would be about and this is really the point where you have a flip from testing to full verification meaning that you could actually prove that this property for whatever sequence of transactions you would make it would always hold no matter what. There is a major flip that happens at that point. Now so just visually what this means is that you will cover all possible states essentially and if you would check all of them and if you check more all of them you have this full guarantee. So that's what the variant system does and you will be using it soon and the input to that system is as we saw the smart contracts as well as the specification because we're dealing with functional correctness here and the main thing of that what the main thing that Verix does is it fully automates this process of fully automating the process of verifying in a sense that it's if it's successful it verifies the property it can guarantee that it is fully verified and if it fails to verify the property then it doesn't give a guarantee whether the property doesn't work or not. Okay so it could be that you have to help a little bit to actually verify the property or it could be that the property is violated and then you have to fix the contract. So we'll see some examples during the technical exercise later. All right so to give you a bit of so something that we actually spent quite some time is to ensure that Verix has a very intuitive and easy to use specification language because that typically is one of the bottleneck when we talk about functional correctness because again to use functional correctness in addition to the contract you have to write down what the contract is supposed to do and if this is very hard and tedious to specify you you know you would end up not really using the system. So I will give a few examples of specifications that we have seen to very frequently appear in real world smart contracts so this is something we just observed during audits and verifying contracts and so this is this is literally what the specifications are so you don't have to write some elaborate scripts or something very complicated to formally state a property. So common properties are things like access control where you want to ensure that certain functions can be involved by particular users for instance is saying that in always in the contract if there was a transaction to deposit then that was that transaction was made by the owner of the contract. Another common pattern that we observe is that very often it's not about who is sending a transaction but it won't in what state the contract is so for instance here we say that if the current time exceeds the refund time by a week then users are never no longer allowed to submit refund transactions. So yes state machine properties as well so again contracts are very stateful there is explicit state variables that define how the states how the contract can transition into different states so you have to make sure that these transitions are encode are implemented correctly in the contracts. We saw that example earlier as well so we have some over basically aggregations over mappings and arrays are also tend to be pretty common so that's we have added this explicit keywords in the language to allow users to to write these properties and another common pattern is that so typically if you have a project it's you don't implement the full product in a one contract but in several contracts and often there are certain invariants that so some sort of dependencies that are exist between the contracts and their properties that's captured these dependencies so you have to verify that they are implemented correctly in the contracts. Okay so again you will be writing some of these specifications so a bit more technically for people interested in logic so the specification language is actually based on something on a fragment of temporal logic which is very well studied specification language it goes, it takes decades of research in this so it has very well understood complexities and expressivity and so on. Alright so I would also like to depth on how how the verifier actually works but intuitively it combines two techniques one technique is it does use this symbolic execution technique which is very good at handling dealing with many different concrete values that you could submit in transactions and then to deal with the unbounded depth that users would submit it uses something called predicate abstraction that allows it to fully capture all the possible like this very large unbounded tree to capture it with some final representation so depending on time we may get into more details about that technique. Alright so that was the high-level intro and now we're going to transition into the actual exercise on how to use the exercise to specify this property so I'll hand over to Mitko who will introduce an example. Yes okay hi I'm Mitko yes and now we continue with a kind of small exercise how to use a verix. By the way if you have any questions at any time just raise your hand just speak and we can ask the questions the goal here is to make the exercise more interactive and not so kind of formal. Okay so so the first step in any kind of formal verification is to actually specify the properties informally. This means that you specify them in natural language whether it's English or some other language you just need to have some clarity over what this smart contract wants to do. And in this exercise we'll look at two main conflicts one is ERC-20 Tolkien and the other is kind of standard crowdsale of course simplified because we don't have too much time. Okay so first we'll go over specifying functional requirements informally. And when we go this is kind of fragmented of ERC-20 interface and for those who kind of are not so familiar with it the contract has let's say three main functions one is total supply how many tokens are in circulation. The other is balance of you can query how much tokens given address or account heads. And the actual main function here is the transfer function where the sender of the transaction can transfer some tokens from its own account to the recipient. So we have the address of this recipient's account and some amount of actor or any tokens sorry not actor but just tokens that want to transfer. And now whenever we are specifying behavior of contracts we do it over the contract and not over the interface. So here are the relevant parts of the actual contract right so the functions we have the balance the total supply and balance become fields of the contract right so these are not private fields. We have total supply as a mapping which says for every address or account how many tokens this address or account possesses right so this one is just an integer and this is a mapping from addresses to integers. And here we have some specification function transfer. Now when we're thinking about the contract or just specifying its correctness at least as a principle when I'm doing these things I never look into the implementation right so for me the contract is a black box and that's why I specifically omitted the body of the transfer function right. So now the goal is to just come up with a couple of properties hopefully full set of properties that specify the whole behavior of the contract. Okay good. So let's do this a little bit more interactive. First property is on me right so we already saw it actually and it says just informally in English total supply always equals the symbol power. So this kind of specifies an invariant meaning that it holds at all states of your contract something that you'd like to hold right and all we need to specify invariance about the transfer function right. So suppose you start the transaction with a given transfer function you have a specific recipient and specific amount and what would be the usual case of transfer? So I would say the amount of the sender needs to decrease the amount of the recipients needs to increase by the amount the balance of the recipient needs to increase amount and the total supply is not allowed to change. The total supply is not allowed to change yes you're right yes so this is very good requirement we can allow right a little bit more so just to repeat right you decrease the sender's account by the given amount you increase the recipients account by the given amount and total supply should remain the same right but one thing for example that we will meet it is that so we said the total supply should be the same but this transfer could have transfer tokens from another account right so we didn't specify this so what we did is a partial specification right so in addition to that we need to specify that all other accounts remain unchanged it's not just the total supply and as a consequence the total supply will also remain unchanged right okay so we also do this in the case the sender's account has sufficient funds right sufficient amount of tokens if it doesn't have the function should not do anything right so the first case a little bit more elaborately right is if the message sender is not equal to the recipient right otherwise you don't have anything to do and there is sufficient amount of tokens in the balance of the message sender then the message sender's account or balance should be decreased amount the balance of the recipient should be increased by the given amount and all remaining balances should be made a change right this is kind of a fairly straightforward informal specification so what will be the remaining balance so we have one more case to do here any clue number of balances should be the same as number of addresses number of balances I mean the yes yes you're correct number of balances should be the same as number of addresses this is kind of implicitly assumed so if we go back a little this is kind of implicitly assumed we have this mapping it is kind of you continue it containing account for everybody every possible address in the world it's very large amount all the possible addresses it's really kind of the ethereum kind of language and security language takes care of this but this is a correct thing yes so what we do is we consider the alternative case right so we have this if here alternative is to logically negate the condition which means that if the message sender is the recipient or the balances are not sufficient right all balances should remain unmodified right yes I'm not taking into account our flow at this point yes you're absolutely right so when you're doing specification is very easy to miss something well also the same way as as you're probably something for example here it could happen that these conditions here are satisfied when overhaul for happens because we have more than a day here we didn't go with addition and subtraction everything works fine even if you overhaul something and the problem is when you overhaul something the actual amount is not the amount is that in general you don't take into account or just in this example I don't take it into account so what you can do with Varex is depending on your property you can specify in such a way that it would automatically fail to verify if all walls happen right but what we currently do with Varex is that we don't explicitly check for overflows right you need to write your property in such a way that it fails even if it is okay and the other thing is you can think of the specification at the informal level as referring to actual integers where there is no overhaul right this is kind of just the informal part but when you go to actual formal verification you cannot think of it this way right okay so this is informal requirements for ESC when okay now let's go to something slightly more elaborate so we have a crowd sale and the crowd sale has a couple fields so a crowd sale contract the amount of either which is raised the goal factor which you want to raise and the closing time of the crowd sale and the behavior of the contract is that whenever somebody sends money through the invest function right this is a payable function the crowd sale contract will deposit this money into the escrow right and when somebody walks close and it's about time to get close right after the close time has passed then depending on this we have two options either the goal was raised in which case the beneficiary of the crowd sale can withdraw the money from the escrow or the goal was not raised in which case the investors can claim the refund for their actor which will be set and this logic should be realized in the escrow so here what you do have is mapping your deposits how many how much actor each other is deposited in the escrow and the beneficiary who in case of success will receive all the money right so let's let's try to specify this again inform right so again let's do the first one so the goal and close time always remain same right so so this might look like a stupid informal requirement but in insularity these things can change right this keeps your contract these are stored in the storage potentially they can change so because of this we need to be explicit about which things need to remain constant or which things can change right so this is a requirement that is all often missed and people can yeah okay other suggestions right so so just to implement kind of the logic that we informally describe now in informal like no need to be very precise this close on the work if you pass sorry close only will belong the work if you pass close time close will only work if you pass the close time yes so what does this mean close will only work if you pass the close time sorry now it's larger than close time well like if now it's less than close time called close must be very successful must be done successful yes yes so you can specify this this is one option let me see what's the next property I specify here is because yes but maybe maybe it's something along the lines of close so what does he say soon no it's it's something else right so so here just for the sake of the workshop I have the properties fixed so you are welcome to say properties I will not have them to the slides here we just work with some things as the properties and property be yes a similar investor deposits equals the actor in escrow unless success right so this means that you cannot withdraw or change money from escrow is success right okay so let's see some something more escrow never allows both withdrawing and claim the reference right so this was one of the requirements we specify and more more yes investors cannot claim refunds after crowdsale goal is reached and maybe you can figure out what would be the complement of this not compliment the complimentary or the extra property needed to counter part this this behavior yes beneficiary can withdraw after crowdsale beneficiary can only withdraw after crowdsale goal is reached yes beneficiary can only withdraw unless callable is rich you can say something in many ways so yes but it's the same so beneficiary cannot withdraw before crowdsale goal is rich right so we have these five properties now this is most likely in complete specification of the behavior of the health so providing a full complete specification is kind of difficult exercise and whenever you are verifying your contracts you don't need to do it right but this means that you should always keep in mind the possibility that you need something right okay so now we have a bunch of properties and what we can do is we can just attempt to formalize them and specify them in the verdict specification language and I okay any questions is as you're going through the requirements is you saw that if you go back to the specific interface for the contract the crowd sale there are three states open yes success and refund yes but there's there another state where the you've reached the goal it's closed but the beneficiary hasn't gotten around to claiming the thing so it's kind of pending is my question is with regard to the interaction between this code and the specification you go back and forth and change the this code based on your understanding of the specification so if you're to develop the contract together with the specification yes this is how it's going to do that right you will do back and forth like you write your requirements if you see that you miss something you change the code and maybe on the other hand you did something in the specification which is wrong and the code replacing correctly to change the specification it's so this process you can miss out because it seems like here there would be some kind of limbo state where there will be a mistake yes absolutely there will be a limbo state once the cross time has reached and is closed by the who is not called right the as problem still be in an open state and you cannot do anything basically you this is because maybe the beneficiary never gets around maybe they got vaporized and that's you know so it remains a little state forever so okay so they need to make a requirement that you can escape the state right you make a next requirement as I said specification with the PC so there is something else I need to tell what you said you can escape the limbo state this is called the liveness property and flags actually cannot verify liveness properties they are different techniques and what we focus on properties of these kinds which are called safety properties yes but I'm not getting too much detail about this yes this kind of a reverse shouldn't you have the formal requirement first before depends on your style how they how develop the code right so some people prefer to write the code so they understand the problem you might better and then develop the specification some people try to develop the specification before they understand it also if you're providing an audit service you're not writing the code you're you're hired to yes this is what people in chains I do yes they they don't touch the code or they give suggestions about the code to change but in general yes we do write specifications sometimes based on the code sometimes based on the requirements given by the clients yes what about the investment function in this yes after the goal is reached whether you can invest after the goal is reached it should not be possible you should not be possible to invest once the crowd sale ended in some way yes absolutely I said the specification is incomplete right right so ideally you'll get a complete specification but this is an open-ended process requires something okay so this one the whole point of this is to emphasize that before you start with formal specification it's good to have informal one right just to have a clue what you want good so okay let's move on verify things with Variks we'll try to formalize these properties in the specification language that Variks supports and see whether they verify or not okay so how things get into the specification language and Variks is based on something called linear temporal logic so this one sounds scary but it's something very natural so let me try to just give a brief explanation so maybe most of you are familiar with classical logic this is our everyday logic that we use and you can express formalized properties for example the age of values was the age of what is even right so classical logic defines the relations between individuals in this case the relation is that the sum of the ages is even right and how would you write this formally in classical logic you say there exists some integer such that age of values with the age of both is twice this integer right so kind of to say the things are even right this is classical logic and temporal logic adds another dimension to this which is time right so things are not just statically laid out in a perfect ideal but we also have progress and temporal logic also is to define relations across states so you have usually initial state in time point zero that you have point one you have another state and so on and so on and so now you can define a relation between those states and here we just as an example such a relation says it's always the case that the age of values is even right so we've just changed the property very slightly by adding the always kind of temporal operator to express this this relation which is across time not just within the single state right so you see that this this this relation does not hold in the real world right it's cannot be always the case the ages are even and somebody the same increments age one guy increments age the same will be comfortable right so this is an example of property that does not hold because it's not always the case sorry unless they're twins unless they're twins or it's born on the same you're obviously yes I forgot so yes so just to say what you're specifying with the temporal logic what you do have is this model kind of you specify properties of traces or formally and each trace is a sequence of states right the index of the sequence gives you kind of discrete time so time progresses from zero to infinity going the increments of one right so for example this could be the zero state or some people like to come from one state and this is the second state this is the third state so this is kind of what you're specifying in temporal logic and each state we can kind of divide the worlds or two parts that the constant inside the states and the variables inside the state and as an example Alice is a person is a constant which means that it this object does not change across time Alice remains Alice in all time points right the same goes with numbers possible ages and 27, 28 what not right so these things are constant they never change the cross time and the other part of the state are variables in this example is age so variables can change across time this this is briefly kind of what the statement contains, contains constants and values right and now when we write a formula right we want to interpret some statement about time it's good to say what the mental model is and how you evaluate those things so here is a different example we have temperature right so we have states and our state contains constant is some temperature and the variable is the temperature in this state right so time could be days in this case so we did not specify it in what units the time is measured it's on the screen unit I think we want to see is this property here it says eventually always the temperature is at least 11 degrees right so we have some property and in order to see whether this is true for this trace so this is the trace right we need to see whether this is true what we do we start evaluating the truth of the sub formulas for the parts of this sentence across the states and for example the kind of the innermost part is temperature is at least 11 degrees right so now we just see at which states this statement is true right within each statement we are kind of almost like a classical logic but not real right and here we can see the temperature is 11 degrees in the first state in the third state and the last two states here so time can continue for all right assume the temperature remains at least 11 degrees forward right so this is where this part of our statement holds true now in order to see in which states the always at least 11 degrees holds true we need to look at the sub formula and see whether it always holds right so always means that maybe better term for this is has for right so we can ask the question is it always the case the temperature is at least 11 degrees in the initial state and it's not the true because in the subsequent state the temperature is 10 degrees it's no longer at least 11 right so it's not always the case that the temperature is the place 11 degrees in the initial state it's also not always the case that it's in all these states until the temperature stabilizes or let's say goes below 11 degrees forever so from this point onwards this part of the formula will devaluate to true right so it's always the case the temperature is 11 degrees and now the final kind of temporal operator you're looking at here is eventually the case that always the temperature is 11 degrees and eventually is true in a given state if there is a future state where the sub sentence that you already is right so in which states is the full sentence true that's how it is guess everything everything yes because no matter which state I evaluate this this formula here there is always a future state where it's always the case that the temperature is at least 11 degrees and this yellow light in which states it's all these I guess I don't understand the meaning of that future state because how do you know that's true or not because there's the heat death of the universe where the temperature will not be so so so this is just an example it's an example when there is no we don't know if there's gonna be a heat death or not so okay okay you're absolutely correct so for this sentence as humans we cannot evaluate but avoiding blindness properties verification problem is yes more questions okay good so let's do a small quiz just to see how this temporal logic works right and here this is very unfortunate because this should be a circle so we have two squares which is very unfortunate it's a printable character yes yes these phones don't have it anyway it's the ball square right so we use the small square to say always how do you say the diamond to say eventually and the ball square to use next something is doing the next step so what does this sentence say right you have two formulas or two predicates P and Q and this thing says he implies that eventually Q right this is what it says so how do you interpret this informally what do you understand from this okay let me help you if there's P there will eventually Q will happen yes if there's P yes so so yes I put this example just to emphasize something when we are evaluating a formula we're evaluating it always in the initial state right so there is a slight kind of something in subscale written time we're always evaluating a formula in the initial state so you're almost yes right we evaluate this in the initial state is if initially P is true then in some future moments or the current moment actually eventually it's not straight but it's all the current moment Q holds and what you said you can formalize with it's always the case if it holds eventually Q right so no matter whether it's initial state or initial state for every state in these holds okay so what about this one always eventually P you just get some alternative description of this formula yes it's impossible for P never happen yes you can play with the Morgan's laws yes yes this is alternative description is valid another one yes exactly yes so you can interpret this because we have kind of time running clean theory you say P is too effectively often it's always the case of eventually P holds but if we eventually dissolve hold in some future state it also must eventually hold so this will repeat infinitely often right and what about this one if we swap eventually always P holds yes okay I just want to talk about some more I want to describe here absolutely as if you just read some facial phrase can spell out well what it's written it is what it is this basically says that eventually P stabilizes kind of from certain moments onwards P will always hold this is always this right well we have three more so so we got into this one so what does it say yes from any state that P is true Q is true that state and every state after in every state after and why is this the case this is true you're correct yes because the always you on the right this is this is the ball square which is next but it's true actually what you said right so if you interpret this next as next right it's always the case right if people then in the next case never people never be true why people never be true because then the next state would be Q and they are not mutually exclusive I'm not usually exclusive they're not so they're just he is always followed by yes he's always followed by this is it right and all you have what you said right is if people's afterwards onwards until infinity if you would hope good so these are the more simple ones one of us I don't know why put so many but okay so this one is more complex it says it's always the case there is some constant and such that in this case the clock equals them and in the next case clock equals yes yes the clock always increments by one this is this is all these properties I just wanted so this is kind of full temporal logic right you can write many complex formulas and statements in full temporal logic code always clicks or peaks by one increment it's correct because the clock actually the time yes the clock it depends on computer clock if it's digital clock or some unique timestamp or whatever it is depends on the yeah yeah doesn't wrap around sorry okay so for for for the standard clock it doesn't work okay yes okay good so now how all these applies to smart companies right so what we do here we need to fix what time needs first first and foremost and what we do is we do the following we have world states and the world states are the states of the whole blockchain in between right so whenever you're thinking some blockchain you always around the thing inside of such and our state will be the world state of the blockchain and time increment means the execution of a single transaction right this is what we do and we don't support the full temporal logic it's about just a fragment of it which is called canonical safety fragment but they're not gone in details and roughly it looks like this you always your formulas of this form always P where P some formula of the following shape so you have logical conjunctions P and Q you have this junction P or you have implication P implies you have this very interesting operator which is temporal operator once P which means that once in the past people is holding this is the time reversal of the eventually operator so we had eventually meaning in future moment P will hold this means that in the past he was holding or the current state yes at least once or at least once exactly so it's not exactly once at least once so in some past state P was holding this is what we do and finally whenever you have some expression you can refer to the previous value of this expression so this is similar to the next operator so in the previous state the value of this expression was something right so here we were refer to the previous value of the expression these are the basic things by the way what happens in the initial state where there is no previous state what do you think so when there was no initial state just for simplicity we take the priors with the current like in the initial state just remember this I mean sometimes it's no yes yes okay and now we have some ethereal specific things because we are after all doing things on ethereal so one thing is we support sum of mappings right so in balances is a mapping inside the token contract we can refer to the sum of all these things function returns the the name of the function which is called in this transaction the top-level function right so we have nested calls we kind of abstract these nested calls away we we can refer only to the top-level transaction the function in the top-level transaction we can refer to function names so this is the syntax for referring to a function name and we can also refer to arguments of functions so syntax is a little bit improvised we're going to improve it in the future so this is the zero arguments of the claim refer function and here what you do is you do canonical name of the function so this is the name of the counter table function and here if you put the signature of the function with the addresses right this is what happens yes okay you just shout okay you shout so so we don't support specification of loop invariance so all we do is basically specify let's call it transaction invariance something that holds across those options what if we have no TV loose in the country so in some cases we can rewrite them rewrite them without loops but if you have no table loops we unfortunately don't support it yes yes I have forgotten yes there is also negation so yes I forgot the negation yes so we got this but you said earlier that you know you evaluated formula always in the initial state in classical temporal yes so what's this is the semantics different now and we know it's the same it just that we support formulas of the shape always be right not that's for the for the operators once and previous if we're always evaluating in the initial state so you evaluate the top level of the formula in the initial state right but it could happen that when you say always this means that the inner part of the formula needs to be evaluated in all states this is the semantics of the always operator so from formula to sub formula you change the point at which you evaluate right depending on the semantics of the temporal operators which is the point at which you evaluate the formula right so always changes the point at which you evaluate you evaluate in all points from the current point on this that's the idea so you evaluate formulas always in all states okay good so now let's move on to small quick question on that box on the left you have once a previous there's no next there is no next we don't support it yes we're somewhat limited but many things that you can express with next actually you can express in this way just you need to massage your formula not everything that's okay but you do you have negation there that was just I forgot yes yes we don't negation yes we require always to be the top level right so never again yes you cannot negate yeah never again yes this is always he is given by this index plus negation you always have to have always you always have to pay always sorry do you write it down yes we were writing down in the formula so it's explicit yes this is basically what you can specify is contract invariance contract invariance exactly you can say this way yes but you also can refer to the past that's that's the kind of cool thing so I'm just curious why not next I mean is there I'm not familiar with the verification technology so is there a technical reason why next is more difficult than previous so for verification it's slightly more difficult yes you need to do some gymnastics okay and when you are eventually becomes more difficult way more difficult because once you always look finite number of steps in the past because in the past time is limited is bound but in the future it's unbounded eventually things become very very infinite that's good okay so maybe you just go quit your exercises so now it's time to formalize what we need and just to love balance our very fire we have two servers in which you can run by X there is nothing using interface let's say this part of the room uses by X1 and the other part of the room uses by X2 as can we do it like this because the service are powerful but the vacations okay sorry just general is very some online too long here is it downloadable the more it It's online too. We hope to outsource it in the future. Okay, so there are two servers, left part of the room, right part of the room. And for Varex intakes, you can click this link and check out the links. Yes. Okay, so if you open the links, you'll see this kind of interface to Varex. On the left, what you have is a list of contracts plus specifications. So we preloaded Varex with a couple of contracts and currently we focus on the ERC20 and ERC, sorry, and CrownServe, right? So we have two contracts which we focus on and the entries, the surface with solution are the solutions to those exercises, right? We have three extra exercises which you can do, but maybe there will be no time for this today. They have no solutions, so you need to kind of give it a little bit more on that, about it. Okay, good. Yes. Why not to be on our questions all the time? Well, I'm wondering how do you do these state predicates? Is all of the state predicates success? Can I define one as a user, for instance? As a user? Okay, let me, maybe, maybe, yes. No, no, no, no solution. Let me use. So you give a list of formulas, later we'll talk about the remaining formulas, but what's important is the first formula. So the first formula gives you your problem. And it has this formula, O is, and then some formula. So whenever you're specifying something, and then you have a table which gives you more details, the syntax, and for example, you can refer to contract fields using contract block fields, right? So you can refer to the contract state this way. I forgot some of the syntax details, right? Also, you can refer to message sender, you can refer to the current time, the time in this world state. I forgot the block. Yes. So, let's see. So I guess I don't see an end on the state predicate. State predicate's very meaningful. In some, are these in the state? I, I guess it's like, it will try, like, actually, if it's double the quality of the state, right? Yeah, I guess, I guess, yeah. Ah, yeah. There's a lot, there's a lot. There's a lot, there's a lot. There's a lot, there's a lot, there's a lot. There's a lot, there's a lot, there's a lot, there's a lot. Yeah, you have an example with like success or refund, that the state predicate's on the success state, or even on the state, or something like that. Ah, okay, okay. Yes. Okay, let me just give you a short demonstration about the first property. I thought of why OEC equals the same imbalances. So. Okay, so, yes, Petter will write the first property, right? This one is simple one. Say always. Talking under the same imbalances. So it's the case that the same imbalances equals the total supply. Yes, this is it. And if it goes scroll down, there's a verify. What's a verify? You see on verify. And it's a point in front. Verification takes some time. You see that the property, the first one is cute, which means it's a pending state. It's not know what a verify is or not. And the other problem is failed verify. So you need to verification takes some time. So you cannot, it's not how to say a tool where you get immediate feedback, you just verification takes some time. I don't know about your approach to that. Why does it take so long? It takes so long because we analyzed the vital level. And the very small problem you heard about yesterday, does it very small. Very small is a tool from Microsoft. It verifies it on the last time symptoms, which is kind of the high level semantics. And then it can be faster. Does that mean some op codes are supportive, or does that mean somewhere before, at the moment it was in your paper I was reading it, but that's the reason why there was... Delegate code, for example, is unsupported. There's some op codes that are unsupported. In some op codes it's unsupported. When you have delegated code, it's very easy to break any property. What would you say?