S-gram: Statistical Linter For Incomplete Solidity Smart Contracts by Han Liu (Devcon4)

good naps number one and my name is Han Liu and I'm currently a postdoc researcher from Tsinghua University in China and I will be talking about a research work on statistic calling to her for austerity smart contracts and okay so as a normal computer computer programs smart contracts have smells such like unused function parameters or unprotected message cores and maybe a delay the update which is vulnerable to re-entrance the attack so these smiles are not not are not necessarily causing any catastrophes but these are something that you don't you're trying to avoid in your smart contracts because they may be can be stylistic Oh arrows or maybe they are not following the best practice some of them are bugs and even security issues so the most straightforward way to capture and remove this Mouse would be when the developer finished their code we can use a bunch of analyzers for example form of air fires static analyzers to check this code and see if the bad code is there and if you're doing this calmly you will need your code to be compatible in most cases and you should be aware of the create affine rules which tell the analyzer what kind of thing they should be searching for and what we're trying to do is that we want to make these checks earlier in the development lifecycle and we want it to be a interactive way which means that the developers can check their code even if they haven't finished it or even if they have no clue what the patterns look like and to realize this idea we have proposed that they a scrum framework which exploits the naturalness of smart contract code so the nationís notion is actually coming from the software engineering community which tells you that how natural or how irregular your code is with respect to a large collection of other code and so we what do we do with this nationalist notion in a scrum is that given the contract code we are we will use a passer to pass it into a token sequence and based on this token sequence we will build this statistical language model which captures the regularity of all the tokens and the language model will be able to answer the question whether the token sequence is likely to occur in the in a specific context and then we can identify irregular code in the smart contract and flag potential problems so more specifically the a sperm from framework works in a two-phase manner in the first phase we will need a large collection or for smart contracts to train the model to do that we will use a steady Canela analyzer to extract semantic metadata of out of your contract basically we are trying to do two types of things and we can focus on the access on our storage data and also the flow sensitivity so if we take a look at this simple smart contract these two lines of code the analyzer will tell you that oh there are two these two lines of code are are accessing on the same storage data call user balance and one of them is radar pressure and the other is right and these two operations are dependent on each other because they are from different public functions and are not commutative to each other and in terms of flow sensitivity if we look at this kind of code the flow condition of this line of code includes constraints from the modifier and also the if statements and the way we model flow the flow this flow is by using the addresses and the operators involving these flow conditions in this case that will be where we'll be using message tender and the two operators as specified here and then we will use a tokenizer to generate a token sequence from this contract and the generation is basically done by traversing the abstract syntax tree in a type based manner which means that we generate a corresponding token for a specific type of ast node and then we will be training the model using an underlying Angra model engine and to build this or statistical language and in the second phase we pretty much do the same thing and given the smart contract we generate the token sequences and then we can use the detector to curate the language model before and then calculate their calculate the regularity or perplexity scores of sub sequences and then we will highlight top candidates of these smart contracts with the highest perplexity scores and if you are trying to use these candidates information to help optimize the existing smart contract analyzes for example a symbolic execution engines what you can do is to design this rancor which takes the candidate information and generate scores for all the information or all the functions in the contract and then this scores will tell the symbolic executors which function is more buggy than the others and then this morning executors can prioritize the exploration of a specific function with high scores so as to detect vulnerabilities more efficiently and in the future we plan to work on optimizations on the language models for example we are trying to figure out more efficient way to encode both syntactic and semantic irregularities and also we are considering porting a SCORM to more existing techniques for example formal verification static analysis random fuzzing something like that and also to create a better developer experience we're planning integrity as we're a scrum with an IDE so that we can capture and model developers feedback and optimize the s quorum itself and we're actually have published the academic paper about the escrow me if you guys are interested you can look into the details and I will be wrong of lying around here for offline discussions and that will conclude my talk thank you