A chain-oriented business chain transaction supervision method

Abstract

This invention discloses a business chain transaction supervision method oriented towards "chain-based governance," aiming to meet the scalability requirements of the regulatory chain during the supervision of business chain transactions. The invention consists of three parts: sharding-based regulatory chain construction, business chain data on-chaining, and business chain transaction verification. Sharding-based regulatory chain construction divides the regulatory chain into multiple shards, with each node within the same shard maintaining a single ledger. Business chain data on-chaining proposes a unified tagging method to distribute business chain transaction data across different shards. Business chain transaction verification completes cross-shard transaction verification by decomposing smart contracts into sub-contracts and then sequentially verifying all sub-contracts. On the one hand, this invention reduces the overhead in the process of supervising business chain transactions by employing sharding technology, improving the scalability of the regulatory chain; on the other hand, it achieves cross-shard transaction verification by decomposing smart contracts, realizing the supervision of business chain transactions on a sharding-based regulatory chain.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and applications, and government information management in a big data environment, specifically to the field of blockchain application supervision in industries such as finance, communications, energy, and logistics. Background Technology

[0002] Blockchain, originating from Bitcoin, is a novel distributed ledger technology. A blockchain ledger consists of sequentially increasing blocks linked together using hashing, and cryptographic techniques ensure its immutability. Each node on the blockchain maintains a copy of the ledger. The blockchain uses a consensus algorithm to guarantee consistency among all nodes. Consortium blockchains are a new type of blockchain technology that utilizes Certificate Authorities (CAs) to verify participant identities and employs cryptographic endorsement strategies to verify transactions, thereby increasing blockchain throughput. In recent years, blockchain technology has received increasing attention and has been widely applied. Leveraging the distributed storage and immutability of blockchain ledgers and integrating them with real-world industries has become a current development trend.

[0003] However, the widespread application of blockchain has brought regulatory challenges. Traditional centralized regulatory models not only undermine the decentralized nature of blockchain but also fail to meet the multi-party regulatory needs of various industries regarding business chains. In recent years, some researchers have argued that the inherent advantages of blockchain—decentralization, data immutability, and publicly verifiable services—are conducive to the regulation of large-scale business chains, and have proposed the concept of "governing chains with chains." Multiple regulatory agencies can jointly deploy a regulatory chain to regulate multiple business chains within an industry. Nodes on the regulatory chain can not only inspect data on the business chains but also verify completed transactions.

[0004] The concept of "chain-based governance" meets the regulatory needs of multiple parties in the industry and provides publicly verifiable regulatory services. However, the increasing number of business chains poses challenges to the long-term efficient operation of the regulatory chain. Sharding is a key technology for improving blockchain scalability, but existing research has mostly focused on increasing transaction throughput on public chains. Therefore, porting it to the regulatory chain presents two major technical challenges. First, the independence between business chains can easily lead to conflicts and uneven distribution of data shards on the regulatory chain. In public chain-based sharding schemes, data is allocated to different shards according to the prefix of the input address. Since the addresses are randomly generated, this approach can avoid conflicts and achieve data balance between shards. However, in cross-chain regulatory scenarios, data from different business chains have independent namespaces, significantly increasing the possibility of data storage conflicts on the regulatory chain and easily causing uneven distribution of data shards. Second, verifying cross-shard transactions on a sharded regulatory chain is difficult. If the data of a transaction is stored on different shards of the regulatory chain, its verification process not only needs to overcome the sharding barriers but also needs to ensure the correctness of each step in the transaction process. Some scholars have proposed deploying a public blockchain to achieve cross-shard transaction verification, but this approach suffers significant performance degradation as the number of transactions increases. Furthermore, some scholars have proposed transaction splitting methods based on the UTXO format, but these are all designed for cryptocurrency transactions on public blockchains. Before verifying a UTXO-formatted transaction, the shards involved in the transaction can be determined, and then the nodes in the relevant shards complete the verification process. However, transactions on a business blockchain require verification through the execution of smart contracts. Only when the smart contract reaches a specific step can the shards involved in the transaction be determined. Therefore, transaction splitting methods based on the UTXO format cannot be applied to scenarios involving cross-chain supervision of business blockchain transactions.

[0005] To address the aforementioned issues, this invention proposes a business chain transaction supervision method oriented towards "chain-based governance". Figure 1 This paper demonstrates a sharded-based "chain-to-chain" cross-chain regulatory scenario. By constructing a sharded regulatory chain, uploading business chain data to the chain, and verifying business chain transactions, this method solves the scalability problem faced by the regulatory chain in the regulatory process, promotes the implementation of blockchain application regulation, and fosters the healthy and orderly development of the blockchain industry. Summary of the Invention

[0006] This invention addresses the challenges of current cross-chain blockchain regulation by deeply analyzing relevant regulatory technologies and solutions. Based on this analysis, it proposes a business chain transaction regulation method oriented towards "chain-based governance." To address the poor scalability of the regulatory chain during cross-chain regulation, it proposes optimizing the regulatory chain using sharding technology. To address the data storage conflicts and uneven distribution caused by sharding, it proposes uniformly labeling all data from the business chain on the regulatory chain. To address the difficulty in verifying cross-shard transactions, it proposes decomposing smart contracts into sub-contracts for sequential verification. This invention reduces computational, communication, and storage overhead during the regulation of business chain transactions by employing sharding technology, thus improving the scalability of the regulatory chain. It uses smart contract-based transaction verification technology to verify transactions within a shard and verifies cross-shard transactions by decomposing smart contracts, thereby achieving regulatory functionality for business chain transactions on a shard-based regulatory chain. In summary, this method consists of three main steps: constructing a shard-based regulatory chain, uploading business chain data to the chain, and verifying business chain transactions.

[0007] S1: Construction of a Sharded Regulatory Chain. To meet the need for simultaneous supervision of multiple business chains within the industry, a regulatory chain consisting of multiple shards is constructed. The specific process can be divided into the following three steps: regulatory chain construction, regulatory chain node sharding, and designing regulatory applications and shard interaction functions.

[0008] S11: Building the Regulatory Chain. Before implementing cross-chain supervision of business chain transactions, a regulatory chain needs to be built. This step completes the identification of the regulatory organization, regulatory chain nodes and members, the construction of the regulatory chain network, and related initialization work. The specific process can be divided into the following 6 steps:

[0009] (1) Establishing the identities of the regulatory organizations. The chain of supervision is jointly constructed by multiple regulatory organizations. When constructing the chain of supervision, it is necessary to first establish the identities of all regulatory organizations. First, a recognized Certificate Authority (CA) is identified. Then, each regulatory organization generates a public-private key pair locally and sends a certificate issuance request to the CA. Finally, the CA completes the registration of each organization's identity and issues a public key certificate to it.

