Today, the team at Nascent is excited to announce the alpha version release of our newest open source security tool, Pyrometer. Check out the code, give us feedback in the Pyrometer Telegram group, and follow us on Twitter for future updates.
What is Pyrometer?
Pyrometer is a next-generation security tool for analyzing smart contracts. In its current early form, Pyrometer serves Solidity developers by evaluating their code using a mix of abstract interpretation, symbolic execution, and static analysis. At its core Pyrometer performs Bound Analysis - tracking variables through the program and understanding how the code affects those variables’ potential values.
Pyrometer is a tool with 2 core users in mind:
Nascent is building Pyrometer to empower both developers and auditors with a deeper understanding of the smart contracts they are working with, allowing them to find & squash bugs faster. We still have a ways to go, but the groundwork has been set with the release of this Alpha version.
Why build a security tool?
One of the core motivations for building Pyrometer was a gap in existing security toolkits. Currently, there are testing frameworks (Foundry and Hardhat), static analysis tools (Slither and Mythril) and even some very promising formal verification tools out there as well.
But across all of these, one aspect that is sorely missing in all of those tools is a tool for understanding your code. We’ve been in post-hack war rooms with teams combing through transactions and codebases with the highest degree of urgency, trying to understand where in the execution things have gone off track. While some exploits are technical, like reentrancy bugs or oracle manipulations, a good number are rooted in business logic flaws. Pyrometer is designed to provide contextual insights in a blazingly fast and developer-friendly way that no other security tool on the market can.
In contrast to existing tooling, Pyrometer’s key is to expose to the user what the tool is doing at its core. By showing the user how their variables change throughout a program, we believe this drives insights that are otherwise missed by auditors and developers. It also happens to be the case that the core analysis performed by Pyrometer is extremely extensible, lending itself to be foundational for further analyses, like access control analysis, to be built on top. Between the gap in existing security tools and the potential for this to be a foundational building block for analyzing code, Nascent was excited to spend time developing this tool for the good of the ecosystem.
Public Goods & Safe Coins
Pyrometer’s goal is 3-fold:
- Enhance a developer’s ability to find bugs early
- Increase an auditor’s understanding of a new codebase & find bugs
- Create a safer ecosystem
With those goals in mind, Nascent is releasing Pyrometer as an open-source public good, under a GPLv3 license. This license may change in the future to a different license, but in this early stage we want contributions to be upstreamed.
Where Pyrometer is today
Pyrometer is nascent (*ba dum tss*), and as such it is not yet the smooth developer experience we are building towards. We are opening up the code in its current state to find fellow builders who share our goals and want to contribute. Contribution can take multiple forms, such as feedback or hopping in the code and opening a PR.
There is no minimally/maximally supported solidity version specified yet - although pragma 0.8.x is the current target. Solidity has many features and, by extension, weird edge cases. As of today, most core language features are supported - many contracts have been passed through the tool without error.
However some less popular, but notable, language features are not currently supported: assembly blocks, low-level calls, user defined value types, and some nonstandard versions of function calls. All of these are on the short-list for being implemented.
Some features have limited support: memory/dynamic length variables and storage variable changes based on constructors. These issues will be ironed out in the next few days.
While the techniques utilized by Pyrometer sound complicated, we have taken (and hope to foster in contributors) an engineering approach first and foremost. There is no opaque magic in the code, just simple building blocks joining together in powerful ways. If you know rust and love public goods, consider contributing.
As a small example of where the tool is today, given this contract:
The tool will output:
As a brief explanation, as the tool analyzes the function, it calculates a range that that variable can be in and reports it to the user (see the repo for more documentation on this output).
This analysis can be used by other analyzers - for example there is an Access Control Querier. This secondary analyzer is still early in its development but it reports out the conditional requirements for writing to a storage variable, for example:
The tool will output:
This feature is only ~40 lines of logic built in 15 minutes on top of the core analysis as a demo. It is probably already best-in-class at reporting access control information to a developer or auditor.
Where Pyrometer is going (with your help)
In addition to building a more robust application, there are a number of features already planned (in no particular order):
- Taint Analyzer
- Gas Optimization Analyzer
- Invariant Analyzer
- Reentrancy Analyzer
- Execution Code Path Querier
- DSL for writing analyzers
- Web UI via WASM
- Tapping into SMT solvers to concretize from conditionals
- LSP/IDE integration
- TUI/GUI for even better code exploration & understanding
Utilizing Pyrometer as a library, the Foundry fuzzer could become best-in-class. The values that Pyrometer calculates in its analysis are highly relevant to code execution and can be key to pointing the fuzzer toward better input generation.
Ultimately, we foresee Pyrometer being a staple for both developers and auditors in the not-too-distant future.
First, we’d like to thank the Spearbit team - they have provided some great suggestions and helped craft the vision for where Pyrometer can go - serving their auditors and clients.
We’d also like to thank the builders - you inspire us and we do this for you all.
Finally, we’d like to thank Matt Solomon, Georgios Konstantopoulos, and t11s for their valuable feedback as we built this tool.
Why UNIChain is Inevitable on Bankless [PODCAST]