Methods of protecting decentralized autonomous organizations from crashes and attacks

Field of study: Blockchain technology, decentralized autonomous organizations, smart contract and their resistance to attacks and failures. Theoretical and practical significance: Due to the fact that such a form of organization is experimental, participants often face problems of attacks on the organization, the consequences of incorrectly written rules and of fraud. The task of creating decentralized autonomous organizations that are resistant to failures and attacks, and research on the causes of such problems has become relevant for software developers and architects. Goals and objectives of work: Investigation of attack algorithms and development of methods for ensuring the sustainability of decentralized autonomous organizations for attacks on the basis of analysis of the subprocesses of border events and logs using the methods of Process Mining. The methods to be developed should promptly identify and prevent inconsistencies between the alleged and actual behavior of smart contracts that lead to such errors in the operation, such as the content of spam contracts, empty transactions, increased block processing time, etc.


Blockchain and crypto-currencies
In the past few years, thanks to the popularization of blockchain technology, which represents a continuous series of blocks containing information, built according to certain rules, there were created many services and applications using various crypto-currencies [13]. Many crypto-currencies are inextricably linked with this technology for such reasons: decisions on the blockchain do not require trust between the participants, they are open and validated. Success of the Bitcoin, decentralized crypto-currency with the capitalization of more than $ 10 billion, is of genuine interest both in industry, government, and in science [2]. A whitepaper, written under the pseudonym Satoshi Nakamoto in 2008, is the basic document for any form of organization created on blocking technology. This document for the first time outlines the Bitcoin structure and introduces the concept of blockchain [30]. The theoretical basis used in the creation of decentralized autonomous organizations is based on the research of automatic verification systems [31,32], cryptography [33,34] and distributed databases [35,36].

Decentralized autonomous organizations
The economic theory and research of organizations [19,20], the theory of contracts [21,22], auction mechanisms [23,24], the theory of innovation [25,26], as well as virtual organizations [27,28] played an important role in the emergence of decentralized autonomous organizations [30]. Bitcoin can be called the very first decentralized autonomous organization created to carry out paid transactions [1]. The most famous decentralized autonomous organization, based on the Bitcoin code, was created in 2014 and was given the current name Dash in March 2015. Dash is currently experiencing a stage of rapid growth. In September 2017, the company's market capitalization was $ 2.5 billion. However, the most promising platforms for the development of decentralized autonomous organizations are platforms that use smart contracts and the Turingcomplete programming language, such as Ethereum [2]. On April 30, 2016, the first decentralized crowd-funding project, known as The Dao (Decentralized Autonomous Organization), was launched on the Ethereum blockchain platform. The organization was established as a venture capital fund with transparent and democratic flows of project financing, in which each investor would have a voice whose weight is directly proportional to the funds invested. The technology of smart contracts was laid for the first time in the basis of the functioning of the organization The DAO. The Dao in record time attracted more than $ 168 million in investment almost immediately became a target of intruders and was repeatedly attacked to steal or freeze funds. As a result of one of the attacks, more than $ 50 million was stolen from the organization, and as a result of the other, more than $ 150 million was frozen [14,16]. The imperfection in the code of smart contracts and the existing vulnerabilities, as well as the inability to change them lead to so-called softfork and hardfork. The Dao is not the only decentralized organization deployed on Ethereum. Fermat (www.fermat.org), Digix.global also operate on the Ethereum blockchain platform and are managed collectively by the participants who own the tokens by voting.

Smart contracts
In 1994, cryptographer Nick Szabo proposed the use of cryptography and computer technology to automate the process of concluding, executing and auditing various contracts [29]. The development of this direction led to the creation of smart contracts on the basis of the blockade -special electronic algorithms introduced into the block, where they are monitored by the decentralized computer network itself. This allows you to expand the capabilities of the block-up to a computing platform for centralized execution of common tasks [5]. Smart contracts allow you to exclude from the process of intermediaries because computer algorithm independently and automatically confirms the fulfillment of the terms of the contract and determines what to do with the asset for which the contract was created. Smart contracts are protected from uncoordinated changes in the terms of the transaction, allow you to automate the audit and make it in real time. The most famous framework for smart contracts is Ethereum, a decentralized virtual machine, where the Turing-complete programming language is used to create smart contracts. A distinctive feature of Ethereum is the ability to transfer ETH crypto currency between users and contracts. Users create transactions on the Ethereum network in order to create a new contract, call a contract, or transfer ETH to a contract or another user. Blockchain allows you to track the status of each contract and the balance of each user. Smart contracts are unchangeable: after they are deployed in the core network, updates and changes are not possible, they are publicly available. The main serious problem of creating smart contracts is their formal verification: for example, in the Etherium network, verifying the decentralized virtual machine (EVM) code is very difficult, so unverified smart contracts are often the subject of hacker attacks. Later in the article, known vulnerabilities and attacks will be examined using the example of the Ethereum network and the distributed decentralized autonomous organization The Dao. In this article, special attention will be paid to the security of decentralized autonomous organizations, which are based on smart contracts, examines examples of existing attacks. The problem of attacks on DAO is currently relevant, although it is currently not very well covered [2,4].

Structure of the DAO based on smart-contracts
A decentralized autonomous organization is a supposedly "democratic" organization operating in a distributed network through a combination of "smart" contracts and a rich scripting language. Technically, DAO is the implementation of a financial service by performing all necessary calculations directly in smart contracts when using the scripting language. A distributed ledger, for example, a host, provides a secure environment for computing and storing data across the entire network, and, as a consequence, eliminates the need for a central trusted party [1]. As an example of the structure of a decentralized autonomous organization, TheDAO can be considered, where the main smart contract is used, serving as a "factory" for sub-contracts, the number of which is already in the millions. Smart contracts in Ethereum run on Ethereum Virtual Machine (EVM), the predominant language of contracts is Solidity. A smart contract is an autonomous agent with its own software logic, an identification address in the network and the associated balance of the Ether. After the initialization, the contract code can no longer be changed, the contract can be called repeatedly and stored on the network forever, until it executes the bytecode of the suicide instruction, after which the contract is no longer subject to a call and is called dead [7,9]. Each contract call is carried out by sending a transaction to the address of the contract together with the input data and charges (the so-called gas). Ideally, the entire mining network performs a function call and skips or does not miss the contract, depending on the consensus reached, based on the consensus protocol. The result of the calculation is replicated through the blockchain and provides a commission for the transaction for the miners in accordance with the established interest rates. In addition to being used as a reward, the service fee also protects against denial-ofservice attacks when an attacker tries to slow down the entire network by requesting time-consuming calculations. Each operation consumes a certain level of gas, the upper consumption threshold and the unit price of which are indicated in the transaction. Unused gas comes back, and if during the calculation all gas was consumed, then the process stops and all gas is lost. EVM allows contract functions to have a local state, while contracts themselves can contain global variables stored in the blockchain. Contracts can also refer to other contracts via message calls. The output of these calls is part of the same transaction and is also returned during the runtime of the transaction. It is important to note that calls can also send the Ether to other contracts and non-contractual addresses. The balance of the contract can be read by any member of the blockchain, but it can be changed only by calls originating from other contracts or initiated from outside the transaction. Only contracts with white list addresses can receive funding from the organization, and track the addition of new contract addresses, the main purpose of which is financing, curators [9]. The main motive for the introduction of human control is the screening out of malicious addresses, through which the "51% attack" is carried out, the purpose of which is to transfer most of the company's funds to one block. After adding the contract address to the white list, further decisions on it are made by voting all the holders of the tokens. At the time of voting, the balance sheets of the voters are "frozen" to the voting results. The withdrawal of funds from the organization is possible only by creating a sub-organization, where the withdrawing funds is the sole curator. The decision on separation (creation of a new DAO) is also adopted by a general vote. The entire process of creating a new DAO takes a little more than 30 days [4,10].

