【论文研读】-An Efficient Framework for Optimistic Concurrent Execution of Smart Contracts

background

Each transaction in the blockchain platform is written by a smart contract. For each transaction to be successfully uploaded to the chain, it first needs to be mined by a miner (the node that wants to be uploaded to the chain, that is, a new block), and then the The mined block is handed over to the verifier (the node that has successfully mined in the blockchain for verification) for verification. If the verification is successful, the block will be uploaded to the chain; if the verification fails, the data will be refused to be uploaded to the chain. So how to judge the verification success and verification failure?

First, the miners will execute the transaction locally, that is, take a part of the transaction from the transaction queue of the blockchain platform for execution, and then send the execution result to the verification nodes of the whole network according to certain rules (consensus mechanism) for verification and summary . If the results summarized by the verification node satisfy most of the results, that is, the transaction result after execution is the same as the execution result sent by the miner, then the verification node agrees, and if the result is different, it rejects it.

However, in the process of smart contract execution, all transactions are executed serially, because the existing smart contract virtual machines do not have the function of concurrent execution, so in the current era of multi-core processors, this is undoubtedly It will cause the throughput of the blockchain to be very low. This post adds concurrency to smart contract execution and we can achieve better efficiency and higher throughput. Mainly develops an efficient framework to use software transactional memory system (STM) to execute smart contract transactions concurrently.

parallelization process

In order to perform parallel processing in blockchain smart contracts, the first problem to be solved is the dependence of transactions. Although what we can know from the data sets of most smart contract transactions is that transactions with transaction dependencies only account for 20% of the total transactions. To ensure correctness, we still need to analyze that there are transaction-dependent transactions in a set of transaction sets. That is to say, we need to create a transaction dependency graph for all transactions that have transaction dependencies, and then create transaction dependency partitions for all transactions in the transaction set, and then assign these transaction dependency partitions to different threads for execution to overcome Only one thread to execute all transactions depends on the inefficiency.

This article realizes the parallelization of smart contracts by introducing several concurrent execution protocols in the database management system into smart contracts, and also introduces multi-version database systems to combine to find the optimal concurrency control model. The final comparison models introduced include Basic Time stamp Ordering (BTO) and Multi-Version Time stamp Ordering (MVTO) . Due to the effect of multi-threaded execution, it achieves 3.6 times and 3.7 times the efficiency of mining execution and 40.8 times and 47.1 times the efficiency of validator verification compared with serial execution.

A transaction depends on a partition

But what about two conflicting transactions? For example:

(a) in this figure shows that two transactions T1 and T2 executed in parallel will write the same data x, which belongs to a piece of data in the blockchain. Figures (b) and (c) mainly show that when conflicting transactions are executed in different orders, the results are different. That is to say, when transaction T1 and transaction T2 have a transaction conflict on the same data, when miners execute in parallel, T1 will be executed first, and T2 will be executed later, resulting in the final value of x being 20, while the verifier When performing parallel execution, T2 will be executed first, and T1 will be executed later, resulting in an x ​​value of 10.

This solution to the above problems in other papers is to build locks between transactions that have transaction dependencies to ensure that transactions can be rolled back, and finally ensure that the execution of transactions is serial execution.

What this article adopts is to use the timestamp protocol in the software transaction memory to ensure the consistency of the final result. Why can the above problems be achieved by using the timestamp protocol in the software transactional memory? See what the Timestamp Protocol actually accomplishes...

Timestamp protocol

Single Version Timestamping Protocol

basic definition

• The timestamp sorting protocol is used to sort transactions based on timestamps. The order of transactions is nothing but the ascending order of transaction creation.

• The old transaction has higher priority, that's why it executes first. To determine the timestamp of a transaction, the protocol uses system time or logical counters.

• A lock-based protocol is used to manage the ordering between conflicting pairs of transactions at execution time. But the timestamp based protocol starts working once the transaction is created.

• Suppose there are two transactions T1 and T2. Assume that transaction T1 enters the system at 007 times, and transaction T2 enters the system at 009 times. T1 has higher priority, so it enters the system first, so it executes first.

