Points to Remember:
- This is not a regular module based assignment rather it’s a research based practicum project worth 30 credits i.e. 1/3rd of our total degree program.
- Therefore, this has to be handled very carefully and it should contain each and every point in detail.
- When we say research it means an actual experiment has to be done to evaluate the tools. You have to take the demo/intentionally created invalid smart contracts and using the same you need to compare different tools and then evaluate their different qualities like performance, efficiancy, accuracy etc.
- We need to demonstrate the results that we will be getting from our experiment in terms of pie charts, and other types of charts/diagrams/graphs.
- As discussed over the call, we will divide the task into smaller task so that, there will be ease of doing it and we can track accordingly.
- This document will only contain one of the requirements.
- In case expert is unclear about the topic/requirement or any specific point, we expect we will be informed and then we can help him/her out.
Things to be done for first task:
Upon completion of this task, we should be able to answer our first Research Question i.e.
RQ1: What are the factors that should be considered in the selection of a tool or
framework for analyzing smart contracts?
We have partially worked on this question and below are the inputs from our end.
Classes of Vulnerabilities:
1. Reentrancy
2. Access Control
3. Unchecked Low Level Calls
4. Arithmatic
6. Bad Randomness
7. Front Running
8. Time Manipulation
9. Short Addresses
10. Unknown Unknowns
The above mentioned are the major categories of smart contract vulnerabilities and highlighted in bold are ethereum specific smart contract vulnerabilities. Currently we need to focus on those 4 first and as we move forward we need to include other categories for our experiment.
Selection Criteria for the tools:
Criteria #1: [Most Recently Updated/Published]
The tool that is most recently updated or published. This excludes any tools that are currently outdated.
Criteria #2: [Compatible Input]
The tool takes as input a Solidity contract. This excludes tools that only consider EVM bytecode.
Criteria #3: [Vulnerability Finding]
The tool detects contract vulnerabilities or bad practises. This excludes tools that are labelled as analysis tools but only create artefacts like control flow graphs.
Criteria #4: [Availability & CLI]
The tool is freely available and has a command-line interface (CLI). The CLI makes it easier to scale the analyses
Criteria #5: [Support Available]
The tool having sufficiently enough support community. This excludes the tools which are not having support community.
Criteria #6: [Ease of Installation/Use of tool]
The tool should be easy to install and shouldn’t depend on complex platforms for other thrid party integration and can be used with minimal efforts by user. This will exclude the complex tools.
Note: We are yet to get the feedback from our supervisor, however, to start off this is pretty much a good criteria for the selection of tools. Expert is free to make any further improvement for the criteria.
Currently proposed tools which satisfies above mentioned criteria:
- Slither
- Maian
- Manticore
- Mythril
- Osiris
- Oyente
- Securify V2.0
- Octopus
- Conkas
- EthSential
- NeuCheck
- Etheno
We have worked on our project this far and now expert need to take over the other parts of the project.
- Install all these tools from the GitHub
- Find out some test datasets for smart contracts such as SBCurated, SB Wild datasets etc (This will help you to gather the test data i.e. smart contract files)
- Start Analysing installed tools using the test data and document the results for further evaluation.
- Analyse which tool is perfect and best to find specific vulnerablity e.g. Tool no 1 is best for finding vulnerability no 7 etc this type of outcome is expected.
Kindly refer the paper shared along with this file to understand the flow of the project as this paper is very similar to our project and can help expert to understand requirements very clearly. (I would say we need exact similar kind of paper but with whatever criteria that we have decided and tools that we have considered for our experiment)
Once that is done, we will let you know the further requirements.