Vulnerabilities of DAO
Attacks of the DAO system based both on the technical imperfection of the system and on the behavioral characteristics of the DAO participants [15,16,17]. The behavior of participants allowed the appearance of the following types of attacks, some of which are still used for malicious actions in the system [4]. Stalker Attack. During the separation and creation of a subsidiary DAO in order to withdraw funds from the system (the withdrawal is possible only under this scheme), an attacker can seize tokens created by the DAO and have a negative impact on the withdrawal of funds. Attack of the last moment. At the last moment of voting, a large investor is added with a hug number of tokens with which he votes "yes" and pushes an unprofitable or absurd project. Attack of the value of the token. Sowing panic among tokens holders, forcing to sell tokens, and not invest in system projects. There is a buying up of tokens at a low price and the acquisition of a larger stake in the DAO. Attack of extra-balance. The attacker provokes the separation of DAO to increase the book value of tokens. The more participants are separated from the DAO, the higher the value of the extra balance as a percentage. Attack of 53%. Despite the huge amounts of 53% of DAO funds and curatorial verification of the addresses of financed contracts, there is a possibility of cartel collusion with the aim of raising funds for interrelated projects. Attack of parallel voting. For the voting period, the balances of the voters are blocked, which can be used for voting for a malicious contract with a smaller voting period. Attack on reward. To reduce the payments to the separated participants of the system, the remaining participants can deliberately create overheads for maintenance by looping money in fake contracts. Logical vulnerability of voting. The nature of voting in the existing DAO does not allow to build a logical chain during voting. For example, (vote "yes" the proposal A if the proposal B is not funded). Because social processes are non-linear, it is impossible to foresee how competing or conflicting proposals run simultaneously. Attacks that exploit the behavioral features of the system, for the most part, require tremendous resources and considerable training, while attacks based on technical vulnerabilities and bugs can be carried out with minimal costs, thus such attacks are the most interesting and dangerous. According to the studies [5], the Ethereum blockchain contains over 34,000 vulnerable smart contracts per 1 million researched contracts. Vulnerable contracts were divided into 3 conditional groups: suicidal contracts, prodigal contracts and greedy contracts -such contracts allow either to block funds for an indefinite period, or to destroy the contract after implementation, or allow leakage means of purse to arbitrary users. There are several types [2] of major vulnerabilities that make the contract dangerous for the system. Call to the unknown. When the code is illiterate, the call, send, and delegate call primitives can result in sending to an unset address or returning a broadcast by calling a backup function. Exception disorder. In Solidity, exceptions are used in the following cases:  the gas has ended;  the call stack has reached the limit;  a command throw is executed [2]. However, in some cases (often these are chains of nested calls), exceptions can lead to an unplanned cancellation of the actions performed, while gas consumption is not returned [11]. Gasless send. The lack of gas in the transmission of Ether can cause unpredictable behavior. Type casts. Using the compiler does not guarantee the correct operation of the contract. Reentrancy. It can often be confusing to realize that if a function is not recursive, then it will not allow repeated repetitions. However, this misconception can lead to the fact that a non-recursive function starts a cycle of calls that ultimately consume all the gas [11]. Keeping secret. Fields in contracts can be both private and public for all users. However, declaring a field private does not guarantee its inaccessibility to others. This is due to the fact that to set the privacy of the field, the user must send the corresponding transaction to the miners who will then publish it in the blockchain. Since the blockchain itself is public, any user can check the contents of the transaction and make changes to the privacy of the field. In order to best protect the contract field, you need to use suitable cryptographic methods [12]. Immutable bugs. As already known, after the publication of the contract in the detachment, it is already impossible to change it, so contracts with errors can manifest themselves completely unpredictably. Sometimes, when the consequences of executing such contracts have an extremely negative impact on the entire detachment, the community comes to the decision to use softfork or hardfork. Ether lost in transfer. Some addresses in the blockchain are not associated with either specific users or contracts, so when sending airtime to these addresses, it is lost irrevocably. Stack size limit. The stack size is limited to 1024 frames. Every time there is a call to another contract or even yourself, the stack size increases by 1. If the rules for rejecting a call when reaching a stack limit are incorrectly set, then the attacker has the opportunity to exploit the vulnerability. The vulnerability was closed in 2016 by limiting gas at a rate of 63/64 from the existing one. Since the current gas limit is limited to 4.7M units, the depth of the stack is always less than 1024. Unpredictable state. When sending a transaction to the network, the user can not always be sure of the status of the contract, which is determined by the cost of its fields and balance. This can happen because at the time of sending the contract status was changed by another transaction, or the contract contains dynamic variables associated with other contracts. Such vulnerability can be used by attackers to link the called contract to malicious components that allow stealing the broadcast. Generating randomness. Due to the fact that execution of the bytecode on EVM is deterministic, i.e. all participants as a result of processing the transaction should receive the same result, unless otherwise specified, to obtain non-deterministic results, some contracts (for example, games, lotteries) use pseudo-random number generators. Such blocks usually have timestamps. The vulnerability lies in the fact that an attacker can try to create his own block with the content controlled by him in order to evade the result of the generator and shift the probability of distribution of pseudo-random numbers. Time constraints. Time constraints are used to identify permitted or mandatory actions and contain a timestamp that is consistent with all participants in the process. Contracts can extract timestamps and set their own. Attackers can exploit this vulnerability to gain temporary advantages over other participants in the process. The Threat of Quantum Computing. One of the potential vulnerabilities is the instability of cryptography to quantum attacks. The most popular public-key encryption algorithms, for example, RSA in the near future can be destroyed with the help of a quantum computer.

