1. The insolvency of the economic model of the application
Description: When designing applications on blockchain platforms, the economic elements of which are in a complex relationship with each other, the developer has to model the economic behavior of one or another participant of the application.
It is necessary to predict how the user can behave if he is given additional economic stimulation or, vice versa, imposed upon restrictions. If the logic of an application is based on an incorrect economic model, then the application may not perform the desired tasks and participants may incur material losses.
This class of security drawback is most often manifested in the following design models: the emission of tokens, the creation of a referral program, the integration of the economies of the blockchain application with the fiatic system, and so on.
Example 1.1: As an example, let’s consider the following economic model. A smart contract accrues users the tokens of a referral application for the performance of any work. To motivate users to use the developed application for as long as possible, developers decide to provide for the logic of the contract in such a way that tokens are credited to all users who have previously done useful work. Thus, if the user has done a useful job at least once, then it will be unprofitable for him to leave the application, because he will constantly receive additional profit in the form of tokens due to the work of other users.
In the described logic there are several security flaws, including technical ones, but let’s just focus on two economic-technical ones:
*If the user has done a useful job first, then he will receive additional profit constantly and he will have no incentive to work in the future; in this case the system will be viable only at the expense of new participants.
*If there are too many active users and the share of emitted tokens will be distributed among all existing users, then those users who have done useful work will receive less of well-deserved profits and sooner or later will stop using the application
Solution: When designing complex systems consisting of various unrelated groups of elements, it is necessary to simulate the probabilistic outcomes of the application,on the basis of which to decide whether to adopt a particular behavioral pattern or not.
2. Impossibility of forecasting factors external to the economy of application
Description: The more dependent the system is from external entities, the more sophisticated the modeling of all components should be. These types of entities can include the following elements: application participants, processed data, probability of outcome, etc.
If the developer can not predict the received application data, then the correct operation of the contract may be at risk. The developer should pay attention to at least the following aspects:
*Inability to accurately predict the number of participants in the application who will use the smart contract, because for the registration of the user, as a rule, only the Ethereum address is needed;
*In complex systems and methods, it is not possible to accurately predict the consumed gas when sending a transaction;
*External shocks that stimulate demand or reduce it, such as fluctuations in community expectations, or a sudden change in the news background.
*The value of the token towards the fiat money (too high or too low), as well as a sharp change in the value of the token. This component can directly affect the profitability of the project and reduce the profitability of using the blockchain application in comparison with competitors.
Way of elimination: One way to eliminate this shortcoming is to change the coordination strategies. It is desirable to develop each of them and have a preliminary plan, under what conditions they are automatically used. Ideally, they can be formed on the basis of the preliminary functioning of the system. But the latter requires knowledge of the aed-theory algorithms, that are used for the mathematical preparation of algorithmists and programmers. The order of the strategy change should be asymmetric. When working out the algorithm — fundamentally asymmetric: when the indicators change, we do not just roll back, but create a new algorithm. Example: with the growth of the market we try to seize it, with a decline — we cut costs. As a result, our algorithms are clearly asymmetric, but the economic efficiency is growing continuously.
3. The lack of user incentive to apply to smart contracts, transaction costs
Description: At the moment in the Ethereum blockchain a smart contract can not call itself. To activate any existing method, it is necessary that the third party to the Ethereum network send the transaction to run the executable code.
In order to send a transaction, the user needs to incur additional costs in the form of gas, even if the activation of the method does not bring any profit, that in turn leads to an increase in transaction costs in the application and reduces the its attractiveness for users. Therefore, developers come up with various economic incentives to send transactions.
When designing an application, it is not always possible to specify exactly how much gas is needed to activate a particular method, especially this problem may occur during the processing of dynamic data.
Example 3.1: Let’s look at an example when a smart contract adds on bonus points once a month evenly for all users of the application. This activity implies additional interest on the part of users to the application. There are two ways to add on points:
*Charging takes place once by a smart contract owner.
*Charging occurs each time the user calls the method of accrual of points.
In the first case, the commission to the miner in the form of gas is paid by the owner of the smart contract. That is not always beneficial to the owner, especially if the project is social and does not involve making a profit. Also, the owner must conduct monthly additional actions to call the method of accrual of points, that introduces an element of centralization.
In the second case, the commission costs are born not by the owner of the smart contract, but by the users of the application. If there are too many users and scoring is based on the formula
where b is the number of all bonus points, u is the user, x is the bonus points for each user, then the potential profit from the value of the points can be much lower than the expenses for transaction. For this, an attacker will only have to generate a number of Ethereum addresses and write them into a smart contract. In the current implemented logic of the application there is also a technical drawback, such as a gas outflow limit in the block.
Remedy: The application developer should take into account that the user incurs additional material costs when accessing the smart contract. Therefore, one should always optimize the costs of the gas used in the application algorithm.
4. Working with unverified data
Description: Perhaps the most important application of smart contracts can be the now emerging infrastructure called “Internet of things”. The economy of the future is a global network of smart things that communicate with each other via smart contracts. Thanks to smart contracts and “oracles” (the mechanisms that allow smart contracts to exchange information with the outside world), smart cars will be able to park and refuel without any assistance, smart homes — to carry out financial transactions with tenants, and drones — to deliver purchases and carry pizza.
The scope of the blockchain technology is expanding as more and more industries and businesses understand the promise of this innovation. But one turing-completeness is not enough to integrate the real world economy. Smart contract,s related to the real world and the Internet of things, should refer to events occurring outside the enclosed ecosystem of blockchain, whether it is change in asset prices on the exchange, the result of a sport match or even the state of the weather.
Some of the blockchain platforms have a closed ecosystem that does not allow direct access to external sources, while others allow it to be done using the platform itself. In the first case, to obtain reliable data on events that go beyond the blockchain, a smart contract requires a reliable external agent — the oracle. For the Ethereum blockchainOraclize can be considered as one of the most popular oracles. But, still like any other software, this oracle can be compromised. Even if not to consider the risk of substituting information on the oracle, there is always the risk of substitution of data on the external source itself. In this case, a smart contract will treat the data as valid, which in turn may affect the operation of the application.
Example 4.1: In this example, the smart contract refers to the external source api.fixer.io to obtain the current GBP rate against the EUR. If the site api.fixer.io is hacked and the data is replaced, the results will be incorrect.
To hide the compromise of the resource api.fixer.io, a bad guy can change the EUR / GBP exchange rate ratio only when the smart contract addresses the oracle, extracting this transaction from the Memory Pool.
Remedy: To avoid the threat of substitution of data from untrusted sources, it is necessary to provide the logic of work in such a way that one single source of data can not affect the entire course of the program. Also, the benefits and costs of implementing reliable oracles should be analyzed, since the value of the information obtained can be lower than the cost of deploying program’s own infrastructure.
Reliability of information concerning the cost of the pound is achieved by the transition of the source of information to the blockchain network. The same is true for any other regular information.
When the external data source itself does not want to provide the necessary information, then you can introduce logging into blockchain. Then any manipulations with the course will be indelible.
Data reliability can increase if the data source itself sends data to a smart contract. Also, the reliability of data will be increased if contracts can exchange general information with each other. At the same time, it is possible to generate a wave of appeals to the oracle, so that time substitution becomes difficult to implement.
In case of oracle fraud, one can add to the system the possibility of protest, rollback, fixing the value of assets and recalculating them for corrected indicators. Also it is desirable to introduce the possibility of delaying the final settlement, so that to give time for filing protests and kickbacks. But the described option may not be suitable for cases where there is a need for high speed processing of financial data.
5. Dependence of program work performance from other participants
Description: It will take a long time before smart contracts are implemented by state organizations and large commercial companies to automate current processes. But even now a lot of applications are being developed, in which a lot of participants are involved at once. These applications include: the creation of a depository based on the blockchain technology, the development of microcrediting, decentralized exchanges, gamification, etc.
In all these entities, a coordinated interaction between the participants of the application is necessary. But since we have to rely on external participants to implement the incorporated functional, there is always the occurrence of a deliberate or unintended error caused by a human factor.
Example 5.1: For illustrative purposes, let’s look at a rock-paper-scissors game. This game presupposes at least two participants who simultaneously demonstrate one of the elements: stone, scissors or paper. If one of the participants has a stone and the other has a paper, then the one with the paper wins. If a stone and scissors, then the stone wins. If scissors and paper, then scissors win. If both participants simultaneously show the same elements, then the round begins anew.
Despite the seeming simplicity of this game logic, it is quite difficult to implement it completely without security flaws. As we remember, all transactions fall first in the Memory Pool, and they are available to all users of the Ethereum blockchain. If participants send game elements in the clear, then the participant who sends his item later will be able to see the opponent’s item sent earlier, thereby gaining an advantage and will be able to win the game.
To avoid such a dishonest advantage, it is recommended that the sent items be pre-hashed using a random value, the so-called salt. After all the participants sent the hashed value of the elements, the game session is considered complete. To determine the winner, you must send another transaction containing the salt and the open element, which is equal to the hashed value. At first glance, there are no security flaws, but this is not entirely true. Let’s look at the potential economic-technical shortcomings in more detail. To motivate players, we will introduce a monetary prize equal to 2 Ether, that will be given to the winner. In order to participate in the game, each user must make a contribution equal to 1 Ether.
Here are the economic-technical shortcomings that can affect the performance of the game logic:
*If one of the players, in order to participate in the game, makes a contribution, then to start the game he will need to wait until the second participant also will contribute his part of the fee. Nevertheless, it should be born in mind that this moment can never come and 1 Ether of the first participant will be frozen. Therefore, there should be a presupposed possibility to return the fee, if the participants have not joined the game for a certain time interval and have not made the necessary contribution amount;
*If both players have contributed the necessary amount of the fee, and also sent the hashed game elements, then you should also set a certain time interval to send a transaction that contains an open game element and salt. Otherwise, one of the participants, for whom the amount of the winnings is insignificant, can sacrifice his contribution to freeze the funds of his opponent. Even in the implementation of this logic, users will incur material costs to activate the method of returning the invested funds.
*If both participants constantly show the same game element, then the costs of sending a transaction can potentially exceed the amount of the win and at some stage the players will stop sending more transactions as it will be unprofitable for them; so the game will remain in the standby mode.
It should be noted that we consider a two-player gaming model. If there are more participants, then the complexity of the game implementation will grow commensurably with the number of new players.
Remedy: In applications with a large number of dependent economic entities it is necessary to provide the logic in such a way, so that it would be possible to rollback data to previous values when a timestamp or corresponding trigger occurs.
It is also desirable to provide for the possibility of imposing a penalty for an attacker in the amount of transaction costs of honest participants.
6. Probability to manipulate the order of transaction execution
Description: Most transactions used in smart contracts are public data. The data of these transactions are visible not only to the miners, but to any Ethereum network user who can access the Memory Pool. The miner decides whether to submit the posted transaction to the block by calculating various metrics, such as Gas Price and Gas Limit. Also, how quickly a decision is made whether to bring in a transaction to the block or not, depends on whether our transaction will get into Uncles, and also from the time of formation of the new block. Now the formation time of the block takes about 13 seconds. In the peak loadings of the Ethereum network, there were situations when over 4000 transactions could not get into the block for more than a minute.
An attacker can take advantage of the time interval for entering a transaction into the block in order to influence the outcome of the transaction in future.
Follow this link to get an example of a working exploit, providing the possibility of using a frontrunning attack.
Example 6.1: A classic example of demonstrating a defect is frontrunning. Frontrunning is unethical and in some cases illegal practice when the broker places his own order before a major client order, which, in his opinion, will lead to market movement. The trader receives an order from the client to buy a package of securities, but he first buys it for himself, and then sells it to the trader or the market at a higher price.
Applying this term to blockchain systems, it is possible to assume with a high degree of probability that all decentralized exchangers and decentralized exchanges are subject to frontrunning. In this case, an evil-doer can analyze the Memory Pool for transactions sent to a smart contract of the exchange. If the request for the purchase or sale of tokens meets certain criteria, then the attacker may try to force the miner to submit his transaction earlier,using, for example, a higher price for Gas Price, which in turn will result in a profit for the attacker and a change in the order book for the user .
Remedy: One of the possible ways of eliminating this disadvantage is the use of the ZkSNARk algorithm. In this case, it will be difficult for an attacker to obtain information about the data of the entire transaction and affect the final result.