CN110993044B - Lightweight dynamic autonomous cross-link interaction method for medical alliance link - Google Patents
Lightweight dynamic autonomous cross-link interaction method for medical alliance link Download PDFInfo
- Publication number
- CN110993044B CN110993044B CN201911187519.4A CN201911187519A CN110993044B CN 110993044 B CN110993044 B CN 110993044B CN 201911187519 A CN201911187519 A CN 201911187519A CN 110993044 B CN110993044 B CN 110993044B
- Authority
- CN
- China
- Prior art keywords
- node
- chain
- contract
- verification
- subgroup
- 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
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Medical Informatics (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Epidemiology (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention belongs to the technical field of medical alliance chains, and discloses a lightweight dynamic autonomous cross-chain interaction method for a medical alliance chain, which comprises the following steps: constructing a cross-chain consensus mechanism based on threshold digital signatures; constructing a cross-chain path attestation signature, comprising: generating and sharing a group key, generating a threshold subgroup signature and updating a path certificate; and value transfer among different alliance chain nodes is realized. The invention simplifies the communication topology among nodes of the medical alliance chain, provides a node cross-chain communication model based on an intelligent contract state period and a node cross-chain communication identity credibility path certification construction rule, and performs dynamic construction and verification of inter-chain transaction interactive credible path certification; modeling the consensus process of the cross-link transaction by the plurality of alliance link verification node lists as a threshold digital signature process with a plurality of privilege subgroups, thereby expanding the alliance link internal consensus based on the verification node lists into the alliance link cross-link consensus on the premise of not increasing the computational complexity.
Description
Technical Field
The invention belongs to the technical field of medical alliance chains, and particularly relates to a lightweight dynamic autonomous cross-chain interaction method for a medical alliance chain.
Background
The existing research medical data storage and management research mainly centers on cloud service technology, fog computing and edge computing, and typical research is as follows: document [1] ([ 1 ]) Single K, batten L.aggregation private data for secure query applications. Future Generation Computer systems,2017, 72: 250-263.Https:// doi.org/10.1016/j.future.2016.11.028.) proposes a solution for sharing sensitive data based on a non-standard diagonal data aggregation method; document [2] ([ 2] Jaben F, hamid Z, wadood A, et al, enhanced Architecture for Privacy Preserving Data Integration in a Medical Research environment [ J ]. IEEE Access, 2017; document [3] ([ 3] Al Hamid H A, rahman S M, hossain M S, et al. A security model for predicting the privacy of a geographic big data in a geographic close using a fog computing facility with a paging-based cryptography [ J ]. IEEE Access,2017, 5; the documents [4,5] ([ 4] Ning Zhenyu, zhang Fengwei, shi Weisong. Trusted execution environment research [ J ] computer research and development based on edge computing 2019,56 (07): 1441-1453.) ([ 5] fern dez-Caram T M, fraga-Lamas P.A Review on the Use of block chain for the Internet of Things of this [ J ] IEEE Access,2018, 6. However, the above solutions all rely on a completely trusted third party, adopt authentication and key protocol schemes to improve the security of medical information sharing, and are vulnerable to off-line password guess attack and privileged internal line attack, so that it is difficult to implement secure, traceable sharing and management of data of cross-institution clinical trials. Different from a centralized management mode, the block chain adopts a chain structure to perform distributed storage on the data ledger containing complete transaction history, has stronger tamper-proof capability, and is convenient to provide integrity and traceability management for medical clinical data, so that the application safety and efficiency of the medical clinical data are improved, and the block chain is considered to be a feasible solution.
In 2008, the article "Bitcoin: A peer-to-peer electronic case system" first describes the block chain core system architecture, and utilizes the means of Hash chain, manufacturing work delay, incentive mechanism, etc. to break through the traditional problems of many academic circles, and applies the block chain technology as the bottom layer security technology to the finance field, and hastens various encrypted digital currencies, and the block chain technology as the bottom layer security technology has attracted wide attention in the cryptography and other circles. The block chain is divided into a public chain, a private chain and a alliance chain according to a node admission mode, wherein the alliance chain can preset an authorization admission and consensus mechanism by an organization in a decentralized supervision mode, so that user hierarchical management and autonomous dynamic flow of values among credible nodes are realized, API (application programming interface) limited query is realized, and related researches on the alliance chain in the medical field appear successively.
Document [6] originally proposed a Healthcare alliance blockchain clinical trial data sharing standard HL7FHIR ([ 6 ]), which provides a framework for the exchange, integration, sharing and retrieval of electronic medical information. On the basis of HL7FHIR, document [7] ([ 7] zhang p, white j, schmidt D c, et al, FHIRChain. The document [8] ([ 8 ]) PhUSE generating trends and technology. How Block chain can Transform the Pharmaceutical and Healthcare industries. Https:// www.phuse.eu/documents/work-groups/delivery chains/use-block chain-while-paper-version on-0-final-18719.Pdf.accessed 18august 2019.) indicates that intelligent and comprehensive medical data mining has a broad application prospect around the point of view of medical data mining, with the prospect of making patients benefit from their personal medical data for research purposes. On the basis of the above-mentioned research, the document [9] ([ 9 ]) (Li M, xia L, seniviratne O.leveraging Standards Based on automatic transactions in Distributed Ledgers. Recent application studies of block-chain technology in biomedical and healthcare are outlined in the literature [10] ([ 10 ]) Kuo T, kim H E, ohno-Machado L.Block distributed ridge technologies for biomedical and healthcare [ J ]. Journal of the American Medical information Association,2017,24 (6): 1211-1220.), mainly around improving Medical record management, strengthening insurance claim programs, accelerating clinical, biomedical studies, and the like. On the basis of the existing research of the medical alliance chain, how to enable a user to have own ownership of medical data, and how to safely and dynamically and autonomously share the medical data among different medical institutions is still a continuously concerned field, so that the method has great significance for the research of the lightweight cross-alliance chain communication mechanism of the medical clinical data based on patient privacy protection and dynamic autonomous interaction.
Research on cross-chain communication of the existing block chain introduces an asset mapping and asset transaction conceptual model reconstruction block chain value exchange network, and compared with the famous cross-chain technology for asset transfer based on hash locking, side chain technology and the like ([ 11] Piatkivskyi D, axelson S, nowostawski M.digital for practical information on the lighting network C. IFIP International Conference on Digital forces Springer, cham, 2017. The main idea of the Hash locking technology is that in order to realize a micropayment channel between users, the users need to lock partial funds in advance, the transaction related to the partial funds is carried out under a chain, and the final allocation scheme of the funds is uploaded to a main chain after being determined. The side chain is based on the original digital assets, and is an inter-chain communication technology for transferring other account book assets among a plurality of block chains, and the inter-chain communication technology is an expansion technology provided for solving the problem of main chain expansion. The fragmentation technology realizes inter-chain communication by a plurality of fragments established on an Ethernet network protocol, exponentially improves network throughput by a method called super-quadratic fragmentation, however, the existing fragmentation technology needs several times or even a plurality of times of hard forking to complete, which brings much inconvenience to the existing application and users. With the increasing demand for uplink and inter-link communication, research has begun to explore intelligent contract-based decentralized cross-link asset management methods ([ 13 ]. Buterin V.A next-generation shared and decentralized application platform [ EB/OL ], https:// encryption. Eu/wlan/ether _ white _ page.pdf.2014.) ([ 14 ]. Zhang Y, kasahara S, shen Y, et al. Smart connected-based access network for the interactions [ J ]. IEEE Internet of assets Journal,2018,6 (2-1605): 2). However, the above-mentioned cross-link communication technology mainly ensures the atomicity of asset interaction through an asset mortgage method, and the implementation logic for processing common digital asset uplink and asset interaction transactions is complex, and cannot be directly applied to a lightweight cross-link dynamic autonomous interaction scenario of a healthcare alliance link.
Disclosure of Invention
Aiming at the problems that the prior tracing technology mainly focuses on front-end tracing, product information is stored and processed in a central database in a centralized manner, the possibility that chip contents are copied or the database is broken exists, and other security threats can be further caused by single-point faults; in addition, the existing medical data privacy protection and sharing solution has a third party, privacy risks may still be caused by direct sharing of patient data among different medical institutions, and the problem that traceability certification of medical data is difficult to provide by the existing mechanism is solved.
In order to achieve the purpose, the invention adopts the following technical scheme:
a lightweight dynamic autonomous cross-link interaction method for a medical alliance link comprises the following steps:
constructing a cross-chain consensus mechanism based on threshold digital signatures;
constructing a cross-chain path attestation signature, comprising: generating and sharing a group key, generating a threshold subgroup signature and updating a path certificate;
and value transfer among different alliance chain nodes is realized.
Further, the constructing of the cross-chain consensus machine based on the threshold digital signature comprises:
establishing m links of cooperative relationshipAlly chain C 1 ,C 2 ,,C m Set of verification node lists as groups
Each federation chain verification node list is referenced as a group->
Wherein m mutually disjoint privilege subgroups +>
Generating a group @basedon a privilege subgroup threshold signature mechanism>
Is coupled with a public and private key>
Federation inter-chain partnerships are represented as:
wherein n is i Representing subgroups
Verifying the number of nodes in the list of nodes, t i Indicating that a privilege subgroup is asserted>
N of (a) i Minimum number of nodes, t, that an individual verification node passes a certain verification i ' represents n i The number of nodes actually passing a certain verification in each verification node, t represents the group ^ or ^ s>
The n verification nodes pass the minimum node number of a certain verification, and TX represents a transaction; equation (4) defines the cooperation relationship among the federation chains, equation (5) and equation (6) represent the scale of the verification node set of the federation chains, equation (7) represents the threshold consensus based on the verification node list in the federation chains, and equation (8) represents the cross-chain consensus based on the privilege subgroup threshold signature mechanism.
Further, the group key generation and sharing includes:
randomly generating a group private key according to equation (12), calculating a group public key according to equation (13), and distributing the group private key by adopting a secret sharing algorithm based on Shamir:
wherein u and v are safety prime numbers and satisfy v | (u-1), f (0), g A (0)，g B (0) Respectively in a finite field Z v 3 polynomials f (x), g secretly chosen A (x)，g B (x) Of alpha finite field Z v The primitive element of (1);
sub-grouping privileges
The abstraction is a privileged node in the directed path certification and is based on the secret sharing algorithmIs a privileged node>
Secret distribution group private key segment->
j＝1,2,…,n A ，k＝1,2,…,n B Calculating the privilege node ^ according to equation (14)>
And discloses:
wherein λ i ，μ i Is a publicly computable lagrangian coefficient in the Shamir secret sharing algorithm.
Further, the threshold subgroup signature generation comprises:
computing public key fragments by equation (15)
Evaluation of a subgroup by means of equation (16)>
Public key r of internal verification node subgroup X Calculating the private key segment ^ of the single verification node by the formula (17)>
Wherein
Represents the randomly chosen parameters for generating the signature, TX is the signed transaction, h (x) is the secure hash function;
verification group of the passing formula (18)
In a subgroup of nodes, a single verification node signature>
The legitimacy of (c):
if equation (18) holds, the subgroup of verification nodes accepts the signature of the single verification node within the subgroup
When +>
Then, the private key s of the subgroup is calculated by equation (19) X Is asserted by the response node>
The subgroup of verification nodes of the federation chain>
Generating a subgroup composite signature ^ according to equation (20)>
Further, the path attestation update includes:
after the sub-group signatures are combined,
in accordance with formula (21) will be paired with a transaction>
In a group signature and request originating node>
Issued request->
Write together transaction +>
Updating the transaction path certificate:
response node
For transaction->
Verification is carried out, after passing, the>
Utilizing local assets->
Based on external request->
Performs a calculation to generate a blind response->
Will switch on according to equation (22)>
Blind response of and updated path prove and->
Write transaction @together>
Further, the implementing value transfer between different alliance chain nodes comprises:
step 3.1: in creating value transfer keys
Then, the request initiating node->
Selecting a one-way collision-resistant hash function H (·), calculating &>
And/or>
Negotiating and deploying with hash lock h and time lock t timestamp An intelligent contract of +8 delta t to realize->
To/is>
Integral transfer hosting of, wherein t timestamp Representing the time of the first phase intelligent contract of the cross-chain communication, Δ t representing the minimum time interval; if/or>
At time t timestamp +8 Δ t forward smart contract sending value transfer key &>
So that
The credit hosted in the smart contract is irrevocably slave @>
Transfer to +>
If/or>
At time t timestamp Failing to reveal the secret before +8 Δ t, is based on +>
Initiating a credit return transaction to return the credit held in the smart contract to ≥>
Step 3.2: node point
Confirm that the smart contract is stably deployed at step 3.1, and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +7 delta t utilizes the preset alliance inter-chain heterogeneous value conversion function to realize the value C of the intelligent contract hosting point in the step 3.1 A The system integrator slave pick>
Is transferred to->
The hosting of (1);
step 3.3: node point
Confirm that the smart contract is stably deployed at step 3.2, and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +6 delta t realizes that the equivalent score is subjected to from/to in step 3.2>
Is transferred to->
The hosting of (1);
step 3.4: node point
Confirm that the smart contract is stably deployed at step 3.3, and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +5 delta t realizes that the equivalent score is subjected to from/to in step 3.3>
Transfer to->
The hosting of (1);
step 3.5:
after confirming the stable deployment of the intelligent contract in step 3.4, the value transfer key is entered into the contract for the contract validity period->
Triggering contract execution to obtain->
Managed assets, which after contract execution is completed, can be returned to intelligent contract deployer in the form of return value>
Sending a value transfer key s;
step 3.6:
obtaining a value transfer key>
Thereafter, the value transfer key is entered into the contract for the duration of the intelligent contract expiration deployed at step 3.3>
Trigger contract execution, and->
Gets a contract to->
The managed assets are processed into return values to the intelligent contract deployer to be treated as ^ er>
Sending a value transfer key->
Step 3.7:
obtain value transfer key->
Thereafter, a value transfer key is input into the contract in step 3.2 for the duration of the validity of the intelligent contract>
Trigger contract execution, and->
Gets a contract to->
Managed assets, which after contract execution is completed, can be returned to intelligent contract deployer in the form of return value>
Sending a value transfer key->
/>
Step 3.8:
obtain value transfer key->
Thereafter, the value transfer key is entered into the contract for the duration of the intelligent contract expiration deployed at step 3.1>
Trigger contract execution in conjunction with>
Gets a contract to->
A hosted asset.
Compared with the prior art, the invention has the following beneficial effects:
the existing tracing technology mainly focuses on front-end tracing, product information is centrally stored and processed in a central database, the possibility that chip contents are copied or the database is broken exists, and other security threats can be further caused by single-point failure. The invention provides a solution to the safety problem of an agricultural product traceability system based on a block chain technology, which comprises the following steps: improving a consensus mechanism; the data integrity and reliability of agricultural product traceability information are guaranteed by using distributed network billing; performing multi-level traceability information verification by using related technologies of cryptography to ensure that traceability information cannot be tampered; and performing access authority control by using a multi-private key rule. The unauthorized change of the traceability information ledger by an attacker can be effectively avoided, so that the credibility of the traceability information is improved.
The existing medical data privacy protection and sharing solution mainly adopts a cloud service technology, fog calculation, edge calculation and the like, and the dynamic autonomous interaction of medical clinical data has two obstacles: on the one hand, direct sharing of patient data between different medical institutions may still lead to privacy risks due to the presence of a serving third party; on the other hand, the existing mechanism is difficult to provide medical data traceability evidence so as to ensure the reliability of the clinical test result from data capture to final analysis. Compared with the existing medical record management method, the scheme provided by the invention can enable patients to reduce the dependence on a clinic record generation mechanism to the maximum extent, allows the patients to selectively share the records of the patients to specific users according to privacy preference, facilitates the realization of traceable proof of medical records, is beneficial to expanding the number of clinical test records of medical mechanisms and improves the clinical cooperation level.
The main contributions of the invention are:
(1) Simplifying the communication topology among nodes of the medical alliance chain, providing a node cross-chain communication model based on an intelligent contract state period and a node cross-chain communication identity credibility path certification construction rule, and performing dynamic construction and verification of inter-chain transaction interactive credible path certification;
(2) Modeling a consensus process of a plurality of alliance chain verification node lists on cross-chain transaction into a threshold digital signature process with a plurality of privilege subgroups, so that the alliance chain internal consensus based on the verification node lists is expanded into alliance chain inter-chain cross-chain consensus on the premise of not increasing the computational complexity;
(3) Analyzing the rational node cooperation honesty behavior motivation of the medical system, establishing a dual incentive mechanism based on the node point and credit of the heterogeneous medical alliance chain system, analyzing the node cross-chain communication intelligent contract deployment and trigger mechanism, and giving a value transfer and autonomous interaction mode among nodes.
Drawings
FIG. 1 is a schematic diagram of a state cycle of an intelligent contract;
FIG. 2 is a diagram of a medical alliance inter-chain communication model;
FIG. 3 is a basic flowchart of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance link, according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a path certification topology of a lightweight dynamic autonomous cross-link interaction method of a medical alliance link according to an embodiment of the present invention;
FIG. 5 is a sequence diagram of a cross-link path signature structure of a lightweight dynamic autonomous cross-link interaction method of a healthcare alliance link, according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a value transfer intelligent contract life cycle of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance chain in accordance with an embodiment of the present invention;
FIG. 7 is a timing diagram illustrating a value transfer intelligent contract deployment of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance chain in accordance with an embodiment of the present invention;
FIG. 8 is a timing diagram illustrating a value transfer intelligent contract trigger of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance chain in accordance with an embodiment of the present invention;
FIG. 9 is a diagram illustrating an example of node value transfer in a lightweight dynamic autonomous cross-chaining interaction method for a federation chain for medical services according to an embodiment of the present invention;
FIG. 10 is a single-chain performance test result diagram of a lightweight dynamic autonomous cross-chain interaction method for a healthcare alliance chain in accordance with an embodiment of the present invention;
FIG. 11 is a diagram illustrating inter-link performance testing results of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance link, in accordance with an embodiment of the present invention;
fig. 12 is a diagram of 4-stage contract deployment delay of a lightweight dynamic autonomous cross-link interaction method for a healthcare alliance chain according to an embodiment of the present invention;
fig. 13 is a 4-phase contract execution delay diagram of a lightweight dynamic autonomous cross-link interaction method for a federation chain of medicine according to an embodiment of the present invention.
Detailed Description
The invention is further illustrated by the following examples in conjunction with the drawings and the accompanying drawings:
in the medical Internet of things system, a bottom network collects user health information through medical monitoring equipment and transmits the user health information to a convergence gateway, and the convergence gateway has stronger storage, processing and communication capabilities than the collection equipment, realizes combination with the bottom network downwards and stably accesses to a network fusion system upwards. Entities such as common users, patients and managers of the same medical institution are used as common nodes in the medical alliance chain, the intelligent contracts are deployed and executed on the intelligent gateways to realize asset transfer and interaction, and the state cycle of the intelligent contracts is shown in fig. 1.
Any node in the system can write own data assets into the intelligent contract through the gateway, the contract storage file is stored in the alliance block chain, and the contract code executes corresponding operation on the storage file when receiving a trigger signal from other trusted nodes or the intelligent contract.
Cross-chain communication is defined as follows:
defining a federation chain as C under a 1P2P communication mode X ，C X Is recorded as
C X Is flagged as ≧ valid>
Node/node combination>
Owned resources are recorded as assets>
Rational node/conjunction>
Utilizing local assets->
A response method in which the message m is operated and only the operation result is output is called blind response.
Define 3sig (m, X) denotes the signature of the private key of X on the message m (m ≠ φ), triplet(m, p, σ) represents node path proof, p = { u = 0 ,…,u k Is a slave request initiating node u 0 To the responding node u k Directed communication path of (1), σ = sig (sig (m, u) 0 ),…,u k ) Is from u 0 To u k The path signature of (2). If u is k For relaying the response node, slave u 0 To u k The path proof of (1) is called current path proof; if u is k For the final response node, from u 0 To u k The path proof of (2) is called full path proof.
Node Cross-Link communication Process As shown in FIG. 2, assume C A 、C B For two federation chains for which a partnership has been established,
to the direction of
Initiating an interaction request>
/>
In the above-mentioned cross-link communication model, in order to achieve inter-link cooperative consensus, it is necessary to establish a cross-link consensus mechanism for transferring inter-link consensus of a federation of cooperating entities on the basis of a consensus mechanism based on an internal verification node list of the federation; in order to dynamically and adaptively identify the node identity, a path certificate for providing the reliability of the node cross-chain communication identity needs to be constructed, and the node behavior is limited in a credible range allowed by an organization; in addition, on the basis of analyzing honest behavior motivation of node cooperation in the medical alliance chain environment, a method for achieving decentralized dynamic autonomous transfer of values among different medical alliance chain nodes by deploying intelligent contracts needs to be provided.
In order to solve the above problem, the present application provides a lightweight dynamic autonomous inter-chain interaction method for a healthcare alliance chain, as shown in fig. 3, including: constructing a cross-chain consensus mechanism based on threshold digital signatures; constructing a cross-chain path attestation signature, comprising: generating and sharing a group key, generating a threshold subgroup signature and updating a path certificate; and value transfer among different alliance chain nodes is realized. If a certain stage of transaction processing does not pass, the transaction is ignored, and the embodiment only analyzes the condition that all stages of transaction processing pass.
Step S101, constructing a cross-chain consensus mechanism based on threshold digital signatures:
earlier work proposed a reputation-based consensus mechanism (see in particular CN 110008720A): inside the alliance chain, a part of trust Nodes are authorized to form a Verification node List VNL (Verification Nodes List), a full-node server in the system is responsible for maintaining the VNL List and providing all effective operations which are not recorded before the consensus starts for the Nodes participating in the Verification, and the Verification results of members in the VNL are relied to achieve the consensus and complete block generation. On the basis of the VNL consensus inside the alliance chain, the cooperation relationship among the alliance chains is abstracted to be a threshold digital group signature process, the consensus process of a plurality of alliance chain verification node lists on cross-chain transaction TX is modeled to be the threshold digital signature process with a plurality of privilege subgroups, and therefore the internal consensus of the alliance chain is expanded to be the cross-chain consensus among the alliance chains. A formal description of establishing federation inter-chain partnership using a threshold digital signature mechanism with multiple privilege subgroups present is given below.
Definition 4 m federation chains C establishing a partnership 1 ,C 2 ,…,C m Set of verification node lists as groups
Each federation chain verification node list is referenced as a group->
Wherein m mutually disjoint privilege subgroups +>
Generating groups +based on a privileged subgroup threshold signature mechanism>
Is coupled with a public and private key>
Federation inter-chain partnerships are represented as:
in the above model, n i Representing subgroups
Verifying the number of nodes in the list of nodes, t i Indicates a subgroup->
N of (A) to (B) i Minimum number of nodes, t, that an individual verification node passes a certain verification i ' represents n i The number of nodes actually passing a certain verification in each verification node, t represents the group ^ or ^ s>
TX represents a transaction, with the minimum number of nodes that pass a certain verification. Equation (4) defines the cooperative relationship among the federation chains, equations (5) and (6) represent the scale of the set of federation chain verification nodes, equation (7) represents the threshold consensus based on the verification node list in the federation chains, and equation (8) represents the cross-chain consensus based on the privilege subgroup threshold signature mechanism.
Step S102, constructing a cross-chain path certificate signature, comprising: group key generation and sharing, threshold subgroup signature generation and path certification updating:
the path certification topology in the P2P communication mode is as shown in fig. 4, and the trusted propagation path is simplified based on the relay forwarding mode of peer-to-peer node pair information, so as to obtain the following path certification construction rules:
a rule 2 simplifies the path certification of nodes in the alliance chain to the verification node subgroup through a plurality of nodes in the chain into a single-hop path certification from the nodes to the verification node subgroup;
the single-hop path between the common nodes in the rule 4 path proof represents a blind response based on the request initiating node value transfer key s.
The intra-chain path-proving topology is shown in part (a) of fig. 4, and the subgroup of verification nodes is verified by rule 1
Abstracted as a node in the directed path certificate, by rule 2, the node &>
Relayed to the verification node subgroup by other nodes in the chain>
Reduced to node->
To or>
Single hop path ofProving; the inter-chain path proving topology is shown in part (b) of figure 4,
C A ∩C B = phi, by rule 3,>
to/is>
The cross-chain path proof only contains the verification node subgroup
As a relay node; according to rule 4, the path proves that a link exists in a loop in fig. 4, the path between any two common nodes proves to be a multi-hop path proves relayed by a plurality of verification node subgroups, and the single-hop path between two common nodes (a gray curve in fig. 4) proves to be a single-hop response of a response node to a request node by sending a value transfer key s based on the path between the request node and the response node.
For simplicity of description, assume groups
There are only 2 privilege subgroups within, cross-chain path signature construction timing as in fig. 5, inter-chain path attestation group signature protocol tag (t) A ,n A ；t B ,n B ；t,n)。
From definition 3, a recursive path proof generation formula based on a threshold signature is obtained:
( Note: the parameter t, n in equation (9) is an optional item for threshold signatures. )
In FIG. 5, the nodes
Construction in clear text of a subscriber station in conjunction with another federation link node>
Based on the interaction request->
Constructor @ based on the path proof construction rule 2 and the generation formula (9)>
To/is>
As shown in equation (10), to generate intelligent contract transactions
And in federation chain C B And (4) in-deployment.
C B Internal verification node list
To a transaction>
Making a consensus if equation (7) is TRUE, i.e., transaction @>
Through C B If the internal verification nodes are identified, then the value in equation (7) is compared>
As->
For transaction->
Is signed by a threshold subgroup of
Will switch on according to equation (11)>
Threshold subgroup signature and->
Write together intelligent contract transaction>
And updating the transaction path certificate.
C A Inner verification node subgroup
For transaction->
After the path proof of validation of (4), the transaction is taken>
Making a consensus if equation (7) is TRUE, i.e., transaction @>
Through C A If the internal verification node is identified, the value in formula (7) is greater than or equal to>
As->
To a transaction>
Is signed by the response node->
The subgroup of verification nodes of the federation chain>
And synthesizing the signatures of each threshold subgroup in the path certification by using the group key.
The cross-link path certification signature structure specifically comprises three parts, namely group key generation and sharing, threshold subgroup signature generation and path certification updating.
(1) Group key generation and sharing:
selecting safety prime numbers u and v by a key issuing organization (CA or similar trusted organization), and satisfying v | (u-1) in a limited domain Z v The upper secret selects 3 polynomials f (x), g A (x)，g B (x) The polynomial selection order is (t-1), (t) A -1)、(t B -1) selecting a finite field Z v The primitive α, public (u, v, α) and x of (1) i ，
j＝1,2,…,n A ，k＝1,2,…,n B . A group private key is randomly generated by a key issuing organization according to the formula (12), a group public key is calculated according to the formula (13), and the group private key is distributed by adopting a secret sharing algorithm based on Shamir.
Based on secret sharing algorithm as privileged node
Secret distribution group private key fragment->
Calculates its public key according to equation (14) and publishes it
(2) Threshold subgroup signature generation:
from formula (5), subgroup
The number of the verification nodes is>
Subgroup->
N of (A) to (B) X The number of threshold nodes passing a certain verification in each verification node is t X Signed transaction is TX, for each t i ∈{t X Secret random selection
Representing a randomly chosen parameter for generating a signature, the public key fragment ≥ being calculated by equation (15)>
Subgroup->
The inner verification nodes calculate a subgroup public key r by a formula (16) X Calculating a single verification node private key segment @, from equation (17)>
Wherein λ is i ，μ i Is Shamir secret sharing algorithmThe method discloses a calculable lagrangian coefficient, h (x) being a secure hash function.
Group of
Inner nodes are signed by a single verification node within a verification subgroup of equation (18)>
The legitimacy of (c):
if equation (18) holds, the subgroup of verification nodes receives the signature of the single verification node in the subgroup when
Then, s is calculated from equation (19) X . In FIG. 5, in a subgroup by verification nodes>
Output Pair transaction @, according to the method described above>
Threshold subgroup signature (r) B ,s B ) Similarly, by a response node>
Verification node subgroup in federation chain>
Generating a subgroup composite signature according to equation (20)
(3) Path certification update:
after the sub-group signature is synthesized,
in accordance with formula (21) will be paired with a transaction>
Is signed and->
Write-together transactions
The transaction path certificate is updated.
Response node
For transaction->
Verification is made and, upon passing, local asset is utilized>
Based on external request->
Performs a calculation to generate a blind response->
Will switch on according to equation (22)>
Blind response and updated path attestation
Write transaction @together>
Step S103, value transfer among different alliance chain nodes is realized:
by definition 2, the rational node performs intelligent contract deployment and execution with Δ t as a minimum time interval:
1. if the time for deploying the first-stage intelligent contract of the cross-chain communication is t timestamp The intelligent contract deployment time sequence of each stage is { t } timestamp ,t timestamp +Δt,…,t timestamp +(k-1)Δt}；
2. The intelligent contract execution sequence triggered based on the value transfer key is opposite to the deployment sequence, and the corresponding intelligent contract start execution time sequence is { t } timestamp +(2k-1)Δt,t timestamp +(2k-2)Δt,…,t timestamp +kΔt}；
3. The life cycle of the intelligent contract with hash locking is {2k delta t,2 (k-1) delta t,2 delta t } in sequence;
4. in a system requiring communication timeliness, such as communication between intelligent devices of the Internet of things, the effective deadline of each stage intelligent contract is set to be { t } timestamp +2kΔt,t timestamp +(2k-1)Δt,…,t timestamp +(k+1)Δt}。
Fig. 6 shows the life cycle of the intelligent contract at each stage in fig. 5, where the horizontal axis is a time axis with Δ t as a unit, the vertical axis is each node participating in contract deployment and execution, the gray solid arrows indicate the intelligent contract deployment negotiated by the arrow head and tail nodes, and the arrows point to the direction indicating the transfer of committed assets in the intelligent contract; the black solid arrow indicates that the corresponding node at the head of the arrow sends the value transfer key to the intelligent contract at the corresponding moment at the tail
Triggering contract execution, wherein an arrow points to a direction which represents the actual asset transfer in the intelligent contract; the intelligent contract is executed and returns to the red dotted line in the form of a return valueThe arrow points to the node to send the value transfer key to trigger the execution of the subsequent intelligent contract; the black bold line segments represent each intelligent contract life cycle taking the nodes corresponding to the longitudinal axis as initiating nodes.
Rational nodes expect that contracts can be executed without losing benefits of the rational nodes, and therefore the rational nodes tend to trigger contracts as soon as possible after acquiring value transfer keys to realize value transfer. Fig. 7 and 8 illustrate the intelligent contract deployment process, the intelligent contract triggering process and the intelligent contract execution process in fig. 6 in more detail, in fig. 8, the solid arrows indicate deployed intelligent contracts, the black dashed arrows indicate executed intelligent contracts, and the gray dashed arrows indicate executing intelligent contracts; value transfer key
The complete value transfer process is as follows:
step (1), as shown in part (a) of fig. 7, requests the originating node
Creating a value transfer key ≧ based>
Selecting a one-way collision-resistant hash function H (·), calculating &>
And/or>
Negotiating and deploying with hash lock h and time lock t timestamp An intelligent contract of +8 delta t to realize->
To/is>
Is entrusted with transfer. If/or>
At time t timestamp +8 Δ t forward smart contract sending value transfer key &>
So that>
Then the credit hosted in the smart contract will irrevocably slave @>
Is transferred to
If/or>
At time t timestamp Failing to reveal the secret before +8 Δ t, is based on +>
Initiating a credit return transaction, the credit held in the smart contract will be returned to ^ er>
Followed by simple expression, and>
step (2), as shown in part (b) of FIG. 7, the nodes
Confirming that the intelligent contract in step (1) is stably deployed and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The +7 delta t intelligent contract utilizes a preset alliance inter-chain heterogeneous value exchange function to realize value C such as the intelligent contract hosting point in the step (1) A System score slave &>
Transfer to->
The intelligent contract execution logic of the step (2), the step (3) and the step (4) is similar to that of the step (1), and is not described again.
Step (3), as shown in part (c) of FIG. 7, the nodes
Confirming that the intelligent contract is stably deployed in step (2), and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +6 delta t realizes that the equivalent score is subjected to from/to in the step (2) with the intelligent contract hosting integral>
Transfer to->
The hosting of (1).
Step (4), node points as shown in part (d) of FIG. 7
After confirming that the intelligent contract is stably deployed in the step (3), and
negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +5 delta t realizes the equivalent integral slave/based on the intelligent contract hosting integral in the step (3)>
Is transferred to->
The hosting of (1).
Step (5), as shown in part (a) of FIG. 8,
after the intelligent contract is stably deployed in the step (4) is confirmed, a value transfer key s is input into the contract within the contract validity period, the contract is triggered to be executed, and the value in the contract is judged and judged>
Managed assets, which after contract execution is completed, can be returned to intelligent contract deployer in the form of return value>
The value transfer key s is sent.
Step (6), as shown in part (b) of fig. 8, similarly,
after obtaining the value transfer key s, inputting the value transfer key s to the contract within the validity period of the intelligent contract deployed in step (3), triggering contract execution, and then judging whether the value transfer key s is in the valid period of the intelligent contract or not>
In a contract>
Managed assets, which after contract execution is completed, can be returned to intelligent contract deployer in the form of return value>
The value transfer key s is sent.
Step (7), as shown in part (c) of FIG. 8,
after obtaining the value transfer key s, inputting the value transfer key s to the contract within the validity period of the intelligent contract deployed in step (2), triggering contract execution, and then judging whether the value transfer key s is in the valid period of the intelligent contract or not>
In a contract>
The managed assets are processed into return values to the intelligent contract deployer to be treated as ^ er>
The value transfer key s is sent.
Step (8), as shown in part (d) of FIG. 8,
after obtaining the value transfer key s, inputting the value transfer key s into the contract within the validity period of the intelligent contract deployed in step (1), triggering contract execution, and then judging whether the value transfer key s is in the valid period of the intelligent contract or not>
Gets a contract to->
A hosted asset.
Through the steps (1) to (8), value transfer among different alliance chain nodes is achieved, and an intelligent contract value transfer algorithm is shown as algorithm 1. The algorithm makes the following limitations: the value transfer function only accepts and verifies the value transfer key provided by the designated transaction partner; the value transfer function returns a value transfer key only to the asset hosting party providing the legal path certification; the asset return function only accepts and validates asset hosted calls.
Inputting: a transaction responder (i.e., an asset hosting party) responder, a transaction initiator, a hosting asset ξ; the responder path proves the triplet (m, p, σ), the value transfer key s, the current time t current ；
And (3) outputting: if the triggering condition is met, executing the contract, transferring the contract hosting asset to a resequester, and returning a value transfer key s to a resender; if the contract cannot be triggered within the validity period, the responder initiates a contract asset return transaction to return the asset hosted in the smart contract to the responder.
To verify the effect of the invention, the following analysis and verification and experimental setup were performed:
1) Performance analysis
(1) Security analysis
Hypothesis groups
Wherein there are actually t nodes signing the transaction TX, wherein at least t A Each node comes from a subgroup->
At least t B Each node comes from a subgroup->
Has the following structure of formula (23)
Therefore, there is a verification equation (24) established
As is clear from the expressions (23) and (24), the gene is not in the group
In which the node is unable to participate in or interfere with the verification process, non-cooperativeThe forged cross-link communication path proves that the forged cross-link communication path cannot be verified, and the system ignores the corresponding transaction; if group is greater or less>
With less than t nodes participating in the signature, it is possible to recover the component g X (0) X belongs to { A, B }, but the component f (0) cannot be recovered, so that the group private key cannot be obtained and is verified; if group->
The node in which the signature is involved is greater than or equal to t, subgroup->
The number of nodes participating in verification is less than t X Component f (0) can be recovered, but component g cannot be recovered X (0) The group private key still cannot be obtained and verified. Therefore, the identity validity proof of node communication between the alliance chains can be realized by using the threshold group signature mechanism based on the privilege subgroups, and the system security is improved.
(2) Extensibility analysis
Inter-chain path attestation group signature protocol (t) A ,n A ；t B ,n B (ii) a t, n) easily generalizes to the more federation chain participating multi-privileged subgroup path proof group signature protocol (t) A ,n A ；t B ,n B ；…；t X ,n X (ii) a t, n), the extension method is as follows: in the protocol establishment stage, | { A, B, …, X } | +1 polynomial f (X), g A (x)，g B (x)，…，g X (x) The calculation methods of the group private key and the group public key expanded by the formulas (12) and (13) are as shown in formulas (25) and (26).
In equations (25) and (26), the nodes in each privilege subgroup hold a component f (x) i ) And corresponding component
Request originating node u 0 To the responding node u k Directed communication path signature σ = sig (… sig (m, u) 0 ),…,u k ) Comprising u 0 、u k The single node signature and the threshold signatures of the relay subgroups on the communication path are realized, wherein the reliability of node identities is ensured by a node subgroup consensus mechanism verified by a federation chain where the single node is located, the safety of the threshold group signature mechanism provides safety guarantee for cross-chain communication of messages on the one hand, and meanwhile, the message transmission path is limited in a federation chain system with a cooperative relationship established, so that the expandability is good.
(3) Value transfer game analysis
FIG. 9 depicts arbitrary nodes from a node cooperative gaming perspective
(or +>
) And triggering four possible situations of value transfer of the intelligent contracts, wherein a solid arrow represents that the value transfer intelligent contracts are deployed, and a dotted arrow represents that only the corresponding intelligent contracts are triggered when the interaction is finished, so that the value transfer occurs. In fig. 9, (a) the intelligent contracts corresponding to the entry edge and the exit edge of part of the nodes are not triggered, which indicates that no value is transmitted through the nodes, the gains of the nodes are not changed, but the willingness of the rational nodes to participate and achieve interaction is violated; part (b) in fig. 9 is that only the value transfer intelligent contract corresponding to the node outgoing edge is triggered, the value transfer intelligent contract corresponding to the node incoming edge is not triggered, the node value is lost, the complex situation that the node is latent in the system and intentionally makes other types of attacks is eliminated, and the rational node does not actively select the strategy; part (c) of FIG. 9 shows that only the value transfer intelligence contract corresponding to the node in-edge is triggered and the value transfer intelligence corresponding to the node out-edge is triggeredThe energy contract is not triggered, the value of the node is increased, and the node can actively select the strategy to maximize the benefit of the node under the condition of no constraint; in fig. 9, (d) the value transfer intelligent contracts corresponding to the entrance and exit edges of the part of nodes are all triggered, the nodes participate in value flow, and the value is conserved, which is a normal situation that rational nodes want to participate and achieve value interaction. From the above analysis, the optimal strategy for selecting the value transfer strategy by the rational nodes is part (c) in fig. 9, and the reasonable value transfer strategy between the nodes of different healthcare alliance chains is part (d) in fig. 9.
Under the value transfer mode proposed by the invention, the nodes participating in the cross-chain value transfer comprise a request initiating node, a response node and a relay node, wherein the request initiating node in the graph 7
Observe that its incoming intelligent contract is formed by>
Will only send a value transfer key ≧ to the contract after participation and stable deployment>
Triggering a value transfer>
Observe its incoming edge intelligent contract is by>
After participating and stable deployment, the intelligent contract at the outgoing edge is deployed, and so on. Rational nodes hope to participate and achieve value interaction, and the intelligent contract for guaranteeing value transfer among nodes on mechanism needs to be sequentially carried out at t timestamp The deployment is completed sequentially within + { k Δ t, (k-1) Δ t, …, Δ t } (where k = 4). Self-judgment>
The period of validity of the value transfer intelligence contract that begins to be deployed between nodes of a communication link in a counter-clockwise direction depends onSub is t timestamp + { (k + 1) Δ t, (k + 2) Δ t, …,2k Δ t }, as shown in FIG. 8.
The following analysis
To or>
And (4) transferring the value of each node on the communication link to a game process. />
In FIG. 9 as part (a), as a rational transaction initiating node, and>
it is desirable to have a cross-link value interaction occur, and therefore, be asserted>
Will send it a value transfer key in the validity period of its incoming intelligent contract>
Trigger value transfer, in a short time->
Proceed to portion (c) of state diagram 9, where the value transfer key is returned to the £ er after the intelligent contract has been executed>
Is based on the fact that it is in a short time>
The state will be entered in part (b) of fig. 9, because @>
It is rational, it will send the value to transfer the cipher key to it in its entering intelligent contract valid period after obtaining the value and transfer the self state toSection (d) of FIG. 9 shows the return of a value transfer key to a £ er after execution of the intelligent contract has been completed>
Similarly, in>
By triggering an intelligent edge-entering contract in the validity period, will->
The status is finally changed from part (b) of FIG. 9 to part (d) of FIG. 9, which will->
The state is finally changed from the part (c) in fig. 9 to the part (d) in fig. 9.
Through the analysis, the value transfer mode provided by the invention can ensure that the intelligent contract is deployed from the mechanism to realize the value transfer among the nodes of different medical alliance chains: if all parties are in compliance with the value transfer mode provided by the invention, cross-chain value interaction can occur by triggering an intelligent contract; if a participant somehow violates a set value transfer method, only the node condition will get worse.
2) Experimental deployment
In order to test the feasibility and performance of the privilege threshold digital signature cross-chain consensus mechanism based on the path certification, an Ethereum simulation test environment consisting of 230 virtual verification nodes is constructed on 5 servers, and an experiment platform is as follows: the CPU is Xeon-E5, the memory size is 64G, and the operating system is Ubuntu-64bit.
The consensus process mainly comprises four parts of node key generation, key reconstruction calculation, consensus signature and consensus signature verification. The node key generation is obtained by pre-calculation among nodes, network time delay is not required to be included, and the actual network time delay is mainly influenced by key reconstruction calculation, consensus signature and consensus signature verification calculation. Therefore, the network delay overhead calculation method is to sum the time overhead of the three.
(1) Single chain performance test
In a single-chain environment, the number of verification nodes n =230, when a threshold value t takes 10 as a step length to take different values in an interval [10,100], the actual network delay variation situation is shown as part (a) in fig. 10, and it can be seen that when t ∈ (50, 100], the network delay significantly rises, therefore, taking t =50, the network delay variation situation is tested when the total number of verification nodes n takes 20 as a step length to take different values in an interval [50,230], and the test result is shown as part (b) in fig. 10, it can be seen that the network delay fluctuates up and down with the value of n, but basically tends to be stable, which indicates that the network delay is not greatly influenced by the variation of n and is mainly influenced by t.
(2) Inter-chain performance test
Configuration n =100,t =50,n A ＝n B =50 duplex links, test for inter-link performance. t is t A +t B When = t, threshold value t B In the interval of 5 steps (5,45)]The variation of the network delay between the internal different value time chains is shown in part (a) of fig. 11, and it can be seen that when the group threshold t is fixed, the variation follows the subgroup threshold t B The inter-chain network delay fluctuates regularly. Multiple test results show that when t is reached X And the network delay is smaller and the performance is better when → t/m (X belongs to { A, B, … }, and m > 1 is the number of alliance chains for establishing the cooperative relationship).
The test result indicates that the inter-link communication time delay of the scheme provided by the invention is under the condition that the verification nodes of all the alliance links have the same scale and the privilege subgroups have the same right. According to the single-chain performance test result, the total number n of the network delay subject verification nodes is not greatly influenced and is mainly influenced by the threshold value t, so that the subgroup threshold value t can be obtained when the verification nodes of all the cooperative alliance chains are different in scale X The conclusion that inter-chain communication achieves better performance is still true for → t/m (X ∈ { A, B, … }, m > 1).
Considering that in an actual application scenario, the rights of all the partners in the federation chain are not equal, t is fixed A Change of t B To t, for A +t B The test was performed for > t. Heavy loadNewly setting the double alliance parameters: n =100,t =50,n A ＝n B ＝50，t A =25, for t B In the interval of 5 steps (25,45)]The network delay variation situation between the time chains with different values is internally tested to obtain part (b) in fig. 11, and in this scene, the time delay variation situation is measured along with t B The inter-chain network delay fluctuates to some extent, but the general trend is to increase. Therefore, we conclude that adding a party right will increase inter-link network latency on the basis of the identity of multiple federation link partner rights.
(3) Intelligent contract deployment and execution
In the simulation test environment, a lightweight intelligent contract is constructed according to an algorithm 1, and a complete cross-chain interaction is realized by deploying a 4-stage intelligent contract. The Hash locking function adopts SHA256 with high safety, according to the communication performance test result in the simulation test environment, the upper limit delta t of the node response time is set to be 160ms, and the upper limit t = t A +t B ，t A ＝t B In this case, different verification node sizes n =100 and n =200 were tested, respectively, resulting in fig. 12.
The 4-stage contract deployment time delay mainly comes from three parts, namely intra-chain consensus, inter-chain consensus and response interval delta t of a node to contract deployment. As can be seen from fig. 12, assuming that the response interval Δ t of a node to contract deployment is constant, (i) at different verification node sizes n =100 and n =200, the network delay increases with increasing threshold value; (ii) Under the condition that the threshold value of the consensus mechanism is not changed, the network delay can be reduced within a certain range by increasing the number of the verification nodes.
Under two built test environments n =100 and n =200, respectively testing the 4-phase contract execution time delay condition. After the intelligent contracts in each stage are deployed stably, the request initiating node sends the value transfer key to the intelligent contracts deployed in the 4 th stage, and the execution of the contracts in the other stages is triggered in sequence, so that the execution delay of the 4-stage intelligent contracts is shown in fig. 13. It can be seen that, as the consensus threshold value increases, the network delay of the 4-phase intelligent contract execution process shows similar changes as the deployment process, however, under the condition that the consensus threshold value and the verification node are the same in size, the 4-phase contract execution delay is slightly increased than the deployment delay. This is because the 4-phase contract execution delay is affected by SHA256 hash calculation and the actual response delay of the nodes on the communication path, in addition to the delay caused by intra-chain consensus and inter-chain consensus.
The execution time delay of the cross-chain interaction mechanism provided by the invention is the sum of the 4-stage intelligent contract deployment and the execution time delay (namely, the total number of 8-stages), is mainly influenced by the consensus threshold value and the response interval delta t of the node to the contract deployment, and the time delay caused by the hash operation for locking the value transfer is smaller under the calculation capacity of the conventional terminal, so that the reliability of the multi-stage intelligent contract value transfer is conveniently ensured by utilizing the unidirectional property of the high-security hash algorithm. In addition, under the test environment, the one-time complete cross-chain interaction time delay is in the second level, and the response requirement of the medical alliance chain cross-chain communication can be basically met.
The above shows only the preferred embodiments of the present invention, and it should be noted that it is obvious to those skilled in the art that various modifications and improvements can be made without departing from the principle of the present invention, and these modifications and improvements should also be considered as the protection scope of the present invention.
Claims (5)
1. A lightweight dynamic autonomous cross-link interaction method for a medical alliance link is characterized by comprising the following steps:
constructing a cross-chain consensus mechanism based on threshold digital signatures;
constructing a cross-chain path attestation signature, comprising: generating and sharing a group key, generating a threshold subgroup signature and updating a path certificate;
value transfer among different alliance chain nodes is realized;
the method for realizing the value transfer among the nodes of the different alliance chains comprises the following steps:
step 3.1: in creating value transfer keys
Then, the request initiating node->
Selecting a one-way collision-resistant hash function H (·), and calculating ^ H->
And/or>
Negotiating and deploying with hash lock h and time lock t timestamp An intelligent contract of +8 delta t to realize->
To or>
Integral transfer hosting of (1), where t timestamp Representing the time of a first phase smart contract of a cross-chain communication, Δ t representing a minimum time interval; if/or>
At time t timestamp +8 Δ t Forward Smart contract sending value transfer Key @>
So that
Then the credit hosted in the smart contract is irrevocably slave ÷ based>
Transfer to +>
If>
At the time ofTime t timestamp Failing to reveal the secret before +8 Δ t, is based on +>
Initiating a point return transaction to return points held in the smart contract to ÷ based on the number of points held in the smart contract>
Step 3.2: node point
Confirm that the smart contract is stably deployed at step 3.1, and @>
Negotiate and deploy HashLock as h and time Lock as t timestamp The +7 delta t intelligent contract utilizes a preset union inter-chain heterogeneous value exchange function to realize the value C such as the intelligent contract hosting point in the step 3.1 A System score slave &>
Is transferred to->
The hosting of (1);
step 3.3: node point
Confirm that the intelligent contract is stably deployed at step 3.2, and respond to the node ≥>
Negotiate and deploy HashLock as h and time Lock as t timestamp The intelligent contract of +6 delta t realizes that the equivalent score is subjected to from/to in step 3.2>
Transfer to->
The hosting of (1);
step 3.4: node point
After confirming stable deployment of the intelligent contract in step 3.3, and->
Negotiate and deploy Hash Lock as h and time Lock as t timestamp The intelligent contract of +5 delta t realizes that the equivalent score is subjected to from/to in step 3.3>
Is transferred to->
The hosting pipe of (a);
step 3.5:
after confirming the stable deployment of the intelligent contract in step 3.4, the value transfer key is entered into the contract for the contract validity period->
Triggering contract execution to obtain->
The managed assets are processed into return values to the intelligent contract deployer to be treated as ^ er>
Sending a value transfer key s;
step 3.6:
obtain value transfer key->
Thereafter, the value transfer key is entered into the contract for the duration of the intelligent contract expiration deployed at step 3.3>
Trigger contract execution, and->
Gets a contract to->
The managed assets are processed into return values to the intelligent contract deployer to be treated as ^ er>
Sending value transfer key>
Step 3.7:
obtain value transfer key->
Thereafter, the value transfer key is entered into the contract for the duration of the intelligent contract expiration deployed at step 3.2>
Trigger contract execution, and->
In obtaining a contract/>
Managed assets, which after contract execution is completed, can be returned to intelligent contract deployer in the form of return value>
Sending a value transfer key->
Step 3.8:
obtain value transfer key->
Thereafter, the value transfer key is entered into the contract for the duration of the intelligent contract expiration deployed at step 3.1>
Trigger contract execution, and->
Gets a contract to->
A hosted asset.
2. The method of claim 1, wherein the constructing a cross-chain consensus machine based on a threshold digital signature comprises:
m federation chains C for establishing cooperative relationships 1 ,C 2 ,…,C m Set of verification node lists as groups
Each federation chain verification node list is referenced as a group->
Wherein m mutually disjoint privilege subgroups +>
Generating groups +based on a privileged subgroup threshold signature mechanism>
Is coupled with a public and private key>
Federation inter-chain partnerships are represented as:
wherein n is i Representing subgroups
Verification nodeNumber of nodes in the list, t i Indicating that a privilege subgroup is asserted>
N of (A) to (B) i Minimum number of nodes, t, that an individual verification node passes a certain verification i ' represents n i The number of nodes actually passing a certain verification in each verification node, t represents the group
The n verification nodes pass the minimum node number of a certain verification, and TX represents a transaction; equation (4) defines the cooperative relationship among the federation chains, equations (5) and (6) represent the scale of the set of federation chain verification nodes, equation (7) represents the threshold consensus based on the verification node list in the federation chains, and equation (8) represents the cross-chain consensus based on the privilege subgroup threshold signature mechanism.
3. The method of claim 2, wherein the group key generation and sharing comprises:
randomly generating a group private key according to equation (12), calculating a group public key according to equation (13), and distributing the group private key by adopting a secret sharing algorithm based on Shamir:
wherein u and v are safety prime numbers and satisfy v | (u-1), f (0), g A (0)，g B (0) Respectively in a finite field Z v 3 polynomials f (x), g secretly selected A (x)，g B (x) Of alpha finite field Z v The primitive of (1);
sub-grouping privileges
The abstraction is a privilege node in the directed path certification, and the privilege node is based on a secret sharing algorithm>
Secret distribution group private key fragment->
j＝1,2,…,n A ，k＝1,2,…,n B Calculating the privilege node ^ according to equation (14)>
And discloses:
wherein λ is i ，μ i Is a publicly computable lagrangian coefficient in the Shamir secret sharing algorithm.
4. The method of claim 3, wherein the threshold subgroup signature generation comprises:
computing a public key fragment by equation (15)
Evaluation of a subgroup by means of equation (16)>
Public key r of internal verification node subgroup X Calculating the private key segment ^ of the single verification node by the formula (17)>
Wherein
Represents the randomly chosen parameters for generating the signature, TX is the signed transaction, h (x) is the secure hash function;
authentication group by equation (18)
Is verified against a single verification node signature within a node subgroup of>
The legitimacy of (c):
if equation (18) holds, the subgroup of verification nodes accepts the signature of the single verification node in the subgroup
When +>
Then, the private key s of the subgroup is calculated by equation (19) X Is asserted by the response node>
The subgroup of verification nodes of the federation chain>
Generating a subgroup combined signature ^ according to equation (20)>
5. The method of claim 4, wherein the path attestation update comprises:
after the sub-group signatures are combined,
will switch on according to equation (21)>
In a group signature and request originating node>
Issued request->
Write transaction @together>
Updating the transaction path certificate:
response node
For transaction->
Verification is carried out, after passing, the>
Utilizing local assets->
Based on external request->
Performs a calculation to generate a blind response->
Will switch on according to equation (22)>
Blind response and updated path proving and & ->
Write transaction @together>
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911187519.4A CN110993044B (en) | 2019-11-28 | 2019-11-28 | Lightweight dynamic autonomous cross-link interaction method for medical alliance link |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911187519.4A CN110993044B (en) | 2019-11-28 | 2019-11-28 | Lightweight dynamic autonomous cross-link interaction method for medical alliance link |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110993044A CN110993044A (en) | 2020-04-10 |
| CN110993044B true CN110993044B (en) | 2023-03-28 |
Family
ID=70087589
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911187519.4A Active CN110993044B (en) | 2019-11-28 | 2019-11-28 | Lightweight dynamic autonomous cross-link interaction method for medical alliance link |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110993044B (en) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111556172B (en) * | 2020-06-16 | 2021-09-21 | 常熟理工学院 | Implementation method of intelligent medical care monitoring system based on biological characteristics |
| CN112104607B (en) * | 2020-08-13 | 2023-03-21 | 北京新盛云佳科技有限公司 | Method, device, network node and storage medium for cross-link communication |
| CN112583598A (en) * | 2020-11-10 | 2021-03-30 | 周口师范学院 | Complex Internet of things alliance chain system communication mechanism |
| CN112435024B (en) * | 2020-11-17 | 2022-06-10 | 浙江大学 | Alliance chain cross-chain privacy protection method based on group signature and CA multi-party authentication |
| CN112364317B (en) * | 2020-11-17 | 2024-04-19 | 中国传媒大学 | Internet of things fog environment management architecture and method based on blockchain technology |
| CN112769568B (en) * | 2021-01-29 | 2022-07-22 | 华中师范大学 | Security authentication communication system and method in fog computing environment and Internet of things equipment |
| CN112948853A (en) * | 2021-02-26 | 2021-06-11 | 安徽航天信息科技有限公司 | Block chain-based medical data sharing method, device, equipment and storage medium |
| CN113067857B (en) * | 2021-03-15 | 2023-04-18 | 新疆大学 | Electronic medical record cross-hospital sharing method based on double-chain structure |
| CN113268732B (en) * | 2021-04-19 | 2022-12-20 | 中国人民解放军战略支援部队信息工程大学 | Method and system for detecting similarity of intelligent contracts of identity |
| CN113312005B (en) * | 2021-06-22 | 2022-11-01 | 青岛理工大学 | Block chain-based Internet of things data capacity expansion storage method and system and computing equipment |
| CN113538140A (en) * | 2021-07-05 | 2021-10-22 | 杭州宇链科技有限公司 | Data transaction method based on trusted execution environment and threshold signature |
| GB2609908B (en) * | 2021-08-09 | 2023-10-18 | Nchain Licensing Ag | Generating Digital signatures |
| CN113747433B (en) * | 2021-09-07 | 2023-12-19 | 深圳市兴海物联科技有限公司 | Equipment authentication method based on block side chain structure in fog network |
| CN115052001B (en) * | 2022-06-09 | 2024-04-05 | 上海万向区块链股份公司 | Extendibility solving method, system and medium for alliance chain |
| US20240144257A1 (en) * | 2022-11-01 | 2024-05-02 | Analog One Corporation | Methods and systems for implementing an omni-chain interoperability protocol in an omni-chain network |
| CN115860744B (en) * | 2023-02-20 | 2023-05-09 | 中国信息通信研究院 | Processing method and device of cross-blockchain transaction, blockchain system and equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018032374A1 (en) * | 2016-08-13 | 2018-02-22 | 深圳市樊溪电子有限公司 | Encrypted storage system for block chain and method using same |
| CN108009811A (en) * | 2017-11-30 | 2018-05-08 | 中国人民解放军国防科技大学 | Inter-cloud computing environment value exchange-oriented cross-chain communication method |
| CN109104286A (en) * | 2018-07-26 | 2018-12-28 | 杭州安恒信息技术股份有限公司 | A kind of new block generation method of the common recognition based on threshold digital signature |
| CN109685489A (en) * | 2018-12-28 | 2019-04-26 | 杭州云象网络技术有限公司 | A kind of assets across chain method of commerce between block chain |
| CN110299195A (en) * | 2019-06-11 | 2019-10-01 | 中国矿业大学 | The electronic health record shared system and application method with secret protection based on alliance's chain |
-
2019
- 2019-11-28 CN CN201911187519.4A patent/CN110993044B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018032374A1 (en) * | 2016-08-13 | 2018-02-22 | 深圳市樊溪电子有限公司 | Encrypted storage system for block chain and method using same |
| CN108009811A (en) * | 2017-11-30 | 2018-05-08 | 中国人民解放军国防科技大学 | Inter-cloud computing environment value exchange-oriented cross-chain communication method |
| CN109104286A (en) * | 2018-07-26 | 2018-12-28 | 杭州安恒信息技术股份有限公司 | A kind of new block generation method of the common recognition based on threshold digital signature |
| CN109685489A (en) * | 2018-12-28 | 2019-04-26 | 杭州云象网络技术有限公司 | A kind of assets across chain method of commerce between block chain |
| CN110299195A (en) * | 2019-06-11 | 2019-10-01 | 中国矿业大学 | The electronic health record shared system and application method with secret protection based on alliance's chain |
Non-Patent Citations (2)
| Title |
|---|
| "Optimization of dynamic data traceability mechanism in Internet of Things based on consortium block chain";Rui Qiao et al.;《International Journal of Distributed Sensor Networks》;20181231;第1-15页 * |
| "基于联盟链的物联网动态数据溯源机制";乔蕊 等;《软件学报》;20190327;第1614-1631页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110993044A (en) | 2020-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110993044B (en) | Lightweight dynamic autonomous cross-link interaction method for medical alliance link | |
| Da Xu et al. | Embedding blockchain technology into IoT for security: A survey | |
| Jesus et al. | A survey of how to use blockchain to secure internet of things and the stalker attack | |
| Fernández-Caramés et al. | A Review on the Use of Blockchain for the Internet of Things | |
| Li et al. | Rational protocols and attacks in blockchain system | |
| Qiao et al. | Dynamic autonomous cross consortium chain mechanism in e-healthcare | |
| Alladi et al. | A comprehensive survey on the applications of blockchain for securing vehicular networks | |
| Kaur et al. | Blockchain-based cyber-physical security for electrical vehicle aided smart grid ecosystem | |
| CN107113179B (en) | Method, system, and non-transitory computer-readable storage medium for communication authentication | |
| Alizadeh et al. | A survey of secure internet of things in relation to blockchain | |
| Zhang et al. | BTCAS: A blockchain-based thoroughly cross-domain authentication scheme | |
| Liang et al. | Secure fusion approach for the internet of things in smart autonomous multi-robot systems | |
| Le et al. | A lightweight block validation method for resource-constrained iot devices in blockchain-based applications | |
| CN112583598A (en) | Complex Internet of things alliance chain system communication mechanism | |
| Ren et al. | HCNCT: A cross-chain interaction scheme for the blockchain-based metaverse | |
| Khalil et al. | FAKey: Fake hashed key attack on payment channel networks | |
| Koe et al. | Hieraledger: towards malicious gateways in appendable-block blockchain constructions for IoT | |
| Porkodi et al. | Integration of blockchain and internet of things | |
| Ren et al. | Building resilient Web 3.0 with quantum information technologies and blockchain: An ambilateral view | |
| Xie et al. | HCVC: A high-capacity off-chain virtual channel scheme based on bidirectional locking mechanism | |
| Deebak et al. | Healthcare applications using blockchain with a cloud-assisted decentralized privacy-preserving framework | |
| Wang et al. | A blockchain-based conditional privacy-preserving authentication scheme for edge computing services | |
| Bhattacharya et al. | LightBlocks: A trusted lightweight signcryption and consensus scheme for industrial IoT ecosystems | |
| Singh et al. | Blockchain applications, opportunities, challenges and risks: a survey | |
| Dai et al. | A multi-hop cross-blockchain transaction model based on improved hash-locking |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |