A blockchain cross-chain supervision method for a publish-subscribe mode

Abstract

This invention discloses a blockchain cross-chain supervision method for a publish-subscribe model. The layered cross-chain system includes a business layer, a supervision layer, and a permissioning layer. In the business layer, business chains publish supervision data, which is subscribed to by the supervision chains in the supervision layer. A permissioned chain in the permissioning layer acts as a publish-subscribe agent and implements cross-chain behavior supervision. An oracle network between layers forwards supervision data while using BLS threshold signatures to verify the authenticity of the data. Furthermore, to avoid the centralized problems of traditional digital identity certificates, distributed digital identity technology is used for identity authentication; to reduce the storage burden on the permissioned chain, a distributed file system is used for expansion in the permissioning layer. This invention, while ensuring the authenticity and security of cross-chain data, meets the multi-party supervision needs of blockchain cross-chain supervision scenarios and improves the scalability of cross-chain supervision.

Description

Technical Field

[0001] This invention relates to a cross-chain regulatory method for blockchain based on a publish-subscribe model, specifically relating to blockchain applications and regulation, and government information management in a big data environment, and is specifically applied to the regulatory field of blockchain applications in industries such as finance, communications, energy, and logistics. Background Technology

[0002] In 2008, Satoshi Nakamoto designed and implemented an electronic cash system based on peer-to-peer networks and cryptography, marking the birth of blockchain technology. As a distributed ledger, blockchain possesses advantages such as decentralization, immutability, transparency, and traceability, thus being considered an effective means to solve the challenges of trust and reliable value transfer on the internet. Therefore, it has broad application prospects in areas such as digital currency, transaction settlement, digital government, and data services for evidence storage and anti-counterfeiting.

[0003] Currently, the nation has identified blockchain as a key area for independent innovation in core technologies. This initiative has, on the one hand, driven the rapid development of blockchain applications and research from a national strategic perspective. On the other hand, it has also made addressing blockchain regulation a pressing need for industry development. However, traditional centralized regulatory models, which rely on centralized nodes or manual oversight, reduce the scalability of the regulatory system, leading to performance bottlenecks and single points of failure. Furthermore, centralized regulatory models struggle to meet the needs of multi-party participation in regulation, resulting in a lack of transparency and openness in the regulatory process, thus affecting its fairness.

[0004] Due to the limitations of centralized regulatory models, adopting a distributed regulatory architecture has become a consensus in industry and academia. Among them, the "chain-based governance" regulatory architecture, which utilizes the inherent characteristics of blockchain technology to regulate blockchain application systems, has emerged as a novel and promising approach. Under the "chain-based governance" blockchain regulatory architecture, various heterogeneous chains can access the regulatory chain through cross-chain technology, thereby achieving distributed regulation of large-scale heterogeneous blockchain applications.

[0005] The core of the regulatory architecture is cross-chain technology. Currently, mainstream blockchain cross-chain technologies include notary mechanisms, hash locking mechanisms, relay / sidechain mechanisms, and distributed key control mechanisms. However, notary mechanisms suffer from centralization, hash locking mechanisms are only applicable to asset exchange, and relay / sidechain and distributed key control mechanisms are difficult to implement and inefficient. Most current cross-chain solutions based on these technologies focus on asset transfer and exchange between public chains and do not provide secure and efficient cross-chain data transmission services to meet the regulatory needs of blockchain applications. Therefore, designing and implementing a cross-chain regulatory method is an urgent problem to be solved in promoting the development and application of blockchain technology in my country.

[0006] To address the needs and challenges of "chain-based governance" regulatory scenarios, this invention proposes a blockchain cross-chain regulatory method oriented towards a publish-subscribe model. This method employs a "business layer publish, regulatory layer subscribe, permission layer proxy" operating model to effectively regulate business chain data, meeting the needs of many-to-many regulatory relationships in blockchain cross-chain regulatory scenarios. Furthermore, based on the above model, a cross-chain interaction protocol is designed, and security features are implemented in off-chain forwarding, cross-chain data storage, and access control, resolving the issues of centralized blockchain regulation and off-chain data authenticity protection, thus providing a guarantee for the vigorous development of blockchain applications. Summary of the Invention

[0007] This invention addresses the challenges in current blockchain application regulation. Based on an in-depth analysis of mainstream cross-chain technologies, it proposes a blockchain cross-chain regulatory method oriented towards a publish-subscribe model. This method aims to meet the demands for distributed deployment, fast and efficient cross-chain communication, and secure and reliable transmission in blockchain regulation. The solution constructs a hierarchical cross-chain regulatory system and designs a cross-chain regulatory protocol based on this system, enabling the regulatory chain to conduct data inspections of the business chain.

[0008] To achieve the above objectives, the technical solution of the present invention is as follows: a blockchain cross-chain supervision method for the publish-subscribe model, which consists of two main steps: constructing a cross-chain supervision system for the publish-subscribe model and designing a cross-chain supervision interaction protocol based on it.

[0009] S1: Construct a cross-chain regulatory system for the publish-subscribe model. This involves two steps: designing a hierarchical structure for the cross-chain regulatory system and designing a distributed cross-chain communication oracle network.

[0010] S11: Design a hierarchical structure for the cross-chain regulatory system. The hierarchical structure of the cross-chain regulatory system proposed in this method is as follows: Figure 2 As shown, the blockchain is divided into three layers: a business layer, a regulatory layer, and a licensing layer. The business layer comprises multiple business chains that record business data from different enterprises and organizations, deployed by an alliance of multiple enterprises or institutions. Data collection smart contracts are deployed on these business chains to collect on-chain blocks, transactions, business contracts, and ledger content for regulatory review by regulatory authorities. The regulatory layer comprises multiple regulatory chains responsible for regulating blockchain applications and services, deployed by an alliance of multiple regulatory agencies and units. Regulatory smart contracts are deployed on these regulatory chains to record regulatory operations by all parties within the alliance and to perform regulatory data review and upload to the chain. The licensing layer comprises a licensing chain and an off-chain distributed file system, deployed by various central authoritative departments.

[0011] S12: Design a distributed cross-chain communication oracle network. The design of a distributed cross-chain communication oracle consists of the following 6 steps.

[0012] (1) Oracle Deployment. An oracle consists of two parts: an on-chain oracle smart contract and an off-chain oracle node. The deployer is a blockchain deployment organization or unit participating in cross-chain supervision at various levels. The on-chain oracle smart contract includes a message processing contract, a data collection contract, a DID query contract, a working group contract, and a signature verification contract. The off-chain oracle node includes a contract interaction module, a network module, and a consensus signature module. The specific module structure is as follows: Figure 3 As shown.

