CN115941191B - Generation and verification method for non-consensus blocks in block chain and witness nodes - Google Patents
Generation and verification method for non-consensus blocks in block chain and witness nodes Download PDFInfo
- Publication number
- CN115941191B CN115941191B CN202211017975.6A CN202211017975A CN115941191B CN 115941191 B CN115941191 B CN 115941191B CN 202211017975 A CN202211017975 A CN 202211017975A CN 115941191 B CN115941191 B CN 115941191B
- Authority
- CN
- China
- Prior art keywords
- witness
- block
- node
- blockchain
- transaction
- 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
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The method for generating and checking the non-consensus block in the blockchain and the witness node can achieve the purposes of improving transaction throughput, reducing acknowledgement time delay and further reducing the operation and maintenance cost of the blockchain; the method comprises the following steps: setting a transaction and block conflict global judging method in a block chain protocol, wherein all block chain nodes independently judge the transaction and the block which are in conflict, and the same result is obtained; dividing the block chain generation process into a collection stage and a witness and casting stage, wherein the two stages are respectively completed by different block chain link points, and after each stage is completed, the executing node of the next stage is randomly and dynamically selected according to the current data.
Description
Technical Field
The application relates to the technical field of blockchains, in particular to a method for generating and checking a non-consensus block in a blockchain and a witness node.
Background
Blockchains are a distributed ledger (distributed data technology), which has been widely developed worldwide since 2008 when this smart was presented in its bitcoin paper, and has been known as one of the most important applications in the 21 st century.
The blockchain has the characteristics of decentralization, disclosure transparency, non-tampering, trust, collective maintenance, traceability and the like, and based on the characteristics, the blockchain not only roots in the financial industry but also flowers in other industries in a floor manner, thereby promoting the production relationship change.
The block chain stores data by using blocks, and the blocks are linked by using hash digests, so that the data cannot be tampered and the consistency of distributed storage is ensured.
In the current blockchain technology, data is written into a blockchain, and the data stored by different nodes is ensured to be consistent through a consensus process, namely, a plurality of blockchain nodes perform calculation verification on the data of the written chain, and the data is written into the blockchain through one of the nodes.
In a distributed peer-to-peer network environment, in order to ensure the consistency of the blockchain, the current blockchain consensus algorithm comprises the types of workload certification (PoW, proof-of-Work), rights and interests certification (PoS, proof-of-status), agent rights and interests certification (DPoS), and the like; the block chains are respectively used for accumulating resources such as workload (CPU time), rights (virtual tokens) and the like required by verification, and the longer the chain is, the more accumulation is, and the higher the cost required by counterfeiters and falsification is; based on the above, the consensus algorithm can ensure the safety of the blockchain.
FIG. 1 is a block chain structure in the prior art, in FIG. 1, each rectangle represents a block of the block chain, the blocks are interlinked, and any modification to the predecessor node will cause the successor node to change comprehensively; each block is generated after nodes in the blockchain peer-to-peer network win in calculation or voting competition, which means that an attacker can forge or tamper at the same or even more cost, and the cost is not economical, so that the consistency and the safety of the blockchain data are ensured.
However, the existing technology based on consensus of the blockchain has the defects of serious resource consumption, low transaction throughput and prolonged confirmation;
in terms of resource consumption:
such as: the consensus algorithm PoW is simple and easy to understand, but has the defects of performance bottleneck and resource waste.
Another example is: the consensus algorithm PoS and DPoS reduce energy consumption, but improve complexity of the completion of the consensus protocol, have high development cost, are inferior to PoW in safety, and have the possibility of weakening decentration.
In terms of throughput and acknowledgement latency:
the time delay of the consensus algorithm PoW is only 7TPS/10-60m (7 strokes/10-60 minutes per second), and the improvement of various PoWs is not more than 100TPS/10m;
the consensus algorithm PoS and PoW are not much different, DPoS is improved, but the method is not much practical, and the maximum value is not more than 200TPS/1m.
From the above, the current blockchain consensus algorithm can only be three or two among the number of consensus nodes, transaction performance and security, and needs to be improved.
Disclosure of Invention
In order to solve the technical problems in the prior art, the application provides a method for generating and checking a block without consensus and a witness node in a block chain, and provides a scheme for generating and checking a block without consensus, thereby achieving the purposes of improving transaction throughput, reducing acknowledgement time delay and further reducing block chain operation and maintenance cost.
The method for generating and checking the non-consensus block in the block chain comprises the following steps:
s01, setting a transaction and block conflict global judgment method in a block chain protocol, wherein all block chain nodes independently judge the transaction and the block which are in conflict, and the same result is obtained;
s02, splitting the block chain generation process into a collection stage and a witness and casting stage, wherein the two stages are respectively completed by different block chain link points, and after each stage is completed, the execution node of the next stage is randomly and dynamically selected according to the current data;
specifically, during the collection phase, it comprises:
s10, nodes of the blockchain peer-to-peer network monitor transaction messages and collect the transaction messages until the transaction number of the blocks designated by the protocol is reached, and then block suggestions are generated;
s20, the node generating the block proposal broadcasts witness and casting requests to a block chain peer-to-peer network;
in witness and casting stages, including:
s30, after receiving the witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node;
s40, the witness node checks the block suggestion, after the check is passed, the witness node attaches witness records after the legal block suggestion, hashes, encapsulates and signs the witness records, and then mounts the witness records on a block chain for broadcasting;
wherein, the block proposal comprises: all transaction data, hash digests of the previous block and witness request records; the witness request record includes: the node public key and the witness public key comparison value obtained after hash operation is carried out on the block proposal.
Optionally, in the method for generating and checking a block without a consensus in a blockchain, in step S30, it is determined whether the node is a witness node, which specifically includes:
based on the witness request record, calculating the witness distance, and when the calculated witness distance is smaller than the witness distance threshold set by the protocol, the node is the witness node.
Optionally, the method for generating and checking the block without consensus in the blockchain is further stated in the blockchain protocol: multiple rounds of witnessing the block suggestions are performed.
Optionally, in the method for generating and checking the block without the consensus in the blockchain, step S40, the witness node checks the block suggestion, after the check is passed, the witness node attaches the witness record to the legal block suggestion, hashes, encapsulates, signs and then mounts to the blockchain for broadcasting; the method specifically comprises the following steps:
s401, checking the validity of the block by the witness node, attaching a witness record after the block suggestion is passed through the check, and executing the step S402, otherwise, discarding the illegal block suggestion, and ending the witness and casting process;
s402, judging whether the number of the witness records added by the block currently is equal to the number of witness rounds, if so, finishing witness by the witness node, carrying out hash packaging and signature, and then mounting to a block chain for broadcasting, otherwise, executing step S403;
s403, attaching a new witness request after witness recording, and broadcasting the new witness and casting request to the blockchain peer-to-peer network;
s404, after receiving the new witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node, if yes, execute step S401, otherwise, do not respond to the new witness and casting request.
Optionally, in the step S401, the verifying the validity of the block includes:
and judging the block height and the legitimacy of all transactions, if the block height and the legitimacy of all transactions are legal, checking to pass, otherwise, discarding illegal block suggestions, and ending the witness and casting process.
Optionally, in the method for generating and checking a block without consensus in a blockchain, in the step S01, the global determination method for block conflict includes:
when the blocks collide, the block with the smallest transaction score value is selected to win, and other blocks are discarded.
The application also provides a witness node, comprising: the nodes of the blockchain peer-to-peer network monitor and collect transaction messages until the transaction number of the blocks designated by the protocol is reached, generating block suggestions, and broadcasting witness and casting requests to the blockchain peer-to-peer network;
the response module is used for judging whether the node is a witness node or not after receiving the witness and casting request;
and the verification module is used for verifying the block suggestion when the node is the witness node, attaching the witness record to the legal block suggestion after the verification is passed, carrying out hash encapsulation and signature, and then mounting the hash encapsulation and signature on the block chain for broadcasting.
Optionally, a witness node, the blockchain protocol further declares: performing multiple rounds of witness on the block suggestion;
the verification module comprises:
the validity judging module is used for checking the block height and the transaction validity by the witness node, attaching witness records after the block suggestions pass the check, discarding illegal block suggestions if the block suggestions do not pass the check, and terminating the witness and casting process;
and the iteration number judging module judges whether the maximum witness round number is reached, if so, the witness node completes witness, carries out hash packaging and signature, then mounts the witness node on a blockchain for broadcasting, otherwise, attaches a new witness request after witness recording, and broadcasts the new witness and casting request to a blockchain peer-to-peer network so as to enable new witness meeting the condition to continue checking.
The technical scheme provided by the application has the advantages that:
in the application, the basic mechanism for solving the block conflict based on the consensus in the existing block chain network is changed, a global block conflict solution based on global rules is replaced by the scheme, and a brand new block generation and verification scheme is provided based on the scheme, so that the dependence of the existing block chain technology on the consensus is removed, the consensus is fundamentally removed, the resource consumption, throughput bottleneck and confirmation time delay caused by the consensus are eliminated, and the practicability is extremely strong.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions of the related art, the drawings that are required to be used in the embodiments or the description of the related art will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort to those of ordinary skill in the art.
FIG. 1 is a block chain structure of the prior art;
FIG. 2 is a flow chart of one embodiment of a method for generating and verifying a non-consensus block in a blockchain provided by an embodiment of the present application;
FIG. 3 is a flowchart illustrating a step S40 of a method for generating and verifying a non-consensus block in a blockchain according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a block generation and verification structure according to an embodiment of the present application;
FIG. 5 is a schematic diagram of hash encapsulation and signing;
FIG. 6 is a schematic diagram of an embodiment of conflict resolution provided by an embodiment of the present application;
FIG. 7 is a schematic structural diagram of a specific embodiment of verifying validity of a transaction according to an embodiment of the present application;
FIG. 8 is a schematic diagram of a witness node according to an embodiment of the present application;
in the figure:
10 is a response module, 20 is a verification module;
201 is a validity judgment module, and 202 is an iteration number judgment module.
Detailed Description
The application provides a method for generating and checking a block without consensus and a witness node in a block chain, which solves the problems of low transaction throughput and prolonged confirmation in the prior art by constructing a new method for generating and checking a block without consensus.
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application; all other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
Example 1
Referring to fig. 2, the method for generating and checking a non-consensus block in a blockchain includes:
s01, setting a transaction and block conflict global judgment method in a block chain protocol, wherein all block chain nodes independently judge the transaction and the block which are in conflict, and the same result is obtained;
s02, splitting the block chain generation process into a collection stage and a witness and casting stage, wherein the two stages are respectively completed by different block chain link points, and after each stage is completed, the execution node of the next stage is randomly and dynamically selected according to the current data;
specifically, during the collection phase, it comprises:
s10, nodes of the blockchain peer-to-peer network monitor transaction messages and collect the transaction messages until the transaction number of the blocks designated by the protocol is reached, and then block suggestions are generated;
s20, the node generating the block proposal broadcasts witness and casting requests to a block chain peer-to-peer network;
in witness and casting stages, including:
s30, after receiving the witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node;
s40, the witness node checks the block suggestion, after the check is passed, the witness node attaches witness records after the legal block suggestion, hashes, encapsulates and signs the witness records, and then mounts the witness records on a block chain for broadcasting;
wherein, the block proposal comprises: all transaction data, hash digests of the previous block and witness request records; the witness request record includes: the node public key and the witness public key comparison value obtained after hash operation is carried out on the block proposal.
In the prior art, in order to ensure that the system meets consistency of different degrees, a consensus algorithm is generally adopted to achieve the goal of solving global conflicts, and in the prior blockchain technology, the casting process is completed in one node.
Specifically, in the collection phase:
all nodes of the blockchain peer-to-peer network participate in blockcollection, they listen for transaction messages and collect until the protocol-specified blocktransaction number (blocktx COUNT) is reached, and then generate blockproposal (blockproposal).
In this embodiment, the block proposal includes all transaction data and a hash digest of the previous block, and appends a WITNESS request RECORD (ask_for_witness_record); thereafter, the node broadcasts a WITNESS AND cast request (AFW: ASK_FOR_WITNESS_AND_MINT) to the blockchain peer-to-peer network.
Wherein, the WITNESS request record comprises the NODE public key (NODE_PK) and a WITNESS public key comparison VALUE (WITNESS_PK_COMPARING_VALUE) obtained after the block proposal is hashed;
further, in the witness and casting phase:
after receiving WITNESS and casting requests, a node in the blockchain peer-to-peer network calculates WITNESS DISTANCEs by using a DISTANCE function, and when the calculation result is smaller than a WITNESS DISTANCE THRESHOLD (WITNESS_DISTANCE_THRESHOLD) set by a protocol, the node is the WITNESS node and is used for checking the blockproposal.
The witness node checks the validity of the block proposal, discards the illegal block proposal, and terminates the witness and casting process.
In the application, the basic mechanism for solving the block conflict based on the consensus in the existing block chain network is changed, a global block conflict solution based on global rules is replaced, a brand new block generation and verification scheme is provided based on the scheme, the dependence of the existing block chain technology on the consensus is removed, the consensus is fundamentally removed, the resource consumption, throughput bottleneck and confirmation time delay caused by the consensus are eliminated, and the practicability is extremely strong.
In this embodiment, in step S30, it is determined whether the node is a witness node, which specifically includes:
based on the WITNESS request record, a WITNESS DISTANCE is calculated, and when the calculated WITNESS DISTANCE is less than a WITNESS DISTANCE THRESHOLD (witness_distance_threshold) set by the protocol, the node is a WITNESS node.
It should be noted that, the selection of the witness node may include various manners, and is not limited to the calculation of the witness distance by the distance function provided in the present embodiment.
In this embodiment, the distance function may be any monotonic distance function, such as: absolute value of the difference. When calculated using the distance function, if the witness public key comparison value is 0x07, the received public key of node a is 0x10, and the public key of node b is 0x5, the witness distance of a is |10-7|=3, and the witness distance of b is |5-7|=2.
The above is a description of one embodiment of the method for generating and checking a block without consensus in a blockchain provided by the present application, and another embodiment of the method for generating and checking a block without consensus in a blockchain provided by the present application will be described below.
Example two
On the basis of the first embodiment, there is no method for generating and checking a consensus block in a blockchain, and the blockchain protocol also declares: multiple rounds of witnessing the block suggestions are performed.
Referring to fig. 3 and 4, in the step S40, the witness node performs verification on the block proposal, after the verification is passed, the witness node attaches a witness record after the legal block proposal, performs hash encapsulation and signature, and then mounts the record to the blockchain for broadcasting; the method specifically comprises the following steps:
s401, checking the validity of the block by the witness node, attaching a witness record after the block suggestion is passed through the check, and executing the step S402, otherwise, discarding the illegal block suggestion, and ending the witness and casting process;
s402, judging whether the number of the witness records added by the block currently is equal to the number of witness rounds, if so, finishing witness by the witness node, carrying out hash packaging and signature, and then mounting to a block chain for broadcasting, otherwise, executing step S403;
s403, attaching a new witness request after witness recording, and broadcasting the new witness and casting request to the blockchain peer-to-peer network;
s404, after receiving the new witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node, if yes, execute step S401, otherwise, do not respond to the new witness and casting request.
In this embodiment, different WITNESS ROUNDs (witness_round_count) may be set according to different needs, so as to perform multiple WITNESS ROUNDs, so as to enhance the security of data.
When multiple rounds of verification are carried out, a first WITNESS node checks the validity of a block, after the verification is passed, a WITNESS RECORD (WITNESS_RECORD) is attached to the block after the block suggestion, meanwhile, whether the number of the WITNESS RECORDs attached to the block currently is equal to the number of WITNESS rounds is judged, if yes, the WITNESS node completes WITNESS, hashes, signs and then mounts the WITNESS node to a block chain for broadcasting, otherwise, after the WITNESS RECORD of the first WITNESS node, a new WITNESS request is attached and the WITNESS RECORD is broadcasted to the block chain peer-to-peer network; thereafter, a new witness meeting the condition in the blockchain peer-to-peer network will repeat the witness and casting process for multiple rounds until the number of witness records attached to the blockproposal is equal to the number of witness rounds.
After the witness record number is equal to the witness round number, the block proposal at the moment is regarded as a legal block, and after witness is completed, the witness node carries out hash encapsulation and signature and is mounted on a chain to broadcast the whole network.
Referring to fig. 5, hash packaging and signing are performed, a merck Tree (Merkle Tree) is generated by using the current transaction, leaf nodes are transactions, and intermediate nodes and root nodes are hash digests of child nodes.
The second embodiment of the method for generating and checking a block without a consensus in a blockchain provided by the present application is described above, and another embodiment of the method for generating and checking a block without a consensus in a blockchain provided by the present application is described below.
Example III
Referring to fig. 6, in the first embodiment, a method for generating and checking a block without a consensus in a blockchain, in the step S401, checking validity of a block includes:
and judging the block height and the legitimacy of all transactions, if the block height and the legitimacy of all transactions are legal, checking to pass, otherwise, discarding illegal block suggestions, and ending the witness and casting process.
In step S01, the global determination method for block conflict includes: when the blocks collide, the block with the smallest transaction score value is selected to win, and other blocks are discarded.
In this embodiment, the conflict resolution algorithm may be any monotonic function from block to real number domain, for example, a simple function may be the concatenation of transaction addresses of tx_score=block ascending transaction sequence.
When a conflict occurs, the block with the smallest tx_score wins, as shown in fig. 7:
the transaction tx_score is 12 and the transaction tx' is 13, when the two conflict, the transaction tx wins.
Referring to fig. 7, in the present embodiment, a method for determining validity of a transaction includes:
the public key of the deposit-side of the transaction in the transaction message and the hash operation of the previous transaction have the same result as the hash value in the message so as to ensure that the deposit-side of the transaction is confirmed by the deposit-side of the previous transaction;
the public key of the deposit party of the previous transaction (the deposit party of the current transaction) is taken out from the public key, and then the signature of the transaction message is verified according to the digital signature technology to be the deposit party of the current transaction (through private key verification).
It should be noted that, in the present embodiment, when verifying the validity of the block, only the block height is the current block height +1, and when all transactions are legal, the block is a legal block.
In the application, the block validity and the block conflict resolution algorithm are globally effective and consistent, any node in the distributed environment independently operates, and the same result (output) is obtained for the same input.
The foregoing describes another embodiment of a method for generating and verifying a non-consensus block in a blockchain provided by the present application, and an embodiment of a witness node provided by the present application is described below.
Referring to fig. 8, a witness node includes: the nodes of the blockchain peer-to-peer network monitor and collect transaction messages until the transaction number of the blocks designated by the protocol is reached, generating block suggestions, and broadcasting witness and casting requests to the blockchain peer-to-peer network;
the response module 10 is configured to determine whether the node is a witness node after receiving the witness and casting request;
and the verification module 20 is used for verifying the block proposal when the node is the witness node, attaching the witness record to the legal block proposal after the verification is passed, carrying out hash encapsulation and signature, and then mounting the hash encapsulation and signature on the block chain for broadcasting.
It should be noted that, in the blockchain protocol, it is also stated that: multiple rounds of witnessing the block suggestions are performed.
The verification module 20 includes:
the validity judging module 201 checks the block height and the transaction validity by the witness node, after the check is passed, the witness record is attached to the block suggestion, if the check is not passed, the illegal block suggestion is discarded, and the witness and casting process is terminated;
the iteration number judging module 202 judges whether the number of the witness records attached to the block currently is equal to the number of witness rounds, if yes, the witness node completes witness, carries out hash encapsulation and signature, and then mounts the witness to the blockchain for broadcasting, otherwise, a new witness request is attached to the witness records, and a new witness and casting request is broadcast to the blockchain peer-to-peer network, so that new witness persons meeting the condition can continue to check.
In addition, the application also provides a storage device, wherein a plurality of instructions are stored, and the instructions are suitable for being loaded by a processor and executing the method for generating and checking the non-consensus blocks in the block chain.
The storage device may be a computer readable storage medium, and may include: a U-disk, a removable hard disk, a Read-only memory (ROM), a random access memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The application also provides a terminal, which can comprise:
a processor adapted to implement instructions; and
a storage device adapted to store a plurality of instructions adapted to be loaded by a processor and to perform a method of generating and verifying a block without consensus in a blockchain as described above.
The terminal may be any device capable of implementing generation and verification of a non-consensus block in a blockchain, and the device may be various terminal devices, for example: desktop computers, laptop computers, cell phones, ioT devices, etc., may be implemented in particular by software and/or hardware.
In summary, the application removes the dependence of the existing blockchain technology on the consensus, instead of the globally consistent deterministic algorithm, designs the corresponding block generation and verification protocol, and eliminates the resource consumption, throughput bottleneck and acknowledgement delay caused by the consensus due to the fundamentally removal of the consensus.
The operation and maintenance cost of the block chain is greatly reduced, and the cost of one block is one hundredth, one thousandth or even one thousandth of the current calculation; the efficiency of the system is greatly improved, and even under the condition of the simplest and non-optimized system, the throughput and the confirmation time delay of the system can easily exceed the throughput and the confirmation time delay of all the prior blockchain technologies, which are better than 1000TPS/10s. And the existing framework has a large optimization space, and is expected to be further greatly promoted across orders of magnitude.
The blockchain technology is a key basis of the new generation of Web3 revolution, and the application plays a fundamental and decisive role.
In the description of the present application, it should be understood that, as will be clearly understood by those skilled in the art, for convenience and brevity of description, specific working procedures of the systems, apparatuses and units described above may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the indirect or direct coupling or communication connection between the illustrated and discussed devices and units may be through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.
Claims (7)
1. The method for generating and checking the non-consensus block in the block chain is characterized by comprising the following steps of: comprising the following steps:
s01, setting a transaction and block conflict global judgment method in a block chain protocol, wherein all block chain nodes independently judge the transaction and the block which are in conflict, and the same result is obtained;
s02, splitting the block chain generation process into a collection stage and a witness and casting stage, wherein the two stages are respectively completed by different block chain link points, and after each stage is completed, the execution node of the next stage is randomly and dynamically selected according to the current data;
specifically, during the collection phase, it comprises:
s10, nodes of the blockchain peer-to-peer network monitor transaction messages and collect the transaction messages until the transaction number of the blocks designated by the protocol is reached, and then block suggestions are generated;
s20, the node generating the block proposal broadcasts witness and casting requests to a block chain peer-to-peer network;
in witness and casting stages, including:
s30, after receiving the witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node;
s40, the witness node checks the block suggestion, after the check is passed, the witness node attaches witness records after the legal block suggestion, hashes, encapsulates and signs the witness records, and then mounts the witness records on a block chain for broadcasting;
wherein, the block proposal comprises: all transaction data, hash digests of the previous block and witness request records; the witness request record includes: the node public key and the witness public key comparison value obtained after hash operation is carried out on the block proposal.
2. The method for generating and verifying a non-consensus block in a blockchain of claim 1, wherein: in the step S30, determining whether the node is a witness node specifically includes:
based on the witness request record, calculating the witness distance, and when the calculated witness distance is smaller than the witness distance threshold set by the protocol, the node is the witness node.
3. The method for generating and verifying a non-consensus block in a blockchain of claim 1, wherein: the blockchain protocol also states: multiple rounds of witnessing the block suggestions are performed.
4. The method for generating and verifying a non-consensus block in a blockchain of claim 3, wherein: step S40, the witness node checks and witness the block proposal, after the check is passed, the witness node attaches witness records after the legal block proposal, hashes, encapsulates and signs, and then mounts the hashes and signs to the blockchain for broadcasting; the method specifically comprises the following steps:
s401, checking the validity of the block by the witness node, attaching a witness record after the block suggestion is passed through the check, and executing the step S402, otherwise, discarding the illegal block suggestion, and ending the witness and casting process;
s402, judging whether the number of the witness records added by the block currently is equal to the number of witness rounds, if so, finishing witness by the witness node, carrying out hash packaging and signature, and then mounting to a block chain for broadcasting, otherwise, executing step S403;
s403, attaching a new witness request after witness recording, and broadcasting the new witness and casting request to the blockchain peer-to-peer network;
s404, after receiving the new witness and casting request, other nodes in the blockchain peer-to-peer network judge whether the node is the witness node, if yes, execute step S401, otherwise, do not respond to the new witness and casting request.
5. The method for generating and verifying a non-consensus block in a blockchain of claim 4, wherein: in the step S401, verifying the validity of the block includes:
and judging the block height and the legitimacy of all transactions, if the block height and the legitimacy of all transactions are legal, checking to pass, otherwise, discarding illegal block suggestions, and ending the witness and casting process.
6. The method for generating and verifying a non-consensus block in a blockchain of claim 1, wherein: in the step S01, the global determination method for block conflict includes:
when the blocks collide, the block with the smallest transaction score value is selected to win, and other blocks are discarded.
7. Witness nodes, characterized in that: comprising the following steps: the nodes of the blockchain peer-to-peer network monitor and collect transaction messages until the transaction number of the blocks designated by the protocol is reached, generating block suggestions, and broadcasting witness and casting requests to the blockchain peer-to-peer network;
the response module (10) is used for judging whether the node is a witness node or not after receiving the witness and casting request;
the verification module (20) is used for verifying the block proposal when the node is the witness node, attaching the witness record to the legal block proposal after the verification is passed, carrying out hash encapsulation and signature, and then mounting the hash encapsulation and signature on the block chain for broadcasting;
the blockchain protocol also states: performing multiple rounds of witness on the block suggestion;
the verification module (20) comprises:
the validity judging module (201) is used for checking the block height and the transaction validity by the witness node, attaching witness records after the block suggestions pass the check, discarding illegal block suggestions if the block suggestions do not pass the check, and terminating the witness and casting process;
and the iteration number judging module (202) judges whether the number of the witness records added to the block currently is equal to the number of witness rounds, if so, the witness node completes witness, carries out hash encapsulation and signature, then mounts the witness to a blockchain for broadcasting, otherwise, attaches a new witness request after the witness records, and broadcasts the new witness and casting request to a blockchain peer-to-peer network so as to enable new witness persons meeting the condition to continue checking.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211017975.6A CN115941191B (en) | 2022-08-24 | 2022-08-24 | Generation and verification method for non-consensus blocks in block chain and witness nodes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211017975.6A CN115941191B (en) | 2022-08-24 | 2022-08-24 | Generation and verification method for non-consensus blocks in block chain and witness nodes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115941191A CN115941191A (en) | 2023-04-07 |
| CN115941191B true CN115941191B (en) | 2023-09-22 |
Family
ID=86552871
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211017975.6A Active CN115941191B (en) | 2022-08-24 | 2022-08-24 | Generation and verification method for non-consensus blocks in block chain and witness nodes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115941191B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109936457A (en) * | 2019-02-20 | 2019-06-25 | 深圳前海微众银行股份有限公司 | Block chain witnesses method, apparatus, equipment and computer readable storage medium in many ways |
| WO2020022958A1 (en) * | 2018-07-27 | 2020-01-30 | Aioz Pte Ltd | Method and apparatus for transaction verification in a blockchain-based network |
| CN110875893A (en) * | 2018-08-29 | 2020-03-10 | 深圳启元信息服务有限公司 | Consensus verification method, check node and block chain system |
| CN112073382A (en) * | 2020-08-12 | 2020-12-11 | 北京大学 | Graph type account book node maintenance method and device based on random consensus |
| CN112116470A (en) * | 2020-08-12 | 2020-12-22 | 北京大学 | Method and device for creating schema book based on random witnesses |
| CN112116349A (en) * | 2020-08-12 | 2020-12-22 | 北京智融云河科技有限公司 | High-throughput-rate-oriented graph type account book randomization consensus method and device |
-
2022
- 2022-08-24 CN CN202211017975.6A patent/CN115941191B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020022958A1 (en) * | 2018-07-27 | 2020-01-30 | Aioz Pte Ltd | Method and apparatus for transaction verification in a blockchain-based network |
| CN110875893A (en) * | 2018-08-29 | 2020-03-10 | 深圳启元信息服务有限公司 | Consensus verification method, check node and block chain system |
| CN109936457A (en) * | 2019-02-20 | 2019-06-25 | 深圳前海微众银行股份有限公司 | Block chain witnesses method, apparatus, equipment and computer readable storage medium in many ways |
| CN112073382A (en) * | 2020-08-12 | 2020-12-11 | 北京大学 | Graph type account book node maintenance method and device based on random consensus |
| CN112116470A (en) * | 2020-08-12 | 2020-12-22 | 北京大学 | Method and device for creating schema book based on random witnesses |
| CN112116349A (en) * | 2020-08-12 | 2020-12-22 | 北京智融云河科技有限公司 | High-throughput-rate-oriented graph type account book randomization consensus method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115941191A (en) | 2023-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110868440B (en) | Block chain male chain | |
| CN109102287B (en) | Block chain accounting method, device, equipment and storage medium | |
| CN111131209B (en) | Improved efficient consensus method, system, computer device and storage medium | |
| WO2023045620A1 (en) | Transaction data processing method and apparatus, computer device and storage medium | |
| CN112039860B (en) | Method and device for realizing joint consensus fragmentation in alliance chain | |
| CN111698094B (en) | Common identification method based on block chain system and block chain system | |
| CN111010284B (en) | Processing method of block to be identified, related device and block chain system | |
| CN110400218B (en) | Layered consensus method based on co-audition group system and block chain data processing system | |
| CN113407632A (en) | PBFT (proxy-based policy and authorization-based ft) trust certification block chain consensus algorithm | |
| CN111478795B (en) | Alliance block chain network consensus method based on mixed Byzantine fault tolerance | |
| CN113518005B (en) | Block consensus method, device, equipment and storage medium | |
| CN112907369A (en) | Block chain-based data consensus method and device, electronic equipment and storage medium | |
| WO2020133148A1 (en) | Data processing method and apparatus for blockchain, and blockchain system | |
| US20220239668A1 (en) | Blockchain-based message processing method and apparatus, device, and storage medium | |
| CN114745131A (en) | PBFT (basis weight function) improved consensus algorithm of block chain | |
| US11831749B1 (en) | Method and system for utilizing the infrastructure of a blockchain to enhance the degree of reliability of another blockchain | |
| CN115941191B (en) | Generation and verification method for non-consensus blocks in block chain and witness nodes | |
| CN114402352A (en) | Method and apparatus for tracking and measuring a proof of work contribution in a mine | |
| CN111371556A (en) | Block link point accounting method, device, equipment and storage medium | |
| CN116977067A (en) | Block chain-based data processing method, device, equipment and readable storage medium | |
| CN112600698B (en) | Block chain consensus method, system, equipment and medium applied to non-block-out node | |
| CN112583908B (en) | Block chain consensus method, system, equipment and medium applied to block outlet node | |
| CN113472825B (en) | NB-IoT terminal transaction processing method and device based on block chain | |
| CN116488818A (en) | Block chain-based data processing method, device, equipment and readable storage medium | |
| US20240015037A1 (en) | Data processing method and apparatus for consensus network, program product, device, and medium |
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 |