## 4 Methods
### Fabric Hyperledger  
Among the field of permissioned blockchains such as Corda [46], Tendermint [47], Quorum [48], and MultiChain [49], Fabric seems to be the most popular one. It is a smart-contract platform, meaning that a transaction can execute any arbitrary (Turing-complete) code and modify the state of the blockchain. While the security of permissionless blockchains relies on game theory and the use of cryptocurrency, permissioned blockchains like Fabric avoid this problem by identifying each member--both clients and nodes--of the network and controlling their access to it. This also allows the usage of identity-based consensus algorithms like PBFT, Paxos, or Raft, which are usually more efficient than their permissionless counterparts. Fabric decoupling services (called ordering service) are dedicated merely to ordering transactions, hence releasing the rest of the network from participating in a costly consensus algorithm. The Fabric smart contract, also called _chaincode_, is an application deployed on a Fabric channel. A channel is an isolated network with its own state and blockchain maintained between a set of nodes. Only nodes being part of the channel are permitted to access the blockchain, achieving confidentiality and privacy. This smart contract is protected by an endorsement policy, which specifies conditions that must be met to invoke such a smart contract. An example endorsement policy would say that a transaction is valid if 2-of-3 nodes produce identical state changes. A state change is a set of key-value writes to the state called a _write set_, and a set of key-version reads from the state called a _read set_. Transactions are delivered to the ordering service, which batches them into blocks. A block is _cut_ once the maximum number of transactions or total size (measured in bytes) is reached, or, alternatively, when a defined amount of time elapses. The block is then broadcast to all peers in the network, which validate it, store it in their local block store (implemented as append-only files) and apply the _write set_ to their local states. Each node maintains its state in a key-value store (KVS). Transactions are, in essence, changes to the state. After executing a smart contract, the resulting _write set_ is changing the state. If the _write set_ is empty, the transaction can be considered useless, since it did not change the outside world. Currently, Fabric supports two KVSs, LevelDB (default) and CouchDB. Access to the current state is possible via GetState(key), and access to transactions which modified the state is possible via GetHistoryForKey(key). Figure 1 presents the relationship between these components. Each smart contract application runs in a docker container on every node participating in the channel. At the time of writing, Fabric executes smart contracts written in Java, Go, and Node.js (JavaScript/TypeScript). Each sensor was associated with a unique identifier that was also its key in the state. Each sensor logs the state by reading its value and wrapping it (with additional meta-data) with the transaction. Such a transaction is sent to a node, which executes it and updates the sensor's state. The sensor's state is a key-value entry in the global state (see Figure 1), where the key is the sensor's identifier and the value is a JSON-encoded object with the following structure:  
\[L=(L_{\text{id}},L_{\text{r}},L_{\text{u}})\]  
where Log \(L\) is a 4-tuple, consisting of the sensor's identifier (\(L_{\text{id}}\)), read time (\(L_{\text{t}}\)), read value (\(L_{\text{v}}\)), and measurement unit (\(L_{\text{u}}\)). In addition to updating the sensor's state, the smart contract also updates aggregated states. The aggregated state is an entry that collects aggregated data for a specific sensor and time frame.