# Proof of Flow: A Design Pattern for the Green Energy Market
## 5 Discussion
### Block Time, Epoch Duration and Contract Expiration  
As already mentioned, the block time, that in the case of Ethereum is twelve s, determines the pace of the blockchain, e.g., the speed at which a blockchain can add data or change its state. This characteristic affects the actors relying on the blockchain to exchange or store data, as well as perform transactions. In our case, while block time represents the minimum amount of time that actors have to wait to detect a change in the blockchain, the epoch \(E\), (proportional to the block time), can vary. As noted earlier, an appropriate duration \(E\) for the epoch has to be chosen. Too short epochs may lead to higher costs as they involve more transactions, while long epochs can delay the updates to DERs' financial  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Function** & **Scenario** & **Number of DERs** & **Gas Units** \\ \hline Deployment & Registry & - & 231,024 \\ Deployment & ARIA & - & 3,620,829 \\ Deployment & Vault & - & 493,662 \\ Join() & - & - & 239,713 \\ SweepEpoch() & supply start & 1 & 212,391 \\ SweepEpoch() & ongoing supply & 1 & 164,662 \\ SweepEpoch() & supply end & 1 & 164,848 \\ SweepEpoch() & supply start & 5 & 444,786 \\ SweepEpoch() & ongoing supply & 5 & 551,031 \\ SweepEpoch() & supply end & 5 & 619,309 \\ SweepEpoch() & supply start & 10 & 735,426 \\ SweepEpoch() & ongoing supply & 10 & 1,076,641 \\ SweepEpoch() & supply end & 10 & 1,197,481 \\ \hline \hline \end{tabular}
\end{table}
Table 5: Measures of gas consumption when deploying smart contracts and when executing significant smart contract’s functions.  
balances for their produced energy. Conversely, when an entity needs to communicate with another, using the blockchain events, as when the Aggregator requires production modulation or notifies a DER that it has been chosen for energy production, its request can be submitted independently of the SweepEpoch() function; i.e., the request need not be synchronized with the function that governs epochs.  
The value of \(E\) depends on the type of blockchain being used. In a private blockchain, which could be employed to aggregate DERs within a tightly knit area such as a neighborhood, islanded microgrids, or nanogrids, and where transaction costs are minimal, the value of \(E\) can be low, potentially as low as 1. Otherwise, when using a public blockchain like Ethereum, it may be impossible to keep up with the block time since transaction costs for the smart contract execution may be high as already said above. In this scenario, by setting the epoch to 72,000 blocks (running the SweepEpoch() function every ten days) the frequency of transactions is low. Then, during periods of network congestion, the value of \(E\) can be increased to mitigate the impact of high gas prices. This strategy, coupled with the division of fees among Aggregator and involved DERs, strikes a balance between regular updates and computational operations to minimize transactions costs.  
In relation to the expiration of the contract, we propose a flexible contract duration, denoted by \(d\) epochs, during which a DER must provide energy. Once a DER's contract expires, the SweepEpoch() moves it back to the list of the prospective DERs, from where it can be selected again for the renewal of a new contract. This approach optimizes DER contributions by considering their capabilities, their ranking (when applicable), and the energy needs.