# Query Processing in Blockchain Systems: Current State and Future Challenges
## 5 Query Capabilities for Blockchain Technology
Thus, it is suitable to consider several of these objects at the same time. This can be done, for example, either in the form of an aggregation or viewing the data as time series to track any trends. In order to support this, a start and end point are required. However, the range queries differ here in whether the objects have block-dependent or object-dependent timestamps. For objects with block-dependent timestamps, the timestamp of a block is relevant, therefore, it must be possible to specify two block numbers. Thus, it must be possible to search between block \(N_{1}\) and block \(N_{2}\). To apply this to SQL, the SELECT start clause could be adjusted as follows:  
**Block Range. **: SELECT <attributes> BETWEEN BLOCK \(N_{1}\) AND \(N_{2}\) (where \(N_{1}\) and \(N_{2}\) of type Integer and \(N_{1}\leq N_{2}\))  
A _block range_ is necessary when a blockchain stores constant objects with block-dependent timestamps. The situation is different for objects with object-dependent timestamps. Here, the order in which the data was added to the blockchain is irrelevant, it only matters when the data was originally generated. Therefore, it is necessary to search via the timestamp of the objects. This means that only objects created between timestamp \(T_{1}\) and \(T_{2}\) are searched. To apply this to SQL, the SELECT start clause could be adjusted as follows:  
**Timestamp Range. **: SELECT <attributes> BETWEEN TIMESTAMP \(T_{1}\) AND \(T_{2}\) (where \(T_{1}\) and \(T_{2}\) of type DateTime (e.g., ISO 8601 [100]) and \(T_{1}\leq T_{2}\)) \begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Query Capability** & **Relational Data Model** & **Blockchain Domain** \\ \hline _Projection_ & SELECT <columns> An SQL statement starts with the projections, a list of columns to include in the final result set. & SELECT <attributes> Instead of columns, attributes of objects are specified. \\ \hline _Join_ & FROM <table> JOIN <other tables> This clause indicates the table from which to retrieve the data. JOIN subclasses enable the joining of additional tables. & FROM <blockchain> JOIN <other blockchains> Instead of a table, the blockchain is specified. If there is only one blockchain given, then the clause might be omitted. If there is more than one blockchain given, JOIN subclauses are required. \\ \hline _Selection_ & WHERE <comparison predicates on columns> This clause eliminates all rows from the result set where a comparison predicate does not evaluate to true. \\ \hline _Grouping \& Aggregation_ & GROUP BY <columns> This clause groups values of one or more columns in conjunction with aggregation functions in the projection on those columns. \\ \hline \multicolumn{3}{p{113.8 pt}}{HAVING <comparison predicates on groups> This clause eliminates all groups returned rows to only those whose comparison predicate does not evaluate to true.} \\ \hline _Sorting_ & ORDER BY <columns> This clause indicates the columns to use to sort the result set including the sort direction. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: The various clauses of an SQL statement and their mapping to the blockchain domain. A _timestamp range_ is necessary when a blockchain stores constant objects with object-dependent timestamps. Even though the two queries look very similar, they are internally very different from each other. Since the block range corresponds to the structure of the blockchain, such a query can be supported very efficiently. The timestamp range, however, requires all blocks between the block with timestamp \(T_{1}\) (nota bene: Even if it is not clear when an object is added to the blockchain, the insertion time (i.e., the timestamp of a block) can in no case precede the timestamp of the object (i.e., the time of capturing).) and now to be searched, since the timestamp of the actual block where the object has been included is greater than the timestamp of the object itself. Expandable objects have fields that are scattered over one or more blocks.