[0010] (2) Construct the CA of the regulatory organization. Each regulatory organization uses the certificate obtained in step (1) to construct its own CA.

[0011] (3) Establishing the identities of chain of supervision nodes and supervisory members. First, determine the department and authority of the chain of supervision nodes or supervisory members within the supervisory organization, and represent their identities in the form of domain names. Then, the chain of supervision nodes or supervisory members generate public-private key pairs locally and send certificate issuance requests to the CA of their respective organizations. Finally, the CA of the supervisory organization completes the registration of the chain of supervision node or supervisory user identity and issues a public key certificate to them.

[0012] (4) Construct a chain of custody network. Configure the chain of custody network information on all chain of custody nodes to ensure network communication between chain of custody nodes.

[0013] (5) Start the chain of custody node program. Using the chain of custody node certificate information obtained in step (3), start the chain of custody node program on a separate host.

[0014] (6) Generate the initial block. The Chain of Supervision node creates the Chain of Supervision configuration file and generates the starting block of the Chain of Supervision.

[0015] S12: Chain of Supervision Node Sharding. This step completes the sharding of the chain of supervision nodes. The specific process consists of the following 6 steps:

[0016] (1) Determine the performance indicators of the regulatory chain. Based on the business requirements of the regulatory chain, design the throughput TH of the regulatory chain and the transaction processing latency D of the regulatory chain.

[0017] (2) Determine the number of nodes N in a shard. Starting with 1 node, continuously increase the number of nodes in a shard, test the latency index d of a single shard, and select the largest number of nodes in a shard as N if d is not greater than D.

[0018] (3) Determine the number of shards M. Test the throughput metric th of a single shard to select the number of shards.

[0019] (4) Divide the chain of supervision nodes. First, assign serial numbers [0, M-1] to the M shards on the chain of supervision. Then, assign serial numbers to all chain of supervision nodes uniformly. Finally, based on the modulo result of the node serial number, assign the node to the shard with the same ID as the modulo result.

[0020] (5) Create the initial block of the shard. In each shard, first select a node to generate shard configuration information and create the initial block of the blockchain ledger within the shard.

[0021] (6) Node joins shard. Based on the result of step (4), the node copies the initial block of the corresponding shard, broadcasts its own request to join the shard, and finally joins the shard.

[0022] S13: Design the interaction functionality between the regulatory application and the blockchain. Complete the definition of the regulatory application and the interface between the application and the regulatory blockchain. The specific process can be divided into the following 6 steps:

[0023] (1) Design the regulatory chain calling interface. Design a regulatory chain smart contract to provide common functional interfaces according to the different needs of regulators, and deploy it on the regulatory chain.

[0024] (2) Design the regulatory application access interface. According to the regulatory function, design the regulatory application access interface for the regulatory link, and encapsulate the calling interface provided by the regulatory chain in step (1) into the regulatory application access interface.

[0025] (3) Configure the regulatory application with regulatory chain information. Configure a file describing the regulatory chain for the regulatory application. The file content includes node information and shard information of the regulatory chain.

[0026] (4) Configure regulator information in the regulatory application. The regulatory application creates a regulatory account for the regulator and stores the regulator's public key certificate and other relevant information for logging into the regulatory chain.

[0027] (5) Connect the regulatory application and the regulatory chain. Based on the configuration file generated in step (3) and the regulatory account generated in step (4), the regulatory application generates information for connecting different shards locally.

[0028] (6) Test the functionality of the regulatory application. The regulator calls the access interface designed in step (2) on the regulatory application to test its usability.

[0029] S2: On-chain data storage for business chains. To enable the regulatory chain to supervise the business chain, business chain data needs to be stored on the regulatory chain. The specific process consists of the following three steps: acquiring business chain data, generating unified data tags, and storing and storing the data on the chain.

[0030] S21: Obtaining Business Chain Data. The regulatory chain obtains transaction data from the business chain ledger. The specific process consists of the following 6 steps:

[0031] (1) Establish cross-chain communication connection. Establish cross-chain communication connection between regulatory application and business chain to transmit regulatory request and response information.

[0032] (2) Sending regulatory requests. Regulators send regulatory requests to the target business chain through the regulatory application as needed. The regulatory request includes the regulator's public key certificate, the identity of the regulated entity, and the content of the requested regulation.

[0033] (3) Business chain verifies regulatory request. After receiving the regulatory request, the business chain verifies the regulator's public key certificate to determine whether it has the requested regulatory authority. If the regulator does not have the relevant authority, proceed to step (4); otherwise, proceed to step (5).

[0034] (4) Business chain rejects regulatory request. If the regulator does not have access rights, the business chain returns a rejection message to the regulatory application, indicating that it cannot provide the regulator with the relevant business chain data.

[0035] (5) The business chain returns relevant data. Based on the regulatory request, the business chain queries the relevant data in the ledger and encapsulates it into a response message, which is then sent to the regulatory chain.

[0036] (6) The regulatory application receives the business chain response. The regulatory application receives the message returned by the business chain from the cross-chain communication connection. If no message is received within the timeout or a rejection message is received, the application returns to step (2) to try to resend the regulatory request; if a response message is received from the business chain, the application proceeds to step S22.

[0037] S22: Generate unified data tags. To resolve storage conflicts and uneven distribution issues arising from data from different business chains during sharding, unified tags need to be generated for all data from the business chains before sharding. The specific process, as shown in Algorithm 1, consists of 10 steps:

[0038] (1) Parse the business chain data. First, determine the type of data obtained from the business chain in step S21. Divide the data from the business chain into three categories: transactions, blocks, and account snapshots. Then, determine the index of the data on the business chain according to the type, where the index of a transaction is the transaction sequence number, the index of a block is the block height, and the index of an account is the account identifier. Finally, determine whether the current data type is a block or a transaction. If yes, proceed to step (2); otherwise, proceed directly to step (3).

[0039] (2) Calculate the transaction or block tag. Concatenate the index of the data on the business chain with the business chain name to form a string S. Use S as the input to the hash function to calculate the tag L. After completion, proceed directly to step (8).

[0040] (3) Calculate account tags. For data of the account snapshot type, calculate account tags and perform steps (4) to (7) in sequence.

[0041] (4) Determine the number of bits to retain, k. Set a variable k, which represents the number of common bits of data from the same account in the tags. The length of k depends on the number of shards, and is required to be 2. k ≥M.

[0042] (5) Calculate the account's public label. Concatenate the account's index with the business chain name to form a string S. Use S as input to a hash function to calculate the account's public label i.

[0043] (6) Calculate the account-unique tag. Concatenate the string S generated in step (5) with the regulatory serial number seq to form a string S′. Use S′ as the input to the hash function to calculate the result t.

[0044] (7) Generate account tag. Account tag L consists of two parts. Take the first nk bits from the calculation result t of step (6) and the last k bits from the calculation result i of step (5). Concatenate the two parts to form an n-bit account tag L.

[0045] (8) Check if the data tag exists. Check if the tag L of the current data exists on the ledger of the supervision chain. If it exists, proceed to step (9); otherwise, proceed directly to step (10).

[0046] (9) Regenerate data tags. First, regenerate tags according to the data type. If it is a transaction or block, directly use the same hash function to re-hash tag L to generate a new tag L; if it is an account snapshot, use the same hash function to re-hash tag L to generate a new tag L′, and reset the low k bits of L′ to the low k bits corresponding to the original L to obtain a new tag L. Finally, return to step (8).

[0047] (10) Bind data tags. Bind the tag L and the corresponding data together as a key-value pair.

[0048]

[0049] S23: Data Storage on the Chain. After generating tags based on the data type, the data needs to be stored on different shards of the custodian chain. The specific process consists of the following 5 steps:

[0050] (1) Serialize business chain data. The regulatory application merges the data from the business chain, the index of the data on the business chain, the regulator's identifier, and the regulatory time, and serializes the data, and uses the result as the value stored in the regulatory chain.

[0051] (2) Determine the data index. Use the data tag L generated in step S22 as the key stored in the chain of custody.

[0052] (3) Calculate the target shard index. Take the last k bits of the tag L, perform a modulo operation M, and use the result as the target shard index for data storage.

[0053] (4) The regulatory application saves the data. The regulatory application calls the method for interacting with the regulatory chain encapsulated in step S13 to initiate a data storage request to the regulatory chain node.

[0054] (5) Regulatory chain nodes store business chain data. Regulatory chain nodes within the target shard reach a consensus on data storage requests from regulatory applications and save the business chain data to a jointly maintained ledger.

[0055] S3: Business Chain Transaction Verification. To verify the correctness of transactions occurring on the business chain on the custodian chain, the business chain's smart contract needs to be executed on the custodian chain. The specific process consists of three steps: determining the transaction type, intra-shard transaction verification, and cross-shard transaction verification.

[0056] S31: Determine Transaction Type. To select a transaction verification method, the transaction type must first be determined. Transactions are categorized into intra-shard transactions and cross-shard transactions. The specific process can be divided into the following 6 steps:

[0057] (1) Implement the business chain ledger operation method. Reimplement the business chain's operation method on the regulatory chain to ensure that regulatory chain nodes have the corresponding operation capabilities for different business chain data stored on the regulatory chain.

[0058] (2) Transform the smart contract on the business chain. For the smart contract on the business chain, iterate through the operation methods it calls, transform them into the operation methods on the regulatory chain that are reimplemented in step (1), and finally form a smart contract that can be executed on the regulatory chain.

[0059] (3) Traverse and inspect smart contracts. Traverse all smart contracts generated in step (2), inspect all steps in each smart contract in sequence, and extract and arrange all operations related to the business chain data on the regulatory chain in sequence.

[0060] (4) Check the operation parameters. For a smart contract, check the parameters of all operations extracted in step (3). Determine whether each operation involves only a single business chain account. If so, add the corresponding account to the account set; otherwise, proceed directly to step (6).

[0061] (5) Check the account set. If the account set generated in step (4) contains accounts from multiple business chains, proceed to step (6); otherwise, proceed to step (4) and check the operation parameters of the next smart contract.

[0062] (6) Determine the transaction type. If the operation of a smart contract involves accounts on multiple business chains, then the corresponding transaction is defined as a cross-shard transaction; otherwise, it is defined as an intra-shard transaction.

[0063] S32: In-shard transaction verification. After the regulatory application confirms that a transaction belongs to a specific shard, the regulatory chain nodes within that shard need to verify the transaction. The specific process consists of the following four steps:

[0064] (1) Initiate transaction verification. The regulatory application sends a transaction request to the regulatory chain node within the shard.

[0065] (2) Controller nodes verify transactions. First, the controller nodes check the identity of the transaction initiator to verify its legitimacy. Then, the controller nodes run the corresponding smart contract locally to verify the transaction. Finally, all controller nodes within the shard reach a consensus on the transaction based on their local verification results. If a consensus is reached, proceed to step (3); otherwise, proceed to step (4).

[0066] (3) The supervisory chain node submits the transaction. When the supervisory chain nodes in the shard reach a consensus on the successful execution of the transaction, they package the local transaction and verification results into a block and store it in the blockchain ledger.

[0067] (4) The custodian chain nodes reject the transaction. If a custodian chain node in a shard discovers a transaction error, it broadcasts the error result. Once the custodian chain nodes in a shard reach a consensus on the failure of the transaction, they package the failed transaction into a block and store it in the blockchain ledger.

[0068] S33: Cross-shard transaction verification. After the regulatory application confirms that a transaction involves multiple shards, all regulatory chain nodes within the involved shards need to verify the transaction. The specific process consists of two steps: smart contract decomposition and subcontract sequential verification.

[0069] (1) Smart Contract Decomposition. To verify cross-shard smart contracts, the entire smart contract needs to be decomposed into sub-contracts that can be verified within a single shard. Algorithm 2 demonstrates the smart contract decomposition algorithm, which consists of the following 6 steps:

[0070] a) Decompose a smart contract into multiple sequential subcontracts. Each operation on the business chain data is broken down into an independent subcontract, and these subcontracts are ordered according to the order of invocation.

[0071] b) Create a directed acyclic graph (DAG) G and a list of nodes StartList.

[0072] c) Iterate through each subcontract sequentially and create a node V for it in graph G. i It then constructs a set C of dependent subcontracts for the current subcontract. By checking the input parameters, it determines whether other subcontracts should be added to the current subcontract set C.

[0073] d) If node V has undergone step c) i If the set of subcontracts C on which it depends is empty, then node V... i Add it to StartList.

[0074] e) If node V i The set of subcontracts C on which it depends is not empty, and each node V in C is traversed. j And add the corresponding edges in graph G. <V j V i >

[0075] f) After creating nodes and marking dependencies for all subcontracts, output graph G and node list StartList.

[0076]

[0077]

[0078] (2) Subcontract Order Verification. After decomposing the smart contract, all subcontracts are verified sequentially. The specific process is shown in Algorithm 3, consisting of the following 6 steps:

[0079] a) For each node V in graph G i Build a waiting queue w i , including V i All dependent nodes.

[0080] b) Iterate through all nodes in StartList and use the smart contract's input parameters to verify the subcontracts corresponding to these nodes. If a subcontract is successfully verified, remove its corresponding node from StartList. If the node corresponding to this contract is in the waiting queue of other nodes, remove it from the waiting queue as well.

[0081] c) After all nodes in StartList have been removed, traverse the remaining nodes in graph G. Only when node V... i waiting queue w i After being cleared, node V i Only then can the verification of the corresponding subcontract begin.

[0082] d) If all nodes have been removed from graph G, then all subcontracts have been verified.

[0083] e) When all subcontracts have verified true, set the return result T to true and set the content of the response string Resp to be consistent with the verification result of the smart contract on the business chain.

[0084] f) If one of the subcontracts fails verification, return result T as false and Resp as an empty string.

[0085]

[0086] Attached Figure Description

[0087] Figure 1 A diagram of a sharded cross-chain regulatory architecture.

[0088] Figure 2 Regulatory application module diagram

[0089] Figure 3 Business chain structure diagram

[0090] Figure 4 Business chain ledger data,

[0091] Figure 5 Cross-shard smart contract breakdown diagram

[0092] Figure 6 Endorsement-Sorting-Submission Flowchart

[0093] Figure 7 The data tag generation flowchart in the embodiment is as follows:

[0094] Figure 8 The smart contract decomposition flowchart in the embodiment is as follows:

[0095] Figure 9 The cross-shard transaction verification flowchart in the embodiment.

[0096] Compared with the prior art, the advantages of the present invention are as follows:

[0097] This invention proposes a business chain transaction supervision method oriented towards "chain-based governance," comprising three main steps: constructing a sharded regulatory chain, uploading business chain data to the chain, and verifying business chain transactions. Compared with current cross-chain blockchain supervision methods, this method has the following advantages:

[0098] (1) Sharded Chain of Supervision Construction. S1 divides the chain of supervision nodes into different shards, significantly reducing consensus overhead between nodes and alleviating performance bottlenecks encountered when supervising numerous business chains. Simultaneously, S1 separates the chain of supervision network from the regulatory applications. The chain of supervision network provides infrastructure services for the regulatory applications, while the regulatory applications provide regulatory services to regulators, reducing the coupling between the chain of supervision and regulatory functions and enhancing the scalability of the chain of supervision.

[0099] (2) On-chain data of business chains. In S2, the ledger that all nodes of the regulatory chain originally needed to maintain completely is divided into independent ledgers with an equal number of shards, which are then maintained independently by different shards. In order to solve the problems of data conflict and uneven sharding caused by sharding, a unified label is used to distinguish data from different business chains. This reduces the storage overhead of the regulatory chain nodes while ensuring the correctness and availability of business chain data stored in shards on the regulatory chain.

[0100] (3) Business Chain Transaction Verification. S3 utilizes blockchain transaction verification technology and smart contract decomposition technology to verify business chain transactions on a sharded regulatory chain. Intra-shard transaction verification employs existing consensus algorithms, ensuring reliability during the intra-shard transaction verification process. For cross-shard transaction verification, the intra-shard transaction verification method and transaction decomposition algorithm are used to complete the verification of cross-shard transactions. This step implements a sharded smart contract verification method, enabling the regulatory chain to supervise smart contract-based transactions occurring on the business chain. Detailed Implementation

[0101] 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.

[0102] Figure 1 This paper presents a sharded "chain-based governance" regulatory system architecture. This embodiment uses Hyperledger Fabric as the blockchain platform to build a sharded regulatory chain for "chain-based governance." The implementation process of this invention mainly consists of three steps: node sharding, data sharding, and transaction verification.

[0103] Before introducing the embodiments of the present invention, it is necessary to first describe the architecture of the business chain in the embodiments. The regulatory chain in the embodiments is precisely for supervising this business chain. This business chain is modified from fabcar in fabric-samples and named mfabcar, which is a blockchain platform for managing vehicle transactions. Figure 3 The architecture of the business chain is demonstrated. The business chain is jointly maintained by two organizations, each corresponding to a real-world enterprise or social organization and containing one peer node. There is one orderer node on the business chain, operating in solo mode. Each node is encapsulated in Docker and runs independently on a separate host. All organizations in the business chain join channel1, which stores the mfabcar ledger. Nodes join the channel and participate in the consensus process of the ledger within it. The ledger and transactions occurring in this channel are also the primary content subject to oversight. Figure 4 The document showcases the storage content of the business chain ledger; mfabcar stores records of the relationships between vehicles and their owners.

[0104] S1: Construction of a sharded regulatory chain. This can be divided into the following three steps: building the regulatory chain, sharding the regulatory chain nodes, and designing the interaction functions between regulatory applications and shards.

[0105] S11: Establishing the chain of supervision. The specific process can be divided into the following 6 steps:

[0106] (1) Establishing the Supervisory Organization Identity. First, a trusted CA is identified. In this embodiment, a self-signed certificate of the root CA is constructed using OpenSSL to simulate a trusted CA. Then, an asymmetric key pair for the supervisory organization is generated using ssh-keygen, and a Certificate Request for Identity (CSR) file for the supervisory organization is constructed using OpenSSL based on this key pair. Finally, the identity is registered with the CA using the CSR file.

[0107] (2) Construction of the Regulatory Organization CA. The regulatory organization CA is created using the `fabric-ca-server` command and the `ca-server-config.yaml` file. In practice, the regulatory organization's CA should be issued certificates by a globally recognized CA authority. In this embodiment, a self-signed certificate generated by the regulatory organization is used to build the regulatory organization's CA. The regulatory organization's CA is run on a separate server to provide certificate distribution services to the regulatory organization's members.

[0108] (3) Establishing the identities of the chain of supervision nodes and regulatory members. Register the chain of supervision node identity with the regulatory organization (CA) using the fabric-ca-client command and the ca-client-config.yaml file. Enable the TLS option; the chain of supervision node machine stores its own identity certificate and TLS certificate.

[0109] (4) Configure the chain of supervision network. Store the chain of supervision node certificates generated in step (2) in organizations / peerorganizations / <peer domain> In the / msp folder, configure the core.yaml file, including the port used by the peer node, the address for storing the blockchain ledger, the Hyperledger Fabric version, channel information, and the storage addresses for identity certificates and TLS certificates.

[0110] (5) Start the chain of supervisors node program. Based on the chain of supervisors network configuration file core.yaml in step (4), use the peernode start command to start the chain of supervisors node on a standalone machine.

[0111] (6) Generate the initial block. Use the `configtxgen` command on the order node to generate the initial blockchain genesis.block and start the order node. The blockchain node receives the genesis block from the orderer, at which point the blockchain node joins the blockchain.

[0112] S12: Chain of Control Node Sharding. The specific process can be divided into the following 6 steps:

[0113] (1) Determine the performance indicators of the regulatory chain. Based on the business requirements of the regulatory chain, the throughput of the regulatory chain is estimated to be 200 TPS, and the transaction processing delay of the regulatory chain is 1 second.