Levels of attacks on smart-contracts
In connection with the fact that the basis of any decentralized autonomous organization is the implementation of smart contracts, the main attacks are aimed at them. The existing vulnerabilities of smart contracts can be conditionally divided into three classes, depending on the level at which the vulnerability is detected (Solidity, EVM bytecode, blockchain). Each vulnerability class can spawn one or more known attack types [2,16,17] (fig. 1). In the study [2], the simplest test DAO was simulated, on which the following attacks, existing in real Ethereum, were made. The DAO Attack. In the well-known attacks on the DAO, the purpose of which was to seize the organization's funds, the call to the unknown and reentrancy vulnerabilities were exploited, which could have a negative impact, because the broadcast was broadcast before the credit was reduced. Examples of contracts used in attacks:

Contracts G P S Type casts
Keeping secrets

Contracts P
Call to the unknown At first glance, contracts seem fair, but the lack of a send return check (1) and intentional call exceptions (2) can result both in unfair winnings and in theft of contract funds after the game is over. Attack in games with multiple players. In such games, hidden fields are often used, which are unknown during the game, but can be opened at the time of joining the game (vulnerability keeping secrets). An example of a similar game with existing vulnerabilities is represented by a contract Using data from private fields, an attacker can lead a strategy of permanent winnings. Attack of Rubixy. Was implemented in contracts that use the Ponzi scheme (financial pyramid). Attack was possible because the developers renamed the contract with DynamicPyramid Rubixy, forgetting to change the name of the constructor, which then became a function that everyone can call. Instead of a single use of DynamicPyramid when setting the owner's address, which is allowed to take profit, this function was used by intruders to set their addresses as owner addresses.
Attack GovernMental. As well as above, the contract is implemented by the Ponzi scheme. Money receives the final invested after 12 hours except for the fees of the organizers. After that, the array is cleared with the data of the participants. At some point, the list became so huge that it took much more gas to clean up the arrays than the maximum allowed for a single transaction. A simplified version of the game with all the existing vulnerabilities looks like this This scheme was also subjected to attacks using the exception disorder and stack size limit vulnerabilities. Thanks to these vulnerabilities, it became possible not to pay the winners to win by launching a new round of the game. Also, dishonest miners used the possibility of not adding new blocks to be the last ones invested, or adding a timestamp to the block in such a way that the block would become the last one each time. An attack using dynamic libraries. Such attacks use the Unpredictable state vulnerability, since it is possible to update the library with malicious content after the publication of the contract.

