Blockchain system architecture, management method, electronic device and readable storage medium

Abstract

The application is suitable for the field of blockchain technology, and provides a blockchain system architecture, a management method, an electronic device and a readable storage medium. The system architecture comprises a blockchain management system, a data management system, a main chain group and a sub-chain group. The blockchain management system is used for managing the creation and deployment of the main chain group and the sub-chain group. The data management system is used for acquiring block data of the sub-chain group, analyzing the block data, and feeding back the analysis result to the block management system. The main chain group is used for accessing the sub-chain group and synchronizing transaction information of the sub-chain group. The sub-chain group is used for processing the transaction information and providing the block data to the data management system. Through the embodiment of the application, large-scale blockchain infrastructure construction can be supported, the difficulty of data analysis can be reduced, the performance of the overall architecture of the blockchain can be improved, the flexibility of the blockchain construction is high, and the overall chain group of the blockchain can be comprehensively supervised.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to blockchain system architecture, management methods, electronic devices and readable storage media. Background Technology

[0002] As an infrastructure, blockchain can be divided into small private chains, medium-sized multi-institutional consortium chains, and large public chain architectures according to its application scope. However, public chain architectures are not suitable for the expansion and management of blockchain architectures in higher-level application scenarios.

[0003] Currently, blockchain architectures mainly include single-chain architecture or master-slave chain architecture. Due to the limitations of the blockchain's performance in single-chain architecture, data analysis in master-slave chain architecture is more difficult, thus failing to support the construction of blockchain infrastructure for large-scale application scenarios. Summary of the Invention

[0004] The purpose of this application is to provide a blockchain system architecture, management method, electronic device, and readable storage medium, which can solve the problems that single-chain architecture blockchains are limited by the performance of the blockchain itself, and the data analysis in master-slave chain architecture is difficult, thus making it impossible to support the construction of blockchain infrastructure for large-scale application scenarios.

[0005] In a first aspect, embodiments of this application provide a blockchain system architecture, which includes: a blockchain management system, a data management system, a main chain group, and a sub-chain group.

[0006] The blockchain management system is used to manage the creation and deployment of the main chain group and the sub-chain group;

[0007] The data management system is used to acquire block data of the sub-chain group, parse the block data, and send the parsing results back to the block management system.

[0008] The main chain group is used to access the sub-chain group and synchronize the transaction information of the sub-chain group;

[0009] The subchain group is used to process the transaction information and provide the block data to the data management system.

[0010] In one possible implementation of the first aspect, the blockchain management system includes a main chain management unit;

[0011] The main chain management unit is used to manage the creation cycle, built-in contracts, and namespaces of the main chains in the main chain group;

[0012] The main chain management unit is also used to analyze the parsing results fed back by the data management system and display the topology of the sub-chain and the transaction information;

[0013] The main chain group is used to divide the main chain into partitions corresponding to the namespace, and the partitions correspond to the transaction information of the sub-chains in the sub-chain group;

[0014] The main chain group is also used to deploy the built-in contract corresponding to the partition according to the namespace. The built-in contract includes the registration management contract of the sub-chain and the business synchronization contract of the sub-chain.

[0015] The main chain management unit is also used to perform visual management of the main chain group based on the creation and deployment information of the main chain group.

[0016] In one possible implementation of the first aspect, the system architecture further includes a front-end gateway, and the blockchain management system further includes a sub-chain management unit;

[0017] The sub-chain management unit is also used to send registered sub-chain transactions to the main chain group through the front-end gateway;

[0018] The front-end gateway is used to forward the registered sub-chain transactions to the main chain group, and after receiving the transaction results from the main chain group, forward the transaction results to the sub-chain management unit.

[0019] The subchain management unit is also used to receive the transaction result forwarded by the front-end gateway, and the transaction result is used to indicate that the subchain registration was successful.

[0020] In one possible implementation of the first aspect, the sub-chain management unit is further configured to obtain the contract address of the built-in contract, the gateway address of the front-end gateway, the space name of the namespace, and the access password for joining the main chain group.

[0021] The subchain management unit is also used to send the registered subchain transaction to the contract address corresponding to the space name in the main chain group based on the gateway address and the access password.

[0022] In one possible implementation of the first aspect, the data management system is further configured to acquire and parse block data corresponding to the transaction information in the sub-chain group based on the transaction information of the sub-chain group, perform structured processing on the parsed block data, and feed back the structured parsing result to the blockchain management system.

[0023] The main chain management unit is also used to perform visual management of the sub-chain group based on the parsing results after structured processing.

[0024] Secondly, embodiments of this application provide a blockchain management method applied to a blockchain system architecture, the method comprising:

[0025] The sub-chain group synchronizes transaction information with the main chain group by connecting to the main chain group; and provides the block data corresponding to the transaction information to the data management system.

[0026] The main chain group receives the access of the sub-chain group and obtains the transaction information synchronized by the sub-chain group;

[0027] The data management system obtains the block data of the sub-chain group, parses the block data, and sends the parsing results back to the blockchain management system;

[0028] The blockchain management system deploys and manages the main chain group and the sub-chain group based on the creation information of the main chain and the sub-chain, and performs visual management of the sub-chain group based on the received parsing results.

[0029] Thirdly, embodiments of this application provide a blockchain management method applied to a blockchain management system, the method comprising:

[0030] Create and deploy the main chain group and sub-chain group;

[0031] The system receives the parsing results from the data management system. The parsing results are obtained by the data management system parsing the block data sent by the sub-chain group. The block data is the data corresponding to the transaction information of the sub-chain group.

[0032] Based on the analysis results, the subchain group is managed visually.

[0033] Fourthly, embodiments of this application provide a blockchain management method applied to a data management system, the method comprising:

[0034] Obtain block data of the sub-chain group, wherein the block data is data corresponding to the transaction information of the sub-chain group;

[0035] The block data is parsed to obtain the parsing result;

[0036] The parsing result is sent to the blockchain management system, and the parsing result is used to instruct the blockchain management system to perform visual management of the sub-chain group.

[0037] Fifthly, embodiments of this application provide a blockchain management device, which includes:

[0038] The transmission unit is used to synchronize transaction information from the main chain group to the main chain group by connecting the sub-chain group; and to provide block data corresponding to the transaction information to the data management system.

[0039] A synchronization unit is used for the main chain group to receive the access of the sub-chain group and to obtain the transaction information synchronized by the sub-chain group;

[0040] The processing unit is used to obtain the block data of the sub-chain group from the data management system, parse the block data, and feed back the parsing results to the blockchain management system;

[0041] The management unit is used by the blockchain management system to deploy and manage the main chain group and the sub-chain group based on the creation information of the main chain and the sub-chain, and to perform visual management of the sub-chain group based on the received parsing results.

[0042] Sixthly, embodiments of this application provide a blockchain management device, the device comprising:

[0043] Create deployment units for creating and deploying the main chain group and sub-chain groups;

[0044] The receiving unit is used to receive the parsing results fed back by the data management system. The parsing results are obtained by the data management system parsing the block data sent by the sub-chain group. The block data is data corresponding to the transaction information of the sub-chain group.

[0045] A visualization management unit is used to perform visualization management of the subchain group based on the analysis results.

[0046] Seventhly, embodiments of this application provide a blockchain management device applied to a data management system. The device includes:

