Review Reports - A New and Smart Gas Meter with Blockchain Validation for Distributed Management of Energy Tokens

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The paper presents the concept of a smart gas meter, with an ultrasonic measurement block separated from the communication block (LoRa/NB-IoT) and with the validation of consumption transactions through a blockchain infrastructure and 1-to-1 energy tokens with energy/volume units. The paper has a promising idea and a coherent architecture.

To improve the manuscript, I recommend addressing the following issues:

The flow results show only a maximum error of ~4–5% compared to a "serial" benchmark, without a complete uncertainty budget, without repetitions, and without metrological traceability of the flow standard (only calibration of pressure sensors).
The 2 mbar limit in EN 14236 is exceeded at maximum flow for housing installation, but no design remedy or quantification of the impact on the metrological class is proposed
The specific blockchain (platform, on-/off-chain for raw data, transaction costs, retention, GDPR) and the size/format of the audit logs are not specified. The "Proof of Federated Authority" mechanism is described in terms of parameters, not implementation/formal verification.

Author Response

The authors thank the reviewer for his thorough review work and for his valuable comments, which helped improve the paper. Below, specific replies to comments are provided.

Comment 1: The flow results show only a maximum error of ~4–5% compared to a "serial" benchmark, without a complete uncertainty budget, without repetitions, and without metrological traceability of the flow standard (only calibration of pressure sensors).

Response 1: Information on the uncertainty of the flowmeter used as a reference in the loop has been added to Section 2.1. Moreover, the following sentence has been added: “Some tests were carried out to check the behavior of the ultrasonic flow sensor: in particular, five repeated measurements have been performed for each flow condition, and mean and standard deviation have been calculated, and compared with the values provided by the reference flowmeters.”

The results of the tests have been added to Section 3.1, highlighting that a rigorous gas meter calibration and a more complete uncertainty assessment will be made once the overall system is fine-tuned and validated:

“The results show that the variability was in the order of 2 %, and the maximum relative error of the mean with respect to the indication of the reference flow measuring device operating in series along the loop of Figure 1 was in the range 4 to 5 %. It is to be pointed out that, once both the measuring block and the transmission one, and the blockchain infrastructure will be validated, a high accuracy gas flow rate measurement device will be introduced for final gas meter calibration and complete evaluation of the uncertainty contributions.”

Comment 2: The 2 mbar limit in EN 14236 is exceeded at maximum flow for housing installation, but no design remedy or quantification of the impact on the metrological class is proposed

Response 2:

In Section 3.1 the following sentence has been added: “The pressure drop is due both to the fluid dynamic path but also to an imperfect seal of the system, so this aspect will be particularly paid attention to in the final version, improving sealing solutions. Leak tests will be carried out according to the standard's specifications [19].”.

Comment 3: The specific blockchain (platform, on-/off-chain for raw data, transaction costs, retention, GDPR) and the size/format of the audit logs are not specified. The "Proof of Federated Authority" mechanism is described in terms of parameters, not implementation/formal verification.

Response 3: Information on the smart contract execution flow and transaction latency has been added to Section 3.2.4:
“The blockchain infrastructure implemented for the purpose of experimental validation is based on an EnergyBatchRegistry.sol smart contract (283 lines of Solidity code), deployed on Hyperledger Besu 24.12.0 with Proof of Authority consensus.
The contract manages the registration of energy transaction batches through two main data structures: Batch and EnergyTransaction.

The complete lifecycle of an energy token involves several phases with specific latencies measured during system validation tests:

Edge Layer (GasMeter Node → Aggregator): Edge nodes generate transactions signed with Ed25519 (average payload 775-835 bytes) and transmit them via MQTT to the Aggregator node. Average latency measured in the GNS3 test environment: 50-150ms on a simulated local network.
Aggregation Layer (Batch Processing): The Aggregator collects transactions into batches with a configurable interval via the BATCH_INTERVAL_SECONDS environment variable (set to 30 s in the tests). The service constructs the Merkle root and validates the data structure. The average batch processing time is 200-500ms for sizes varying from 5 to 50 transactions (MIN_BATCH_SIZE and MAX_BATCH_SIZE).
Blockchain Layer (Smart Contract Execution): The smart contract's submitBatch() function executes the following atomic operations:

Batch parameter validation (presence of at least one transaction, correctness of arrays)
Registration of the batch in the blockchain with block.timestamp
Iteration over all transactions in the batch with an anti-duplication check via mapping
On-chain storage of cryptographic hashes and transaction metadata
Emission of BatchSubmitted and TransactionRecorded events for traceability

