Smart Contracts can be defined as applications that allow writing programs on the Ethereum blockchain. They run entirely on the blockchain and once written, cannot be edited, updated, or deleted. The uses of smart contracts are based on cryptology.
To talk about smart contracts, we first need to talk about Ethereum and, before that, about the structure of the blockchain.
The blockchain is a data structure developed by Satoshi Nakomoto in 2008 to be used for Bitcoin. It can be thought of as a kind of ledger that can be used publicly without the need for any central server. The blockchain consists of blocks, and since each new block is encrypted with the address of the previous block, the data of the previous blocks is always protected and cannot be changed. Cryptocurrencies such as Bitcoin and Ethereum use blockchain infrastructure.
Bitcoin has a somewhat primitive structure as it is only used as a money transfer, transfer ledger. Ethereum, on the other hand, has evolved from a transfer ledger to a programmable machine with smart contracts. Released in 2015 by Vitalik Buterin, Ethereum is now the most widely used blockchain.
Smart contracts are defined as programs that are programmed and written on Ethereum and can be used by others. Since smart contracts can be written, signed and used by anyone, they have become vulnerable to abuse, mostly in monetary transactions.
Smart contracts: Application scenarios, advantages, and potentials
Developing a Smart Contract
Smart contracts are developed on Ethereum using a programming language called Solidity. Solidity is developed in a similar syntax to ECMAScript and is constantly updated for security and optimization. Remix, which includes the Solidity compiler, is used as the IDE.
For example, if we want to write a simple donation application on Ethereum:
In the above application, the person who creates the contract is defined as a charity and then the donations received are sent directly to the charity account and the donor is added to the list of donations.
If we want to see it as a demo:
At 0x583…, we created the contract on the test network, as shown on the left, paying a tax called gas. This gas tax can vary depending on the size of the program being written, but the more gas paid, the faster the transaction takes place on the network.
After the contract was created, we also donated 2 Ether at 0xdD8…… As you can see on the right, 2 Ether + tax was deducted from our donor account and 2 Ether was transferred from our donor account to the charity account.
Looking down the image, we can see the available functions. With the “bagisVer” function we made our donation, with the “bagislar” function we checked our donation and with the “hayir_kurumu” function we verified the address of the charity.
As you can see, it is very simple to create and use a smart contract, and this simplicity should be treated with caution, considering that malicious people can also create contracts.
Smart Contract Security
Since smart contracts are a program, they allow the software developer who creates the contract to create any function they want. Some contracts are also subject to fraudulent activities called traps. However, since Ethereum smart contracts are publicly available, you can see the source code and take precautions accordingly.
Below, I’ll discuss a few bugs and the security issues encountered in response to these bugs.
Repeated Login
While smart contracts are used by individuals, they can also be used by other contracts. This paves the way for attacking other contracts with certain techniques. For example, let’s say that money can be deposited and withdrawn from a bank contract. I can withdraw $100 from a contract where I previously deposited $100.
When the withdrawal function is as above, the money is sent and checked before the balance is reset, and then the person’s balance is reset. There is nothing logically wrong with checking that the money has been received, but it is open to abuse.
If another contract sends $100 to this contract and wants to withdraw it again, and the contract withdraws again before it receives a response, it can withdraw $200 or more.
Above, the contract named Attacker deposits 1 Ethereum in the bank, then wants to withdraw it. The bank checks the attacker’s balance (1ETH) and sends him the balance. As soon as the attacker receives the money, he wants to withdraw it again. The bank checks the attacker’s balance (1ETH) and sends the balance. After receiving it, the process continues again until the gas tax paid by the attacker runs out or the bank’s balance runs out. Finally, when the transaction is finished, the bank resets the attacker’s address balance. The problem here is resetting the balance after sending it. The solution is to reset the balance before sending and not accept the transaction because the balance will be zero in subsequent requests. It is a very simple mistake, but about 8% of the contracts in the market make this mistake.
Default Access – Visibility
In Solidity programming language, there are 4 types of visibility and access types: public, private, external, and internal.
Public: Access type that can be seen and called from outside and inside.
Private: Access type that can only be accessed by the original contract.
External: Access type that can be seen and accessed externally but not internally.
Internal: Access type that can only be seen and accessed internally or through inherited contracts.
If external access is granted to a function that should only be accessed internally, it may be open to error and abuse by the functions called due to the workflow.
For this reason, access types should be used correctly in order to avoid such problems, but it should not be forgotten that even if it has a private access type, every code written can be clearly visible to everyone.
Denial of Service – DOS Attacks
Loops, which are frequently used in programming languages used in daily life, are also available in Solidity. For example, loops that are used to search for a specific user within 100 users do not pose much of a problem in traditional programming languages, except for wasting time (probably in milliseconds). However, this is very different in smart contracts. Each transaction used in a smart contract causes the contract to pay a tax.
If we use a loop to search for a user out of 100 users in a smart contract, as in the previous example, this will cause us to pay more gas tax than necessary. Since the code is also publicly available, attackers can abuse the smart contract and call the function with the loop, allowing the contract to become unable to respond to subsequent requests when the tax budget on the contract is exhausted.
As a solution, instead of using loops to call a user, the user’s address can be used directly in the function to avoid loops.
Honey Trap – Honeypot Contracts
Some attackers can trap investors by preparing decoy contracts. Such contracts can only be understood by reading their code. If the money transferred into the contract can be sent by anyone but can only be withdrawn by the owner or certain people, these contracts are called honey traps, or honeypot contracts in the original name. Since anyone can create a smart contract using Solidity, it’s worth paying attention to such traps.
These are not the only security flaws in contracts, and they will continue to increase as contracts are created. We can avoid them by reviewing the SWC (Smart Contract Weakness Classification).
Sources
https://ethereum.org/en/developers/docs/smart-contracts
https://ethereum.org/en/developers/docs/smart-contracts/security/
Would you like to trade some smart contracts? Trade on Venice Swap today. Try to the best decentralized exchange experience.