Smart contracts

Programs on blockchains

A smart contract (SC) is a script that:

• runs on blockchain

• cannot be modified once deployed

• does exactly what you tell it to do

The term smart contract dates to 1994, defined by Nick Szabo as:

A computerized transaction protocol that executes the terms of a contract. The general objectives of smart contract design are to satisfy common contractual conditions, minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries.

Szabo, a computer scientist and legal scholar, developed the concept with the goal of bringing well established practices of contract law and practice to the design of electronic commerce protocols between strangers on the Internet.

Benefits of smart contracts

Compared to traditional contracts, the benefits of smart contracts include:

• Decentralized. All nodes on the blockchain store the same copy of the SC with exactly the same state (association between variables and values)

• Automated. The outcome of a SC is automatically executed when the contract conditions are realized

• Deterministic. SCs execute precisely based on the conditions written within the contract's code. This precision means that given the same circumstances, the SC will produce the same result, even when it is buggy

• Immutable. Once deployed on the blockchain, a SC cannot be changed, and runs forever. A new version can be deployed, but the old version is still saved and cannot be removed

• Transparent. you can check what's in a SC before you sign it (or otherwise interact with it). Better yet, public transparency of the terms in the contract means that anyone can scrutinize it

• Independent. SCs have their own addresses and can therefore store, send and receive crypto independently, and even calling other SCs

• Fast. A SC can be fulfilled seconds after the initial criteria are met

• Cost efficient. The lack of intermediary and of risk of hidden costs for things like arbitration and enforcement if there are any problems with the contract makes the interaction with a SC quite convenient

• Permissionless. Anyone (with the right skills) can write a SC and deploy it to the network

• Reusable and composable. SC are open-source and can be forked, re-used and composed by anyone

Smart contract use cases

Here are some popular, real-world use cases:

• decentralized finance applications like stablecoins, decentralized exchanges, lending, borrowing and staking

• marketplaces of NFTs

• decentralized metaverses

For instance, SuperRare is a digital art marketplace that uses smart contracts to trade art in the form of NFTs. You can interact with the SuperRare smart contracts (mint and sell if you are a whitelisted artist; bid and buy if you are a collector) using its Web interface. Alternatively, you can interact with the contract on etherscan, an Ethereum blockchain explorer.

Consider the Andy-Machine-Portrait-2020 artwork. Let's get the metadata of the NFT by querying the contract:

1. copy the token id (5746) and then click on the contract address

2. click on the contract tab and then on Read Contract

3. scroll down, find the tokenUri function and insert the token id

4. copy and paste the returned URI on a browser to read the metadata of the artwork

Problems with smart contracts

• Bugs. Open-source development is a staple of Web3 applications since decentralized apps work without human intervention, hence users need to be able to audit the underlying code in order to trust the application. But this also stands to benefit cybercriminals, who can analyze the scripts for vulnerabilities and plan exploits in advance

• Protocol changes. A change on the platform level (blockchain) might cause contracts to start behaving differently to what was expected before

• Real world issues that cannot be easily communicated by oracle services. Imagine that you rented an apartment or a car and made some accidental damage. How would a smart contract without any human intervention possibly know about it?

Common smart contract vulnerabilities

• Reentrancy attacks: When a function makes an external call to another contract before it finishes executing, attackers can potentially call back into the contract before the first execution is complete, leading to unexpected behaviors.

• Arithmetic over/underflows: Smart contracts written in Solidity are vulnerable to overflows (when numbers wrap from maximum to minimum) and underflows (the reverse). This can be exploited to manipulate contract logic.

• Gas limit and loops: Functions that run large loops or consume a high amount of gas can hit the block gas limit, causing transactions to fail. Care must be designed to minimize gas usage.

• Timestamp dependence: Contracts depending on block timestamps for logic can be manipulated by miners to some extent, as the exact block time can be slightly altered.

• Visibility modifiers: Incorrect use of Solidity's visibility modifiers (public, external, internal, private) can expose functions and data that should be restricted.

Best practices for secure smart contracts

• Code audits and reviews: Before deployment, have the contract code reviewed and audited by experienced developers and use automated tools to scan for common vulnerabilities.

• Use established libraries: Where possible, use well-tested libraries and contracts such as those provided by OpenZeppelin to reduce the risk of introducing bugs.
• Limit use of external calls: Design contracts to minimize the use of external calls and ensure they handle unexpected outcomes gracefully.

• Implement circuit breakers: Pause functionality in the contract that can be activated in case of detected anomalies or attacks.

• Regularly update and maintain: Be prepared to update contracts in response to discovered vulnerabilities or to improve functionality, understanding the challenges of contract immutability.