Nick Szabo coined the term smart contract in 1994. Smart contracts are self-executing contracts. They eliminate intermediaries and allow direct P2P transactions. A smart contract has the power to automatically enforce some obligations. One of the best examples of this is a vending machine: when you need an item from a vending machine, you pay into it and it gives you that item without needing any middleman.

Smart contracts are very different from traditional software programs. Smart contract code is immutable once deployed on the blockchain. Because of this immutable property, we have to think twice before deploying it; otherwise, it could end up with critical flaws in production. A different mindset is required for writing smart contracts. Some smart contracts present in decentralized applications handle the flow of ETH or other ERC20 tokens, which have real monetary value. If something goes wrong in the production, any attacker can steal ETH or ERC20 tokens from your smart contracts.

Once you deploy your smart contract on Ethereum blockchain, either on the testnet or the mainnet, you cannot modify the code of the smart contract files that you have deployed. All code that is deployed becomes immutable. Not even an attacker/hacker can change the deployed code.

If your code is deployed on the testnet for testing purposes, then you can fix any issues in your smart contract files present on your local machine, and redeploy your code on the testnet again to check whether the functionality is working or not. But if you have deployed your contract on the mainnet (production) and other people, entities, or contracts started using that contract code, then you cannot change that contract code. If those entities are still not using that freshly deployed code, then you still have a chance to fix any issues/errors and redeploy. There is another way to create an upgradable contract in Solidity; for more details, you can refer to Chapter 11, Upgradable Contracts Using ZeppelinOS.

You cannot change the code of smart contracts, but you can change the different states/variables of the smart contracts—those are handled with smart contract code. Based on the different states/variables, your smart contract code behavior changes.

Once the smart contracts are deployed on Ethereum network, their code becomes immutable. No one can change the code of the deployed smart contract. It's the same as when some transaction on the Ethereum network is done, and there is no way to reverse that transaction. For example, if person A sends 1 ETH to person B and the transaction is successfully executed, then there is no way for person A to reverse that transaction and to get that 1 ETH sent back to their wallet. 

For smart contracts as well, if you have done a particular transaction on a smart contract that has changed the state of the contract, then there is no way to reverse that transaction. There might be some other functions available in the smart contract to get the same state again, but, in terms of transactions, it is not possible to reverse the transaction that was executed.

I am serious—think twice before deploying smart contracts on production!

Before deploying smart contracts on the mainnet (production), you must ensure that all of the unit tests and other test cases that you have for the smart contract are passing. Your code is reviewed by some other developer to ensure that the logic of the contract is correct and is going to behave as per your expectations in production. Ensure that the code coverage reports are reviewed, and the maximum possible coverage of the code is ensured.

You might be wondering why I am mentioning these normal things—as a developer, you would think that these are the processes we follow on a daily basis during software development, so what's new and special about this? 

To date, as a software developer, you have been writing software/applications and following best practices to ensure that no errors/bugs are in the system. But, at the back of your mind, you also think that if something goes wrong with the script/code, we can apply a patch and re-deploy the software/application again, with no issues. Since the beginning of software development, this has been the practice. 

Now, as a software developer, you need to understand that smart contracts are not like your existing software/applications, where you can apply a patch and change the code at any time. As smart contract code becomes immutable once deployed, only states/variables can be changed via allowed methods that are present in smart contracts. As a developer, you need to mentally prepare yourself for the fact that the smart contracts you are writing cannot ever be changed once deployed on the Ethereum blockchain. If you have experience of writing device drivers for hardware, then you can understand this easily as device drivers have limited changeability/upgradability.

If you are planning to upgrade smart contracts in the future, then you need to be prepared for it when deploying the first version of the contracts. For example, you should be able to stop an existing version of a smart contract and move on to the new upgraded version. You also need to think about how existing users will migrate to a new upgraded version of contracts.

There are some design patterns available to provide upgradability to smart contracts. We will cover those in Chapter 11, Upgradable Contracts Using ZeppelinOS.

The preceding summary is not intended to threaten you about how smart contracts could go wrong, but to inform you about the consequences it could cause if the code is not well tested and reviewed with multiple iterations.

When your smart contract stores some variables/states, it has to be stored on the blockchain's ledger. The storage space of smart contracts is limited and costly. As the gas limit per block is limited, so is the execution of a transaction. The Ethereum blockchain should not be used as data storage or a replacement database. The blockchain is a kind of decentralized database; however, at the moment, the Ethereum blockchain cannot handle the processing of loads of data in a transaction. Blockchain technology is still evolving; in the future, it might be possible to even store large amounts of data and processes in a single transaction.

If you want to store big files or data on decentralized blockchains, you should look for Swarm, IPFS, StorJ, or Filecoin, according to your needs. 

The gas consumption that we are going to talk about is with respect to the Ethereum blockchain. We are not going to talk about how other types of blockchain treat their smart contract executions.

On the Ethereum blockchain, every transaction that sends ether consumes gas; in the same way, to execute a smart contract's logic, the transaction initiator has to pay gas in ether. As a developer, you must ensure that the logic of your smart contract is not complex and consumes optimal gas. You might need to re-design your logic to ensure that gas consumption is not very high.

As we saw previously, the main currency of the public Ethereum blockchain is ETH. There are some other currencies also present on the Ethereum blockchain itself; these follow ERC20 standards and are called tokens. ETH and some of the ERC20 tokens are being traded on some cryptocurrency exchanges.

You can write some smart contracts that involve ETH and ERC20 tokens in your contracts; for example, if you are writing a decentralized exchange on the Ethereum blockchain. To name a few, some existing decentralized exchanges include EtherDelta, IDEX, and KyberNetwork.

When using ETH/ERC20 tokens in your smart contract, you need to ensure the safety of funds. The following are some examples that have led to multimillion dollar hacking of smart contracts on the Ethereum blockchain itself. One of the famous attacks was the DAO Smart Contract hack, in which attackers were able to spawn new child contracts and were able to steal ETH from the main contract. Another famous attack was the Parity multi-signature wallet hack, in which attackers were able to steal ETH from all of the contracts that were using the Solidity code of the Parity multisignature wallet. To prevent this attack, white hat hackers have to hack all other existing Parity multi-signature wallets, as there was no other solution and no way to change the contract code.

Not all smart contracts deal with ETH/ERC20 tokens, but if they are dealing with ETH/ERC20 tokens, then extra care must be taken before deployment.