Smart Contracts Security: Interview with Psy Labs Co-Founder

Consulting company Psy Labs specializes in smart contracts for DEXs and CEXs, DeFi protocols, NFT projects, trading bots, etc. They develop smart contracts on Ethereum, Sui, Cardano, Polkadot, Near Protocol, Ripple, Solana, and Holochain networks. 

The Psy Labs team includes ex-employees from Meta, McKinsey, Binance, Kaspersky, and other industry giants, developing crypto solutions from scratch to full deployment. But what turned out to be more important within our acquaintance is that Psy Labs specialists also ensure the security of their own and third-party smart contracts, which is especially relevant in light of the multi-million dollar losses that the Web3 industry is experiencing from hacker attacks. 

Mike Belous, Co-Founder and CTO of Psy Labs, answered questions from CP Media. He shared his expertise in securing smart contracts based on his experience using SmartSafe software developed by the Psy Labs team as an outsourced product. As befits, we started a little bit from afar…

Why did you choose to develop smart contracts?

The development of smart contracts is the most requested service in our field, as they’re the main component of the vast majority of crypto projects.

At what point did the request to develop a vulnerability detection system for smart contracts emerge? 

The news of major breaches of smart contracts, such as the hack of The DAO, surfaced. These incidents highlighted the vulnerability of even well-funded projects and made everyone a little nervous.

Although there are tools generally available for detecting software vulnerabilities, there’s no comprehensive solution adapted for smart contracts on different blockchains.

How would you rate the level of smart contract security today?

Today, developers have access to modern tools and platforms designed specifically for smart contract security. For instance, formal verification tools are being used to mathematically prove the correctness of contracts, which wasn’t as prevalent a few years ago. Moreover, there’s a trend towards the adoption of more secure programming languages in smart contract platforms, like Vyper for Ethereum, to reduce potential security loopholes (at the time of preparing the interview, vulnerabilities were also found in Vyper — ed.).

However, challenges persist. The DeFi boom, as exciting as it is, brings new complexities. We’ve seen hackers use innovative ways to interact with smart contracts during flash loan attacks, showing that the ecosystem still has vulnerabilities.

What do you find most problematic about this issue? 

In the realm of smart contract security, one of the most pressing issues is the immutable nature of the blockchain. Once a smart contract is deployed, it can’t be altered. So, any vulnerability or flaw in the contract remains permanently, exposing it to potential exploits. The already infamous hack of The DAO on the Ethereum platform, which resulted in a loss of around $60 million, was a stark reminder of this challenge.

Additionally, the rapid evolution of the DeFi sector has introduced intricate interactions between smart contracts. This can sometimes lead to unforeseen vulnerabilities. As an example, in the bZx platform attack, attackers cleverly manipulated the protocol through a series of DeFi transactions, causing significant financial losses.

Can you tell us about the five most common types of vulnerabilities you encounter?

We certainly pay special attention to categorizing attack vectors, given how frequently some of the vulnerabilities mentioned below are used:

1. Reentrancy attacks. This attack is perhaps best known due to the hack of The DAO. In a nutshell, it allows an attacker to re-enter and execute a function multiple times before its initial invocation is complete. This is similar to a record skipping on a turntable, with the same line being played over and over again before moving on to the next action.
2. Uncontrolled integer overflow and underflow. This is where the numbers can go beyond the set limits. Imagine a car odometer resetting to zero after reaching its maximum display. In the world of smart contracts, this can lead to a situation where, say, subtracting from a low balance results in a very large number rather than a negative one.
3. Exposed functions. Sometimes developers accidentally leave functions known as public or external, meaning that anyone can call them. This is akin to leaving the front door of your house open, and anyone passing by could just walk in.
4. Gas limit issues. Contracts that require more gas than the block gas limit can become irrevocably stuck. This can be compared to powering an entire city on a single AA battery. While this isn’t always an attack vector, it can result in locked funds or unusable contracts.
5. Inadequate event logging. This might not seem like a typical vulnerability, but it’s crucial for dApps. Without proper event logging, a dApp might not display or operate correctly, and users can be left in the dark. This is similar to a car dashboard that doesn’t show the speed or fuel level, leaving the driver driving blind.

