An integrated blockchain and IPFS-based solution for secure and efficient source code repository hosting using middleman approach

Md. Rafid Haque; Sakibul Islam Munna; Sabbir Ahmed; Md. Tahmid Islam; Md Mehedi Hassan Onik; A.B.M. Ashikur Rahman

doi:10.1371/journal.pone.0331131

Peer Review History

Original SubmissionSeptember 27, 2024
13 Jun 2025 Decision Letter - Yang (Jack) Lu, Editor PONE-D-24-43266An Integrated Blockchain and IPFS-based Solution for Secure and Efficient Source Code Repository Hosting using Middleman ApproachPLOS ONE Dear Dr. Ahmed, Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process. Please submit your revised manuscript by Jul 28 2025 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file. Please include the following items when submitting your revised manuscript: A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'. A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'. An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'. If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter. If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols. We look forward to receiving your revised manuscript. Kind regards, Yang (Jack) Lu, PhD Academic Editor PLOS ONE Journal Requirements: When submitting your revision, we need you to address these additional requirements. 1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf 2. Please note that PLOS ONE has specific guidelines on code sharing for submissions in which author-generated code underpins the findings in the manuscript. In these cases, all author-generated code must be made available without restrictions upon publication of the work. Please review our guidelines at https://journals.plos.org/plosone/s/materials-and-software-sharing#loc-sharing-code and ensure that your code is shared in a way that follows best practice and facilitates reproducibility and reuse. 3. Please provide a complete Data Availability Statement in the submission form, ensuring you include all necessary access information or a reason for why you are unable to make your data freely accessible. If your research concerns only data provided within your submission, please write "All data are in the manuscript and/or supporting information files" as your Data Availability Statement. [Note: HTML markup is below. Please do not edit.] Reviewers' comments: Reviewer's Responses to Questions Comments to the Author 1. Is the manuscript technically sound, and do the data support the conclusions? The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented. Reviewer #1: Yes Reviewer #2: Yes ******** 2. Has the statistical analysis been performed appropriately and rigorously? Reviewer #1: Yes Reviewer #2: No ****** 3. Have the authors made all data underlying the findings in their manuscript fully available? The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified. Reviewer #1: Yes Reviewer #2: No ****** 4. Is the manuscript presented in an intelligible fashion and written in standard English? PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here. Reviewer #1: Yes Reviewer #2: No ****** 5. Review Comments to the Author Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters) Reviewer #1: Dear authors, The scientific contribution of this study is fine. Article presentation and reference literature must be improved. I have a few minor concerns. 1. Abstract and Conclusion must be revised. Make is concise but solid. 2. It is suggested to avoid writing short paragraphs which cause inconvenience in writing flow. 3. Motivation and Organization of this study must6 be clear defined. 4. Figures must be revised and an interested presentation should be adopted with high resolution quality. 5. The authors should carefully check if all abbreviations are defined at the first place for better readability. 6. Reference literature must be updated and suggested to add following articles i. Liu, Y., Jia, Z., Jiang, Z., Lin, X., Liu, J., Wu, Q.,... Susilo, W. (2024). BFL-SA: Blockchain-based federated learning via enhanced secure aggregation. Journal of Systems Architecture, 152, 103163. doi: https://doi.org/10.1016/j.sysarc.2024.103163 ii. Liu, Y., & Zhao, Y. (2024). A Blockchain-Enabled Framework for Vehicular Data Sensing: Enhancing Information Freshness. IEEE Transactions on Vehicular Technology, 1-14. doi: 10.1109/TVT.2024.3417689 iii. Sun, G., Xu, Z., Yu, H., Chen, X., Chang, V.,... Vasilakos, A. V. (2020). Low-Latency and Resource-Efficient Service Function Chaining Orchestration in Network Function Virtualization. IEEE Internet of Things Journal, 7(7), 5760-5772. doi: 10.1109/JIOT.2019.2937110 iv. Sun, G., Zhu, G., Liao, D., Yu, H., Du, X.,... Guizani, M. (2019). Cost-Efficient Service Function Chain Orchestration for Low-Latency Applications in NFV Networks. IEEE Systems Journal, 13(4), 3877-3888. doi: 10.1109/JSYST.2018.2879883 v. Sun, G., Li, Y., Liao, D., & Chang, V. (2018). Service Function Chain Orchestration Across Multiple Domains: A Full Mesh Aggregation Approach. IEEE Transactions on Network and Service Management, 15(3), 1175-1191. doi: 10.1109/TNSM.2018.2861717 vi. Yang, J., Yang, K., Xiao, Z., Jiang, H., Xu, S.,... Dustdar, S. (2023). Improving Commute Experience for Private Car Users via Blockchain-Enabled Multitask Learning. IEEE Internet of Things Journal, 10(24), 21656-21669. doi: 10.1109/JIOT.2023.3317639 7. Material and Methods are fine. Better to improve writing for results discussion. Reviewer #2: The manuscript presents a novel architecture that combines blockchain, IPFS, and a temporary centralized middleman to build a secure and efficient decentralized version control system (VCS) for source code. The system is designed to address key limitations of existing blockchain-based VCS solutions—specifically issues of latency, scalability, access control, and secure collaboration. Lack of Empirical Evaluation: Issue: The manuscript fails to provide quantitative performance results. Any benchmark, latency analysis, or transaction cost metrics do not support claims regarding scalability, efficiency, and performance improvement over existing systems. Provide experimental evaluations comparing Blockchain gas fees with/without Middleman IPFS, upload/download time and throughput metrics, and comparisons with traditional centralized systems (e.g., GitHub/GitLab). Unclear Novelty Beyond Engineering Integration: The “Middleman IPFS” is essentially a cache or temporary node. While practical, this seems like an engineering optimization, not a fundamentally new algorithm or protocol. Clarify the scientific novelty of this middleware. Does it offer any guarantees (e.g., consistency, eventual deletion enforcement, reduced consensus cost)? If not, frame the contribution more as a design integration and prototype than a fundamental system innovation. Security and Trust Assumptions Are Underexplored: The system assumes that the Middleman IPFS deletes keys post-confirmation, but does not specify how this is enforced or audited. Explain how deletion is verified. Consider potential attacks (e.g., replay, key retention, collusion). Add a formal threat model or table of assumptions. Lack of Usability and Developer Workflow Analysis: The paper lacks consideration for developer experience. There's no discussion of CI/CD pipeline compatibility. Branching, merging, or pull request equivalents. Real-time editing conflicts and resolution. Add a section comparing the proposed system with Git-based developer workflows, especially in collaborative scenarios. Overuse of Passive Language and Redundancy: Several sections are highly repetitive, particularly those that describe IPFS and blockchain properties. Condense redundant text. Emphasize what was implemented and tested, and reduce generic blockchain/IPFS descriptions already covered in existing literature. ****** 6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files. If you choose “no”, your identity will remain anonymous but your review may still be made public. Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy. Reviewer #1: No Reviewer #2: Yes: Abdul Razzaq ******** [NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.] While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step. https://doi.org/10.1371/journal.pone.0331131.r001
Revision 1
11 Jul 2025 Author Response Response to Reviewer #1 Comment 1: "Abstract and Conclusion must be revised. Make it concise but solid." Response: We thank the reviewer for this valuable suggestion. We agree that the original versions were too descriptive. We have completely rewritten the Abstract and Conclusion to be more concise and to reflect the empirical findings of our study. The new versions are data-driven and confidently state the achievements of our work. Comment 2: "It is suggested to avoid writing short paragraphs which cause inconvenience in writing flow." Response: We appreciate this stylistic advice. We have carefully reviewed the entire manuscript and have merged short paragraphs, particularly in the Related Works and Introduction sections, to improve the overall narrative flow. Comment 3: "Motivation and Organization of this study must be clearly defined." Response: We thank the reviewer for this important point. We have added a new, explicit paragraph at the end of the Introduction section that clearly outlines the primary motivations for our work and details the organization of the paper, guiding the reader through the manuscript's structure. Comment 4: "Figures must be revised and an interested presentation should be adopted with high-resolution quality. If possible, check and revise figure captions, they are too long." Response: We have taken this feedback to heart. We have revised Figures 1 and 2 to increase clarity and generated a new set of high-resolution charts based on our experimental data (see new Figures 3, 4, and 5 in the revised manuscript). We have also revised all figure captions throughout the manuscript to be more concise and impactful while still accurately describing the content. Comment 5: "The authors should carefully check if all abbreviations are defined at the first place for better readability." Response: We have performed a thorough check of the entire manuscript and have now defined all technical abbreviations (e.g., VCS, IPFS, SSS, IIoT, IoV, NFV) upon their first use to enhance readability. Comment 6 & 7: "Reference literature must be updated and suggested to add following articles... Material and Methods are fine. Better to improve writing for results discussion." Response: We thank the reviewer for these literature suggestions. We have carefully reviewed the recommended articles and have now integrated them into our revised Related Works section to better contextualize our research. Furthermore, the Results and Discussion section has been completely rewritten from the ground up, based on our new empirical data, which we believe substantially improves the quality of the discussion. Response to Reviewer #2 Comment 1: Lack of Empirical Evaluation: "The manuscript fails to provide quantitative performance results. Any benchmark, latency analysis, or transaction cost metrics do not support claims regarding scalability, efficiency, and performance improvement over existing systems. Provide experimental evaluations comparing Blockchain gas fees with/without Middleman IPFS, upload/download time and throughput metrics, and comparisons with traditional centralized systems (e.g., GitHub/GitLab)." Response: We thank Reviewer #2 for this critical and essential feedback. We agree completely that the original manuscript's claims required robust empirical validation. To address this, we have implemented a full prototype of our proposed architecture and conducted a comprehensive performance evaluation on the public Sepolia testnet. The new Results and Discussion section (Section 4) is now rewritten completely to present this data. Specifically: We provide a direct performance comparison against a centralized Git/GitHub baseline in Table 1 and Figure 3, analyzing both push and pull operations. - We present a detailed breakdown of system latency to identify bottlenecks in Figure 4. - We report the consistent on-chain gas costs for repository registration in the System Overhead and Bottleneck Analysis subsection. - We believe this new data fully addresses the reviewer’s concern and substantiates the performance claims of our system with rigorous, quantitative evidence. In accordance with PLOS ONE's data availability policy, all underlying data for our findings are provided in the Supporting Information files. Furthermore, the complete source code for our prototype and middleware has been made publicly available on GitHub and permanently archived with a DOI via Zenodo (DOI: 10.5281/zenodo.15700465). Comment 2: Unclear Novelty Beyond Engineering Integration: "The ‘Middleman IPFS’ is essentially a cache or temporary node. While practical, this seems like an engineering optimization, not a fundamentally new algorithm or protocol. Clarify the scientific novelty of this middleware. Does it offer any guarantees (e.g., consistency, eventual deletion enforcement, reduced consensus cost)? If not, frame the contribution more as a design integration and prototype than a fundamental system innovation." Response: We thank the reviewer for this critical suggestion to clarify the novelty of our contribution. The reviewer correctly noted that a simple cache would be an engineering optimization. In our revised manuscript, we now clarify that the novelty lies not merely in the existence of the middleman, but in the secure, high-performance protocol it enables. We have strengthened this argument in two key ways: 1. Security Protocol Novelty: We have integrated Shamir's Secret Sharing (SSS) as a core component. As detailed in the new Security and Trust Model subsection (Section 4.4), this renders the middleman cryptographically powerless and distributes trust, elevating the design beyond a simple cache to a trust-minimized protocol. 2. Application-Layer Protocol Novelty: We formally define our "Authoritative-First, Optimistic-Fallback" retrieval protocol. We argue in the revised Related Works and Discussion sections that this protocol is a novel contribution to solving the well-known problem of user-perceived latency in dApps, and our empirical data proves its effectiveness. Comment 3: Security and Trust Assumptions Underexplored: "The system assumes that the Middleman IPFS deletes keys post-confirmation, but does not specify how this is enforced or audited. Explain how deletion is verified. Consider potential attacks (e.g., replay, key retention, collusion). Add a formal threat model or table of assumptions." Response: We thank the reviewer for this important point. We have added a new, dedicated Security and Trust Model subsection (Section 4.4) to formally address this. We present a threat model and explain how the integration of SSS directly mitigates threats such as key retention by the middleman. We argue that, since the middleman holds only a single, insufficient key share, the security of the system does not depend on a trusted deletion mechanism. Furthermore, we clarify that the authoritative share is stored immutably on the blockchain, providing a permanent disaster recovery path. Comment 4: Lack of Usability and Developer Workflow Analysis: "The paper lacks consideration for developer experience. There's no discussion of CI/CD pipeline compatibility. Branching, merging, or pull request equivalents. Real-time editing conflicts and resolution. Add a section comparing the proposed system with Git-based developer workflows, especially in collaborative scenarios." Response: This is an excellent point. To address it, we have added a new subsection titled Comparative Analysis with Centralized VCS (Section 4.1.1). This subsection uses our new experimental data (Table 1 and Figure 3) to provide a direct, data-driven comparison of the user-perceived latency of our system's push and pull operations against the equivalent commands in Git. This allows for a concrete discussion of the practical trade-offs for a developer. Comment 5: Overuse of Passive Language and Redundancy. "Several sections are highly repetitive, particularly those that describe IPFS and blockchain properties. Condense redundant text. Emphasize what was implemented and tested, and reduce generic blockchain/IPFS descriptions already covered in existing literature." Response: We thank the reviewer for this stylistic feedback. We have thoroughly revised the entire manuscript to use more active and confident language, particularly in the Abstract, Introduction, and Conclusion. We have also condensed the Related Works section, removing redundant descriptions of general blockchain/IPFS concepts to focus more on literature that directly informs or contrasts with our specific contributions. We are confident that these substantial revisions have addressed all the concerns raised and have resulted in a much-improved manuscript. We once again thank the editor and the reviewers for their time and valuable contributions to our work. Attachments Attachment Submitted filename: response_to_reviewer.pdf https://doi.org/10.1371/journal.pone.0331131.r002
6 Aug 2025 Decision Letter - Yang (Jack) Lu, Editor PONE-D-24-43266R1An Integrated Blockchain and IPFS-based Solution for Secure and Efficient Source Code Repository Hosting using Middleman ApproachPLOS ONE Dear Dr. Ahmed, Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process. Please submit your revised manuscript by Sep 20 2025 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file. Please include the following items when submitting your revised manuscript: A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'. A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'. An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'. If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter. If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols. We look forward to receiving your revised manuscript. Kind regards, Yang (Jack) Lu, PhD Academic Editor PLOS ONE Journal Requirements: If the reviewer comments include a recommendation to cite specific previously published works, please review and evaluate these publications to determine whether they are relevant and should be cited. There is no requirement to cite these works unless the editor has indicated otherwise. Please review your reference list to ensure that it is complete and correct. If you have cited papers that have been retracted, please include the rationale for doing so in the manuscript text, or remove these references and replace them with relevant current references. Any changes to the reference list should be mentioned in the rebuttal letter that accompanies your revised manuscript. If you need to cite a retracted article, indicate the article’s retracted status in the References list and also include a citation and full reference for the retraction notice. [Note: HTML markup is below. Please do not edit.] Reviewers' comments: Reviewer's Responses to Questions Comments to the Author 1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation. Reviewer #3: (No Response) Reviewer #4: All comments have been addressed ******** 2. Is the manuscript technically sound, and do the data support the conclusions? The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented. Reviewer #3: Yes Reviewer #4: Yes ****** 3. Has the statistical analysis been performed appropriately and rigorously? Reviewer #3: Yes Reviewer #4: No ****** 4. Have the authors made all data underlying the findings in their manuscript fully available? The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified. Reviewer #3: Yes Reviewer #4: No ****** 5. Is the manuscript presented in an intelligible fashion and written in standard English? PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here. Reviewer #3: Yes Reviewer #4: Yes ****** 6. Review Comments to the Author Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters) Reviewer #3: 1. Though the paper has a comparison between Git workflows, it is better that the manuscript could add a brief discussion about how the proposed system integrates with existing Ci/CD pipelines. 2.The conclusion mentions that the middleware could be evolved into a Dao-based service. I think it would be better that some details could be added like design considerations or potential challenges. 3. I think some figure captions could be further tightened. Reviewer #4: Strengths: 1.Relevant and timely topic: The problem of centralized control and security in code hosting platforms (e.g., GitHub) is highly relevant given increasing concerns over data ownership and reliability. 2.Technical novelty: The integration of blockchain with IPFS and a middleman node as a broker offers an interesting hybrid approach for balancing performance and decentralization. 3.Prototype development: The authors implement and test their system on Hyperledger Fabric and IPFS, offering a proof-of-concept with basic performance metrics. Weakness: 1. Limitation in empirical analysis: While the proposed architecture is conceptually sound, the lack of empirical evaluation limits the paper’s contribution. The authors should at minimum conduct simulation-based performance tests or benchmarking against centralized platforms (e.g., GitHub, GitLab). Without demonstrating measurable or theoretical speed-up, reliability, or cost-effectiveness, it is difficult to assess the practical value of the proposed system. 2.Performance Evaluation: The evaluation is rather limited and only includes basic metrics such as upload/download latency. To strengthen this section:Compare performance with centralized systems (e.g., GitHub);Include stress tests (e.g., increasing number of users/files);Provide data on blockchain transaction throughput or IPFS lookup success rate. ****** 7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files. If you choose “no”, your identity will remain anonymous but your review may still be made public. Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy. Reviewer #3: Yes: Chengyang Nie Reviewer #4: No ******** [NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.] While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step. https://doi.org/10.1371/journal.pone.0331131.r003
Revision 2
7 Aug 2025 Author Response Response to Reviewer #3 (Dr. Chengyang Nie) We thank Dr. Nie for his positive assessment and excellent suggestions for extending the discussion. Comment 1: "...it is better that the manuscript could add a brief discussion about how the proposed system integrates with existing Ci/CD pipelines." Response: This is an excellent point. We have now added a new paragraph in the 'Developer Workflow and Usability' subsection discussing exactly this. We outline how a command-line interface could wrap our system's core functions to enable integration into automated CI/CD pipelines for verifiable, decentralized builds and deployments. Comment 2: "The conclusion mentions that the middleware could be evolved into a Dao-based service. I think it would be better that some details could be added..." Response: Thank you for this critical observation. Our initial mention was too brief. We have expanded the 'Conclusion' section to include more specific design considerations for a future DAO implementation, such as managing a treasury for IPFS pinning and using token-based voting for governance. Comment 3: "I think some figure captions could be further tightened." Response: We thank the reviewer for this advice. We have reviewed and edited all figure captions throughout the manuscript to make them more concise while retaining their descriptive accuracy. Response to Reviewer #4 We thank Reviewer #4 for their thorough and insightful review. The weaknesses identified by the reviewer regarding the lack of empirical data were perfectly aligned with the feedback we received in the first round. We are pleased to confirm that addressing these points was the primary focus of our first revision (R1), and the current manuscript now contains the comprehensive evaluation the reviewer has called for. Weakness 1: Limitation in empirical analysis: "...the lack of empirical evaluation limits the paper’s contribution. The authors should at minimum conduct simulation-based performance tests or benchmarking against centralized platforms..." Response: We agree wholeheartedly. The current version of the manuscript is now built upon a comprehensive empirical evaluation. As detailed in the 'Results and Discussion' section, we have implemented a full prototype, deployed it to the public Sepolia testnet, and benchmarked its performance directly against a centralized Git/GitHub baseline across a range of file sizes. Weakness 2: Performance Evaluation: "The evaluation is rather limited... Compare performance with centralized systems (e.g., GitHub); Include stress tests... Provide data on blockchain transaction throughput..." Response: We have addressed these points directly in our 'Results and Discussion' section. To guide the reviewer to these specific additions, we have highlighted the key introductory sentences for each piece of evidence in blue text in the 'Revised Manuscript with Track Changes' file: Comparison with GitHub: Our direct, quantitative comparison of 'push' and 'pull' latency against Git is introduced by the highlighted text in the 'Comparative Analysis with Centralized VCS' subsection and presented in Table 1 and Fig 3. Stress Tests: We conducted stress tests by scaling the file size from 1MB to 20MB. Fig 4 and the highlighted texts in the 'System Overhead and Bottleneck Analysis' subsection provide a detailed breakdown of where the system latency is spent under this load. Blockchain Data: The highlighted text in the same subsection reports the consistent 'Gas Used' for on-chain transactions and provides a detailed analysis of the 'Pure Blockchain Latency', which is a more direct measure of the on-chain performance bottleneck than raw TPS for our use case. We are confident that our new, data-driven 'Results and Discussion' section now provides the robust empirical evidence the reviewer correctly identified as a critical requirement. We believe these latest revisions, combined with the major improvements from the first round, have resulted in a much stronger and more complete manuscript. We thank you again for your time and consideration. Sincerely, Sabbir Ahmed (on behalf of all authors) Attachments Attachment Submitted filename: R2_response_to_reviewer.pdf https://doi.org/10.1371/journal.pone.0331131.r004
12 Aug 2025 Decision Letter - Yang (Jack) Lu, Editor An Integrated Blockchain and IPFS-based Solution for Secure and Efficient Source Code Repository Hosting using Middleman Approach PONE-D-24-43266R2 Dear Dr. Ahmed, We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements. Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication. An invoice will be generated when your article is formally accepted. Please note, if your institution has a publishing partnership with PLOS and your article meets the relevant criteria, all or part of your publication costs will be covered. Please make sure your user information is up-to-date by logging into Editorial Manager at Editorial Manager® and clicking the ‘Update My Information' link at the top of the page. For questions related to billing, please contact billing support. If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org. Kind regards, Yang (Jack) Lu, PhD Academic Editor PLOS ONE Additional Editor Comments (optional): Reviewers' comments: Reviewer's Responses to Questions Comments to the Author 1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation. Reviewer #3: All comments have been addressed Reviewer #4: All comments have been addressed ******** 2. Is the manuscript technically sound, and do the data support the conclusions? The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented. Reviewer #3: Yes Reviewer #4: Yes ****** 3. Has the statistical analysis been performed appropriately and rigorously? Reviewer #3: Yes Reviewer #4: Yes ****** 4. Have the authors made all data underlying the findings in their manuscript fully available? The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified. Reviewer #3: Yes Reviewer #4: Yes ****** 5. Is the manuscript presented in an intelligible fashion and written in standard English? PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here. Reviewer #3: Yes Reviewer #4: Yes ****** 6. Review Comments to the Author Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters) Reviewer #3: (No Response) Reviewer #4: Thank you for your prompt response and for addressing the weakness! I have no further questions or additional comments at this time. ****** 7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files. If you choose “no”, your identity will remain anonymous but your review may still be made public. Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy. Reviewer #3: Yes: Chengyang Nie Reviewer #4: No ******** https://doi.org/10.1371/journal.pone.0331131.r005
Formally Accepted
Acceptance Letter - Yang (Jack) Lu, Editor PONE-D-24-43266R2 PLOS ONE Dear Dr. Ahmed, I'm pleased to inform you that your manuscript has been deemed suitable for publication in PLOS ONE. Congratulations! Your manuscript is now being handed over to our production team. At this stage, our production department will prepare your paper for publication. This includes ensuring the following: * All references, tables, and figures are properly cited * All relevant supporting information is included in the manuscript submission, * There are no issues that prevent the paper from being properly typeset You will receive further instructions from the production team, including instructions on how to review your proof when it is ready. Please keep in mind that we are working through a large volume of accepted articles, so please give us a few days to review your paper and let you know the next and final steps. Lastly, if your institution or institutions have a press office, please let them know about your upcoming paper now to help maximize its impact. If they'll be preparing press materials, please inform our press team within the next 48 hours. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org. You will receive an invoice from PLOS for your publication fee after your manuscript has reached the completed accept phase. If you receive an email requesting payment before acceptance or for any other service, this may be a phishing scheme. Learn how to identify phishing emails and protect your accounts at https://explore.plos.org/phishing. If we can help with anything else, please email us at customercare@plos.org. Thank you for submitting your work to PLOS ONE and supporting open access. Kind regards, PLOS ONE Editorial Office Staff on behalf of Dr. Yang (Jack) Lu Academic Editor PLOS ONE https://doi.org/10.1371/journal.pone.0331131.r006

Open letter on the publication of peer review reports

PLOS recognizes the benefits of transparency in the peer review process. Therefore, we enable the publication of all of the content of peer review and author responses alongside final, published articles. Reviewers remain anonymous, unless they choose to reveal their names.

We encourage other journals to join us in this initiative. We hope that our action inspires the community, including researchers, research funders, and research institutions, to recognize the benefits of published peer review reports for all parts of the research system.

Learn more at ASAPbio .