Intelligent contract from the perspective of concurrency (ON) "Raven Paper Series" __ Intelligent contract

Thesis Author:

Ilya Sergey1and Aquinas Hobor2

1 University College London, United Kingdomi.sergey@ucl.ac.uk
2 Yale-nus College and School of Computing, national University of Singaporehobor@comp.nus.edu.sg

Translation: Raven

"Let the domestic and foreign block chain technology no time difference."

Write in front of "new column":

The translation of the paper is extremely painful.

But our goal is "let the domestic and foreign block chain technology no time difference."

To bring you more block chain technology dry goods.

Capacity is limited, but also ask the great God a lot of supervision, advice.

Welcome to contribute, both in English and Chinese.

Summary:

In this article, we explored the significant similarities between the multiple transaction behavior of intelligent contracts such as ethereum and the classic problem of shared memory concurrency. We examine two real-world examples from the Ethereum block chain and analyze how they are susceptible to errors that often occur in traditional concurrent programs. We then elaborate on the relationship between observable contractual behavior and the in-depth study of concurrent topics, such as atomicity, interference, synchronization, and resource ownership. A similar analogy to the description of the concurrent objects allows you to learn more about the potential threats of smart contracts, guide practice, and use the most advanced forms of existing authentication techniques.

1. Introduction:

An intelligent contract is a program that is stored on a block chain, a Byzantine fault-tolerant database. A smart contract can be triggered by a block chain transaction and read and write data on its block [38]. Although intelligent contracts are run and validated in a distributed manner, although there are many complex interaction patterns, including, for example, reentrant and recursive calls, their semantics indicate that they can be treated as sequential programs. This mental model simplifies formal and informal reasoning about contracts, allowing immediate reuse of existing generic frameworks for program validation [5,16,31,32], which can be used to validate smart contracts such as writing. Curing [15] only minor adjustments.

Although all calculations on the block are deterministic [1], some nondeterministic calculations still occur because of the competition between the transaction itself (such as which transactions are selected for a given block). We will show that non-determinism can be exploited by hostile parties and that reasoning about contractual behavior is particularly subtle and reminiscent of the known challenges involved in traditional parallel programming.

In this article, we outline the concurrent execution properties of the smart contract. This execution can be transacted across multiple block chains (within the same block or blocks), thereby violating the required security attributes that are not specified by using only the implementation and local state of the contract, which is the concern of existing authentication methods [5, 32]. To facilitate the reuse of common programming, we propose the following analogy:

An account that uses a smart contract in a block chain is like a thread that uses concurrent objects in shared memory.

A thread that uses concurrent objects in shared memory. Through concurrent objects, we mean a large number of data structures that are used to exchange data and manage interactions between multiple threads (processes) running concurrently [20]. Typical examples of concurrent objects are blocks, queues, and atomic counters-typically used by databases such as Java,util,concurrent. Also, at run time, these concurrent objects are allocated to shared memory blocks that are accessible to the running thread. The behavior that arises when a thread accesses an object simultaneously-that is, the disturbance is unpredictable and therefore extremely difficult to understand.

It does not use the appropriate synchronization of concurrent objects (for example, with locks or obstructions) can be under the interference of data competition [2] behavior, resulting in loss of memory integrity. Even for a competition-free object, the observed interference behavior may be wrong in the opinion of one or more clients. For example, a particular thread might not "anticipate" the action taken by another thread with a shared object, and therefore might not expect the object to change in a disturbing manner.

The account uses the smart contract block. Smart contracts are similar to concurrent objects. They are stored in chunks rather than in a shared memory; Not used by a thread, but by an account (user or other contract). Like concurrent objects, they have an internal mutable state, manage resources (such as funds), and can be accessed in blocks and across multiple blocks. Unlike traditional concurrent objects, because of the computational transaction model, the method of intelligent contract is atomic. That is, a single call to a contract (or a series of calls to each other) is executed sequentially-without interruption-and terminates or aborts after a successful update of the chunk chain and returns to the previous configuration.

However, the concept of "atomic freedom" is deceptive because concurrent behavior can still be observed at the level of the block chain:

-The order of the transactions included in the transaction is not certain when the transaction is executed, so the result can depend to a large extent on the ranking of other transactions [27].

-Several programming tasks need to spread the logic of the contract across a number of block-chain transactions (for example, when the contract is "communicated" to a world outside the block) to achieve real concurrency behavior.

-Invoking other contracts can be considered a multitasking collaboration. With multitasking, multiple threads can run, but do not interrupt unless they are explicitly "generated." In other words, a call from contract A to contract B can be considered a profit from the perspective of contract A, and contract B proceeds on return. The key to a smart contract is that contract B can run code that is not recognized by the designer of contract A, which makes the situation closer to the concurrency setting than a typical sequential device. [3] In particular, contract B may modify the state that contract a can assume during the call. This is the essence of DAO error [9], where contract B invokes contract A to modify the local state of a, before returning [27]. However, re-entry is not the only error that manifests itself because:

-It's not hard to imagine a contract being used as another block (user and contract) to manage access to shared resources and, in a sense, as a concurrent library. As multiple transactions become more common, the various observed patterns of interference should also be taken into account.

