CN113407977B - Cross-chain extension method and system based on aggregated signature - Google Patents
Cross-chain extension method and system based on aggregated signature Download PDFInfo
- Publication number
- CN113407977B CN113407977B CN202110826497.2A CN202110826497A CN113407977B CN 113407977 B CN113407977 B CN 113407977B CN 202110826497 A CN202110826497 A CN 202110826497A CN 113407977 B CN113407977 B CN 113407977B
- Authority
- CN
- China
- Prior art keywords
- chain
- cross
- signature
- aggregation
- user client
- 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
- 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/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Medical Informatics (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses a cross-chain expansion method based on aggregated signatures, which adopts an aggregated public key and the aggregated signatures to execute cross-chain and increases user signature weight to realize autonomous controllable decentralized cross-chain expansion, and comprises the following steps: generating an aggregation public key by using public keys of a user client and a plurality of hosting nodes, deriving an aggregation hosting address by using the aggregation public key, transferring a first block chain digital asset into the aggregation hosting address by using the user client, and casting a corresponding mapping asset in an account wallet of a second block chain, wherein the hosting node is selected from verification nodes of the second block chain, and the mapping asset circulates in the second block chain and is converted with the first block chain digital asset according to a fixed ratio; responding to a cross-chain requirement that a user client selects a signature weight to trigger adaptation, carrying out consensus verification on the second blockchain by the verification node, and executing corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is arranged in the first blockchain.
Description
Technical Field
The invention belongs to the technical field of block chains and cross-chain, and particularly relates to a cross-chain extension method and system based on aggregated signatures.
Background
The blockchain as a distributed account book technology can be applied to a plurality of fields, but is limited by factors such as throughput, network isolation, supervision, flexibility and the like, and various blockchain cross-link projects are rapidly developed at present. The light node is combined with the multi-label hosting cross-chain, and the current main flow ground cross-chain mode is adopted.
The concept of multiple digital signatures was first published by Okamoto and Takura et al and a specific algorithm scheme was devised, and multiple signatures can distribute the rights of an account over multiple keys, preventing the loss of a key from causing the entire account to run away. An asset operation transaction for an account requires a plurality of relatively independent private keys to sign a message in the clear, and the transaction is validated when the number of signatures is sufficient. Because the direct support of multiple signature algorithms in the account embodiment of the blockchain system requires the change of the architecture design of the whole blockchain, the specific implementation of the method is mostly used in an intelligent contract, and the signatures and the required signature quantity threshold values are specified in advance. The security of the multiple signature method depends on the design and implementation of the smart contract and is not flexible because the smart contract is difficult to change once deployed. The multiple signature method can exert the safety under a certain scene, but the lower flexibility is difficult to be widely used.
In the cross-chain consensus process, all nodes generally need to sign the whole block and store related data, such as block data, node public keys, and signature data, in the block. As application usage increases, signature-related stored data may continue to grow. Different from the traditional application, the data on the chain is only increased but not reduced theoretically, and the mass data brought by the mass signature is a huge burden on data storage, network transmission and signature verification. How is the specific technology implemented to perform aggregate compression on digital signature data on the premise of ensuring that massive signature data can be verified?
Most federation chain consensus currently employs the ECDSA signature algorithm. For the block data, each node generates an independent digital signature by using a private key of the node and broadcasts the signature to other nodes. The other nodes verify the signature and write it to the next block of data. By using the method, when the number of the common identification nodes is large, the signature data stored in each round of the common identification blocks is increased continuously, and the storage space is occupied. The large amount of signature data poses a significant challenge to network bandwidth whenever a new node joins the network, requiring synchronization of the history blocks.
Compared with the method for directly storing a plurality of independent signatures, after the aggregated signature technology is used, each node collects aggregated signature fragments broadcasted by other nodes, and then the signature fragments are aggregated and stored. The public key signatures or the private key signatures are aggregated into a new public key or a new signature which can contain complicated exchange conditions and fund use details, and all the contents are provided to the outside for use as a new fund use condition (a new aggregated signature lock). Therefore, the data volume transmitted and stored on the block chain is reduced, more deals contained in a single block are made, the cost is reduced, and the capacity expansion effect is achieved. And when a new node is added, the synchronous history block only needs to download the aggregated signature data, so that the occupation of network bandwidth is greatly reduced.
Meanwhile, in the cross-chain execution controlled by a plurality of trustees, the problem of trusteeization still exists, the cross-chain control right is mastered in a small number of trustees, a cross-chain user cannot independently and effectively control own cross-chain assets, multiple times of signature confirmation are carried out outside a chain, the whole script needs to be disclosed, if the conditions are complex, the data size is large, the execution is expensive, the efficiency is not high, in addition, the method is not beneficial to privacy, and the script can disclose the information of all the participants.
Therefore, a method for ensuring the autonomous controllability and the chain-crossing privacy security of the user on the basis of increasing the chain-crossing performance is needed, so as to further improve the chain-crossing technology.
Disclosure of Invention
In view of the above, the present invention provides a cross-chain expansion method based on aggregated signatures, which is used for performing aggregated compression on signature data on the basis of multi-signature cross-chain execution, and ensuring user autonomous controllability and privacy security, and increasing the decentralized degree of cross-chain.
A cross-chain expansion method based on aggregated signatures adopts an aggregated public key and an aggregated signature to execute cross-chain, increases user signature weight, and realizes autonomous and controllable decentralized cross-chain expansion, which specifically comprises the following steps:
generating an aggregation public key by using public keys of a user client and a plurality of hosting nodes, deriving an aggregation hosting address by using the aggregation public key, transferring the first block chain digital asset to the aggregation hosting address by the user client, and casting a corresponding mapping asset in an account wallet of a second block chain; wherein the escrow node is selected from the verification nodes of the second blockchain; and completing the chain crossing of the mapping of the first blockchain digital asset in the second blockchain. The mapping assets are circulated in the second blockchain and are converted with the first blockchain digital assets according to a fixed ratio;
in the traditional multi-sign cross chain, each hosting node comprises an independent cross chain asset hosting address, cross chain assets are stored in a plurality of hosting person addresses, an aggregation public key is generated and an aggregation hosting address is derived, the cross chain assets are only required to be stored in the aggregation hosting address at one time, the data storage amount is reduced, and the hosting efficiency is improved;
the escrow node is obtained from the verification node through mortgage asset selection, namely the escrow node is the verification node, the safety of the escrow node is improved, the on-chain independent signature is realized, and the off-chain multi-signature verification is changed. Under this mental logic, the more the managed nodes are close to infinity, the more decentralized the managed nodes are, and the final decision of the cross-chain account is in the hands of the user.
Responding to a cross-chain requirement that a user client selects a signature weight to trigger adaptation, carrying out consensus verification on the second blockchain by the verification node, and executing corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is arranged in the first blockchain.
Here, let the user's weight move smoothly between weights between 0 and 1/3 to accommodate different cross-chain scenarios, where there are two extremes:
for example, user a goes to the cross-chain, and there is no user a in all N hosting nodes, and when N approaches infinity, the whole cross-chain system is decentralized and secure, increasing the scalability, because the digital assets of the first blockchain that cross to the second blockchain can be operated without limitation, and are hosted by a fixed group of hosting nodes, and how user a goes to operate on the second blockchain has no relation.
At the other extreme, a user goes across the chain, a participates in the hosting node and takes 1/3 weight, and due to POW consensus, when the cross-chain asset can be transferred with signature more than 2/3, in this case, the account control right of a is basically in hand of a. A cannot be moved to a cross-chaining asset at will because A is moved, but control over the cross-chaining asset network is still in A.
This 1/3 privilege is well suited to this scenario if A wants absolute security if he wants to transfer only the digital assets of the first blockchain to the second blockchain to earn bonus, rather than trade. The authority of a has corresponding application scenarios between the two extremes, i.e. over the interval 0, 1/3.
That is, in the cross-chain system, a plurality of authority choices between 0 and 1/3 are provided for the user, and specifically, how to choose, the user needs to see the corresponding scene chosen by the user on the second blockchain.
Although the participating user can select the signature weight autonomously, the user cannot do harm, for example, the user possesses 1/3 private key signature authority, and then the user cannot do any transfer when crossing to the cross-chain asset on the second blockchain, because the weight of the user is too large, the total weight of other signature nodes on the second blockchain is less than 2/3, in the system, the cross-chain asset transfer is converted into the transfer of the second blockchain internal mapping asset, here, the user cannot participate in the signature, only the signature nodes in the second blockchain perform signature consensus, and because the total weight of other signature nodes is less than 2/3 at this time, the internal transfer consensus of the mapping asset cannot be completed in the second blockchain, and further the transfer of the cross-chain asset cannot be completed.
Therefore, when the user selects the signature authority, the user can select the signature authority according to the past and later use of the cross-chain,
if the selection is wrong, the function he says cannot be done, for example, the user selects the weight mode of 1/3, but the user wants to perform cross-chain transfer on the second blockchain, and at this time, the user intelligently selects a weight less than 1/3 or a weight of 0 to perform cross-chain transfer.
Further, still include:
the first blockchain and the second blockchain verify the authenticity of the cross-chain transaction information through deploying the light nodes of the opposite side, and the cross-chain message communication of the first blockchain and the second blockchain is transferred through the relay program.
The light node only needs to store the Block Header, but does not store the information such as the entire transaction list. Judging whether a transaction is in a current block chain transaction list or not through Merkle certification, adopting multi-chain light node verification logic, and verifying the true existence of the transaction through Merkle certification under the condition that each chain asset block head exists;
for example, a light node of a second blockchain is deployed in a first blockchain, the second blockchain block header information is recorded in real time, cross-chain information which is generated in the second blockchain by a user client and is related to the first blockchain is obtained, and the authenticity of the cross-chain information is verified in the first blockchain in time. And the relay program is set as cross-link switching of the first block chain and the second block chain, and is used for cross-link communication for connecting the first block chain and the second block chain.
Further, an aggregation public key is generated by using the user client and the public keys of the plurality of managed nodes, and an aggregation managed address is derived from the aggregation public key, which specifically includes the following steps:
setting a relay program associated with the first block chain in the second block chain, selecting a plurality of managed nodes from the second verification nodes in the relay program, and distributing random keys for the managed nodes;
and generating signature public keys for the user client and all the escrow nodes in sequence by utilizing the uniform ellipse base point, collecting all the signature public keys to generate an aggregation public key, and performing hash calculation on the aggregation public key to derive an aggregation escrow address.
Here, the user client and the escrow node each have a respective random key for generating an aggregated public key and participating in an aggregated signature. The cross-chain assets (first blockchain digital assets) are stored in the aggregation hosting address, the cross-chain assets are prevented from being stored in a plurality of independent hosting addresses, and cross-chain users participate in the aggregation hosting address, so that the handling control strength of the hosting node is reduced, and the risk is reduced.
Further, the signature weight threshold for the user client to select is set in the first blockchain, specifically as follows:
setting a signature weight of a user client for crossing a first blockchain digital asset to a second blockchain user participating in multiple signatures in a first block, wherein the weight threshold range is [0, 1/3 ];
according to the cross-chain requirements of cross-chain withdrawal and cross-chain transfer proposed by a user cross-chain service application scene, aiming at the cross-chain withdrawal and cross-chain transfer, a user client side sequentially adapts and selects a signature weight meeting corresponding cross-chain POW consensus verification within a signature weight threshold range.
Specifically, the cross-link promotion implementation flow is as follows:
responding to a cross-link cash-up request of the user client on the second block chain, establishing a cash-up transaction by the hosting node, sending the cash-up transaction to the relay program, and initiating a multi-signature transaction of cross-link cash-up; the cash-out transaction at least comprises a digital asset cash-out quantity and a user account, and the validity of the cash-out transaction is confirmed through a light node scheme in a first block chain;
after the validity is confirmed, the user client selects a signature weight, a signature aggregation mechanism is started, the joint escrow node sequentially carries out multiple signatures on the cross-link cash-withdrawal information by using respective private keys, the generated multiple signatures are aggregated to generate an aggregated signature, and the user client participating in the signature and the escrow node public key are aggregated to form a public key list;
verifying the aggregated signature by the verification node in the second blockchain according to the public key list and the cross-chain message, and counting accumulated signature shares of the user client and the escrow node, wherein after the accumulated signature shares exceed 2/3 of the total number, POW consensus is executed;
validating the cash-out transaction through the light node scheme in the first blockchain, transferring the cross-chain assets from the escrow address to the user account, and destroying the mapped assets on the second blockchain.
The transfer of the cross-chain asset out of the aggregated escrow address requires initiation of multiple signature transactions that need to be performed to a specified consensus threshold, typically set to 2/3 of total occupancy. In the form of aggregated signatures, the user and the escrow node can together initiate a multiple signature transaction, where if the user's signature accounts for 1/3 of the total weight, the other escrow signature weights are close to 2/3. In this setting, the premise of the transfer completed by the hosted cross-chain assets is that the user signs the transaction, the total weight of other hosting nodes is less than 2/3, and even if all passes, multiple signature transactions cannot be completed. Therefore, when the user participates in the aggregated signature, the user can effectively control the managed assets, and the trusted centralized management in the conventional scheme is reduced.
By adopting the scheme of aggregating the public key and the signature, the byte number of the transaction script can be effectively compressed, so that the transaction commission fee is obviously reduced, the maximum number of managed nodes is not limited, and the decentralized degree of the cross-chain is continuously improved along with the increase of the number N of the managed nodes.
In particular, the cross-chain transfer implementation flow is as follows:
responding to a user client side cross-chain transfer request, establishing a transfer transaction by a hosting node and sending the transfer transaction to a relay program, wherein the transfer transaction at least comprises a digital asset transfer quantity, an aggregation hosting address, a user client side mapping asset wallet address, a target client side mapping asset wallet address, and confirming the validity of the transfer transaction through a light node scheme in a first block chain;
after the validity is confirmed, the hosting node in the relay program inquires whether the balance of the digital assets in the aggregation hosting address reaches the transfer amount;
when the transfer sum is not reached, the associated user client stores the cross-chain digital assets containing the transfer quantity to the aggregation hosting address, and casts the corresponding mapping assets in the bound mapping asset wallet;
if yes, the user client selects the signature weight, and initiates a corresponding mapping asset transfer transaction in the second block chain, wherein the transaction information comprises the mapping asset transfer quantity, the mapping asset wallet address of the user client and the mapping asset wallet address of the target client;
the second blockchain verification node performs consensus verification on the mapping asset transfer transaction, and mapping assets required by the mapping asset wallet address transfer from the user client to the target client mapping asset wallet address after the verification is passed;
and simultaneously destroying a corresponding number of cross-chain assets in the aggregation managed address of the user client.
The cross-chain withdrawal process needs to carry out multiple signatures to ensure mutual transfer of cross-chain assets between the aggregation hosting address and the user client account address, and the cross-chain transfer is to convert the cross-chain assets into corresponding mapping assets of the second blockchain, so that the transfer of the mapping assets is carried out in the second blockchain, and the cross-chain multi-signature hosting verification is not needed.
In particular, the signature aggregation mechanism specifically comprises the following steps:
selecting a uniform elliptic curve base point to sequentially calculate a signature public key for a random private key of a signer; the participatory signers comprise user clients and managed nodes;
performing hash operation on all signature public keys after being collected to generate a public key list;
each participator selects a random number, the derivative random numbers of the random numbers are calculated by using the elliptic curve base points, and the derivative random numbers are summed to generate an aggregation random number;
further carrying out Hash operation on the public key list and the signature public key to obtain an aggregation public key;
the participator signs the cash withdrawal transaction by using a random number, an aggregation public key, an aggregation random number and a participator random private key, and generates an aggregation signature with the aggregation random number after summing all signatures;
and when the cash withdrawal transaction is executed, the verification node verifies the aggregated signature by using an elliptic curve algorithm according to the cash withdrawal transaction information and the public key list.
Here, a signature aggregation mechanism is deployed in the relay program, and associates a first blockchain and a second blockchain to compress and combine multiple signature data into a single aggregated signature. And the verifier verifies the single aggregated signature through a list consisting of the data related to all the signatures and the public key, and if the verification passes, the effect of the verifier is equal to that of independently verifying all the related signatures and totally passing the verification.
Further, the method is characterized by also comprising the step of encrypting and storing the signature script by adopting a MAST structure, which specifically comprises the following steps:
in the process of executing cross-chain cash withdrawal and cross-chain transfer signature, the signature scripts generated by the user client and the hosting node are subjected to hash processing, corresponding hash values are generated and stored in the MAST tree, the hash values recur upwards layer by layer, and finally a hash value is generated and stored in the top Mercker root.
The trace of the bitcoin script can be hidden, when cross-chain transaction is verified, all script information does not need to be exposed, only data on a Merck root and a Merck path reaching a certain using condition need to be provided, and other information is still in a hash ciphertext state. These complex functions appear as one transaction in which the signature script can be hidden and the user can only see these peer-to-peer transactions. Thus, the MAST script structure not only improves expandability and privacy through hiding scripts and fuzzy keys, but also increases data processing efficiency.
An aggregation signature-based cross-chain extension system comprises an aggregation casting module and a verification execution module;
the aggregation casting module generates an aggregation public key by using public keys of a user client and a plurality of hosting nodes, derives an aggregation hosting address from the aggregation public key, transfers a first block chain digital asset to the aggregation hosting address through the user client, and casts a corresponding mapping asset in an account wallet of a second block chain, wherein the hosting node is selected from verification nodes of the second block chain, and the mapping asset circulates in the second block chain and is converted with the first block chain digital asset according to a fixed ratio;
and the verification execution module responds to a cross-chain requirement that the user client selects the signature weight to trigger adaptation, the verification node performs consensus verification on the second block chain and executes corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is arranged in the first block chain.
As an embodiment, the polymeric casting module is configured to:
setting a signature weight of a user client for crossing a first blockchain digital asset to a second blockchain user participating in multiple signatures in a first block, wherein the weight threshold range is [0, 1/3 ];
and according to a cross-chain requirement of cross-chain withdrawal and cross-chain transfer proposed by a user cross-chain service application scene, and aiming at the cross-chain withdrawal and cross-chain transfer, a user client side sequentially adapts and selects a signature weight meeting corresponding cross-chain POW consensus verification within a signature weight threshold range.
The invention designs a cross-chain extension method based on a polymerization signature, which has the following advantages:
(1) compressing multi-signature cross-chain storage data by using an aggregation signature mechanism, and expanding cross-chain operation performance;
(2) the trusteeship node is from the verification node, so that the chain down trusteeship is avoided, the chain up-independent signature is realized, and the chain out-of-chain multi-signature verification is changed;
(3) increasing user signature weight, increasing the controllable degree of a user to managed assets, increasing the number of managed nodes infinitely and increasing the decentralized degree;
(4) setting a user signature weight threshold, wherein the user signature weight is independently selectable and flexibly adapts to a cross-chain application scene;
(5) the signature script is encrypted using the Merkel Abstract Syntax Tree (MAST) to further extend the privacy protection of cross-chain execution.
Drawings
FIG. 1 is a cross-chain architecture of the present invention;
FIG. 2 is a process flow diagram of the hosting cross-chaining of the present invention;
FIG. 3 is a diagram illustrating user-selected signature weights participating in an aggregated signature;
FIG. 4 is a diagram illustrating a MAST structure for storing a signature script in an encrypted manner;
FIG. 5 is a flow chart of the light node verification of the present invention;
FIG. 6 is a schematic diagram providing the Mercker tree demonstration.
Detailed Description
In order to more specifically describe the present invention, the following detailed description is provided for the technical solution of the present invention with reference to the accompanying drawings and the specific embodiments.
Example 1:
the invention provides a cross-chain expansion method based on a polymerization signature, which adopts a polymerization public key and the polymerization signature to execute cross-chain and increases the user signature weight to realize autonomous and controllable decentralized cross-chain expansion.
In this embodiment, set chain a as the first blockchain, chain B as the second blockchain, digital asset M on chain a can cross-chain to chain B, and mapped asset corresponding to M in chain B is XM, and its mapping ratio is 1: 1;
a plurality of verification nodes exist on the chain B for commonly verifying the transactions on the chain, and the verification nodes can be escrow nodes associated with A and B by mortgaging the digital assets to which the verification nodes belong according to a mortgage rule, wherein each escrow node is distributed with a random key and an asset escrow address which are independent for multiple tags; meanwhile, a light node of the chain B is deployed in the chain a to acquire related cross-chain information in the chain B, a relay program is set on the chain B to associate with the chain a, and an aggregation signature mechanism is deployed to manage the managed node and forward a cross-chain message of the chain B to the chain a, wherein a cross-chain architecture is shown in fig. 1.
1. The user client cross-links the digital assets M of the chain a of the user a to the chain B, as shown in fig. 2, specifically including the following steps:
(1) first, generating an aggregated managed address:
electing a plurality of fixed hosting nodes (1 … i … n) n from the verification nodes of chain B>2 and assigns a random key skiThe user client provides the key sk of the cross-chain user aaSelecting a uniform elliptic curve base point G to sequentially calculate a signature public key PK for a random key of a managed node and a key of a user ai＝ski·G,PKa＝ska·G；
Computing public key list L hash (PK)1…PKi,PKa…PKn)；
Further carrying out Hash operation on the public key list and the signature public key to obtain an aggregation public key:
P＝hash(L,PK1)·PK1+…hash(L,PKi)·PKi+hash(L,PKa)·PKa+…+hash(L,PKn)·PKn)；
the aggregated escrow address D is further derived from the aggregated public key P: hash (P, r), r is a random number.
(2) Hosting the cross-chain asset M and generating the mapping asset XM:
transferring the cross-chain asset M from the account address of user a's chain A to the aggregated hosted address D at the user client, while casting a corresponding percentage of the mapped asset XM in chain B's account wallet, completes the cross-chain of user a's chain A's digital asset M to B chain.
At this time, the user a participates in the generation of the aggregation public key and the aggregation hosting address, the weight of the user a is 1/(1+ n), when the hosting nodes are 50, the weight of the user a is 1/51, and under the weight, the user a can realize the cross-chain withdrawal and transfer of the chain a digital asset to the chain B and the cross-chain withdrawal and transfer of the chain a digital asset.
2. User a brings up cross-chain asset M from chain B:
setting a user a selectable signature weight threshold [0, 1/3] in the chain A, enabling the user a to select a signature weight to adapt to the cross-chain requirement, responding to the cross-chain requirement, enabling the verification node to perform consensus verification in the chain B, and executing corresponding cross-chain transaction. The threshold for verifying that the nodes normally agree is 2/3, that is, when a transaction occurs, at least 2/3 nodes can execute the transaction after agreeing.
In this embodiment, the user a selects 1/3 signature weight to perform cross-link rendering operation of the asset M, and fig. 3 is a schematic diagram illustrating the user selects signature weight to participate in the aggregate signature.
The specific flow of the cross-chain cash-up operation is as follows:
in response to a cross-chain cash-out request on chain B from user a on the user client, the hosting node builds a cash-out transaction TMAnd sending the signature to a relay program, and initiating a multi-signature transaction of cross-link cash withdrawal; the cash-out transaction at least comprises the cash-out quantity of the digital assets M and a user account address d;
the user a selects 1/3 signature weight, starts a signature aggregation mechanism, and the joint escrow node sequentially carries out multiple signatures on the cross-link cash-up information by using respective private keys, and aggregates the generated multiple signatures to generate an aggregated signature:
each hosting node and user a select a random number ki/kaCalculating the random number R derived from the random number using the base point G of the elliptic curve as described abovei/RaSumming all the derived random numbers yields an aggregate random number R ═ (R)1+…+Ri+Ra+…Rn)；
The participator signs the cash-out transaction by using the random number, the aggregation public key, the aggregation random number and the participator random private key:
Si＝ki+hash(P,R,TM)·ski；Sa＝ka+hash(P,R,TM)·ska
summing all signatures S ═ S (S)1+…+Si+Sa+…Sn)；
An aggregated signature (R, S) is generated with the aggregated random number.
When the cash-out transaction is executed, the verification node in the chain B performs verification according to the public key list L and the cross-chain information TMSignature verification on aggregate signature (R, S):
verifying the presence of S G ═ R + hash (P, R, T)M) P, if present, the verification succeeds, and if not, the verification fails.
Counting the accumulated signature share of the user a and the managed node as signature weight and signature quantity, and performing POW consensus after the accumulated signature share exceeds 2/3 of the total quantity;
there is also a need to verify the authenticity of the cross-link cash-out information occurring in validation chain B in chain a by the light node, validate the cash-out transaction, transfer the cross-link asset M from the escrow address to the user a account, and destroy the mapped asset XM on chain B.
3. User a transfers managed asset M to user b across chains, and the implementation process is as follows:
in response to a user client user a cross-chain transfer request, a transfer transaction t is established by a hosting nodexAnd sends it to the relay program to transfer the transaction txAt least M transfer number NUM, aggregate hosting address D, user client mapping asset wallet address DaTarget client mapping asset wallet address db(ii) a Validation of transfer transactions by light node scheme in chain ASex;
after the validity is confirmed, the hosting node in the relay program inquires whether the balance of M in the aggregation hosting address D reaches NUM;
when the transfer sum is not reached, the associated user client informs the user a to store M meeting the transfer amount to the aggregation hosting address, and casts a corresponding mapping asset XM in the bound mapping asset wallet;
if so, the user client user a selects the signature weight (say 0, since the smaller its weight, the greater the chance that it will agree), and initiates the corresponding mapped asset XM transfer transaction t in chain Bx' the transaction information comprises mapping asset transfer number NUM and mapping asset wallet address d of the user clientaTarget client mapping asset wallet address db；
Chain B verification node pair mapping asset transfer transaction tx' carry on consensus verification, when the verification node of 2/3 agrees on the transaction, the verification passes from daNUM XM to d required for migrationb；
And destroying the corresponding quantity of cross-chain assets M of the user a in the aggregation hosting address D.
At this time, the user b can convert the corresponding XM into the corresponding digital asset M through the cross-chain cash-out operation, and the cross-chain transfer is completed.
The signature aggregation mechanism in the whole process is implemented as follows:
selecting a uniform elliptic curve base point to sequentially calculate a signature public key for a random private key of a signer; the participatory signers comprise a user client user and a managed node;
performing hash operation on all signature public keys after being collected to generate a public key list;
each participator selects a random number, the derivative random numbers of the random numbers are calculated by using the elliptic curve base points, and the derivative random numbers are summed to generate an aggregation random number;
further carrying out Hash operation on the public key list and the signature public key to obtain an aggregation public key;
the participator signs the cash withdrawal transaction by using a random number, an aggregation public key, an aggregation random number and a participator random private key, and generates an aggregation signature with the aggregation random number after summing all signatures;
and when the cash withdrawal transaction is executed, the verification node verifies the aggregated signature by using an elliptic curve algorithm according to the cash withdrawal transaction information and the public key list.
Example 2:
in the process of executing cross-chain cash withdrawal and cross-chain transfer signature, a MAST structure is adopted to encrypt and store a signature script, which specifically comprises the following steps:
and carrying out hash processing on the signature scripts generated by the user client and the managed node, generating corresponding hash values, storing the corresponding hash values in an MAST tree, carrying out upward recursion layer by layer, and finally generating a hash value, and storing the hash value in a top-end Merck root.
FIG. 4 is a diagram illustrating encrypted storage of signature scripts in MAST structure:
the signature script 3 generated by multiple signatures of a hosting node and a user in the cross-chain withdrawal process, and the signature script 1 and the signature script 2 generated by a verification node 1 and a verification node 2 in the cross-chain transfer process are subjected to Hash operation and stored in a MAST tree, and finally the Mercker root Hash (1,2&3) of the MAST tree is calculated. That is to say, when the signature script is output, only the data related to the signature on the mercker root and the mercker path in the mask tree needs to be provided, and the other signature information is still output in a hash ciphertext state.
Example 3:
and the chain A and the chain B verify the authenticity of the cross-chain transaction information by deploying the light node of the other side, and the cross-chain message communication of the chain A and the chain B is switched through the relay program.
1) In response to the user a cross-chain transaction request, the light node of the chain A monitors the block head containing the cross-chain transaction chain B, and the verification logic of the light node is as follows:
the light node contains the block header information of the block chain, and only the roothash value calculated by the merkle tree of all transactions needs to be maintained, namely the current block header containing the cross-chain transaction is confirmed according to the cross-chain transaction request.
Comparing the Root hash value obtained by the merkel Root (merkel Root) stored in the block header 2 in the light node with the Root hash value obtained by the merkel Proof (merkel Proof) provided by the chain a as in the block header 2 in fig. 5, the cross-chain transaction (cross-chain lifting or cross-chain transferring) TX3 obtained by the merkel Proof (merkel Proof) provided by the chain a as in fig. 6, and if they are consistent, the block header 2 contains a specific transaction; if not, not including;
setting the verification threshold to be 6, and confirming that the cross-chain transaction exists if the POW consensus is performed on 6 blocks after the block 2 containing the transaction, that is, the block 2 performs 6 times of consensus verification in the first block chain.
Example 2:
an aggregation signature-based cross-chain extension system comprises an aggregation casting module and a verification execution module;
the aggregation casting module generates an aggregation public key by using public keys of a user client and a plurality of hosting nodes, derives an aggregation hosting address from the aggregation public key, transfers a first block chain digital asset to the aggregation hosting address through the user client, and casts a corresponding mapping asset in an account wallet of a second block chain, wherein the hosting node is selected from verification nodes of the second block chain, and the mapping asset circulates in the second block chain and is converted with the first block chain digital asset according to a fixed ratio;
and the verification execution module responds to a cross-chain requirement that the user client selects the signature weight to trigger adaptation, the verification node performs consensus verification on the second block chain and executes corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is arranged in the first block chain.
More specifically, the polymeric casting module is configured to:
setting a signature weight of a user client for crossing a first blockchain digital asset to a second blockchain user participating in multiple signatures in a first block, wherein the weight threshold range is [0, 1/3 ];
and according to a cross-chain requirement of cross-chain withdrawal and cross-chain transfer proposed by a user cross-chain service application scene, and aiming at the cross-chain withdrawal and cross-chain transfer, a user client side sequentially adapts and selects a signature weight meeting corresponding cross-chain POW consensus verification within a signature weight threshold range.
The embodiments described above are presented to enable a person having ordinary skill in the art to make and use the invention. It will be readily apparent to those skilled in the art that various modifications to the above-described embodiments may be made, and the generic principles defined herein may be applied to other embodiments without the use of inventive faculty. Therefore, the present invention is not limited to the above embodiments, and those skilled in the art should make improvements and modifications to the present invention based on the disclosure of the present invention within the protection scope of the present invention.
Claims (10)
1. A cross-chain extension method based on aggregated signatures is characterized in that a cross-chain is executed by adopting an aggregated public key and the aggregated signatures, user signature weight is increased, and autonomous controllable decentralized cross-chain extension is realized, and the method specifically comprises the following steps:
generating an aggregation public key by using public keys of a user client and a plurality of hosting nodes, deriving an aggregation hosting address by using the aggregation public key, transferring a first block chain digital asset into the aggregation hosting address by using the user client, and casting a corresponding mapping asset in an account wallet of a second block chain, wherein the hosting node is selected from verification nodes of the second block chain, and the mapping asset circulates in the second block chain and is converted with the first block chain digital asset according to a fixed ratio;
and responding to a cross-chain requirement that the user client selects the signature weight to trigger adaptation, carrying out consensus verification on the second blockchain by the verification node, and executing corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is set in the first blockchain.
2. The aggregate signature-based cross-chain extension method of claim 1, further comprising:
the first blockchain and the second blockchain verify the authenticity of the cross-chain transaction information through deploying the light nodes of the opposite side, and the cross-chain message communication of the first blockchain and the second blockchain is transferred through the relay program.
3. The method according to claim 1 or 2, wherein an aggregation public key is generated by using a user client and a plurality of managed node public keys, and an aggregation managed address is derived from the aggregation public key, specifically as follows:
setting a relay program associated with the first block chain in the second block chain, selecting a plurality of managed nodes from the second verification nodes in the relay program, and distributing random keys for the managed nodes;
and generating signature public keys for the user client and all the escrow nodes in sequence by using the uniform elliptic base point, collecting all the signature public keys to generate an aggregate public key, and performing hash calculation on the aggregate public key to derive an aggregate escrow address.
4. The method according to claim 1, wherein the signature weight threshold for the user client to select is set in the first blockchain, specifically:
setting a signature weight of a user client for crossing a first blockchain digital asset to a second blockchain user participating in multiple signatures in a first block, wherein the weight threshold range is [0, 1/3 ];
and according to a cross-chain requirement of cross-chain withdrawal and cross-chain transfer proposed by a user cross-chain service application scene, and aiming at the cross-chain withdrawal and cross-chain transfer, a user client side sequentially adapts and selects a signature weight meeting corresponding cross-chain POW consensus verification within a signature weight threshold range.
5. The method for cross-chain extension based on aggregated signatures according to claim 4, wherein the cross-chain promotion implementation flow is as follows:
responding to a cross-link cash-up request of a user client, establishing a cash-up transaction by a hosting node, sending the cash-up transaction to a relay program, and initiating a multi-signature transaction of cross-link cash-up; the cash-out transaction at least comprises a digital asset cash-out quantity and a user account, and the validity of the cash-out transaction is confirmed in a first block chain through a light node scheme;
after the validity is confirmed, the user client selects the signature weight, a signature aggregation mechanism is started, the combined escrow node sequentially carries out multiple signatures on the cross-link cash-up information by using respective private keys, the generated multiple signatures are aggregated to generate an aggregated signature, and the user client participating in the signature and the escrow node public keys are aggregated to form a public key list;
verifying the aggregated signature by the verification node in the second block chain according to the public key list and the cross-chain message, and counting accumulated signature shares of the user client and the hosting node, wherein after the accumulated signature shares exceed 2/3 of the total number, POW consensus is executed;
transfer cross-chain assets from the hosting address to the user account while destroying mapped assets on the second blockchain.
6. The method for cross-chain extension based on aggregated signatures according to claim 4, wherein the cross-chain transfer implementation flow is as follows:
responding to a user client side cross-chain transfer request, establishing a transfer transaction by a hosting node and sending the transfer transaction to a relay program, wherein the transfer transaction at least comprises a digital asset transfer quantity, an aggregation hosting address, a user client side mapping asset wallet address, a target client side mapping asset wallet address, and confirming the validity of the transfer transaction through a light node scheme in a first block chain;
after the validity is confirmed, the hosting node in the relay program inquires whether the balance of the digital assets in the aggregation hosting address reaches the transfer amount;
when the transfer sum is not reached, the associated user client stores the cross-chain digital assets containing the transfer quantity to the aggregation hosting address, and casts the corresponding mapping assets in the bound mapping asset wallet;
if yes, the user client selects the signature weight, and initiates a corresponding mapping asset transfer transaction in the second block chain, wherein the transaction information comprises the mapping asset transfer quantity, the mapping asset wallet address of the user client and the mapping asset wallet address of the target client;
the second blockchain verification node performs consensus verification on the mapping asset transfer transaction, and mapping assets required by the mapping asset wallet address transfer from the user client to the target client mapping asset wallet address after the verification is passed;
and simultaneously destroying a corresponding number of cross-chain assets in the aggregation managed address of the user client.
7. The method for spreading across chains based on aggregated signatures according to claim 5, wherein the signature aggregation mechanism comprises the following steps:
selecting a uniform elliptic curve base point to sequentially calculate a signature public key for a random private key of a participator, wherein the participator comprises a user client and a trusteeship node;
performing hash operation on all signature public keys after being collected to generate a public key list;
each participator selects a random number, the derivative random numbers of the random numbers are calculated by using the elliptic curve base points, and the derivative random numbers are summed to generate an aggregation random number;
further carrying out Hash operation on the public key list and the signature public key to obtain an aggregation public key;
the participator signs the cash-out transaction by using a random number, an aggregation public key, an aggregation random number and a participator random private key, and generates an aggregation signature with the aggregation random number after summing all signatures;
and when the cash withdrawal transaction is executed, the verification node verifies the aggregated signature by using an elliptic curve algorithm according to the cash withdrawal transaction information and the public key list.
8. The method for expanding across chains based on aggregated signatures according to claim 1, further comprising a step of storing the signature script in an encrypted manner by using a MAST structure, and specifically, in the process of executing cross-chain cashing and cross-chain transfer signature, the signature scripts generated by the user client and the hosting node are subjected to hash processing, corresponding hash values are generated and stored in the MAST tree, and recursion is performed upwards layer by layer, and finally the generated hash values are stored in the top Mercker root.
9. The cross-chain extension system based on the aggregate signature is characterized by comprising an aggregate casting module and a verification execution module;
the aggregation casting module generates an aggregation public key by using public keys of a user client and a plurality of hosting nodes, derives an aggregation hosting address from the aggregation public key, transfers a first block chain digital asset to the aggregation hosting address through the user client, and casts a corresponding mapping asset in an account wallet of a second block chain, wherein the hosting node is selected from verification nodes of the second block chain, and the mapping asset circulates in the second block chain and is converted with the first block chain digital asset according to a fixed ratio;
and the verification execution module responds to a cross-chain requirement that the user client selects the signature weight to trigger adaptation, the verification node performs consensus verification on the second block chain and executes corresponding cross-chain transaction, wherein the signature weight threshold value selected by the user client is set in the first block chain.
10. The aggregate signature-based cross-chain extension system of claim 9, wherein the aggregate casting module is configured to:
setting a signature weight of a user client for crossing a first blockchain digital asset to a second blockchain user participating in multiple signatures in a first block, wherein the weight threshold range is [0, 1/3 ];
and according to a cross-chain requirement of cross-chain withdrawal and cross-chain transfer proposed by a user cross-chain service application scene, and aiming at the cross-chain withdrawal and cross-chain transfer, a user client side sequentially adapts and selects a signature weight meeting corresponding cross-chain POW consensus verification within a signature weight threshold range.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110826497.2A CN113407977B (en) | 2021-07-21 | 2021-07-21 | Cross-chain extension method and system based on aggregated signature |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110826497.2A CN113407977B (en) | 2021-07-21 | 2021-07-21 | Cross-chain extension method and system based on aggregated signature |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113407977A CN113407977A (en) | 2021-09-17 |
| CN113407977B true CN113407977B (en) | 2022-06-10 |
Family
ID=77687336
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110826497.2A Active CN113407977B (en) | 2021-07-21 | 2021-07-21 | Cross-chain extension method and system based on aggregated signature |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113407977B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114037449A (en) * | 2021-11-02 | 2022-02-11 | 杭州复杂美科技有限公司 | Cross-chain asset transfer method, computer device, and storage medium |
| CN114172661B (en) * | 2021-12-03 | 2023-12-08 | 杭州链网科技有限公司 | Bidirectional cross-link method, system and device for digital asset |
| CN114726548B (en) * | 2022-05-19 | 2022-11-11 | 国网数字科技控股有限公司 | Cross-chain-supported green electricity tracing method and system |
| CN117917681A (en) * | 2022-10-20 | 2024-04-23 | 腾讯科技（深圳）有限公司 | Asset transfer method, device, equipment, medium and product based on multi-block chain |
| CN117592991B (en) * | 2024-01-18 | 2024-04-26 | 暨南大学 | Efficient blockchain cross-chain data exchange method based on threshold signature |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109685486A (en) * | 2018-11-28 | 2019-04-26 | 杭州云象网络技术有限公司 | A kind of polymeric chain framework based on block chain technology |
| CN111769948A (en) * | 2020-06-15 | 2020-10-13 | 布比（北京）网络技术有限公司 | Block chain-based inter-chain interaction method, system, device and computer equipment |
| CN112184228A (en) * | 2020-09-30 | 2021-01-05 | 杭州复杂美科技有限公司 | Asset exchange method, device and storage medium |
| CN113032482A (en) * | 2021-03-10 | 2021-06-25 | 杭州链网科技有限公司 | Construction method and system of cross-chain transfer bridge |
| CN113114759A (en) * | 2021-04-09 | 2021-07-13 | 杭州链网科技有限公司 | Chain-crossing method and system for realizing multi-chain intercommunication |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210049600A1 (en) * | 2018-05-18 | 2021-02-18 | Qredo Ltd. | Digital Asset Delivery Network |
| AU2020341824A1 (en) * | 2019-09-06 | 2022-03-24 | Bosonic, Inc. | System and method of providing a blockchain-based recordation process |
-
2021
- 2021-07-21 CN CN202110826497.2A patent/CN113407977B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109685486A (en) * | 2018-11-28 | 2019-04-26 | 杭州云象网络技术有限公司 | A kind of polymeric chain framework based on block chain technology |
| CN111769948A (en) * | 2020-06-15 | 2020-10-13 | 布比（北京）网络技术有限公司 | Block chain-based inter-chain interaction method, system, device and computer equipment |
| CN112184228A (en) * | 2020-09-30 | 2021-01-05 | 杭州复杂美科技有限公司 | Asset exchange method, device and storage medium |
| CN113032482A (en) * | 2021-03-10 | 2021-06-25 | 杭州链网科技有限公司 | Construction method and system of cross-chain transfer bridge |
| CN113114759A (en) * | 2021-04-09 | 2021-07-13 | 杭州链网科技有限公司 | Chain-crossing method and system for realizing multi-chain intercommunication |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113407977A (en) | 2021-09-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113407977B (en) | Cross-chain extension method and system based on aggregated signature | |
| CN109360100B (en) | Transaction rapid confirmation method and device based on block chain technology | |
| US11257077B2 (en) | Blockchain system for confidential and anonymous smart contracts | |
| Duong et al. | Twinscoin: A cryptocurrency via proof-of-work and proof-of-stake | |
| CN106899698B (en) | Cross-chain interoperation method between block chains | |
| CN109858281B (en) | Block chain account model privacy protection method based on zero knowledge proof | |
| CN111371905B (en) | Block chain layering consensus proving system and method based on cloud computing | |
| CN112907252B (en) | Block chain transaction method and system based on multi-person chain lower channel | |
| CN109741068B (en) | Online banking cross-row signing method, device and system | |
| CN111046437A (en) | Block chain parallel transaction processing method and system based on isomorphic multi-chain and terminal | |
| CN113556237B (en) | Threshold signature method, system, device and storage medium based on aggregation of multiple signatures | |
| CN109245894B (en) | Distributed cloud storage system based on intelligent contracts | |
| CN109743182B (en) | Intelligent contract approval method and system based on block chain | |
| Asfia et al. | Energy trading of electric vehicles using blockchain and smart contracts | |
| CN115801260B (en) | Block chain-assisted collaborative attack and defense game method in untrusted network environment | |
| CN112488682B (en) | Three-party transfer method and device for block chain | |
| Tomescu et al. | Utt: Decentralized ecash with accountable privacy | |
| Bugday et al. | Securing blockchain shards by using learning based reputation and verifiable random functions | |
| Ning et al. | Keeping time-release secrets through smart contracts | |
| Ye et al. | Garou: An efficient and secure off-blockchain multi-party payment hub | |
| Dorsala et al. | Fair protocols for verifiable computations using bitcoin and ethereum | |
| Khalil et al. | FAKey: Fake hashed key attack on payment channel networks | |
| Wadhwa et al. | He-htlc: Revisiting incentives in htlc | |
| CN112669159A (en) | Trust-based value circulation method in different block chain systems | |
| CN111815329A (en) | Method for realizing high-performance block chain network based on cross-chain technology |
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 |