[0114] (2) Determine the number of nodes within a shard. Starting with 1 node, continuously increase the number of nodes within a shard, test the latency of a single shard, and select the maximum number of nodes within a shard if the latency is no greater than 1 second. Here, we choose 2 nodes within a shard.

[0115] (3) Determine the number of shards. The throughput of a single shard is 130 TPS, which is based on the formula in section S12 of the invention. The calculated number of fragments is 2.

[0116] (4) Node partitioning. First, assign fragment numbers {0,1}. Then, number the chain of custody nodes. The domain name of the chain of custody nodes in S1 is composed of peer. <num>.<supervision name> In this case, num represents the node number of the regulatory chain, and r = nummods. Finally, the num-th node is assigned to the r-th shard.

[0117] (5) Create the initial shard block. Specify a supervisory chain node and use the peer channel create command and configuration file configtx.yaml to create a shard configuration file shard.tx and a shard configuration block shard.block.

[0118] (6) Joining a Node to a Shard. Other nodes within the same shard use the peer channel fetch command to retrieve the shard configuration block shard.block. Then, they use the peer channel join command to join the shard.

[0119] S13: Implement the regulatory application and sharding interaction module. The specific process consists of the following 6 steps:

[0120] (1) Write and deploy the regulatory link interface code. Write smart contracts on the regulatory chain that interact with the blockchain ledger, including functions for adding, deleting, querying, and modifying data, such as add(key,value), delete(key), query(key), and update(key,value).

[0121] (2) Write code to encapsulate the supervisory link port. In the supervisory application, combine and encapsulate the supervisory link port in step (1) that uses SubmitTransactions and EvaluateTransactions in hyperledger / fabric-sdk-go.

[0122] (3) Configure the regulatory application. Write the conn.yaml configuration file. The conn.yaml configuration file is shown in Table 1. The configuration file needs to specify sharding information and related organization and node information to help the regulatory application initiate transactions to specific nodes.

[0123] (4) Configure the supervisor information. Use gateway.NewX509Identity and wallet.Put to generate a supervisor identity for the supervisor and save it locally. Use gateway.NewFileStemWallet to create the supervisor's local configuration file.

[0124] (5) Connect regulatory applications with the regulatory chain. Figure 2 This demonstrates the role of the regulatory application and the regulatory chain interaction module within the regulatory system. The regulatory application connects to all shards based on relevant configuration files. It obtains the shard connection handle `gw` and uses `gw.Contract` to retrieve the specific smart contract, which actually includes both the smart contracts required by the regulatory chain itself and the business chain smart contracts. The regulatory application stores the `gw` information of all shards in a local hash table `m`.

[0125] (6) Test the regulatory application functionality. Call regulatory application methods, such as the add() method to store data on the regulatory chain and the delete(key) method to delete unnecessary regulatory data. Verify the correctness of the method functionality.

[0126] Table 1. Configuration file conn.yaml

[0127]

[0128]

[0129] S2: Business chain data on-chain. The specific process consists of three steps: business chain data acquisition, generation of unified data tags, and data storage on-chain.

[0130] S21: Business chain data acquisition. The specific process consists of the following 6 steps:

[0131] (1) Establish cross-chain communication. Here, we choose a blockchain cross-chain communication method based on a cross-chain proxy. A regulatory proxy is deployed on the business chain side, and the regulatory application establishes a socket connection with the regulatory proxy.

[0132] (2) The regulatory application initiates a regulatory request. Specific regulatory requests include getAccountState, getBlock, and getTransactions, which retrieve account snapshots, block information, and transaction information, respectively. The format of the regulatory request is as follows:

[0133] (3)SupReq={SupervisorID|BusinessBlockchainID|BusinessContent|Signature}.

[0134] (4) Business chain verifies regulatory request. The business chain verifies the identity of the regulatory requester. If the regulator does not have regulatory authority, proceed to step (4); otherwise, proceed to step (5).

[0135] (5) The business chain rejects the regulatory request. The response content of the business chain rejecting the regulatory request is Resp = {ErrorMessage}.

[0136] (6) The business chain returns regulated content. The content returned by the business chain is Resp = {BusinessContent|Signature}.

[0137] (7) The monitoring application receives the business chain response. The monitoring application reads the response information of the business chain from the socket connection established in step (1) so as to monitor the business chain data in the future. If no message is received within the timeout or a rejection message is received, retry(requireTransaction) is called to return to step (2) to try to resend the monitoring request; if a response message from the business chain is received, the application proceeds to step S22.

[0138] S22: Generate unified data labels. Figure 7 The process of generating data labels is demonstrated. It can be divided into the following 10 steps:

[0139] (1) Parse the corresponding data in the business chain. Set up data indexes, including data source and data type. Figure 4 The account data stored in the business chain all originate from "mfabcar" and are of type "Account", indicating that they are account data. Determine whether the current data type is "Block" or "Transaction". If yes, proceed to step (2); otherwise, proceed directly to step (3).

[0140] (2) Calculate the transaction or block tag. Concatenate the business chain name and the index of the data in the business chain to obtain S = {DataIndex|SourceBlockchainName}, and calculate the data tag L = FNV(S). Execute step (8).

[0141] (3) Calculate account tags. For user account snapshot data, calculate their business chain tags and perform steps (4)-(7).

[0142] (4) Determine the number of bits to retain, k. There are two slices here, so choose k = 1.

[0143] (5) Calculate the account public label. S = {DataIndex|SourceBlockchainName}, and use it as the input of the hash function to calculate the account public label i = FNV(S).

[0144] (6) Calculate the account-specific tag. Hash t = FNV(S|seq) with the regulatory serial number seq generated in step (5).

[0145] (7) Generate account tags. The lowest bit of the account tag L is taken from the position corresponding to i, which is obtained by hashing the account index and the business chain name; the remaining high bits t are the corresponding bits.

[0146] (8) Check if the data label exists. If query(L) == TRUE, proceed to step (9); otherwise, proceed to step (10).

[0147] (9) Regenerate the data tag. If the data is a transaction or block, let L′ = FNV(L). If the data is an account snapshot, replace the lower k position of the rehashed result with the corresponding bit of L to generate a new tag L′, and let L = L′. Proceed to step (8).

[0148] (10) Bind data labels. After generating labels L for the data, bind the data to the labels.

[0149] S23: Data storage on the blockchain. The specific process can be divided into the following 5 steps:

[0150] (1) Serialize business chain data. Use JSON to serialize business chain data, DataJSON = json.Marshal(Data).

[0151] (2) Determine the data index. The data's index on the chain of custody is Index = L.

[0152] (3) Calculate the target shard index. Use the formula ShardID = Index[:k] mod M to obtain the target shard where the data is located.

[0153] (4) The regulatory application saves data. The smart contract m.submitTransaction(add, Index, DataJSON) corresponding to the shard in S13 is called to send a data save request to the regulatory chain node in the corresponding shard.

[0154] (5) The regulatory chain node stores business chain data. After receiving a request from the regulatory application, the regulatory chain node calls the local smart contract add(Index, DataJSON) to store the data on the business chain onto the regulatory chain.

[0155] S3: Business Chain Transaction Verification. Specifically, it can be divided into transaction type determination, intra-shard transaction verification, and cross-shard transaction verification.

[0156] S31: Determine the transaction type. The specific process can be divided into the following 6 steps:

[0157] (1) Write the business chain ledger operation methods. Based on the logic of adding, deleting, querying and modifying the ledger, replace the interaction methods of the business chain smart contract code with the blockchain ledger in S13, such as add, update, delete and query or a combination thereof.

[0158] (2) Write the business chain smart contract. Replace the corresponding call in the original business chain with the method generated in step (1) and write the business chain smart contract on the regulatory chain.

[0159] (3) Traverse and inspect smart contracts. Traverse the operation methods called by the smart contracts in the order they appear in the custodian chain. For example, the query() method for finding data and the add() method for adding data.

[0160] (4) Check the operation parameters. If the parameters of the smart contract called on the custodian chain only involve a single account, then record that account in the set C = {Account1, Account2, ...}.

[0161] (5) Check the account set. If the account addresses involved in the methods called by the custodian chain smart contract may not be equal, proceed to step (6); otherwise, traverse the next smart contract and proceed to step (4).

[0162] (6) Determine the transaction type. If the method called by the custodian chain smart contract involves multiple accounts, then mark it as InterShardSmartContract; otherwise, mark it as IntraShardSmartContract.

[0163] S32: In-shard transaction verification method. Figure 6 The verification process for transactions within a shard is demonstrated. It can be divided into the following four steps:

[0164] (1) Initiate transaction verification. The regulatory application initiates a transaction request TransReq = {SmartContract|Params|Signature|Metadata} to the regulatory chain node.

[0165] (2) Regulatory chain nodes verify transactions. First, the regulatory chain nodes verify the legality of the Signature based on a trusted CA. Then, the regulatory chain nodes run the SmartContract(Params) locally to verify the transaction based on the transaction content. Finally, based on the transaction result, they initiate transaction consensus within the shard. If the transaction verification is successful, proceed to step (3); otherwise, proceed to step (4).

[0166] (3) The supervisory chain node submits the transaction. When ConsensusPolicy(ReceivedResult) = true, the supervisory chain node packages the local transaction and verification result into a block Block = {Trans1, Trans2, ...} and modifies the local ledger.

[0167] (4) The supervisory chain node rejects the transaction. When the supervisory chain node in the shard discovers a transaction error, it calls Broadcast(ErrorMessage) to broadcast the error result, packages the failed transaction into block Block = {Trans1, Trans2, ErrorTrans...}, and submits it to the chain.

[0168] S33: Cross-shard transaction verification. This involves the following two steps:

[0169] (1) Decomposition of smart contracts. Figure 8 The process of breaking down a smart contract is demonstrated. It can be divided into the following 6 steps:

[0170] a) Based on the access to the ledger via the mfabcar smart contract, it is first decomposed into five sequential sub-smart contracts: QueryCarOwner, RmFromOldOwner, AddToNewOwner, UpdateCarOwner, and UpdateTransaction. These correspond to the five steps of querying the current owner information of a vehicle, removing the vehicle from the old owner's name, adding the vehicle to the new owner's name, updating the vehicle's owner, and finally submitting all updates.

[0171] b) Create an empty DAG graph G and a list of starting nodes StartList.

[0172] c) Some of the above steps are dependent on each other, while others are not and can be executed in parallel. First, knowing the result of QueryCarOwner, i.e., the current car owner's information, is necessary to delete a car under that owner's name, so RmFromOldOwner can be executed. Then, after the above two steps are executed successfully, the vehicle owner can be updated and the vehicle added to the owner's name simultaneously, so AddToNewOwner and UpdateCarOwner can be performed concurrently. Finally, after all transactions are successfully verified, the following is called...

[0173] UpdateTransaction updates the transaction results and writes them to the final ledger.

[0174] d) Based on the analysis in step (c), take the above five smart contracts as vertices V of the DAG graph, and construct an edge from QueryCarOwner to RmFromOldOwner to indicate that the execution of the latter needs to wait for the result of the former. Figure 5 It contains the final DAG graph G.

[0175] e) The execution of the QueryCarOwner smart contract does not depend on the results of other smart contracts, so it is placed in the StartList.

[0176] f) Return the generated graph G and StartList.

[0177] Table 2 Smart Contract Configuration File fablo.yaml

[0178]

[0179] (2) Subcontract order verification. Figure 9 The process of sequentially verifying sub-smart contracts is demonstrated. The specific process can be divided into the following 6 steps:

[0180] a) Develop and deploy a transaction verification program. First, based on the DAG graph generated in S33, develop a smart contract program. The smart contract chaincode contains a built-in tmpMap, which stores temporary values ​​generated during smart contract calls in key-value format, with the key and value corresponding to the storage method in the custodian chain ledger. Set the load and store methods for this map, as well as the corresponding locks, to ensure data security under high concurrency. Then, package the smart contract into chaincode and install it in each shard of the custodian chain. The chaincodes entry in Table 2 specifies the location of the smart contract and the corresponding channel where it is installed. Finally, run the smart contract using peer node start. The remaining steps describe the process of verifying specific cross-shard transactions.

[0181] (b) Generate a waiting queue for each node in graph G. For example, the node representing AddToNewOwner needs to wait for the node representing RmFromOldOwner to finish running before it runs, so the latter is in the former's waiting queue. Continue this process to generate corresponding waiting queues for all nodes. The waiting queues for nodes located in StartList are empty.

[0182] c) Based on the input of the original transaction, i.e., the CarId (vehicle number) is used to calculate the shardId of the vehicle, and the shardId is used as a handle to call QueryCarOwner in the relevant shard to query the owner information. The result is put into the channel shared with the RmFromOldOwner coroutine.

[0183] d) Then, after receiving the vehicle owner information from the channel, the latter also calls the RmFromOldOwner function in the target slice to remove the vehicle information from the old owner's name. After execution, the execution result is placed into the coroutines that call the AddToNewOwner and UpdateCarOwner smart contracts. The latter reads the necessary information from the channel and also starts calling the relevant smart contracts, returning the result to the UpdateTransaction coroutine. The intermediate results are stored in tmpMap.

[0184] e) After UpdateTransaction receives the successful execution results from AddToNewOwner and UpdateCarOwner, it modifies the account value.

