Smart contracts may not be as smart as you think

Blockchain technology has sparked the interest of enterprises 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 smarter technical products.

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

But for all the disruptive potential and much-touted capabilities that blockchain promises, the number raids focus on smart contracts has increased more than 12 times in the past two years. If they are so smart, why are we seeing such a huge increase in robberies?

For a better understanding, 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 counteracts this by eliminating the single point of failure of a network.

While a blockchain network cannot exactly be hacked, many of the distributed apps and smart contracts that blockchain enables 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 is only likely to increase as more assets move on-chain with the proliferation of tokenized real-world assets. Hacking poses a serious threat to this burgeoning blockchain sector, as assets stolen from smart contracts are extremely difficult to recover.

Threats to smart contracts

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

While miscoding can be prevented by a smart contract check, other threats are more complex. For example, the default visibility vulnerability is a common error that happens when feature visibility is not specified and certain features are left public. For example, hackers could access the coin feature and create billions of relevant tokens. Fortunately, this vulnerability can be prevented by running an audit that ensures that all functions are set to private by default.

Another more complicated and serious threat caused by encryption errors is a return attack. This happens when an attacker exploits the smart contract’s remote function calls and deploys a malicious smart contract to communicate with whoever owns the money.

2016 the DAO incident, which took place in the early days of Ethereum, showed how dangerous this type of attack can be and eventually led to the creation of Ethereum Classic. Preventing recurrence attacks is not easy, but there are frameworks and protocols that can limit the damage, including IEC (control, effects and interactions), return guards and more.

If you are proficient in smart contract code, reading the code itself is always a huge advantage. Just as reading a contract before moving into a new apartment protects you from surprises, reading the code of a smart contract can reveal bugs, malicious features, or features that don’t work or make sense.

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

Address vulnerabilities in smart contracts

Let’s not forget that most smart contract administrators give themselves some administrative privileges, usually to make changes after launch. To access these privileges, the administrators must use their private keys. These private keys are yet another vulnerability, and if not properly stored (i.e. in an offline cold vault), hackers who somehow gain access can make changes to the smart contract and funnel the money anywhere they want .

Recently, the European Parliament a kill switch mechanism used to mitigate damage in the event that a smart contract is compromised. While the regulators intended to give people more protection over their own personal information, the law has raised concerns in the Web3 community.

If a kill switch is not implemented properly, the entire smart contract and all the value stored on it can be destroyed. A better implementation would be to activate a pause function that, in the event of a security threat, could freeze the smart contract and reactivate it once the issue has been resolved.

If the pause function is implemented, it is recommended that the administrator use two different private keys. Because once the private key (used to pause the contract) goes online, it becomes vulnerable to attack. As stated in my article according to the mandate, separating the pause and resume admin keys and storing them offline strengthens the security of the smart contract by eliminating potential points of failure.

As with all technologies, security threats exist in the DeFi and blockchain ecosystems. Smart contracts certainly have their benefits, as we’ve seen with the rise of DeFi platforms and protocols, but understanding their vulnerabilities, doing careful research, and following the guidelines in this article can mitigate them. Over time, enhanced 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.