BugBounty.Center brings to your attention the final part of the report “The Main Economical-Technical Threats for Blockchain Applications”. Developed by the co-founder of the company Grigory Vasilkov.
7. Vagueness of changes in the value of assets
Description: The cryptocurrency market is constantly in motion and it is very difficult to predict, and even more to reveal the regularity, what will be the the rate of this or that currency in a long time. But it can happen that the logic of the developed application obviously depends on the rate of cryptocurrency or tokens, and developers need to build the application model in such a way that the possible fluctuations of the rate are to be taken into account.
Example 7.1: Let’s analyze the following model of the smart contract work. Assume, there is a commercial company that provides cargo transportation insurance services. Because of the strong volatility of the Ethereum rate and the need to work with contractors, the company decides to hedge the received Ether tokens against the US dollar. Thus, knowing in advance the exact price at which Ether is received, the participants of the transaction insure their risks from the likely fluctuation of the exchange rate at the cryptocurrency market and, as a consequence, the change in the market price of the insurance service. If something happens to the goods during shipping, the insurance company undertakes to reimburse the damage in Ether, but with reference to the previously hedged rate.
If the cost of Ethereum increases during the payment of insurance, then in this case, even after payment of insurance, the insurance company will have an additional profit. If the cost of Ethereum decreases, then the company will incur huge losses, up to the announcement of bankruptcy.
Solution: At best, you need to track the change in the value of assets and make the appropriate changes to the smart contract. If a smart contract is autonomous over a long period of time, then such a scenario is not always possible and requires a different approach to solve the problem.
8. Delays in obtaining information
Description: Despite the fact that we live in a world of high technologies and high speeds, we can not deny the fact that sometimes the speed of obtaining data does not match the claimed one or the resource has availability problems. It may even happen that the needed centralized resource has undergone a DDOS attack, or some country has decided to block it on its territory.
Still, inside the enclosed decentralized systems, the delay in obtaining data may also take place. For example, if a smart contract depends on certain data of another contract that a third-party system participant should add.
Timing problems can also include a race condition when a transaction is included in a block, if the transaction is not in that uncles, or the network block is overloaded due to the large number of transactions sent.
Example 8.1: Let’s assume the logic of a smart contract is based on the periodic receipt and processing of data from a certain external source. If the required source is for some reason unavailable for a long period of time, then the smart contract will not be able to fulfill the logic inherent in it and will spend all available means to access the inaccessible source.
Remedy: In emergency situations, when there is no possibility of receiving information from external sources, there should be a possibility to enter data into the application manually.
9. Discrepancy in the data received
Description: If you properly develop the architecture of any application, you should not trust a single source of data retrieval. The data acquisition chain is very long and potentially can be compromised at any place. The correct solution would be to receive data from several independent sources and compare them. If the data are different, this discrepancy should be noted and actions should be taken.
Any resulting exceptions are fairly easy to handle in centralized applications. In decentralized applications there are many nuances that are not always easy to foresee.
Example 9.1: Suppose that our decentralized application refers to an external source for the current rate of the cryptocurrency. In order to protect themselves from data substitution, the developers provided for the possibility of parallel access to another external source for obtaining the current rate of cryptocurrency. If the difference is more than 3%, then the system should make requests until the rate meets the necessary conditions.
Considering that the volatility of the cryptocurrency on various exchanges is really significant, the difference in value between them can be more than 30% over a long period of time. In the described situation a smart contract can spend all the funds for accessing external sources, not having proceed with the required operation.
Remedy: The remedy is similar to the previous paragraph. In unforeseen situations, when there is no possibility of obtaining information from external sources, there should be a presupposed possibility for manual data entering.
10. Dependence of work performance of smart contracts from other smart contracts
Description: Sometimes, for the ease of use, smart contracts use third-party libraries or even address third-party calls of other contracts. This architectural implementation can help with the process of updating smart contracts, but at the same time makes the application itself depend on the performance of third-party programs and libraries.
Example 10.1: If the logic of the referred smart contract is changed or the smart contract is destroyed, for example by using the self-destruct operation, then the performance of the program will be at risk. The implementation of this shortcoming was demonstrated on November 8, resulting in the blocking of more than 500,000 Ether.
Solution: Do not completely rely on a third-party contract that you do not manage. It should also be noted that even if the contract code does not contain a call to the self-destruct method, it can still perform this operation using ‘delegatecall’ or ‘callcode’.
11. Difficulties in predicting and influencing the incoming data
Description: When developing a smart contract, the developer must provide for various options to obtain input data. If the data obtained does not match the expected data, then an exception must be invoked. But it can happen that the input data will match the expected mask, but be fundamentally different from the current valid data. For example, when a developer expects to receive only an integer value as a variable, but forgets to provide a range of possible values.
Example 11.1: Suppose that a smart contract, which is a decentralized exchanger, refers to the exchange for receiving the current rate of cryptocurrency or tokens. An attacker can try to extract this transaction from the Memory Pool and, using his own means, try to change the requested rate for a short time, especially if the traded volume is small.
As soon as a smart contract will bring the received exchange value into the blockchain, the evil-doer will exchange values at the price necessary to him.
The way of mitigation: It is necessary to foresee different variants of input data and call corresponding freezing methods if something goes wrong, especially this touches the logic of the application that works with financial data.
12. Disclosure and influence of own data on the result of work
Description: When developing applications in the blockchain system, it should be born in mind that all data transferred between the platform participants is open, unless any cryptographic means of information protection is used in advance. Therefore, it is always worthwhile to understand that everything we do in the blockchain systems is available for analysis to others.
Blockchain is not anonymous by nature, it is just unpersonalized. This means that if only one time it will be possible to detect the address of the user’s wallet, then any participant will be able to compile the necessary picture of the relationships of the given user and make appropriate conclusions about his or her preferences.
Open data for all participants of the system can significantly affect the application work progress.
Example 12.1: Suppose that the developed smart contract implements the function of selling a specialized product on a tender basis among several buyers. Even if we assume that the transmitted data, between the buyers participating in the tender and the seller, are encrypted, then the competitor only needs to personalize the addresses of the accounts of buyers who are interested in the products, in order to offer each of them a specialized price. In this case, the firm that conducts the tender can stay without customers.
Solution: Use the ZkSNARk algorithm if you do not want to disclose the details, because they are confidential and secret. ZkSNARk can simply show part of the process without showing the whole process, and prove that you are honest.
ACKNOWLEDGMENTS
Thanks for comments and advice on the research to:
Arthur Pinchuk
Roman Grebnev
Alexander Bazhanov
Maxim Lazarevich
Konstantin Turovets
Pavel Buka
Margarita Zhakovich
Congratulations @bugbountycenter! You have received a personal award!
Click on the badge to view your Board of Honor.
Do not miss the last post from @steemitboard:
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Congratulations @bugbountycenter! You received a personal award!
You can view your badges on your Steem Board and compare to others on the Steem Ranking
Vote for @Steemitboard as a witness to get one more award and increased upvotes!
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit