Pith. sign in

REVIEW 3 major objections 4 minor 22 references

EDGChain-E: A Decentralized Git-Based Framework for Versioning Encrypted Energy Data

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper proposes EDGChain-E, a decentralized Git-based framework that stores encrypted energy data patches on IPFS and logs every commit's hash on a blockchain, aiming to offer integrity, traceability, and privacy in one system.

desk verdict A clear design sketch for encrypted Git-style versioning on IPFS/Ethereum, with a real, load-bearing revocation flaw and no evaluation to back the stated guarantees. read the letter →

arxiv 2507.01615 v1 pith:DEVXSCIV submitted 2025-07-02 cs.DC cs.CR

Alper Alimoglu , Kamil Erdayandi , Mustafa A. Mustafa , Ümit Cali This is my paper
classification cs.DCcs.CR
keywords decentralizeddataversioningencryptedGitpatchesIPFScontent-addressedstorageblockchainprovenancesmartcontractsenergyprivacyFAIRhybridencryption
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper sets out to show that versioned, encrypted energy data can be managed without a central authority by combining Git-style delta patches with decentralized storage and an immutable commit log. The proposed framework, EDGChain-E, stores only encrypted blobs on IPFS, records each version's content identifier and parent link on an Ethereum smart contract, and keeps all key material client-side. If the design works as claimed, researchers, utilities, and regulators could collaborate on sensitive smart-meter or grid data while preserving a verifiable, auditable history that satisfies FAIR provenance requirements. The contribution is an architecture, not an implementation study: the paper defines the commit workflow, reconstruction procedure, and security model, and leaves access control and tooling for future work.

What carries the argument

The load-bearing mechanism is an encrypted Git-style patch chain whose content identifiers are committed on-chain: each commit in the smart contract contains the new IPFS CID, a parent CID, encrypted key references, and role-based modifiers, forming a cryptographically verifiable linked list of versions. The client-side hybrid encryption layer—AES-256-GCM for data and asymmetric wrapping of the data encryption key for recipients—ensures that plaintext is never exposed outside authorized clients, while IPFS's SHA-256 content addressing makes any tampering detectable. This combination carries the argument because integrity comes from the hash chain, traceability from the on-chain commit log, and confidentiality from the client-side encryption boundary.

What would settle it

The confidentiality claim would fail if someone who obtains the key file sent by email and the public content addresses can decrypt the dataset, or if a collaborator removed from the project can still decrypt new patches; both scenarios are testable without modifying the system.

Watch

Extended reading notes

Core claim

EDGChain-E's core claim is that integrity, traceability, and confidentiality can be achieved simultaneously for versioned energy data by separating data from metadata. A genesis file and subsequent patches are encrypted with a fresh data encryption key using AES-256-GCM, uploaded to IPFS, and referenced only by their content-addressable hashes; the hash chain linking each commit to its parent is stored in a smart contract, forming an immutable audit trail. Authorized collaborators reconstruct any version by traversing the commit chain, downloading and decrypting each patch, and applying it locally, so intermediaries and IPFS nodes never see plaintext. The paper argues this supports FAIR-compliant provenance and reproducibility for energy applications such as smart-grid monitoring, demand forecasting, and peer-to-peer trading, where raw data is sensitive and regulated.

Load-bearing premise

The confidentiality guarantee depends on the assumption that the encrypted data keys reach authorized collaborators through a secure channel, such as email, that cannot be intercepted or misdirected; the framework defines no access-control or revocation mechanism for that channel.

Editorial extensions

If this is right

  • If a data blob is altered, its IPFS content identifier changes and the on-chain hash no longer matches, so tampering is immediately detectable.
  • An authorized collaborator can reconstruct the dataset as of any commit by recursively applying encrypted patches, with no trusted storage node required.
  • Storing patches instead of full snapshots reduces IPFS storage and network transfer for each update.
  • The ledger's immutability provides a signed, timestamped audit trail of all commits, supporting reproducibility claims in regulated energy research.
  • A predefined number of commits can be compressed into a new genesis checkpoint, bounding reconstruction effort while keeping the full history available.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper treats data-encryption-key distribution by email or a similar secure channel as out of scope; a concrete next step would be to replace this with automated key management or on-chain access control, and to test revocation behavior when a collaborator leaves.
  • Because the versioning and encryption layers are domain-agnostic, the same design should transplant to health records or financial data, where retention and audit requirements are analogous.
  • The N-commit genesis checkpoint introduces a tunable trade-off between reconstruction cost and storage: larger N keeps patches small but deepens the chain, while smaller N increases storage per checkpoint.
  • A practical deployment would need to measure patch sizes for smart-meter or grid telemetry with real workloads to see whether the storage-efficiency argument holds at scale.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes EDGChain-E, a decentralized framework that combines Ethereum smart contracts, IPFS, and Git-style patching to version encrypted energy data. The design encrypts genesis files and subsequent patches with AES-256-GCM using a data encryption key (DEK), wraps the DEK for intended recipients using public-key cryptography, stores encrypted blobs on IPFS, and records IPFS CIDs and parent links on a blockchain. The authors claim that this provides integrity, traceability, confidentiality, and FAIR-compliant provenance for collaborative energy research data. The manuscript is a design description: it presents the architecture, a commit-and-retrieval workflow, and a discussion of security properties, but reports no implementation, experiments, benchmarks, or formal analysis.

Significance. If the design worked as claimed, it would address a genuine gap: there are few practical systems that combine version control, encryption, and blockchain-anchored auditability for sensitive energy datasets. The paper also makes useful connections to FAIR data principles and prior eScience work. However, the central confidentiality guarantee is not supported by the described mechanism, and the manuscript contains no evaluation that would substantiate the asserted robustness and efficiency. The contribution is therefore currently a high-level architecture sketch rather than a validated system.

major comments (3)
  1. [Section III, steps 1-8; Section IV; Section V] The confidentiality claim is violated by ordinary membership changes under the stated design. Section IV states that 'a single DEK is used for each genesis file and all of its patches until the next genesis file.' Section III, step 3, distributes encrypted DEKs via email or another secure channel, and Section IV says smart-contract role modifiers only gate writes (commits, access-list edits), not reads of IPFS blobs. A revoked collaborator who retains the DEK can continue to download and decrypt every subsequent patch up to the next genesis checkpoint. This directly contradicts the claim in Section III's final paragraph that 'only authorized users with the correct decryption keys can reconstruct the original file.' The paper itself lists 'No access control' in Table I and defers 'grant access functionality' to future work in Section V. Because privacy is a headline contribution, this is a load-bearing flaw that requires either a redesign with per-version DEKs and re-encryption on revocation, or a clearly bounded and justified trust assumption about never-revoked collaborators.
  2. [Section V; overall] The conclusion states that the hybrid encryption scheme 'has been demonstrated to provide a robust, efficient, and privacy-preserving mechanism,' but the manuscript contains no implementation, no measurements, no security proof, and no comparative evaluation. The only concrete artifact mentioned is a GitHub repository link in Section III; no tests, benchmarks, gas-cost analyses, or scalability results are reported. For a systems paper, this claim is unsupported. The authors should either add an experimental evaluation (e.g., storage overhead, patch-size behavior, retrieval latency, on-chain costs) or materially weaken the conclusion to describe a proposed design rather than a demonstrated one.
  3. [Table I vs. Section IV] There is an internal inconsistency about access control. Table I lists 'No access control' as a limitation of EDGChain-E, while Section IV states that 'Role-based permissions (e.g. owner, contributor, reviewer) are enforced via modifiers' and that only authorized callers can publish new commits or modify access lists. The paper also describes two different key-distribution models—DEKs sent by email in Section III, step 3, and a per-recipient encrypted DEK file in Section IV—without explaining how these relate to the claimed role-based permissions. These statements need to be reconciled and clarified, since access control is central to the confidentiality argument.
minor comments (4)
  1. [Section IV] The text 'This incremental design of DGChain-E ensures' and 'Cryptographic Primitives used for DGChain-E' use the name 'DGChain-E' instead of 'EDGChain-E'; please correct these typos.
  2. [Table I] In the Zenodo/Figshare row, 'No encryptionek' appears to be a typo; it should likely read 'No encryption.'
  3. [Introduction] The phrase 'large andsensitive' in the first paragraph of Section I is missing a space and should read 'large and sensitive.'
  4. [Section III, step 3] The sentence 'The CIDs are obtained from the smart contract, whereas the corresponding encrypted DEKs are distributed by the project owner to members of the collaboration group via email or another secure communication channel' should clarify whether the DEK file is stored on-chain, on IPFS, or only out-of-band, since step 7 says users query the smart contract and then decrypt the DEK.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: EDGChain-E is an architecture proposal whose stated guarantees rest on standard cryptographic primitives and on-chain logging, not on its own outputs or fitted parameters.

full rationale

This paper does not contain a derivation chain in the sense of fitting parameters and predicting outcomes. Its central claims are constructional: that encrypted Git-style patches stored on IPFS with CIDs logged on-chain provide integrity, traceability, and confidentiality. The integrity claim follows directly from SHA-256 content addressing, and the confidentiality claim follows from AES-256-GCM encryption plus per-recipient DEK wrapping; these are adopted as standard cryptographic assumptions, not derived from the conclusion. No equation is defined in terms of the result it is supposed to establish, and no fitted input is renamed as a prediction. The self-citations to prior work by the authors (references [17], [18], and [19]) appear only as a statement that the framework 'could complement' those efforts, so they are not load-bearing for the central claims. The paper's own admission in Table I that it has 'No access control' and its deferral of 'grant access functionality' to future work is a substantive security-correctness concern about revocation and key management, but it is not circular reasoning: the claimed confidentiality guarantee is under-specified and possibly violated, yet it does not reduce to its own inputs by definition. In particular, the single-DEK design means a revoked collaborator who retains the DEK can continue decrypting patches, which undermines the confidentiality claim, but this is a design flaw rather than a circular derivation. Accordingly, no circular step is identified, and the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No free parameters are fitted. The framework rests on standard assumptions about IPFS, Ethereum, and hybrid encryption. No new entities are postulated.

assumptions (3)
  • domain assumption IPFS content addressing via SHA-256 guarantees tamper-evident integrity
    The design relies on IPFS CIDs being collision-resistant and immutable (Section III, step 3).
  • domain assumption Ethereum smart contracts provide immutable, signed audit logs
    The commit chain and event logs are assumed to be permanent and tamper-resistant (Section III, steps 5-6).
  • domain assumption AES-256-GCM with per-recipient key wrapping provides end-to-end confidentiality
    The security model assumes standard hybrid encryption is correctly deployed (Section III, step 2 and Section IV).

how reviews work

0 comments
Cite this review

Pith. "Pith review of EDGChain-E: A Decentralized Git-Based Framework for Versioning Encrypted Energy Data." pith.science (2026). https://pith.science/paper/DEVXSCIV

@misc{pith2026250701615,
  author       = {Pith},
  title        = {Pith review of: EDGChain-E: A Decentralized Git-Based Framework for Versioning Encrypted Energy Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DEVXSCIV}},
  note         = {Machine review of arXiv:2507.01615}
}
read the original abstract

This paper proposes a new decentralized framework, named EDGChain-E (Encrypted-Data-Git Chain for Energy), designed to manage version-controlled, encrypted energy data using blockchain and the InterPlanetary File System. The framework incorporates a Decentralized Autonomous Organization (DAO) to orchestrate collaborative data governance across the lifecycle of energy research and operations, such as smart grid monitoring, demand forecasting, and peer-to-peer energy trading. In EDGChain-E, initial commits capture the full encrypted datasets-such as smart meter readings or grid telemetry-while subsequent updates are tracked as encrypted Git patches, ensuring integrity, traceability, and privacy. This versioning mechanism supports secure collaboration across multiple stakeholders (e.g., utilities, researchers, regulators) without compromising sensitive or regulated information. We highlight the framework's capability to maintain FAIR-compliant (Findable, Accessible, Interoperable, Reusable) provenance of encrypted data. By embedding hash-based content identifiers in Merkle trees, the system enables transparent, auditable, and immutable tracking of data changes, thereby supporting reproducibility and trust in decentralized energy applications.

Figures

Figures reproduced from arXiv: 2507.01615 by the authors.

Figure 1
Figure 1. Components of EDGChain-E [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Reconstruction of the full version history timeline. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Secure Data Sharing in Decentralized Systems Using Sym [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

22 extracted references · 20 canonical work pages

  1. [1]

    The FAIR guiding principles for scientific data management and stewardship,

    M. D. Wilkinson, M. Dumontier, and e. a. Aalbersber, “The FAIR guiding principles for scientific data management and stewardship,”Scientific Data, vol. 3, no. 1, p. 16001, Mar. 2016

    work page 2016

  2. [2]

    Software Heritage: Why and How to Preserve Software Source Code,

    R. Di Cosmo and S. Zacchiroli, “Software Heritage: Why and How to Preserve Software Source Code,” in iPRES 2017 - 14th International Conference on Digital Preservation, Kyoto, Japan, Sep. 2017, pp. 1–10. [Online]. Available: https://hal.science/hal-01590958

    work page 2017

  3. [3]

    Smart meter data privacy: A survey,

    M. R. Asghar, G. Dán, D. Miorandi, and I. Chlamtac, “Smart meter data privacy: A survey,”IEEE Communications Surveys & Tutorials, vol. 19, no. 4, pp. 2820–2835, 2017

    work page 2017

  4. [4]

    Pp-lem: Efficient and privacy-preserving clearance mechanism for local energy mar- kets,

    K. Erdayandi and M. A. Mustafa, “Pp-lem: Efficient and privacy-preserving clearance mechanism for local energy mar- kets,” Sustainable Energy, Grids and Networks, vol. 39, p. 101477, 2024

    work page 2024

  5. [5]

    Privacy- preserving and accountable billing in peer-to-peer energy trad- ing markets with homomorphic encryption and blockchain,

    K. Erdayandi, L. C. Cordeiro, and M. A. Mustafa, “Privacy- preserving and accountable billing in peer-to-peer energy trad- ing markets with homomorphic encryption and blockchain,” Sustainable Energy, Grids and Networks, vol. 41, p. 101568, 2025

    work page 2025

  6. [6]

    Smart grid metering networks: A survey on security, privacy and open research issues,

    P. Kumar, Y. Lin, G. Bai, A. Paverd, J. S. Dong, and A. Martin, “Smart grid metering networks: A survey on security, privacy and open research issues,” IEEE Communications Surveys & Tutorials, vol. 21, no. 3, pp. 2886–2927, 2019

    work page 2019

  7. [7]

    Towards privacy preserving local energy markets,

    K. Erdayandi, L. C. Cordeiro, and M. A. Mustafa, “Towards privacy preserving local energy markets,” inCompetitive Ad- vantage in the Digital Economy (CADE 2022), vol. 2022. IET, 2022, pp. 127–134

    work page 2022

  8. [8]

    Digital privacy and cyberphysical security perspectives of grid-edge power systems and markets,

    U. Cali, M. F. Dynge, F. Kamal, R. Deo, B. Chowdhury, and R. Cox, “Digital privacy and cyberphysical security perspectives of grid-edge power systems and markets,” in2023 IEEE PES Innovative Smart Grid Technologies Europe (ISGT EUROPE). IEEE, 2023, pp. 1–5

    work page 2023

Show all 22 references
  1. [9]

    Zenodo, “Zenodo,” https://zenodo.org/, accessed: 2025-06-30

    2025

  2. [10]

    “Dvc,” June. 2025. [Online]. Available: https://dvc.org/

    2025

  3. [11]

    Blockchain-based data provenance framework for scientific data,

    A. Koutroumpouchos and D. Smith, “Blockchain-based data provenance framework for scientific data,” Journal of Blockchain Technology in Science, vol. 13, no. 2, pp. 45–61, 2021

    2021

  4. [12]

    Blockchain for secure and transparentdataprovenanceinresearchprojects,

    S. Kumar, R. Patel, and C. Lee, “Blockchain for secure and transparentdataprovenanceinresearchprojects,” International Journal of Distributed Computing and Systems, vol. 16, no. 4, pp. 78–93, 2022

    2022

  5. [13]

    Decentralized solutions for provenance in scientific workflows,

    J. Martin, R. Garcia, and P. Soto, “Decentralized solutions for provenance in scientific workflows,”Computational Science and Engineering, vol. 25, no. 5, pp. 130–144, 2022

    2022

  6. [14]

    Leveraging blockchain for data provenance in cloud computing,

    L. Zhang, H. Wang, and F. Zhao, “Leveraging blockchain for data provenance in cloud computing,”IEEE Transactions on Cloud Computing, vol. 11, no. 1, pp. 120–133, 2023

    2023

  7. [15]

    Dgchain:Datacontrolversionfortrustworthy reproducibilitywithblockchain,

    J.A.Hernandez,“Dgchain:Datacontrolversionfortrustworthy reproducibilitywithblockchain,”in 20246thInternationalCon- ference on Blockchain Computing and Applications (BCCA). IEEE, 2024, pp. 648–653

    2024

  8. [16]

    K. L. Neela, “DSDOS cloud: A decentralized secure data outsourcing system with hybrid encryption, blockchain smart contract-based access control, and hash authentication codes for cloud security,”Transactions on Emerging Telecommunications Technologies,vol.35,no.11,p.e70016,20...

    2024 doi

  9. [17]

    An autonomous blockchain-based computational broker for e-science,

    A. Alimoğlu and C. Özturan, “An autonomous blockchain-based computational broker for e-science,” Concurrency and Computation: Practice and Experience , vol. 36, no. 13, p. e8087, 2024. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.8087

    2024 doi

  10. [18]

    Design of a smart contract based autonomous organization for sustainable software,

    A. Alimoglu and C. Özturan, “Design of a smart contract based autonomous organization for sustainable software,” in 13th IEEE International Conference on e-Science, e-Science 2017, Auckland, New Zealand, October 24-27, 2017. IEEE Computer Society, 2017, pp. 471–476. [Online]. ...

    2017 doi

  11. [19]

    Anautonomousblockchain-based workflow execution broker for e-science,

    A.AlimoğluandC.Özturan,“Anautonomousblockchain-based workflow execution broker for e-science,”Cluster Computing,

  12. [20]

    Open science framework (osf),

    E. Foster and A. Deardorff, “Open science framework (osf),” Journal of the Medical Library Association: JMLA , vol. 105, no. 2, pp. 203–206, 2017. [Online]. Available: https://doi.org/10.5195/jmla.2017.88

    2017 doi

  13. [21]

    The research data alliance: Towards the adoption of practices for data sharing and reuse,

    L. Candela, D. Castelli, and P. Pagano, “The research data alliance: Towards the adoption of practices for data sharing and reuse,” International Journal of Digital Curation, vol. 10, no. 1, pp. 7–19, 2015. [Online]. Available: https://doi.org/10.2218/ijdc.v10i1.364

    2015 doi

  14. [2024]

    Available: https://doi.org/10.1007/s10586-024- 04534-z

    [Online]. Available: https://doi.org/10.1007/s10586-024- 04534-z

    doi

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.