[0013] (2) Oracle Node Registration. When a new node joins the oracle network, it needs to be authenticated and its identity information broadcast among the oracle nodes. The steps are as follows:

[0014] a) Access oracle nodes generate their own distributed digital identity (DID). The DID identifier is named according to a pre-defined unified method and uses a universally unique identifier (UUID) to ensure the DID's uniqueness across the entire network. For example... Figure 4 As shown.

[0015] b) The deployment organization generates a verifiable claim for the access node.

[0016] c) The access node sends its own DID and verifiable claim to the permissioned chain.

[0017] d) The permissioned chain first registers the access oracle node on the chain based on the received DID, and then checks the verifiable claims.

[0018] If the check passes, the relevant information in the verifiable declaration will be uploaded to the blockchain; otherwise, the oracle node registration will fail.

[0019] e) Based on the execution result of step d, return a response message to the oracle node indicating whether the access was successful or not.

[0020] f) Upon receiving the successful access message, the access oracle node then broadcasts the verifiable declaration within the oracle network.

[0021] g) After receiving the verifiable claim, other oracle nodes query the public key of the deploying organization on the permissioned blockchain and use the public key to verify the authenticity of the claim. Once verified, the new node information from the verifiable claim is added to the oracle network node information table.

[0022] (3) Oracle Node Working Group Formation. The oracle node working group consists of a fixed group of m oracle nodes, used to handle cross-chain data forwarding. The formation of the working group involves 5 steps:

[0023] a) After an oracle node registers, it will enter a pending pool managed by a permissioned blockchain. The pending pool contains n (n>

[0024] After determining the pending nodes (m), the oracle workgroup assignment request is sent to n nodes.

[0025] b) After receiving the oracle workgroup allocation request, the oracle node performs an initialization operation to generate initialization parameters in the verifiable random function ECVRF based on the elliptic curve cryptography algorithm. The symbol meanings of the specific initialization parameters are shown in Table 1.

[0026] c) The oracle node generates a random number using the DID private key and the number of times it has joined the workgroup. It then constructs a proof of the random number using the DID private key, public key, and the number of times it has joined the workgroup, as shown in Algorithm 1. The node then...

[0027] The number of times you have joined the working group and the proof of the random number are sent to the permissioned chain for verification.

[0028] Table 1. Meaning of ECVRF Symbols

[0029]

[0030]

[0031] d) The permissioned blockchain smart contract runs and verifies the random number. If it outputs a VALID, then the random number r is processed according to formula (1). i Mapping to the workgroup number space T, we obtain the workgroup number n to be joined. i The system then returns a message indicating that the node has successfully joined the workgroup. This message includes the workgroup number and the workgroup node information table. If the output is INVALID, the system returns a message indicating that the node has failed to join, instructing it to regenerate a random number.

[0032]

[0033]

[0034] e) When a node receives an access success message, the last node to join the workgroup is set as the workgroup master node and broadcasts the workgroup node information table to other workgroups.

[0035] f) If the oracle node that receives the workgroup node information table is the master node of a workgroup, then record the workgroup node information table and add the workgroup number in the table to the queue of workgroups to be activated; if it is a regular member node of a workgroup, then forward the message to the master node of its workgroup for processing.

[0036] (4) The selection of the oracle node working group involves the following three steps:

[0037] a) If a blockchain is being connected to a cross-chain regulatory system for the first time, upon successful connection, the deploying organization will query the queue of working groups to be activated and select the earliest established group of node working groups for the blockchain connection. If the blockchain is already connected to an oracle working group, the current oracle working group master node will query the queue of working groups to be activated and select the earliest established group of node working groups for the blockchain connection.

[0038] b) The selected workgroup returns its workgroup node information table to the on-chain oracle workgroup smart contract and broadcasts the message that this workgroup is enabled in the oracle network.

[0039] c) After receiving the broadcast message, other nodes remove the workgroup number from the list of workgroups to be activated.

[0040] (5) Verification of the authenticity of data from the oracle node working group. For example... Figure 5 As shown, the specific process includes the following 5 steps:

[0041] a) The permissioned blockchain acts as the key distribution center to initialize the parameters of the oracle network, setting the parameters (G1, G2, G...) as follows: T The expression G(x, e, g1, g2, p, h) is made public. Here, G1 and G2 are multiplicative cyclic groups of order p, with generators g1 and g2; e is a bilinear mapping: G1 × G2 → G(x, e, g1, g2, p, h). T ; Secure hash function: h{0,1} * →G1.

[0042] b) The oracle working group master node completes the key generation and selects the master private key M. sk =x, where x is a random number selected by the system; calculate the master public key M according to formula (2). pk Then, calculate the private and public keys for each workgroup node: randomly select a Z... P A polynomial P of order t-1 on the given surface satisfies P(0) = x. Calculate x. i =P(i), then the private key of the i-th node is The public key of the i-th node is obtained according to formula (3). Finally, the master public key M is made public within the working group. pk and the public keys of all workgroup nodes

[0043]

[0044]

[0045] c) The node working group receives cross-chain data from other node working groups. s The i-th node in the working group uses its private key according to formula (4). For cross-chain data Ds Sign to obtain σ i ; m nodes in the workgroup will broadcast their node signatures within the workgroup; each node in the workgroup will first verify the correctness of the node signatures received from the broadcast according to formula (5), and if the signature is correct, it will be recorded; when a single node receives the correct signatures of n different nodes from the broadcast, it will calculate the group signature σ according to formula (6), where λ i The calculation method is shown in formula (7). Algorithm 3 demonstrates the aggregation process of group signatures.

[0046]

[0047]

[0048]

[0049]

[0050] d) The first node to obtain the group signature σ sends cross-chain data D to the permissioned chain's signature verification smart contract. s Group signature

[0051] σ is sent simultaneously to other workgroup nodes. Once the other nodes receive and verify the group signature σ, they cease processing.

[0052]

[0053] e) On-chain signature verification smart contract verifies whether e(σ,g2) is equal to e(h(D)). s ),M pk If they are equal, then regulatory data D s

[0054] Wait for further processing; if they are not equal, terminate the data upload process and record the abnormal behavior during the upload.

[0055] (6) Dissolution of the oracle node working group. After the blockchain completes the cross-chain transfer of regulatory data, the working group master node updates the working group information table and broadcasts the dissolution message to other oracle nodes.

