# Query Processing in Blockchain Systems: Current State and Future Challenges
## 6 Overview of the State of the Art
### State of Research  
Given the problems with the State of Technology, there is also a variety of research. These can be divided into four research directions:  
**Improvements to the Frontend Query Capabilities. **_Ethereum_[110] is a popular public blockchain that supports smart contracts, which are programs with code (i.e., functions) and data (i.e., states) that run on the blockchain. It uses the key-value database LevelDB as persistent storage. [PERSON] et al. [111] extend the Ethereum-based blockchain system _quorum_ by an embedded relational database system _SQLite_ (see [[https://www.sqlite.org/index.html](https://www.sqlite.org/index.html)]([https://www.sqlite.org/index.html](https://www.sqlite.org/index.html)); accessed on 15 December 2021) next to _LevelDB_ (see [[https://github.com/google/leveldb](https://github.com/google/leveldb)]([https://github.com/google/leveldb](https://github.com/google/leveldb)); accessed on 15 December 2021) enabling SQL SELECT queries. In this system, the data of smart contract transactions are stored in the SQLite database instead of the LevelDB database. Smart contract transactions can use SQL queries (e.g., range or conditional queries), which are then executed by the relational database system. However, there are some open questions, e.g.,  
* What happens, if the data in the relational database SQLite is tampered with? * Smart contracts in Ethereum only have access to the latest state of their data. Is this also the case here? The research work of [PERSON] et al. [112] also focuses on providing SQL support in blockchains systems. However, they take a different approach. They introduce an SQL middleware, which encapsulates RPC-based (remote procedure call) interfaces of blockchain systems as SQL interfaces to facilitate SQL queries on the blockchain data, just like the aforementioned approach, where blockchain systems are enhanced with database features. Furthermore, [PERSON] et al. [113] present a data query layer called _EtherQL_, which enables a set of useful analytical queries such as range and top-k queries on the blockchain Ethereum. **Efficiency Improvements in Query Processing. **[PERSON] et al. [114] use the parallelization technique Map/Reduce to extract and analyze information from a blockchain, in their case from the Ethereum blockchain. Here, a master node instructs different jobs to worker nodes, each of which extracts data from the Ethereum blockchain and writes them to a relational database. After that, queries can be made to the relational database to obtain information from the Ethereum blockchain. [PERSON] et al. [115] present an accumulator-based authenticated data structure that allows aggregation over arbitrary attributes. This enables lightweight users, i.e., users who have only the block headers locally stored, to have service providers storing the full blockchain to execute boolean range queries, while allowing them to verify the integrity of the results. [PERSON] et al. [116] present a subchain index structure for the transaction chain. Here, the transaction chain is divided into subchains and different subchains are linked with hash pointers. The goal is to shorten the query path for queries on historical transactions. [PERSON] et al. [117] present the _AB-M tree_ structure as a storage structure for transactions, which combines the advantages of _balanced binary trees_ (fast data retrieval) and Merkle trees (fast data verification). Instead of storing transactions in an ordinary Merkle tree within a block, they are now stored in an AB-M tree. This provides faster transaction retrieval, but at the same time guarantees the integrity of the transactions. [PERSON] et al. [118] and, based on this, [PERSON] et al. [119] present a middleware layer called _Verifiable Query Layer_ (_VQL_). It extracts information about the blocks, their transactions, and possible balances from an underlying blockchain system and stores these data reorganized in one or more databases so that queries can be answered more efficiently.