## 4 Methods
### Main Elements  
On a general level, we can distinguish three types of cooperated elements:  
1. Sensors--IoT devices producing logs and sending them to nodes;
2. Nodes--servers that are receiving signals from sensors, co-creating blockchain networks, and storing logs in immutable form;
3. Clients--systems or users querying nodes for individual data or aggregated results stored in nodes.  
Data flow starts with a sensor reading its state, encrypting it, and wrapping it in a blockchain transaction. The sensor then sends the transaction to some available node. This node broadcasts the transaction across the peer-to-peer network, and upon a successful consensus round, updates its state. The transaction is then saved in an immutable repository based on blockchain.  
Depending on the implementation, the blockchain is stored in files or some kind of database. In both cases, querying such a big data set is time-consuming. We need to consider the case where we collect a stream of hundreds of events and then want to effectively offer them to others. Therefore, to achieve real-time queries, we need to employ some optimization techniques that we present in our model.  
We propose to change classical one-way chain data organization into a time-based tree hierarchy aggregation scheme combined with a computed pattern to achieve efficient querying. A time-based tree hierarchy means that we are creating an overlay tree structure that can be easily indexed by time periods. The computed pattern means that we compute results ahead of query time and store them back in the blockchain, replacing the computation overhead with a storage overhead by keeping all the pre-computed values in the database.  
We perform computation at the same moment when new data are saved into the blockchain. Computation is performed in different sliding windows for specified aggregation functions. In the result, if the user needs to compare, e.g., the maximum value for a day, he can query our repository for a pre-computed value and compare it with the value computed in another system. In classical solutions based on blockchain, we would need to query the whole blockchain to find the maximum or average value. What we do instead is to pre-compute these queries for each time frame and store the aggregated values in the blockchain state. As a result, the query can be quickly retrieved without the need to fetch the whole blockchain history.  
Implementation of the aggregation process depends on the capabilities of a blockchain platform. Platforms equipped with smart-contract capabilities, a.k.a programmable transactions, can perform aggregation as a part of the storing-log-transaction, whereas platforms without smart-contract capabilities have to introduce a component responsible for producing aggregated values.  
The final structure contains blocks with two types of transactions: original data from IoT and additional information that summarizes data from IoT stored in the same block and that summarizes data that was registered in previous blocks. Each summarization transaction contains also the IDs of the first and the last block that describe the range of blocks whose values were aggregated.  
To present how the proposed model can work, we prepare the implementation on two heterogeneous blockchain platforms. The first one uses the Stellar blockchain, and the second one uses Hyperledger Fabric. We decided on these two because besides immutable storage, they have little in common; therefore, the successful application of our method on both of them indicates desirable versatility.