EnergyAuction: IoT-Blockchain Architecture for Local Peer-to-Peer Energy Trading in a Microgrid

Abstract

The widespread adoption of distributed energy resources (DERs) and the progress made in internet of things (IoT) and cloud computing technologies have enabled and facilitated the development of various smart grid applications and services. This study aims to develop and implement a peer-to-peer (P2P) energy trading platform that allows local energy trading between consumers and prosumers within a microgrid which combines IoT and blockchain technologies. The proposed platform comprises an IoT-cloud home energy management system (HEMS) responsible for gathering and storing energy consumption data and incorporates a blockchain framework that ensures secure and transparent energy trading. The proposed IoT–blockchain architecture utilizes a Chainlink oracle network and a private Ethereum blockchain. Through the use of smart contracts, consumers and prosumers can participate in an open auction to trade energy, while the settlement process involves acquiring external energy data from an API through the oracle network. The performance of the platform is evaluated through a testbed scenario using real-world energy data from a real house in Valparaiso, Chile, while storing those measurements in AWS cloud, validating the feasibility of the proposed architecture in enabling local energy trading. This work contributes to the development of energy management systems by providing a real-world implementation of an IoT–blockchain architecture for local energy trading. The integration of these technologies will allow for a more efficient and secure energy trading system that can benefit prosumers, consumers, and utilities.

1. Introduction

Decades ago, traditional power grids were designed with the primary purpose of delivering electricity from large centralized power plants to individual residences. However, significant transformations have occurred in the electricity sector due to the integration of various technologies, including distributed energy resources (DERs), electric vehicles (EVs), advanced metering infrastructures (AMIs), and home energy management systems (HEMSs) [1]. DERs have enabled many end-users to transition from being energy consumers to becoming energy prosumers. This transformation allows prosumers to produce and consume energy simultaneously. In the near future, energy prosumers and consumers will be able to connect with one another and trade energy locally through a marketplace during instances of mismatch between supply and demand [2].

During the period when prosumers have surplus electricity, they can store it using energy storage systems (ESS), export it back to the power grid, or sell it to other customers. The direct energy trading among prosumers and consumers is called peer-to-peer (P2P) energy trading [3]. The implementation of this novel P2P energy trading structure allows the local sharing of surplus energy from small-scale DERs within a microgrid, bringing advantages to prosumers, consumers, and the distribution system operator (DSO). P2P energy trading presents several benefits to all parties involved, as it facilitates local energy balance and improves the overall energy exchange process [4].

Internet of things (IoT) technologies are widely used to enable different smart grid applications. IoT technologies can be used for monitoring and controlling by using various sensors, actuators, and metering devices [5,6,7,8]. Such integrations can be found in HEMSs, which facilitates users’ operation and management of household appliances and DER. To enable a microgrid application, such as trading within a microgrid, it is necessary to collect the energy consumption and/or generation data of houses. The use of these data serves as a key element to enable the implementation of various applications [9,10].

