CN113839768A - Cross-link communication method based on satellite link relay - Google Patents

Cross-link communication method based on satellite link relay Download PDF

Info

Publication number
CN113839768A
CN113839768A CN202111119894.2A CN202111119894A CN113839768A CN 113839768 A CN113839768 A CN 113839768A CN 202111119894 A CN202111119894 A CN 202111119894A CN 113839768 A CN113839768 A CN 113839768A
Authority
CN
China
Prior art keywords
chain
cross
link
node
satellite
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.)
Granted
Application number
CN202111119894.2A
Other languages
Chinese (zh)
Other versions
CN113839768B (en
Inventor
范时平
刘思思
徐光侠
马创
刘俊
张家俊
曾茂森
谢佳吟
周宗成
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chongqing University of Post and Telecommunications
Original Assignee
Chongqing University of Post and Telecommunications
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Chongqing University of Post and Telecommunications filed Critical Chongqing University of Post and Telecommunications
Priority to CN202111119894.2A priority Critical patent/CN113839768B/en
Publication of CN113839768A publication Critical patent/CN113839768A/en
Application granted granted Critical
Publication of CN113839768B publication Critical patent/CN113839768B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Radio Relay Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention belongs to the technical field of block chains, and particularly relates to a cross-link communication method based on satellite chain relay, which comprises the following steps: classifying nodes in the block chain, and realizing communication and information transmission between other block chains and a satellite chain by adopting an independent cross-chain gateway; the satellite chain is used as an independent relay chain, the chain is initialized, and a credit consensus mechanism POC is adopted for transaction calling, so that the expandability of the satellite chain is realized; adapting a public link protocol and a cross-link protocol to realize inter-link communication; using an improved Byzantine fault-tolerant algorithm mechanism to confirm transaction information in a satellite chain to complete communication; aiming at the cross-link communication requirement in the block chain, the invention combines a Byzantine fault-tolerant mechanism to realize the confirmation and the packaging of the cross-link transaction, thereby ensuring the decentralization and the safety of the transmission information.

Description

Cross-link communication method based on satellite link relay
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a cross-link communication method based on satellite chain relay.
Background
The block chain is used as a decentralized database and is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, a secret algorithm and the like. The data blocks are combined into a chain type data structure according to the time sequence, the distributed data account book is guaranteed to be not falsifiable and counterfeitable by adopting a cryptography technology, the distributed data account book is an application which needs all network nodes to achieve consensus, and the application mechanism guarantees high integrity and transparency of a block chain.
With the development of block chain technology, more and more chains appear, including public chains, alliance chains and private chains, and interconnection and intercommunication between chains become more and more important, and the transfer of cross-chain information becomes a very important research problem. But the blockchains based on a single architecture do not scale well and communication transmission and interoperability between different blockchains is hampered. The cross-chain technology can be understood as a bridge between various blockchains, and is a complex process, which needs to independently verify nodes in the chain, scatter input, acquire and verify information in the world of the external chain, and acquire and verify information in the world of the external chain. Currently, the main chain-crossing technologies are: notarization scheme, side chain/relay, hash lock, etc.; however, the above-mentioned cross-chain technology cannot implement cross-chain communication of complex services, and can only serve simple business scenarios, such as asset transaction between two entities in a cross-chain, and each party involved in an intelligent contract usually has only two parties at a time, and cannot implement cross-chain communication of complex rules. In the aspect of cross-link information transaction and transmission, the improvement of the speed and the expandability of cross-link communication is particularly important. Therefore, it is necessary to provide a satellite link relay cross-link communication method to ensure the security, privacy and effectiveness of the transaction information transmission process.
Disclosure of Invention
In order to solve the problems in the prior art, the invention provides a cross-link communication method based on satellite link relay, which comprises the following steps:
s1: acquiring all nodes in a block chain network, and dividing all the nodes into a cross-link node group, a common node group and an application node group;
s2: applying nodes U in a node groupaInitiating a cross-chain transaction Requesta(ii) a The block chain performs homomorphic encryption packaging on the request data of the node to determine encrypted data information; consensus node group to node UaCarrying out consensus computing service on the initiated cross-chain transaction request;
s3: the first cross-link gateway receives cross-link transaction request information, verifies the cross-link transaction request through information receipt feedback, packages the received transaction signature and transaction information, and sends the transaction signature and the transaction information to a satellite link relay;
s4: satellite chain relay node selection satellite chain relay node Satenodex(ii) a After receiving the cross-link transaction request packaged by the first cross-link gateway, the satellite link relay node verifies the transaction reliability of the cross-link transaction request, packages the cross-link transaction request if the verification is passed, and invalidates the transaction if the verification is not passed;
s5: satellite chain relay node SatenodexVerifying the consensus calculation result in the request information, if the consensus calculation result passes the verification, allowing the cross-chain transaction request to obtain a satellite chain relay node, packaging all information of the cross-chain transaction request, and sending the packaged information to a second cross-chainThe gateway, if the verification fails, the transaction is invalid;
s6: the second cross-link gateway confirms the received packed transaction request and sends the confirmed transaction request to other application nodes U of the application node groupb；
S7：UbThe transaction request is confirmed by adopting a chain independent consensus mechanism, and if the confirmation is passed, the transaction request is confirmed at an application chain link point UbOn account of (2) processing a cross-chain Request information RequestaCreating corresponding asset credential information to enable the asset to be at the application link point UbIf the confirmation is not passed, the Request is discardedaAnd (6) transaction request. The confirmed transaction request includes content information and authentication information for the transaction.
Preferably, the process of dividing the nodes includes: acquiring all node data, converting the node data into histogram gray distribution data, and selecting partial distribution with a quantile value of 90% by adopting a one-dimensional histogram thresholding method; grading the partial distribution values of the nodes by adopting a grading rule; setting classification node threshold S1And S2In which S is1>S2(ii) a When the node data score satisfies S ≧ S1When the node is a common node group; when the node data score satisfies S1≥S≥S2Then, the node is a cross-link node group; when the node data score satisfies S2And when the node is more than or equal to S, the node is an application node group.
Further, the set scoring rule is as follows: if the node n of the block is determined to verify the participation information AnWhether to participate in the consensus verification weight SABlock information BnWhether the result obtained by the corresponding participation consensus verification is correct or not is the weight SBThen the score of the block node n is: s ═ PA*SA+PB*SBIn which P isAAnd PBIs a preset value, PA+PB＝1，PA>0 and PB>0。
Preferably, the process of homomorphic encryption and encapsulation of the request data of the node by the blockchain comprises:
step 1: generating a homomorphic secret key by the block chain, wherein the secret key comprises a homomorphic public key PK and a homomorphic private key SK;
step 2: sending the homomorphic public key PK to a first cross-chain gateway, and randomly generating a corresponding Symmetric key Symmetric by the first cross-chain gatewaykey(ii) a Encrypting the symmetric key by adopting a homomorphic public key PK;
and step 3: the first cross-link gateway returns the encrypted symmetric key to the blockchain.
Preferably, the process of verifying the cross-chain transaction request through the information receipt feedback comprises:
s31: first cross-link gateway real-time monitoring Application node group ApplicationnodeIf the event is lost, directly acquiring the lost event from the application node group;
s32: a Client is realized on the first cross-link gateway, and a Server is realized on the satellite link relay; the client and the server transmit data in a GRPC communication mode, and package and send the cross-link transaction request to the satellite link relay through short connection;
s33: satellite chain relay node Satenode continuously synchronized by first cross-chain gatewayxThe block initiates block message subscription to a satellite chain relay, and waits for a relay chain to send a cross-chain transaction request to a cross-chain node group through a satellite chain length connection flow;
s34: addressing a next hop through the DHT, wherein the address of the next hop is determined by a distributed routing table in the first cross-link gateway, and the distributed routing table records a node group ID set on a satellite link relay governed by the first cross-link gateway;
s35: and the first cross-link gateway calls the destination link contract, if the first cross-link gateway fails, the request is terminated, otherwise, the cross-link transaction request is successfully verified.
Preferably, satellite chain relay selects satellite chain relay node SatenodexThe method comprises the step of selecting the satellite chain relay node by the POC (push to talk over cellular) by adopting a credit consensus mechanism.
Further, the credit consensus mechanism POC in the satellite chain includes: calculating the credit cardinality of the node according to a credit evaluation formula, and selecting the node with a certain credit degree to participate in consensus; the credit evaluation formula is:
cr＝m+l
where cr denotes a credit base, m denotes a capability coefficient, and l denotes a liability coefficient.
Preferably, the process of verifying the transaction reliability of the satellite link relay node on the cross-link transaction request includes: step 1: satellite chain relay node SatenodexGenerating public keys PKxAnd a private key SKxGeneral of SatenodexVerifier set and SatenodexConsensus strategy of (1), SatenodexPublic key PKxAnd SatenodexThe signature information is sent to Satellite chain relay node group Satellite in a system transaction modenodeThe other nodes in (1);
step 2: satellite chain relay node Satenode by other nodes in satellite chainxSynchronizing all information, satellite chain relay nodes SatenodexRequest for cross-chain transactionaThe registration is checked, and the checking result is sent to other nodes;
and step 3: when enough verified auditing results are collected, all the auditing results are combined into a final proof;
and 4, step 4: satenode if the final proof meets the expected criteria and is acceptedxThe verifier of (2) further verifies whether the consensus strategy allows other nodes in the satellite chain to enter the SatenodexThe consensus request response of (1);
and 5: if the consensus strategy passes the verification, other nodes send the proof of finality proof to the Satenodex，SatenodexVerifying the proof of finality proof according to the chain information contained in the proof of finality proof;
step 6: if SatenodexThe proof of finality proof passes, then the satellite chain relay node SatenodexRequest for cross-chain transactionaGo through, if the verification does not pass, then Request for cross-chain transaction RequestaAnd (5) interrupting.
Preferably, the satellite chain relay node SatenodexFor consensus calculation in request informationThe line verification comprises the step of verifying the consensus calculation result by adopting a Byzantine fault-tolerant algorithm mechanism.
Preferably, the process of the second cross-chain gateway confirming the received packed transaction request includes: and comparing the data structure information in the transaction request with the verified transaction records in the satellite chain transaction pool, and if the data structure information is consistent with the verified transaction records in the satellite chain transaction pool, confirming the transaction request.
Aiming at the cross-link communication requirement in the block chain, the invention combines a Byzantine fault-tolerant mechanism to realize the confirmation and the packaging of cross-link transaction, thereby ensuring the decentralization and the safety of the transmission information; the satellite chain forms an interconnected but independent sub-chain of a single block chain system, different consensus protocols can be run in parallel, and the satellite chain is used as an independent hub station, so that reliability and expandability can be realized in cross-chain transaction; other affiliated chains have own private classified accounts, so that any non-member node can be effectively prevented from receiving or accessing any transaction information in the classified accounts, and the safety and privacy in cross-chain transaction are improved; the cross-chain communication method has the advantages that the cryptology is utilized to ensure the transaction safety, and each cross-chain circulation of the transaction is recorded in the satellite chain, so that the transaction safety can be ensured no matter whether the target chain is a malicious chain or not.
Drawings
Fig. 1 is a schematic diagram of the overall framework of the cross-chain communication of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
S1, dividing the nodes in the whole block chain network into 3 node groups according to the function types of the nodes, wherein the node groups are Cross link point groups respectivelynodeConsensus node group ConsenssusnodeAnd application node group applicationtionnode. And performing initialization classification on all nodes in the block chain network by using a node fuzzy function classification method, and encoding the nodes in each node group by adopting a real number encoding mode.
S2, block chain BlockchainaApplication node group ApplicationnodeIn which there is a node UaThe node initiates a cross-chain transaction RequestaThe request contains information such as execution function called by cross-chain and is carried out by the BlockchainaThe data in the node request is subjected to homomorphic encryption packaging verification and information confirmation, and meanwhile, the node group Consensus is achievednodeUsing efficient computing power, through high-speed network connections, to node UaInitiated cross-chain transaction RequestaAnd performing consensus computing service.
S3 Cross Link Point group CrossnodeMiddle node combined with external equipment to form cross-chain gateway GateaReceiving Application from a group of blockchain Application nodesnodeNode UaRequest of cross-chain transactionaVerifying the Request by information receipt feedback processingaWhen collecting Application from Application node groupnodeAnd packaging the corresponding transaction signature and the transaction information, and sending the packaged transaction signature and transaction information to a satellite chain relay.
S4, the satellite chain relay receives the cross-chain transaction Request packed by the first cross-chain gatewayaSatellite chain relay node Satenode selected by POC through credit consensus mechanismx，SatenodexFor RequestaPerforming transaction reliability verification, and if the verification is passed, requesting Request of cross-chain transactionaPacking again, if the verification is not passed, the transaction is invalid, and the Request is carried outaSelf-destruction.
S5, the satellite chain relay calls a Byzantine fault-tolerant algorithm mechanism to participate in consensus of the whole satellite chain relay node group, and if the consensus passes verification, the Request passesaWill obtain the node SatenodexGrant, simultaneous RequestaAll information is again protected by SatenodexPackaged and made by SatenodexCross-chain transaction after packagingRequestaSending, if the verification is not passed, the transaction is invalid, and the Request is carried outaSelf-destruction;
s6 Cross Link Point group CrossnodeMiddle node combined with external equipment to form cross-chain gateway GatebReceiving a request from a node SatenodexBlock header and Request ofaInformation by connecting satellite chain relay nodes SatenodexConfirming the transaction, and if the confirmation is correct, then the Request is sentaSubmit to BlockchainbApplication node group ApplicationnodeNode U inb；
S7、UbThe transaction is confirmed, and if the confirmation is passed, the chain link point U is appliedbOn account processing Request ofaRequest information across chains, create corresponding asset credential information, and assets can be at application chain link points UbFlow-through use is carried out, and if the confirmation is not passed, the Request is discardedaA transaction request;
s8, if the cross-chain transaction requests the RequestaIf there is a receipt request, steps S2-S6 are executed in reverse.
The implementation of the POC and the parameters are specifically shown as:
credit evaluation formula: credit base as capability factor + liability factor
Capacity coefficient: block count from history
Responsibility coefficient: calculating according to violation condition and block output correctness
Credit is the honesty coefficient of the account in the system, and the credit of all accounts is in the interval [ -1,1], and is automatically calculated through a credit rating algorithm formula.
And the consensus awards are comprehensively calculated according to the guarantee fund submitted by all the consensus nodes and the consensus node credit. Consensus reward calculation formula:
Figure BDA0003276703810000061
wherein CB is the current consensus award; fee is the handling fee of the newly added block; rnc is the number of nodes in the current round of formula; bti is the block out interval time (seconds); spy is the total time of year (seconds); cmc is the number of consensus entrusted tokens; cr is the credit base.
The calculation formula of voting in the Byzantine fault-tolerant algorithm mechanism in the satellite chain is specifically expressed as follows:
Figure BDA0003276703810000071
wherein, the creditnScoring a credit for node n; creditkScoring a credit for voting node k; votekThe voting condition of the node k is 1, -1 and 0, which respectively represent support, objection and abandon right tickets; γ and μ are values that can be set autonomously, and γ + μ is guaranteed to be 1.
An embodiment of partitioning a node, comprising:
s11, obtaining information of each node in the block chain network, wherein the information comprises verification participation information A stored based on a consensus mechanismnAnd block information Bn；
S12, according to the grading rule, if the block node n is determined to verify the participation information AnAnd block information BnThe corresponding scores are as follows in sequence: sAAnd SBThen the score of the block node n is: pA*SA+PB*SBIn which P isAAnd PBIs a preset value, PA+PB＝1，PA>0 and PB>0；
S13, according to the verification participation information AnAnd block information BnAnd presetting a threshold value in each type of node group, and determining the nodes with the scores larger than the threshold value as the nodes of the corresponding type.
The specific implementation mode of carrying out homomorphic encryption packaging verification on the request data of the node by the block chain comprises the following steps:
s21, BlockchainaCalling an intelligent contract to realize homomorphic encryption to generate a homomorphic secret key, wherein the homomorphic secret key comprises a homomorphic public key PK and a homomorphic private key SK;
s22, sending the homomorphic public key PK generated in the step S21 to the cross-chain gateway GateaSimultaneously cross-chain gateway GateaGenerating corresponding Symmetric key symmetry based on random functionkeyAnd by the acquired PK to symmetrykeyEncrypting, cross-chain gateway GatebProcessing a cross-chain transaction RequestaInformation and encrypted Symmetric key symmetrykey' Return to Block chain Blockchaina。
The specific implementation mode of processing and verifying the cross-chain transaction request by adopting the information receipt feedback comprises the following steps:
s31, receiving a block chain Blockchain from the block chainaUpper node UaRequest of cross-chain transactionaGateway Gate across chainaApplication node group Application requiring monitoringnodeEvent throw-out, if a loss occurs, it is necessary to forward the ApplicationnodeObtaining loss event, cross-chain gateway GateaWhen a specific application chain is connected, not only is the transaction monitored in real time, but also the orderliness of cross-chain transaction is ensured;
s32, using GRPC communication mode to cross-chain gateway GateaThe Client is realized, the Server is realized on the satellite link relay, and the cross-link transaction Request is realized through short connectionaPacking and sending to a satellite chain relay;
s33, cross-chain gateway GateaConstantly synchronizing satellite chain relay nodes Satenode as light nodes of satellite chain relay node groupxThe block of (1). Cross-chain gateway GateaOnly block message subscription needs to be initiated to the satellite chain relay at start-up, so that the relay chain can wait to flow to Cross through the satellite chain link connectionnodeSending a cross-chain transaction Requesta；
S34, addressing the next jump through DHT, wherein the address of the next jump is controlled by cross-chain gateway GateaIs determined by the distributed routing table in (1). The distributed routing table records the cross-chain gateway GateaAn application node group ID set on the governed satellite link relay;
s35, cross-chain gateway GateaWhen the destination chain contract is called, if failure occurs, the attempt is continuously made in a final consistency mode until success is achieved.
The specific implementation method for verifying the transaction reliability of the cross-link transaction request by the satellite link relay node comprises the following steps of:
s41 and satellite chain relay node SatenodexGenerating public keys PKxAnd a private key SKxGeneral of SatenodexVerifier set and SatenodexConsensus strategy of (1), SatenodexPublic key PKxAnd SatenodexThe signature information is sent to Satellite chain relay node group Satellite in a system transaction modenodeThe other nodes in (1);
s42 relay node Satenode from satellite chain by other nodes in satellite chainxSynchronizing all information, satellite chain relay nodes SatenodexRequest for cross-chain transactionaThe result is checked by SatenodexSending the data to other nodes in the satellite chain in a system transaction mode;
s43, once other nodes are from SatenodexSufficient verified information is collected and other nodes in the satellite chain combine to generate a final proof, which represents an aggregate approval of other nodes in the satellite chain, proof of the cross-chain transaction RequestaThe method is really available and reasonable, and can be used for executing the next operation in a satellite chain;
s44, Satenode if proof of final proof of proof meets set expectation criteria and is acceptedxThe verifier of (2) will further verify whether the consensus strategy allows other nodes in the satellite chain to enter the SatenodexThe consensus request response.
The set expected standard is all nodes participating in verification and audit, and the results are combined into a final proof, namely, the node combination rate is equal to the actual node participation rate.
S45, if the consensus strategy passes the verification, other nodes send the proof of final proof to Satenodex，SatenodexBased on the chain information it contains, e.g. verification list, underlying coherency protocolEtc., verifying the proof of finality proof;
s46, Satenode ifxThe proof of finality proof passes, then the satellite chain relay node SatenodexRequest for cross-chain transactionaGo through, if the verification does not pass, then Request for cross-chain transaction RequestaInterrupting and self-destroying.
The above-mentioned embodiments, which further illustrate the objects, technical solutions and advantages of the present invention, should be understood that the above-mentioned embodiments are only preferred embodiments of the present invention, and should not be construed as limiting the present invention, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (10)

1. A cross-link communication method based on satellite link relay is characterized by comprising the following steps:
s1: acquiring all nodes in a block chain network, and dividing all the nodes into a cross-link node group, a common node group and an application node group;
s2: applying nodes U in a node groupaInitiating a cross-chain transaction Requesta(ii) a The block chain performs homomorphic encryption packaging on the request data of the node to determine encrypted data information; consensus node group to node UaCarrying out consensus computing service on the initiated cross-chain transaction request;
s3: the first cross-link gateway receives cross-link transaction request information, verifies the cross-link transaction request through information receipt feedback, packages the received transaction signature and transaction information, and sends the transaction signature and the transaction information to a satellite link relay;
s4: satellite chain relay node selection satellite chain relay node Satenodex(ii) a After receiving the cross-link transaction request packaged by the first cross-link gateway, the satellite link relay node verifies the transaction reliability of the cross-link transaction request, packages the cross-link transaction request if the verification is passed, and invalidates the transaction if the verification is not passed;
s5: satellite chain relay node SatenodexVerifying the consensus calculation result in the request information, if the consensus calculation result passes the verification, obtaining the permission of the satellite link relay node for the cross-link transaction request, packaging all information of the cross-link transaction request, and sending the packaged information to a second cross-link gateway, and if the consensus calculation result does not pass the verification, the transaction is invalid;
s6: the second cross-link gateway confirms the received packed transaction request and sends the confirmed transaction request to other application nodes U of the application node groupb；
S7：UbThe transaction request is confirmed by adopting a chain independent consensus mechanism, and if the confirmation is passed, the transaction request is confirmed at an application chain link point UbOn account of (2) processing a cross-chain Request information RequestaCreating corresponding asset credential information to enable the asset to be at the application link point UbIf the confirmation is not passed, the Request is discardedaAnd (6) transaction request.
2. The method of claim 1, wherein the dividing the nodes comprises: acquiring all node data, converting the node data into histogram gray distribution data, and selecting partial distribution with a quantile value of 90% by adopting a one-dimensional histogram thresholding method; grading the partial distribution values of the nodes by adopting a grading rule; setting classification node threshold S1And S2In which S is1＞S2(ii) a When the node data score satisfies S ≧ S1When the node is a common node group; when the node data score satisfies S1≥S≥S2Then, the node is a cross-link node group; when the node data score satisfies S2And when the node is more than or equal to S, the node is an application node group.
3. The method according to claim 2, wherein the set scoring rule is as follows: if the node n of the block is determined to verify the participation information AnWhether to participate in the consensus verification weight SABlock information BnWhether the result obtained by the corresponding participation consensus verification is correct or not is the weight SBThen the score of the block node n is: s ═ PA*SA+PB*SBIn which P isAAnd PBIs a preset value, PA+PB＝1，PA> 0 and PB＞0。
4. The method of claim 1, wherein the block chain homomorphic encryption encapsulation of the request data of the node comprises:
step 1: generating a homomorphic secret key by the block chain, wherein the secret key comprises a homomorphic public key PK and a homomorphic private key SK;
step 2: sending the homomorphic public key PK to a first cross-chain gateway, and randomly generating a corresponding Symmetric key Symmetric by the first cross-chain gatewaykey(ii) a Encrypting the symmetric key by adopting a homomorphic public key PK;
and step 3: the first cross-link gateway returns the encrypted symmetric key to the blockchain.
5. The method of claim 1, wherein the process of verifying the request for a cross-chain transaction through information receipt feedback comprises:
s31: first cross-link gateway real-time monitoring Application node group ApplicationnodeIf the event is lost, directly acquiring the lost event from the application node group;
s32: a Client is realized on the first cross-link gateway, and a Server is realized on the satellite link relay; the client and the server transmit data in a GRPC communication mode, and package and send the cross-link transaction request to the satellite link relay through short connection;
s33: satellite chain relay node Satenode continuously synchronized by first cross-chain gatewayxThe block initiates block message subscription to a satellite chain relay, and waits for a relay chain to send a cross-chain transaction request to a cross-chain node group through a satellite chain length connection flow;
s34: addressing a next hop through the DHT, wherein the address of the next hop is determined by a distributed routing table in the first cross-link gateway, and the distributed routing table records a node group ID set on a satellite link relay governed by the first cross-link gateway;
s35: and the first cross-link gateway calls the destination link contract, if the first cross-link gateway fails, the request is terminated, otherwise, the cross-link transaction request is successfully verified.
6. The method of claim 1, wherein the satellite chain relay selects a satellite chain relay node SatenodexThe method comprises the step of selecting the satellite chain relay node by the POC (push to talk over cellular) by adopting a credit consensus mechanism.
7. The method according to claim 6, wherein the credit consensus mechanism POC in the satellite chain comprises: calculating the credit cardinality of the node according to a credit evaluation formula, and selecting the node with a certain credit degree to participate in consensus; the credit evaluation formula is:
cr＝m+l
where cr denotes a credit base, m denotes a capability coefficient, and l denotes a liability coefficient.
8. The method of claim 1, wherein the process of verifying the transaction reliability of the satellite link relay node for the cross-link transaction request comprises:
step 1: satellite chain relay node SatenodexGenerating public keys PKxAnd a private key SKxGeneral of SatenodexVerifier set and SatenodexConsensus strategy of (1), SatenodexPublic key PKxAnd SatenodexThe signature information is sent to Satellite chain relay node group Satellite in a system transaction modenodeThe other nodes in (1);
step 2: satellite chain relay node Satenode by other nodes in satellite chainxSynchronizing all information, satellite chain relay nodes SatenodexRequest for cross-chain transactionaIs registered intoAuditing is carried out, and an auditing result is sent to other nodes;
and step 3: when enough verified auditing results are collected, all the auditing results are combined into a final proof;
and 4, step 4: satenode if the final proof meets the set-up expectations and is acceptedxThe verifier of (2) further verifies whether the consensus strategy allows other nodes in the satellite chain to enter the SatenodexThe consensus request response of (1);
and 5: if the consensus strategy passes the verification, other nodes send the proof of finality proof to the Satenodex，SatenodexVerifying the proof of finality proof according to the chain information contained in the proof of finality proof;
step 6: if SatenodexThe proof of finality proof passes, then the satellite chain relay node SatenodexRequest for cross-chain transactionaGo through, if the verification does not pass, then Request for cross-chain transaction RequestaAnd (5) interrupting.
9. The method of claim 1, wherein a satellite link relay node (Satenode) is used for the inter-link communication based on the satellite link relayxThe verification of the consensus calculation result in the request information comprises the verification of the consensus calculation result by adopting a Byzantine fault-tolerant algorithm mechanism.
10. The method of claim 1, wherein the second inter-link gateway validating the received packed transaction request comprises: and comparing the data structure information in the transaction request with the verified transaction records in the satellite chain transaction pool, and if the data structure information is consistent with the verified transaction records in the satellite chain transaction pool, confirming the transaction request.
CN202111119894.2A 2021-09-24 2021-09-24 Cross-link communication method based on satellite link relay Active CN113839768B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111119894.2A CN113839768B (en) 2021-09-24 2021-09-24 Cross-link communication method based on satellite link relay

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111119894.2A CN113839768B (en) 2021-09-24 2021-09-24 Cross-link communication method based on satellite link relay

Publications (2)

Publication Number Publication Date
CN113839768A true CN113839768A (en) 2021-12-24
CN113839768B CN113839768B (en) 2023-09-08

Family

ID=78969682

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111119894.2A Active CN113839768B (en) 2021-09-24 2021-09-24 Cross-link communication method based on satellite link relay

Country Status (1)

Country Link
CN (1) CN113839768B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114760288A (en) * 2022-03-18 2022-07-15 国网四川省电力公司天府新区供电公司 Block chain-based file cross-chain transmission method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110892696A (en) * 2019-04-19 2020-03-17 阿里巴巴集团控股有限公司 Method and apparatus for establishing communication between blockchain networks
CN112073222A (en) * 2020-08-18 2020-12-11 西北工业大学 Air-ground network mobile management architecture based on block chain cross-chain technology
CN113098694A (en) * 2021-04-09 2021-07-09 杭州链网科技有限公司 Hybrid cross-chain consensus method
US20210232571A1 (en) * 2020-01-06 2021-07-29 Tata Consultancy Services Limited Method and system for processing transactions in a blockchain network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110892696A (en) * 2019-04-19 2020-03-17 阿里巴巴集团控股有限公司 Method and apparatus for establishing communication between blockchain networks
US20210232571A1 (en) * 2020-01-06 2021-07-29 Tata Consultancy Services Limited Method and system for processing transactions in a blockchain network
CN112073222A (en) * 2020-08-18 2020-12-11 西北工业大学 Air-ground network mobile management architecture based on block chain cross-chain technology
CN113098694A (en) * 2021-04-09 2021-07-09 杭州链网科技有限公司 Hybrid cross-chain consensus method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
XINTONG LING: "Satellite-Aided Consensus Protocol for Scalable Blockchain", 《MDPI》 *
赵 涛: "基于聚类簇中心的共识跨链交换模型", 《计算机科学》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114760288A (en) * 2022-03-18 2022-07-15 国网四川省电力公司天府新区供电公司 Block chain-based file cross-chain transmission method
CN114760288B (en) * 2022-03-18 2024-02-06 国网四川省电力公司天府新区供电公司 File cross-chain transmission method based on block chain

Also Published As

Publication number Publication date
CN113839768B (en) 2023-09-08

Similar Documents

Publication Publication Date Title
CN109871669B (en) Data sharing solution based on block chain technology
Jesus et al. A survey of how to use blockchain to secure internet of things and the stalker attack
Zheng et al. An overview of blockchain technology: Architecture, consensus, and future trends
Wang et al. Blockchain router: A cross-chain communication protocol
CN111046352B (en) Identity information security authorization system and method based on block chain
CN112418860A (en) Block chain efficient management framework based on cross-chain technology and working method
WO2018197491A1 (en) Method and system for settling a blockchain transaction
CN113746858B (en) Cross-chain communication method based on verifiable random function
CN109245894B (en) Distributed cloud storage system based on intelligent contracts
CN110417790A (en) Block chain system of real name queuing system and method
CN113328997A (en) Alliance chain cross-chain system and method
US20200169416A1 (en) Consensus protocol for permissioned ledgers
CN116527684B (en) Multi-chain information interaction method based on 1+1+N relay consensus committee
Le et al. A lightweight block validation method for resource-constrained iot devices in blockchain-based applications
Robinson Consensus for crosschain communications
Robinson et al. Anonymous state pinning for private blockchains
Hatefi et al. A conditional privacy-preserving fair electronic payment scheme based on blockchain without trusted third party
Liu et al. Fail-safe watchtowers and short-lived assertions for payment channels
Oh et al. Algorithm based on Byzantine agreement among decentralized agents (BADA)
CN113839768B (en) Cross-link communication method based on satellite link relay
Liu et al. A blockchain-based cross-domain authentication management system for IoT devices
Chen et al. IOV Privacy Protection System Based on Double‐Layered Chains
CN117375797A (en) Anonymous authentication and vehicle-mounted information sharing method based on blockchain and zero knowledge proof
Sui et al. AuxChannel: Enabling efficient bi-directional channel for scriptless blockchains
Gojka et al. Security in distributed ledger technology: An analysis of vulnerabilities and attack vectors

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