During validation tests with experimental deployment, the gas consumption for the invocation of the submitBatch() function was measured: for a batch containing a single transaction, the gas consumed was approximately 1,646,143 gas (20.6% of the block gas limit of 8,000,000 gas).

The batch architecture was designed to optimize gas efficiency: with batches containing the maximum number of transactions (50 tx), the initial fixed cost is amortized, reducing the average cost per transaction to approximately 80,000-100,000 gas per single energy transaction. The blockchain block time in PoA configuration is about 5 s, ensuring rapid transaction finality”.

Reviewer 2 Report

Comments and Suggestions for Authors

This paper addresses the design and validation of a smart gas meter for blockchain-based distributed energy management. The authors propose a novel modular metering device that integrates an ultrasonic sensor-based flow measurement system with LoRa and NB-IoT communication technologies, thereby enhancing data integrity and security. In addition, by introducing the concept of Energy Tokens, the paper explores the management of gas consumption as verifiable digital assets on a blockchain, aiming to enable the expansion toward a peer-to-peer (P2P) energy trading market. Experimentally, the authors verified flow accuracy and pressure loss, and through blockchain network simulations, they confirmed the feasibility of an infrastructure capable of handling thousands of nodes. The paper demonstrates a high level of technical maturity, and its integrated hardware/software design is impressive.

<<General Comments>>

Strengths:

The system architecture integrating ultrasonic metering, LoRa/NB-IoT communication, and blockchain-based authentication exhibits a high degree of technological innovation.

The approach of ensuring reliability and transparency of gas metering data through energy tokenization is timely and relevant.

Both experimental validation (flow rate, pressure loss, and accuracy assessment) and network simulation (load and node structure) are balanced and well conducted.

The paper clearly presents practical application prospects, including potential industrial implementation in smart metering and energy trading systems.

<<Specific Comments>>

(1) L165–L180 (Figure 1):
The configuration of the experimental pipeline and flow conditions are clearly presented; however, an explanation of flow uncertainty (±%) is missing. The calibration procedure should be described in more detail.

(2) L374–L389 (Figure 7):
When the pressure loss exceeds the standard value (2.0 mbar), no corrective measures or design improvement strategies are suggested. Discussion of design modifications or flow limitation conditions would be beneficial.

(3) L219–L234 (Figure 5):
The hierarchical structure of the blockchain network is well explained, but it would be clearer if a table summarizing communication intervals and data size (in bytes) between nodes were provided.

(4) L309–L331:
Each step of the authentication procedure is logically described; however, there is no mention of certificate revocation or periodic renewal processes, which should be included.

(5) L445–L451 (Figure 8):
The token life cycle diagram is conceptually clear, but it would be improved by adding empirical data on smart contract execution flow or transaction latency.

Author Response

The authors thank the reviewer for his thorough review work and for his valuable comments, which helped improve the paper. Below, specific replies to comments are provided.

Comment 1: L165–L180 (Figure 1):
The configuration of the experimental pipeline and flow conditions are clearly presented; however, an explanation of flow uncertainty (±%) is missing. The calibration procedure should be described in more detail.

Response 1:

Information on the uncertainty of the flowmeter used as a reference in the loop has been added to Section 2.1. Moreover, the following sentence has been added: “Some tests were carried out to check the behavior of the ultrasonic flow sensor: in particular, five repeated measurements have been performed for each flow condition, and mean and standard deviation have been calculated, and compared with the values provided by the reference flowmeters.”

As for the pressure measurement, in Section 2.1 the following sentences have been added: “The pressure sensors have been calibrated by comparison with the reference gauge, realizing different pressure conditions (0, 0.01, 0.02, 0.1, 0.2, 0.3, 0.4 and 0.5 bar) at the measuring point shown in Figure 3.b. The uncertainty contribution of linearity has been estimated as the maximum deviation of the measured values from the least squares regression line, assuming a rectangular probability distribution [21]. Furthermore, a repeatability test has been carried out by means of ten repeated measurements, in order to evaluate, through a standard deviation of the results, the repeatability uncertainty. Finally, the contributions of repeatability, linearity and reference uncertainty have been combined together [21] to evaluate the calibration uncertainty.”

Comment 2: L374–L389 (Figure 7):
When the pressure loss exceeds the standard value (2.0 mbar), no corrective measures or design improvement strategies are suggested. Discussion of design modifications or flow limitation conditions would be beneficial.

Response 2:

Comment 3: L219–L234 (Figure 5):
The hierarchical structure of the blockchain network is well explained, but it would be clearer if a table summarizing communication intervals and data size (in bytes) between nodes were provided.

Response 3:

The summarizing table about communication intervals and data size between nodes has been added as Table 2 in Section 2.3.1

Comment 4: L309–L331:
Each step of the authentication procedure is logically described; however, there is no mention of certificate revocation or periodic renewal processes, which should be included.

Response 4:

Information on the revocation and renewal processes has been added to section 2.3.4. The following sentence has been added: “Once the accreditation process is done, a certificate is issued and its renewal is carried out annually, always managed by the Certification Authority. This process involves periodic verification of the manufacturing company’s compliance with technical and security requirements, as well as checking the integrity and authenticity of registered devices. When the outcome of the verification process is positive, then the Certification Authority proceeds to the certificate renewal by issuing a new set of cryptographic keys and updating, if necessary, the serial codes generation algorithms. This mechanism ensures system operational continuity and reduces the risk of long-term compromise of authentication keys. At the same time, the Certification Authority carries out constant monitoring of active certifications, verifying any anomalies, expirations, or cases of non-compliance that could compromise system security.
When these conditions occur, the certification revocation procedure is activated so the public keys associated with the devices are invalidated and removed from the blockchain's ledger of trust.
As a result, even if the device retains the ability to correctly generate serial numbers using the algorithm unlocked in the firmware, these are no longer valid.
The blockchain, in fact, automatically rejects any authentication attempt coming from devices with revoked keys, preventing the validation of transactions”.

Comment 5: L445–L451 (Figure 8):
The token life cycle diagram is conceptually clear, but it would be improved by adding empirical data on smart contract execution flow or transaction latency.

Response 5:

Information on the smart contract execution flow and transaction latency has been added to Section 3.2.4:
“The blockchain infrastructure implemented for the purpose of experimental validation is based on an EnergyBatchRegistry.sol smart contract (283 lines of Solidity code), deployed on Hyperledger Besu 24.12.0 with Proof of Authority consensus.

The contract manages the registration of energy transaction batches through two main data structures: Batch and EnergyTransaction.
The complete lifecycle of an energy token involves several phases with specific latencies measured during system validation tests:

Edge Layer (GasMeter Node → Aggregator): Edge nodes generate transactions signed with Ed25519 (average payload 775-835 bytes) and transmit them via MQTT to the Aggregator node. Average latency measured in the GNS3 test environment: 50-150ms on a simulated local network.
Aggregation Layer (Batch Processing): The Aggregator collects transactions into batches with a configurable interval via the BATCH_INTERVAL_SECONDS environment variable (set to 30 s in the tests). The service constructs the Merkle root and validates the data structure. The average batch processing time is 200-500ms for sizes varying from 5 to 50 transactions (MIN_BATCH_SIZE and MAX_BATCH_SIZE).
Blockchain Layer (Smart Contract Execution): The smart contract's submitBatch() function executes the following atomic operations:

Batch parameter validation (presence of at least one transaction, correctness of arrays)
Registration of the batch in the blockchain with block.timestamp
Iteration over all transactions in the batch with an anti-duplication check via mapping
On-chain storage of cryptographic hashes and transaction metadata
Emission of BatchSubmitted and TransactionRecorded events for traceability

Reviewer 3 Report

Comments and Suggestions for Authors

Based on the analysis of the article, it was found that it is devoted to a topical scientific and technical area. The authors conducted thorough experimental work. However, there are certain comments on the article that would improve the objectivity and reproducibility of the research results, namely:

The overview and analysis of the known types of sensors listed in the introduction are recommended to be presented in a comparative table, which will improve the quality of the analysis and interpretation of the relevant results.
In the introduction, more attention should be paid to research work on the architectural integration of networked gas meters. The problems of the hardware and software structure of such meters should be more precisely localised. Based on this, the research tasks of the article and the proposed ways of solving them should be localised. The implementation of LoRa and NB-IoT technologies is a fairly popular solution in modern practice, so the authors should indicate the research issues more thoroughly.
The authors should provide a more detailed substantiation for the simultaneous use of two network technologies: NB-IoT and LoRa. They should also describe in more detail the application scenarios for each of these two network technologies.
In subsection 2.1, it is necessary to add information on metrological assessments of the technical means used, as well as the metrics used to assess the overall accuracy of the test sample.
In subsection 2.3.1, authors are recommended to provide information about the type of blockchain used (public, private, permissioned, or other) and its parameters.
Section 2.3.2 should describe in more detail the network load parameters during modelling: the number of connected nodes, delay, etc.
Section 3 is not sufficiently thorough. The authors are advised to provide the results of statistical analysis of the findings, identify sources of error, etc. This will allow the objectivity of the findings to be assessed.
The article should include a Discussion section, which should present the results of a critical analysis of the outcomes, including comparisons with known solutions. This section should also describe the limitations of the technology proposed by the authors in real cases of use.

