# Enhancing IoT Data Dependability through a Blockchain Mirror Model
## 4 Practical Consequences  
Blockchain may effectively provide trust to a model that represents some portion of the real world if the life cycles of prominent objects in the model are kept in synch with mirror assets in the blockchain. This has some practical consequences that we should note. The first concerns time. In fact, it is highly recommended to mark objects and corresponding mirror assets with a timestamp. The ordinary object id serves to keep the identity of an object that corresponds to the uniqueness of the represented real-world entity and time serves to register the changes of state through the sequence of object versions (the object history). Moreover, time is a fundamental element of trust. In fact, the timestamp in the mirror object is an undeniable declaration that at that time the object identified by _a.id_ (i.e., _a.id_) possessed exactly this mirror (i.e., an image of the original object mediated by the predicate, _P(o,a)_). The second major practical consequence of the Mirror Model is that transformations of objects should be kept in synch with transactions of the corresponding mirror assets. This is the only way to ensure that objects will be trusted throughout their whole life cycle, i.e., objects that are dependable and can be processed to enforce security and reliability. To achieve this synchronization, it is necessary that whenever an object in the Representation model is engaged in a transformation, the corresponding mirror asset engages in a transaction (processed by a \"smart contract\") that keeps the new mirror asset in synch with the new version of the object after the transformation. This effect could be achieved through a mechanism of application programming interface (API) composition (Figure 3). Figure 3: Synchronized API and API gateway. Figure 2: Mirror history. It could be imaged to have two distinct sets of services structured in two APIs:  
* The Transformation API implementing the services ordinarily used to upgrade the classic information system that model the IoT scenario;
* The Transaction API implementing the \"smart contracts\" used to upgrade the ledger in the blockchain. These two APIs may be integrated and composed in one single synchronized API through the mediation of one of the many available API gateways [20]. In this way, applications (App\({}_{1}\), App\({}_{2}\),..., App\({}_{n}\)) refer to the service of a single API--the Synchronized API--that automatically keeps the Representation and Trust domains in synch, thus providing a trusted model. This approach has the nice effect of allowing for a separate design, implementation and test of the transformation API (which may be informally named \"API as usual\", i.e., the ordinary web services organized in an API commonly implemented in a software platform) and the transaction API, that is the final product of \"smart contracts\" programming. In the end, both Transformation and Transaction APIs are composed in the final and unique Synchronized API. This decomposition of efforts is a direct consequence of the initial conceptual choice to structure the model in the three domains--Reality, Representation and Trust--and it is also a proof of how abstraction may lead to practical benefits. These practical suggestions that stem directly from the theoretical Mirror Model may be applied in any practical application. We have indeed followed these design lines in the realization of a system aimed at providing Utilities Meter Data Collection and Management (UMDCM).