[0047] The acquisition unit is used to acquire block data of the sub-chain group, wherein the block data is data corresponding to the transaction information of the sub-chain group;

[0048] The parsing unit is used to parse the block data and obtain the parsing result;

[0049] A transmission unit is used to send the parsing result to the blockchain management system, the parsing result being used to instruct the blockchain management system to perform visual management of the sub-chain group.

[0050] Eighthly, embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the third or fourth aspect.

[0051] Ninthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the third or fourth aspect.

[0052] In a tenth aspect, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in any one of the third or fourth aspects above.

[0053] It is understood that the beneficial effects of the second to tenth aspects mentioned above can be found in the relevant descriptions in the first aspect, and will not be repeated here.

[0054] The beneficial effects of this application compared to existing technologies are as follows: The blockchain system architecture provided by the embodiments of this application includes a blockchain management system, a data management system, a main chain group, and a sub-chain group; the blockchain management system is used to manage the creation and deployment of the main chain group and the sub-chain group; the data management system is used to acquire block data of the sub-chain group, parse the block data, and feed back the parsing results to the block management system; the main chain group is used to create a main chain, connect to the sub-chain group, and synchronize the transaction information of the sub-chain group; the sub-chain group is used to create sub-chains, process the transaction information, and provide the block data to the data management system; it can support the construction of large-scale blockchain infrastructure, reduce the difficulty of data analysis, improve the performance of the overall blockchain architecture, has high flexibility in blockchain construction, and can comprehensively supervise the entire blockchain group; it has strong ease of use and practicality. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is a schematic diagram of the blockchain system architecture provided in the embodiments of this application;

[0057] Figure 2 This is a schematic diagram of the namespace provided in the embodiments of this application;

[0058] Figure 3 This is a flowchart illustrating the BDMS monitoring block provided in an embodiment of this application;

[0059] Figure 4 This is a schematic diagram of the external process of module interaction in the system architecture provided in the embodiments of this application;

[0060] Figure 5 This is a schematic diagram of the internal flow of system interaction provided in the embodiments of this application;

[0061] Figure 6This is a flowchart illustrating the blockchain management method provided in an embodiment of this application;

[0062] Figure 7 This is a flowchart illustrating the blockchain management method provided in an embodiment of this application;

[0063] Figure 8 This is a flowchart illustrating the blockchain management method provided in an embodiment of this application;

[0064] Figure 9 This is a schematic diagram of the blockchain management device provided in the embodiments of this application;

[0065] Figure 10 This is a schematic diagram of the blockchain management device provided in the embodiments of this application;

[0066] Figure 11 This is a schematic diagram of the blockchain management device provided in the embodiments of this application;

[0067] Figure 12 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0068] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0069] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0070] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0071] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "once detected [the described condition or event]," or "in response to the detection of [the described condition or event]."

[0072] Furthermore, in the description of this application and the claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0073] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in some other embodiments," "in other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0074] As an infrastructure, blockchain can be categorized based on its application scope into small-scale private chains, medium-sized multi-institutional consortium chains, and large-scale public chain architectures. Public chain architectures are not suitable for city-level, provincial-level, or even national-level blockchain construction. For example, city chains, or city-level blockchain infrastructure, are typically built under the unified planning of provinces, autonomous regions, municipalities, or prefecture-level cities, providing unified blockchain services to multiple levels of administrative units within the administrative region. To meet this overall trend and requirement of "intensive construction," a "new type of infrastructure" needs to be proposed. At the application level, government regulatory departments can build the main chain, maintaining the sub-chain structure, supervision, and business data, ensuring basic services such as digital identity management and cross-chain functionality. Business sub-chains built by specific industries need to be registered on the main chain, providing specific applications such as supply chain traceability and digital commodity trading within the industry.

[0075] Current blockchain architectures have several drawbacks: First, they cannot support large-scale blockchain businesses: Traditional single-chain architectures are limited by the performance of the blockchain itself and cannot support large-scale blockchain infrastructure construction at the city level. Second, data analysis is difficult, and excessive redundancy leads to performance degradation: Current multi-chain models are mainly based on a "master-slave" architecture, where the master chain is responsible for data verification and storage, and slave chains are responsible for specific business operations. Each slave chain belongs to a different namespace and corresponds to a set of business ledgers. Currently, the master chain stores "master-slave" structure information, as well as business data from all slave chains, and each slave chain itself stores all business data. Therefore, the current "master-slave" architecture is not only data-redundant and complex, but also cannot be subdivided according to business, resulting in extremely high data complexity and a significant increase in analysis difficulty. As the number of slave chains increases, the consensus capability of the master chain decreases, causing the business operations of the slave chains to be affected by the performance of the master chain, ultimately leading to a decrease in the overall performance of the blockchain cluster. Third, it does not support heterogeneous chain integration: The current "master-slave" architecture only supports slave chains using different consensus mechanisms, and cannot support the use of other blockchain underlying layers. For example, taking Hyperchain as an example, it can support slave chains using Hyperchain's Solo or RBFT consensus mechanisms, but it does not support slave chains using other blockchain technologies such as Fabric or BCOS. Fourth, it lacks flexibility: The current "master-slave" architecture does not support the dynamic expansion of existing slave chains. If an existing running business chain wants to become a slave chain, it cannot be connected to the master chain and must be built "from scratch," resulting in insufficient flexibility. Fifth, it lacks oversight: The master chain cannot know about key actions of slave chains such as registration, adding, deleting, and canceling nodes, as well as information such as the number and structural changes of connected sub-chains. The master chain cannot control or perceive the overall picture of the chain group. At the same time, in practical scenarios, the master chain needs to supervise the transactions of sub-chains to prevent illegal transactions. In the current "master-slave" architecture, the master chain can only verify the authenticity of data and cannot detect sensitive words in the transaction content.

[0076] To address the aforementioned shortcomings, this application provides a blockchain system architecture comprising a blockchain management system, a data management system, a main chain group, and a sub-chain group. The blockchain management system manages the creation and deployment of the main chain group and sub-chain groups. The data management system acquires and parses block data from the sub-chain groups, providing the parsing results back to the block management system. The main chain group creates the main chain, connects to the sub-chain groups, and synchronizes transaction information within the sub-chain groups. The sub-chain group creates sub-chains, processes transaction information, and provides block data to the data management system. The main chain's built-in contracts provide unified identity identification, sub-chain registration, and different business management capabilities, thereby achieving the basic capabilities of main chain supervision and cross-chain interoperability between sub-chains. This architecture offers the following advantages: First, it can support large-scale blockchain infrastructure construction similar to city-level projects, providing comprehensive main chain supervision while sub-chains run business operations, breaking through the performance limits of a single chain in city-level scenarios. Second, clear business logic: sub-chains report business data according to the main chain's namespace and business logic, avoiding data clustering on the main chain and achieving separation and isolation between business logic and the physical ledger. Furthermore, the Block Data Management System (BDMS) can be used to parse block data, enabling business data visualization on the BaaS platform. Third, flexible heterogeneous chain integration: Different heterogeneous chains can register with the main chain through the built-in sub-chain registration management contract and front-end gateway. The main chain uses BDMS to parse data from transactions, obtaining specific information about the sub-chain for management. Even if a sub-chain is running, it can still connect to the main chain without interruption, ensuring uninterrupted operation of its own business. Fourth, comprehensive main chain oversight: Sub-chain registration, node addition / deletion, and deregistration are all packaged into transactions and reported to the main chain. The main chain can then perceive the overall picture of the entire chain cluster by parsing these transactions. Simultaneously, it can monitor transactions to detect any sensitive transactions on sub-chains. Fifth, flexible architecture: The main and sub-chains are deployed separately. Sub-chains can join or leave the main / sub-chain system as needed. Running sub-chains can join the main chain system at any time. If a sub-chain wants to operate independently of the main / sub-chain system, it only needs to send a deregistration request without stopping its operation, without affecting its existing business. Joining the main chain follows the same procedure. The blockchain system architecture is highly user-friendly and practical.

