# A Blockchain-Based Real-Time Power Balancing Service for Trustless Renewable Energy Grids
## 5 Assessment of the Results
### Network Congestion  
Congestion conditions in the blockchain network proved to change rapidly and unpredictably, thus affecting the performance of our application in a significant way. As previously mentioned, the transaction confirmation times are highly susceptible to network overloads not only for obvious delays in the network components, but also for a demand/supply mechanism that causes the gas price to rise, thus causing the overall gas cost of transactions to follow suit. This circumstance has two major consequences: on the one hand, the transaction emitted with a lower gas price than the current average one, determined by the congestion conditions, risks not being confirmed by the mining  
Figure 11: Execution logs from the simulation tests showing an error message from the RPC interface to the Energy Web Volta test network. It explains the occurrence of a problem actually impeding the correct execution of the simulation set-up phase. Specifically, going past the 290 prosumers limit exceeds the max limit for the gas cost of one transaction, the one the simulator uses to reset its simulated IoT data registered in the ledger before restarting.  
protocol within acceptable time frames; on the other hand, a higher transaction cost can undermine the balance of blockchain accounts or even prevent them from transacting, in case of insufficient funds (see Figure 12).  
A massive reduction in gas price volatility and transaction costs may be introduced by permissioned blockchain technologies, where the network access can be regulated by selected nodes, so as to prevent intolerable congestion situations. Better scalability and security performances in permissioned blockchains are obviously obtained at the detriment of the decentralization dimension, as stated by the \"blockchain trilemma\". However, in a public blockchain, a certain decrease of decentralization can be regarded as critical, not as much in enterprise environments where, with the same decrease percentage, the system can still exhibit an elevated degree of decentralization towards the authorized participants.  
Whereas the application logic would expect a rapid and sequential transaction processing, the system may experience a disordered and discontinuous response, based on the congestion conditions of the validator nodes and, in particular, in our prototype, of the RPC interface node. In the worst cases, crossing public networks can favor the occurrence of situations in which some transactions, already in the transaction pool for confirmation in a definitive block, may randomly remain \"pending\" for an indefinitely long time without any feedback to the sender.  
To limit the above problem, it can be convenient to connect the aggregator, which generates transaction bursts by design, to the blockchain network with more reliable mechanisms, such as an internal Inter-Process Communication (IPC) channel, a private connection, or an IP tunnel (i.e., a VPN). We have observed that this actually relieves the problem, as this guarantees that the packets will be received by the blockchain network sequentially.