Author Response

The authors thank the reviewer for his thorough review work and for his valuable comments, which helped improve the paper. Below, specific replies to comments are provided.

Comment 1: The overview and analysis of the known types of sensors listed in the introduction are recommended to be presented in a comparative table, which will improve the quality of the analysis and interpretation of the relevant results.

Response 1:

Thank you for your suggestion. A summary table of the main characteristics of the flow meters has been added in the Introduction.

Comment 2: In the introduction, more attention should be paid to research work on the architectural integration of networked gas meters. The problems of the hardware and software structure of such meters should be more precisely localised. Based on this, the research tasks of the article and the proposed ways of solving them should be localised. The implementation of LoRa and NB-IoT technologies is a fairly popular solution in modern practice, so the authors should indicate the research issues more thoroughly.

Response 2:

Thank you for the suggestion. A brief paragraph about hardware/software problems in recent LoRa-NB-IoT smart gas meters implementations has been integrated in the introduction: “Recent developments in smart-utility metering have significantly advanced remote monitoring, diagnostics and automated billing for gas infrastructure. In this context, smart gas meters incorporate electronic measurement modules, low-power wide-area network (LPWAN) communications and backend integration. As an example, Al-Sammak et al. built a smart-meter prototype integrating both LoRaWAN and NB‑IoT modules and applied an adaptive algorithm to reduce packet transmissions [11]. Their results claim packet reductions of up to ~76 % (LoRaWAN) and ~86 % (NB-IoT), and energy-spike reductions of ~88 % and ~87 % respectively. Nevertheless, this result comes without a proper data management security structure based on IoT models, such as blockchains. Additionally, the choice of LoRaWAN over other LoRa protocols may lead, in specific situations, to limitations in large-scale deployments, involving collisions, interference, and duty-cycle constraints [12]. As a matter of fact, security in data management and the choice of the proper LoRa protocol remain open challenges for smart metering systems.”

[8]: Al-Sammak, K.A.; Al-Gburi, S.H.; Marghescu, I.; Drăgulinescu, A.-M.C.; Marghescu, C.; Martian, A.; Al-Sammak, N.A.H.; Suciu, G.; Alheeti, K.M.A. Optimizing IoT Energy Efficiency: Real-Time Adaptive Algorithms for Smart Meters with LoRaWAN and NB-IoT. Energies 2025, 18, 987. https://doi.org/10.3390/en18040987.

[9]: Jouhari, M.; Saeed, N.; Alouini, M.-S.; Amhoud, E.M. A Survey on Scalable LoRaWAN for Massive IoT: Recent Advances. IEEE Communications Surveys & Tutorials 2023, 25, 1841–1876, doi:10.1109/comst.2023.3274934.

Comment 3: the authors should provide a more detailed substantiation for the simultaneous use of two network technologies: NB-IoT and LoRa. They should also describe in more detail the application scenarios for each of these two network technologies.

Response 3:

Thank you for the suggestion, a more detailed explanation about the simultaneous use of NB-IoT and LoRa has been provided in Sec. 2.2: “In particular, the combined use of the two technologies is justified by the need for flexibility depending on the specific smart gas meter installation. In fact, NB-IoT is used to send data directly to the internet, while LoRa technology is either used when:

NB-IoT coverage is limited, hence data is sent, through LoRa, to the nearest covered point;
when many gas meters of this type are installed in a neighborhood.

In the latter situation, the closest smart gas meter is installed in a 50 m range, thus, data from each device is forwarded through LoRa to a local gateway, for data gathering and transmission to the internet for its visualization and blockchain integration. Specifically, LoRaP2P was chosen as protocol due to its packet customizability and, thus, its low-power feasibility. On the other hand, when the gas meter of interest is the only device installed in a neighborhood, hence, there are no smart gas meters in a 50 m range, NB-IoT is used.”.

Comment 4: In subsection 2.1, it is necessary to add information on metrological assessments of the technical means used, as well as the metrics used to assess the overall accuracy of the test sample.

Response 4:

Information on the uncertainty of the flowmeter used as a reference in the loop has been added to Section 2.1: “Two reference flow meters (uncertainty of 2.5 % f.s.) with different measuring ranges (4 - 50 l/min and 10 - 100 l/min) have been inserted in series along the loop of Figure 1”.

Moreover, the following sentence has been added: “Some tests were carried out to check the behavior of the ultrasonic flow sensor: in particular, five repeated measurements have been performed, and mean and standard deviation have been calculated, and compared with the values provided by the reference flowmeters.” Correspondingly, in the Results section, the test results have been reported: “The results show that the variability was in the order of 2 %, and the maximum relative error of the mean with respect to the indication of the reference flow measuring device operating in series along the loop of Figure 1 was in the range 4 to 5 %.”

As for the pressure measurement, in Section 2.1 the following sentences have been added: “The pressure sensors have been calibrated by comparison with the reference gauge, realizing different pressure conditions (0, 0.01, 0.02, 0.1, 0.2, 0.3, 0.4 and 0.5 bar) at the measuring point shown in Figure 3.b. The uncertainty contribution of linearity has been estimated as the maximum deviation of the measured values from the least squares regression line, assuming a rectangular probability distribution [19]. Furthermore, a repeatability test has been carried out by means of ten repeated measurements, in order to evaluate, through a standard deviation of the results, the repeatability uncertainty. Finally, the contributions of repeatability, linearity and reference uncertainty have been combined together [19] to evaluate the calibration uncertainty.”

Comment 5: In subsection 2.3.1, authors are recommended to provide information about the type of blockchain used (public, private, permissioned, or other) and its parameters.

Response 5:

Information on the blockchain type used and its parameters has been added to Section 2.3.1:
The system implemented for experimental validation is based on a private and permissioned blockchain with the following characteristics:

Network Type: Private Permissioned (Hyperledger Besu with Proof of Authority consensus algorithm)
Mechanism: Proof of Authority (PoA) with pre-authorized validators
Network ID: 1337 (custom private network identifier)
Block Time: ~5 s in test configuration
Block Gas Limit: 8.000.000 gas
Theoretical Capacity: ~4–5 batches per block (with optimal batches of 50 tx), equivalent to ~200–250 energy transactions per block

Comment 6: Section 2.3.2 should describe in more detail the network load parameters during modelling: the number of connected nodes, delay, etc.

Response 6:

Information on the network parameters has been added to Section 2.3.2:
“The topology includes dedicated switches for each layer (AuthoritySwitch, AggregatorSwitch, ConsumerEdgeSwitch) connected via a central ISPSwitch for inter-VLAN routing, simulating a realistic geographical distribution.

The following traffic generation parameters were configured for system validation:

1. Transaction Generation Frequency:

Consumer node: 1 transaction every 60 s (average consumption 2–8 kWh)
Producer node: 1 transaction every 45 s (average production 5–15 kWh)
Prosumer node: 1 transaction every 90 s (production/consumption/transfer mix)

2. MQTT Broker Load (Aggregator):

Concurrent Connections: Tested from 3 edge devices (PoC) up to 500 simultaneous connections in stress tests
Message Throughput: 100–200 msg/s in stress test scenarios
QoS Used: QoS 1 (At Least Once) to ensure reliable delivery of critical energy transactions
Keep-alive: 60 s
Average Payload Size: 775–835 bytes (JSON signed with Ed25519)

3. Batch Configuration and Throughput:

Batch Interval: 30 s (configurable via BATCH_INTERVAL_SECONDS in the 10–120s range)
Batch Size: Min 1 tx, Max 50 tx (adaptive based on network load)
Theoretical Blockchain Throughput: ~240 transactions/minute with optimal batches (48 tx/batch × 5 blocks/min)
Observed Blockchain Throughput: ~100 transactions/minute in nominal test scenarios

End-to-end latencies were measured during 2-hour test sessions:

Edge → Aggregator (MQTT): 50–150 ms (dependent on simulated network latency)
Batch processing: 200–500 ms (a function of batch size and Merkle tree construction)
Smart contract execution: 800–1200 ms (dependent on gas used and batch complexity)
Block confirmation: ~5 s (PoA block time)
Total End-to-End Latency: 6–37 s (average 20s)

The total latency varies significantly as a function of the transaction's arrival time relative to the batching cycle: in the optimal case (transaction arrived at the start of the batch window), the total time is approximately 6 s; in the worst case (transaction arrived immediately after the previous batch was sent), the time extends up to 37 s including the wait for the next cycle.”

Comment 7: Section 3 is not sufficiently thorough. The authors are advised to provide the results of statistical analysis of the findings, identify sources of error, etc. This will allow the objectivity of the findings to be assessed.

Response 7:

Thank you for the comment. The answer to point 4 should also address this observation.

Comment 8: The article should include a Discussion section, which should present the results of a critical analysis of the outcomes, including comparisons with known solutions. This section should also describe the limitations of the technology proposed by the authors in real cases of use.