# Process Automation and Blockchain in Intelligence and Investigation Units: An Approach
## 4 The Proposed Approach
### Overall Approach
#### 4.2.3 Blockchain Application
In the scenario of specialized units, permissioned blockchains (private or consortium) are more appropriate because of the need to limit access to more stable and restricted environments, as well as to identify participants and their operations. In the system management layer, smarts contracts are used by the participants for the execution of the transactions automatically and for providing controlled access to the ledger. Invoked by the applications, the smart contract takes the transactions and execute queries and updates on the ledger state, where transactions are stored in appended blocks and the update results are returned to the application. Current (world state) and historical information (logs) are stored in the ledger that are accessed by smart contracts. Adapted from [PERSON] et al. [45], Figure 9 illustrates the ledger operations using a smart contract. Finally, the third layer composes the infrastructure responsible for the storage of the actual digital assets (off-chain storage). Regarding storage, distributed (e.g., inter-planetary file system [62]) or centralized (e.g., cloud storage or traditional databases) approaches can be adopted depending on participant needs. With respect to the procedures performed regarding the interaction of users (through applications) and the system management layer, the main interactions are focused on queries and updates on digital assets and user data, as well as queries in log history records. Regarding asset management, all CRUD transactions in assets are recorded in ledgers allowing users to also query the log history of these transactions for auditing purposes (traceability). When user applications need to access ledgers and smart contracts, they need to communicate with peers. Figure 10 presets an illustration of the interaction between user applications and peers to access the ledgers via smart contracts. Through a peer, queries and updates can be performed in the ledger by executing smart contracts which contains the information's of transactions performed in assets. Peers and orderers are responsible for keeping the ledger up to date on all nodes. In the illustration presented in Figure 4, it can be seen that the user application connects to a peer through a channel and invokes the smart contract (SC) to query or update the ledger. The SC generates a proposal response that contains a query result or a ledger update. The proposed response is then received by a user application (in this point the process is completed for queries). A proposal may contain the identity of the user, the transaction payload, a smart contract identifier, and a transaction identifier (the proposal is also signed by the user). Figure 9: Operations in the ledger using smart contracts. Regarding updates, endorsed responses are grouped into transaction proposals by the application and send to orderers responsible for the distribution of the generated blocks to participating peers. After receiving the transactions, a validation is performed by peers in order to identify whether the transactions were endorsed by the units identified as responsible according to the endorsement policy. After updating the ledger, an event is generated by the peer and received by the requesting application. Table 8 presents information on smart contract model that can adopt operations on digital assets for the scenario of specialized units, including participant descriptions, assets, and transactions. The specialists are the system users and are linked to a specific unit, and this unit to an organization. Transactions are focused on digital assets and can be categorized (e.g., financial crimes, violent crimes, etc. ), having specific subjects. Only transactions focused on assets were exemplified.