[0056] S2: Design a cross-chain regulatory interaction protocol for a publish-subscribe model. This protocol includes the following four steps: regulatory chain and business chain access permission, business chain data publishing, regulatory chain data subscription, and permissioned layer data push.

[0057] S21: Regulatory chain and business chain access permitting. The specific process can be divided into the following 4 steps:

[0058] (1) Connect to the blockchain to generate your own distributed digital identity (DID). For example... Figure 6As shown, the DID identifier adopts a pre-defined unified naming and uses a universally unique identifier (UUID) to ensure the uniqueness of the DID identifier across the entire network.

[0059] (2) The consortium that deploys the blockchain generates a verifiable statement for accessing the blockchain.

[0060] (3) Access the blockchain by sending its own DID and verifiable claims to the permissioned blockchain.

[0061] (4) The permissioned blockchain first checks the signature of the verifiable claim. If the check passes, the DID and related information from the verifiable claim are added to the blockchain; otherwise, blockchain access fails.

[0062] S22: Business Chain Data Publication. The business chain sends on-chain business data to the permissioned layer at specified time intervals. The specific process of data publication within each time interval can be divided into the following 6 steps:

[0063] (1) The contract interaction module of the business chain working group master node listens for on-chain events, collects on-chain events, and encapsulates the obtained data. Algorithm 4 illustrates the above process, which covers event types including: BlockEvent, FilteredBlockEvent, TransactionStatusEvent, and ChaincodeEvent.

[0064]

[0065]

[0066]

[0067] (2) Before transmitting on-chain data, the business chain completes the authorization of publishing permissions and key distribution through the permissioned chain. The specific steps are as follows:

[0068] a) The business chain oracle working group master node will retrieve the business chain identity identifier obtained from the on-chain query and a generated random number.

[0069] The L1 and timestamp are encapsulated into a message, the hash value of the message is signed using the business chain private key, and the message and signature are sent to the permissioned chain.

[0070] b) The permissioned chain queries the corresponding DID document on the chain based on the sent identifier, obtains the public key of the business chain, and checks the signature to ensure the authenticity of the business chain request.

[0071] c) After successful signature verification, the permissioned chain queries the corresponding verifiable claim to obtain detailed information about the business chain to determine whether the permissioned chain should enable the data publishing service. The permissioned chain working group master node generates a message containing the name of the permitted service, the service validity period, and two random numbers l1 and l2 encrypted using the business chain's public key. It then signs the request's hash value using the permissioned chain's private key and sends the message and signature to the business chain.

[0072] d) Upon receiving the message, the business chain working group master node verifies the signature using the permissioned chain public key and decrypts random numbers l1 and l2 using the business chain private key. Subsequently, the business chain generates a data encryption key for cross-chain encrypted transmission of business chain regulatory data within a valid timeframe. The business chain working group master node generates a response message containing the data encryption key signed with the business chain private key and random number l2, encrypts it using the permissioned chain public key, and sends it to the permissioned chain.

[0073] e) The permissioned blockchain working group master node decrypts the message using the permissioned blockchain private key, then verifies the decrypted message using the business blockchain public key to obtain the data encryption key and the random number l2. The permissioned blockchain message processing smart contract uploads the data encryption key to the blockchain and sends a confirmation message to the business blockchain.

[0074] f) Once the business chain receives the confirmation message, the business chain and the permission chain end the access authorization and key distribution process.

[0075] g) When the validity period of the business chain service expires, the data encryption key expires, and the process of step af is re-executed to perform access authorization and key distribution.

[0076] (3) The business chain oracle working group master node encapsulates the business chain digital identity, encrypted business data and signature in a message and sends it to each node of the permissioned chain working group to generate signature fragments by BLS threshold signature. See S12 (4) for specific steps.

[0077] (4) The permissioned chain receives the message and verifies its BLS aggregate signature. If the signature verification process fails, the permissioned chain sends an error code and explanation to the business chain; if the signature passes the verification, the permissioned chain sends the authorization information signed with the permissioned chain's private key and the distributed file system interface to the master node in the oracle working group. After the master node receives and verifies the authorization message successfully, it sends encrypted regulatory data to the interface.

[0078] (5) The encrypted regulatory data is uploaded to the distributed file system, and the distributed file system returns the regulatory data file identifier to the oracle working group master node.

[0079] (6) The working group master node uploads the regulatory data file identifier to the permissioned chain.

[0080] S23: Regulatory Chain Data Subscription. This step involves the regulatory chain requesting the required business data from the permissioned chain according to regulatory requirements. The process consists of two steps.

[0081] (1) Before the regulatory chain initiates a regulatory subscription, the regulatory chain oracle working group queries the verifiable business chain statements stored on the permissioned chain to determine the digital identity identifier of the business chain that needs to be regulated.

[0082] (2) The regulatory chain and the permissioned chain also need to perform subscription permission authorization and data encryption key distribution, which are divided into 3 steps:

[0083] a) The master node of the regulatory chain oracle working group encapsulates the regulatory chain digital identity identifier, the set of business chain identity identifiers that need to establish a regulatory relationship, a generated random number l1, and a timestamp into a message and sends it to the permissioned chain.

[0084] b) The permissioned chain oracle working group queries the corresponding DID document on the chain based on the sent regulatory chain identity identifier, obtains the public key of the business chain, and uses the public key to check the message signature to ensure the authenticity of the regulatory chain request.

[0085] c) After successful signature verification, the permissioned chain message processing smart contract determines, according to Algorithm 6, whether the regulatory chain is allowed to provide data subscription services to the business chain. If regulation is allowed, the on-chain regulatory relationship table is updated and a message is generated, containing the allowed business chain DID identifier, the subscription validity period, and a random number l1 encrypted using the regulatory chain's public key.

[0086] And a random number l2. The message is then sent to the regulatory chain oracle working group. If not permitted, the permissioned chain records this regulatory refusal.

[0087]

[0088] d) The regulatory blockchain oracle working group receives the message, verifies its integrity using the permissioned blockchain public key, and obtains a random number l1.

[0089] And a random number l2. Then, the random number l2 is encrypted using the permissioned chain's public key and sent to the permissioned chain.

[0090] e) The permissioned chain oracle working group receives the message and decrypts it using the permissioned chain private key. If the verification of random number l2 is successful, the data encryption key set of the business chain subscribed to by the regulatory chain will then be sent to the regulatory chain.