[0077] The following specific examples illustrate the construction of a blockchain system architecture and the interaction modes between its modules.

[0078] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the specific architecture of the blockchain system architecture 100 provided in this application embodiment. For example... Figure 1 As shown, the system architecture 100 includes: a blockchain management system 110, a data management system 120, a main chain group 130, and a sub-chain group 140.

[0079] Among them, the blockchain management system 110 is used to manage the creation and deployment of the main chain group 130 and the sub-chain group 140.

[0080] In some embodiments, the blockchain management system 110 is referred to as BaaS (Blockchain as a Service), supporting the management of the creation and deployment of main chain group 130 and sub-chain group 140. A main chain group 130 may include multiple main chains, and a sub-chain group 140 may include multiple sub-chains. The number of main chains and sub-chains can be N and M, respectively, where N and M are positive integers. A sub-chain group 140 can connect to one main chain in a main chain group 130. The main chain and sub-chains can be homogeneous chains or heterogeneous chains.

[0081] The data management system 120 is used to obtain block data from the sub-chain group 140, parse the block data, and send the parsing results back to the blockchain management system 110.

[0082] In some embodiments, the data management system 120 is also referred to as the BDMS (Block Database Management System). When block data from the sub-chain group 140 is transmitted to the BDMS, the BDMS parses the block data and then feeds back the parsing results to the blockchain management system 110. The data management system 120 provides block retrieval and parsing capabilities and processes black-box data of block transactions, which is encrypted data. By encrypting the data, the security of transactions can be protected.

[0083] Among them, the main chain group 130 is used to receive the access of the sub-chain group 140 and synchronize the transaction information of the sub-chain group 140.

[0084] In some embodiments, the main chain group 130 is typically built by the project leader or regulator, supports the access of homogeneous or heterogeneous sub-blockchains, and has public capabilities such as built-in sub-chain registration management, unified digital identity management, and cross-chain management. It also provides basic services such as built-in sub-chain registration management, unified digital identity management, and cross-chain management to the accessed sub-chains. After the main chain group 130 accesses the sub-chain group 140, it will synchronize the transaction information of the sub-chain group 140.

[0085] Subchain group 140 is used to process transaction information and provide block data to data management system 120.

[0086] In some embodiments, the subchain group 140 may include multiple subchains, the number of which can be deployed according to the user's actual needs. Subchains can be newly created or already running. Subchains primarily carry out actual blockchain business, connect to real-world business application systems, and can use the public infrastructure services provided by the main chain, such as the main chain's digital identity management, cross-chain services, and registration management. After processing the transaction information generated in the actual blockchain business of the subchains, the subchain group 140 provides the data management system 120 with block data corresponding to the transaction information.

[0087] Through this embodiment, the cross-chain-free architecture based on the above-mentioned "main chain and sub-chain" can support the construction of large-scale blockchain infrastructure similar to city-level infrastructure, with the main chain overseeing the overall situation and the sub-chain running business, breaking through the upper limit of "single chain" performance in city-level scenarios.

[0088] The following corresponds Figure 1 This paper provides a detailed introduction to the components of the blockchain system architecture 100.

[0089] like Figure 1 As shown, the blockchain management system 110 includes a main chain BaaS (BaaS for main chain management) 112 and a sub-chain BaaS (BaaS for sub-chain management) 114. The main chain BaaS 112 includes main chain management 1122 and sub-chain management 1124. Main chain management 1122 is used for the management of the main chain, including the management of its creation cycle, built-in contracts, namespaces, and front-end gateways. It can also be used for the visual management of the creation cycle, built-in contracts, namespaces, and front-end gateways of the main chains in the main chain group 130. The main chain creation cycle is the lifecycle of the main chain, that is, the time from its creation to its deregistration. Sub-chain management 1124 is used for the management of sub-chains, including analyzing the parsing results fed back by the data management system 120 and displaying the sub-chain's topology and transaction information in a visual form. It can even push these to subscription services to achieve sensitive data alert monitoring and audit event push.

[0090] The subchain's BaaS114 can further include functions such as creating subchains, obtaining access information, applying for registration, and receiving transaction results, used to manage the creation of subchains. The subchain's BaaS114 is also used to send subchain registration transactions to the main chain group 130 through the front-end gateway and receive transaction results forwarded by the front-end gateway, which indicate successful subchain registration. Simultaneously, the subchain's BaaS114 is also used to obtain information such as the contract address of the built-in contract, the gateway address of the front-end gateway, the namespace name, and the access password for joining the main chain group 130; thus, it can send subchain registration transactions to the contract address corresponding to the namespace name in the main chain group 130 based on the gateway address and access password.

[0091] like Figure 1 As shown, the main chain group 130 includes N main chains. Main chain 1 is connected to the sub-chain group 140. Main chain 1 can include four namespaces, namely the first namespace namespace1, the second namespace namespace2, the third namespace namespace3, and the fourth namespace namespace4.

[0092] For example, namespace 1 includes the subchain structure state and the built-in subchain registration contract; namespace 2 includes the subchain 1 business and the built-in subchain business synchronization contract; namespace 3 includes the subchain 2 business and the built-in subchain business synchronization contract; and namespace 4 includes the subchain 3 business and the built-in subchain business synchronization contract. Namespace 1 receives the subchain structure state data transmitted by the front-end gateway from subchain group 140. Namespaces 2, 3, and 4 respectively receive the business data transmitted by heterogeneous subchain 1, heterogeneous subchain 2, and heterogeneous subchain 3 from subchain group 140 through the front-end gateway. Main chain group 130 transmits the block data corresponding to the transaction information transmitted by subchain group 140 through the front-end gateway to the latest block listening module in BDMS. Main chain group 130 is directly managed by main chain management 1122 in BaaS112 of the main chain. Main chain group 130 receives transaction information forwarded by subchain BaaS114 through the front-end gateway.

[0093] It should be noted that the number and type of namespaces on any main chain in the main chain cluster can be expanded or set based on actual application scenarios, and are not limited to the above example. Each main chain can also include more namespaces, and each namespace can correspond to a business sub-chain in a sub-chain cluster. This allows for the expansion of the main chain based on the main chain cluster, and the expansion of the sub-chain cluster based on the namespaces on each main chain. Simultaneously, sub-chains can report business data according to their business logic based on the namespaces of the main chain, avoiding data clustering on the main chain and achieving the separation and isolation of business logic and the physical ledger.

