## 4 Modified Blockchain Model
### Mining  
The mining process has two basic steps. Firstly, the correctness of the transactions is confirmed, and they are placed into a new block. Secondly, a consensus protocol such as PoW or PoS is followed to obtain a chance of proposing the new block to others for validation and votes, which is explained in the following section. Now, let us focus on the correctness of transactions; indeed, there are two kinds of transactions: read and update. The read transaction only includes read operations, while the update transaction includes at least one write operation, as shown in Figure 1. Actually, Figure 1 shows examples of different kinds of transactions. T1 is a read transaction that includes only one read operation, which returns the value of the variable \(a\). At the end, the transaction tries to commit (TryC). T2 is a read transaction that includes multiple read operations for the variables \(a\), \(b\), and \(c\). T3 is an update transaction that includes only one write operation, which updates the value of the variable \(a\) with the value 5. T4 is a update transaction that includes multiple write operations to update the variables \(a\), \(b\), and \(c\), consequently with the values 1, 2, and 3. T5 is an update transaction that includes multiple read and write operations, which read variable \(a\), write to \(a\), then read variable \(c\). Furthermore, since transactions run in parallel and in isolation, the effects of the operations appear after transaction is committed. This means that the changes that result from transaction operations are not visible to the system until it commits. This may allow for inaccurate data to be read (not up to data), and may cause conflict among transactions, as illustrated in Figure 2. In fact, running a read transaction in parallel does not have any negative impact, since the values of the memory data are stable. However, update transactions change the value of the memory content. Figure 2 gives an example of four transactions running in parallel and shows how the conflicts caused the abortion of some  
Figure 1: Kinds of transactions. transactions. T1, T2, and T3 are read transactions, while T4 is an update transaction. The operations of those transactions accessed some memory variables, namely, a = 0, \(b\) = 0, \(c\) = 0, and \(d\) = 0. Actually, T1 read variable \(a\) (returning \(a\) = 0), \(c\) (returning \(c\) = 0), and \(d\) (returning \(d\) = 0). T2 read variables \(a\) (returning \(a\) = 0) and \(b\) (returning \(b\) = 1), which means that T4 changed the value of \(b\) and had already committed. T3 read variable \(b\) (returning \(b\) = 0) and \(d\) (returning \(d\) = 1). This means that T3 read \(b\) before the commitment of T4, and \(d\) afterward. T4 read variable \(a\) (returning \(a\) = 0) and updated the values of \(b\) (returning \(b\) = 1) and \(d\) (returning \(d\) = 1). In fact, the correctness of the execution of parallel transaction is confirmed when the results of parallel execution match any correct serialized execution. In other words, the transactions in parallel execution must be ordered in a logical way. Considering our example in Figure 2, T1 can be considered as the first executed transaction, since it returned all original values of \(a\), \(c\), and \(d\). T4 can be considered as the second executed transaction, since it read the original values of \(a\) and updated the value of \(b\) (\(b\) = 1) and \(d\) (\(d\) = 1). T2 can be considered as the third executed transaction, since it read the original values of \(a\) (no concurrent transaction has updated \(a\)) and \(b\) (returning \(b\) = 1), where the \(b\) value had been updated by T4. However, T3 must be aborted and ignored in the process of ordering; it could not be ordered before T4 as it read \(d\) = 1, which could only be seen after the commitment of T4, and it could not be ordered after T4 as it read \(b\) = 0, clearly ignoring the change in variable \(b\) that took place after T4 was committed.