[0091] f) The oracle working group receives and confirms the message, stores the data encryption key set on the blockchain, and thus ends the subscription authorization and key distribution process between the custodian blockchain and the permissioned blockchain.

[0092] S24: Permission Layer Data Push. Based on the time when the business chain releases regulatory data, the permissioned chain promptly pushes the regulatory data for the current time period to the regulatory chain. This process involves five steps:

[0093] (1) The permissioned chain queries the on-chain regulatory relationship table. If the business chain has not yet subscribed to data by the regulatory chain, the subsequent steps will not be performed; if the regulatory chain is found to have subscribed to the business chain's data from the regulatory relationship table, the permissioned chain working group master node queries the business chain's regulatory data file identifier on the chain.

[0094] (2) The master node of the permissioned chain oracle working group receives the regulatory data file identifier, sends the business chain regulatory data file identifier to the distributed file system interface, and returns the regulatory data.

[0095] (3) The permissioned chain working group master node calls the on-chain working group smart contract to query the list of oracle network node working groups, and from this query, the regulatory chain oracle working group that subscribes to the business chain data, and obtains the interface information of each node in the working group.

[0096] (4) The master node of the permissioned chain working group sends regulatory data to each node of the regulatory chain working group. The regulatory chain oracle working group performs BLS threshold signature on the regulatory data. For the specific signing process, please refer to step (4) in S12.

[0097] (5) The regulatory chain receives the message containing regulatory data and verifies its BLS aggregate signature. If any step in the signature verification process fails, the regulatory chain sends an error code and explanation to the permissioned chain; if the signature passes verification, the regulatory chain unblocks the regulatory message and performs further processing.

[0098] Compared to existing technologies, the advantages of this invention are as follows: This invention proposes a cross-chain regulatory method for blockchain oriented towards "chain-based governance." Compared with current blockchain regulatory methods, the advantages of this method are:

[0099] (1) Constructing a cross-chain regulatory system oriented towards the publish-subscribe model. In the complex and ever-changing cross-chain regulatory scenarios of consortium blockchains, this system adopts a publish-subscribe model to implement cross-chain regulation, avoiding the increased system complexity and redundant cross-chain overhead caused by the traditional request-response model. In step S11, a hierarchical cross-chain regulatory system introduces a permissioned layer as a proxy to regulate cross-chain behavior, achieving efficient and controllable cross-chain regulation. In step S12, an oracle network is designed between each layer to forward cross-chain data and verify its authenticity, ensuring the security of regulatory data during the cross-chain process. Therefore, this system can achieve efficient and secure blockchain application regulation in complex and ever-changing cross-chain scenarios.

[0100] (2) Design a cross-chain regulatory interaction protocol for the publish-subscribe model. In step S21, a distributed digital identity is used as the access permission credential for the consortium link to enter the cross-chain regulatory system, avoiding the centralization problem caused by traditional digital certificate identity authentication. In step S22, the oracle working group uses an on-chain event listening mechanism to collect regulatory data and uses a threshold signature algorithm to complete the data authenticity verification. This verifies the authenticity of the regulatory data in the cross-chain process while reducing damage to the original blockchain structure. In steps S23 and S24, permissioned chain smart contracts in the permission layer are used to complete the automated matching of regulatory relationships and the recording of cross-chain behavior, enhancing the reliability of the traceability of cross-chain regulatory behavior. Attached Figure Description

[0101] Figure 1 Summary diagram of the subscription regulatory system;

[0102] Figure 2 Cross-chain regulatory architecture diagram;

[0103] Figure 3 : Schematic diagram of the oracle module structure;

[0104] Figure 4 Diagram illustrating the digital identity of oracle nodes (DID);

[0105] Figure 5 : Diagram of BLS threshold signature for workgroup nodes;

[0106] Figure 6 : Diagram illustrating blockchain-based DID digital identity;

[0107] Figure 7 Business chain architecture diagram;

[0108] Figure 8 : Chain of Control Architecture Diagram;

[0109] Figure 9 Permissioned blockchain architecture diagram;

[0110] Figure 10 Sequence diagram of the identity authentication key distribution process for the business chain and permissioned chain;

[0111] Figure 11 Sequence diagram of the permission layer on-chain index and off-chain storage process. Detailed Implementation

[0112] The technical solutions in the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the embodiments described below are merely one embodiment of the method of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the following embodiments without creative effort are within the scope of protection of the present invention.

[0113] Example 1: A blockchain cross-chain supervision method for the publish-subscribe model. The implementation process of this invention consists of two main steps: building a cross-chain supervision system for the publish-subscribe model and implementing a cross-chain supervision interaction protocol for the publish-subscribe model.

[0114] S1: Building a cross-chain regulatory system for the publish-subscribe model. This embodiment uses Hyperledger Fabric as the underlying blockchain implementation architecture to build a cross-chain regulatory system for the publish-subscribe model, and implements the system from four aspects: business layer, permission layer, regulatory layer, and oracle network.

[0115] Furthermore, the implementation process of step S1 includes the following two steps:

[0116] S11: Establish a hierarchical structure for cross-chain regulatory systems: The system architecture in this embodiment includes a business layer, a regulatory layer, and a licensing layer.

[0117] like Figure 7 As shown, a business chain is built using Hyperledger Fabric technology at the business layer. The business chain network adopts a multi-machine, multi-node deployment, including one order node and four peer nodes located in two different organizations. The order node is responsible for achieving on-chain consensus and sorting and packaging business chain transactions. Each organization contains two peer nodes, one as the master node and one as the anchor node, used for storing the ledger and installing chaincode. The organization in reality refers to an enterprise or unit related to the business. Peer nodes located in the two organizations jointly join a channel 1 to maintain a common distributed ledger, enabling multi-party sharing and secure storage of business data.

[0118] like Figure 8 As shown, a business chain is built using Hyperledger Fabric technology at the regulatory layer. The business chain network is deployed with multiple machines and nodes, including one order node and four peer nodes located in two different organizations. The order node is responsible for achieving on-chain consensus and ordering and packaging regulatory chain transactions. Each organization contains two peer nodes, one as the master node and one as the anchor node, used for storing the ledger and installing chaincode. The organization in practical terms represents a regulatory body or scope. Peer nodes located in the two organizations jointly join a channel 2 to maintain a shared distributed ledger, enabling multi-party sharing and secure storage of regulatory data.

[0119] like Figure 9As shown, a business chain is built using Hyperledger Fabric technology in the permissioned layer, with the InterPlanetary File System (IPFS) as the off-chain distributed file system. The permissioned chain network is deployed with multiple machines and nodes, including one order node and six peer nodes located in three different organizations. The order node is responsible for achieving on-chain consensus and ordering and packaging business chain transactions. Each organization contains two peer nodes, one as the master node and one as the anchor node, used for storing the ledger and installing chaincode. The organization's practical meaning is a central authority managing regulatory actions. Peer nodes located in the three organizations jointly join three channels: channel3, channel4, and channel5. Channel3 maintains a distributed ledger to record file identifiers and encryption keys for regulatory data in IPFS; channel4 maintains a distributed ledger to record distributed digital identity information; and channel5 maintains a distributed ledger to record cross-chain regulatory actions, blockchain-corresponding working groups, and other cross-chain information.

[0120] The deployment process for business chains, regulatory chains, and permissioned chains is similar. The following example uses a permissioned chain, and the specific deployment involves four steps:

[0121] (1) First, set up the environment required for the Hyperledger Fabric network, including Docker, Docker-Compose, Golang, Node.js, etc.

[0122] (2) Add an `order` node and basic node information for three organizations (Org1, Org2, and Org3) to the `crypro-config.yaml` configuration file, as shown in Table 2. Subsequently, in this embodiment, the `cryptogen` tool is used to generate encryption and signing elements such as certificates and private keys for the required nodes in the network based on the `crypro-config.yaml` configuration file. It is worth noting that in a production environment, certificates should be issued by a legitimate and officially recognized Certificate Authority (CA).

[0123] (3) Construct the basic configuration of the initial channel 3 stored in the genesis block in the configtx.yaml configuration file, as shown in Table 3. Use the configtxgen tool to generate the genesis block genesis.blcok, the channel configuration transaction channel.tx, and the organization anchor node configuration transactions Org1MSPanchor.tx, Org2MSPanchor.tx, and Org3MSPanchor.tx according to the configtx.yaml configuration file.

[0124] (4) Define the image required to start the container, the container network configuration, the environment variables required for the node, and the file mount path in the docker-compose.yaml configuration file.

[0125] Table 2. crypto-config.yaml configuration file

[0126]

[0127] Table 3 contains sections of the configtx.yaml configuration file.

[0128]

[0129] S12: Establish a distributed cross-chain communication oracle network. In this embodiment, the oracle network implementation process includes the following 6 steps:

[0130] (1) Deployment of smart contracts and oracle nodes on the oracle chain. Some functions on the oracle chain are implemented using smart contracts written in Go, including the message processing smart contract `oracleRelayCc`, the workgroup smart contract `oracleGroupCc`, the signature verification smart contract `oracleSignVerifyCc`, the data collection smart contract `dataCollectionCc`, and the digital identity query smart contract `oracleDIDQueryCc`. The calls to other oracle smart contracts in the `Invoke` function of `oracleRelayCc` are as follows:

[0131]

[0132] In this embodiment, the oracle network consists of 9 nodes, with 3 nodes each deployed by the relevant institutions of the business chain, regulatory chain, and permissioned chain. The number of nodes in the oracle node working group is set to 3. Each oracle node in the off-chain part is deployed using Docker and built using Go as the development language. It consists of a Fabric contract interaction module, a network module, and a consensus signature module. The Fabric contract interaction module uses Fabric-SDK-go to develop basic functional interfaces for communication with the blockchain, including oracleRelay for cross-chain message forwarding, dIDQuery for querying digital identities, groupCotroller for workgroup operations, and eventInvoke for invoking data publication. The contract interaction module uses IPFS-SDK-go to develop two basic functional interfaces for communication with the IPFS interplanetary file system, including addIPFS for uploading files and catIPFS for downloading files. The network module is developed based on the memberlist library, using the gossip protocol for network message propagation, implementing node discovery, node failure detection, and node list maintenance. It maintains the Oracle network node information table OracleNodeList, the Oracle network workgroup information table OracleGroupList, and the SleepGroupQueue queue for pending workgroups. OracleNodeList includes fields as shown in Table 4. OracleGroupList includes fields as shown in Table 5. The content of OracleNodeQueue is the workgroup number GroupUUID. The consensus signature module is developed based on the blast library to implement the BLS threshold signature scheme, mainly including master key generation, node key generation, signing, and aggregate signature functions.

[0133] Table 4 Oracle Network Node Information Table

[0134]

[0135] Table 5. Oracle Network Working Group Information Sheet

[0136]

[0137] (2) Oracle Node Registration. When a new node joins the regulatory system, it must complete identity authentication and broadcast its identity information among oracle nodes. The specific steps include 7 steps.

[0138] a) Oracle network nodes use the ECC algorithm to create their own digital identity (DID). node1 .

[0139] b) The organization that creates the oracle node generates a verifiable declaration VC based on the node's deployment. node1 VC nod The public key PK of the organization or unit that deployed the node org1 A signature is required to prove its authenticity.

[0140] c) The oracle node to be registered will have DID node1 and VC node1 Send to the permissioned chain.

[0141] d) After receiving the access request, the master node of the permissioned chain oracle working group calls oracleDIDQueryCc to query the on-chain digital identity information and verify the VC. node1 Whether it is by the relevant organization DID org1 Perform a signature. If the access node information is valid, then the DID will be... node1 and VC node1 Write to the permission chain.

[0142] e) After a successful write to the permissioned chain, the permissioned chain oracle working group master node will send the DID. node1 Use the private key SK of the permissioned chain pc1 Perform the signing and send the signature to the oracle node to be registered.

[0143] f) The permissioned blockchain public key PK used by the oracle node to be registered pc Verify the signature to confirm that the node has completed registration, and simultaneously set the DID. node1 The signature is used to form the payload for broadcasting.

[0144] g) After receiving the broadcast message, other oracle nodes use the permissioned blockchain public key SK pc1 Verify the authenticity of the signature. If the signature verification is successful, add the new node information to OracleNodeList; otherwise, do not perform any operation.

[0145] (3) Oracle Node Working Group Formation. The specific steps for forming the node working group are as follows:

[0146] a) After an oracle node completes registration, it first joins the WaitingPool managed by the permissioned chain. When the number of nodes in the WaitingPool reaches 3 and the OracleNodeQueue is not full, the permissioned chain's RandomAssign function sends a workgroup assignment request to the oracle nodes in the WaitingPool.