[0094] For example, the transaction information corresponding to the subchain group may include business data, subchain structure data, and subchain status data. Business data is the data generated when the subchain undertakes specific business, subchain structure data is the data generated when analyzing the specific structure of the subchain itself, and subchain status data is the data generated by the subchain in operation events such as registration, cancellation, adding nodes, and deleting nodes.

[0095] In some embodiments, the main chain group 130 is further used to divide the main chain into partitions corresponding to the namespace, which correspond to the transaction information of the sub-chains in the sub-chain group 140.

[0096] In some embodiments, the main chain can implement a transaction partitioning protection mechanism within the blockchain network through the namespace method. Users divide transactions according to namespaces, and achieve the effect of physical-level privacy protection by making the partitions independent and isolated.

[0097] For example, such as Figure 2 The diagram shows the structure of a namespace. The namespace name is configured by the user according to the specific business. Any four nodes can form a new namespace. Each namespace is isolated from each other and maintains its own ledger data, which is the transaction data generated during the actual transaction process recorded by the user in the ledger. Each namespace can deploy contracts with a specific theme, which is a specific business theme. Different ledgers correspond to contracts with different themes. Figure 2 Nodes 1, 2, 5, and 6 form namespace 1; nodes 3, 4, 7, and 8 form namespace 2; and nodes 2, 3, 6, and 7 form namespace 3.

[0098] There is no specific limit to the number of nodes that make up the namespace. The nodes in the main chain can also be divided and formed into corresponding namespaces according to the actual business needs of the sub-chain.

[0099] In this embodiment, ledger data in different namespaces is isolated, avoiding excessive data aggregation and facilitating business decomposition and business data parsing; subchains report business data according to the main chain's namespace and business logic, avoiding data clustering on the main chain, and achieving the separation and isolation of business logic and physical ledger.

[0100] In some embodiments, the main chain group 130 is also used to deploy built-in contracts corresponding to the partitions according to the namespace. The built-in contracts may include the main chain's built-in sub-chain registration management contract and the main chain's built-in sub-chain business synchronization contract, etc.

[0101] In some embodiments, after creating multiple namespaces, corresponding built-in contracts can be deployed in different namespaces according to supported business rules.

[0102] For example, a namespace can be created with a built-in subchain registration management contract, primarily used to manage subchain operation events. These subchain operation events mainly include registration, deregistration, adding nodes, and deleting nodes. The main chain can resolve the entire main-subchain cluster through transactions within this namespace. Alternatively, a namespace can be created with a built-in subchain business anchoring contract, also known as a built-in subchain business synchronization contract. This subchain business synchronization contract can be used to synchronize the block header data of the subchain business, or it can synchronize the block body data. To ensure the overall performance of the chain cluster, only the block header data of the subchain business can be synchronized.

[0103] like Figure 1 As shown, subchain group 140 can include M heterogeneous subchains. Heterogeneity means that the underlying logical architecture of the subchains is different from that of the main chain. The M subchains can also be homogeneous, that is, the underlying logical architecture of the subchains is the same as that of the main chain. The subchains can be homogeneous or heterogeneous, which is not limited here. Heterogeneous subchain 1, heterogeneous subchain 2, and heterogeneous subchain 3 each have a namespace 1 internally, and the specific business logic is placed in namespace 1. Externally, each subchain is connected to a front-end gateway, which transmits the subchain structure state data and business data to the corresponding namespace in the main chain 1 of the main chain group 130. Subchain group 140 is directly managed by the subchain's BaaS 114, and the subchains in subchain group 140 are created by the subchain's BaaS 114. Subchain group 140 is used to process transaction information and provide block data to the data management system 120.

[0104] In some embodiments, firstly, the subchain needs to register with the main chain, i.e., register the subchain: the subchain can send a registration request to the built-in contract (subchain registration management contract) address in a specific namespace of the main chain through the front-end gateway. After the transaction is successful, the subchain is successfully registered. Subsequent operation events of the subchain will be sent to the main chain through the front-end gateway, such as deregistering the subchain, adding nodes, deleting nodes, etc. Secondly, the subchain needs to synchronize transaction information with the main chain, i.e., business synchronization: this mainly involves the built-in subchain business synchronization contract of the main chain. The block header data of the specific business of the subchain can be synchronized with its own business data to the main chain through the front-end gateway.

[0105] It should be noted that the block header data of the specific business of the subchain can be synchronized to the main chain through the front-end gateway. The built-in subchain business synchronization contract can not only synchronize business data, but also solve the problem of heterogeneity between the main chain and the subchain. By using the contract to unify the logic, the differences caused by different underlying layers are eliminated, thereby achieving the goal of unification. The subchain only needs to send the transaction encapsulated with business data to the contract address in the specific namespace according to the specific structure.

[0106] The subchain processes the business data, its own structural data, and status data generated during the actual business operation, and then provides this data to the data management system 120. However, the subchain does not provide the above data directly to the data management system 120, but provides it through the main chain group 130.

[0107] Through this embodiment, different heterogeneous chains can register with the main chain through the built-in sub-chain registration management contract and front-end gateway. The main chain uses BDMS to parse the data in the transactions to obtain the specific information of the sub-chain and manage it. Even if the sub-chain is running, it can connect to the main chain without interruption and without affecting the operation of the sub-chain's own business.

[0108] like Figure 1 As shown, the blockchain system architecture 100 also includes a front-end gateway, each of which is connected to the corresponding heterogeneous sub-chain and the main chain group 130.

[0109] In some embodiments, the number of front-end gateways is determined by the number of sub-chains; the number of front-end gateways corresponds to the number of sub-chains. A front-end gateway, also known as an internetwork connector or protocol converter, is a transaction forwarding middleware. If a server is likened to a room, then the gateway is like a door, primarily used to transmit client data to the server for processing.

[0110] The following corresponds Figure 1 and Figure 3 This paper provides a detailed introduction to the key processes of the Data Management System (BDMS) 120 monitoring block.

[0111] like Figure 1 As shown, BDMS includes a module for monitoring the latest blocks and a module for parsing block information. The module for monitoring the latest blocks is used to pull block data corresponding to the namespace on the main chain in the main chain group 130. The module for parsing block information is used to parse the block data pulled by the module for monitoring the latest blocks, and then transmit the parsed data to the main chain management 1122 in BaaS112 of the main chain. Parsing block information mainly involves parsing the specific contract data in actual transactions through a parsing model. The specific contract data includes sub-chain registration management contract data and sub-chain business synchronization contract data. After the data parsing is completed, the data is processed according to the defined data processing rules, and finally the processed data is pushed to the main chain management 1122 in BaaS112 of the main chain, where the main chain management 1122 in BaaS112 performs data analysis.

[0112] like Figure 3As shown, the key process of BDMS listening to blocks is as follows: First, BDMS obtains the latest block height; second, the main chain or sub-chain returns the current block height (max); third, BDMS pulls the block; fourth, the main chain or sub-chain returns the block; fifth, BDMS listens for the latest block; sixth, it pulls block information based on the latest block height; seventh, the main chain or sub-chain returns the block information; eighth, BDMS parses the block and updates its local block height. The above process can be summarized as follows: After the main chain connects to BDMS, it starts pulling blocks from the chain starting from block 0 until the latest block on the chain matches the locally processed block height. Then, BDMS starts its block listening logic. When block data is generated on the chain, BDMS will detect this information, first starting the block pulling process, then parsing the block data and updating the local block height, and then starting the next round of listening, thus repeating the cycle.

