CN114363352B - Cross-chain interaction method of Internet of things system based on block chain - Google Patents
Cross-chain interaction method of Internet of things system based on block chain Download PDFInfo
- Publication number
- CN114363352B CN114363352B CN202210008587.5A CN202210008587A CN114363352B CN 114363352 B CN114363352 B CN 114363352B CN 202210008587 A CN202210008587 A CN 202210008587A CN 114363352 B CN114363352 B CN 114363352B
- Authority
- CN
- China
- Prior art keywords
- node
- request
- main chain
- user
- link
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 40
- 230000003993 interaction Effects 0.000 title claims abstract description 33
- 238000012795 verification Methods 0.000 claims abstract description 25
- 238000013500 data storage Methods 0.000 claims description 23
- 238000011217 control strategy Methods 0.000 claims description 16
- 230000004044 response Effects 0.000 claims description 12
- 230000003068 static effect Effects 0.000 claims description 12
- 238000012545 processing Methods 0.000 claims description 11
- 238000004364 calculation method Methods 0.000 claims description 10
- 238000012544 monitoring process Methods 0.000 claims description 10
- 238000012216 screening Methods 0.000 claims description 6
- 230000001174 ascending effect Effects 0.000 claims description 4
- 238000012163 sequencing technique Methods 0.000 claims description 4
- 238000013475 authorization Methods 0.000 description 23
- 238000010586 diagram Methods 0.000 description 9
- 238000007726 management method Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000012423 maintenance Methods 0.000 description 4
- 238000005070 sampling Methods 0.000 description 4
- 238000011160 research Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013523 data management Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a block chain-based inter-link interaction method of an Internet of things system, which comprises the following steps: deploying a node credit model on the main chain nodes, periodically updating credit values of the main chain nodes, and selecting at least one main chain node with the highest credit value as a main chain consensus node of the round of consensus period; a user initiates a user request for a target sub-chain by accessing a sub-system corresponding to the source sub-chain; the source sub-link point fuses the user request into a cross-link request packet according to the priority policy module, and takes the cross-link request packet as a parameter to be transmitted into a cross-link transaction contract of the main chain, the cross-link transaction contract verifies the user authority, and if the verification is successful, the main chain consensus node throws out a cross-link request event; the target sub-link point monitors a cross-link request event, acquires a user request aiming at the target sub-link, executes the user request, feeds back an execution result to the source sub-link node, and feeds back the execution result to the user.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a block chain-based cross-link interaction method of an Internet of things system.
Background
Blockchains are a distributed ledger technique that is commonly maintained by multiple nodes to de-trust and de-center that once data is uploaded to the blockchain through the verification of the blockchain node, it will be permanently stored and not tampered with. Because of the characteristics of the blockchain, such as trust-free storage, tamper resistance, traceability, disclosure transparency and the like, research researchers at home and abroad have made more researches on the application of the blockchain in the Internet of things system, and the safe and reliable storage of the Internet of things data is realized; and the intelligent contract is utilized to realize automatic monitoring of equipment and equipment data management.
Because the intelligent device in the scene of the Internet of things has the characteristics of high sampling frequency, large sampling data volume and the like, if all data are stored on the same blockchain, the storage capacity of the blockchain node can be challenged greatly, and meanwhile, the management and the use of the data are not facilitated. In the prior art, data generated by each subsystem are stored in different sub-chain blockchains, and data interaction among the sub-chains is realized by utilizing a main chain.
The above study, while the data is stored in a plurality of blockchains in a scattered manner by a multi-chain cross-chain manner, achieves data interaction between different subsystems while relieving the storage pressure of blockchain nodes, but involves a smaller number of blockchain nodes. In an actual scene, an internet of things system is generally composed of a plurality of sub-domain systems, the number of block chain links forming a main chain is large, and the common-knowledge time delay among nodes cannot meet the actual use requirement of the system; in addition, the operation requests generated by the internet of things system can be divided into different priorities, the response time requirements of the system acceptance standard on various operation requests are different, and in the prior art, although a request processing strategy based on a multi-priority queue is designed, the processing logic is simpler, and the requests of the priorities are difficult to process efficiently and timely.
Aiming at the problem that the common delay of the block chain in the related technology cannot meet the actual use requirement of the system, no effective solution has been proposed yet.
Disclosure of Invention
Aiming at the technical problem of long consensus time delay, the invention provides a block chain-based cross-link interaction method of an Internet of things system.
In order to achieve the above object, the present invention provides the following technical solutions:
in a first aspect, the invention provides a blockchain-based internet of things system cross-link interaction method, which comprises the following steps:
a main chain consensus node selection step, namely deploying a node credit model on the main chain nodes, periodically updating credit values of all the main chain nodes, and selecting at least one main chain node with the highest credit value as the main chain consensus node of the current round of consensus period;
a user request interaction step, wherein a user initiates a user request for a target sub-chain by accessing a sub-system corresponding to a source sub-chain;
a right verification step, wherein a source sub-link point corresponding to a source sub-link fuses user requests into a cross-link request packet according to a priority policy module, and the cross-link request packet is used as a cross-link transaction contract of a main chain, the cross-link transaction contract internally verifies the user right of each user request in the cross-link request packet, and if verification is successful, a main chain consensus node throws out a cross-link request event;
And in the request response step, a target sub-link point corresponding to the target sub-link monitors a cross-link request event, analyzes and acquires a user request aiming at the target sub-link, executes the user request, feeds back an execution result to a source sub-link node, and feeds back the received execution result to a user.
Preferably, the authority verification step further includes an authority control tree generation step before the authority verification step, including the steps of:
defining a user's authority control strategy for the subsystem, calling an authority control contract deployed on the main chain, generating a corresponding authority control tree by splitting and combining the authority control strategy, and storing the authority control tree into the main account book, wherein the authority control tree is used for verifying the user authority requested by the user.
Preferably, the authority control tree generating step further includes:
transmitting the authority control strategy into the authority control contract in the form of character strings, wherein the authority control strategy comprises attributes and relations;
defining the structure of nodes in the authority control tree in the authority control contract, wherein the nodes comprise root nodes and other nodes;
obtaining a character string array only comprising attributes and the relationship of U by utilizing a U-shaped character screening authority control strategy, and then screening each item of the character string array by utilizing the U-shaped character to obtain a two-dimensional character string array;
Traversing the two-dimensional character string array generated in the steps, connecting each item of the two-dimensional character string array by using a pointer to form a subtree, and connecting all the subtrees to a root node to form a permission control tree.
Preferably, the updating process of the reputation value in the main chain consensus node selection step specifically comprises the following steps:
the method comprises the steps that a reputation value obtaining step is carried out on each main chain node, wherein each main chain node obtains a reputation value of each main chain node in the previous cycle of consensus period by calling a node reputation value obtaining contract, and the total score of the reputation value of each main chain node is obtained by combining hardware indexes of each main chain node and the consensus voting result in the previous cycle of consensus period according to the reputation value obtaining contract, and a node reputation value list is generated;
broadcasting the node credit value list calculated by each main chain node and the signature to the node credit value list to other main chain nodes through a network, when any main chain node collects the node credit value list of more than 2/3 other main chain nodes, the main chain node calls a node credit value update contract, and the collected node credit value lists are used as parameters to be transmitted into the node credit value update contract;
a step of updating the credit value, in which a node credit value updating contract checks the correctness of each main chain node for the signature, when the verification is passed, the total credit value score of each main chain node is calculated, the calculation result is recorded in a main chain account book, and a node credit value updating event is thrown out;
And monitoring the reputation value updating event, namely binding and monitoring the node reputation value updating event by each main chain node, and triggering the step when the event is thrown out and waiting for the start of the next consensus period, wherein the updating flow of the reputation value of the current round is ended.
Preferably, the reputation value obtaining step further comprises:
a static score obtaining step, wherein the main chain node uses CPU core number and memory as credit value calculation indexes, and the static score of each main chain node is calculated and updated through the following formula;
wherein ,Mi Represents the memory size (unit is GB) of the main chain node i, M max 、M min Representing the maximum memory and the minimum memory in all main chain nodes; u (U) i CPU core number, U, representing main chain node i max 、U min Representing the maximum CPU core number and the minimum CPU core number in all main chain nodes; alpha represents a first weight parameter, and 0<α<1；
A dynamic score obtaining step, namely calculating and updating the dynamic score of each main chain node according to the consensus voting result and the dynamic score of the main chain node in the last round of consensus period through the following formula;
wherein ,dynamic fraction of backbone node i in t-th round consensus period,/>A t-1 round dynamic score; beta represents a second weight parameter, and 0<β<1；N r 、N w Representing the number of times that the node throws valid tickets and invalid tickets in the consensus period;
And obtaining the total score of the reputation value, namely carrying out weighted summation on the static score and the dynamic score to calculate the total score of the reputation value of each main chain node.
Preferably, the step of fusing the user request into the cross-chain request packet by the source sub-link point according to the priority policy module includes:
the source sub-link point caches the source sub-link point into different request lists of a local request pool according to the priority of the user request, periodically loads a priority policy module and respectively sorts the user requests in the different lists;
the source sub-link point obtains a corresponding number of user requests from each list of the local request pool according to one or a combination of the sequencing result, the preset single-round maximum request submission number and each priority request acquisition proportion, fuses the obtained user requests into a cross-link request packet, and transmits the cross-link request packet as a parameter into a cross-link transaction contract of a main chain.
Preferably, the request processing flow of the priority policy module includes the following steps:
the source sub-link node acquires a request list of each priority from a local request pool, wherein the request list comprises a high-priority request list, a medium-priority request list and a low-priority request list;
traversing the three request lists, updating the waiting time of each user request in a local request pool, and calculating the residual waiting time according to the maximum response time of each user request;
And respectively carrying out ascending sort on the user requests of each request list in the local request pool by taking the residual waiting time as a sorting basis, and updating the sorted results to the local request pool.
Preferably, the method further comprises a data storage step between the main chain consensus node selection step and the user request interaction step, and specifically comprises the following steps:
the target sub-chain edge gateway calls a data acquisition interface to acquire related data from corresponding subsystem equipment;
the target sub-chain edge gateway calls an IPFS interface to upload the acquired data to the IPFS network and acquire a corresponding data storage address, calls a data storage contract of the target sub-chain to store the data storage address into a target sub-chain account book, and throws out a storage success event;
the target sub-chain server binds and monitors a successful event of data storage, when the event is thrown out, the target sub-chain server acquires the transaction ID and the block number of the data storage transaction and constructs a sub-chain data log record, invokes a data log storage contract of a main chain and initiates a storage request of the chain data log record, assembles the storage request into blocks after the consensus of the main chain consensus node, and records the blocks into a main account book.
Preferably, the step of verifying the user right requested by the user further comprises:
And acquiring a user attribute list and a request type by analyzing a user request, acquiring a corresponding authority control tree according to the request type, comparing the authority control tree with the user attribute list, if the user attribute traverses to a node of the authority control tree, indicating that the user has the execution authority of the request type, otherwise, indicating that the user does not have the execution authority of the request type.
Preferably, the main chain consensus node selection step further comprises an environment deployment step, specifically comprising the following steps:
installing and deploying a blockchain operation environment on an edge gateway and a server, and forming corresponding sub-chains and main chains by using the edge gateway and the server as blockchain link points, wherein the edge gateway is used as the sub-chain link points, and the server is used as a sub-chain node and/or main chain node.
Compared with the prior art, the embodiment of the application provides a block chain-based cross-link interaction method of an Internet of things system, which can be applied to the technical field of building Internet of things or the technical field of manufacturing Internet of things and has the following advantages:
1. by disposing the node credit model on the main chain node and selecting the main chain node with the highest credit value as the main chain consensus node, the consensus efficiency and throughput can be effectively improved;
2. And the priority policy module is utilized to realize efficient response of the user request.
3. Fine-grained user access rights control is achieved through the rights control tree structure.
4. And the hardware factors and the consensus indexes of the nodes are combined to construct a node reputation model, factors influencing the authentication efficiency of the system under a fixed consensus algorithm are considered, and the accuracy of the main chain consensus node is effectively improved.
Drawings
Fig. 1 is a schematic diagram of a cross-link interaction method of a blockchain-based internet of things system according to an embodiment of the present application;
FIG. 2 is a process of constructing a rights control tree according to an embodiment of the present application;
FIG. 3 is a flowchart of a method for updating a node reputation value in a main-chain consensus node selection step according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a method for updating a node reputation value in a main-chain consensus node selection step according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a request processing flow of a priority policy module according to an embodiment of the present application;
FIG. 6 is a schematic diagram of a visitor reservation registration model based on a cross-chain interaction method according to an embodiment of the present application;
fig. 7 is a schematic flow chart of visitor reservation registration based on a cross-link interaction method according to an embodiment of the present application.
Detailed Description
Hereinafter, embodiments of the present application will be further described with reference to the accompanying drawings.
The intelligent device in the scene of the Internet of things has the characteristics of high sampling frequency, large sampling data volume and the like, and if the data are all stored on the same blockchain, the storage capacity of the blockchain node can be challenged greatly, and meanwhile, the management and the use of the data are not facilitated. The prior study realizes data interaction among different subsystems while relieving the storage pressure of block chain link points through a multi-chain cross-chain mode, but the number of the related block chain nodes is small. With the continuous expansion of the scene scale of the Internet of things and the continuous increase of the number of the block chain nodes, the consensus time delay of the block chain cannot meet the actual use requirements of the system. In addition, in the existing blockchain related research, processing logic for multi-priority requests is simple, and it is difficult to efficiently and timely process each priority request.
Accordingly, the application provides a block chain-based cross-link interaction method of an Internet of things system, which is used for reducing the consensus time delay of a block chain and efficiently processing operation requests with different priorities on the premise of realizing data interaction of all subsystems of the Internet of things.
The embodiment of the application provides a blockchain-based cross-link interaction method of an Internet of things system, wherein a flow chart of the method is shown in fig. 1, and before the formal cross-link interaction method is carried out, an environment deployment step S1 is needed to be carried out firstly, and the method specifically comprises the following steps: installing and deploying a blockchain operation environment on an edge gateway and a server, and forming corresponding sub-chains and main chains by using the edge gateway and the server as blockchain link points, wherein the edge gateway is used as the sub-chain link points, and the server is used as a sub-chain node and/or main chain node.
Specifically, taking the internet of things as an example, the building intelligent subsystem comprises, but is not limited to, a building control system, an environment monitoring system, a fire protection system, a security protection system, a parking lot management system and/or an intelligent access control system.
It should be noted that the edge gateway serves only as a blockchain node for the sub-chain, and the server serves as both a blockchain node for the sub-chain and the backbone.
It should be noted that, in the embodiment of the present application, there are fewer blockchain nodes that make up the sub-chain, typically between 3 and 4, so all blockchain nodes of the sub-chain are set as consensus nodes.
It should be added that the edge gateway and server must meet the memory and hard disk space necessary to deploy the blockchain operating environment, otherwise the sub-chains and/or the main chains will not operate properly, thus having high requirements on the performance of the edge gateway and server.
It should be noted that different intelligent subsystems may share the same edge gateway and/or server.
The method further comprises the steps of:
step S3, a main chain consensus node selection step is carried out, a node credit model is deployed on the main chain nodes, credit values of the main chain nodes are updated periodically, and at least one main chain node with the highest credit value is selected as the main chain consensus node of the common consensus period of the round;
specifically, the backbone consensus node may be selected according to a preset consensus node threshold N within the node reputation model.
Specifically, the node reputation model is deployed as a local model in each backbone node for periodically calculating a reputation value for each backbone node (i.e., server).
It should be noted that, the calculation period of the reputation value (i.e., the consensus period) and the consensus node threshold value are written into the model when the model is initialized, and need to be set before the model is run.
Preferably, a flow diagram of a node reputation value updating method in the main-chain consensus node selection step is shown in fig. 3, a model diagram is shown in fig. 4, and the reputation value updating flow in the main-chain consensus node selection step specifically comprises the following steps:
step S31 of obtaining the reputation value, wherein each main chain node obtains the reputation value of each main chain node in the previous cycle of consensus period by calling the node reputation value to obtain contracts, and the total score of the reputation value of each main chain node is obtained by combining the hardware index of each main chain node and the consensus voting result in the previous cycle of consensus period according to the reputation value, and a node reputation value list is generated;
A reputation value broadcasting step S32, wherein each main chain node broadcasts a node reputation value list calculated by each main chain node and a signature on the node reputation value list to other main chain nodes through a network, when any main chain node collects node reputation value lists of more than 2/3 other main chain nodes, the main chain node calls a node reputation value updating contract, and the collected node reputation value lists are used as parameters to be transmitted into the node reputation value updating contract;
specifically, the signature in the reputation value broadcasting step S32 refers to data generated after the main node server processes the reputation value list by using a private key and elliptic curve signing algorithm.
It should be noted that, all servers, edge gateways and/or system users will use elliptic curve cryptography to generate public-private key pairs, public keys are disclosed for data encryption and verification of private key signatures, and private key confidentiality is used for data decryption and identification.
A step S33 of updating the credit value, in which a node credit value updating contract checks the correctness of each main chain node for the signature, when the verification is passed, the total score of the credit value of each main chain node is calculated, the calculation result is recorded in a main chain account book, and a node credit value updating event is thrown out;
Specifically, the verification of the correctness of the signature in the above steps means that the signature is decrypted by using the public key of the main chain node server, and whether the decrypted data and the original credit value list are consistent or not is compared.
The server public key has been stored into the backbone and each subchain ledger at blockchain initialization.
Specifically, the node reputation value updating event in the above step refers to that after executing the node reputation value updating contract, the event API interface provided by the blockchain platform is called to feed back the user-defined content to the node monitoring the event; other events mentioned later are similar and will not be described in detail.
It should be noted that, the foregoing feedback includes, but is not limited to, a current consensus period, a reputation value of each node after updating, an update time, and the like.
And S34, binding and monitoring node reputation value updating events by all main chain nodes, and triggering the steps when the events are thrown out, wherein the updating flow of the reputation value of the current round is ended and the next consensus period is waited.
Specifically, the binding and listening event in the reputation value update event listening step S34 is implemented through an SDK interface function provided by the blockchain platform.
Preferably, the reputation value acquisition step S31 further includes:
In the Static score obtaining step S311, the main chain node uses the CPU core number and the memory as the reputation value calculation index, calculates and updates the Static score of each main chain node by the following formula, assuming that the current main chain node is i, and the node Static score is Static i ；
wherein ,Mi Represents the memory size (unit is GB) of the main chain node i, M max 、M min Representing the maximum memory and the minimum memory in all main chain nodes; u (U) i CPU core number, U, representing main chain node i max 、U min Representing the maximum CPU core number and the minimum CPU core number in all main chain nodes; alpha represents a first weight parameter, and 0<α<1；
A Dynamic score obtaining step S312, according to the consensus voting result and the Dynamic score of the last round of consensus period of the main chain node, calculating and updating the Dynamic score of each main chain node through the following formula, and assuming that the current main chain node is i, and Dynamic represents the Dynamic score of the main chain node i;
wherein ,dynamic fraction of backbone node i in t-th round consensus period,/>A t-1 round dynamic score; beta represents a second weight parameter, and 0<β<1；N r 、N w Representing the number of times that the node throws valid tickets and invalid tickets in the consensus period;
specifically, the node consensus voting in the dynamic score acquisition step includes three cases of True, false, and non-voted, true represents a data consistency vote support, false represents an anti-vote.
The judgment basis of the effective ticket and the ineffective ticket is as follows: when nodes are commonly recognized, true is a valid ticket, false and not voted is an invalid ticket; when the consensus fails, true and not voted for invalid tickets, false for valid tickets.
It should be noted that, in order to facilitate score comparison and prevent the excessive dynamic score gap between nodes, the above two calculation methods are adopted to control the dynamic score between 0 and 1: when N is r -N w >0, adopting a first calculation mode of the formula (2) to reduce the score encouragement of the nodes with high reputation values and improve the score encouragement of the nodes with low reputation values; when N is r -N w <And 0, adopting a second calculation mode of the formula (2), reducing the point penalty on the nodes with low reputation values, and increasing the point penalty on the nodes with high reputation values.
It should be noted that only the dynamic score of the consensus node in the last consensus cycle is updated, and the dynamic score of the non-consensus node is unchanged.
It should be noted that when the blockchain network is initialized, the backbone nodes do not start to be commonly known, the dynamic score is 0, and at this time, the commonly known nodes are selected according to the hardware configuration information (i.e., the static score) of the backbone nodes.
And a reputation value total score obtaining step S313, wherein the static score and the dynamic score are weighted and summed to calculate the reputation value total score of each main chain node.
Specifically, the formula of the total score of the reputation value in the above step is shown as formula (3), whereinRepresenting the total score of the reputation value of the main chain node i in the t-th round consensus period; lambda represents a third weight parameter, and 0<λ<1。
Taking the model diagram of fig. 4 as an example, the node reputation value updating method is described.
1. Backbone server 1, 2..n, obtaining reputation values for each backbone node for the last cycle of consensus period;
2. each main chain server calculates and updates the credit value of each main chain node;
3. each main chain server broadcasts a node credit value list calculated by the main chain server and a signature to the node credit value list;
4. invoking a node reputation value update contract of a main chain, and transmitting the collected reputation value lists into the node reputation value update contract as parameters;
5. updating contract checking signature by the node reputation value, and taking the median as the total score of the reputation value of each node after the checking is passed;
6. the main chain consensus nodes carry out consistency consensus;
7. packing the blocks and storing;
8. each main chain server monitors the node reputation value updating event, and the reputation value updating flow of this round is ended.
Step S5, user request interaction, namely, a user initiates a user request for a target sub-chain by accessing a sub-system corresponding to a source sub-chain;
Specifically, the source sub-chain refers to a sub-chain corresponding to a subsystem that generates a certain user request.
Specifically, the data structure of the user request is shown in table 1, including but not limited to a source sub-chain number, a destination sub-chain number, a user identification, request details, priorities, request times, and maximum response times.
TABLE 1
It should be noted that the user identifier is composed of a user number and a user certificate, and is used for identifying and verifying the user identity. The user certificate is generated by a special third party certificate authority center during user registration and is used for storing information such as a user public key, a user attribute set, an authority center number, a public key of the authority center, a certificate valid time and the like; the priority, i.e. the priority level of the request, is in this embodiment divided into high, medium and low three types;
the request time is the time when the user request is generated; the maximum response time is preset according to the type of the user request (the unit is seconds), and if the maximum response time is set to be 5 seconds, the system is required to finish the request execution within 5 seconds; the details of the request are used to record details of the user request, and the data structure is shown in table 2, including but not limited to source subsystem number, target subsystem number, request type, interface name, request parameters, and error handling.
TABLE 2
The source subsystem number indicates the number of the subsystem that generated the user request; the target subsystem number represents the number of the subsystem that handled the request; request types include, but are not limited to, contract queries, contract updates, and chain operations; the interface name is used for identifying the function name of the function interface to be called; the request parameters are used for recording a parameter list which is required to be transmitted when the interface is called; error handling includes retry and termination of both types.
Step S6 of authority verification, the source sub-link points corresponding to the source sub-links fuse the user requests into a cross-link request packet according to a priority policy module, the cross-link request packet is used as a cross-link transaction contract of a main chain, the cross-link transaction contract internally verifies the user authority of each user request in the cross-link request packet, and if verification is successful, the main chain consensus node throws out a cross-link request event;
it should be noted that, when the priority policy module is initialized, the module loading period is already written into the module, and needs to be set before the server runs.
In practical application, if verification is passed, the main chain consensus node agrees with the consistency of the content of the cross-link request packet, generates a block and stores the block into a main chain account book, and throws out the cross-link request event in a contract; if the verification is not passed, the user request is removed from the cross-link request packet, and verification failure information is fed back to the source sub-link server corresponding to the request.
Specifically, the user authority verification means that a user attribute list in a certificate is acquired by analyzing a user request, an authority control tree stored in an account book is acquired according to a request type and is compared with the user attribute list, and if the user can traverse leaf nodes of the authority control tree according to the user attribute, the user is indicated to have the execution authority of the request type; and otherwise, indicating that the user does not have the execution authority of the request.
It should be noted that, when the user attribute performs attribute initialization during user registration, if the user wants to update the attribute, the user needs to apply for certificate update to the certificate authority.
In particular, the traversal authority control tree is implemented by depth first search (DFS, deep First Search), ensuring that each sub-tree can be traversed in its entirety.
Specifically, after the event content of the cross-link request event is subjected to authority verification, the cross-link request packet only contains the cross-link request packet effectively requested by the user.
And S7, a request response step is carried out, a target sub-link point corresponding to the target sub-link monitors a cross-link request event, a user request aiming at the target sub-link is obtained through analysis, the user request is executed, an execution result is fed back to a source sub-link node, and the source sub-link point feeds back the received execution result to a user.
Specifically, the target sub-chain server binds and monitors a cross-chain request event, and when the event is thrown, the server analyzes the content of the cross-chain request packet, acquires a user request aiming at the self-chain and executes the request. The target sub-chain server feeds back the execution result to the source sub-chain server, and invokes the main chain cross-chain transaction update contract to update the cross-chain transaction execution result to the main chain account book, and the source sub-chain server receives the execution result of the user request and feeds back the execution result to the user.
Specifically, executing the user request refers to obtaining an interface name and a request parameter to be called through analyzing the user request, then judging the request type, and if the request type is a contract inquiry or contract update type, calling a contract interface corresponding to the interface name by using an SDK provided by the blockchain platform; and if the operation type is the under-chain operation type, calling a function module corresponding to the interface name in the server.
It should be noted that, when executing the user request fails, if the error handling manner of the user request is retried, the destination sub-chain server will repeatedly execute the user request until the request is executed successfully or the execution times exceed the predefined upper limit; if the error processing mode is terminated, the execution failure information is directly fed back to the source sub-chain server, and the request is not repeatedly executed.
Since the servers share information such as the server ID and the IP address at the time of initialization, the destination sub-chain server may directly transmit the execution result to the source sub-chain server by means of an HTTP request.
Specifically, the cross-chain execution results include, but are not limited to, the following fields: transaction ID, execution result and execution time, wherein the execution result comprises two conditions of Success and Failed, the Success indicates that the user request corresponding to the transaction ID is successfully executed, and the Failed indicates that the execution fails.
Preferably, the authority verification step S6 is preceded by an authority control tree generation step S2, which includes the following steps:
defining a user's authority control strategy for a subsystem, calling an authority control contract deployed on a main chain, generating a corresponding authority control tree by splitting and combining the authority control strategy, and storing the authority control tree into the main chain account, wherein the authority control tree is used for verifying the user authority requested by the user.
Specifically, the authority control contracts and other intelligent contracts mentioned in the embodiment of the present application have been successfully deployed into the main chain (or sub-chain) through the consensus of the blockchain consensus node before the main chain (or sub-chain) runs, and the user can call the intelligent contracts to execute corresponding functions through the SDK interface provided by the main chain (or sub-chain); the smart contracts mentioned later are similar to them and will not be described again.
Specifically, the users include, but are not limited to, project managers, subsystem administrators, operation and maintenance engineers and/or cell households, wherein the project managers are project administrators responsible for dispatching and confirming the fault (or alarm) problems of each subsystem device; the subsystem administrator is responsible for device management and/or rights control policy definition within a single subsystem; the operation and maintenance engineer is responsible for equipment maintenance and/or equipment daily inspection; the residential home can perform customer service complaints, equipment maintenance applications, and/or indoor equipment management.
Specifically, the permission control policy is used to determine whether the user has permission to execute a function.
Preferably, as shown in fig. 2, the authority control tree generating step S2 further includes:
s21: transmitting the authority control strategy into the authority control contract in the form of character strings, wherein the authority control strategy comprises attributes and relations;
specifically, the attribute refers to a custom attribute, for example, character strings such as "admin", "write", "read" and the like can be used as the attribute; the relationship includes "intersection" and "union" (for convenience of description and use, ".u" and ". U" are used in the authority control policy string), ".u" relationship indicates that the attributes on both sides of the relationship symbol must all be contained, and "" relationship indicates that the attributes on both sides of the relationship symbol contain any one. Illustratively, an "admin" authority control policy string indicates that a user must possess an "admin" attribute and must possess one of the "write" or "read" attributes.
The authority control strategy character string is stored in the blockchain in a key-value key pair form, wherein the key is an operation code number which needs to be subjected to authority control: illustratively, "01" represents read data, "02" represents write data, etc.; "value" is the entitlement control policy string for the corresponding operation: for example, "admin U read", "admin U write", etc., and "key" and "value" are set by an administrator according to the actual situation.
S22: defining the structure of nodes in the authority control tree in the authority control contract, wherein the nodes comprise root nodes and other nodes;
specifically, the root Node includes two parts of an attribute value Val and other Node pointer set Node, and the other Node includes two parts of an attribute value Val and a pointer Next to the Next Node.
S23: screening the authority control strategy by utilizing U-shaped characters to obtain a character string array only comprising attributes and the relationship of U, wherein the character string array is exemplified by [ "A-U-B", "B-U-C ], and then screening each item of the character string array by utilizing U-shaped characters to obtain a two-dimensional character string array;
it should be noted that, each item in the two-dimensional character string array is a subtree of the authority control tree, and a value in each item is an attribute value Val of a node in the subtree.
S24: traversing the two-dimensional character string array generated in the steps, connecting each item of the two-dimensional character string array by using a pointer to form a subtree, and connecting all the subtrees to a root node to form a permission control tree.
Preferably, the step of verifying the user right requested by the user using the right control tree further includes:
and acquiring a user attribute list and a request type by analyzing a user request, acquiring a corresponding authority control tree according to the request type, comparing the authority control tree with the user attribute list, if the user attribute traverses to a node of the authority control tree, indicating that the user has the execution authority of the request type, otherwise, indicating that the user does not have the execution authority of the request type.
Preferably, the step of fusing the user request into the cross-chain request packet by the source sub-link point according to the priority policy module includes:
s61: the source sub-link point caches the source sub-link point into different request lists of a local request pool according to the priority of the user request, periodically loads a priority policy module and respectively sorts the user requests in the different lists;
s62: the source sub-link point obtains a corresponding number of user requests from each list of a local request pool according to one or a combination of a sequencing result, a preset single-round maximum request submitting number and each priority request obtaining proportion, fuses the obtained user requests into a cross-link request packet, and transmits the cross-link request packet as a parameter into a cross-link transaction contract of a main chain.
Specifically, a corresponding number of user requests are obtained from three request lists according to a preset single-round maximum request submission number and each priority request obtaining proportion. By way of example, the maximum number of requests submitted per round is set to 100, and the acquisition rates of the high, medium, and low priority requests are 50%, 30%, and 20%, respectively (i.e., 50, 30, and 20 user requests are acquired from each request list, respectively).
It should be noted that, when the preset maximum number of single-round request submissions is smaller than the user request amount, the user requests to be fused are obtained in combination with the sequencing result.
It should be noted that, when the source sub-link point (in the embodiment of the present application, the server) obtains the request of the local request pool, the obtaining proportion of the requests with different priorities is dynamically adjusted according to the current request number in the request pool. Illustratively, assume that the current number of requests in the high, medium, and low priority are 100, 10, 30, respectively, where the current number of requests in the high and low priority lists is higher than the default number of request acquisitions (50, 20 requests) and the medium priority list number of requests is lower than the default number of request acquisitions (30 requests). Therefore, the server will adjust the acquisition numbers of the high, medium and low priority requests to 70, 10 and 20 under the condition of meeting the maximum request submission number (100 requests), i.e. when the current request number of individual priority is lower than the default request acquisition number, the request with higher priority is processed as first as possible.
Specifically, the data structure of the cross-chain request packet is shown in table 3, and includes a server ID, a user request list, a commit time, and a server signature.
TABLE 3 Table 3
| Server ID | User request list | Commit time | Server signature |
The user request list refers to a list formed by each user request obtained from the request pool; the commit time refers to the time the source sub-chain server invokes the cross-chain transaction contract; the server signature is data generated by the source sub-chain server after splicing the first three fields of the cross-chain request packet and signing the spliced fields by using a private key and elliptic curve signature algorithm.
Preferably, as shown in fig. 5, the request processing flow of the priority policy module includes the following steps:
s611: the source sub-link node acquires a request list of each priority from a local request pool, wherein the request list comprises a high-priority request list, a medium-priority request list and a low-priority request list;
specifically, the local request pool in the above steps may be implemented by using a database, a structure variable, or the like.
S612: traversing the three request lists, updating the waitdtime of each user request in the local request pool, and calculating the residual waiting time according to the maximum response time respTime of each request;
Specifically, the waiting time in step S612 is calculated from the current time and the request time within the user request by the following formula.
spareTime＝respTime-waitedTime
S613: and respectively carrying out ascending sort on the user requests of each request list in the local request pool by taking the residual waiting time as a sorting basis, and updating the sorted results to the local request pool.
Specifically, the ascending sort is implemented using a stable sort algorithm to ensure that the order of execution of multiple requests of the same remaining latency is unchanged.
Preferably, a data storage step S4 is further included between the main-chain consensus node selection step S3 and the user request interaction step S5, specifically including:
firstly, a target sub-chain edge gateway calls a data acquisition interface to acquire related data from corresponding subsystem equipment;
specifically, the target sub-chain refers to a sub-chain pointed by a target system to which a user request is sent when responding to the user request.
Specifically, the data acquisition interface refers to an interface preset by an intelligent device manufacturer for intelligent devices and specially used for other users or devices to acquire data of the intelligent devices.
In particular, the relevant data includes, but is not limited to, device status information, device operational data, and/or ambient information collected by the smart device.
Then, the target sub-chain edge gateway calls an IPFS interface to upload the acquired data to the IPFS network and acquire a corresponding data storage address, calls a data storage contract of the target sub-chain to store the data storage address into a target sub-chain account book, and throws out a storage success event;
specifically, IPFS (i.e., interstellar file system) is a decentralized distributed storage system that stores data in the form of files, generates unique hash values through the file contents to identify the files, is used to relieve the storage pressure of blockchain nodes, and solves the operational inconveniences caused by blockchain storage of file type data.
Specifically, the data storage address refers to a unique hash value of the identification file storage address returned by the IPFS network after the collected data is stored in the form of a file in the IPFS network.
It should be noted that, in the IPFS network, only relevant data collected by the edge gateway from the intelligent device and part of non-text data (such as an equipment manual, an analysis report, a historical video stream file, etc.) generated by each subsystem are stored, and temporary files such as a visitor face image, a real-time video stream, etc. and other text data are not stored in the IPFS.
Specifically, the content of the successful storage event is the relevant information of the data storage transaction, including but not limited to transaction ID, block number, data type, data storage address, and storage time. Wherein, the transaction ID refers to the transaction ID corresponding to the data storage transaction; the block number refers to the block ID of the block where the storage transaction is located; the data type is used to identify the data type of the data to be stored, including but not limited to device sample data, device ledger information, personnel information.
And finally, binding and monitoring a successful event of data storage by the target sub-chain server, when the event is thrown out, acquiring a transaction ID and a block number of the data storage transaction, constructing a sub-chain data log record, calling a data log storage contract of a main chain and starting a storage request of the data log record, assembling the storage request into a block after the consensus of a main chain consensus node, and recording the block into a main account book.
Specifically, the data structure of the sub-link data log record is shown in table 4, including, but not limited to, a sub-link number, a data type, a transaction ID, a sub-link block number, and a generation time.
TABLE 4 Table 4
| Sub-chain numbering | Data type | Transaction ID | Sub-chain block number | Time of generation |
The sub-chain number is used for uniquely identifying the sub-chain, and the numbers of the main chain and each sub-chain are allocated when the block chain is initialized; the transaction ID refers to a transaction ID corresponding to the sub-chain data storage transaction;
the sub-chain block number refers to the block ID of the block in the sub-chain in which the transaction is stored.
For a further understanding of the present patent application, more specific examples are set forth below. The following application embodiments are examples of visitor reservation registration based on a cross-link interaction method, fig. 6 is a schematic diagram of a model of visitor reservation registration based on a cross-link interaction method provided by the embodiment of the present application, and fig. 7 is a schematic diagram of a flow of visitor reservation registration based on a cross-link interaction method provided by the embodiment of the present application. The edge gateway and the server are installed and deployed with a blockchain running environment, and serve as blockchain link points to form corresponding sub-chains and main chain networks; the node reputation model and the priority policy module are deployed and operated in the server, so that the periodic selection of the main chain consensus node and the multi-priority processing of the user request can be automatically performed; each subsystem administrator has stored the rights control policies for the subsystem into the blockchain.
The embodiment of the application comprises the following steps:
s701: and the client is about to enter an industrial park and enterprise docking service, uses the APP provided by the visitor management system to carry out visitor reservation registration, inputs visitor basic information, face images, access to the enterprise, reservation time and other information, and submits the information.
Specifically, the visitor base information includes, but is not limited to, visitor name, the business to which the visitor belongs, and contact phone.
S702: assuming that a Server corresponding to the visitor management system is server_a, a corresponding sub-Chain is chain_a, and after receiving a reservation registration request of a visitor, the server_a calls a reservation registration contract deployed on the chain_a to store the reservation registration request of the visitor into an account book of the chain_a.
Specifically, the guest reservation registration request includes, but is not limited to, the following fields: visitor name, the business to which the visitor belongs, contact phone, visitor reason, face image, visiting business, reservation time.
S703: and the manager checks and approves the reservation registration request of the visitor, and after the approval is passed, the server_A invokes the visitor reservation approval contract deployed on the chain_A to update the state of the reservation registration application.
Specifically, the administrator refers to an administrator to which the client accesses the enterprise, and the enterprise administrator approves the reservation registration request of the client.
Specifically, the update reservation registration application state refers to storing the approval result and the approval signature of the enterprise administrator in the chain_a. The examination result comprises three conditions of non-examination, examination passing and examination failing, if the examination fails, the Server_A directly feeds back examination failing information to the client, and the subsequent flow is not executed any more; the approval signature is a signature of the character string after splicing the visitor reservation registration request and the approval result by using an enterprise administrator private key and an elliptic curve signature algorithm.
S704: after the server_A successfully calls the visitor reservation approval contract, a user Request is generated and cached in a local Request pool, and the user Request is used for initiating a Request (request_B) to a Server (server_B) corresponding to the intelligent access control system, so that the specified channel access permission is opened for the visitor.
Specifically, the priority level of the user request may be customized by a subsystem administrator at the time of server initialization, and in the embodiment of the present application, the user request is set to a low priority level.
In particular, the designated lanes include, but are not limited to, must-route and other backup routes from the industrial park entrance to the enterprise doorway.
S705: the server_A obtains user requests with different proportions from each list of the local Request pool, fuses the request_B and other requests into a cross-link Request packet, and transmits the cross-link Request packet into a cross-link transaction contract of a main chain as a parameter.
S706: and verifying the user authority of each user Request including the request_B in the cross-link Request packet in the cross-link transaction contract, if the verification is not passed, rejecting the user Request from the cross-link Request packet, and feeding back verification failure information to a source sub-link server corresponding to the Request.
It should be noted that, in the embodiment of the application, the visitor does not need to register the user before the reservation registration, so that the authority judgment is not performed by traversing the authority control tree according to the user attribute, and only whether the enterprise administrator signs the reservation registration request of the visitor or not is checked, and the correctness of the signature is checked.
S707: after verification, the main chain consensus node agrees with the consistency of the content of the cross-link request packet, generates a block and stores the block into a main chain account book, and throws out the cross-link request event in the contract.
S708: server_B binds and triggers a cross-link Request monitoring event, analyzes the content of the cross-link Request packet, and acquires a user Request request_B for the self-link.
S709: the server_B analyzes the request_B, constructs a guest face image, an access enterprise name, an access time and a Request authorization path into a path authorization Request, and sends the path authorization Request to an edge gateway B corresponding to the intelligent access control system.
It should be noted that, the IP information of the server and the edge gateway are already shared with each other when the server (and the edge gateway) is initialized, and in the embodiment of the present application, an HTTP request mode is used to send a path authorization request to the edge gateway B.
S7010: and the edge gateway B receives the path authorization request, and imports the face information into the corresponding access control equipment to open a designated channel for the visitor.
Specifically, the corresponding access control devices refer to all access control devices contained in the request authorization path.
S7011: and the edge gateway B returns the channel path opening information to the Server_B, simultaneously and concurrently invokes the path authorization log storage contract, and stores the authorization record in the sub-Chain chain_B corresponding to the intelligent access control system.
Specifically, the channel path opening information includes, but is not limited to, the following fields: visitor name, authorization path, authorization valid time.
Specifically, the authorization record includes, but is not limited to, the following fields: visitor basic information, visitor face image information, an authorization path, an authorization time, and an authorization valid time.
S7012: server_B calls a cross-link transaction update contract of the main chain, and updates information of successful execution of the request_B into the main chain account book.
S7013: the server_b returns the channel path authorization information to the server_a.
S7014: and the server_A feeds back the received channel path authorization information to the client.
Specifically, the information feedback refers to that channel path authorization information is returned to a mobile phone APP of a client and/or the client is informed in a short message form.
As shown in the model of fig. 6, taking successful visitor reservation registration as an example, the working condition of each node in the visitor reservation registration process is described, and in the figure: 1. registering a visitor appointment; 2.1, a reservation registration request; 2.2, calling a reservation registration contract; 2.3, storing a reservation registration request; 3.1, checking and approving by an administrator; 3.2, calling a visitor reservation approval contract; 3.3, updating the state of the reservation registration application; 4. the server Sever_A generates a user request; 5. the server Sever_A constructs a cross-link request packet and transmits the cross-link request packet into a cross-link transaction contract; 6. verifying user rights across chain trade contracts; 7. the verification is passed, and the user request is stored; 8. the server Sever_B successfully monitors the event and analyzes and acquires the request_B of the user; 9. constructing a path authorization request and sending the path authorization request to an edge gateway B; 10. leading the face information into corresponding access control equipment; 11.1, the edge gateway B returns channel path opening information; 11.2, concurrently invoking a path authorization log storage contract with 11.1; 11.3, storing an authorization record; 12.1, transmitting the execution result of the request_B into a cross-chain transaction update contract; 12.2, storing an execution result; 13. the server Sever_B returns channel path authorization information to the server Sever_A;14.1, the server Sever_A feeds back the result to the visitor management system; 14.2, the visitor management system returns channel path authorization information.
According to the cross-chain interaction method provided by the invention, the node with the high reputation value is selected as the main chain consensus node through the node reputation model, so that the consensus efficiency is improved on the premise of guaranteeing the decentralization and the safety degree of the blockchain network, and meanwhile, the improvement of the throughput of the blockchain network can be directly promoted by reducing the number of the consensus nodes. In addition, the efficient response and processing of user operation requests with different priorities are realized through the priority policy module.
The present invention is not limited to the above-mentioned embodiments, and any equivalent embodiments which can be changed or modified by the technical content disclosed above can be applied to other fields, but any simple modification, equivalent changes and modification made to the above-mentioned embodiments according to the technical substance of the present invention without departing from the technical content of the present invention still belong to the protection scope of the technical solution of the present invention.
Claims (6)
1. The block chain-based internet of things system cross-chain interaction method is characterized by comprising the following steps of:
a main chain consensus node selection step, namely deploying a node credit model on the main chain nodes, periodically updating credit values of the main chain nodes, and selecting at least one main chain node with the highest credit value as the main chain consensus node of the round of consensus period, wherein the updating flow of the credit values specifically comprises the following steps:
The method comprises the steps that each main chain node obtains the credit value of each main chain node in the last cycle of the consensus period by calling the node credit value to obtain contracts, and the total score of the credit value of each main chain node is calculated according to the hardware index of each main chain node and the consensus voting result in the last cycle of the consensus period, and a node credit value list is generated;
broadcasting the node credit value list and the signature to the node credit value list, wherein the node credit value list and the signature to the node credit value list are calculated by each main chain node to other main chain nodes through a network, and when any main chain node collects node credit value lists of more than 2/3 other main chain nodes, the main chain node calls a node credit value update contract and transmits the collected node credit value lists into the node credit value update contract as parameters;
a step of updating the credit value, in which the node credit value updating contract verifies the correctness of each main chain node for the signature, when the verification is passed, the total score of the credit value of each main chain node is calculated, the calculation result is recorded in the main chain account book, and the node credit value updating event is thrown out;
monitoring the reputation value updating event, namely binding each main chain node and monitoring the node reputation value updating event, and triggering the steps when the event is thrown out and the updating flow of the reputation value of the current round is ended and the next consensus period is waited;
The static score obtaining step, wherein the main chain node uses CPU core number and memory as credit value calculation indexes, and calculates and updates the static score of each main chain node through the following formula;
wherein ,Mi Representing the memory size, M, of the backbone node i max 、M min Representing the maximum memory and the minimum memory in all main chain nodes; u (U) i CPU core representing main chain node iNumber U max 、U min Representing the maximum CPU core number and the minimum CPU core number in all main chain nodes; alpha represents a first weight parameter, and 0<α<1；
A dynamic score obtaining step, namely calculating and updating the dynamic score of each main chain node according to the consensus voting result and the dynamic score of the main chain node in the last round of consensus period through the following formula;
wherein ,dynamic fraction of backbone node i in t-th round consensus period,/>A t-1 round dynamic score; beta represents a second weight parameter, and 0<β<1；N r 、N w Representing the number of times that the node throws valid tickets and invalid tickets in the consensus period;
a step of obtaining a total credit score of the main chain node, wherein the total credit score of each main chain node is calculated by carrying out weighted summation on the static score and the dynamic score
A user request interaction step, wherein a user initiates a user request for a target sub-chain by accessing a sub-system corresponding to a source sub-chain;
Defining a right control strategy of a subsystem of a user, calling a right control contract deployed on a main chain, generating a corresponding right control tree by splitting and combining the right control strategy, and storing the right control tree into a main chain account book, wherein the right control tree is used for verifying the user right requested by the user, and transmitting the right control strategy into the right control contract in the form of a character string, and the right control strategy comprises attributes and relations;
defining the structure of nodes in the authority control tree in the authority control contract, wherein the nodes comprise root nodes and other nodes;
screening the authority control strategy by utilizing U-shaped characters to obtain a character string array only comprising attributes and the relationship of U, and screening each item of the character string array by utilizing the U-shaped characters to obtain a two-dimensional character string array;
traversing the two-dimensional character string array generated in the steps, connecting each item of the two-dimensional character string array by using a pointer to form a subtree, and connecting all subtrees to the root node to form the authority control tree;
a right verification step, wherein a source sub-link point corresponding to a source sub-link fuses the user requests into a cross-link request packet according to a priority policy module and takes the cross-link request packet as a cross-link transaction contract of a main chain, the cross-link transaction contract internally verifies the user right of each user request in the cross-link request packet, and if verification is successful, the main chain consensus node throws out a cross-link request event;
And a request response step, wherein a destination sub-link point corresponding to the destination sub-link monitors the cross-link request event, analyzes and acquires a user request aiming at the destination sub-link, executes the user request, feeds back an execution result to a source sub-link node, and feeds back the received execution result to a user.
2. The blockchain-based internet of things system cross-chain interaction method of claim 1, wherein the step of fusing the user request into a cross-chain request packet by the source child link point according to the priority policy module comprises:
the source sub-link point caches the source sub-link point into different request lists of a local request pool according to the priority of the user request, periodically loads a priority policy module and respectively sorts the user requests in the different lists;
the source sub-link point obtains a corresponding number of user requests from each list of the local request pool according to one or a combination of the sequencing result, the preset single-round maximum request submission number and each priority request obtaining proportion, fuses the obtained user requests into a cross-link request packet, and transmits the cross-link request packet into the cross-link transaction contract as a parameter.
3. The blockchain-based internet of things system cross-chain interaction method of claim 2, wherein the request processing flow of the priority policy module comprises the following steps:
the source sub-link node obtains a request list of each priority from the local request pool, wherein the request list comprises a high-priority request list, a medium-priority request list and a low-priority request list;
traversing the three request lists, updating the waiting time of each user request in the local request pool, and calculating the residual waiting time according to the maximum response time of each user request;
and respectively carrying out ascending sort on the user requests of each request list in the local request pool by taking the residual waiting time as a sorting basis, and updating the sorted result to the local request pool.
4. The blockchain-based internet of things system cross-chain interaction method of claim 1, further comprising a data storage step between the main chain consensus node selection step and the user request interaction step, specifically comprising:
the target sub-chain edge gateway calls a data acquisition interface to acquire related data from corresponding subsystem equipment;
the target sub-chain edge gateway calls an IPFS interface to upload acquired data to an IPFS network and acquire a corresponding data storage address, calls a data storage contract of a target sub-chain to store the data storage address into a target sub-chain account book, and throws out a storage success event;
And the target sub-chain server binds and monitors a successful event of data storage, when the event is thrown out, the target sub-chain server acquires the transaction ID and the block number of the data storage transaction, constructs a sub-chain data log record, calls a data log storage contract of a main chain and initiates a storage request of the chain data log record, assembles the storage request into blocks after the consensus of the main chain consensus node, and records the blocks into a main account book.
5. The blockchain-based internet of things system cross-chain interaction method of claim 1, wherein the step of verifying the user rights of the user request further comprises:
and acquiring a user attribute list and a request type by analyzing the user request, acquiring a corresponding authority control tree according to the request type, comparing the authority control tree with the user attribute list, if traversing to a node of the authority control tree according to the user attribute, indicating that the user has the execution authority of the request type, otherwise, indicating that the user does not have the execution authority of the request type.
6. The blockchain-based internet of things system cross-chain interaction method of claim 1, wherein the main chain consensus node selection step is preceded by an environment deployment step, specifically comprising the steps of:
Installing and deploying a blockchain operation environment on an edge gateway and a server, and utilizing the edge gateway and the server as blockchain link points to form corresponding sub-chains and main chains, wherein the edge gateway is used as a sub-chain node, and the server is used as a sub-chain node and/or main chain node.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210008587.5A CN114363352B (en) | 2022-01-05 | 2022-01-05 | Cross-chain interaction method of Internet of things system based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210008587.5A CN114363352B (en) | 2022-01-05 | 2022-01-05 | Cross-chain interaction method of Internet of things system based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114363352A CN114363352A (en) | 2022-04-15 |
| CN114363352B true CN114363352B (en) | 2023-08-15 |
Family
ID=81106404
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210008587.5A Active CN114363352B (en) | 2022-01-05 | 2022-01-05 | Cross-chain interaction method of Internet of things system based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114363352B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115002221B (en) * | 2022-06-06 | 2023-06-23 | 长春理工大学 | Block chain consensus method and system suitable for Internet of things |
| CN115455457B (en) * | 2022-11-11 | 2023-03-24 | 北京共识数信科技有限公司 | Chain data management method, system and storage medium based on intelligent big data |
| CN116523518B (en) * | 2023-07-03 | 2023-09-15 | 中铱数字科技有限公司 | Cross-channel data access method, system and storage medium based on blockchain |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003005232A2 (en) * | 2001-07-06 | 2003-01-16 | Angoss Software Corporation | A method and system for the visual presentation of data mining models |
| CN109767199A (en) * | 2018-12-10 | 2019-05-17 | 西安电子科技大学 | PBFT common recognition system and method, block chain data processing system based on prestige |
| CN110288345A (en) * | 2019-06-26 | 2019-09-27 | 深圳市网心科技有限公司 | Across chain communication means, device, main chain node and storage medium |
| CN110351067A (en) * | 2019-06-12 | 2019-10-18 | 南京理工大学 | For the block chain common recognition mechanism of principal and subordinate's multichain |
| CN110490562A (en) * | 2019-07-10 | 2019-11-22 | 布比（北京）网络技术有限公司 | A kind of across the chain data processing method and system of multi-tiling chain |
| CN111131181A (en) * | 2019-12-05 | 2020-05-08 | 重庆邮电大学 | Reputation mechanism and DPBFT algorithm-based block chain dynamic DPoS consensus method |
| CN112039964A (en) * | 2020-08-24 | 2020-12-04 | 大连理工大学 | Node reputation consensus method based on block chain |
-
2022
- 2022-01-05 CN CN202210008587.5A patent/CN114363352B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003005232A2 (en) * | 2001-07-06 | 2003-01-16 | Angoss Software Corporation | A method and system for the visual presentation of data mining models |
| CN109767199A (en) * | 2018-12-10 | 2019-05-17 | 西安电子科技大学 | PBFT common recognition system and method, block chain data processing system based on prestige |
| CN110351067A (en) * | 2019-06-12 | 2019-10-18 | 南京理工大学 | For the block chain common recognition mechanism of principal and subordinate's multichain |
| CN110288345A (en) * | 2019-06-26 | 2019-09-27 | 深圳市网心科技有限公司 | Across chain communication means, device, main chain node and storage medium |
| CN110490562A (en) * | 2019-07-10 | 2019-11-22 | 布比（北京）网络技术有限公司 | A kind of across the chain data processing method and system of multi-tiling chain |
| CN111131181A (en) * | 2019-12-05 | 2020-05-08 | 重庆邮电大学 | Reputation mechanism and DPBFT algorithm-based block chain dynamic DPoS consensus method |
| CN112039964A (en) * | 2020-08-24 | 2020-12-04 | 大连理工大学 | Node reputation consensus method based on block chain |
Non-Patent Citations (1)
| Title |
|---|
| Credible Peer-to-Peer Trading with Double-Layer Energy Blockchain Network in Distributed Electricity Markets;Wang Longze;《Electronics》;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114363352A (en) | 2022-04-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114363352B (en) | Cross-chain interaction method of Internet of things system based on block chain | |
| US20190207751A1 (en) | Blockchain enterprise data management | |
| US11296863B2 (en) | Blockchain enterprise data management | |
| Pyoung et al. | Blockchain of finite-lifetime blocks with applications to edge-based IoT | |
| JP2019160312A (en) | Blockchain node, method of blockchain node, and computer program for blockchain node | |
| CN110032545A (en) | File memory method, system and electronic equipment based on block chain | |
| JP2021526751A (en) | Secure consensus endorsement for self-monitoring blockchain | |
| JP5160205B2 (en) | Method and system for file transfer management | |
| CN112241919A (en) | Multi-domain blockchain network with data flow control | |
| KR102564106B1 (en) | System and Method for Intelligent mediating based enhanced smart contract for privacy protection | |
| CN113726913B (en) | Backbone node access method and block chain system | |
| CN109951490A (en) | Webpage integrity assurance, system and electronic equipment based on block chain | |
| US10192262B2 (en) | System for periodically updating backings for resource requests | |
| KR20220160021A (en) | Low Trust Privilege Access Management | |
| CN105991596A (en) | Access control method and system | |
| CN114117264A (en) | Illegal website identification method, device, equipment and storage medium based on block chain | |
| KR20200097773A (en) | Blockchain-based identity system | |
| CN100561516C (en) | Network gridding service system of national geolopy spatial data | |
| CN116800541A (en) | Classified and hierarchical access control and access method for flight operation data | |
| CN112291264B (en) | Security control method, device, server and storage medium | |
| US20220255970A1 (en) | Deploying And Maintaining A Trust Store To Dynamically Manage Web Browser Extensions On End User Computing Devices | |
| Quamara et al. | An In-depth Security and Performance Investigation in Hyperledger Fabric-configured Distributed Computing Systems | |
| CN116975158B (en) | Request processing method, apparatus, computer device and storage medium | |
| CN116760632B (en) | Data processing method, device, equipment and readable storage medium | |
| Liu et al. | BGRA: A reference architecture for blockchain governance |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20221212 Address after: 266525 No.777, Jialingjiang East Road, Huangdao District, Qingdao City, Shandong Province Applicant after: QINGDAO TECHNOLOGICAL University Applicant after: QINGDAO PENGHAI SOFTWARE Co.,Ltd. Address before: 266525 No.777, Jialingjiang East Road, Huangdao District, Qingdao City, Shandong Province Applicant before: QINGDAO TECHNOLOGICAL University |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240126 Address after: 266000 Building 1, 169 Songling Road, Laoshan District, Qingdao City, Shandong Province Patentee after: QINGDAO PENGHAI SOFTWARE Co.,Ltd. Country or region after: China Address before: 266525 No.777, Jialingjiang East Road, Huangdao District, Qingdao City, Shandong Province Patentee before: QINGDAO TECHNOLOGICAL University Country or region before: China Patentee before: QINGDAO PENGHAI SOFTWARE Co.,Ltd. |