[0147] b) After receiving the allocation request, the i-th node calls the ECVRF_hash function and the ECVRF_prove function to input the private key SK. nodeiGenerate a random number r using GroupNum, which is the number of workgroups the current node has joined. i and random number declaration prove i The node will r i GroupNum and prove i Send it to the permissioned chain for verification.

[0148] c) The permissioned chain calls the ECVRF_verify function to verify the random number, inputting the PK. nodei GroupNum,prove i If the output is VALID, then r i Mapping to the workgroup number space T, we get the workgroup number n to be joined. i Returns a success message for adding the node, which contains OracleGroupList. If the output is INVALID, returns a failure message to notify the node to regenerate a random number.

[0149] d) When a node receives a successful access message and learns that there are 3 nodes in the workgroup, the workgroup is successfully formed, and the last node to join the workgroup is set as the workgroup master node (DID). master1 Using private key SK master1 The updated workgroup node information table OracleGroupList is signed, and the OracleGroupList and the signature are combined into a payload and broadcast in the oracle network.

[0150] e) If the oracle network node receiving the broadcast message is the master node of the workgroup, then it uses the public key PK of the master node that sent the broadcast. master1 Verify the signature, update the OracleGroupList, and add the GroupUUID to the SleepGroupQueue; if it is a regular member node of the workgroup, forward the message to the workgroup master node for processing.

[0151] (4) Selection of the oracle node working group. If the blockchain is being integrated into a cross-chain regulatory system for the first time, the permissioned blockchain DID will be responsible for the selection upon successful integration. pc1 Query the SleepGroupQueue to get the first group of workgroups that entered the queue, retrieve the contents of the OracleGroupList for that workgroup, and broadcast the GroupUUID of that workgroup in the oracle network. Nodes that receive this message will remove the GroupUUID from the SleepGroupQueue. If the blockchain is already connected to an oracle workgroup, the current oracle workgroup will perform the above operations before disbanding to select the next group of oracle node workgroups for the blockchain.

[0152] (5) Oracle Node Working Group Data Authenticity Verification. Before sending cross-chain data, the sending chain's oracle master node queries the gRPC interface addresses of each oracle working group node in the receiving chain's OracleGroupList. The sending chain's oracle master node then calls the OracleRelay function to send the cross-chain data to the interfaces of each oracle node in the target chain. The target chain's oracle working group uses the BLS threshold signature algorithm to generate signature shards for the cross-chain data. Each oracle working group node aggregates the signature shards to obtain a group signature σ. The first node to obtain σ uses the EventInvoke function to call the VerifyBLSSign function of oracleSignVerifyCc on the permissioned chain to verify σ.

[0153] (6) Oracle Working Group Disbandment. After the blockchain completes the cross-chain transfer of regulatory data, the oracle working group master node sends a groupDisband message to the blockchain, calls the ExpireGroup function of oracleGroupCc to make the information in the OarcleGroupList table of working group nodes on the chain expire, and at the same time, the working group master node deletes the information of this working group in the network module and broadcasts the groupDisband message to other nodes in the working group. The working group node is disbanded and re-enters the WaitingPool.

[0154] S2: Implementing a cross-chain regulatory interaction protocol for a publish-subscribe model. This embodiment implements a cross-chain regulatory interaction protocol based on the cross-chain regulatory system built in S1.

[0155] Furthermore, step S2 specifically includes the following four steps:

[0156] S21: Access Permission for the Regulatory Chain and Business Chain. In this embodiment, taking a single business chain as an example, the access permission process consists of the following four steps:

[0157] (1) The business chain uses the ECC algorithm to create its own digital identity (DID). chain DID chain This includes: DID identifier and DID document. The DID document declares attributes such as DID identifier id, public key publicKey, and service. An example of a DID document is shown in Table 6.

[0158] (2) The business chain will integrate blockchain digital identity DID chain And generate a verifiable statement VC based on specific blockchain information. chain Stored in the business chain, this includes the claim ID, claim type, issuer, issue date (issuanceDate), credentialSubject, and proof. Verifiable Claims (VC)chain Examples are shown in Table 7. The SleepGroupQueue, a queue of working groups to be enabled, allocates a group of oracle nodes to the current cross-chain operation. The master node triggers the on-chain DID query smart contract to retrieve the DID stored on the chain. chain and VC chain1 Encapsulated in the message regDIDMsg, the business chain oracle master node sends regDIDMsg to the permissioned chain's off-chain workgroup node for forwarding to the permissioned chain.

[0159] Table 6 DID Document Examples

[0160]

[0161] Table 7 Examples of DID Verifiable Claims

[0162]

[0163] (3) Permissioned chain nodes receive regDIDMsg and query the DID on the chain. org1 Public key PK org1 Use the DIDVerify function to check the DID in regDIDMsg. chain1 and VC chain The signature is verified. If the function returns true, the DID is... chai and VC chain Write it to the ledger in channel 4 of the permissioned chain.

[0164] (4) After the permission chain is successfully written, the regDIDReply message is sent to the business chain to confirm the access relationship.

[0165] S22: Business chain data publication. In this embodiment, when the business chain DID... chain After obtaining access permission, the oracle working group node can request regulatory data from the business chain at 4-hour intervals as specified in the oracle working group contract interaction module. The specific process can be divided into 6 steps;

[0166] (1) The business chain oracle working group master node triggers the EventInvoke function to call the getEvent method of Fabric-SDK-go to capture events sent from the chain, setting parameters to listen for the chaincode number ccId, transaction number txId, and event collection time eventTime. Upon receiving the call request, the business chain calls the SetEvent method to collect the four types of events on the chain, and simultaneously calls the smart contract dataCollectionCc to obtain real-time data from the current state database.

[0167] (2) The business chain working group master node encapsulates the collected events and database data into CrossData, and uses the data encryption key K to encrypt the CrossData. tc1 Encryption is performed, and the gPRC interface addresses of each node in the Permissioned Chain Working Group are obtained by querying OracleGroupList.

[0168] (3) The business chain and the permissioned chain need to perform identity authentication and key distribution. Specific steps are as follows: Figure 10 As shown.

[0169] a) The business chain working group's master node, using the DIDQuery function, initiates an on-chain query for DID to the smart contract oracleDIDQueryCc. tc1 DID tc1 An identifier, a generated random number (nonce1), and a timestamp are encapsulated in the payload using DID. tc1 The private key SK tc1 Sign the hash value of the payload. Send the payload and signature to the permissioned chain.

[0170] b) Permissioned Chain Oracle Working Group Master Node DID master1 According to the sent DID tc1 The identifier calls the smart contract oracleDIDQueryCc to perform an on-chain query for the DID. tc1 Documentation, obtain the public key PK of the business chain. tc1 Search for the corresponding VC tc Retrieve detailed information about the business chain and use the PubCheck function to determine if the business chain has data publishing permissions. Permissioned Chain Working Group Master Node DID master1 Generate a payload containing the allowed service name (ServiceName), the service validity period (ValidTime), and the public key (PK) used in the business chain. tc1 Encrypted random numbers nonce1 and nonce2. Then, the permissioned blockchain private key SK is used. pc1 Sign the hash value of the payload. Send the payload and signature to the business chain.

[0171] c) Business Chain Working Group Master Node DID master2 Received message, use permissioned blockchain public key PK pc Verify the signature and use SK tc1 Decrypt the random numbers nonce1 and nonce2 in the payload, and then generate a data encryption key K. tcThis is used for cross-chain encrypted transmission of business chain regulatory data within a valid timeframe. The business chain working group master node generates a payload containing the business chain private key SK. tc1 Signed data encryption key K tc1 And the random number nonce2, which is used to PK the payload with the permissioned blockchain public key. pc1 It is then encrypted and sent to the permission chain.

[0172] d) The permissioned blockchain working group master node uses the private key SK pc1 The payload is decrypted, and then the decrypted payload is PK'd using the business chain public key. tc1 Verification was performed to obtain the data encryption key K. tc1 And the random number nonce2. The message processing smart contract encrypts the data using the key K. tc1 It is uploaded to the blockchain, and a confirmation message is sent to the workgroup node.

[0173] e) Once the workgroup node receives the confirmation message, the process of access authorization and key distribution for the business chain and permission chain is complete.

[0174] (4) The business chain working group master node will encrypt the regulatory data, signature, and DID. tc1 The payload is composed and sent to the gPRC interface address of the permissioned chain workgroup node.

[0175] (5) The permissioned chain smart contract oracleRelayCc calls the smart contract oracleSignVerifyCc to verify the BLS group signature σ of the message. After successful verification, it sends a signVerifySucceed message to the permissioned chain oracle workgroup node of the first synthetic group signature σ.

[0176] (6) After receiving the signVerifySucceed message, the oracle working group node initiates the process of regulating the on-chain index and off-chain storage of the data chain. The specific steps are as follows: Figure 11 As shown:

[0177] a) The first synthetic group signature σ of the permissioned chain's workgroup node calls the `oracleRelay` function to send encrypted `CrossData` and the group signature σ to activate the on-chain contract `oracleSignVerifyCc` to verify σ and upload it to the chain. It then calls the `DIDQuery` function to activate the on-chain contract `oracleDIDQueryCc` to query the business chain's DID. tc Public key PK tc And the ServiceLicense that the business chain allows is sent back to the workgroup node.

[0178] b) Workgroup nodes use PKtc Verify the signature of the encrypted CrossData and check if the Servicelicense allows publication. If it does, call the addIPFS function to send the encrypted CrossData to the IPFS API interface.

[0179] c) Encrypted CrossData is uploaded to IPFS. If the size of CrossData is larger than 256kb of an IPFS object, it is hashed and sharded. The shards are then stored on different IPFS nodes. A distributed hash table stores the shard locations. Finally, IPFS returns the data file identifier CrossDataIdentifier to the permissioned chain oracle working group node.

[0180] d) The workgroup node calls the permission chain oracleRelayCc to pass the CrossDataIdentifier and the business chain DID. tc1 The identifier and timestamp (TimeStamp) are uploaded to the blockchain, and a pubSuccess message is sent to other workgroup nodes.

[0181] S23: Subscription to Chain of Supervision Data. This involves two steps:

[0182] (1) Before initiating a regulatory subscription, the main node of the regulatory chain oracle working group obtains the business chain verifiable declaration (VC). tc1 Based on relevant information in the business chain, determine the business chain DID that needs to be regulated. tc1 .

[0183] (2) The regulatory chain and the permissioned chain conduct subscription permission authorization and data key distribution, and the specific process is as follows:

[0184] a) The Chain of Supervision Oracle Working Group master node will send the Chain of Supervision DID sc1 Identifiers, business chain DIDs that require establishing regulatory relationships tc1 The operation request action encapsulates a generated random number (nonce1) and a timestamp as the payload, using DID. sc1 The private key SK sc Sign the hash value of the payload and send the payload and signature to the master node of the permissioned chain oracle working group.

[0185] b) The permissioned chain oracle working group master node determines the DID sent by the oracle. sc1 Perform an on-chain query of the corresponding DID document to obtain the public key (PK) of the regulatory chain. sc Using PK sc1 The hash value of the signature is checked to ensure the authenticity of the chain of custody request.

[0186] c) After successful signature verification, the permissioned chain oracle working group master node queries VC. sc1 And business chain VCs that need to establish regulatory relationships tc1 Call the SubCheck function of the message processing smart contract and input VC. sc1 VC tc The function, along with the action, determines whether the regulatory chain has regulatory authority over the business chain. If the function returns "deny," the operation stops, and the regulatory chain's "subDeny" message is returned. If the function returns "allow," the permissioned chain oracle working group masternode generates a payload containing the permitted business chain's DID for subscription. tc1 Subscription validity period (ValidTime) and use of the blockchain public key (PK) sc1 Two encrypted random numbers, nonce1 and nonce2, are then used. This is followed by the permissioned blockchain private key SK. pc1 Sign the hash value of the payload. Send the payload and signature to the custodian chain.

[0187] d) The custodian chain receives the message and uses the permissioned chain's public key to PK. pc Verify the signature of the payload hash value and use SK sc1 Decrypt the payload to obtain random numbers nonce1 and nonce2. The custodian blockchain message processing smart contract generates a payload containing the random number nonce2, and then uses the permissioned blockchain public key to perform a key-click operation on the payload. pc It is then encrypted and sent to the permission chain.

[0188] e) The permissioned chain receives the message and uses the private key SK pc1 Decryption is performed, and the nonce2 is successfully verified. Then, the encryption key for the data from the subscribed business chain is PK'd using the custodian chain's public key. sc1 It is then encrypted and sent to the custodian chain.

[0189] f) The regulatory chain receives and confirms the message, stores the encryption key for the subscribed business chain data on the chain, and the subscription authorization and key distribution process between the regulatory chain and the permissioned chain is completed.

