<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article article-type="research-article" dtd-version="2.3" xml:lang="EN" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Blockchain</journal-id>
<journal-title>Frontiers in Blockchain</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Blockchain</abbrev-journal-title>
<issn pub-type="epub">2624-7852</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">1619708</article-id>
<article-id pub-id-type="doi">10.3389/fbloc.2025.1619708</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Blockchain</subject>
<subj-group>
<subject>Original Research</subject>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>Information model operation and maintenance data network security construction based on partitioned blockchain</article-title>
<alt-title alt-title-type="left-running-head">Chen et al.</alt-title>
<alt-title alt-title-type="right-running-head">
<ext-link ext-link-type="uri" xlink:href="https://doi.org/10.3389/fbloc.2025.1619708">10.3389/fbloc.2025.1619708</ext-link>
</alt-title>
</title-group>
<contrib-group>
<contrib contrib-type="author" corresp="yes">
<name>
<surname>Chen</surname>
<given-names>Fuyang</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<xref ref-type="corresp" rid="c001">&#x2a;</xref>
<uri xlink:href="https://loop.frontiersin.org/people/3049220/overview"/>
<role content-type="https://credit.niso.org/contributor-roles/writing-original-draft/"/>
<role content-type="https://credit.niso.org/contributor-roles/formal-analysis/"/>
<role content-type="https://credit.niso.org/contributor-roles/project-administration/"/>
<role content-type="https://credit.niso.org/contributor-roles/conceptualization/"/>
<role content-type="https://credit.niso.org/contributor-roles/methodology/"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Yao</surname>
<given-names>Jie</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<role content-type="https://credit.niso.org/contributor-roles/funding-acquisition/"/>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
<role content-type="https://credit.niso.org/contributor-roles/resources/"/>
<role content-type="https://credit.niso.org/contributor-roles/data-curation/"/>
<role content-type="https://credit.niso.org/contributor-roles/investigation/"/>
<role content-type="https://credit.niso.org/contributor-roles/visualization/"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Xu</surname>
<given-names>Zihan</given-names>
</name>
<xref ref-type="aff" rid="aff2">
<sup>2</sup>
</xref>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
<role content-type="https://credit.niso.org/contributor-roles/validation/"/>
</contrib>
</contrib-group>
<aff id="aff1">
<sup>1</sup>
<institution>School of Design and Art, Yancheng Institute of Technology</institution>, <addr-line>Yancheng</addr-line>, <addr-line>Jiangsu</addr-line>, <country>China</country>
</aff>
<aff id="aff2">
<sup>2</sup>
<institution>Artificial Intelligence Program, Suzhou Institute of Technology</institution>, <addr-line>Suzhou</addr-line>, <addr-line>Jiangsu</addr-line>, <country>China</country>
</aff>
<author-notes>
<fn fn-type="edited-by">
<p>
<bold>Edited by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/748038/overview">Avishek Nag</ext-link>, University College Dublin, Ireland</p>
</fn>
<fn fn-type="edited-by">
<p>
<bold>Reviewed by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/1374371/overview">Grit Ngowtanasuwan</ext-link>, Mahasarakham University, Thailand</p>
<p>
<ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/2913074/overview">Ahmad Ali Eyadat</ext-link>, Irbid National University, Jordan</p>
<p>
<ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/2979778/overview">Lei Yang</ext-link>, Shenyang University of Technology, China</p>
</fn>
<corresp id="c001">&#x2a;Correspondence: Fuyang Chen, <email>fyangchen@126.com</email>
</corresp>
</author-notes>
<pub-date pub-type="epub">
<day>01</day>
<month>09</month>
<year>2025</year>
</pub-date>
<pub-date pub-type="collection">
<year>2025</year>
</pub-date>
<volume>8</volume>
<elocation-id>1619708</elocation-id>
<history>
<date date-type="received">
<day>28</day>
<month>04</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>15</day>
<month>08</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#xa9; 2025 Chen, Yao and Xu.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Chen, Yao and Xu</copyright-holder>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/">
<p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</p>
</license>
</permissions>
<abstract>
<p>In response to the problems of single point of failure risk and poor scalability in current network security construction, this article applies an information model operation and maintenance data network security construction method based on partitioned blockchain. The effectiveness and advantages of the partitioned blockchain method used is evaluated in a comparison with traditional models. The research results show that the overall recall rate of the adopted method for daily network attacks is very high. Compared with traditional models, the CPU and memory usage are lower, ensuring the scalability and efficiency of blockchain while achieving a more reliable information operation and maintenance.</p>
</abstract>
<kwd-group>
<kwd>network security</kwd>
<kwd>construction</kwd>
<kwd>partitioned blockchain</kwd>
<kwd>information model operation</kwd>
<kwd>single point of failure</kwd>
</kwd-group>
<counts>
<page-count count="18"/>
</counts>
<custom-meta-wrap>
<custom-meta>
<meta-name>section-at-acceptance</meta-name>
<meta-value>Blockchain in Industry</meta-value>
</custom-meta>
</custom-meta-wrap>
</article-meta>
</front>
<body>
<sec id="s1">
<title>1 Introduction</title>
<p>With the rapid development of the Internet and the deepening of digital transformation, network security issues have become increasingly prominent. In the field of information operation and maintenance (<xref ref-type="bibr" rid="B33">Zhang, 2021</xref>), single point of failure risk (<xref ref-type="bibr" rid="B28">Yang et al., 2022</xref>) and insufficient scalability have become the main obstacles restricting system security (<xref ref-type="bibr" rid="B27">Xiaoyi et al., 2020</xref>) and stability. The current methods for building network security (<xref ref-type="bibr" rid="B7">Ding et al., 2021</xref>), such as centralized firewalls and intrusion detection systems (<xref ref-type="bibr" rid="B21">Shijie et al., 2020</xref>), although effective to some extent, their vulnerability gradually becomes apparent when facing complex and ever-changing network environments. For example, if a critical node in a centralized system related to a construction project is attacked, the entire system may face paralysis. The field of information operation and maintenance requires the intervention of new technologies to enhance the security and reliability of information model operation and maintenance and ensure the integrity and availability of data.</p>
<p>Partitioned blockchain is a technology that improves system concurrency and fault tolerance by dividing data into multiple relatively independent parts (<xref ref-type="bibr" rid="B13">Hu et al., 2022</xref>). In information model operation and maintenance, this technology can effectively reduce the risk of single point of failure and ensure the integrity and security of data. Through decentralization (<xref ref-type="bibr" rid="B3">Chaoyi et al., 2024</xref>), partitioned blockchain (<xref ref-type="bibr" rid="B26">Xiaoqing et al., 2021</xref>) can achieve precise control over data access and enhance protection against potential threats. The network security framework constructed based on this technology can improve the scalability and reliability of the system, providing solid support for information operation and maintenance.</p>
<p>Partitioned blockchain is more capable of solving single point of failure and scalability challenges than existing methods because of the following reasons.</p>
<p>Firstly, partitioned blockchain divides the network into multiple parallel processing sub networks through sharding technology, with each sub network running independently to improve performance, thus having advantages in solving single point of failure and scalability challenges.</p>
<p>Secondly, Sharding technology divides the blockchain network into multiple sub networks, with each sub network independently processing transactions, significantly improving overall throughput. Sharding technology reduces the pressure on the main chain by allowing parallel processing of data.</p>
<p>Thirdly, Sharding technology itself disperses the risk of single point of failure. Each sub network operates independently, and even if some nodes or sub networks fail, other sub networks can still function normally. In addition, distributed storage and fault-tolerant mechanisms further ensure the robustness of the system.</p>
<p>The purpose of this study is to construct an information model for operation and maintenance data network security based on partitioned blockchain. By designing a framework that combines the decentralization and partitioning features of blockchain, a network security model is gradually built, and the experimental verification is conducted. Firstly, the security requirements of existing information models in the operation and maintenance process are thoroughly analyzed to identify potential vulnerabilities; secondly, a security architecture based on partitioned blockchain is designed to ensure the integrity and confidentiality of data during transmission and storage, and prevent data leakage and tampering; finally, the performance of the model in different environments is evaluated through simulation experiments, and its feasibility and effectiveness in practical applications are analyzed.</p>
<p>The research objectives are to significantly improve the security of information model operation and maintenance, to reduce the risk of single point of failure; to enhance the overall scalability of the system and to provide theoretical support and practical guidance for future network security construction.</p>
</sec>
<sec id="s2">
<title>2 Related work</title>
<p>Many researchers have proposed different solutions to address the issue of network security construction. For example, scholars such as <xref ref-type="bibr" rid="B20">Shao (2024)</xref> and <xref ref-type="bibr" rid="B32">Yu Mingzhou (2024)</xref> reduced the risk of single point of failure by applying multiple backup mechanisms, while scholars such as <xref ref-type="bibr" rid="B16">Muhtadi et al. (2021)</xref> and <xref ref-type="bibr" rid="B23">Wenwu et al. (2022)</xref> focused on improving the scalability of the system and adopting a distributed architecture to achieve efficient resource utilization. In addition, with the development of artificial intelligence technology, scholars such as <xref ref-type="bibr" rid="B18">Saheed et al. (2022)</xref> and <xref ref-type="bibr" rid="B12">Hidayat et al. (2023)</xref> adopted machine learning-based intrusion detection systems to improve response speed and accuracy to potential threats. These methods often face high complexity, high cost, and poor data privacy protection in practical applications. Multiple backups may lead to data redundancy and storage overhead, while machine learning models require a large amount of labeled data for training (<xref ref-type="bibr" rid="B15">Liu et al., 2021</xref>), which is not always feasible in real-world environments. Therefore, existing research has not yet solved some problems and urgently needs to find more effective technical solutions.</p>
<p>Through a review of relevant literature, it can be found that scholars such as <xref ref-type="bibr" rid="B9">Gao (2023)</xref> and <xref ref-type="bibr" rid="B2">Cai et al. (2021)</xref> attempted to use blockchain technology to enhance network security. The decentralized nature of blockchain provides high security in data storage and transmission processes. Scholars such as <xref ref-type="bibr" rid="B31">Yao (2023)</xref> and <xref ref-type="bibr" rid="B25">Wu et al. (2024)</xref> proposed the use of decentralization to prevent data tampering and ensure data immutability and transparency. In addition, scholars such as <xref ref-type="bibr" rid="B17">Peng et al. (2021)</xref> and <xref ref-type="bibr" rid="B14">Lang (2021)</xref> achieved automated execution of security protocols through smart contracts, further reducing the risk of human intervention. However, there is still insufficient exploration of the application of partitioned blockchain in existing research. Partitioned blockchain can play an important role in improving the system&#x2019;s concurrent processing capability and fault tolerance by dividing data into multiple relatively independent parts, while reducing the risk of single point failures. This article adopts a partitioned blockchain and combines the data dynamic update mechanism of information model operation and maintenance to systematically solve the single point of failure and scalability problems in information model operation and maintenance, providing an innovative solution for network security construction.</p>
<p>Compared with the existing literature, the new features of blockchain framework are mainly reflected in the following aspects.</p>
<sec id="s2-1">
<title>2.1 Distributed storage and consensus mechanism</title>
<p>Blockchain adopts distributed storage technology, where data is stored in multiple nodes to avoid the risk of single point of failure. Consensus mechanisms, such as proof of work and proof of stake, ensure data consistency while reducing power concentration issues in centralized organizations.</p>
</sec>
<sec id="s2-2">
<title>2.2 Smart contracts and decentralized applications</title>
<p>Smart contracts are automatically executed through script code, supporting new application scenarios. Decentralized applications (DAPP) run in a distributed network, where data storage and operations are jointly maintained by nodes, enhancing security and reliability.</p>
</sec>
<sec id="s2-3">
<title>2.3 Non tampering and traceability</title>
<p>Blockchain ensures data immutability through hash algorithms and chain structures, while adding timestamps to achieve data traceability. The verification mechanism of adjacent blocks further strengthens the authenticity and security of data on the chain.</p>
</sec>
<sec id="s2-4">
<title>2.4 Cross chain and privacy protection</title>
<p>Support cross chain protocols to achieve value transfer and data sharing between different blockchains, while ensuring transaction security and privacy protection through encryption algorithms such as public and private keys.</p>
<p>Whether the partitioned blockchain framework is based on attribute access control depends on the specific framework design. For example, Hyperledger Fabric supports attribute-based access control (ABAC), which implements permission control through login certificates (ECert) containing attribute names and values.</p>
</sec>
<sec id="s2-5">
<title>2.5 Integration of attribute access control and blockchain</title>
<p>Blockchain technology can achieve more refined permission management through smart contracts and attribute verification mechanisms. For example, the ADAC framework manages device attributes and control policies through subject contracts, object contracts, and policy contracts to achieve distributed trusted access control.</p>
</sec>
<sec id="s2-6">
<title>2.6 Differences in framework design</title>
<p>Some blockchain frameworks, such as Ethereum, use role-based access control (RBAC) to manage user access through role permissions. However, frameworks such as Hyperledger Fabric tend to lean towards attribute driven access control models.</p>
</sec>
</sec>
<sec id="s3">
<title>3 Partition data management</title>
<p>Partition data management, as an important component of system architecture, aims to alleviate the risk of Single Point of Failure (SPOF) and enhance the system&#x2019;s fault tolerance, security, and scalability through data partitioning and isolation. This article adopts a partition-based storage and management strategy (<xref ref-type="bibr" rid="B22">Shiyu and Zhang, 2021</xref>), which divides data into multiple autonomous subsets to ensure that the failure of a single partition does not affect the entire system. This section covers multiple dimensions such as partition strategy, data mapping, data consistency, and security assurance, and provides a detailed introduction to the application of relevant technical methods and their practical effects in network security.</p>
<p>A multidimensional data partitioning strategy is designed based on business characteristics and security requirements. The core goal of data partitioning is to divide operational data into several independent partitions based on their sensitivity, access frequency, correlation between data, and different business scenarios. This article applies a hybrid strategy based on Hierarchical Clustering Algorithm (<xref ref-type="bibr" rid="B36">Zheng et al., 2022</xref>) and dynamic weighted data segmentation model (<xref ref-type="bibr" rid="B34">Zhang and Chen, 2021</xref>), ensuring that the coupling and distribution characteristics of data can be fully considered during data partitioning. As shown in <xref ref-type="fig" rid="F1">Figure 1</xref>, by defining a distance metric function for data, the operation and maintenance data is hierarchically clustered and segmented. Each object is treated as a class, and the minimum distance between each pair is calculated. The two classes with the smallest distance are merged into a new class, and the distance between the new class and all classes is recalculated. The first two processes are repeated until all classes are finally merged into one class.</p>
<fig id="F1" position="float">
<label>FIGURE 1</label>
<caption>
<p>Hierarchical clustering algorithm.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g001.tif">
<alt-text content-type="machine-generated">Dendrogram and Venn diagram comparison. The dendrogram on the left clusters items A through I based on similarity, with A and G forming distinct branches. The Venn diagram on the right groups similar items together with overlapping circles, showing relationships among A to I.</alt-text>
</graphic>
</fig>
<p>The distance measurement function adopts Euclidean Distance or Cosine Similarity, and the specific formulas are as follows:</p>
<p>The formula for calculating the Euclidean distance between two data objects <inline-formula id="inf1">
<mml:math id="m1">
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>n</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf2">
<mml:math id="m2">
<mml:mrow>
<mml:mi>y</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mi>n</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is indicated by the <xref ref-type="disp-formula" rid="e1">Equation 1</xref>:<disp-formula id="e1">
<mml:math id="m3">
<mml:mrow>
<mml:mi>d</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:msqrt>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:munderover>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:msup>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x2212;</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:msqrt>
</mml:mrow>
</mml:math>
<label>(1)</label>
</disp-formula>
</p>
<p>If cosine similarity is used, its formula is indicated by the <xref ref-type="disp-formula" rid="e2">Equation 2</xref>:<disp-formula id="e2">
<mml:math id="m4">
<mml:mrow>
<mml:mtext>Sim</mml:mtext>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>&#xb7;</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2225;</mml:mo>
<mml:mi>x</mml:mi>
<mml:mo>&#x2225;</mml:mo>
<mml:mo>&#x2225;</mml:mo>
<mml:mi>y</mml:mi>
<mml:mo>&#x2225;</mml:mo>
</mml:mrow>
</mml:mfrac>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:msubsup>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:msubsup>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mrow>
<mml:msqrt>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:msubsup>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:msubsup>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
<mml:mn>2</mml:mn>
</mml:msubsup>
</mml:mrow>
</mml:msqrt>
<mml:msqrt>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:msubsup>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:msubsup>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:msubsup>
<mml:mi>y</mml:mi>
<mml:mi>i</mml:mi>
<mml:mn>2</mml:mn>
</mml:msubsup>
</mml:mrow>
</mml:msqrt>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
<label>(2)</label>
</disp-formula>
</p>
<p>Data partitioning is optimized by minimizing the distance within partitions and maximizing the distance between partitions. The system objective is to minimize the total distance <inline-formula id="inf3">
<mml:math id="m5">
<mml:mrow>
<mml:mi>W</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> within the partition, and its objective function is indicated by the <xref ref-type="disp-formula" rid="e3">Equation 3</xref>:<disp-formula id="e3">
<mml:math id="m6">
<mml:mrow>
<mml:mi>W</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>K</mml:mi>
</mml:munderover>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>k</mml:mi>
</mml:msub>
</mml:mrow>
</mml:munder>
</mml:mstyle>
<mml:mrow>
<mml:mtext>&#x200a;</mml:mtext>
<mml:mi>d</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(3)</label>
</disp-formula>
<inline-formula id="inf4">
<mml:math id="m7">
<mml:mrow>
<mml:mi>K</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the total number of partitions; <inline-formula id="inf5">
<mml:math id="m8">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>k</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is the dataset in the <inline-formula id="inf6">
<mml:math id="m9">
<mml:mrow>
<mml:mi>k</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>-th partition; <inline-formula id="inf7">
<mml:math id="m10">
<mml:mrow>
<mml:mi>d</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is the distance between any two data points <inline-formula id="inf8">
<mml:math id="m11">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf9">
<mml:math id="m12">
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
<p>This model uses a Multi-Criteria Optimization (MCO) mechanism to select the optimal partitioning scheme, ensuring efficient system load balancing and data distribution. To further optimize resource scheduling and access control after data partitioning (<xref ref-type="bibr" rid="B6">Das et al., 2020</xref>), this article adopts Sharding technology (<xref ref-type="bibr" rid="B11">Hellings and Sadoghi, 2021</xref>). In the Sharding architecture, the system divides data into different Shards based on business requirements, each with independent storage and computing resources. Through Sharding, it ensures that each partition can independently scale and handle its related transaction load in high concurrency scenarios, greatly improving the scalability of the system.</p>
<p>To ensure the efficiency of distributed storage and retrieval of partitioned data, this study applies Distributed Hash Table (DHT) as the core data storage and mapping mechanism. The hash function of DHT (<xref ref-type="bibr" rid="B30">Yanzhe et al., 2021</xref>) maps data blocks to unique storage nodes. Through this decentralized mapping method, the storage location of data does not depend on a single node, thereby avoiding data loss caused by single point failures. To improve the efficiency of data retrieval, the storage and query time complexity of DHT is controlled at <inline-formula id="inf10">
<mml:math id="m13">
<mml:mrow>
<mml:mi>O</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>log</mml:mi>
<mml:mo>&#x2061;</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> (N is the number of nodes), which can effectively reduce retrieval latency in large-scale distributed networks.</p>
<p>In the data mapping process of a DHT, the hash function <inline-formula id="inf11">
<mml:math id="m14">
<mml:mrow>
<mml:mi mathvariant="normal">h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> maps each data object <inline-formula id="inf12">
<mml:math id="m15">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to a node <inline-formula id="inf13">
<mml:math id="m16">
<mml:mrow>
<mml:mi mathvariant="normal">N</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in the storage node set, and the mapping formula is as follows indicated by the <xref ref-type="disp-formula" rid="e4">Equation 4</xref>:<disp-formula id="e4">
<mml:math id="m17">
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>x</mml:mi>
<mml:mo>&#x2061;</mml:mo>
<mml:mi>mod</mml:mi>
<mml:mo>&#x2061;</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:math>
<label>(4)</label>
</disp-formula>
</p>
<p>To ensure load balancing and even distribution of data, the hash function <inline-formula id="inf14">
<mml:math id="m18">
<mml:mrow>
<mml:mi mathvariant="normal">h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> selects a consistent hash algorithm with good distribution characteristics as indicated by the <xref ref-type="disp-formula" rid="e5">Equation 5</xref>. Assuming <inline-formula id="inf15">
<mml:math id="m19">
<mml:mrow>
<mml:mi mathvariant="normal">m</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the total number of nodes, the hash function <inline-formula id="inf16">
<mml:math id="m20">
<mml:mrow>
<mml:mi mathvariant="normal">h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> maps the data <inline-formula id="inf17">
<mml:math id="m21">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to the hash space of <inline-formula id="inf18">
<mml:math id="m22">
<mml:mrow>
<mml:mfenced open="[" close="]" separators="|">
<mml:mrow>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:msup>
<mml:mn>2</mml:mn>
<mml:mi>m</mml:mi>
</mml:msup>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
</inline-formula>:<disp-formula id="e5">
<mml:math id="m23">
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mtext>SHA</mml:mtext>
<mml:mo>&#x2010;</mml:mo>
<mml:mn>256</mml:mn>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mi>mod</mml:mi>
<mml:mo>&#x2061;</mml:mo>
<mml:msup>
<mml:mn>2</mml:mn>
<mml:mi>m</mml:mi>
</mml:msup>
</mml:mrow>
</mml:math>
<label>(5)</label>
</disp-formula>
</p>
<p>A replica management strategy is employed to address the reliability and consistency issues of data across different partitions. For high-sensitivity data and high-frequency access data, the system maintains synchronous replicas among multiple nodes and adopts a Master-Slave replication mechanism (<xref ref-type="bibr" rid="B29">YANG Jun, 2022</xref>) to ensure that the master node can update the slave node replicas in real-time every time data is written. As shown in <xref ref-type="fig" rid="F2">Figure 2</xref>, a master-slave replication mechanism is used for data replica storage, where each master node <inline-formula id="inf19">
<mml:math id="m24">
<mml:mrow>
<mml:mi>P</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> maintains a replica set of <inline-formula id="inf20">
<mml:math id="m25">
<mml:mrow>
<mml:mi>R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> slave nodes <inline-formula id="inf21">
<mml:math id="m26">
<mml:mrow>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mi>R</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
<fig id="F2" position="float">
<label>FIGURE 2</label>
<caption>
<p>Basic process of master-slave replication.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g002.tif">
<alt-text content-type="machine-generated">Diagram illustrating a data replication process. A primary server (P) updates a binary log. Data is read by an I/O process and written to a relay log. This relay log is read by an SQL process for replay on secondary servers (S1, S2, S3, S4). Arrows indicate the flow of data between components.</alt-text>
</graphic>
</fig>
<p>The write operation first updates the master node, and then propagates to the slave nodes through the following formula as indicated by the <xref ref-type="disp-formula" rid="e6">Equation 6</xref>:<disp-formula id="e6">
<mml:math id="m27">
<mml:mrow>
<mml:msub>
<mml:mi>S</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>P</mml:mi>
<mml:mtext>for</mml:mtext>
<mml:mi>i</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mrow>
<mml:mfenced open="[" close="]" separators="|">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>,</mml:mo>
<mml:mi>R</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(6)</label>
</disp-formula>
</p>
<p>For low-frequency access data, a decentralized redundant storage strategy is adopted to store asynchronous replicas at different regional nodes. This not only improves data persistence, but also reduces storage load without affecting overall performance.</p>
<p>In a multi-partition system, data consistency and reliability are crucial. Therefore, this article chooses the Practical Byzantine Fault Tolerance (PBFT) algorithm (<xref ref-type="bibr" rid="B1">Bin and Zhang, 2024</xref>) to ensure that consensus can be reached on most nodes during data updates.</p>
<p>As shown in <xref ref-type="fig" rid="F3">Figure 3</xref>, the consensus reached by PBFT is based on a core three-stage communication protocol: pre-preparation stage, preparation stage, and commit stage.</p>
<fig id="F3" position="float">
<label>FIGURE 3</label>
<caption>
<p>Practical Byzantine fault tolerant algorithm.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g003.tif">
<alt-text content-type="machine-generated">Flowchart representation of a client-server interaction with a master node and three nodes labeled Node1, Node2, and Node3. The process spans five stages: Request, Pre-Prepare, Prepare, Commit, and Reply. Node3 is marked with an &#x22;X,&#x22; indicating an issue or failure at that point. Arrows denote communication pathways across different stages.</alt-text>
</graphic>
</fig>
<p>Pre-preparation stage: in this stage, the master node is responsible for broadcasting a message to all participating child nodes. According to the rules, an honest master node does not send two messages with the same sequence number but different content. Therefore, if a child node receives two messages with the same node number but carrying different content, they reject these requests to prevent potential data inconsistencies.</p>
<p>Preparation stage: after the preparation stage is completed, each child node sends a preparation message to all other child nodes, indicating that it has accepted the message from the preparation stage and is ready to move on to the next stage. In this process, if a sub node receives preparation messages from at least 2f&#x2b;1 different nodes (f is the maximum number of tolerable faulty nodes), it can be considered that the preparation stage has been successfully completed, indicating that most nodes have agreed to the content of the preparation stage.</p>
<p>Commit stage: like the preparation stage, after receiving enough preparation messages, the child nodes begin sending commit messages. Once a node collects 2f&#x2b;1 submission messages from different nodes (including the one sent by itself), it can be determined that most nodes have confirmed and are ready to perform the operation. This node can safely execute client requests and update its status or database records.</p>
<p>The state change function calculated for each node <inline-formula id="inf22">
<mml:math id="m28">
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in the <inline-formula id="inf23">
<mml:math id="m29">
<mml:mrow>
<mml:mi mathvariant="bold-italic">v</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>-th vote in each stage is indicated by the <xref ref-type="disp-formula" rid="e7">Equation 7</xref>:<disp-formula id="e7">
<mml:math id="m30">
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:munderover>
</mml:mstyle>
<mml:mtext>&#x200a;</mml:mtext>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>&#xb7;</mml:mo>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
<label>(7)</label>
</disp-formula>
<inline-formula id="inf24">
<mml:math id="m31">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> represents the voting value of the <inline-formula id="inf25">
<mml:math id="m32">
<mml:mrow>
<mml:mi mathvariant="normal">j</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>-th node, and <inline-formula id="inf26">
<mml:math id="m33">
<mml:mrow>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is the weight of the corresponding node. The prerequisite for achieving consensus in the entire network is <inline-formula id="inf27">
<mml:math id="m34">
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mo>&#x2264;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mn>3</mml:mn>
</mml:mfrac>
</mml:mrow>
</mml:math>
</inline-formula> faulty nodes (that is, Byzantine nodes). Among them, <inline-formula id="inf28">
<mml:math id="m35">
<mml:mrow>
<mml:mi>f</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the number of faulty nodes, and <inline-formula id="inf29">
<mml:math id="m36">
<mml:mrow>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the total number of nodes.</p>
<p>The overall time complexity of PBFT is indicated by the <xref ref-type="disp-formula" rid="e8">Equation 8</xref>:<disp-formula id="e8">
<mml:math id="m37">
<mml:mrow>
<mml:mi>T</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>O</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(8)</label>
</disp-formula>
</p>
<p>This is mainly because in the three stages of communication at the core, the communication volume between each node and the other nodes increases at the square level.</p>
<p>PBFT uses a voting mechanism and a multi-round communication protocol to prevent data tampering and forgery even if malicious nodes exist in the system. As shown in <xref ref-type="fig" rid="F4">Figure 4</xref>, this article combines the Merkle tree (<xref ref-type="bibr" rid="B35">Zheng and Wang, 2022</xref>) structure to generate hash values from the data changes in each partition and organize them into a tree structure. This not only verifies the consistency of the data, but also effectively reduces the communication overhead of PBFT algorithm and improves its feasibility in large-scale systems.</p>
<fig id="F4" position="float">
<label>FIGURE 4</label>
<caption>
<p>Merkle tree structure model.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g004.tif">
<alt-text content-type="machine-generated">Diagram of a blockchain structure showing block headers and block body. The block headers include version number, block height, timestamping, nonce, target hash, parent blocks, and Merkle root. The block body contains a trade set represented by a Merkle tree with trades leading to hashes, culminating in Hash1234. A previous area connects to the block headers from the left, while a next area connects from the right.</alt-text>
</graphic>
</fig>
<p>There are significant differences between mainstream blockchain security solutions and non-blockchain methods in terms of security, decentralization, data integrity, and efficiency. Here is a specific comparison.</p>
<sec id="s3-1">
<title>3.1 Safety</title>
<p>Blockchain achieves data immutability through decentralized structures and cryptographic safeguards such as public/private key encryption and hash functions, while traditional systems rely on a single central authority to manage data and are vulnerable to attacks.</p>
</sec>
<sec id="s3-2">
<title>3.2 Data integrity</title>
<p>Blockchain ensures transaction consistency through consensus mechanisms such as PoW/PoS, and any tampering requires more than 51% computing power, far beyond the feasibility of reality; Traditional systems may have inconsistent data due to a single point of failure.</p>
</sec>
<sec id="s3-3">
<title>3.3 Privacy protection</title>
<p>Blockchain uses technologies such as zero knowledge proofs (ZK SNARKs) to verify privacy transactions, while traditional methods (such as encrypted transmission) only protect the transmission process and cannot verify the authenticity of data.</p>
</sec>
<sec id="s3-4">
<title>3.4 Efficiency and cost</title>
<p>Smart contracts on blockchain can achieve automated execution and reduce human intervention; Traditional methods rely on manual review, which is inefficient and prone to errors.</p>
</sec>
<sec id="s3-5">
<title>3.5 Anti-attack capability</title>
<p>Blockchain significantly enhances its ability to resist quantum computing attacks through distributed storage and fault-tolerant mechanisms, such as PoW&#x2019;s power competition; Traditional methods, such as single key management, are easily cracked.</p>
<p>The improvement of partitioning strategy compared to traditional sharding or PBFT mechanism is mainly reflected in the following aspects.</p>
<p>There are significant differences in data structure, consensus mechanism, and performance, and the following are the main improvement points.</p>
</sec>
<sec id="s3-6">
<title>3.6 Data structure</title>
<p>Traditional blockchain stores data in blocks, with each block containing multiple transaction records, forming a chain structure through timestamps and encrypted links. The partition strategy is directly based on a single transaction, forming a network through reference relationships, and each node needs to verify other transactions before initiating new transactions.</p>
</sec>
<sec id="s3-7">
<title>3.7 Consensus mechanism</title>
<p>Traditional blockchain adopts the longest chain consensus mechanism, where all nodes synchronously verify the legitimacy of new blocks. The partition strategy uses multi chain mutual authentication consensus, where each node needs to verify other transactions before initiating new transactions and distributes the verification responsibility to each user in the network.</p>
</sec>
<sec id="s3-8">
<title>3.8 Performance</title>
<p>The partition strategy supports asynchronous concurrent write transactions, allowing for slight differences in node data and ultimately synchronization. Traditional blockchain requires synchronization of the entire block data, resulting in lower processing efficiency. Partition strategy improves processing speed through multi-core and multi-threaded mode, suitable for high-frequency trading scenarios.</p>
</sec>
<sec id="s3-9">
<title>3.9 Safety</title>
<p>The partition strategy enhances security through a distributed verification mechanism, where each node participates in transaction verification and reduces the risk of single point of failure. Traditional blockchain relies on centralized miners to maintain the network, which leads to trust dependency issues.</p>
</sec>
</sec>
<sec id="s4">
<title>4 Execution of smart contracts</title>
<p>In the information model operation and data network security construction of partitioned blockchain, smart contract execution is an important mechanism for achieving network security automation. Through smart contracts, automated network security policy deployment, dynamic adjustment, and event-based response can be achieved.</p>
<p>The core of smart contracts is that the code logic is enforced on the blockchain to ensure that each operation follows pre-set security rules. To build a network security system for operation and maintenance data, the smart contract in this article is divided into three main modules:</p>
<p>Access control module: it is responsible for permission management and user authentication, ensuring that only authorized users can access and operate specific data.</p>
<p>Data storage and verification module: it is responsible for the storage and verification of data in blockchain and distributed storage systems, ensuring data consistency and security.</p>
<p>Security policy execution module: it is responsible for automating the execution of security policies and dynamically adjusting them based on real-time monitoring data.</p>
<p>As shown in <xref ref-type="fig" rid="F5">Figure 5</xref>, the encryption algorithm is automatically called to encrypt the data before transmission. In this article, the symmetric encryption algorithm AES-256 (<xref ref-type="bibr" rid="B24">Wu and Rong, 2023</xref>) is used to encrypt the data and generate ciphertext <inline-formula id="inf30">
<mml:math id="m38">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>E</mml:mi>
<mml:mi>K</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>D</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf31">
<mml:math id="m39">
<mml:mrow>
<mml:mi>K</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is a dynamically generated encryption key. The key is distributed to authorized users through asymmetric encryption algorithms, and the smart contract automatically manages and distributes the key to ensure that only authorized users can decrypt and access the data.</p>
<fig id="F5" position="float">
<label>FIGURE 5</label>
<caption>
<p>AES-256 encryption model.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g005.tif">
<alt-text content-type="machine-generated">Diagram illustrating AES encryption. It starts with plain text, which is encrypted with an AES key to produce cipher text. The same AES key is used for decryption to recover the original plain text.</alt-text>
</graphic>
</fig>
<p>Integrity checks are performed on transmitted data through hash functions to ensure that the data has not been tampered with during transmission. Whenever data is transmitted, the contract automatically calculates the hash value <inline-formula id="inf32">
<mml:math id="m40">
<mml:mrow>
<mml:mi>H</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>D</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> of the data and compares it with the receiver as indicated by the <xref ref-type="disp-formula" rid="e9">Equation 9</xref>. If the hash value calculated by the receiver is consistent with the hash value before transmission, the integrity of the data is verified to ensure that the data has not been tampered with.<disp-formula id="e9">
<mml:math id="m41">
<mml:mrow>
<mml:mi>H</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>D</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>S</mml:mi>
<mml:mi>H</mml:mi>
<mml:mi>A</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>256</mml:mn>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>D</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(9)</label>
</disp-formula>
</p>
<p>When the hash value of the data matches, the data transmission is automatically approved; if there is no match, the contract rejects transmission and issues an alert.</p>
<p>Smart contracts are deployed on various blockchain nodes, and the distributed nature of blockchain is utilized to ensure that even if some nodes fail or engage in malicious behavior, they can still operate normally on the remaining nodes, maintaining the overall security of the system. In partitioned blockchain, data transmission involves multiple nodes. To ensure that data is not tampered with or intercepted during transmission, a series of encryption and verification operations are automatically performed. Multiple network security control operations can be automatically executed through preset security policies.</p>
<p>In <xref ref-type="fig" rid="F6">Figure 6</xref>, when the system detects intrusion behavior, the contract can respond immediately. For example, when a node issues an abnormal request or engages in unauthorized data modification behavior, the smart contract automatically triggers the security policy (<xref ref-type="bibr" rid="B8">G et al., 2020</xref>), isolates the node, and notifies the administrator for further processing.</p>
<fig id="F6" position="float">
<label>FIGURE 6</label>
<caption>
<p>Smart contract intrusion detection system.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g006.tif">
<alt-text content-type="machine-generated">Diagram showing a security system for smart contracts. Normal transactions proceed to the IDS and enter the blockchain. Malicious transactions are identified as violations, reverting changes and raising alarms. False positives are reviewed by administrators managing transactions.</alt-text>
</graphic>
</fig>
<p>The intrusion detection response mechanism can be described as indicated by the <xref ref-type="disp-formula" rid="e10">Equation 10</xref>:<disp-formula id="e10">
<mml:math id="m42">
<mml:mrow>
<mml:mi>R</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="{" close="" separators="|">
<mml:mrow>
<mml:mtable columnalign="center">
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:mtext>Isolate&#x2009;Node&#xa0;if</mml:mtext>
<mml:mi>I</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:mtext>Allow&#x2009;Access&#xa0;if</mml:mtext>
<mml:mi>I</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(10)</label>
</disp-formula>
<inline-formula id="inf33">
<mml:math id="m43">
<mml:mrow>
<mml:mi>R</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is the response operation; <inline-formula id="inf34">
<mml:math id="m44">
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is the intrusion detection result; 1 represents intrusion; 0 represents normal.</p>
<p>To ensure that network security policies can be dynamically adjusted, smart contracts support version management and compatibility checks. When new network security policies need to be deployed, the system can achieve automated upgrades by updating smart contracts. Smart contracts use the version control mechanism of blockchain to automatically detect compatibility between old and new versions, ensuring that network security vulnerabilities are not triggered during contract updates. Each smart contract has a unique version identifier <inline-formula id="inf35">
<mml:math id="m45">
<mml:mrow>
<mml:mi>V</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, and when implementing network security policies, the system first checks the version information of the contract. If a new contract version is detected, the system decides whether to upgrade to the latest version through a consensus mechanism as indicated by the <xref ref-type="disp-formula" rid="e11">Equation 11</xref>:<disp-formula id="e11">
<mml:math id="m46">
<mml:mrow>
<mml:msub>
<mml:mi>V</mml:mi>
<mml:mtext>new</mml:mtext>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>max</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>V</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>V</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>&#x2026;</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>V</mml:mi>
<mml:mi>n</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(11)</label>
</disp-formula>
</p>
<p>Through this approach, smart contracts ensure the latest security policies and system compatibility.</p>
</sec>
<sec id="s5">
<title>5 Access control mechanism</title>
<p>In the context of information security, it is crucial to ensure that only authorized users can access specific data. A hierarchical structure of roles is established by clearly defining the roles of system users. Each role represents a group of users with similar permissions. For example, the system can define the following roles: administrator, auditor, operator, and visitor. Each role is assigned corresponding permissions based on their functions in the business process, such as read, write, modify, and delete. To enhance the access control and security of partitioned data, this article adopts the Attribute-Based Access Control (ABAC) mechanism (<xref ref-type="bibr" rid="B10">Gupta et al., 2020</xref>). Unlike traditional Role-Based Access Control (RBAC), ABAC dynamically decides whether to grant access to specific data partitions based on user attributes, request context, data sensitivity, and other factors by defining finer grained access policies.</p>
<p>To achieve ABAC, this article defines the authorization rules for access control as follows indicated by the <xref ref-type="disp-formula" rid="e12">Equation 12</xref>:<disp-formula id="e12">
<mml:math id="m47">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>u</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="{" close="" separators="|">
<mml:mrow>
<mml:mtable columnalign="center">
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:mtext>&#xa0;</mml:mtext>
<mml:mn>1</mml:mn>
<mml:mo>,</mml:mo>
<mml:mtext>if</mml:mtext>
<mml:mi>&#x3d5;</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>u</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x2265;</mml:mo>
<mml:mi>&#x3b3;</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:mtext>&#xa0;</mml:mtext>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mtext>otherwise</mml:mtext>
</mml:mrow>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(12)</label>
</disp-formula>
<inline-formula id="inf36">
<mml:math id="m48">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>u</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> represents the access permission of user <inline-formula id="inf37">
<mml:math id="m49">
<mml:mrow>
<mml:mi>u</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to data <inline-formula id="inf38">
<mml:math id="m50">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>; <inline-formula id="inf39">
<mml:math id="m51">
<mml:mrow>
<mml:mi>&#x3d5;</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>u</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> represents the attribute vector of the user; <inline-formula id="inf40">
<mml:math id="m52">
<mml:mrow>
<mml:mi>&#x3b3;</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> represents the sensitivity level of the data. When the user attributes meet the security requirements for data access, access is authorized.</p>
<p>In the process of data encryption, the system adopts a hybrid encryption mechanism. Assuming the symmetric encryption algorithm is AES, the encryption process is as follows indicated by the <xref ref-type="disp-formula" rid="e13">Equation 13</xref>:<disp-formula id="e13">
<mml:math id="m53">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>E</mml:mi>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>s</mml:mi>
</mml:msub>
</mml:msub>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>M</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(13)</label>
</disp-formula>
<inline-formula id="inf41">
<mml:math id="m54">
<mml:mrow>
<mml:mi>M</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is plaintext; <inline-formula id="inf42">
<mml:math id="m55">
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is ciphertext; <inline-formula id="inf43">
<mml:math id="m56">
<mml:mrow>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>s</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is symmetric encryption key; <inline-formula id="inf44">
<mml:math id="m57">
<mml:mrow>
<mml:mi>E</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is AES encryption function. Asymmetric encryption is used for key exchange. Assuming that the key pair for RSA encryption is <inline-formula id="inf45">
<mml:math id="m58">
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mtext>pub</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mtext>priv</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
</inline-formula>, the encryption formula is indicated by the <xref ref-type="disp-formula" rid="e14">Equation 14</xref>:<disp-formula id="e14">
<mml:math id="m59">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>K</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>E</mml:mi>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mtext>pub</mml:mtext>
</mml:msub>
</mml:msub>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>s</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
<label>(14)</label>
</disp-formula>
<inline-formula id="inf46">
<mml:math id="m60">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>K</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is the encrypted symmetric key <inline-formula id="inf47">
<mml:math id="m61">
<mml:mrow>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>s</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, ensuring the security of key transmission under public key encryption.</p>
<p>As shown in <xref ref-type="fig" rid="F7">Figure 7</xref>, AA (Attribute Authority) is responsible for creating, managing, and querying entity attributes; PAP (Policy Administration Point) is responsible for creating, managing, and querying access control policies; PEP (Policy Enforcement Point) queries AA for attributes based on access requests, generates attribute based access requests, and sends them to PDP (Policy Decision Point) to access resources based on the judgment results; PDP receives attribute-based access requests from PEP, receives policy sets from PAP, and then judges the access requests based on the policies, returning the judgment results to PEP. This mechanism enables the system to flexibly respond to complex business scenarios, ensuring that only authorized users can operate on specific data in a data partitioning environment.</p>
<fig id="F7" position="float">
<label>FIGURE 7</label>
<caption>
<p>Attribute-based access control model.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g007.tif">
<alt-text content-type="machine-generated">A flowchart illustrating an access control process. An access request is sent to the Policy Enforcement Point (PEP), which then queries attributes from an Attribute Authority (AA). The AA returns the attributes to the PEP. The PEP forwards an attribute-based access request to the Policy Decision Point (PDP), which sends a strategy query to the Policy Administration Point (PAP). The PAP returns the query result to the PDP, which then provides a judgment result to the PEP. The PEP finally requests resources and processes the results.</alt-text>
</graphic>
</fig>
<p>In the process of role definition and permission allocation, the specific tasks of different roles in the system are analyzed and the required permissions are determined. According to the principle of minimum privilege, only the roles are given the minimum privilege required to execute tasks, to avoid excessive permission expansion. If the required permission for role <inline-formula id="inf48">
<mml:math id="m62">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is <inline-formula id="inf49">
<mml:math id="m63">
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x2286;</mml:mo>
<mml:mi>P</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, the design is based on the principle of minimum permissions, that is, <inline-formula id="inf50">
<mml:math id="m64">
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="{" close="}" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>p</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mfenced open="|" close="" separators="|">
<mml:mrow>
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>&#x2208;</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:msub>
<mml:mi mathvariant="script">T</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf51">
<mml:math id="m65">
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="script">T</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is the set of tasks for role <inline-formula id="inf52">
<mml:math id="m66">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. The role permissions are updated in a timely manner when role responsibilities change, or business requirements are adjusted to ensure that security policies are consistent with actual needs.</p>
<p>After the allocation of roles and permissions is completed, the system implements specific access control to data through an Access Control List (ACL), which can be represented as <inline-formula id="inf53">
<mml:math id="m67">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mi>C</mml:mi>
<mml:msub>
<mml:mi>L</mml:mi>
<mml:mi>d</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mfenced open="{" close="|" separators="|">
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mfenced open="" close="}" separators="|">
<mml:mrow>
<mml:mrow>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>R</mml:mi>
</mml:mrow>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf54">
<mml:math id="m68">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the data object. When user <inline-formula id="inf55">
<mml:math id="m69">
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> attempts to access data object <inline-formula id="inf56">
<mml:math id="m70">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, the system performs identity authentication, calculates user role <inline-formula id="inf57">
<mml:math id="m71">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>U</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, and checks <inline-formula id="inf58">
<mml:math id="m72">
<mml:mrow>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>U</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>P</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>A</mml:mi>
<mml:mi>C</mml:mi>
<mml:msub>
<mml:mi>L</mml:mi>
<mml:mi>d</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. Each data object maintains an access control list, which lists the roles and corresponding permissions that can access the object. When a user attempts to access specific data, the system first verifies their identity. As shown in <xref ref-type="fig" rid="F8">Figure 8</xref>, this article adopts the TOTP (Time-Based One-Time Password) password algorithm in Multi-Factor Authentication (MFA) technology. It is a time-based one-time password generation mechanism that combines passwords and dynamic verification codes to improve the security of authentication. After confirming the user&#x2019;s identity, the system queries the access control list based on their corresponding role to verify whether they have permission to access the data object. If the user does not have the corresponding permissions, the access request is denied and detailed information about unauthorized access attempts is recorded for subsequent auditing and analysis. The processing result of the access request is fed back to the user in real-time. If the request is rejected, the system provides the reason for the rejection, enhancing the transparency of the user experience.</p>
<fig id="F8" position="float">
<label>FIGURE 8</label>
<caption>
<p>Multi-factor authentication model.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g008.tif">
<alt-text content-type="machine-generated">Flowchart illustrating a multi-factor authentication (MFA) process using time-based one-time password (TOTP). It involves an authentication server and physical equipment using common encryption algorithms. Access passwords A and B are compared; if they match, login is successful. Otherwise, login fails.</alt-text>
</graphic>
</fig>
<p>To further enhance security, the system keeps detailed records of all access requests, including user ID, request time, request data, operation type, etc. All access requests are <inline-formula id="inf59">
<mml:math id="m73">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mfenced open="{" close="}" separators="|">
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>U</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>d</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>t</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>o</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>; <inline-formula id="inf60">
<mml:math id="m74">
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the user ID; <inline-formula id="inf61">
<mml:math id="m75">
<mml:mrow>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the requested data; <inline-formula id="inf62">
<mml:math id="m76">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is time; <inline-formula id="inf63">
<mml:math id="m77">
<mml:mrow>
<mml:mi>o</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is the type of operation that needs to be recorded in log <inline-formula id="inf64">
<mml:math id="m78">
<mml:mrow>
<mml:mi mathvariant="normal">L</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to ensure immutability. Anomaly detection model <inline-formula id="inf65">
<mml:math id="m79">
<mml:mrow>
<mml:mi>D</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is utilized to perform real-time analysis on logs, where <inline-formula id="inf66">
<mml:math id="m80">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> represents access patterns. If <inline-formula id="inf67">
<mml:math id="m81">
<mml:mrow>
<mml:mi>D</mml:mi>
<mml:mrow>
<mml:mfenced open="(" close=")" separators="|">
<mml:mrow>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> detects an abnormality, it triggers alarm <inline-formula id="inf68">
<mml:math id="m82">
<mml:mrow>
<mml:msub>
<mml:mi>A</mml:mi>
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>r</mml:mi>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. The log recording adopts an immutable method to ensure the integrity and credibility of the data. By establishing a rule-based anomaly detection model, real-time analysis of access logs can be conducted. If the system detects abnormal access patterns, such as multiple unauthorized accesses within a short period of time, the system automatically triggers an alert to remind the security administrator to investigate. The system sets up a regular audit mechanism, and security administrators regularly review access logs to analyze user access behavior and permission usage, ensuring the effectiveness and rationality of access control policies. Audit reports are generated regularly and used to evaluate and optimize access control policies.</p>
<p>To ensure the effectiveness of the access control mechanism, the system also implements user training and security awareness enhancement measures, providing regular security training to all users, covering access control policies, potential security threats, and countermeasures, to enhance users&#x2019; security awareness. A security manual is published to clarify the responsibilities and permissions of each role, and guide users on how to use the system correctly and securely. User feedback channels are established to encourage users to report issues and suggestions during the access control process, to continuously optimize system security.</p>
</sec>
<sec id="s6">
<title>6 Construction of real-time montonotoring system</title>
<p>To achieve dynamic monitoring and rapid response to information model operation and maintenance data network security, the real-time monitoring system adopts a layered architecture, mainly including a data collection layer and a data processing layer.</p>
<p>The data collection layer collects real-time information such as network traffic, user behavior, system status, access logs, and security events through sensors and log proxies. All data is preprocessed during the collection process, filtering out irrelevant information to ensure the efficiency of subsequent analysis.</p>
<p>The data processing layer adopts the real-time streaming data processing framework (Flink) (<xref ref-type="bibr" rid="B5">Cheng et al., 2020</xref>) to perform real-time analysis on the collected data, supporting both stream processing and batch processing with the same runtime mechanism. As shown in <xref ref-type="fig" rid="F9">Figure 9</xref>, Flink can calculate based on the actual occurrence time of events, which enables it to correctly handle data that arrives out of order. It also provides powerful state management functions for state management, making it easy to save and access state information in operators. Flink provides end-to-end consistency and fault tolerance through a checkpointing mechanism, ensuring that even in the event of a failure, it can recover to a consistent state and handle large amounts of data with low processing latency. It offers different levels of abstraction, including SQL, Table API, DataStream API, and DataSet API, to meet different levels of development needs.</p>
<fig id="F9" position="float">
<label>FIGURE 9</label>
<caption>
<p>Real-time streaming data processing framework Flink.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g009.tif">
<alt-text content-type="machine-generated">Diagram illustrating the architecture of Flink. At the top are the base components: Table API, CEP API, SQL, FlinkML, and Gelly. Below are the user-oriented APIs: DataStream API and DataSet API. Central is the Flink Runtime Execution Engine, categorized under core structure. At the bottom are deployment options: Local, Cluster, YARN, and Mesos.</alt-text>
</graphic>
</fig>
<p>At the data processing layer, by modeling the behavior data of normal operations, a baseline of user and system behavior is constructed. Clustering analysis methods are used to classify user behavior and determine the scope of normal activities. Machine learning algorithms are applied for anomaly detection, and real-time user and system behavior data is analyzed. Compared with behavior baselines, activities that deviate from normal patterns are identified. Using Association Rules Mining (<xref ref-type="bibr" rid="B19">Santoso, 2021</xref>), potential relationships between security events are identified. For example, if a user frequently attempts unauthorized access, their relationship with other security events is included in the analysis scope to determine possible attack patterns.</p>
</sec>
<sec id="s7">
<title>7 Evluation indicator design</title>
<p>Once a potential security threat is detected, the real-time monitoring system immediately triggers a response mechanism to monitor abnormal behavior in real-time through preset thresholds. Once an anomaly is detected, the system automatically sends an alert, including the type of event, scope of impact, and preliminary analysis results, and promptly notifies the security team. The system automatically takes measures based on the defined response strategy. For example, if malicious login behavior is detected, the system temporarily locks the account and conducts a detailed review. The execution of this strategy is managed by smart contracts to ensure automation and accuracy of responses. All security incidents and response measures are recorded in the event log for subsequent auditing and analysis. These logs are not only used for post investigation, but also provide data support for improving the monitoring algorithm.</p>
<p>As shown in <xref ref-type="fig" rid="F10">Figure 10</xref>, two key monitoring indicators are set to evaluate the effectiveness of the real-time monitoring system:</p>
<fig id="F10" position="float">
<label>FIGURE 10</label>
<caption>
<p>Real-time monitoring system detection. <bold>(A)</bold>: Statistics of abnormal event types; Figure 10 <bold>(B)</bold>: Response time and number of abnormal events.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g010.tif">
<alt-text content-type="machine-generated">Chart A is a bar graph displaying the number of occurrences for different types of anomalies, with security events having the highest count. Chart B is a line graph showing response time in milliseconds over fifty anomaly events, exhibiting fluctuations around two hundred milliseconds.</alt-text>
</graphic>
</fig>
<p>Abnormal event detection: <xref ref-type="fig" rid="F10">Figure 10A</xref> shows the number of abnormal events and security events detected by the real-time monitoring system during four time periods.</p>
<p>Abnormal event response: <xref ref-type="fig" rid="F10">Figure 10B</xref> measures the time from event occurrence to system response, with an average response time of around 203&#xa0;m.</p>
<p>When evaluating network security, the first focus is on network security indicators, which not only reflect the system&#x2019;s ability to resist various security threats, but also reflect the effectiveness of the deployed security policies.</p>
<p>Definition of relevant parameters: As indicated by the <xref ref-type="disp-formula" rid="e15">Equation 15</xref>, TP is the number of samples correctly predicted as positive examples; TN is the number of samples correctly predicted as negative examples; FP is the number of samples that are incorrectly predicted as positive; FN is the number of samples that are incorrectly predicted as negative examples. The harmonic average of precision and recall are F1 as indicated by <xref ref-type="disp-formula" rid="e16">Equations 16</xref>-<xref ref-type="disp-formula" rid="e18">18</xref>.<disp-formula id="e15">
<mml:math id="m83">
<mml:mrow>
<mml:mtext>Accuracy</mml:mtext>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mtext>TP</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>TN</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mtext>TP</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>TN</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>FP</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>FN</mml:mtext>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
<label>(15)</label>
</disp-formula>
<disp-formula id="e16">
<mml:math id="m84">
<mml:mrow>
<mml:mtext>Precision</mml:mtext>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mtext>TP</mml:mtext>
<mml:mrow>
<mml:mtext>TP</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>FP</mml:mtext>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
<label>(16)</label>
</disp-formula>
<disp-formula id="e17">
<mml:math id="m85">
<mml:mrow>
<mml:mtext>Recall</mml:mtext>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mtext>TP</mml:mtext>
<mml:mrow>
<mml:mtext>TP</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>FP</mml:mtext>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
<label>(17)</label>
</disp-formula>
<disp-formula id="e18">
<mml:math id="m86">
<mml:mrow>
<mml:mi>F</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mo>&#xb7;</mml:mo>
<mml:mtext>Precision</mml:mtext>
<mml:mo>&#xb7;</mml:mo>
<mml:mtext>Recall</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mtext>Precision</mml:mtext>
<mml:mo>&#x2b;</mml:mo>
<mml:mtext>Recall</mml:mtext>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
<label>(18)</label>
</disp-formula>
</p>
<p>To quantify this indicator, a series of pre-set security test cases are used, including but not limited to common attack methods such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Distributed Denial of Service (DDoS) (<xref ref-type="bibr" rid="B4">Chen and Chen, 2020</xref>). The Metasploit penetration testing tool is used to simulate these attacks and execute attack attempts in specific scenarios through custom scripts. In a controlled environment, a zombie network simulator is used to generate abnormal traffic to simulate real DDoS attacks, to monitor the system&#x2019;s responsiveness.</p>
<p>As shown in <xref ref-type="table" rid="T1">Table 1</xref>, the results of all attacks in the experiment are recorded, and the success rate of each type of attack is calculated based on this data, with different weights given according to its potential impact. In this experiment, 90,221 samples are added for different types of network attacks, and 46,521 security data are mixed in. From <xref ref-type="table" rid="T1">Table 1</xref>, the model can still maintain a recall rate of up to 97.56% and an F1 value of 97.49% under different network attacks and can also maintain a precision rate of 97.44% in monitoring.</p>
<table-wrap id="T1" position="float">
<label>TABLE 1</label>
<caption>
<p>Simulation of various real attack data statistics.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Network flow type</th>
<th align="center">Number of samples collected</th>
<th align="center">Accuracy</th>
<th align="center">Precision</th>
<th align="center">Recall</th>
<th align="center">F1</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">XSS</td>
<td align="center">11,256</td>
<td align="center">96.54%</td>
<td align="center">96.25%</td>
<td align="center">96.54%</td>
<td align="center">96.39%</td>
</tr>
<tr>
<td align="center">CSRF</td>
<td align="center">10,489</td>
<td align="center">95.89%</td>
<td align="center">95.65%</td>
<td align="center">95.89%</td>
<td align="center">95.76%</td>
</tr>
<tr>
<td align="center">SYN Flood</td>
<td align="center">11,755</td>
<td align="center">96.67%</td>
<td align="center">96.43%</td>
<td align="center">96.67%</td>
<td align="center">96.54%</td>
</tr>
<tr>
<td align="center">Ping Flood</td>
<td align="center">12,459</td>
<td align="center">98.32%</td>
<td align="center">98.59%</td>
<td align="center">98.32%</td>
<td align="center">98.45%</td>
</tr>
<tr>
<td align="center">UDP Flood</td>
<td align="center">10,976</td>
<td align="center">97.73%</td>
<td align="center">97.57%</td>
<td align="center">97.73%</td>
<td align="center">97.64%</td>
</tr>
<tr>
<td align="center">Fragmentation Bombs</td>
<td align="center">10,395</td>
<td align="center">98.51%</td>
<td align="center">98.30%</td>
<td align="center">98.51%</td>
<td align="center">98.40%</td>
</tr>
<tr>
<td align="center">LAND</td>
<td align="center">11,028</td>
<td align="center">97.24%</td>
<td align="center">97.01%</td>
<td align="center">97.24%</td>
<td align="center">97.12%</td>
</tr>
<tr>
<td align="center">Smurf</td>
<td align="center">11,863</td>
<td align="center">97.83%</td>
<td align="center">97.62%</td>
<td align="center">97.83%</td>
<td align="center">97.72%</td>
</tr>
<tr>
<td align="center">Normal network flow</td>
<td align="center">46,521</td>
<td align="center">99.34%</td>
<td align="center">99.54%</td>
<td align="center">99.34%</td>
<td align="center">99.43%</td>
</tr>
<tr>
<td align="center">Overall</td>
<td align="center">136,742</td>
<td align="center">97.56%</td>
<td align="center">97.44%</td>
<td align="center">97.56%</td>
<td align="center">97.49%</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Another key security indicator is data leakage, which directly affects the protection status of sensitive information in enterprises. To accurately monitor this indicator, a comprehensive log audit is implemented to ensure that all access requests and user behavior are recorded in detail. SIEM (Security Information and Event Management) is deployed to integrate log information from multiple sources, and big data analysis techniques are used to quickly identify suspicious activities. Finally, machine learning algorithms are used to train an anomaly detection model that automatically labels and alerts for any behavior that deviates from the normal baseline. As shown in <xref ref-type="table" rid="T2">Table 2</xref>, 21,162 pieces of data are provided internally, and all data are defined as three different fields: basic field, business field, and confidential field. Various virus plugins are used for data leakage testing. From <xref ref-type="table" rid="T2">Table 2</xref>, the average data leakage rate of the virus for each field is only 7.70%.</p>
<table-wrap id="T2" position="float">
<label>TABLE 2</label>
<caption>
<p>Data leakage testing.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Field type</th>
<th align="center">Field input quantity</th>
<th align="center">Number of field detection</th>
<th align="center">Missing fields</th>
<th align="center">Leakage rate</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">Basic fields</td>
<td align="center">8,564</td>
<td align="center">7,867</td>
<td align="center">697</td>
<td align="center">8.86%</td>
</tr>
<tr>
<td align="center">Business Field</td>
<td align="center">6,925</td>
<td align="center">6,458</td>
<td align="center">467</td>
<td align="center">7.23%</td>
</tr>
<tr>
<td align="center">Confidential Field</td>
<td align="center">5,673</td>
<td align="center">5,324</td>
<td align="center">349</td>
<td align="center">6.56%</td>
</tr>
<tr>
<td align="center">Overall</td>
<td align="center">21,162</td>
<td align="center">19,649</td>
<td align="center">1,513</td>
<td align="center">7.70%</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The response time of the model is the time delay between the client initiating a request and the server returning the result, which directly affects the quality of user experience. To evaluate this, JMeter is used as the stress testing tool. As shown in <xref ref-type="fig" rid="F11">Figure 11</xref>, the same task is repeatedly executed in an unloaded state until a stable average time is obtained. During the experiment, the number of concurrent connections is gradually increased until the hardware resource limit is reached.</p>
<fig id="F11" position="float">
<label>FIGURE 11</label>
<caption>
<p>JMeter concurrent connection stress test view.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g011.tif">
<alt-text content-type="machine-generated">A line graph displaying the number of concurrent connections over elapsed time. The connections increase in a step-like pattern, reaching a maximum of 2000 before sharply declining near the end at 45 minutes and 24 seconds.</alt-text>
</graphic>
</fig>
<p>The experimental results are plotted using software to create line graphs of response times for each stage, to visually display the trend of service performance changing with load. The initial value of the stress testing software is set to record data every 4&#xa0;s, and the number of concurrent links is increased by 100&#xa0;at a time until the upper limit is reached before stopping sending.</p>
<p>From <xref ref-type="fig" rid="F12">Figure 12</xref>, the system response time fluctuates between 210&#xa0;m and 230&#xa0;m, and the average system response time obtained by the software is 221&#xa0;m.</p>
<fig id="F12" position="float">
<label>FIGURE 12</label>
<caption>
<p>JMeter monitoring system response time.</p>
</caption>
<graphic xlink:href="fbloc-08-1619708-g012.tif">
<alt-text content-type="machine-generated">Line graph depicting response time in milliseconds versus the number of concurrent connections ranging from zero to one thousand. Response time fluctuates between 210 and 230 milliseconds, showing no consistent pattern.</alt-text>
</graphic>
</fig>
<p>
<xref ref-type="table" rid="T3">Table 3</xref> shows the continuous monitoring of server CPU and memory usage during the testing process and comparison with traditional models. When the concurrency is 50, the improved model has a CPU usage rate that is about 5.02% lower and a memory usage rate that is about 4.82% lower compared to the traditional model. It has demonstrated excellent performance in the construction of information model operation and data network security in partitioned blockchain. This model has consistently shown near ideal results in multiple experiments.</p>
<table-wrap id="T3" position="float">
<label>TABLE 3</label>
<caption>
<p>Comparison of CPU and memory usage between traditional and improved models.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th rowspan="2" align="center">Concurrency</th>
<th colspan="2" align="center">Improved model</th>
<th colspan="2" align="center">Traditional model</th>
</tr>
<tr>
<th align="center">CPU usage</th>
<th align="center">Memory usage</th>
<th align="center">CPU usage</th>
<th align="center">Memory usage</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">50</td>
<td align="center">7.23%</td>
<td align="center">11.52%</td>
<td align="center">12.25%</td>
<td align="center">16.34%</td>
</tr>
<tr>
<td align="center">100</td>
<td align="center">7.40%</td>
<td align="center">10.89%</td>
<td align="center">12.43%</td>
<td align="center">16.62%</td>
</tr>
<tr>
<td align="center">200</td>
<td align="center">7.56%</td>
<td align="center">11.21%</td>
<td align="center">12.68%</td>
<td align="center">16.87%</td>
</tr>
<tr>
<td align="center">300</td>
<td align="center">7.71%</td>
<td align="center">11.46%</td>
<td align="center">12.91%</td>
<td align="center">17.11%</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Simulations of zero-day attacks are also made and indicates that partition blockchains (such as Ethereum 2.0 sharding) enhance scalability through sharding technology, but also amplify the risk of zero-day attacks.<list list-type="simple">
<list-item>
<p>a. Expanded vulnerability exposure: Sharding architecture increases the complexity of cross shard communication interfaces and consensus mechanisms, which may become a new target for zero-day vulnerabilities; Simulation shows that vulnerabilities in IoT devices, which account for 35% of high-risk vulnerabilities in industrial control systems, can be likened to blockchain edge nodes and are easily exploited to trigger network level attacks.</p>
</list-item>
<list-item>
<p>b. Increased challenges in fixing windows: The decentralized nature of blockchain may lead to delayed vulnerability fixes; Reference data shows that the average repair cycle for traditional systems is 98 days, while industrial control systems can last up to 150 days. In sharded blockchain systems, coordinating multi partition repairs or exacerbating the &#x201c;attack and defense time gap&#x201d; puts 40% of zero-day vulnerabilities at long-term risk of not being fixed.</p>
</list-item>
<list-item>
<p>c. New attack path: Zero-day vulnerability exploitation is combining AI and big model technology (such as automatic generation of attack code), which may target smart contracts or cross chain bridges on sharded blockchain; In the Google experiment, the large model has successfully identified 0&#xa0;day vulnerabilities in memory security, indicating that attack tools are rapidly evolving and threatening defense systems.</p>
</list-item>
</list>
</p>
<p>To cope with the zero-day attack risk of partitioned blockchain, the cutting-edge defense frameworks can be used for reference as follows.<list list-type="simple">
<list-item>
<p>a. Multi-layer protection strategy: Implement full lifecycle security requirements like the EU&#x2019;s. Network Resilience Act, including vulnerability scanning, intrusion detection, and automated response mechanisms to compress attack window.</p>
</list-item>
<list-item>
<p>b. AI driven threat detection: Utilize large models for vulnerability mining (such as the Google case) can enhance the proactive defense capabilities of blockchain systems; The AI security guidelines of the Five Eyes Alliance emphasize multi-layer protection and are suitable for anomaly monitoring in sharded environments.</p>
</list-item>
<list-item>
<p>c. Compliance and Collaboration: Strengthen the transparency of blockchain open source components and establish cross partition emergency collaboration mechanisms to resist industrial attack chains.</p>
</list-item>
</list>
</p>
<p>In summary, the simulation risk of zero-day attacks in partitioned blockchain is highlighted as a triple upgrade of &#x201c;speed-scale- complexity&#x201d;, requiring the integration of AI enhanced defense and strict compliance frameworks to reduce threats.</p>
<p>Adversarial sample testing of partitioned blockchain has also been conducted, which shows that the system strengthens its defense against malicious construction traffic through multiple layers of mechanisms, with the core reflected in the following aspects.</p>
<sec id="s7-1">
<title>7.1 Permission control and identity authentication enhancement</title>
<p>The system strictly separates the access permissions of different roles (such as users and administrators) to prevent unauthorized operations and uses multi factor authentication and key management to resist identity forgery or session hijacking, ensuring that malicious traffic cannot obtain illegal access.</p>
</sec>
<sec id="s7-2">
<title>7.2 Smart contract security and consensus mechanism protection</title>
<p>Using static analysis and fuzzy testing to detect logical vulnerabilities in smart contracts (such as re-entry attacks and overflow), while simulating scenarios such as 51% attacks and double spending attacks to verify the robustness of consensus algorithms (such as PoW/PoS) and block malicious traffic from exploiting protocol weaknesses. Five Combining AI driven behavior detection, such as kernel level file write blocking technology, can achieve high precision killing before malicious payloads are executed.</p>
</sec>
<sec id="s7-3">
<title>7.3 Network layer and application layer defense in depth</title>
<p>Integrate DDoS protection mechanisms, such as dynamically responding to sudden traffic surges through elastic bandwidth and load balancing (such as Nginx) and verify the effectiveness of P2P network communication encryption and node admission mechanisms.</p>
<p>For adversarial samples, the system utilizes AI models (such as generative adversarial network GAN defense) to detect high simulation traffic and prevent data leakage caused by malicious sequence injection or role-playing attacks.</p>
</sec>
<sec id="s7-4">
<title>7.4 Data privacy and end-to-end security</title>
<p>Protecting data transmission and storage privacy through zero knowledge proof, homomorphic encryption, and other technologies, combined with federated learning architecture to ensure communication confidentiality in distributed environments, and resist traffic theft or tampering.</p>
<p>At the level of computing power networks, deploy intrusion detection and SDN security mechanisms to ensure real-time response capabilities in the &#x201c;cloud edge collaboration&#x201d; scenario.</p>
<p>Overall, the system combines technical countermeasures (such as vulnerability detection) with operational countermeasures (such as continuous monitoring) to form a comprehensive defense system against malicious traffic.</p>
<p>There are certainly some differences between the simulated environment and the actual network scales as described below.</p>
<sec id="s7-4-1">
<title>7.4.1 Node size and data authenticity</title>
<p>Simulated environments typically contain a small number of nodes (such as within 100 nodes), and the data has been desensitized or fabricated. For example, a student performance management system only contains simulated data for 5 classes. However, the actual network environment usually involves large-scale nodes (such as thousands to tens of thousands of nodes), processing TB level unstructured data in real business scenarios, such as social media platforms requiring real-time analysis of millions of user behavior logs.</p>
</sec>
<sec id="s7-4-2">
<title>7.4.2 Performance differences in consensus mechanisms</title>
<p>Simplified consensus algorithms (such as PBFT) are often used in simulated environments to test basic functions, with an average TPS (transactions per second) of only 1.59, while in actual networks, using more efficient consensus mechanisms (such as Kafka) can achieve 2.37 TPS. In addition, simulation environments cannot verify complex scenarios such as Byzantine fault tolerance and dynamic node joining/exiting in real networks.</p>
</sec>
<sec id="s7-4-3">
<title>7.4.3 Fault injection and risk-taking</title>
<p>Simulate the environment for testing through preset faults (such as malicious node attacks), but without causing real economic losses. In actual networks, it is necessary to deal with sudden failures, and wrong decisions may lead to the loss of transactions worth hundreds of thousands of dollars per minute. For example, in a case where a certain e-commerce promotion lost 27% of orders due to insufficient bandwidth.</p>
</sec>
<sec id="s7-4-4">
<title>7.4.4 Distributed feature verification</title>
<p>The simulated environment only verifies single point or cluster communication, while the actual network needs to verify multi node data synchronization consistency, cross chain atomicity, and other characteristics. For example, blockchain testing requires verifying the immutability of Merkle tree hashes, while traditional testing only verifies ACID properties.</p>
<p>The adaptability of large-scale distributed networks is a multidimensional and continuously evolving goal. It depends on the combination of a series of distributed algorithms, protocols, architecture patterns and emerging technologies (decentralization, DHT, Gossip, SDN, NFV, ML/AI, edge computing, etc.). Designers need to make wise choices among various trade-offs (consistency, availability, partition tolerance, efficiency, overhead, security) and follow core principles such as decentralization, locality, redundancy, and feedback control. With the continuous growth of network size and complexity, utilizing AI/ML for intelligent perception, prediction, and automated decision-making will become a key direction for building the next-generation of highly adaptive distributed networks.</p>
<p>Since the current partitioning relies on static clustering algorithms without addressing adjustments under dynamic data updates, therefore, it is necessary to supplement the design with dynamic partitioning strategies.</p>
<p>The dynamic partitioning strategy of partitioned blockchain is a data management method that combines the characteristics of blockchain and dynamic partitioning technology to address the adjustment problem under dynamic data updates. It mainly optimizes performance and resource allocation by adjusting data storage or network structure in real-time. Its core strategy includes the following key points.</p>
</sec>
</sec>
<sec id="s7-5">
<title>7.5 Implementation mechanism of dynamic partitioning</title>
<sec id="s7-5-1">
<title>7.5.1 Data driven partition adjustment</title>
<p>Dynamically partition data storage areas based on real-time loads such as transaction volume and node pressure. For example, when there is a surge in transactions in a specific partition, the system automatically splits the partition and migrates data to a new node to avoid single point congestion.</p>
</sec>
<sec id="s7-5-2">
<title>7.5.2 Time series partition management</title>
<p>Adopting dynamic partitioning rules like databases (such as hourly/daily partitioning), pre creating future partitions and regularly cleaning up expired data to ensure efficient storage expansion.</p>
</sec>
<sec id="s7-5-3">
<title>7.5.3 Intelligent partition merging and splitting</title>
<p>Based on a preset threshold (such as the upper limit of data volume), trigger partition merging (reducing fragmentation) or splitting (sharing load), combined with algorithms (such as machine learning) to predict hotspot areas.</p>
</sec>
</sec>
<sec id="s7-6">
<title>7.6 Key technical support</title>
<sec id="s7-6-1">
<title>7.6.1 Dynamic accumulator and cryptographic guarantee</title>
<p>Use dynamic accumulators (such as improved Merkle trees) to quickly verify cross partition data integrity and prevent tampering.</p>
</sec>
<sec id="s7-6-2">
<title>7.6.2 Adaptation of consensus mechanism</title>
<p>Dynamic partitioning needs to be coordinated with consensus algorithms: during partition adjustment, voting or BFT protocols are used to ensure consistent states between nodes and avoid forking.</p>
</sec>
<sec id="s7-6-3">
<title>7.6.3 Lightweight node synchronization</title>
<p>After the partition boundary changes, only the metadata (such as the new partition header) needs to be synchronized, reducing network transmission overhead.</p>
</sec>
</sec>
<sec id="s7-7">
<title>7.7 Core optimization objectives</title>
<sec id="s7-7-1">
<title>7.7.1 Break through the limitations of the &#x201c;impossible triangle&#x201d;</title>
<p>Dynamic trade-off between decentralization, security, and high performance: partition refinement improves processing speed (performance) but requires the addition of verification nodes to maintain security; Partition merging enhances decentralization and sacrifices some throughput.</p>
</sec>
<sec id="s7-7-2">
<title>7.7.2 Maximizing resource utilization</title>
<p>Allocate node resources through algorithms such as first adaptation and best adaptation to reduce memory fragmentation (dynamic partition allocation like operating systems).</p>
<p>The following are the core technical points of dynamic partitioning strategy for partitioned blockchain.</p>
</sec>
</sec>
<sec id="s7-8">
<title>7.8 Dynamic shard adjustment mechanism</title>
<sec id="s7-8-1">
<title>7.8.1 Load responsive shard quantity control</title>
<p>The system automatically increases or decreases the number of shards based on real-time transaction load to ensure that resource allocation matches network demand.</p>
</sec>
<sec id="s7-8-2">
<title>7.8.2 Automated management driven by smart contracts</title>
<p>Creating, merging, and migrating shards through smart contracts to reduce manual intervention costs. The dynamic sharding algorithm proposed by MIT can automatically perform sharding operations based on preset rules.</p>
</sec>
</sec>
<sec id="s7-9">
<title>7.9 Key technology implementation path</title>
<sec id="s7-9-1">
<title>7.9.1 Incremental graph partitioning strategy</title>
<p>This strategy can model network nodes as dynamic graphs, optimize shard structures through real-time analysis of node interaction relationships, and cope with the pressure of massive data and high-frequency trading.</p>
</sec>
<sec id="s7-9-2">
<title>7.9.2 Tiered data storage</title>
<p>The system supports automatic cooling of hot and cold data, and regularly creates/deletes sub tables through dynamic partitioning rules to reduce storage costs.</p>
</sec>
</sec>
<sec id="s7-10">
<title>7.10 Performance improvement effect comparison between the traditional architecture and the dynamic sharding architecture (as indicated by <xref ref-type="table" rid="T4">Table 4</xref> below)</title>
<p>The dynamic partitioning strategy solves the scalability bottleneck of blockchain through shard elasticity, automatic data migration, and innovative consistency protocols, providing underlying support for high concurrency scenarios such as the Internet of Things.</p>
<table-wrap id="T4" position="float">
<label>TABLE 4</label>
<caption>
<p>Performance improvement effect comparison between traditional architecture and the dynamic sharding architecture.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Index</th>
<th align="center">Traditional architecture</th>
<th align="center">Dynamic sharding architecture</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">System Throughput</td>
<td align="center">&#x2264;100, 000TPS</td>
<td align="center">Million level TPS</td>
</tr>
<tr>
<td align="center">Storage Scalability</td>
<td align="center">Fixed Partitioning</td>
<td align="center">Elastic Expansion and Contraction</td>
</tr>
<tr>
<td align="center">Cross Shard Consistency Maintenance</td>
<td align="center">High latency</td>
<td align="center">Smart Contract Protection</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>When blockchain data is dynamically updated, the stability of partition strategies mainly depends on efficient rebalancing mechanisms and adaptive techniques to prevent data skewing and performance degradation. A fixed number of partition architectures can significantly reduce the amount of data migration during node changes (such as adding or deleting nodes) and maintain load balancing by avoiding the use of hash mod N methods.</p>
<p>The dynamic adjustment strategy combined with deep reinforcement learning models the system as a Markov decision process, optimizing the number and configuration of shards in real-time to adapt to changes in block size, block generation time, network load, etc., improving system throughput and fault tolerance.</p>
<p>Sharding technology uses spatial partitioning (such as hash distribution) and temporal sharding (such as Merkle Tree structure), combined with differential compression and hierarchical management of hot and cold data, to compress storage space, reduce read and write latency, and ensure stability under high concurrency data updates. These mechanisms collectively ensure the data consistency of blockchain in the dynamic changes of the network.</p>
<p>Finally, the Partitioned blockchain technology can also strengthens sensitive data privacy protection through the following core measures.<list list-type="simple">
<list-item>
<p>a. Distributed storage: Data is stored in a decentralized manner among network nodes to avoid single point of failure and centralized leakage risks, ensuring that even if individual nodes are attacked, the overall data remains secure.</p>
</list-item>
<list-item>
<p>b. Advanced encryption technology: using asymmetric encryption (such as public and private key mechanisms), only authorized users can access sensitive information, preventing data from being illegally cracked.</p>
</list-item>
<list-item>
<p>c. Non tampering: Once data is written into the blockchain, it is permanently recorded and cannot be changed. Any tampering behavior will be detected and rejected by the node network, ensuring data integrity.</p>
</list-item>
<list-item>
<p>d. Smart contract control: By automatically executing programs with preset conditions, data access permissions are restricted to ensure that only authorized operations can trigger data flow.</p>
</list-item>
<list-item>
<p>e. Privacy protection technology: integrating mechanisms such as zero knowledge proof and homomorphic encryption to verify their effectiveness without exposing the original data, achieving a &#x201c;usable but invisible&#x201d; data environment.</p>
</list-item>
</list>
</p>
</sec>
</sec>
<sec sec-type="conclusion" id="s8">
<title>8 Conclusion</title>
<p>This article proposes a method for constructing network security for sustainable information model operation and maintenance data based on partitioned blockchain. Through steps such as decentralized data storage, automated execution of smart contract policies, role-based access control, and real-time monitoring mechanisms, the security and scalability of the information operation and maintenance system are effectively improved. The research results indicate that this method not only significantly reduces the risk of single point of failure, but also enhances the overall security protection capability of the system and improves the efficiency and scalability of blockchain technology while ensuring security.</p>
<p>Compared to the previous studies, the results of the study in this article shows that there are significant differences between the partitioned blockchain method and non-blockchain methods in terms of security, decentralization, data integrity, and efficiency, in which the partitioned blockchain method has much stronger performance. This result is certainly also better result.</p>
<p>However, this study also has certain limitations, such as inadequate response to complex attack patterns in large-scale distributed networks and the need for further optimization of adaptability to networks of different scales. Future research can explore more efficient consensus algorithms to support a wider range of application scenarios such as the related applications on various construction projects and strengthen defense measures against emerging threats, providing more comprehensive security for information operation and maintenance data.</p>
</sec>
</body>
<back>
<sec sec-type="data-availability" id="s9">
<title>Data availability statement</title>
<p>The raw data supporting the conclusions of this article will be made available by the authors, without undue reservation.</p>
</sec>
<sec sec-type="author-contributions" id="s10">
<title>Author contributions</title>
<p>FC: Writing &#x2013; original draft, Formal Analysis, Project administration, Conceptualization, Methodology. JY: Funding acquisition, Writing &#x2013; review and editing, Resources, Data curation, Investigation, Visualization. ZX: Writing &#x2013; review and editing, Validation.</p>
</sec>
<sec sec-type="funding-information" id="s11">
<title>Funding</title>
<p>The author(s) declare that financial support was received for the research and/or publication of this article. This research was supported by Research on the Service Ecology and Optimization Strategy of Jiangsu Design Museum Empowered by Metacosmos, Jiangsu Province, China, 2022 (22YSB022); Research on Digital Ecology and Scenario-based Service Strategy of Design Education Resources in Local Colleges and Universities, Yancheng College of Technology, Jiangsu Province, China, 2022.</p>
</sec>
<sec sec-type="COI-statement" id="s12">
<title>Conflict of interest</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
<sec sec-type="ai-statement" id="s13">
<title>Generative AI statement</title>
<p>The author(s) declare that no Generative AI was used in the creation of this manuscript.</p>
<p>Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.</p>
</sec>
<sec sec-type="disclaimer" id="s14">
<title>Publisher&#x2019;s note</title>
<p>All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.</p>
</sec>
<ref-list>
<title>References</title>
<ref id="B1">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Bin</surname>
<given-names>L. I.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>GBFT: an improved practical byzantine fault tolerant algorithm</article-title>. <source>Comput. Digital Eng.</source> <volume>52</volume> (<issue>1</issue>), <fpage>87</fpage>&#x2013;<lpage>93</lpage>.</citation>
</ref>
<ref id="B2">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Cai</surname>
<given-names>G. U. O.</given-names>
</name>
<name>
<surname>Xuran</surname>
<given-names>L. I.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>Y.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Overview of the application of blockchain technology in the internet of things</article-title>. <source>Chin. J. Internet Things</source> <volume>5</volume> (<issue>1</issue>), <fpage>72</fpage>&#x2013;<lpage>89</lpage>.</citation>
</ref>
<ref id="B3">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Chaoyi</surname>
<given-names>Q. I. N.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Fang</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Survey of RPKI decentralized security enhancement technology</article-title>. <source>J. Commun.</source> <volume>45</volume> (<issue>7</issue>), <fpage>196</fpage>&#x2013;<lpage>205</lpage>.</citation>
</ref>
<ref id="B4">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Chen</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Distributed denial of service attack detection of internet of things based on statistics</article-title>. <source>J. Jilin Univ. Eng. Sci.</source> <volume>50</volume> (<issue>5</issue>), <fpage>1894</fpage>&#x2013;<lpage>1904</lpage>.</citation>
</ref>
<ref id="B5">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Cheng</surname>
<given-names>D. I.</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Han</surname>
<given-names>Y.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Real-time processing and servitization system for streaming data</article-title>. <source>J. Chongqing Univ.</source> <volume>43</volume> (<issue>7</issue>), <fpage>75</fpage>&#x2013;<lpage>83</lpage>.</citation>
</ref>
<ref id="B6">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Das</surname>
<given-names>A. K.</given-names>
</name>
<name>
<surname>Nikum</surname>
<given-names>A. K.</given-names>
</name>
<name>
<surname>Krishnan</surname>
<given-names>S. V.</given-names>
</name>
<name>
<surname>Pratihar</surname>
<given-names>D. K.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Multi-objective bonobo optimizer (MOBO): an intelligent heuristic for multi-criteria optimization</article-title>. <source>Knowl. Inf. Syst.</source> <volume>62</volume> (<issue>11</issue>), <fpage>4407</fpage>&#x2013;<lpage>4444</lpage>. <pub-id pub-id-type="doi">10.1007/s10115-020-01503-x</pub-id>
</citation>
</ref>
<ref id="B7">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Ding</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Kai</surname>
<given-names>L. I. U.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>A review of research on network security knowledge graph</article-title>. <source>J. Huazhong Univ. Sci. Technol. Nat. Sci. Ed.</source> <volume>49</volume> (<issue>7</issue>), <fpage>79</fpage>&#x2013;<lpage>91</lpage>.</citation>
</ref>
<ref id="B8">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Gansen</surname>
<given-names>ZHAO</given-names>
</name>
<name>
<surname>Zhijian</surname>
<given-names>X. I. E.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Contract guard: an intrusion detection system for smart contracts on ethereum blockchain</article-title>. <source>Chin. J. Netw. Inf. Secur.</source> <volume>6</volume> (<issue>2</issue>), <fpage>35</fpage>&#x2013;<lpage>55</lpage>.</citation>
</ref>
<ref id="B9">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Gao</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Research on network security technology based on blockchain</article-title>. <source>Electron. Commun. Comput. Sci.</source> <volume>5</volume> (<issue>5</issue>), <fpage>76</fpage>&#x2013;<lpage>78</lpage>.</citation>
</ref>
<ref id="B10">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Gupta</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Awaysheh</surname>
<given-names>F. M.</given-names>
</name>
<name>
<surname>Benson</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Alazab</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Patwa</surname>
<given-names>F.</given-names>
</name>
<name>
<surname>Sandhu</surname>
<given-names>R.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>An attribute-based access control for cloud enabled industrial smart vehicles</article-title>. <source>IEEE Trans. Industrial Inf.</source> <volume>17</volume> (<issue>6</issue>), <fpage>4288</fpage>&#x2013;<lpage>4297</lpage>. <pub-id pub-id-type="doi">10.1109/tii.2020.3022759</pub-id>
</citation>
</ref>
<ref id="B11">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hellings</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Sadoghi</surname>
<given-names>M.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>ByShard: sharding in a byzantine environment</article-title>. <source>Proc. VLDB Endow.</source> <volume>14</volume> (<issue>11</issue>), <fpage>2230</fpage>&#x2013;<lpage>2243</lpage>. <pub-id pub-id-type="doi">10.14778/3476249.3476275</pub-id>
</citation>
</ref>
<ref id="B12">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hidayat</surname>
<given-names>I.</given-names>
</name>
<name>
<surname>Ali</surname>
<given-names>M. Z.</given-names>
</name>
<name>
<surname>Arshad</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Machine learning-based intrusion detection system: an experimental comparison</article-title>. <source>J. Comput. Cognitive Eng.</source> <volume>2</volume> (<issue>2</issue>), <fpage>88</fpage>&#x2013;<lpage>97</lpage>. <pub-id pub-id-type="doi">10.47852/bonviewjcce2202270</pub-id>
</citation>
</ref>
<ref id="B13">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hu</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Leng</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Yuan</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Intelligent O&#x26;M management method based on BIM and data</article-title>. <source>J. Tsinghua Univ. Nat. Sci. Ed.</source> <volume>62</volume> (<issue>2</issue>), <fpage>199</fpage>&#x2013;<lpage>207</lpage>.</citation>
</ref>
<ref id="B14">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Lang</surname>
<given-names>F.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>A new interpretation of smart contracts to contracts under blockchain technology</article-title>. <source>J. Chongqing Univ. Soc. Sci.</source> <volume>27</volume> (<issue>5</issue>), <fpage>169</fpage>&#x2013;<lpage>182</lpage>.</citation>
</ref>
<ref id="B15">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Liu</surname>
<given-names>F.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Xiao</surname>
<given-names>D.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Application of machine learning model in landslide vulnerability assessment</article-title>. <source>Chin. J. Geol. Hazard Control</source> <volume>32</volume> (<issue>6</issue>), <fpage>98</fpage>&#x2013;<lpage>106</lpage>.</citation>
</ref>
<ref id="B16">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Muhtadi</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Pandit</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Nguyen</surname>
<given-names>N.</given-names>
</name>
<name>
<surname>Mitra</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Distributed energy resources based microgrid: review of architecture, control, and reliability</article-title>. <source>IEEE Trans. Industry Appl.</source> <volume>57</volume> (<issue>3</issue>), <fpage>2223</fpage>&#x2013;<lpage>2235</lpage>. <pub-id pub-id-type="doi">10.1109/tia.2021.3065329</pub-id>
</citation>
</ref>
<ref id="B17">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Peng</surname>
<given-names>QIAN</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>He</surname>
<given-names>Q.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Research on security vulnerability detection technology of smart contract</article-title>. <source>J. Softw.</source> <volume>33</volume> (<issue>8</issue>), <fpage>3059</fpage>&#x2013;<lpage>3085</lpage>.</citation>
</ref>
<ref id="B18">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Saheed</surname>
<given-names>Y. K.</given-names>
</name>
<name>
<surname>Abiodun</surname>
<given-names>A. I.</given-names>
</name>
<name>
<surname>Misra</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Kristiansen Holone</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Colomo-Palacios</surname>
<given-names>R.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>A machine learning-based intrusion detection for detecting internet of things network attacks</article-title>. <source>Alexandria Eng. J.</source> <volume>61</volume> (<issue>12</issue>), <fpage>9395</fpage>&#x2013;<lpage>9409</lpage>. <pub-id pub-id-type="doi">10.1016/j.aej.2022.02.063</pub-id>
</citation>
</ref>
<ref id="B19">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Santoso</surname>
<given-names>M. H.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Application of association rule method using apriori algorithm to find sales patterns case study of indomaret tanjung anom</article-title>. <source>Brill. Res. Artif. Intell.</source> <volume>1</volume> (<issue>2</issue>), <fpage>54</fpage>&#x2013;<lpage>66</lpage>. <pub-id pub-id-type="doi">10.47709/brilliance.v1i2.1228</pub-id>
</citation>
</ref>
<ref id="B20">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Shao</surname>
<given-names>H.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Research on reliability technology of civil aviation communication network</article-title>. <source>Electron. Commun. Comput. Sci.</source> <volume>6</volume> (<issue>4</issue>), <fpage>163</fpage>&#x2013;<lpage>165</lpage>.</citation>
</ref>
<ref id="B21">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Shijie</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Lu</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Du</surname>
<given-names>D.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Review of network intrusion detection technology</article-title>. <source>Chin. J. Inf. Secur.</source> <volume>5</volume> (<issue>4</issue>), <fpage>96</fpage>&#x2013;<lpage>122</lpage>.</citation>
</ref>
<ref id="B22">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Shiyu</surname>
<given-names>S. H. U.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Q.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Research on partition management mode of parts warehouse based on COI model</article-title>. <source>Logist. Eng. Manag.</source> <volume>43</volume> (<issue>3</issue>), <fpage>78</fpage>&#x2013;<lpage>80</lpage>.</citation>
</ref>
<ref id="B23">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Wenwu</surname>
<given-names>Yu</given-names>
</name>
<name>
<surname>Qian</surname>
<given-names>X. U.</given-names>
</name>
<name>
<surname>Lei</surname>
<given-names>W.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Smart distribution grid information system and distributed energy storage planning method based on distributed architecture</article-title>. <source>Sci. CHINA Technol. Sci.</source> <volume>50</volume> (<issue>6</issue>), <fpage>811</fpage>&#x2013;<lpage>818</lpage>.</citation>
</ref>
<ref id="B24">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Wu</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Rong</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Data encryption technology in computer network information security</article-title>. <source>Eng. Technol. Innovation Dev.</source> <volume>1</volume> (<issue>1</issue>), <fpage>174</fpage>&#x2013;<lpage>176</lpage>.</citation>
</ref>
<ref id="B25">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Wu</surname>
<given-names>N. A. N.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>R. U.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Z. E. M.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Quality data control of whole process of model project based on blockchain perspective</article-title>. <source>Eng. Manag.</source> <volume>5</volume> (<issue>9</issue>), <fpage>86</fpage>&#x2013;<lpage>88</lpage>.</citation>
</ref>
<ref id="B26">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Xiaoqing</surname>
<given-names>C.</given-names>
</name>
<name>
<surname>Yao</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Liang</surname>
<given-names>Z.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Blockchain principles and core technologies</article-title>. <source>Chin. J. Comput.</source> <volume>44</volume> (<issue>1</issue>), <fpage>84</fpage>&#x2013;<lpage>131</lpage>.</citation>
</ref>
<ref id="B27">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Xiaoyi</surname>
<given-names>H. U.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>R.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Review on the development of model-based security and reliability analysis techniques for complex systems</article-title>. <source>J. Aeronautics Astronautics</source> <volume>41</volume> (<issue>6</issue>), <fpage>140</fpage>&#x2013;<lpage>151</lpage>.</citation>
</ref>
<ref id="B28">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yang</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Wan</surname>
<given-names>W.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Blockchain consensus mechanism for heterogeneous identity alliance risk assessment model</article-title>. <source>J. Appl. Sci.</source> <volume>40</volume> (<issue>4</issue>), <fpage>681</fpage>&#x2013;<lpage>694</lpage>.</citation>
</ref>
<ref id="B29">
<citation citation-type="journal">
<collab>YANG Jun</collab> (<year>2022</year>). <article-title>Analysis and scheme design of information system disaster recovery technology</article-title>. <source>Railw. Comput. Appl.</source> <volume>31</volume> (<issue>8</issue>), <fpage>52</fpage>&#x2013;<lpage>56</lpage>.</citation>
</ref>
<ref id="B30">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yanzhe</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Zhu</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Analysis of applicable conditions of distributed hash table in big data scenario of internet of things</article-title>. <source>Chin. J. Comput.</source> <volume>44</volume> (<issue>8</issue>), <fpage>1679</fpage>&#x2013;<lpage>1695</lpage>.</citation>
</ref>
<ref id="B31">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yao</surname>
<given-names>Y.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Research on data security sharing methods of enterprise fintech from the perspective of blockchain technology</article-title>. <source>J. Int. Econ. and Manag.</source> <volume>4</volume> (<issue>5</issue>), <fpage>112</fpage>&#x2013;<lpage>114</lpage>.</citation>
</ref>
<ref id="B32">
<citation citation-type="journal">
<collab>YU Mingzhou</collab> (<year>2024</year>). <article-title>Analysis on the effective application of transmission technology in information and communication engineering</article-title>. <source>Smart City Appl.</source> <volume>7</volume> (<issue>7</issue>), <fpage>44</fpage>&#x2013;<lpage>46</lpage>.</citation>
</ref>
<ref id="B33">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zhang</surname>
<given-names>ming.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Centralized IT O&#x26;M information retrieval algorithm based on bayesian network</article-title>. <source>J. Jilin Univ. Inf. Sci. Ed.</source> <volume>39</volume> (<issue>5</issue>), <fpage>576</fpage>&#x2013;<lpage>582</lpage>.</citation>
</ref>
<ref id="B34">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zhang</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Feature selection algorithm for dynamic weighted conditional mutual information</article-title>. <source>J. Electron. and Inf. Technol.</source> <volume>43</volume> (<issue>10</issue>), <fpage>3028</fpage>&#x2013;<lpage>3034</lpage>.</citation>
</ref>
<ref id="B35">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zheng</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Secure cloud storage system based on merkle tree</article-title>. <source>J. Comput. Syst. Appl.</source> <volume>31</volume> (<issue>4</issue>), <fpage>81</fpage>&#x2013;<lpage>90</lpage>.</citation>
</ref>
<ref id="B36">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zheng</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Xu</surname>
<given-names>Q.</given-names>
</name>
<name>
<surname>Xiaofeng</surname>
<given-names>F.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Research on short-term load forecasting based on hierarchical clustering algorithm and ISA-LSSVM</article-title>. <source>Electr. Power Demand Side Manag.</source> <volume>24</volume> (<issue>5</issue>), <fpage>51</fpage>&#x2013;<lpage>57</lpage>.</citation>
</ref>
</ref-list>
</back>
</article>