[0185] f) If any of the transactions fails, return a response Resp containing the error message ErrorMsg.

[0186] 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.< / num>

Claims

1. A business chain transaction supervision method oriented towards using blockchain to govern blockchain, characterized in that, The method includes the following steps: S1: Construction of a sharded regulatory chain; the specific process is divided into the following 3 steps: S11: Construction of the regulatory chain, S12: Sharding of regulatory chain nodes, S13: Design of regulatory application and sharding interaction functions; S2: Business chain data is uploaded to the blockchain; the specific process consists of the following 3 steps: S21 acquiring business chain data, S22 generating unified data tags, and S23 storing and uploading data to the blockchain; S3: Business chain transaction verification; the specific process consists of 3 steps: S31: Determine the transaction type. S32 intra-shard transaction verification S33 Cross-Shard Transaction Verification; in, S22: Generate unified data labels, which consists of 10 steps: (1) Parse the business chain data. First, determine the type of data obtained from the business chain in step S21. Divide the data from the business chain into three categories: transactions, blocks, and account snapshots. Then, determine the index of the data on the business chain according to the type. The index of a transaction is the transaction number, the index of a block is the block height, and the index of an account is the account identifier. Finally, determine whether the current data type is a block or a transaction. If so, proceed to step (2); otherwise, proceed directly to step (3). (2) Calculate the transaction or block tag, and concatenate the index of the data on the business chain with the business chain name into a string. ,Will The label is calculated as input to the hash function. After that, proceed directly to step (8). (3) Calculate account tags. For data of the account snapshot type, calculate account tags and execute steps (4) to (7) in sequence. (4) Determine the number of digits to retain. Set variables , The number of common bits in the labels representing data from the same account. The length depends on the number of fragments, requiring , (5) Calculate the account public tag and concatenate the account index with the business chain name into a string. ,Will The public tag of the account is calculated as input to the hash function. , (6) Calculate the account-unique tag, and use the string generated in step (5) With regulatory serial number Concatenate into a single string ,Will The result is calculated as input to the hash function. , (7) Generate account tags, account tags It consists of two parts, derived from the calculation results of step (6). Take the front Each bit is calculated from the result of step (5). After taking Each bit will be used to concatenate the two parts into a single unit. Account tags , (8) Check if the data tag exists and query the current data tag on the ledger of the supervision chain. If it exists, proceed to step (9); otherwise, proceed directly to step (10). (9) Regenerate data tags. First, regenerate tags according to the data type. If it is a transaction or a block, directly use the same hash function to regenerate the tags. Re-hash to generate new labels If it is an account snapshot, use the same hash function to hash the tags. Re-hash to generate new labels ,Will low The bit is reset to its original position. Corresponding low The position gets a new label. Finally, return to step (8). (10) Bind data tags, and bind the tags It is bound together with the corresponding data as a key-value pair.

2. The business chain transaction supervision method based on blockchain governance according to claim 1, characterized in that, S11: Chain of Supervision Construction, which consists of the following 6 steps: (1) Constructing the identities of regulatory organizations: The regulatory chain is jointly constructed by multiple regulatory organizations. When constructing the regulatory chain, it is necessary to first construct the identities of all regulatory organizations. First, a recognized Certificate Authority (CA) is determined. Then, each regulatory organization generates a public-private key pair locally and sends a certificate issuance request to the CA. Finally, the CA completes the registration of the identities of each organization and issues public key certificates to them. (2) Construct the CA of the regulatory organization. Each regulatory organization uses the certificate obtained in step (1) to construct its own CA. (3) Constructing the identities of regulatory chain nodes and regulatory members: First, determine the department and authority of the regulatory chain node or regulatory member within the regulatory organization, and represent their identity in the form of a domain name. Then, the regulatory chain node or regulatory member generates a public-private key pair locally and sends a certificate issuance request to the CA of the organization to which it belongs. Finally, the CA of the regulatory organization to which it belongs completes the registration of the regulatory chain node or regulatory user identity and issues a public key certificate to them. (4) Construct a chain of custody network, configure the chain of custody network information on all chain of custody nodes, and ensure network communication between chain of custody nodes. (5) Start the chain of custody node program. Using the chain of custody node certificate information obtained in step (3), start the chain of custody node program on a separate host. (6) Generate the initial block. The regulatory chain node creates the regulatory chain configuration file and generates the regulatory chain starting block; S12: Chain of Supervision Node Sharding. This step completes the sharding of the chain of supervision nodes. The specific process consists of the following 6 steps: (1) Determine the performance indicators of the chain of custody and design the throughput of the chain of custody based on the business requirements of the chain of custody. Delay in transaction processing on the regulatory chain , (2) Determine the number of nodes within a partition Starting with one node, the number of nodes within a shard is gradually increased to test the latency metric of a single shard. ,exist Not greater than In this case, the largest number of nodes within the partition is selected as the maximum number of nodes. , (3) Determine the number of slices Test the throughput metrics of a single shard Select the number of shards , (4) Divide the regulatory chain nodes. First, divide the regulatory chain nodes. Each fragment is assigned a sequence number in sequence. Then, a serial number is uniformly assigned to all chain nodes. Finally, based on the modulo result of the node serial number, the node is assigned to a shard with an ID that matches the modulo result. (5) Create the initial block of the shard. In each shard, first select a node to generate shard configuration information and create the initial block of the blockchain ledger within the shard. (6) The node joins the shard. Based on the result of step (4), the node copies the initial block of the corresponding shard, broadcasts its own request to join the shard, and finally joins the shard. S13: Design the interaction function between the regulatory application and the blockchain, and complete the definition of the regulatory application and the interaction interface between the application and the regulatory blockchain. The specific process is divided into the following 6 steps: (1) Design the regulatory chain call interface and the regulatory chain smart contract, provide general functional interfaces according to the different needs of regulators, and deploy them on the regulatory chain. (2) Design the regulatory application access interface. According to the regulatory function, design the regulatory application access link interface. Encapsulate the calling interface provided by the regulatory chain in step (1) into the regulatory application access interface. (3) Configure the regulatory application with regulatory chain information. Configure a file describing the regulatory chain for the regulatory application. The file content includes node information and shard information of the regulatory chain. (4) The regulatory application configures the regulator's information. The regulatory application creates a regulatory account for the regulator and stores the regulator's public key certificate information for logging into the regulatory chain. (5) Connect the regulatory application and the regulatory chain. Based on the configuration file generated in step (3) and the regulatory account generated in step (4), the regulatory application generates information for connecting different shards locally. (6) Test the functionality of the regulatory application. The regulator calls the access interface designed in step (2) on the regulatory application to test its availability.

