Smart contracts may not be as smart as you think

Blockchain technology has attracted the interest of businesses around the world. Its benefits, including immutability and transparency, have led legacy companies outside of finance, such as BMW and Bosch, to experiment with smart contracts to create more efficient supply chains and make more engineered products. smart.

Smart contracts, which are essentially software coded in a specific blockchain, formalize and execute agreements between multiple parties, removing the need for a trusted third-party intermediary, saving time, and enabling consensus-based multi-party validation. They can be used in a variety of activities, such as wills, chess games, and even deed transfer.

But for all of blockchain’s disruptive potential and promises of much-vaunted capabilities, the number of burglaries smart contract targeting has increased more than 12 times over the past two years. If they’re so smart, why are we seeing such a massive increase in robberies?

To better understand, let’s clarify the relationship between blockchain and smart contracts.

Decentralization

Think of a blockchain network like Amazon’s AWS platform and each of its smart contracts as a server. With blockchain, there is no single centralized server for hackers to exploit, making it more difficult for cybercriminals to use traditional hacking methods, such as Trojans, physical attacks, and ransomware . Blockchain thwarts them by eliminating a network’s single point of failure.

While a blockchain network cannot exactly be hacked, many blockchain-enabled distributed applications and smart contracts can.

Thanks to the gradually growing success and influence of decentralized finance (DeFi), large amounts of value are channeled through smart contracts, making them attractive to hackers. And this threat will likely only grow as more and more assets move on-chain with the increase in tokenized real-world assets. Hacking poses a serious threat to this burgeoning blockchain sector, as assets mined from smart contracts are extremely difficult to recover.

Threats to smart contracts

Like any code, smart contracts are subject to human error. These errors can take the form of typos, misrepresentation of specifications, or more serious errors that can be used to hack or “cheat” the smart contract. Unlike the blockchain, there is no guarantee that the contracts have been reviewed or validated by peers.

While faulty coding can be avoided with a smart contract audit, other threats are more complex. The default visibility vulnerability, for example, is a common error that occurs when function visibility is not specified and certain functions are left public. For example, hackers could access the mint function and create billions of relevant tokens. Fortunately, this vulnerability can be avoided by running an audit that ensures all functions are set to private by default.

Another more complicated and serious threat caused by coding errors is a reentrancy attack. This occurs when an attacker takes advantage of the smart contract’s external function calls and deploys a malicious smart contract to interact with whoever holds the funds.

In 2016, the DAO incident, which happened in the early days of Ethereum, demonstrated how dangerous this type of attack can be and ultimately led to the creation of Ethereum Classic. Preventing reentrancy attacks isn’t straightforward, but there are frameworks and protocols that can mitigate the damage, including IECs (verification, effects, and interactions), reentrancy guards, and more.

If you are proficient in smart contract code, reading the code itself is always a huge plus. Just like reading a contract before moving into a new apartment protects you from any surprises, being able to read the code in a smart contract can reveal flaws, malicious functions, or features that don’t work or haven’t worked. of meaning.

However, if you are an end user who is not particularly tech-savvy, only use smart contracts with publicly available and widely used code. This, as opposed to compiled smart contracts, where the code is hidden and people cannot view it, is the preferred option.

Addressing smart contract vulnerabilities

Let’s not forget that most smart contract admins leave themselves some admin privileges, usually to make changes after launch. To access these privileges, administrators must use their private keys. These private keys are another vulnerability, and if not properly kept (i.e. in an offline vault), hackers who somehow gain access to them can bring changes to the smart contract and route the funds where they want.

Lately, the European Parliament has mandated the use of a kill switch mechanism to mitigate damages in the event of a smart contract compromise. While the intention of regulators was to give people more protection over their own personal data, the law raised concerns in the Web3 community.

If not implemented properly, a kill switch could destroy the entire smart contract and any value stored in it. A better implementation would be to activate a pause function which, in the event of a security threat, could freeze the smart contract and reactivate it once the problem is solved.

If the pause function is implemented, the administrator is advised to use two different private keys. Because once the private key (used to suspend the contract) is online, it becomes vulnerable to attack. As mentioned in my tenure article, separating the pause and resume admin keys and storing them offline enhances smart contract security by eliminating potential points of failure.

As with all technologies, security threats exist in the DeFi and blockchain ecosystems. Smart contracts certainly have their advantages, as we have seen with the emergence of DeFi platforms and protocols, but understanding their vulnerabilities, performing diligent research, and following the guidelines laid out in this article can help mitigate them. In time, improved security protocols will take shape, strengthening smart contract use cases and ushering in a more robust blockchain ecosystem.

Shahar Shamai is CTO and co-founder of GK8.