# A Survey of Ledger Technology-Based Databases
## 4 Permissioned Blockchain Based Databases
### Blockchain Relational Database
#### 4.1.2 Transaction Processing  
Two approaches are identified to achieve a blockchain-based relational database between untrusted nodes. The first step of the first technique, order-then-execute, is the ordering of all transactions by a consensus service, which are then executed by database peer nodes simultaneously. The second technique has a different approach; first, database peer nodes, without knowledge of ordering, execute transactions. During execution, ordering is determined by an ordering service. The second technique has better performance compared to the first; however, the tradeoff is a greater requirement of implementations and modifications on the relational database. **Order then Execute:** submitted client transactions in the order-then-execute are required to be firstly ordered by an ordering service, followed by the execution and commit ment on the database peer node and, finally, being recorded in the checkpoint phase. This model can be seen in Figure 2.  
**Order Phase:** Clients send transactions directly to any one of a number of ordering service nodes. On an intermittent timeout (for example, every one second), ordering service nodes attempt to agree on a consensus to create a new block of sent transactions from clients. Following the construction of a block, all nodes receive the block from the ordering service by broadcast. **Execute Phase:** Following the order phase, every database node must verify that the current block is in sequence and was sent by the ordering service. Every transaction from the received block is appointed a thread. The PL/SQL procedures are executed separately on each thread with the received arguments corresponding with the transaction. Using the 'abort during commit', the SSI variant ensures the same committed state on all database nodes. The next block will only be processed if the current block of transactions is committed. **Commit Phase:** The commit phase begins after the execution of all transactions. These transactions can be committed or aborted. The order in which transactions appear in the block is the same as the order in which they are committed. This is to ensure that the commit order aligns on all database nodes. As in the execute phase, 'abort during commit' SSI variant is used to ensure execution of transactions on the same committed state. **Checkpoint Phase:** Following the processing of all transactions in a block, to ensure that the execution and commitment on all non-faulty nodes was successful, these nodes calculate the hash of the write set. This hash represents all changes made to the database by the block. This is submitted as proof for the ordering service that all prior phases were successful. This submitted proof will be the same if there were no faulty nodes that sent proof. It is not necessary for all blocks to include a record of a checkpoint. **Execute and Order in Parallel:** Having better performance than the aforementioned, as the ordering by the ordering nodes and execution by the database nodes happens simultaneously, the execute and order phases occur parallel. Following this are the commit and checkpoint phases. This model can be seen in Figure 3.  
**Execute Phase:** Clients send transactions in the same way as has been detailed prior. However, here, the database node that receives this request, sends it to the other nodes and as well as to the ordering service to be ordered in the background. Every transaction received by a database node is designated a thread. This thread is used to forward and execute the transaction. Thus, execution and ordering happen in parallel. As a result of this parallel action, a shared transaction includes the block height to guarantee the same committed data on all database nodes. **Order Phase:** The ordering service receives transactions from the database nodes, differing from the order-then-execute approach. Therefore, the ordering can occur simultaneously as a result of the ordering service, while the execution of transactions in the database nodes occurs.