[0113] The block height is the identifier of a block. A block has two identifiers: the hash value of the block header and the block height. The hash value of the block header is a number obtained by performing a secondary hash calculation on the block header using the SHA256 algorithm. The block hash value can uniquely and clearly "identify" a block, and any node can independently obtain the block hash value by simply hashing the block header. The block height refers to the block's position in the blockchain, not its unique "identifier." While a single block always has a definite and fixed block height, the reverse is not true; a block height does not always identify a single block. Two or more blocks may have the same block height, vying for the same position in the blockchain.

[0114] This embodiment allows us to detect whether there are sensitive transactions in a subchain by monitoring transactions, and if sensitive information is detected, it can be processed in a timely manner.

[0115] The following corresponds Figure 4 This paper provides a detailed introduction to the interaction process between modules in a blockchain system architecture.

[0116] First, create the main chain: Create a main chain through the BaaS of the main chain. After successful creation, the pre-set built-in contracts will be automatically deployed, such as the sub-chain registration management contract. In order for the sub-chain to connect to the main chain for registration, a front-end gateway also needs to be deployed.

[0117] Secondly, the subchain obtains access information: The subchain needs to obtain relevant information about the main chain's creation of the front-end gateway, including: the contract address of the built-in contract, the gateway address of the front-end gateway, the namespace name, and the access password for joining the main chain.

[0118] Secondly, automatic subchain registration: If a subchain is newly created and has been successfully registered to the main chain, it will run specific business operations and generate on-chain transactions after successful registration. If a subchain is already running and needs to join the main chain / subchain system, it needs to register its operation events with the main chain. The external process for automatic subchain registration via BaaS is as follows: First, create the subchain. After successful creation, a registration event will be automatically triggered, and a transaction will be automatically initiated with the main chain. This transaction will be sent to the contract address in a specific namespace on the main chain through a front-end gateway. Second, obtain relevant information about the creation of the front-end gateway, including: the contract address of the built-in contract, the gateway address of the front-end gateway, the namespace name, and the access password for joining the main chain group 130. The obtained built-in contract address is mainly the contract address of the subchain's registration management contract. The namespace name is determined by the specific transaction. The obtained access password for joining the main chain group 130 is the Access password used for authentication. The Key (AK) is crucial for a subchain to connect to the main chain. Without this key, even if the contract address of the built-in contract, the gateway address of the front-end gateway, and the namespace name are obtained, the subchain cannot connect to the main chain. The third step is to apply for registration as a subchain with the main chain. The fourth step is to forward transaction information to the main chain through the front-end gateway. The fifth step is for the main chain to register the subchain's operation events, which are then recorded as transactions on the chain. The sixth step is to receive feedback on the call results through the front-end gateway. The seventh step is to receive the successful registration result. The eighth step is to send a creation success message to the subchain.

[0119] The internal process of automatic subchain registration is as follows: Figure 5As shown (dashed arrows represent logical data flow, solid arrows represent actual call relationships): First, deploy the main chain: The sub-chain's BaaS sends a deployment command to the "Chain Driver" through the "Core Service," instructing the "Chain Driver" to deploy the sub-chain and nodes; Second, register event reporting: After the sub-chain's BaaS's "Core Service" confirms the successful deployment of the sub-chain and nodes, it converts the deployment event into registration information, encapsulates it into a transaction, and forwards the transaction to the main chain through the front-end gateway. Specifically, the sub-chain's BaaS's "Chain Driver" reports the status of the deployed chain and nodes to the sub-chain's BaaS's "Core Service." The "Status Reporting Processing" in the "Core Service" processes the status of the chain and nodes. The status report is sent to the "Status Interceptor" in the "Core Services". The "Status Interceptor" determines whether to intercept the status report. If the subchain no longer needs to register with the main chain, the "Status Interceptor" will intercept the status report. If the subchain still needs to register with the main chain, the "Status Interceptor" will not intercept the status report. Then, the "Status Interceptor" reports the status to the "Event Handling" in the "Core Services". The "Event Handling" reports the status to the subchain's BaaS "Front Gateway Driver". The "Front Gateway Driver" calls the main chain's built-in contract, and the main chain's BaaS "Front Gateway" performs authentication and forwarding. Authentication mainly uses AK (Access Authentication Key). If authentication is successful, the "front-end gateway" will report the status to the "main chain's built-in sub-chain registration management contract". The "main chain's built-in sub-chain registration management contract" connects to the "contract interface" in the "chain driver" of the main chain's BaaS. The "chain driver" of the main chain's BaaS calls the contract to the main chain. The addition, deletion and cancellation of nodes and sub-chains are all based on this logic.

[0120] Finally, the main chain and sub-chains are managed as follows: First, the main chain and sub-chain group structure and topology are obtained: After the operation events of the sub-chains are recorded as transactions on the chain, BDMS will pull blocks according to a preset time, parse the transaction information of the blocks, and simultaneously structure the parsed block data corresponding to the transaction information according to the set business analysis rules. BDMS has no restrictions on the state of the sub-chains when pulling them. Whether the sub-chain is in a state of registration, deregistration, or adding / deleting nodes, or in a state of business operation or shutdown, it can pull data. For example, it can pull data when the sub-chain applies for registration with the main chain and when the sub-chain is running specific business. The main chain's BaaS will visualize and manage the main chain group and sub-chain group using the parsed results after structured processing according to the set business analysis rules. Second, sub-chain business data reporting and supervision: The sub-chain's block data can be directly monitored through BDMS, pulled and parsed. If sensitive information is found, an alarm message will be reported to the main chain's BaaS. Alternatively, the logic of registration event reporting can be reused to package the sub-chain's business data into transactions and send them to the main chain, which will then parse them through BDMS. It can be applied according to different actual scenarios, offering high flexibility.

[0121] This embodiment supports the construction of large-scale blockchain infrastructure, similar to city-level systems. It provides comprehensive main chain oversight while sub-chains operate their business, breaking through the performance limitations of a single chain in city-level scenarios. Different heterogeneous chains can register with the main chain through built-in sub-chain registration management contracts and front-end gateways. The main chain uses BDMS to parse transaction data, obtaining specific sub-chain information for management. Even if a sub-chain is running, it can still connect to the main chain without interruption, ensuring uninterrupted operation of its own business, thus enabling flexible access for heterogeneous chains. The main and sub-chains are deployed separately, with sub-chains joining or leaving the main / sub-chain system as needed. Running sub-chains can join the main chain system at any time. To allow a sub-chain to operate independently without stopping its operation, it simply needs to send a deregistration request, without affecting its existing business. Joining the main chain follows the same procedure. Simultaneously, sub-chain registration, node addition / deletion, and deregistration actions are packaged into transactions and reported to the main chain. The main chain can then analyze these transactions to perceive the overall picture of the entire chain cluster, achieving comprehensive main chain oversight of sub-chains.

[0122] The following corresponds Figure 5 This document details the specific processes for structuring block data and visually managing the master-slave chain group.