Potential mitigations and solutions
Having considered the above vulnerabilities and attacks based on them, it is possible to draw conclusions and understand the need for steps to be taken in the field of DAO security. Confidentiality. Many mistakenly accept conditional anonymity of transactions in the blockchain for real: transactions are recorded and stored in the public registry and are linked to the address of the account that does not contain information about the real person behind this account. However, identifying information can be obtained through web trackers and cookies. In addition, the required data is often contained directly in smart contracts [17]. Lack of confidentiality is a serious threat when it comes to medical records, identity documents, credential management, and a number of closed financial documents. Strengthen confidentiality in several ways:  addresses on the Diffie-Hellman-Merkle protocol on elliptical curves (ECDHM) will allow the use of the secret key by the two sides of the process;  creation of a decentralized mix-protocol for joining a group of payments into one pool, with the possibility of tracking amounts in a private registry, without a third party;  evidence with zero disclosure -the preservation of confidential information and at the same time the certification of its availability; it can be achieved by authentication of the "call-response" to verify the transaction, using the zkSNARK (zk-zero-knowledge, SNARK-Succinct Non-interactive Adaptive Argument of Knowledge) module for verification; it will make certain contract variables private, ensuring that they are stored out of the blockchain by users who using the SNARK protocol to prove that they adhere to its rules (requires a prior "trust"); the use of the zkSTARK (T-transparent, i.e. transparent) block is a simple protocol that relies solely on hashes and is better protected of quantum computers, because it does not use elliptic curves;  use of obfuscation (code entanglement);  use of oraclesparties transferring information between smart contracts and external data sources;  use of the trusted environment for program execution.
Verification of smart contracts. The development of tools for verification, the introduction of verification formats will make sure that the smart contract behaves the way it was intended. The complexity of verification of smart contracts lies in the complexity of verification of the EVM bytecode. Verification of smart contracts will also reduce the risk of virus infection and hacker attacks. Verification guarantees greater accuracy, than traditional approaches, for example, testing [8].
Perfection of intra-organizational processes. Improving the voting processes by introducing a grace period that allows the movement of non-voting funds, adding the function of the voting office, prolonging the voting time for a statistical release, attracting more users to the process, developing secure withdrawal methods will prevent a number of attacks and increase trust in the system. Improving the mechanism for achieving consensus. The use of the existing PoW (Proof-of-Work) protocol, which depends on computing power, jeopardizes the decentralization of the system and makes it possible for a cartel plot. Because Major mining pools have a great advantage over private miners in the extraction of blocks and profit distribution, centralization occurs in the blockage and several large mining pools own more than 70% of the hash. A more advanced PoS protocol (Proof-of-Stake) practically excludes the possibility of bundle aggregations in terms of computing power, but at the same time it requires solutions to problems such as «Nothing at stake», when forming forecaster, the miners vote simultaneously for several different blocks on one altitude, or start fork from any place, getting validators of previous participants and creating a million blocks in a new blockchain, preventing users from understanding which of the blockchain is «correct». Creation of the necessary tools for development.
At the moment, in the ecosystem of the toolkit of the developer of smart contracts, the weak points are:  Integrated Development Environment (IDE);  the code assembly system and compiler program;  deployment tools;  storage medium;  debugging and logging tools;  security audit;  analytical tools. Improving the development toolkit will have a positive impact on the functioning of the entire DAO.