[0190] S24: Permission layer data push. The specific process includes 5 steps.

[0191] (1) When the business chain CrossData is sent to the permissioned chain for publication, after the publication is successful, the permissioned chain working group master node calls the EventInvoke function to call the on-chain SupervisorQueryCc to query the regulatory relationship. If it is found that the current business chain has been subscribed to by the regulatory chain, oracleRelayCC is called to send the latest CrossDataIdentifier of the business chain to the permissioned chain working group master node.

[0192] (2) The master node of the permissioned chain working group receives the CrossDataIdentifier and calls the catIPFS function to download the corresponding encrypted CrossData through the IPFS API.

[0193] (3) The master node of the permissioned chain working group queries OracleGroupList to obtain the API of the regulatory chain working group node, and calls the OracleRelay function to send CrossData to the API of each regulatory chain oracle node.

[0194] (4) The first synthetic group signature σ’s supervisory chain workgroup node calls the EventInvoke function to activate the on-chain oracleSignVerifyCc to verify the group signature σ.

[0195] (5) After the supervisory chain verifies the validity of the aggregate signature, the supervisory chain working group node uses the corresponding business chain data encryption key K. tc1 Decrypt the CrossData and process it on the blockchain to obtain business chain regulatory data.

[0196] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1. A cross-chain regulatory method for blockchains using a publish-subscribe model, characterized in that, The method includes the following steps: S1: Construct a cross-chain regulatory system for the publish-subscribe model; S2: Design a cross-chain regulatory interaction protocol for the publish-subscribe model; Step S1: Constructing a cross-chain regulatory system for the publish-subscribe model, which consists of two steps: S11: Design a hierarchical structure for the cross-chain regulatory system; S12: Design a distributed cross-chain communication oracle network; Step S2: Design a cross-chain regulatory interaction protocol for the publish-subscribe model, which includes the following four steps: S21: Regulatory chain and business chain access permits; S22: Business chain data release; S23: Subscription to Chain of Supervision data; S24: Permission layer data push; S11: Design a hierarchical structure for the cross-chain regulatory system, specifically as follows: The hierarchical structure of the cross-chain regulatory system is divided into a business layer, a regulatory layer, and a permission layer. The business layer contains multiple business chains that record business data from different enterprise organizations. The deployers are an alliance of multiple enterprises or institutions. Data collection smart contracts are deployed on the business chains to collect on-chain blocks, transactions, business contracts, and ledger content for regulatory departments to access and review. The regulatory layer contains multiple regulatory chains that are responsible for regulating blockchain applications and services. The deployers are an alliance of multiple regulatory agencies and units. Regulatory smart contracts are deployed on the regulatory chains to record the regulatory operation records of all parties in the alliance and to execute regulatory data review and upload them to the chain. The permission layer contains a permission chain and an off-chain distributed file system. The deployers are various central authoritative departments. S12: Design a distributed cross-chain communication oracle network, as detailed below: (1) Oracle deployment; (2) Oracle node registration; (3) Establishment of the oracle node working group; (4) Selection of oracle node working groups; (5) Verification of the authenticity of data from the oracle node working group; (6) Dissolution of the oracle node working group; S21: Regulatory chain and business chain access permitting, the specific process can be divided into the following 4 steps: (1) Connect to the blockchain to generate your own distributed digital identity (DID); (2) The consortium that deploys the blockchain generates a verifiable statement for accessing the blockchain; (3) Accessing the blockchain involves sending one's own DID and verifiable claims to the permissioned blockchain; (4) The permissioned chain first checks the signature of the verifiable claim. If the check passes, the DID and related information in the verifiable claim are uploaded to the chain; otherwise, the blockchain access fails. S22: Business chain data release, details are as follows: (1) The contract interaction module of the business chain working group master node listens to on-chain events, collects on-chain events, and encapsulates the obtained data; (2) Before transmitting on-chain data, the business chain completes the authorization of publishing permissions and key distribution through the permissioned chain; (3) The business chain oracle working group master node encapsulates the business chain digital identity, encrypted business data and signature in a message and sends it to each node of the permissioned chain working group to generate signature fragments by performing BLS threshold signature. (4) The permissioned chain receives the message and verifies its BLS aggregate signature. If the signature verification process fails, the permissioned chain sends an error code and explanation to the business chain. If the signature passes the verification, the permissioned chain sends the authorization information signed with the permissioned chain's private key and the distributed file system interface to the master node in the oracle working group. After the master node receives and verifies the authorization message successfully, it sends encrypted regulatory data to the interface. (5) The encrypted regulatory data is uploaded to the distributed file system, and the distributed file system returns the regulatory data file identifier to the oracle working group master node; (6) The working group master node uploads the regulatory data file identifier to the permissioned chain; S23: Subscribing to blockchain data, the specific process consists of two steps: (1) Before the regulatory chain initiates a regulatory subscription, the regulatory chain oracle working group queries the verifiable declarations of the business chain stored on the permissioned chain to determine the digital identity identifier of the business chain that needs to be regulated. (2) The regulatory chain and the permissioned chain also need to perform subscription permission authorization and data encryption key distribution; S24: Permission Layer Data Push. The permissioned chain promptly pushes regulatory data for the current time period to the regulatory chain based on the time when the business chain releases regulatory data. The specific process consists of 5 steps: (1) The permissioned chain queries the regulatory relationship table on the chain. If the business chain has not yet subscribed to data by the regulatory chain, the subsequent steps will not be performed. If the regulatory chain is found to have subscribed to the business chain data from the regulatory relationship table, the permissioned chain working group master node queries the regulatory data file identifier of the business chain on the chain. (2) The master node of the permissioned chain oracle working group receives the regulatory data file identifier, sends the business chain regulatory data file identifier to the distributed file system interface, and returns the regulatory data; (3) The permissioned chain working group master node calls the on-chain working group smart contract to query the list of oracle network node working groups, and from this query, the regulatory chain oracle working group that subscribes to the business chain data, and obtains the interface information of each node in the working group; (4) The master node of the permissioned chain working group sends regulatory data to each node of the regulatory chain working group, and the regulatory chain oracle working group performs BLS threshold signature on the regulatory data; (5) The regulatory chain receives the message containing regulatory data and verifies its BLS aggregate signature. If any process fails during the signature verification, the regulatory chain sends an error code and explanation to the permissioned chain. If the signature passes the verification, the regulatory chain unblocks the regulatory message and performs further processing operations.

Images