# A Blockchain-Based Real-Time Power Balancing Service for Trustless Renewable Energy Grids
## 4 Prototype Decentralized Application
### Aggregator Smart Contract
Upon event notification, every notified DER has to implement the modulation, for three times or stages: a modulation start transient, where the DER output power will rise from the contractual baseline value to the requested modulated value; a modulated regime stage, where the DER will hold this modulated power value steady; and a modulation end transient, where the DER will gradually return to its contractual baseline. Upon completion, the DER will call the smart contract's provideFlexibility() function, passing it the modulation amplitude it declares to have accomplished, which potentially could turn out to be either compliant or non-compliant with the issued request. iv. The aggregator, by monitoring the parallel real-time data flow from the DERs' smart meters, can check and determine whether the modulation declared by each DER is truthful (matches the real-time smart meter readings) and whether it conforms to the requested modulated amplitude or not. Similarly, at the aggregate modulation _end_: deadline, it will invoke the endFlexibilityRequest() smart contract function, with the list of collected results. This, in turn, will save those data in a flexibilityResults data structure and emit the EndFlexibilityRequest() event to notify about this result the DERs. Figure 3: Sequence diagram of interactions to implement an aggregate modulation request issued. * Upon this last notification, the DERs invoke the provideFlexibilityFare() function to register their contribution and claim a corresponding contractual reward, by means of a non-repudiation blockchain transaction. This transaction will have the aggregator as the counterpart and will actually be successful if and only if there has been an agreement on the conformity of the DERs' implemented modulation. The aggregator pays a credit to the prosumers for their contribution in restoring the unbalanced power network. The prosumers can then use this credit to pay for their next transactions or their own eventual power consumption bills. The aggregator would take this money out of its profits for energy selling. The smart contract's internal storage is only used for the state variables required by its functions and includes the data structures shown in Listing 1. ```
addresspublicimmutableaggregator;//aggregator;saccount int256 publicenergyBalance;//instantaggregatepower mapping(address=>Prosumer)publicprosumers;//prosumers'states mapping(address=>Agreement)publicagreements;//prosumers'contracts address[]publicprosumerslist;//prosumers'accounts FlexibilityRequestpublicflexibilityRequest;//requestedaggregatemodulation mapping(address=>int256)publicflexibilityResults;//prosumers'modulation outcomes
```  
Listing 1: State variables for the smart contract governing DERs. The smart contract defines and makes use of the event types in Listing 2. ```
eventRegisterAgreement(...); eventReviseAgreement(...); eventCancelAgreement(...); eventRequestFlexibility(...); eventEndRequestFlexibility(...); eventFlexibilityProvisioningSuccess(...); eventFlexibilityProvisioningError(...); eventRewardProduction(...);
```  
Listing 2: Events defined and used by the smart contract governing DERs. ```
eventRegisterAgreement(...); eventCancelAgreement(...); eventRequestFlexibility(...); eventEndRequestFlexibility(...); eventFlexibilityProvisioningSuccess(...); eventFlexibilityProvisioningError(...); eventRewardProduction(...);
```  
Listing 3 provides a code snippet simulating the invocation of the smart contract's requestFlexibility() function.