Our goals and motivations. Fortunately, the study of parallel and distributed programming over the past 30 years has provided code for a large number of theoretical and application frameworks, specifying, justifying, and formally validating concurrent objects and their implementation frameworks. Therefore, the objective of this article is twofold. First, we will briefly outline some of the known concurrency issues that may occur in the smart contract, characterizing the problem in more traditional concurrency abstractions. Second, our goal is to establish an intuitive "good" and "bad" contractual behavior that can be identified and validated/tested accordingly, using existing formal methods to infer concurrency.

2. Example of concurrent behavior

Here we discuss two contracts that have been deployed on ethereum blocks, each of which illustrates different aspects of concurrent type behavior. Blockking's contract, like many other people in today's Ethereum group, has achieved a simple gaming game [2]. Although blockking is not widely used, we study it because it shows the potential use of the Oraclize service [4], which is a service that allows the contract to communicate with the world beyond the block, thus understanding true concurrency. Many other contracts that use oraclize may be reflected in their implementation because of the early adopters of the Oraclize service presenting it as a demo of the service and providing its source code for free.

The second example we are discussing is a widely studied error in DAO [1]. DAO and more than 18,000 investors have established an owner-managed venture capital fund; it attracts 14% of the etheric currency that existed at the time. The ensuing attacks cost investors about 3.6 million ether, at a time worth about 50 million dollars. DAO uses what we call "uncoordinated multitasking," because when DAO sends money to the recipient, that recipient can run the code, interfering with the DAO's contract state through the DAO's contract state, assuming that the DAO will not change during the call.

2.1BlockKing contract

Blockking's gambling is as follows. At any time, there is a designated "Block King" (originally the editor of the contract). When the sender sends the currency to the contract, a random number of J is generated between 1 and 9. If the current block Number 10 equals J, then S becomes the new block king. After that, Blockking received a certain percentage of the money in the contract (depending on the parameters, from 50% to 90%), the contract editor will receive the balance.

In deterministic systems, it is difficult to generate high-quality random numbers, especially when all data is publicly stored, and for attackers there is economic incentive. Therefore, Blockking uses the service of the trusted party Wolframalpha to use the Oraclize waiter as its random number. Assuming that oraclize is a good behavior, this random number selection strategy should be the attacker's prediction.

Blockking's code has 365 lines, but the code given in Figure 1 is very interesting; The line number here is the actual source code of the contract given by Etherscan[2. When the currency is sent to the contract, the input function is invoked. It sets some contract variables (line 299-301), and then sends a query to the Oraclize service (line 303).

Figure 1. Blockking code fragment [2]

The Oraclize_query function raises an event to be visible in the real world and then returns to its caller and exits (row 304). In the real world, the Oraclize server monitors the event log, service requests (in this case by contacting the Wolframalpha Web Service), and then makes a new call to the original contract at the specified callback point (line 306 in blockking). Many things can happen between events and their callbacks, in which block calls can eject several blocks before calling Oraclize_query and restore control at callback time. During this time, the state of the block, even the blockking contract itself, may change dramatically. In other words, this is the real concurrency behavior on the block.

What can go wrong. Suppose multiple gamblers want to try their luck in a short time (even in the same block). The contract did not attempt to track this behavior. As a result, each new entrant will overwrite the previous data (key warrior blocks and warrior variables) in row s 299-301. When the callback finally occurs, the last contestant in the batch will have multiple opportunities to win the throne of the contestants who participated in the other callbacks in the batch. The culprit is the 第339-347 line from the Process_payment function, called the last line of the callback function in row 309.

Each process_ payment function, called the Warrior block, is computed and stored in the variable singledigitblock. [4]. Each time the Process_ payment function is invoked, he has a new chance to match the random number in line No. 339. If the number matches, the final contestant is crowned on line No. 345.

2.2DAO contract

DAO's source code has 1,239 lines, more complex than blockking [[23] because the bug has been written a lot (for example [9,27]), so we just give the key line in Figure 2. The problem is the order of Line 1012th, which (through a series of further function calls) sends ether to Msg.sender, and in 1014 rows, the account of the msg.sender of the 0-odd number is zero.

Fig. 2. DAO generation buy Clips [23]

In a sequential program, reordering two separate operations has no effect on the final behavior of the program. In concurrent programs, however, the effect of a sequential, innocuous reordering can have a significant effect, because the order in which the operation takes place can affect how the thread interferes. In DAO, the ether is sent in line 1012th, and in some multitasking sense, the control of an arbitrary (potentially malicious) contract located in Msg.sender is generated.

Unfortunately, the DAO internal state still indicates that the account has been funded because its account balance has not been cleared in line 1014th. As a result, a malicious msg.sender can initiate a second recall by calling back the DAO contract, which will be paid once the control reaches 1012 rows. In fact, a malicious msg.sender can start a third, fourth, etc withdrawal, all of which will result in payment. Only after many multiples of the original balance was paid, his account was eventually cleared.

Previous analysis of this bug indicates that the problem is recursive or unexpected reentrant. In the narrow sense, this is true, but in a broader sense, what is happening is the meaning of sequential code running in concurrent environments.

3 Intervention and synchronization

3.1 Atomic updates in shared memory concurrency

Figure 3 depicts an example of an incorrectly used concurrent object (rendered in a similar Java8 pseudo code) that should use the get and set methods to implement the "atomic" counter. Because the synchronization primitives are used, the implementation of the concurrency counter on the left is clearly thread-safe (that is, no data competition) [17]. However, the problem is how to use an instance of the counter class in multithreaded client code on the right.