# Proof of Flow: A Design Pattern for the Green Energy Market
## 4 Proof of Flow Design Pattern
### Phase 2: Energy Flows from DERs to the Aggregator  
The DER and the Aggregator are equipped by the Operator with a smart meter that measures the energy produced by the DER at each end of the transmission power line. During the normal functioning of the system, after a DER has been requested to transmit energy, as the smart meters are positioned downstream of both the DER and the Aggregator, the energy flow data are periodically measured on both sides. Such data are signed by the DER's smart meter, to prove its own identity, and saved locally. The blockstamp of the latest block in the blockchain is included in local data records to indicate the time of recording. Moreover, the Aggregator, on the other side of the transmission power line, measures the energy received by each DER, signs the data, and saves them locally in the same way. The Aggregator will use the said measures when having to reward DERs (see Section 4.3), whereas DERs use saved measures when asking for a revision of the reward amount (see Section 4.4). The data stored by the smart meters is used to generate proof that a specific amount of energy has been produced (in the case of the DER) or received (in the case of the Aggregator) within a given time frame. We dubbed this proof: \"Proof of Flow.\" Table 1 shows the data of the Proof of Flow (PoF).  
Considering the significant volume of data and the potential cost when keeping them in a blockchain storage, it is not feasible to store the whole data recorded by smart meters on-chain or in online databases like IPFS. Instead, by separating data storage from the blockchain, a more scalable and cost-effective solution is achieved. Nevertheless, proofs of energy flow are needed when potential disagreements arise. In such cases, these proofs can be automatically used to resolve them and impose penalties to the malicious actor (see Section 4.4 for details). This mechanism is a countermeasure for potential malicious behavior; it provides a further protection and strengthen trust among parties.  
The smart meter may take energy readings at regular intervals, even multiple times per second. However, it is advisable to record the average of measurements for the time span that corresponds to the creation of a block. i.e., a new record is recorded every time the value of the Blockstamp is updated. Given that the data recorded to generate Proofs of Flow (PoFs) consist of EpochNonce (uint16), Blockstamp (uint256), and \(\mathsf{kWs}\) (uint16), and that the other fields are added only when generating the PoF, the total space for a single record takes exactly 36 bytes. If a record is saved every 12 s (Ethereum's blocktime), 36 bytes would be written every 12 s, for a total of 180 bytes each minute. That is 10,800 bytes in an hour and 259,200 bytes in 24 h. If an epoch lasted 24 h, the minimum storage size required  
\begin{table}
\begin{tabular}{c c l} \hline \hline
**Name** & **Type** & **Purpose** \\ \hline EpochNonce & uint161  & time-frame to which the Proof of Flow refers \\ Blockstamp & uint256  & time of recording \\ kWs & uint16 & kilowatts of energy flow \\ ID & uint256 & unique ID of the smart meter \\ Address & address \({}^{\text{iii}}\) address of the wallet of the DER or the Aggregator \\ \hline \hline \end{tabular}
\end{table}
Table 1: Proof of Flow data types for a specific epoch.  
to archive a year of recordings would be about 90.5 MB. Since longer epochs summarize more data, the amount of storage space required decreases as the epoch duration increases. The Aggregator will store the same amount of data as DERs multiplied by the number of active DERs.