[0123] The specific process of structuring block data is as follows: Based on the transaction information of the sub-chain group, BDMS obtains and parses the block data corresponding to the transaction information in the sub-chain group, performs structuring processing on the parsed block data, and feeds back the parsing results after structuring processing to the blockchain management system.

[0124] For example, such as Figure 5 As shown, the specific process by which BDMS acquires and parses block data from the sub-chain group and feeds back the parsing results to the main chain's BaaS is as follows: First, it acquires the block data corresponding to the transaction information in the sub-chain group transmitted by the sub-chain's BaaS; second, it parses the acquired block data according to the parsing model; third, it performs structured processing on the parsed block data according to the set business analysis rules. The structured data includes the sub-chain structure topology and sub-chain business data, etc.; finally, it transmits the processed block data to the "core service" in the main chain's BaaS.

[0125] The specific process of visual management of the main chain and sub-chains is as follows: the main chain's BaaS performs visual management of the sub-chains based on the parsing results after the above structured processing; the main chain's BaaS also performs visual management of the main chain group based on the creation and deployment information of the main chain group.

[0126] In some embodiments, the BaaS of the main chain includes a "core service" and a database (db). The "core service" includes specific business logic. Based on the structured parsing results, the "core service" and the database (db) provide visual management of the creation and deployment information of the main chain cluster and the specific structure of the sub-chain clusters.

[0127] For example, such as Figure 5 As shown, the main chain's BaaS transmits the block data corresponding to the transaction information, which has been structured according to the set business analysis rules, to the main chain's BaaS "core service." The "core service" integrates the block data according to visualization requirements and specific "business logic," and stores the integrated block data in the "database db." When a user needs to view the overall architecture of the main chain and sub-chains, the main chain's BaaS "core service" directly pulls the block data from the "database db" and presents it to the user.

[0128] This embodiment allows for the parsing of block data using BDMS, enabling the visualization of business data on the main chain's BaaS; it also allows for the monitoring of transactions to determine whether sensitive transactions exist on sub-chains.

[0129] The following corresponds Figure 4 The role of the front-end gateway will be explained in detail.

[0130] The front-end gateway is used to forward registered subchain transactions to the main chain, and after receiving the transaction results from the main chain, forwards the transaction results to the subchain's BaaS.

[0131] In some embodiments, the front-end gateway forwards transactions that apply to register as a sub-chain through the sub-chain's BaaS to the contract address in a specific namespace on the main chain. After receiving the transaction result from the main chain indicating that the main chain's built-in sub-chain registration management contract has been invoked, the front-end gateway forwards the transaction result to the sub-chain's BaaS. Subsequent sub-chain operation events, such as deregistering a sub-chain, adding a node, and deleting a node, are all sent to the main chain through the front-end gateway.

[0132] For example, such as Figure 1 and Figure 4As shown, the front-end gateway forwards transactions for registering a subchain through BaaS114 to the contract address in the specific namespace 1 on the main chain within the main chain group 130. After receiving the transaction result from the main chain group 130 indicating the invocation of the main chain's built-in subchain registration management contract, the front-end gateway forwards the transaction result to the subchain's BaaS114. Similarly, the front-end gateway forwards transactions for deregistering a subchain through BaaS114 to the contract address in the specific namespace 1 on the main chain within the main chain group 130. After receiving the transaction result from the main chain group 130 indicating the invocation of the main chain's built-in subchain registration management contract, the front-end gateway forwards the transaction result to the subchain's BaaS114. Finally, the front-end gateway forwards transactions to the specific namespace 1 on the main chain within the main chain group 130. The contract address in space1 forwards transactions for adding nodes through BaaS114 on the subchain. After receiving the transaction result from the main chain group 130 that calls the built-in subchain registration management contract of the main chain, it forwards the transaction result to BaaS114 on the subchain. The front-end gateway forwards transactions for deleting nodes through BaaS114 on the subchain to the contract address in the specific namespace namespace 1 on the main chain in the main chain group 130. After receiving the transaction result from the main chain group 130 that calls the built-in subchain registration management contract of the main chain, it forwards the transaction result to BaaS114 on the subchain.

[0133] In this embodiment, the main chain and sub-chains are deployed separately. Sub-chains can join or leave the main chain system architecture as needed. Sub-chains that are already running can join the main chain system at any time. If a sub-chain business wants to run independently of the main chain system, the main sub-chain only needs to send a request to cancel the sub-chain without stopping the system, which will not affect the existing running business of the sub-chain.

[0134] Corresponding to the blockchain system architecture 100 described in the above embodiment, Figure 6 A flowchart illustrating a blockchain management method provided in an embodiment of this application is shown. This blockchain management method is applied to a blockchain system architecture 100, and the method includes:

[0135] S801, the sub-chain group synchronizes transaction information to the main chain group by connecting to the main chain group; and provides block data corresponding to the transaction information to the data management system.

[0136] This step is implemented by the entity terminal corresponding to any node in any subchain of the subchain group.

[0137] S802, the main chain group receives the access of the sub-chain group and obtains the transaction information synchronized by the sub-chain group.

[0138] This step is implemented by the entity terminal corresponding to any node in the main chain of the main chain group.

[0139] S803, the data management system obtains the block data of the sub-chain group, parses the block data, and sends the parsing result back to the blockchain management system.

[0140] This step is implemented by the physical terminal corresponding to the data management system.

[0141] S804, the blockchain management system deploys and manages the main chain group and the sub-chain group respectively based on the creation information of the main chain and the sub-chain, and performs visual management of the sub-chain group based on the received parsing results.

[0142] This step is implemented by the physical terminal corresponding to the blockchain management system.

[0143] The specific process of the method provided in this embodiment has been described above and will not be repeated here.

[0144] The beneficial effects of the method provided in this embodiment can be found in the relevant descriptions in the embodiments of the blockchain system architecture 100 described above, and will not be repeated here.

[0145] Corresponding to the blockchain management system 102 described in the above embodiments, Figure 7 A flowchart illustrating a blockchain management method provided in an embodiment of this application is shown. This blockchain management method is applied to a blockchain management system 110, and the method includes:

[0146] S901 is used to create and deploy the main chain group and sub-chain group.

[0147] S902, Receive the parsing result fed back by the data management system. The parsing result is obtained by the data management system parsing the block data sent by the sub-chain group. The block data is the data corresponding to the transaction information of the sub-chain group.

[0148] S903, Based on the analysis results, the subchain group is managed visually.

[0149] The specific process of the method provided in this embodiment has been described above and will not be repeated here.

[0150] The beneficial effects of the method provided in this embodiment can be found in the relevant descriptions in the above-described embodiment of the blockchain management system 110, and will not be repeated here.

[0151] Corresponding to the data management system 120 described in the above embodiments, Figure 8 A flowchart illustrating a blockchain management method provided in an embodiment of this application is shown. This blockchain management method is applied to a data management system 120, and the method includes:

[0152] S101, Obtain the block data of the sub-chain group, wherein the block data is the data corresponding to the transaction information of the sub-chain group.

[0153] S102, parse the block data to obtain the parsing result.

[0154] S103, send the parsing result to the blockchain management system, the parsing result being used to instruct the blockchain management system to perform visual management of the sub-chain group.

[0155] The terminal that implements the above method can be a standalone terminal, an integrated module deployed on the BAAS side of the main chain, or a unit of an entity terminal deployed on any node in the main chain.

