The growing adoption of Distributed Energy Resources (DERs), such as small-scale green energy producers that feed into the main grid energy gathered by photovoltaic power plants or small wind turbines, has given rise to Aggregators, a new category of energy players in electricity markets [1,2,3]. Aggregators play a crucial role by ensuring fair and reliable compensation for the energy supplied by DERs and facilitating the seamless integration of intermittent energy production from renewable sources into the distribution network [4]. An Aggregator is responsible for supplying an overall baseline power (aggregate power) to a higher-level entity (company), hereafter termed the Operator, which manages electric lines and other power grid devices to serve residential, commercial, and industrial consumers.

From the viewpoint of system software architecture, researchers are actively exploring various approaches to aggregating and coordinating DERs, with a view to addressing key challenges and enabling efficient energy management. While standards like OpenADR (Open Automated Demand Response, https://www.openadr.org, accessed on 25 July 2023) are available to address the goal of interoperability among different systems (by a common format for message exchange), several other noteworthy, high-level, concerns are still awaiting satisfactory solutions. Such concerns include, e.g., reliable orchestration and data storing, incentives to behave fairly, resolution of potential disagreements, etc.

Thanks to its decentralized nature, blockchain is immune from vulnerabilities caused by single points of failure. Also, blockchain-run code, or smart contracts, can be used to store on the blockchain permanently data that cannot be altered later on and are visible to any interested player, thus ensuring transparency and fairness, and reinforcing trust. For these reasons, blockchain has been widely acknowledged as an effective framework for designing distributed applications and achieving decentralization and transparency [5,6,7].

Nevertheless, in this respect, there are several outstanding issues. To begin with, simply relying on efficient consensus algorithms to ensure the consistency of the blockchain state is, admittedly, not sufficient to prevent malicious behavior by participants. When employing a technology that is known to be vulnerable to attacks, this possibility must constantly be addressed [8,9,10]. In addition, while the blockchain has the potential to reduce disagreements due to its transparency feature, current approaches lack specific procedures for addressing and resolving disputes that may arise between a DER and the Aggregator [11,12,13,14,15]. Moreover, many approaches use the blockchain essentially to handle financial and energy balances [16,17,18,19,20], and, due to the large amount of interactions and data typical in the energy market, possibly incur in excessive cost for the use of blockchain computing and storage resources.

Design pattern, named Proof of Flow (PoF), was proposed to govern the interactions between DERs, providing electrical energy to the system, and an Aggregator that manages the DERs according to the energy flows it detects and the requests made by the Operator. Accordingly, the proposed framework, besides catering for the transparent and efficient coordination of DERs with a view to ensuring fair remuneration, addresses the case where a DER is unable to provide the amount of energy it committed to offer, and provides means for the resolution of any potential disputes. In addition, this pattern minimizes blockchain access and related costs in terms of fees incurring when running a smart contract. A localized scale setting, such as a microgrid or a small energy community comprising a few dozen DERs, was considered. The Aggregator is physically linked to the DERs it manages enabling seamless energy transfer and measurement, while data exchange occurs via the blockchain when needed.

The PoF pattern leverages a smart contract implemented in Solidity, called “ARIA” (Aggregator Renewable Integration Agreement), which oversees the interaction between energy players. It works in conjunction with a smart contract called “Vault” to maintain and manage a balance for rewarding DERs and the Aggregator. The Vault smart contract has been introduced in the context of the “Treasury Manager” design pattern [21].

Blockchain technology gives support to the verifiability of smart contract code and the permanence of storage, ensuring their immutability, regardless of potential tampering that could occur in a single host, thus ensuring security, transparency and ultimately trust. Specifically, this solution relies on blockchain to make sure that algorithms governing energy players are immutable, and generated events can be easily observed, cannot be questioned, and cannot be lost. However, the data storage employed is outside the blockchain, this reduces the frequency of blockchain accesses, the storage space needed, hence the associated costs. Data recorded outside the blockchain in a set of external hosts are then ordered temporally, regardless of local clocks, by exploiting, as a surrogate timestamp, the blockstamp, i.e., the hash of the latest block stored in the blockchain. As data are stored on external hosts, labeling them with blockstamps ensures that all actors can assign them temporal identifiers, which depend on the blockchain state and maintain a pace consistent with the blockchain itself. This functionality plays a crucial role in our system’s dispute-resolution measures. Disputes could arise when a DER has not received the expected amount for the energy production, then energy measures from different smart meters have to be compared for given timeframes.

A blockchain is a peer-to-peer distributed ledger that stores cryptographically signed transactions in an append-only list of linked blocks, namely the chain [27]. Blockchain technology combines different well-known concepts, such as digital signatures, cryptographic hashing functions, and decentralized consensus algorithms, to validate transactions without relying on a central authority [28,29,30,31]. Once written, the content of a blockchain is immutable and cannot be deleted, otherwise the entire data recorded become invalid. This feature ensures the provenance, integrity, and authenticity of data, preventing tampering. Consensus among all peer network nodes, called Validators, which reach a common agreement on the state of the distributed ledger, ensures the reliability of the blockchain. The consensus algorithm also discourages dishonest behavior by making it economically disadvantageous for a Validator to deviate from the expected protocol rules [5].

Ethereum [5] was the first blockchain that introduced the innovative possibility of executing user programs on a virtual machine, called the Ethereum Virtual Machine (EVM), that operates under each Validator node within its network. These programs, or “smart contracts”, are compiled to bytecode and deployed to the blockchain. They can be executed requesting a transaction towards their addresses and can independently maintain their own balance. Once stored on the blockchain, smart contracts’ bytecode cannot be modified, reflecting the immutable feature of the blockchain. However, they can be removed by the owner, i.e., the entity owning the private key of the address that deployed the contract. The advent of smart contracts has turned the blockchain into a global computer accessible from a variety of different devices, making it a general-purpose technology that extends beyond finance and offers opportunities to leverage the blockchain as a backend for designing distributed applications, offering enhanced transparency, security, traceability, and trust across various sectors.

In the blockchain domain, time is marked by the block time, which refers to the average time it takes for the network to generate an additional block. e.g., in Ethereum, a new block is minted every 12 s, except in unexpected conditions. Consequently, a transaction that proposes a new state based on the prior state of the blockchain will face at least a 12-second delay [33,34]. Moreover, smart contracts’ execution is limited by a maximum amount of “gas” consumption allowed. Gas is a metaphor that quantifies the computational effort required while executing a smart contract, which results in a financial cost that users have to pay to execute the code [35].

Generally, many smart contracts manage users’ balances. When the code of a smart contract has to change to meet new requirements or to fix bugs, then a new version of the contract has to be deployed and the accumulated financial reserve has to be transferred to the latest version; afterwards, the previous version will be deleted. However, for such a balance transfer operation expensive gas fees could incur [36].

The Treasury Manager pattern has been devised to avoid the need to transfer the accumulated reserve from the old smart contract to the latest version, thereby avoiding the gas fees (see Figure 1). The following participants constitute the Treasury Manager.

• Registry smart contract that stores the address of the Service smart contract [37].
• Service smart contract that provides a useful service.
• Vault smart contract that retains the financial reserve and manages user balances.

Registry acts as a proxy and hands to client the requested Service address. When the Service is updated, its new address is stored in Registry, ensuring that clients always access the current version of the service. This solution enables users to interact with new versions of Service seamlessly, even though the new smart contracts have different addresses. Vault is responsible for managing users’ accounts and balances, and can only be triggered by Service to authorize withdrawals and deposits. Service, which runs the business logic, can be updated independently of Vault, which remains unchanged and continues to hold all balances. The new Updated Service will refer to the same Vault contract, hence this approach avoids the need to transfer the accumulated reserve from one wallet to another, thereby saving expensive gas fees.

After deploying a new version of the Service contract (Updated Service Contract), the owner of the contracts will store its address in the Vault contract, allowing the Updated Service contract to become the only entity authorized to interact with the Vault to unlock users’ coins (hence, old Service Contract cannot deposit or withdraw any amount anymore).

Treasury Manager is used by the Proof of Flow pattern to hold, manage, and maintain the energy players’ balances, as well as handle DERs’ and Aggregator’s deposits and rewards.

5. Proof of Flow Design Pattern