Blockchain technology has been gaining attention in non-cryptocurrency-related research, such as the integration of heterogeneous IoT systems with the energy market, with features such as data privacy, cybersecurity, and reliability [11]. In general, four layers compose the P2P energy trading system: the power grid layer, information and communication technology (ICT) layer, control layer, and business layer [12]. There have been several projects that have been carried out as energy trading pilots. Among these are the following projects: Piclo in the United Kingdom (see https://www.piclo.energy/ accessed on 2 November 2022), Transactive Grid and Brooklyn Microgrid in the USA [13], Peer Energy Cloud in Germany, and Powerledger in Australia [14,15]. The combination of IoT technology and blockchain technology has been covered in [16], where digitalization and decentralization are stated as the key enablers for a transactive energy internet (EI). A schematic diagram is presented in Figure 1 to provide a visual representation of the interaction between microgrids, distributed peer-to-peer networks, and cloud-based services. This diagram illustrates the main components of this research work, including the relationships and interactions between different entities. The microgrid is defined as a modern and innovative energy system that involves various parties, including electric vehicles (EVs), photovoltaic systems (PVs), energy storage systems (ESSs), prosumers, consumers, and utilities, which interact by exchanging both energy and data. In our previous work, Ref. [17], we presented the basic concept for the development of “EnergyAuction”, a P2P energy trading platform that focuses on a proof of concept for the integration of oracles into smart contracts.

This work proposes the design and implementation of a P2P energy trading platform in a microgrid combining two key components to enable secure, transparent, and decentralized energy trading among participants: a HEMS and blockchain technologies. The HEMS facilitates real-time monitoring and control of energy consumption and generation and supports two different implementations based on edge devices and cloud-based services, respectively. The blockchain platform uses a private Ethereum network and Chainlink oracle network to facilitate energy trading between participants, storing energy transactions through a distributed ledger. Cloud-based services, such as the application programming interface (API), provide access to valuable energy consumption and generation data. To retrieve data from cloud-based services, oracle networks serve as a gateway, such as using available APIs, and route data to blockchain-based services.

Although a lot of research work has been conducted for peer-to-peer energy trading, there is no available information for the detailed technical implementation of such systems nor detailed aspects of such IoT–blockchain integration. The main contributions of this paper are given below:

• A thorough analysis of blockchain network design and market types/attributes for local peer-to-peer energy trading.
• Proposal of IoT–blockchain architecture for local P2P energy trading in a microgrid which consists of two layers: physical (IoT layer) and virtual (off-chain layer and blockchain layer).
• Development, deploying, and testing of four smart contracts for local peer-to-peer energy trading: data access contract, energy trading smart contract, Link Token contract, and oracle client contract.
• A testbed implementation (hardware/software) is carried out in a laboratory environment for one prosumer, one consumer, and a microgrid control center, where the off-chain layer of the HEMS is implemented on AWS platform and the blockchain layer is implemented using an AIO computer.

The remainder of this paper is organized as follows: Section 2 presents a review of the most relevant work related to blockchain technology, smart contracts, oracle networks, and the implementation of P2P energy trading. Section 3 describes necessary concepts for the design of P2P energy trading platforms, while Section 4 details the main components of the proposed architecture. Section 5 explains the process of setting up a market for P2P energy trading in a microgrid, including the definition of market type, archetypal market design, price formation mechanism, market participants, market value proposition, market scale, and market operation. Section 6 shows the implementation of the proposed platform, and in Section 7, the obtained results are analyzed. In addition, Section 8 provides the conclusions and future work.

2. Related Work

The energy internet presents a virtuous relationship among various entities, such as energy producers and end consumers. When these entities trade with one another, they are defined as a local energy market (LEM), which aims to support energy exchange between them in a competitive market and balance supply and demand locally [18]. The two key enablers for energy trading in a LEM are digitalization and decentralization [16]. Both decentralization and energy markets are presented below.

2.1. Decentralization: Blockchain Technology

The accelerated growth of renewable energy resources and the growing adoption of distributed power generation are transforming the energy sector. Peer-to-peer (P2P) energy trading has surfaced as an innovative solution, empowering prosumers and consumers to engage in energy trading in a more adaptable, efficient, and decentralized manner [19,20]. Blockchain technology, characterized by decentralization, transparency, and immutability, offers an ideal foundation for building P2P energy trading platforms [21].

Blockchain technology facilitates a secure and reliable environment for executing business logic and allowing participants in energy trading to interact. It creates transparent and tamper-proof records of energy transactions, ensuring that both producers and consumers can trust the system without relying on intermediaries [22]. This decentralized trust model, along with the ability to automate processes through smart contracts, has the potential to revolutionize energy trading and distribution [23]. Blockchain is also being introduced in the industrial internet of things (IIoT). For example, in [24], the authors used blockchain technology to enhance the security and privacy of a multi-camera multi-tracking using edge cameras. The authors in [25] presented an algorithm that improves the scalability and reduces latency. This improves the performance of blockchain for IIoT solutions. Numerous studies and projects have emphasized the potential of blockchain technology in facilitating P2P energy trading. For instance, the authors in [26] proposed a decentralized framework for coordinating energy supply and demand in a local market using blockchain and smart contracts. The work demonstrated that blockchain technology is a natural facilitator for implementing business logic and bringing energy trading participants together for interaction. As the energy sector continues to progress, the adoption of blockchain-based solutions is expected to rise, laying the foundation for a more decentralized and efficient energy landscape. General elements in the blockchain-enabled system consider network selection and configuration, consensus mechanism, privacy and network access, smart contracts, and oracle networks. These attributes are shown in Figure 2 and discussed in Section 2.2.

2.2. Blockchain Network Design

2.2.1. Network Selection

Selecting the right blockchain network is essential for the success of an energy trading platform. There are several networks available, each with its unique features and characteristics. Ethereum (ETH), Hyperledger Fabric, Avalanche, and Cardano are some of the prominent options. The choice should be based on criteria such as the developer community, ecosystem maturity, and available tools. Ethereum is a popular choice due to its large developer base, robust ecosystem, and the backing of the Enterprise Ethereum Alliance. However, it is crucial to consider the specific requirements of the energy trading platform when selecting a blockchain network.

2.2.2. Consensus Mechanisms

A crucial aspect of the configuration of a blockchain network is choosing the appropriate consensus mechanism which ensures the reliability and trustworthiness of the system. Popular consensus mechanisms include Proof of Stake (PoS), Proof of Work (PoW), Practical Byzantine Fault Tolerance (PBFT), and Delegated Proof of Stake (DPoS) [27]. The choice of consensus mechanism should be based on factors such as security, energy efficiency, and transaction throughput.

2.2.3. Privacy and Network Access

Several privacy and network access configurations can be considered based on the requirements of the energy trading platform. As an example, a public blockchain allows any participant to interact with the platform and join the network, whereas a permissioned or private blockchain restricts access to a selected group of users [27]. Privacy-preserving techniques, such as zero-knowledge proofs or secure multiparty computation, can be implemented to protect sensitive user data [28]. The selection of privacy and network access configuration should be aligned with the platform’s objectives and the desired level of decentralization and security.

2.3. Smart Contracts

Smart contracts are a critical component of blockchain-based energy trading platforms, as they allow the automation of transactions and agreements between parties [29]. These self-executing contracts, coded with specific rules and conditions, eliminate the need for intermediaries and enhance the efficiency and transparency of the trading process. Designing and implementing robust smart contracts is essential to ensure the reliability, security, and performance of the platform. Several research papers and projects have demonstrated the use of smart contracts for energy trading. For example, the authors in [13] presented a study of a local energy market based on the Ethereum blockchain, where smart contracts were used to manage energy transactions between prosumers and consumers. The authors in [22] proposed a consortium blockchain-based energy trading framework that leverages smart contracts for trading and settling energy transactions between microgrids. This framework aimed to improve the efficiency and security of energy trading while reducing transaction costs. These examples highlighted the versatility of smart contracts in facilitating energy trading and their potential to transform the energy sector.

2.4. oracle Networks

Significant advancements have been made in the domain of blockchain-based networks. However, one notable limitation of smart contracts is their ability to interact with real-world data (also known as off-chain data). To overcome this challenge, the integration of blockchain oracles has become crucial. By incorporating blockchain oracles, the issue of securely and reliably incorporating external data sources into smart contracts can be effectively addressed. The authors in [30] conducted a survey aimed to identify researchers and institutions involved in blockchain oracle research. The survey findings revealed that a total of 162 papers were identified from different databases during the last seven years. This indicates that, despite the significance of the topic, there is still a need for greater efforts to establish a widely accepted oracle taxonomy. The results emphasize the importance of further research and collaboration in order to enhance the understanding and promote standardization in the field of blockchain oracles. In [31], different types of oracles were introduced to facilitate the selection process for specific blockchain-based applications. The authors in [32] introduced a decentralized energy flexibility market based on blockchain, which leverages oracles to fetch results from an off-chain computation process for determining flexibility matching. In this implementation, oracles were utilized to address the limited computational capabilities of smart contracts. In [33], the authors presented a decentralized access control system for IoT data that incorporates blockchain technology and trusted oracles. oracles were employed as intermediaries between entities responsible for hosting the blockchain network and IoT data.

2.5. Pilots and Implementations

Various pilots and testing platforms have been conducted to evaluate the potential of blockchain technology in energy trading.

Table 1. Literature review for blockchain in smart grids. “✓” represents “included”, a cross mark “✕” represents “not included” in the reviewed articles.

Reference	Survey	Implementation	Testbed	Energy Trading
[13]	✕	✓	✕	✓
[21]	✓	✕	✕	✓
[34]	✓	✓	✕	✓
[28]	✓	✓	✕	✓
[35]	✕	✓	✓	✓
[36]	✓	✓	✕	✓
This work	✕	✓	✓	✓

summarizes the literature review of energy trading-related surveys, implementations, and testbeds. One notable example is the Brooklyn Microgrid project, which demonstrated the feasibility of a blockchain-based P2P energy trading platform within a microgrid [13]. Other examples include the Energy Web Foundation’s EW-DOS platform, and the Power Ledger’s trials in Australia [28,34]. These initiatives presented the potential benefits of blockchain technology in enhancing efficiency, transparency, and decentralization in energy trading while also highlighting the challenges that must be addressed for widespread adoption. In [21], the authors provided a comprehensive overview of blockchain’s involvement in the energy sector, discussing its potential and limitations. The authors examined various scenarios where blockchain has been applied to energy trading, including mitigating the impact of electric vehicle charging during peak periods. The authors in [35], presented an energy trading implementation using IOTA, a “Tangle”-based framework, which is considered a third-generation DLT that uses a directed acyclic graph (DAG). The authors provided guidelines for deploying end-to-end transactions for the energy section on a dynamic set of scenarios.

This work differentiates itself from other related works by providing an implementation of a P2P energy trading platform using IoT and blockchain. The proposed implementation is validated in a testbed using real data consumption. Our work provides insight on how to implement and carry out a testbed scenario using the given architecture. Furthermore, a functional and cost analysis was also performed.

3. Local P2P Energy Trading

In order to design and implement an energy trading platform, it is necessary to define the design of the energy trading market. The authors in [37] conducted a systematic literature review of three local energy market (LEM) models: P2P markets, collective self-consumption (CSC) or community, and transactive energy (TE) markets. The work provided detailed information on the market design and aspects of LEM transactions. These models were compared in terms of six categories representing attributes found in surveyed literature, archetypal market design, price formation mechanism, market participants, market value proposition, market scale, and market operation. The relationship between the three energy market models and the aforementioned attributes is shown in Figure 3.

3.1. Market Type

Three types of LEMs have emerged [20,37,38,39]:

• P2P Markets: Facilitate trading between users without the need for an intermediary. The primary objective of this market is to encourage active participation by energy users, providing them with an incentive to participate in the energy markets.
• Collective Source Connected (CSC) or Collaborative: Users tend to be co-located energy prosumers that trade their surplus energy in a market arrangement.
• Transactive Energy Markets: Maintain supply–demand equilibrium through autonomous management of DER using price signals, which ensures system stability. These markets offer services to the electricity system by optimizing the use of resources.

3.2. Archetypal Market Design

Six archetypal market designs have been identified [37,40,41,42]:

• Futures market is the most common market design, in which all the trading happens before the settlement period. When the settlement period arrives, the participants stick to their traded position. Any variation from the trading position is dealt with by the settlement.
• Real time market is where all the trading occurs at the settlement period, where participants contract with other participants to buy or sell the energy they are in the process of consuming or producing. This approach usually considers the usage of forecasted consumption or generation curves. One consideration found in this market design is that it is assumed that they are connected to larger traditional energy systems, which are able to provide or absorb an infinite excess supply or demand.
• Mixed decentralized/centralized market is a two-phase market design where initial decentralized trading is carried between participants looking to clear the market as far as possible, without intervention from a market operator. The second phase is performed by a centralized entity, which clears the remainder of the market.
• Mixed futures/real time market consists of two phases: An initial phase before the settlement, where participants trade based on predicted supply and demand for energy. During the settlement period, participants can adjust their position based on actual supply and demand curves in a real-time energy market.
• Multi-layer market starts from a local or bottom level for clearing the market. An aggregator is used for passing the uncleared supply or demand for energy to the next market level.
• Settlement after the fact is an uncommon scheme where no trading was carried out before the end of the settlement. Here, participants are charged or paid for the energy bought or sold after the settlement. A fixed price for buying or selling energy is defined by the system. Participants can purchase or sell the amount of energy they require.

3.3. Price Formation Mechanism

Price formation refers to the mechanism by which prices are discovered. There are five main categories [37,43]:

• Single auction: Only one party of the market is able to submit bids.
• Double auction: Allows sellers and buyers to submit bids.
• System-determined mechanisms: Usually defined by the system operator. Some of these mechanisms include uniform or fixed prices or cooperative game theory.
• Negotiation-based mechanisms: Automated transactions considered usually through the use of artificial intelligence (AI). Negotiating autonomous agents is one kind of negotiation-based mechanism.
• Equilibrium-based mechanisms: Use game theory to establish market equilibrium, which utilizes the bids and offers from the participants.

3.4. Market Participants

There are different market participants such as prosumers, consumers, and grid operators. Based on [2,37], the following are the main market participants:

• Prosumers are participants that generate and consume energy at the same time using small-scale distributed energy resources (DERs) such as wind turbines and solar panels.
• Pure consumer are participants that only consume energy without any DERs.
• Pure generator are participants that only generate energy.
• Retailer is an entity that connects to other large markets.
• Market operator is a single agent that runs the market operation.
• Grid operator is an entity that operates the electricity network and interacts with the market.
• Aggregator is an actor that represents a small group of participants.

3.5. Market Value Proposition

Market commodity and the benefits to participants are described in [37,44] as follows:

• Market commodity corresponds to the traded commodity in the market. Electrical energy was the most found commodity traded. Other commodities include flexibility alongside the sale of energy or a flexibility-only market. Other forms of energy are also found, such as combined heat and power, combined power and gas, or combined heat, power, and gas.
• Benefits to market participants are mainly financial, like increasing the profit from the sale of energy. Other objectives can also be considered, such as increasing the total welfare, which implies multiple financial benefits to all market participants, reducing the grid imbalance, or reducing the electricity cost.

3.6. Market Scale

Market scale considers the number of nodes involved in sizing the market [2,37]. For the participant scale, four different scales of participants are found:

• Small scale: Considers residential or individual energy users.
• Building scale: Multiple buildings trade with each other.
• Microgrid/community scale: Energy users operate as a community, rather than as individual participants.
• Grid scale: The trading is at a distribution or transmission network level.

3.7. Market Operation

Market operation refers to the type of data that is shared by the participants with the system, as well as the user preferences. Also, the settlement period and gate closures are discussed [20].

• Data shared: Price, volume, price and volume, demand and supply curve, controllable loads, the flexibility available, battery state of charge (SoC), distribution line distance, and discomfort level are some of the data parameters that can be shared for the energy trading.
• Settlement period and gate closure: The settlement period is a period of time in which the supply and demand of market participants are balanced. Gate closure is the period of time before the settlement, where bidding and offering can take place.

4. How Does Blockchain Enable Energy Trading?

Modern blockchain networks implement smart contracts which allow automatizing transactions [29,45]. Programming languages can be used to write scripts that implement energy trading business logic. This added to the benefits of an immutable, trustworthy, and decentralized network that provides the foundations to support an energy trading platform. As shown in Figure 4, a simplified diagram illustrates the interaction between the participants including prosumers, consumers, IoT devices, and the blockchain network. Data collected from the cloud-IoT HEMS is used to improve the implemented business logic in smart contracts. Information such as the available energy from an ESS, or the last hourly consumption from a householder, is used to enhance validations in the smart contract, resulting in viable trading scenarios. One challenge for using these data is the restriction for blockchain networks to fetch data from outside the blockchain. oracle networks work as a middleware between the blockchain networks and the data provider, as shown in Figure 5. oracle’s primary job is to collect and provide data feeds to smart contracts [46].

The proposed IoT–blockchain architecture for P2P energy trading in a microgrid is shown in Figure 6. The system is composed of multiple entities that are divided into two layers: the physical layer and the virtual layer. The main components of the system are the microgrid, cloud-based services, and distributed P2P networks. The microgrid consists of prosumers, consumers, battery energy storage systems, and photovoltaic systems, which exchange energy and data. Data related to energy consumption and generation are available through cloud-based services via APIs. Transactions of energy are recorded on a distributed ledger, such as a blockchain, through distributed P2P networks. oracle networks, another form of distributed P2P network, act as a connection between cloud-based services and blockchain-based services by retrieving data from APIs and routing them to the blockchain. The data that are routed back to the blockchain are then utilized by smart contracts.

4.1. Physical Layer: IoT Layer

The physical layer considers the physical infrastructure that a microgrid requires to enable the energy trading feature. The microgrid is composed of three main actors: the prosumer, the consumer, and the microgrid control center (MCC). A prosumer is a consumer who has the capability of generating energy through photovoltaic systems or wind turbines. The energy stored in a battery energy storage system can be used as a power supply to satisfy its own consumption or to sell energy to the rest of the microgrid. Consumers consume the energy provided by the MCC, but they can also employ a BESS to store energy bought from the grid. The MCC manages the energy present in the microgrid. It also provides the power infrastructure for energy flow. This energy is bought or sold by households of the microgrid. Energy can be from decentralized energy resources or from the utility service provider. This will define the operation mode of the microgrid, by island mode or grid-connected mode, respectively.

The physical layer generates plenty of energy-related data, which are required to be stored and/or transmitted to the cloud layer in order to enable several smart grid applications. This challenge is addressed by IoT devices, which enable the collection of the intended energy measurements while also communicating the data to cloud-based services on the internet. The devices in the context of microgrids are smart meters. Smart meters are digital hardware devices that allow the reading of energy consumption from households on a regular basis. Other IoT-related devices are HEMSs, which aggregate energy-related data such as state of charge of BESS, appliance loads consumption, or the main household consumption.

4.2. Virtual Layer: Off-Chain Layer

The virtual layer of the IoT–blockchain architecture for P2P energy trading in a microgrid encompasses both energy data and energy trading transactions generated by the physical layer’s IoT devices. This virtual layer is comprised of two sub-layers: the off-chain layer and the blockchain layer. The off-chain layer functions as a mediator between the real-world data captured by the IoT devices and the blockchain layer. The data are stored in cloud-based systems belonging to the HEMS provider and used for various purposes, such as load scheduling, load monitoring, alarm triggers, and forecasting. These features are available through cloud-based services offered by various HEMS providers. In addition, the MCC acts as a microgrid energy manager, collecting energy data from smart meters. This function enables the MCC to manage different processes and services on its own cloud servers. Both HEMSs and MCC cloud services may be self-hosted on-premise or through public cloud platforms such as Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. As these services manage energy storage data that are not stored on the blockchain, they are considered part of the off-chain layer.

4.3. Virtual Layer: Blockchain Layer

The blockchain layer plays a critical role in enabling secure and transparent energy trading in the microgrid. It provides a decentralized and trusted platform for energy transactions. The use of distributed ledger technology (DLT) ensures that all energy trading transactions are recorded in a tamper-proof and transparent manner. Furthermore, it enables all participants to have access to the same information and reduces the risk of fraudulent or malicious activities. The use of consensus mechanisms, such PoA, PoW, or PoS, enables the platform to validate and confirm energy trading transactions in a decentralized manner. This ensures that all parties involved in the energy trading platform can trust the outcome of the transaction and reduces the risk of fraud or errors.

5. Market Setup

This section provides a description of the market setup process for P2P energy trading in the microgrid. The following are the definitions of main elements, including the P2P market type, market design, price mechanism, types of market participants, market value proposition, market scale, and market operation. In order to establish a functional and efficient market, these key elements are crucial for P2P energy trading.

• Market Type: It is set up as a peer-to-peer, meaning that the participants are able to exchange energy directly among each other without intermediaries. This allows for greater autonomy and more flexibility in energy trading.
• Market Design: It is selected as a future market design, which means that the participants trade for future delivery of energy. Such a design allows for greater predictability and flexibility in energy trading.
• Price Formation Mechanism: The market price is determined by the intersection of the energy offered by the prosumer and the energy demanded by the consumer. This mechanism ensures efficiency and fairness in the energy trading process.
• Market Participants: The participants in the market are defined as prosumers, pure consumers, and the microgrid control center (MCC). The MCC is responsible for the overall operation of the microgrid and acts as a combination of both the market operator and the grid operator. The decentralization of the system through the use of blockchain technology ensures more efficient management of the microgrid.
• Market Value Proposition: The commodity traded in the market is energy, and the main benefit of the model is to put prosumers at the forefront of energy production and supply to consumers. This allows for a more sustainable and decentralized energy system.
• Market Scale: The market is defined as small-scale, with participants confined to a single microgrid. This allows for more efficient and localized energy trading.
• Market Operation: The market operation involves two categories: data related, including state of charge (SoC) data from the battery energy storage system (BESS), energy consumption and generation data from IoT devices, and trade-related, including price and quantity. The settlement and gate closure procedures are defined in detail in a subsequent figure, promoting a transparent and fair energy trading system.

Settlement and gate closure policy is depicted in Figure 7. The energy trading window and the energy trading sequence diagram are defined as part of the market setup. The trading window is composed of four sequential phases which make up the trading process:

• Bidding and Offering Period: This is a 10 min phase in which consumers and prosumers can submit bidding and offer requests, respectively.
• Matching Period: This is a 2 min phase in which the bids and offers are processed to make a match between them.
• Energy Transfer Period: This is a 60 min phase during which energy is transferred from prosumers to consumers.
• Settlement Period: This is a 3 min phase in which the settlement of funds takes place. The settlement period verifies how much consumers should pay to prosumers based on the actual energy received.

The four phases are modeled in the trading smart contract as valid states that a trading window can take. The transition between the states is executed autonomously by the microgrid control center using the smart contract when the expiration time elapses. Regarding the market operation, Figure 8 presents the interaction in which participants manage to bid and offer energy. Before any trading operation is executed by the households, every householder has to grant permission to the trading smart contract to request energy data from its data sources, which is depicted as the data access granting phase from the trading window.

• The MCC starts a new energy trading window, which begins with the bidding and offering phase. This is broadcasted as an event in the blockchain network.
• The prosumer submits an offer to sell excess energy. The energy trading smart contract validates the offer request by obtaining energy readings from the HEMS through an oracle network. If the prosumer is unable to provide the offered energy, the smart contract emits an event to notify the prosumer that their offer will not be considered, and this is depicted in “Case 1”. This ensures fairness and transparency by preventing false offers. If the prosumer has enough energy, the smart contract records the energy offer as valid, and this is depicted in “Case 2”.
• A consumer submits a bid to buy energy, which is recorded in the record of bids. After 10 min, the smart contract matches available energy offerings with the record of bids, providing a match between prosumers and consumers for energy transfer.
• In the energy-transferring phase, which lasts for 60 min, the prosumer becomes the energy provider of the consumer who charges its ESS with the energy provided. A maximum of 10 kWh is set for this phase due to technological restrictions of a common residential system to transfer more than 10 kW over an hour to the battery.
• In the settlement phase, the energy trading smart contract obtains energy readings from the consumer smart meter on the HEMS API through an oracle network. If the consumer received less energy than they requested, funds are returned to cover the energy mismatch. The payment is then transferred to the prosumer based on the revenue generated from the sale of energy, which is determined by market demand through the use of bid pricing. The mathematical representation of this process can be represented as $R=E\ast B$, where R represents the revenue, E represents the energy received by the consumer, and B represents the bid price.

6. Implementation

The testbed was carried out in the research laboratory B110 at Universidad Tecnica Federico Santa Maria in Valparaiso, Chile. In the laboratory, two Raspberry Pi 4 Model B units were used to represent the prosumer and consumer participants. An all-in-one (AIO) computer was used to set the blockchain-related elements and for the MCC operations. Additional services were implemented in Amazon Web Services (AWS). As seen in Figure 9, the implementation is divided into three main components:

6.1. Off-Chain Layer

The off-chain layer of the home energy management system (HEMS) was implemented on the AWS platform. AWS IoT Core was utilized to provide an MQTT broker for messaging between the energy data publisher microservice available in both the consumer and prosumer HEMS. This broker allows energy consumption and generation data to be sent to the cloud, where it is stored and made available through an API. Energy data for each household can be requested using a unique identifier assigned to each smart meter.

The two HTTP get endpoints implemented are:

• /battery-soc/id: This endpoint returns an object with the readings from the last measurement of the state of charge (SoC) of a battery energy storage system (BESS). The readings are randomly generated each hour, and the id represents the identifier of the battery.
• /smartmeter/id: This endpoint returns the last hour energy consumption in kWh from a user’s smart meter. The id represents the identifier of the smart meter.

The implementation of the off-chain layer allows the collection and storage of energy data from both the consumer and prosumer HEMS. The use of AWS and the energy data publisher microservice ensures the feasibility of the IoT–blockchain energy trading system in microgrids. The source code for this implementation is provided in a GitHub repository. (https://github.com/pipegreyback/EViG-Server accessed on 3 November 2022).

6.2. Blockchain Layer

The blockchain layer of the IoT–blockchain energy trading system was implemented in a laboratory using an all-in-one (AIO) computer, which featured an AMD Ryzen 7 5300U CPU, 16 GB RAM, and a 1 TB hard drive. The Hyperledger Besu, an open-source Ethereum client, was used to implement a private Ethereum network. To speed up the network setup, Hyperledger Besu Docker quickstart was used, which allowed for the deployment of four validator nodes and three client nodes. The validator nodes were configured to operate using IBFT 2.0 consensus [47], which was chosen due to its high throughput and finality compared to other consensus mechanisms. This is also the consensus mechanism set by default in Hyperledger Besu. This consensus mechanism uses a dynamic mechanism for validator selection and requires at least a $2/3$ validator signature in order to confirm a block. In case no consensus is reached, further validation rounds are required until the consensus is reached. Additional tools, such as a block explorer, were also provided to simplify the development process. Finally, to develop smart contracts, Remix, a popular online Solidity compiler, and a debugger were used.

6.2.1. Smart Contracts

Four smart contracts were deployed to enable energy trading. Figure 10 shows a summary of each smart contract by category.

• In the privacy contract category, the data access contract was implemented to manage an access control list containing entities authorized to request energy data from a user’s HEMS. This permission is granted by the user. This smart contract helps ensure that the energy data are only accessible to authorized parties, which helps to protect the privacy and security of the energy data.
• In the trading contract category, the energy trade smart contract was developed, which contains the main business logic of the energy trading system. This smart contract implements a trading window consisting of four states: a bidding and offering state, a matching state, an energy-transferring state, and a settlement state. During the initial phase, the bidding and offering period is initialized when a new trading window is requested in the trading smart contract. Additionally, the trading window allows granting data access at any time, which is required to participate in a trading window. A class diagram is presented in Figure 11, where the solidity structures are presented as classes, that possess attributes and functions.
• In the oracle contracts category, two contracts were developed. The Link Token contract issues the ERC-20 Link Token, which is required to pay for data requests through the oracle network. The oracle client contract is used to request energy data using the HEMS APIs, and this request is handled by the oracle network, which processes the request and provides a callback with the results of the request. Both the Link Token contract and the oracle client contract can be found in the Chainlink official repository (https://github.com/smartcontractkit/chainlink/tree/develop/contracts/src accessed on 3 November 2022).

6.2.2. oracle Nodes

In order to enable smart contracts to utilize the available API, the deployment of a Chainlink oracle network using docker containers was necessary. Additionally, a PostgreSQL database was deployed using docker containers to support the Chainlink oracle network. Configuration between the Ethereum network and the Chainlink oracle node was established to facilitate interaction between smart contracts and the oracle within the Ethereum network. The primary parameters utilized for communication between the two networks include the RPC URL and the chainId. Figure 12 shows the interaction diagram for the data feed request between smart contracts and oracle nodes.

In order to access the endpoints provided by the HEMS API, it is necessary to create and deploy a job within the oracle node. A job comprises a sequence of steps, called tasks, that fulfill the data feed requirement of a smart contract. In this specific case, a direct request job was created. This job involved requesting data from the HEMS API, parsing the response, encoding the data into a format compatible with Solidity, and ultimately submitting the transaction back to the requesting smart contract. Figure A1 shows the direct request job configured.

6.3. IoT Layer

For the IoT layer, the two Raspberry Pi units were used. Docker was employed to run containers of the services required to enable the energy data client and the energy trading client.

6.3.1. Energy Data Client

The implementation of the IoT layer was done using the AWS platform and the energy data publisher microservice was developed using Node.js and MQTT.js. This microservice sends energy data to the HEMS cloud service using MQTT, allowing the collection and storage of energy data from each household. The microservice was packaged into a docker container for easy deployment and running on any operating system that supports docker containers.

6.3.2. Energy Trading Client

Both the consumer and the prosumer were configured with an energy trading client, which allows for submitting bids and offers to the blockchain to participate in the energy trading within the microgrid. The energy trading client was developed using Node.js and the ethers.js library, which is an Ethereum client that allows the execution of operations within a blockchain network. The energy trading client was also packaged into a docker container for ease of deployment. The trading client subscribes to the four events that the smart contract emits to the blockchain network. The event subscription and execution of smart contract functions are managed by ether.js.

Table 2. Available operations for the energy trading smart contract.

Operation	Description
Constructor	Initialize the contract’s state variables when the smart contract is deployed.
Phase Transition	Update the current phase of the trading process based on a predetermined timeline or other criteria.
Start Trading Window	Mark the beginning of the trading phase and set the initial trading parameters, such as the duration of the trading window and the maximum amount of energy that can be traded.
Submit Energy Offer	Allow sellers to submit offers to sell their energy at a certain price and quantity. These offers are stored in the contract’s state variables until they are matched with a corresponding bid.
Submit Energy Bid	Allow buyers to submit bids to buy energy at a certain price and quantity. These bids are stored in the contract’s state variables until they are matched with a corresponding offer.
Matching Phase	Match the submitted offers and bids based on their price and quantity, and assign the matched pairs to a transfer list for the transferring phase.
Transferring Phase	Transfer the energy between the matched parties based on the agreed-upon price and quantity. This phase ensures that the energy is delivered securely and efficiently.
Settlement Phase	Transfer the payment between the matched parties based on the agreed-upon price and quantity, and update the state variables to reflect the completed trade. This phase ensures that the payment is made accurately and securely.

describes the operations that any participant in the microgrid can execute within the energy trading smart contract. The client source code is provided in the repository, and it considers three possible configurations: consumer, prosumer, and MCC.

6.4. Use Case and Validation

The testbed consists of one prosumer, one consumer, and a microgrid control center. We assumed that a prosumer owns a PV system and BESS, which will offer excess energy, the consumer with BESS will bid to fulfill his energy consumption requirements, and the microgrid control center will provide the power infrastructure for all households in the microgrid. The smart contract for energy trading was deployed by the lab all-in-one (AIO) computer acting as the MCC. Both the prosumer and consumer grant data access permission to the energy trading smart contract for making energy requests to the HEMS API. Figure A2 shows the event log where the prosumer executes the grant data access function passing the energy trading smart contract address and the smart meter id as the parameters in the invocation.

The energy trading window starts with an energy price of 60,000 gwei per kWh, which was set by the microgrid control center (MCC). This price is equivalent to around CLP 102 per kWh, which is the rate provided by energy utility Chilquinta in Chile (https://www.chilquinta.cl/informacion-de-interes/tarifas-vigentes accessed on 3 November 2022) for the cost of energy per kWh, and the cost of transmission per kWh, for the BT1A tariff. The trading window has now entered the offering and bidding phase, allowing consumers and prosumers to submit their offers to sell or bids to buy energy at the specified price. The energy starting window event is broadcasted to all participants in the trading system, enabling them to react to the event on the clients by event subscription and execute their own state machines. This enhances the overall efficiency and transparency of the trading process, allowing participants to respond quickly and accurately to changes in the trading window and the energy price. The log message shown in Figure A3 confirms the current phase of the trading window and the energy price broadcasted in the event. This information is essential for understanding the initial pricing conditions and the current state of the energy trading system.

Later, a prosumer submits an offer to sell 10 kWh. This offer request triggers the oracle smart contract for making a request to the HEMS API for checking the prosumer available energy. The event of an energy offering being denied due to insufficient energy is illustrated in Figure A4. An event with an error message indicating the reason for the denial, and in this case, “insufficient energy” is provided. In the event that a participant has not granted the energy trading smart contract the required permission to access the energy data, an error is returned by the contract validations, as seen in Figure A5.

In the case of valid energy offers and energy bids, when the matching phase finishes, a result event is broadcasted to the matched participants, as seen in Figure A6. This event indicates that the energy trading smart contract has reached the matching state, where a consumer and prosumer have agreed on a trade for 10 units of energy at a price of 54,000 gwei per unit. The smart contract has successfully matched the consumer’s energy demand with the prosumer’s energy supply at the agreed price, and the settlement phase can proceed.

Regarding the received energy by the consumer, Figure A7 shows the log from the oracle request. This log was emitted by the energy trading smart contract during the energy-transferring phase, indicating that the consumer received 8 kWh of energy from the prosumer, as measured by the smart meter. It is important to note that the energy data are managed by the Chainlink oracle, and the energy trading smart contract interacts with the oracle contracts to retrieve the data. The discrepancy between the initially agreed 10 kWh, and the 8 kWh received by the consumer may be due to a delay in the initial transfer from the prosumer, or external factors such as network congestion or power outages. However, the flexibility provided by the smart contract allows for mismatches between agreed energy and received energy to be addressed during the settlement phase.

The settlement phase, which follows the energy-transferring phase, is responsible for determining the proportional payment to be made to the prosumer based on the amount of energy received by the consumer. Figure A8 shows an example of the proportional payment calculation for the scenario where the consumer received 8 kWh of energy, which was less than the initially agreed 10 kWh. The implementation of the energy trading smart contract provides a degree of flexibility by allowing for adjustments to be made during the settlement phase in case of mismatches between agreed and received energy.

6.5. Cost Analysis Results

Table 3. Cost comparison of different energy trading smart contract operations based on the network execution.

Contract Operation	Gas Utilization	Cost in CLP in Our System	Cost in CLP in Slow Public Ethereum	Cost in CLP in Average Public Ethereum	Cost in CLP in Fast Public Ethereum
Constructor	2,619,703	$0	$81.010	$89.112	$97.213
Phase Transition	161,524	$0	$4.995	$5.494	$5.994
Start Trading Window	286,403	$0	$8.857	$9.742	$10.628
Submit Energy Offer	129,613	$0	$4.008	$4.409	$4.810
Submit Energy Bid	130,354	$0	$4.031	$4.434	$4.837
Matching Phase	153,400	$0	$4.744	$5.218	$5.692
Transferring Phase	134,179	$0	$4.149	$4.564	$4.979
Settlement Phase	144,247	$0	$4.461	$4.907	$5.353

shows a cost comparison of different energy trading smart contract operations performed in our energy trading platform and in various speed-based configurations on the public Ethereum network. As our implementation uses a private Ethereum network, there were no transaction fees incurred during contract deployment or execution. Therefore, the gas values listed in the table represent the resources used to perform the operations. In comparison, public Ethereum networks charge transaction fees for contract execution, and gas prices can vary based on the user’s preference for transaction speed. This is because the public Ethereum network tends to become congested, where validators prioritize transactions with a higher gas price to process and receive a reward. As a result, users may choose to pay a higher gas price to increase the chances of their transaction being processed sooner. The public Ethereum network offers suggested gas prices for different transaction speeds, namely slow, average, or fast. For the public Ethereum network, each transaction speed has a corresponding gas price, which on the date of this study were 20 gwei, 22 gwei, and 24 gwei. To simplify the comparison, the transaction costs in the table are presented in Chilean pesos (CLP) using the conversion rate from ETH to CLP on 10 April 2023.

Block time in the Ethereum network is dynamic and reflects the network congestion and performance. In the case of Hyperledger Besu, the block time is a critical parameter that determines the block frequency. This time has a direct impact on both throughput and latency. If the block time is very short (e.g., 1 s), blocks will be generated frequently, which results in low latency and high throughput. However, in the case of a block period being very long, the performance will be reduced because the transactions will need to wait a long time to be added to the next block [48].

In our implementation of the energy trading smart contract, the created Ethereum network provided a 5 s validation block time. In comparison, the last average block time of the public Ethereum network is around 12 s (https://etherscan.io/chart/blocktime accessed on 10 January 2023), as shown in Figure 13. The difference in block times could be due to various factors, such as network congestion or the consensus mechanism used by the network. Understanding the impact of block time on the energy trading smart contract’s performance, throughput, and gas usage is critical for future optimizations and improvements.

The maximum block size in gas units for a regular block in our implementation and in public Ethereum networks is 30 million gas units. Figure 14 shows a bar chart where the eight operations of the energy trading smart contract are presented in terms of the percentage of block usage. The constructor is the most gas-consuming operation and utilizes $8.73\%$ of the available gas in a block. The remaining operations present lower gas consumption, between $0.43\%$ and $0.95\%$ of gas usage for the available gas in a block. An analysis of the gas usage for the energy trading smart contract revealed that no more than 12 constructors or 200 trading operations could be performed within a single block. This indicates that the platform may face limitations in terms of scalability and network congestion with an increasing number of participants. However, given the 5 s block time of the private Ethereum network used in this work, and the number of participants for the use case validation scenario, this limitation was not explored in detail. Future research could investigate ways to optimize the gas usage of the smart contract or explore alternative solutions to address scalability and congestion issues.

7. Discussion and Limitations

The implemented energy trading platform successfully demonstrates the feasibility of a permissioned blockchain network for energy trading. The platform was designed to support energy trading between prosumers and consumers, with the support of an MCC. While the use of an access control list in conjunction with oracles allows the energy trading smart contract to access energy information, the relationship is established between the consumer or prosumer and the contract, instead of using IoT devices as a separate entity in the interaction. Recent developments in the field propose the use of Non-Fungible Tokens (NFTs) as a digital representation or “digital twin” of IoT devices. These tokens, standardized by Ethereum under the ERC-721 and ERC-1155 interfaces, enable the establishment of ownership relationships between the householder, consumer, or prosumer and their energy data-collecting devices. This feature includes the data access functionality, which can simplify the addition of further implementations, such as the one presented here.

In terms of cost analysis, the results indicate that a private implementation of the energy trading platform is more cost-effective than implementing the same business logic in the public Ethereum network. This is mainly due to the public network’s high transactional fee and longer validation block times, caused by network congestion and a different consensus mechanism. Therefore, it is recommended to implement such platforms in private Ethereum networks or shared private networks, such as consortiums involving multiple entities related to smart grid applications. If by any means there is a requirement to deploy such a platform in a public network, it is recommended to make a prospection into layer two (L2) solutions, which present lower transactional fees and faster validation block time.

The privacy of the energy trading system is achieved through the use of a permissioned blockchain network, which restricts access to only authorized nodes. However, it is important to note that while the access control list and the oracles provide privacy for off-chain data access, the transactions that occur within the energy trading smart contract are still recorded on the blockchain. This includes the funds transferred between parties during the settlement phase and the readings from the off-chain data that are accessed via the oracles. Therefore, further research is needed to ensure the privacy of on-chain transactions in the energy trading system. For example, a technology that could be used to enhance the privacy and security of energy trading platforms is the zero-knowledge proof (Zk-proofs). Zk-proofs enable the verification of data without revealing the data itself. This could be useful in scenarios where the privacy of the energy trading data is of utmost importance, such as trading between competitors or sensitive business transactions.

The analysis of the gas usage of the smart contract revealed that the constructor had an average gas usage of 9%, while the average gas usage for each function call was 0.5%. Although the implementation was successful in supporting the energy trading use case, the gas usage results suggest that there is room for improvement in the smart contract design. Future work could explore the use of more advanced smart contract technologies, such as verifiable computing (VC) or zero-knowledge proof (ZKP), to optimize gas usage and enable the implementation of more complex business logic.

In this work, the old transactions are still kept on the blockchain. However, the concept of offloading can be applied, but a different approach is needed regarding the blockchain network configuration, IoT data, transactions executed by devices, and energy trading participants. For example, in [49], the authors introduced using different types of nodes including full nodes, semi-full nodes, and light nodes, while in [50], the authors developed a hierarchical blockchain storage structure for industrial IoT architectures.

Regarding the law and regulations, in Chile, the current regulation allows prosumers with PV systems to only inject surplus energy to the power grid; however, consumers and prosumers are not allowed to conduct direct energy trading with one another. To enable such opportunities, new regulations should be developed that will bring benefits not only to utility companies but also all participants, including prosumers, consumers, and utilities.

8. Conclusions

This paper presents the development and deployment of a microgrid-based local peer-to-peer energy trading system in a laboratory environment. It thoroughly examined and discussed the conceptual architecture of a distributed peer-to-peer network. To establish a blockchain-based system in a test environment, a Chainlink oracle and a private Ethereum blockchain network were employed as foundational components. The research focused on exploring the capabilities of oracles as intermediaries between off-chain data sources, such as smart meter energy readings, and the business logic implemented within smart contracts, which typically lack the ability to directly request off-chain data. Overall, this work highlights the potential of IoT and blockchain technologies to enable sustainable and efficient energy management practices. Despite the promising results, the proposed platform has some limitations and challenges that require further research and development. The following are the main directions to extend the current work:

• To support a large number of participants, there is a need to optimize the platform performance and scalability. This includes optimizing the smart contract code, data storage, and processing algorithms.
• To support real-time energy trading, different business models and trading schemes should be developed where participants trade energy in real time based on the current market conditions.
• Cybersecurity and privacy are important factors to be considered. This includes the data exchange among different participants as well as the sensors, smart meters, and networking infrastructure.