3. The business chain transaction supervision method based on blockchain governance according to claim 2, characterized in that, S21: Obtaining Business Chain Data. The regulatory chain obtains transaction data from the business chain ledger. The specific process consists of the following 6 steps: (1) Establish cross-chain communication connections: A cross-chain communication connection is established between the regulatory application and the business chain to transmit regulatory request and response information. (2) Sending regulatory requests: The regulator sends regulatory requests to the target business chain through the regulatory application as needed. The regulatory request includes the regulator's public key certificate, the identity of the regulated object, and the content of the regulatory request. (3) The business chain verifies the regulatory request. After receiving the regulatory request, the business chain verifies the public key certificate of the regulator to determine whether it has the requested regulatory authority. If the regulator does not have the relevant authority, proceed to step (4); otherwise, proceed to step (5). (4) If the business chain rejects a regulatory request, and the regulator does not have access rights, the business chain returns a rejection message to the regulatory application, indicating that it cannot provide the regulator with the relevant business chain data. (5) The business chain returns relevant data. Based on the regulatory request, the business chain queries the relevant data in the ledger and encapsulates it into a response message, which is then sent to the regulatory chain. (6) The regulatory application receives the response from the business chain. The regulatory application receives the message returned by the business chain from the cross-chain communication connection. If no message is received within the timeout period or a rejection message is received, the application returns to step (2) to try to resend the regulatory request. If a response message from the business chain is received, the application proceeds to step S22. S22: Generate unified data labels. S23: Data storage on the blockchain, the specific process consists of the following 5 steps: (1) Serialize business chain data. The regulatory application merges the data from the business chain, the index of the data on the business chain, the regulator's identifier, and the necessary information for the regulatory time, and serializes the data, and uses the result as the value stored in the regulatory chain. (2) Determine the data index and assign the data tags generated in step S22. As a key stored on the regulatory chain, (3) Calculate the target fragment index and retrieve the tag. back Position, perform mold taking The operation is performed, and the result serves as the target shard index for data storage. (4) The regulatory application saves the data. The regulatory application calls the method for interacting with the regulatory chain encapsulated in step S13 to initiate a data storage request to the regulatory chain node. (5) Regulatory chain nodes store business chain data. Regulatory chain nodes within the target shard reach a consensus on data storage requests from regulatory applications and save business chain data to a jointly maintained ledger.

4. The business chain transaction supervision method based on blockchain governance according to claim 3, characterized in that, S31: Determine the transaction type, which involves the following 6 steps: (1) Implement the business chain ledger operation method. Reimplement the business chain's operation method on the regulatory chain to ensure that the regulatory chain nodes have the corresponding operation capabilities for different business chain data stored on the regulatory chain. (2) Transform the smart contract on the business chain. For the smart contract on the business chain, iterate through the operation methods it calls and transform them into the operation methods on the regulatory chain that are reimplemented in step (1), and finally form a smart contract that can be executed on the regulatory chain. (3) Traverse and inspect smart contracts. Traverse all smart contracts generated in step (2), sequentially inspect all steps in each smart contract, extract and sequentially arrange all operations related to the business chain data on the regulatory chain. (4) Check the operation parameters. For a smart contract, check the parameters of all operations extracted in step (3) to determine whether each operation involves only a single business chain account. If so, add the corresponding account to the account set; otherwise, proceed directly to step (6). (5) Check the account set. If the account set generated in step (4) contains accounts from multiple business chains, proceed to step (6); otherwise, proceed to step (4) and check the operation parameters of the next smart contract. (6) Determine the transaction type. If a smart contract operation involves accounts on multiple business chains, then the corresponding transaction is defined as a cross-shard transaction; otherwise, it is defined as an intra-shard transaction. S32: In-shard transaction verification. After the regulatory application confirms that a transaction belongs to a specific shard, the regulatory chain nodes within that shard need to verify the transaction. The specific process consists of the following four steps: (1) Initiate transaction verification: The regulatory application sends a transaction request to the regulatory chain nodes within the shard. (2) The regulatory chain node verifies the transaction. First, the regulatory chain node checks the identity of the transaction initiator to verify its legality. Then, the regulatory chain node runs the corresponding smart contract locally to verify the transaction. Finally, all regulatory chain nodes in the shard reach a consensus on the transaction based on the local verification results. If a consensus is reached, proceed to step (3); otherwise, proceed to step (4). (3) When a regulatory chain node submits a transaction, and the regulatory chain nodes within the shard reach a consensus on the successful execution of the transaction, they package the local transaction and verification results into a block and store it in the blockchain ledger. (4) If a custodian node rejects a transaction, and a custodian node within a shard discovers a transaction error, it broadcasts the error result. Once the custodian nodes within the shard reach a consensus on the failure of the transaction, they package the failed transaction into a block and store it in the blockchain ledger. S33: Cross-shard transaction verification. After the regulatory application confirms that a transaction involves multiple shards, all regulatory chain nodes within the involved shards need to verify the transaction. The specific process consists of two steps: smart contract decomposition and subcontract sequential verification. (1) Smart contract decomposition: To verify cross-shard smart contracts, the entire smart contract needs to be decomposed into sub-contracts that can be verified within a single shard. The specific process consists of the following 6 steps: a) Decompose a smart contract into multiple sequential subcontracts, breaking down each operation on the business chain data into an independent subcontract, and then sorting these subcontracts according to the order of their invocation. b) Create a directed acyclic graph. and a list of nodes , c) Iterate through each subcontract sequentially and assign it to the graph. Create a node And build a set of dependent subcontracts for it. By checking the input parameters, it determines whether other subcontracts should be added to the current subcontract's set. middle, d) If the node after step c) The set of subcontracts it depends on If it is an empty set, then the nodes Join middle, e) If node The set of subcontracts it depends on Not empty, traversal Each node in and in the figure Add the corresponding edge >, f) After creating nodes and marking dependencies for all subcontracts, output the graph. With node list ; (2) Subcontract sequence verification: After the smart contract is decomposed, all subcontracts are verified sequentially, which consists of the following 6 steps: a) is a diagram Each node in Build a waiting queue ,Include All dependent nodes, b) Traversal All nodes in the system use the input parameters of the smart contract to verify their corresponding sub-contracts. If a sub-contract is successfully verified, its corresponding node is removed from the list of nodes in the system. If the node corresponding to the contract is in the waiting queue of another node, then remove it from the waiting queue as well. After all nodes are removed, traverse the graph. The remaining nodes in the list, only when the node waiting queue After being cleared, the node Only then can the verification of the corresponding subcontract begin. d) If all nodes have been removed from the graph If removed from the middle, all subcontracts will have completed verification. e) When the verification results of all subcontracts are true, the result will be returned. Set to true and set the response string The content settings are consistent with the verification results of the smart contract on the business chain. f) If one of the subcontracts fails verification, the result will be returned. Set it to false, and Set to an empty string.

Images