The intelligent contract from the perspective of concurrency (Next) "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."

4. Ownership and authority

Another way to ban unwanted intervention in contracts is to design a custom license contract that controls the set of operations allowed by different aspects.

First, if we enforce a limited access rule, we can avoid the problem shown by the two-thread example in Figure 3 and block any content that asserts its status X. For example, you can query/modify its state by representing up to one thread at any time. This will grant the corresponding thread exclusive ownership on the object [30], thus proving the assertion that the state of the object is made locally from the thread.

Exclusive ownership, in the traditional sense, is obtained by prohibiting any intervention, but the individual has a major change in the state of the contract, Ethereum's contract guarantees unique ownership. For example, Figure 5 (left) shows the changed version of the counter contract, so no other party can interact with it except for its "owner." Ownership rules are executed by the solidity cosmetic mechanism, allowing people to provide custom dynamic check pre/post conditions for the function. In our example, the Byowner modifier will be enforced, and the get and set of the functionality will only be on behalf of the fixed party-contract owner reference.

Fig. 5. Exclusive (left) and read/lock (right) contracts

This is a fairly crude solution because it means excluding any concurrent interactions in the contract. However, from a point of view, the contract as a concurrent object of the view is very obvious, please see our analogy: Account number is a thread. In fact, as Figure 5 shows, applying a specific ownership rule to a contract is similar to enhancing its Java counterpart by explicitly checking thread. CurrentThread (). GetId ().

Now let's try to further drive the comparison between the account and the thread by designing a counter with more detailed access rights. We will make sure that an "interested" account (that is, "thread") makes its value immutable (because the internal logic may depend on its immutability) and that it is not allowed to be modified by other parties. Similarly, if a party currently has the sole license to modify the contract, the other party may not be allowed to read it. The solution to this synchronization problem is to read/lock by name [6], which is well known in the concurrent community. Its implementation needs to track the thread that is currently reading and writing the shared object, so the thread should explicitly obtain the appropriate permissions before performing a read/write operation, and then release it when it is finished.

The right-hand part of Figure 5 shows the basic part of the read/write locking contract implementation. Two new fields, tracking current active readers and writers. The new modifiers CanRead and CanWrite will be used for the omitted get and set operations. Finally, as long as there is no active writer in the system, Acqureadrock allows its caller to acquire the lock and register through the reader mapping.

We can see that the threading analogy is very effective. We have proposed some solutions to solve possible synchronization problems, which can be carried out verbatim in the concurrent literature. The only drawback to the proposed solution is that it is a fairly holistic fact: The contract now combines the functionality of the data structure (that is, the counter) with the synchronization primitives (i.e., locks). In section 5th, we will discuss possible ways to improve the implementation of modularity.

Considerations for formal reasoning and validation. Formal inference about license accounts and all state-separated access is a subject of long-term research in shared memory concurrency literature (see Overview for example [8]). Formalization, such as concurrent separation logic and [30] Fractional/counting permissions [6] provides a flexible way to define abstract ownership rules and verify that a particular implementation is faithfully followed. For example, our read/write lock contract can be proven to be secure (i.e. no concurrent modification) by the formal permissions model of Bornat and others [6].

5 Discussion

5.1 The preparation of the contract

The locking contract "pattern" considered in the 4th section has a significant extension: its design is modular. In other words, the locking mechanism is implemented by the contract itself rather than by third party data. Unlike the good practice of software engineering, it is recommended that synchronization primitives, such as normal and reentrant locks, be implemented as stand-alone libraries that can be used to manage access to client-specific resources.

But once the locking logic is released from the contract, the inference about the behavior of the contract becomes more difficult, because in order to prove the preservation of its internal invariants, it is necessary to understand the attributes of the locking protocol, such as the uniqueness of the editor, which is outside the contract. In other words, the contract verification can no longer be carried out in isolation, and a model needs to be established to allow for the inference of contracts that interact with other strictly specified contracts. The idea of releasing the contract logic is not just what we think it is, but it is crucial in the development of the contract. For example, the same idea is advocated as a way to implement Ethereum upgradeable contracts by introducing and adding additional levels of indirection [11]. A "contract factory" with another contract that can be invoked by either party constitutes a verification challenge similar to proving the security attributes of higher-order concurrent objects (i.e., working with other objects) [19].

The idea of combinatorial reasoning and interdependence and high order concurrent object validation using concurrent logic has been a hot topic in the past decade [12,33,34, 37]. And most of them focus on the concept of protocol, in the case of simultaneous updating, as the object behavior of the abstract interface, while hiding low-level implementation details (that is, the actual code). We believe that by leveraging our analogies, we will be able to develop a modular validation approach for this multiple-contract interaction.

5.2 Activity

With the introduction of locking and exclusive access, there is another concurrency-related problem: the progress of the inference contract implementation and the activity attributes. For example, it is not difficult to imagine a situation where a specific account registered as "reader" in the example in Figure 5 might never release the reader lock, preventing others from changing the future status of the contract. Being active in this situation means that there will be good things in the end, which means that either side has the appropriate incentive to unlock it. In concurrent terms, such assumptions can be redefined as the fairness of the system scheduler, making it possible to reuse existing proof methods for progress in single and multiple-contract execution [25] and the modular reasoning that terminates [18].