Can you describe your smart contract analyzer in more detail? What methods does it use to identify vulnerabilities?

The smart contract analyzer is the linchpin of our vulnerability detection framework. Let me break down its main components:

1. Abstract Syntax Tree (AST) parsing. At its essence, AST helps us understand the structure and hierarchy of a smart contract’s code. Imagine taking a complex sentence and breaking it into its constituent parts of speech. That’s exactly what AST does but for code. By analyzing this structure, we can pinpoint areas that might be prone to certain vulnerabilities.
2. Control flow analysis. This examines the possible paths a transaction takes from its start to its completion. It can be compared to mapping out all the possible routes one could take on a road trip to spot potential hazards or obstacles on each of them.
3. Data flow analysis. This method traces how data moves and changes throughout the contract. Imagine that water flows through a series of interconnected pipes, and you want to track its movement and the points of potential contamination.
4. Integration with Rule Engine. Our analyzer works hand-in-hand with our Rule Engine, which contains a set of predefined rules derived from known vulnerabilities and our research. Imagine having a checklist of things not to do — the Rule Engine has this list and cross-references it with AST analysis, controls, and data flows.
5. Machine learning component. Over time, as our system reviews more contracts, it learns from the patterns it identifies. So, if a novel vulnerability pattern emerges in the ecosystem, our analyzer can detect it, even if it hasn’t been formally defined in our Rule Engine. Think of it as a self-updating encyclopedia that gets smarter the more it reads.

What is the role and mechanism of the Rule Engine in your system?

At its core, the Rule Engine is a vast library of predefined rules or patterns that correspond to known vulnerabilities. Consider it as a reference book on what not to do when writing a smart contract.

How does your framework integrate with other smart contract development tools?

We focus greatly on this area because we recognize the importance of a seamless development workflow. Let’s dive into this topic:

1. Command-line interface (CLI) support. At the most basic level, our framework offers a CLI tool. It allows developers to run vulnerability checks directly from their familiar command line environment. This is similar to a grammar checker tool that can be quickly run in a document, only for smart contract vulnerabilities.
2. CI/CD pipeline compatibility. Continuous Integration and Continuous Deployment (CI/CD) are the backbone of modern software delivery. Our framework fits perfectly into these pipelines, ensuring vulnerability checking at all stages of the development and deployment process. Think of it as a quality control checkpoint on an assembly line.
3. Plugin modules for IDEs. We understand that developers spend a lot of time in their Integrated Development Environments (IDEs). That’s why we develop plugin modules that integrate directly with popular IDEs. This provides real-time feedback as developers write or modify smart contract code, almost like red underlines under misspelled words when typing in a word processor.

How automated is your system, and where is expert involvement required?

Most of the components described work in an automated fashion, and it’s like having an extra set of eyes that never sleep. The system is constantly scanning, analyzing, and classifying vulnerabilities without needing constant monitoring.

Automation covers everything from digging into code with things like AST parsing to generating neat reports with graphs that our clients love so much. It can even sync with the tools that developers are already using, making it super convenient. 

But, as you know, automation is only as good as the people behind it. That’s where our specialists come in. They’re the ones developing the rules that the system works by. And when there’s a complex vulnerability or a new blockchain to work with, they’re the ones who figure out how to handle it. They also keep the system up to date, upgrading it with new patterns as the security landscape changes. 

What plans do you have for your system’s development? Are there any new features or enhancements you are looking to implement?

First up, we want to expand the machine learning aspect of vulnerability detection by adding new, more complicated methods. We think about more predictive analytics, foreseeing issues before they become a trend. 

Then, there’s the whole world of new blockchains springing up like mushrooms after rain. We aim to make our framework adaptable to as many of them as possible. 

We’re also exploring more interactive and user-friendly reporting. We want to turn this data into something tangible that developers and security teams can play with.

Let’s not forget about collaboration. Within Psy Labs, we often brainstorm ways to make our system a collaborative hub where different stakeholders can come together, share insights, and work on solutions.