[0156] The specific process of the method provided in this embodiment has been described above and will not be repeated here.

[0157] The beneficial effects of the method provided in this embodiment can be found in the relevant descriptions in the above-described embodiments of the data management system 120, and will not be repeated here.

[0158] The blockchain system architecture and blockchain management method provided in this application have the following advantages: First, they can support large-scale blockchain infrastructure: the proposed "master-sub-chain" architecture design can support the construction of large-scale blockchain infrastructure similar to city-level infrastructure. The master chain oversees the entire picture, while the sub-chains run business operations, breaking through the performance ceiling of a "single chain" in city-level scenarios. Second, the business is clear: the sub-chains report business data according to the business logic based on the master chain's namespace, avoiding the master chain from storing data in clusters, achieving the separation and isolation of business logic and physical ledgers. Furthermore, they can use BDMS to parse block data, thus enabling business data visualization on BaaS. Third, they allow flexible access to heterogeneous chains: different heterogeneous chains can register with the master chain through the built-in sub-chain registration management contract and front-end gateway. The main chain uses BDMS to parse data from transactions to obtain specific information about sub-chains for management. Even if a sub-chain is running, it can still connect to the main chain without interruption, ensuring the operation of its own business. Fourth, the main chain provides comprehensive oversight: actions such as sub-chain registration, node addition / deletion, and deregistration are packaged into transactions and reported to the main chain. The main chain can perceive the overall picture of the entire chain cluster by parsing transactions and can also monitor transactions to detect whether there are any sensitive transactions in the sub-chains. Fifth, the architecture is flexible: the main and sub-chains are deployed separately. Sub-chains can join or leave the main / sub-chain system as needed. Running sub-chains can join the main chain system at any time. If a sub-chain wants to operate independently of the main / sub-chain system, it only needs to send a deregistration request without stopping its operation, without affecting the existing business of the sub-chain. Joining the main chain is the same operation.

[0159] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0160] Corresponding to the blockchain management method described in the above embodiments, Figure 9 A structural block diagram of a blockchain management device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0161] Reference Figure 9 The device includes:

[0162] Transmission unit 111 is used to synchronize transaction information to the main chain group by the sub-chain group through access to the main chain group; and to provide block data corresponding to the transaction information to the data management system.

[0163] Synchronization unit 112 is used for the main chain group to receive the access of the sub-chain group and obtain the transaction information synchronized by the sub-chain group;

[0164] The processing unit 113 is used to obtain the block data of the sub-chain group from the data management system, parse the block data, and feed back the parsing results to the blockchain management system;

[0165] The management unit 114 is used by the blockchain management system to deploy and manage the main chain group and the sub-chain group based on the creation information of the main chain and the sub-chain respectively, and to perform visual management of the sub-chain group based on the received parsing results.

[0166] Corresponding to the blockchain management method described in the above embodiments, Figure 10 A structural block diagram of a blockchain management device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0167] Reference Figure 10 The device includes:

[0168] Create deployment unit 121, which is used to create and deploy the main chain group and the sub-chain group;

[0169] The receiving unit 122 is used to receive the parsing result fed back by the data management system. The parsing result is obtained by the data management system parsing the block data sent by the sub-chain group. The block data is data corresponding to the transaction information of the sub-chain group.

[0170] The visualization management unit 123 is used to perform visualization management of the subchain group based on the analysis results.

[0171] Corresponding to the blockchain management method described in the above embodiments, Figure 11A structural block diagram of a blockchain management device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0172] Reference Figure 11 The device includes:

[0173] The acquisition unit 131 is used to acquire block data of the sub-chain group, wherein the block data is data corresponding to the transaction information of the sub-chain group;

[0174] Parsing unit 132 is used to parse the block data and obtain the parsing result;

[0175] The transmission unit 133 is used to send the parsing result to the blockchain management system, and the parsing result is used to instruct the blockchain management system to perform visual management of the sub-chain group.

[0176] Figure 12 This is a schematic diagram of the structure of an electronic device 14 provided in an embodiment of this application. Figure 12 As shown, the electronic device 14 of this embodiment includes: at least one processor 141 ( Figure 12 (Only one is shown in the diagram), memory 143, and computer program 142 stored in said memory 143 and executable on said at least one processor 141, wherein said processor 141 executes said computer program 142 to implement the steps described above in the method embodiments applied to the blockchain management system and data management system.

[0177] The electronic device 14 can be a desktop computer, laptop, handheld computer, or mobile phone, etc. The electronic device 14 may include, but is not limited to, a processor 141 and a memory 143. Those skilled in the art will understand that... Figure 12 This is merely an example of electronic device 14 and does not constitute a limitation on electronic device 14. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0178] The processor 141 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0179] In some embodiments, the memory 143 may be an internal storage unit of the electronic device 14, such as a hard disk or memory of the electronic device 14. In other embodiments, the memory 143 may be an external storage device of the electronic device 14, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 14. Furthermore, the memory 143 may include both internal and external storage units of the electronic device 14. The memory 143 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 143 can also be used to temporarily store data that has been output or will be output.

[0180] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, when implementing all or part of the processes in the methods of the above embodiments of this application, it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps described in the method embodiments applied to the blockchain management system and data management system. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include at least: any entity or device capable of carrying computer program code to a blockchain device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, such as a USB flash drive, a portable hard drive, a magnetic disk, or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable storage media cannot be electrical carrier signals or telecommunication signals.

[0181] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0182] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0183] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0184] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. The apparatus / network device embodiments described above are merely illustrative, and the division of modules or units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, and some features may be ignored. Furthermore, the indirect coupling, direct coupling, or communication connection shown or discussed may be through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0185] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0186] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A blockchain system architecture, characterized in that, include: Blockchain management system, data management system, main chain group and sub-chain group; The blockchain management system is used to manage the creation and deployment of the main chain group and the sub-chain group; The data management system is used to acquire block data of the sub-chain group, parse the block data, and send the parsing results back to the blockchain management system. The main chain group is used to access the sub-chain group and synchronize the transaction information of the sub-chain group; The subchain group is used to process the transaction information and provide the block data to the data management system; The blockchain management system includes a main chain management unit and a sub-chain management unit; the main chain management unit includes a part for main chain management and a part for sub-chain management; the main chain management part is used to manage the main chain group, and the sub-chain management part is used to manage the sub-chain group; The main chain management section of the main chain management unit is used to create the main chain, deploy built-in contracts, and bind the front-end gateway; The sub-chain management part of the main chain management unit is used to create and deploy sub-chains, and after successful deployment, encapsulate the deployment event into a transaction, send the transaction to the contract deployed on the main chain through the front-end gateway, and instruct the main chain to put the transaction that registers the sub-chain event on the chain by calling the contract deployed on the main chain; The data management module is also used to pull blocks and parse the transaction information of the subchain after the transaction of the registered subchain event is put on the chain, and transmit the transaction information to the core service in the main chain management, and integrate the transaction information and put it into the database through the core service; The data management module is also used to pull data from the database through the core service to present the structure of the main chain group and the sub-chain group; Each main chain in the main chain group includes different namespaces, and different contracts corresponding to sub-chain businesses are deployed in different namespaces to synchronize the block data of the sub-chain businesses. The subchains of the subchain group send business data and operation events to the contract address in the namespace corresponding to the subchain's business in the main chain through a front-end gateway.

