# A Blockchain-Based Real-Time Power Balancing Service for Trustless Renewable Energy Grids
## 4 Prototype Decentralized Application
### Aggregator Smart Contract  
A smart contract was designed to regulate the interactions between the aggregator and its managed DERs, exhibiting the following functionalities: (i) registration and updating of the contractual agreements of a DER; (ii) the transmission of modulation commands to registered DERs and accounting for the implemented modulations on the DERs' blockchain accounts. The DApp set-up phase takes care of deploying the developed smart contract catering to the tasks to be executed in the blockchain, and the aggregator is the account owner of the smart contract implemented in Solidity. The smart contract management of contractual agreements was implemented in the following operations: registerAgreement(), reviseAgreement(), and cancelAgreement(), which are used to govern the creation of a contractual agreement with a DER, to later alter its terms, or to allow deleting it, respectively. Such operations were executed as part of the transaction requests started by the DERs. The contractual agreements will take into account data about the energy source type, the expected amount and price of the produced energy, and the flexibility that the DER is expected to provide. Upon successful termination of one of this type of transaction, a smart contract internal data structure named agreements, containing the data of registered DERs' contracts, will be correspondingly updated. The second main functionality of the smart contract regards the power modulations. Such transactions will be started by the aggregator and will use the following data:  
* Flexibility: the percentage of modulation that the network must produce with respect to the baseline;
* Start: the deadline by which all DERs must reach the required modulated value;
* End: the indication of the moment from which the DERs have fifteen minutes to return to baseline. The DApp allows a Transmission System Operator (TSO) to issue a modulation request command specifying the baseline percentage to be altered. The Ethereum blockchain event mechanism was used to allow the aggregator to collectively notify an aggregate modulation request to the whole pool of DERs while storing the relative instance data in the blockchain transaction logs. This dramatically improves performance, as the aggregator avoids having to referto a long sequence of transactions for any time-critical interaction with the DERs. The system reaction for an aggregate modulation request sent to IoT devices is shown in the sequence diagram sketched in Figure 3, and the corresponding sequence of interactions is also detailed in the following. IPC Handler is a component letting the Electron-framework-based front-end communicate with the server side. Tracker handles the global timing for the events. 1. Upon receipt of a user-generated aggregate modulation request from the front-end user interface, parameterized by the overall modulation amount and the two timestamps for the beginning and end of a desired duration, the aggregator saves such data for later in an internal flexibilityRequestdata data structure, and upon the aggregate modulation, start: time, will invoke the requestFlexibility() smart contract function. ii. Operation requestFlexibility() emits a RequestFlexibility() event to be published on the blockchain logs, to notify about the modulation request each DER in the managed pool, in parallel. The DERs' IoT devices (simulated by the IoT objects) intercept the notifications of this event, by means of a specific event watcher implemented in the smart contract (an event watcher is a specific Web3 functionality that allows a requester to be notified when a filtered event occurs in a blockchain log). iii.