6. Related work

The formal inference of intelligent contract is a new and exciting one, which is suitable for describing the behavior of contract, which is worth studying. In this section, we relate our observations to the existing results of formalizing and validating contract attributes, outlining the areas that will benefit from our concurrency analogy.

6.1 Verification Contract implementation

Since DAO bug [9], the Ethereum community has been focused on preventing similar errors and using common tools for program validation.

Currently, the contracts written by solidity can be annotated with a Hoare-style predecessor/Post condition and converted to OCaml code [32], so they can be validated using the Why3 tool, which uses automation to exclude the generated validation conditions [16]. This method is valid for verifying the basic security attributes of the solidity program, such as the particular variable that always resides within the bounds of a particular array index, and the retention of the general contract invariants (usually in one form, if the linear equation on the value of the UINT value variable) method boundary and before the external contract call is performed This is also the DAO contract violation.

Bhargavan and others have recently translated solidity subsets (no loops and recursion) [5] to F-a programming languages and validation frameworks, based on dependency types [35]. They also provide translations from EVM bytecode to F programs. These two methods can use F as a uniform tool for validating contract properties, such as invariant saving and no unhandled exception, encoded as an effect by F on the support of the index Hoaremonad [36]. Pettersson and Edstr [31] Adopt a similar method of specifying contract behavior and dependency types, and they implement an effect based small contract DSL as shallow embedded into idris[7], with executable code extracted to serpent[14] A python-style contract language.

Hirai recently completed the full specification of the ethereumvirtual Maine [22] in lem[28] to the Isabelle/hol validation Assistant, for the mechanized verification of contracts compiled into EVM bytecode, There are a number of security attributes that include assertions about mutable states and missing potential reentrant. Unlike previous methods, the formalization of Hirai does not provide a syntactic approach to structuring and combinatorial proofs (for example, through Hoare program logic), and all inferences about contract behavior are performed from low-level execution semantics [38].

Compared with these jobs, which focus primarily on low-level security and invariance preservation, our observations suggest a higher level of formal meaning for capturing the attributes of contract behavior and its communication with the outside world. In particular, we consider the use of the abstract state conversion System (STS) [29] as an appropriate form of communication, using established toolset such as TLA+[24, to track contract execution and activity properties. In order to connect such abstract representations to low-level contract codes, it is necessary to demonstrate refinement between high-level and low-level representations, that is, between STS and code [3]. In a sense, finding a suitable contract invariant and proving it through WHY3 or F verifies that the refinement between a state-transition system makes the unique state the state of the invariant description, as well as an implementation that retains it. However, we expect that more complex STS will be required to infer contracts with preemption concurrency.

6.2 Pushing global contracts

[27]. Luu and others found that, due to interference, some contracts are prone to unintentional or confrontational abuse of the view. They look at the problem as we have shown in the Counter example in section 3rd, transaction Order dependency (TOD), which can be summed up as a question of unrestricted interference according to our concurrency analogy. Luu's solution to the TOD problem requires changing the semantics of the Ethereum transaction and providing a similar primitive to the Testandset in Figure 4. Although the advantage of this approach is that there is no need to modify a contract that has already been deployed (only code that interacts with client code needs to change), it is necessary for all relevant users to upgrade their client applications to consider the changes. In essence, the Luu solution is for very specific concurrency patterns: by adding block-supported read-modify-write primitives to enhance the synchronization provided by the atomic registers. Recognizing the nature of the problem implies that our analogy may suggest alternative contract solutions, such as engineering lock-in agency contracts. However, the disadvantage of this approach is that it needs to be foreseen at the time the contract is designed and deployed. In other words, the ability to model this behavior allows us to believe that our metaphor can be achieved.

7. Conclusion

We believe that our comparisons between intelligent contracts and concurrent objects can provide new perspectives, stimulate research, and allow for effective reuse of existing results, tools, and insights into how to debug and validate complex contractual behavior in Distributed ledger. As a metaphor, we should not act verbatim: on the one hand, there are indeed concurrent problems that seem almost impossible to observe in contract planning; On the other hand, intelligent contract executives should also be cautious about the notion that there is no direct correspondence in the concurrency field, such as gas Execution and fund management.

In short, we leave the reader with a few guesses, inspired by our observations, but neither resolves nor opposes:

-The common concurrency challenge in the non-garbage collection language is the uniqueness of the tracking heap location, which can be recycled and reused later-called the ABA issue [10]. Due to the lack of due diligence, the ABA problem may result in the violation of object state integrity. We can imagine a similar situation in a multiple-contract environment.

-Continue to compare, if the chunk chain is considered a shared state, then the mining protocol defines the priority of the schedule. We can leverage the insight of effective concurrent threading management to analyze and improve existing distributed ledger.

-linearized [21] (also known as atomicity) is the standard concept for specifying the correctness of advanced behavior for a lock-free concurrent object. For composite contracts with multiple transaction operations (such as blockking), what is the de facto consistency concept of equivalence.

Original: https://zhuanlan.zhihu.com/p/29354702