# A Cryptography-Powered Infrastructure to Ensure the Integrity of Robot Workflows
## 5 Outlook: An Architecture for Compliant and Accountable Robot Application Development
### Distributed Ledger and Smart Contracts  
For the complAI environment we use the open source framework HyperLedger Fabric ([[https://www.hyperledger.org/use/fabric](https://www.hyperledger.org/use/fabric)]([https://www.hyperledger.org/use/fabric](https://www.hyperledger.org/use/fabric))), which provides a distributed ledger software package including the necessary tools for setting up the environment appropriately. In this context, the information shared by the peers is grouped in channels which ensures privacy of sensitive information. The channel access can be restricted by the use of certificates. Every channel consists of world state which is serialized and stored in a database and a block chain which stores the transactions committed on the state. Later modification on past transaction entries lead to an invalid block chain and can be recognized by each peer which guarantees data integrity. Furthermore, the transactions contain a digital signature of the issuer which ensures authenticity on the one hand and non-repudiation on the other hand. In addition to that, participants can initiate smart contracts in order to agree on how the ledger state can be modified. A smart contract defines an asset which the participants can work on as well as methods which can be called when committing a transaction on the ledger. If a peer whats to execute a transaction, it first has to be endorsed by a set of channel peers. If the endorsement policy is fulfilled the transaction is sent to an orderer node which defines an order of incoming transactions and stores them into blocks for the transaction block chain. After that, the block is sent out to each peer which then store the block in their replication of the transaction block chain. Figure 11 shows a concept for a distributed ledger for the complAI environment. Again, we have the client and the robot as actors along with a verification system. The picture in Figure 11 provides a logical view on the complAI distributed ledger, which means that channel state, contracts and block chain are illustrated as shared information within a channel. Additionally, each participating entity has a peer node operating on the channel. These nodes serve as an entry point for client application which want to operate on the ledger. Up to now four entities were identified during the design process:  
**The Design Environment:**: What the client uses to compose the robot application
**The Execution Environment:**: The extended execution entitity as presented in this work
**The Compliance Environment itself**: with  
* The ComplAIController responsible for setting up the ledger and running the orderer node
* The Verification Entity responsible for for verifying workflows in terms of ethical, legal safety and security aspects  
Each entity has its own Certificate Authority in order to issue access rights to external clients and additional peers if necessary. The verification process (as illustrated in Figure 12) of a robot program is implemented in form of a smart contract which is installed on the channel. When a new development is started, a new channel is opened. During the composition of the application, the verification environment provides the developer with supporting information on the requirements. This can be drawn either from automated verification methods as far as possible or from pre-developed questionnaires or from domain experts that may judge the application (such as typically done in safety certification). Each transaction independent if tool output, questionnaire or expert input is logged within the blockchain infrastructure. As the figure shows, the verification process can be triggered from the program composition environment (part of the client). Then the verification will be performed until all inputs from questionnaire, automated evaluation, and external experts has been addressed. At some point, the application can be approved and it is digitally signed for execution on the robot. The robot verifies that the signature of the workflow is valid and executes it.