• The timestamp ordering protocol also maintains timestamps of the last "read" and "write" operations on the data.

Fundamental

The basic timestamp ordering protocol works as follows:

1. Whenever a transaction Ti issues a Read (X) operation, the following conditions are checked:

• The operation is rejected if W_TS(X) >TS(Ti).
• If W_TS(X) <= TS(Ti) then perform the operation.

Update the timestamps of all data items.

2. Whenever transaction Ti issues a Write(X) operation, the following conditions are checked:

• The operation is rejected if TS(Ti) < R_TS(X).
• If TS(Ti) < W_TS(X) then reject the operation and roll back Ti, otherwise perform the operation.

in:

• TS(TI) represents the timestamp of transaction Ti.

• R_TS(X) represents the read timestamp of data item X.

• W_TS(X) represents the write timestamp of data item X.

Multi-Version Timestamping Protocol

In the multi-version timestamp ordering technique, for each transaction in the system, a unique timestamp is assigned before the transaction starts executing. The timestamp of transaction T is TS(T). For each data item X, a sequence of versions <X 1 , X 2 , X 3 , ... XK > is associated.

For each version Xi of a data item (X), the system maintains the following three fields:

• Version value.
• Read_TS(Xi): The read timestamp of X i is the maximum timestamp of any transaction that successfully read version X i .
• Write_TS(Xi): The write timestamp of X i is the maximum timestamp of any transaction that successfully wrote version X i .

To ensure serializability, the following two rules are used:

Suppose a transaction T issues a read request and a write request for a data item X. Let X i be the version with the largest Write_TS(X i ) among all versions of X that is also less than or equal to TS(T).

• Rule 1: Suppose transaction T sends a Read(X) request, if Read_TS(X i )<TS(T), the system returns the value of Xi i to transaction T and updates the value of Read_TS(X i ) to TS(T)
• Rule 2: Suppose transaction T issues a Write(X) request TS(T) < Read_TS(X), then the system aborts transaction T. On the other hand, if TS(T) = Write_TS(X), the system overwrites the contents of X; if TS(T) > Write_TS(X) it creates a new version of X.

mechanism

Use the method of adjacency list to build block dependency graph. As shown in the figure below:

where ts is the timestamp of submitting the transaction (unique), $A{U}_{id}$The id of the atomic unit executed for the transaction Ti. In order to maintain the vNode node as decremented, we initialize inCnt to 0. When there is a dependency relationship, we can modify the inCnt with the dependency relationship to the corresponding value (executed in the dependency graph order), and eNext and vNext are the edge connection points for building the dependency graph in the dependency graph.

The algorithm of how to construct the dependency graph mainly uses five algorithms in a lock-free library: addVert(), addEdge(), searchLocal(), searchGlobal() and decInCount(). (The specific algorithm is similar to the algorithm for building a connection table)

The Process of Parallel Mining

1. Get trades from the trading platform
2. Execute transaction calculations in parallel and calculate the final state of each variable
3. Generate a conflict table (or a transaction dependency graph)
4. Calculate the hash value of the previous block
5. Generate the value that needs to be generated inside the final block
6. Push to all verification nodes for verification

Summarize

It mainly compares the results of the parallel execution of smart contracts between single-version timestamp and multi-version timestamp protocols. It is mainly biased towards the application of transactional memory system (STM) in smart contracts, so the reference value of this article is mainly How to use timestamps and prove formulas.

Appendix - Algorithms

Simple Auction Contract

line2: the address of the auction transaction
line3: the auction end time
line5: the address of the highest auctioneer
line6: the bid of the highest auctioneer
line7: connect the address of the highest auctioneer with the bid
Function:

1. The current time exceeds the auction time, an exception is thrown
2. The bidder's bid is less than the current price, an exception is thrown
3. High bidders and record bidders and bids within a reasonable time

Parallel Execution of Miners

Validators execute in parallel (according to block dependency graph, BG)