solsearch

Here's why and for what solsearch can be used:

1. Highly customizable linters: the DSL can encode simple linting rules.
2. Highly extensible static analysis tools: the DSL can be used to write rules on the fly. Current static-analysis tools require working with the AST directly in a high-level language like C++, Rust or Python. The learning curve and feedback-loop for existing static-analysis tool is bad.
3. Security research:
   • A researcher can build their own internal set of rules, for common vulnerabilities and patterns that they notice, and run it againt solidity contracts.
   • When a new security bug is found, this search tool can be used to query against all verified contracts on chain to find out affected contracts.
4. Language designers: when existing features for solidity gets updated, the compiler team often needs to understand the impact of the changes. This search tool can be used to precisely located open-source contracts that use certain language patterns.
5. Fun: I wanted to see how to design a query language to search over Solidity's AST and how powerful such queries can get.

It's in built on Rust, and uses some existing libraries (solidity-rs: I had to make a fork of this repo to use it as a library, my fork) that has the Rust struct bindings for solc's AST. For the first few hours, I was mainly searching such a library. Implementing it from scratch would have been tedious and impractical for a Hackathon. (tweet: the replies to this tweet gave some other libraries.)

More importantly, functions or the visitor patterns are also needed for building the search tool. In retrospect, the visitor pattern implemented in this library wasn't suitable for building the generalized matching engine. In the end, I decided to de-scope the matching engine to only work with a few rules. If I were to build this over 2 weeks, I'd probably reimplement the visitor pattern to be something more suitable for my use-case.

The Domain Specific Language (DSL) was inspired by Semgrep. Solsearch can be thought of as a highly specialized semgrep for Solidity. It understands the nitty-gritty annotations that the solidity compiler internally creates for the program. Working directly with the solidity AST can be powerful, as it has plenty of rich details about the language.

Once the DSL and the AST could be internally represented, it was a matter of building the pattern matching engine for it. For the MVP, I decided to just support the pattern matching engine just for the AST node functionCalls. The DSL has support for a few more type of AST nodes, but both do not completely support every AST node type from Solidity. Completing this would be a more ambitious project that would take around 2 weeks. The future plans are listed in the GitHub repo.