2. The system architecture as described in claim 1, characterized in that, The blockchain management system includes a main chain management unit; The main chain management unit is used to manage the creation cycle, built-in contracts, and namespaces of the main chains in the main chain group; The main chain management unit is also used to analyze the parsing results fed back by the data management system and display the topology of the sub-chain and the transaction information; The main chain group is used to divide the main chain into partitions corresponding to the namespace, and the partitions correspond to the transaction information of the sub-chains in the sub-chain group; The main chain group is also used to deploy the built-in contract corresponding to the partition according to the namespace. The built-in contract includes the registration management contract of the sub-chain and the business synchronization contract of the sub-chain. The main chain management unit is also used to perform visual management of the main chain group based on the creation and deployment information of the main chain group.

3. The system architecture as described in claim 2, characterized in that, The system architecture also includes a front-end gateway, and the blockchain management system also includes a sub-chain management unit; The sub-chain management unit is used to send registration sub-chain transactions to the main chain group through the front-end gateway; The front-end gateway is used to forward the registered sub-chain transactions to the main chain group, and after receiving the transaction results from the main chain group, forward the transaction results to the sub-chain management unit. The subchain management unit is also used to receive the transaction result forwarded by the front-end gateway, and the transaction result is used to indicate that the subchain registration was successful.

4. The system architecture as described in claim 3, characterized in that, The sub-chain management unit is also used to obtain the contract address of the built-in contract, the gateway address of the front-end gateway, the space name of the namespace, and the access password for joining the main chain group; The subchain management unit is also used to send the registered subchain transaction to the contract address corresponding to the space name in the main chain group based on the gateway address and the access password.

5. The system architecture as described in claim 2, characterized in that, The data management system is also used to acquire and parse block data corresponding to the transaction information in the sub-chain group based on the transaction information of the sub-chain group, perform structured processing on the parsed block data, and feed back the structured parsing result to the blockchain management system. The main chain management unit is also used to perform visual management of the sub-chain group based on the parsing results after structured processing.

6. A blockchain management method, characterized in that, Applied to blockchain system architecture, the method includes: The sub-chain group synchronizes transaction information to the main chain group by connecting to the main chain group; and provides the data management system with block data corresponding to the transaction information. The main chain group receives the access of the sub-chain group and obtains the transaction information synchronized by the sub-chain group; The data management system obtains the block data of the sub-chain group, parses the block data, and sends the parsing results back to the blockchain management system; The blockchain management system deploys and manages the main chain group and the sub-chain group based on the creation information of the main chain and the sub-chain, and performs visual management of the sub-chain group based on the received parsing results. The blockchain management system includes a main chain management unit and a sub-chain management unit. The main chain management unit comprises a main chain management section and a sub-chain management section. The main chain management section manages the main chain group, and the sub-chain management section manages the sub-chain group. The main chain management section of the main chain management unit creates the main chain, deploys built-in contracts, and binds a front-end gateway. The sub-chain management section of the main chain management unit creates and deploys sub-chains, and after successful deployment, encapsulates the deployment event into a transaction, sends the transaction to the contract deployed on the main chain through the front-end gateway, and instructs the main chain to upload the transaction registering the sub-chain event by calling the contract deployed on the main chain. The main chain includes a data management module, which, after a transaction for a registered sub-chain event is uploaded to the chain, pulls blocks and parses the sub-chain's transaction information, transmits the transaction information to the core service in the main chain management, integrates the transaction information through the core service, and stores it in the database. The data management module also pulls data from the database through the core service to present the structure of the main chain group and the sub-chain group. Each main chain in the main chain group includes different namespaces, and different contracts corresponding to the sub-chain business are deployed within different namespaces to synchronize the block data of the sub-chain business. The sub-chains of the sub-chain group send business data and operation event transactions to the contract address in the namespace corresponding to the sub-chain business in the main chain through a front-end gateway.

7. A blockchain management method, characterized in that, Applied to a blockchain management system, the method includes: Create and deploy the main chain group and sub-chain group; The system receives the parsing results from the data management system. The parsing results are obtained by the data management system parsing the block data sent by the sub-chain group. The block data is the data corresponding to the transaction information of the sub-chain group. Based on the analysis results, the subchain group is managed visually. The blockchain management system includes a main chain management unit and a sub-chain management unit. The main chain management unit comprises a main chain management section and a sub-chain management section. The main chain management section manages the main chain group, and the sub-chain management section manages the sub-chain group. The main chain management section of the main chain management unit creates the main chain, deploys built-in contracts, and binds a front-end gateway. The sub-chain management section of the main chain management unit creates and deploys sub-chains, and after successful deployment, encapsulates the deployment event into a transaction, sends the transaction to the contract deployed on the main chain through the front-end gateway, and instructs the main chain to upload the transaction registering the sub-chain event by calling the contract deployed on the main chain. The main chain includes a data management module, which, after a transaction for a registered sub-chain event is uploaded to the chain, pulls blocks and parses the sub-chain's transaction information, transmits the transaction information to the core service in the main chain management, integrates the transaction information through the core service, and stores it in the database. The data management module also pulls data from the database through the core service to present the structure of the main chain group and the sub-chain group. Each main chain in the main chain group includes different namespaces, and different contracts corresponding to the sub-chain business are deployed within different namespaces to synchronize the block data of the sub-chain business. The sub-chains of the sub-chain group send business data and operation event transactions to the contract address in the namespace corresponding to the sub-chain business in the main chain through a front-end gateway.

8. A blockchain management method, characterized in that, Applied to a data management system, the method includes: Obtain block data of the sub-chain group, wherein the block data is data corresponding to the transaction information of the sub-chain group; The block data is parsed to obtain the parsing result; The parsing result is sent to the blockchain management system, and the parsing result is used to instruct the blockchain management system to perform visual management of the sub-chain group; The blockchain management system includes a main chain management unit and a sub-chain management unit. The main chain management unit comprises a main chain management section and a sub-chain management section. The main chain management section manages the main chain group, and the sub-chain management section manages the sub-chain group. The main chain management section of the main chain management unit creates the main chain, deploys built-in contracts, and binds a front-end gateway. The sub-chain management section of the main chain management unit creates and deploys sub-chains, and after successful deployment, encapsulates the deployment event into a transaction, sends the transaction to the main chain's deployed contract through the front-end gateway, and instructs the main chain to upload the transaction registering the sub-chain event to the chain by invoking the main chain's deployed contract. The data management module is also used to pull blocks and parse the transaction information of the sub-chain after the transaction of the registered sub-chain event is uploaded to the chain, and transmit the transaction information to the core service in the main chain management. The core service integrates the transaction information and puts it into the database. The data management module is also used to pull data from the database through the core service to present the structure of the main chain group and the sub-chain group. Each main chain in the main chain group includes different namespaces. Different contracts corresponding to the sub-chain business are deployed in different namespaces to synchronize the block data of the sub-chain business. The sub-chains of the sub-chain group send business data and operation event transactions to the contract address of the namespace corresponding to the sub-chain business in the main chain through the front-end gateway.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 7 or 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 7 or 8.

Images