# ID-Service: A Blockchain-Based Platform to Support Digital-Identity-Aware Service Accountability
## 3 Case Study: A Biomass Production Chain
### PIM Smart Contract Implementation  
The _platform-independent model specification_, PIM in short, gave clear guidance in the implementation efforts to be carried out, once a definite technological choice had been made, according to domain-specific criteria.  
We used Solidity, the premier programming language for Ethereum Smart Contracts at the moment. The implementation created retains its property of being process agnostic. That means: regardless of the process' specific field of application, a smart contract mod  
Figure 2: Model of a simple biomass production chain process.  
elled according to the specified requirements, supports subsequent process mining efforts easily. The _finite state machine_ is also a kind of behaviour that can easily be created using language-specific features, like invocation modifiers.  
Code must, not only, support the PIM, but also respect the platform uniqueness. For example in Ethereum, every transaction or, specifically, smart contract call, costs a certain amount of gas. Gas is a way to measure the resources needed to accomplish a certain computation on the distributed, EVM based network. The deployment itself of a smart contract also costs gas, and such price heavily depends on code size: keeping code short, concise, and reusable is considered a definite plus.  
So, it is preferable to keep code as simple as possible, avoiding loops, redundant writes, and unnecessarily complicated data structures.  
Also, it is very unwieldy to update smart contract code, while retaining all the information contained within. Standard techniques should be employed, such as the usage of specific design patterns (e.g., _Check-Effects-Interactions_ and _Create-Read-Update-Delete_), and code must then be thoroughly tested.  
It should be noted that we used a slightly modified version of the classical Check-Effects-Interactions pattern: we moved away from the construct _require_ using a simple _if_ check to emit an event logging the unexpected condition (Listing 1).  
```
if(log.isLogged(_sender)==false){ emitTradeFailed(_sender,_receiver,_valueTradeHash,msg.sender); returnfalse; }
```  
Listing 1: smart contract code.  
In order to correctly implement our PIM, we created a function for each edge connecting one state to another, and, for each function, exactly one event describing a correct execution, and a certain number of other events emitted whenever execution encountered a particular error. Data were laid out to support the multi-FSM behaviour: the Create-Read-Update-Delete pattern was used to keep track of every new information exchange performed by actors. Structs and enums, instead, were put in place in order to contain relevant data, such as actors' UIDs, and timestamps. As an example, here's the signature of the _OfferTradeSigned_ function in Listing 2.  
```
functionofferTradeSigned(bytes32_sender,bytes32_receiver,bytes32__valueHash, uint_tmuot,uint8 sigV,bytes32 sigR,bytes32 sigS)returns(boolsuccess) public()
```  
Listing 2: smart contract code of OfferTradeSigned function.  
This function implements the very first edge found in the PIM, with blockchain native signature checking. A correct execution of this particular function results in the emission of an instance of the event in Listing 3.  
```
eventTradeOfferPlaced(bytes32 indexedsender,bytes32 indexedreceiver, bytes32 valueTradeHash,addressindexedcallingAn)
```  
On the other hand, if the sender tries to re-enact an information exchange performed already in the past, execution stops, and the event in Listing 4 is emitted.  
```
eventValueAlreadyTrade(bytes32 indexedsender,bytes32 indexed valueTradeHash)
```  
By applying the same principles for the other remaining functions, a fully functional implementation is obtained.