CN109951474B - Method for realizing block chain common identification block - Google Patents
Method for realizing block chain common identification block Download PDFInfo
- Publication number
- CN109951474B CN109951474B CN201910196533.4A CN201910196533A CN109951474B CN 109951474 B CN109951474 B CN 109951474B CN 201910196533 A CN201910196533 A CN 201910196533A CN 109951474 B CN109951474 B CN 109951474B
- Authority
- CN
- China
- Prior art keywords
- block
- witness
- verification information
- voting
- information
- 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
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a method for realizing block chain common identification block, which comprises the following concrete steps: (1) the participating nodes select witnesses; (2) generating a block by the witness; (3) and verifying and confirming the generated block and writing the block into a database to finish block output. The invention provides an effective reward penalty mechanism and an excitation mechanism for participating nodes, reduces the node range for carrying out the common identification block through the selection of a witness, improves the safety, reduces the common identification energy consumption, generates and selects a unique and consistent block on the height of a certain block by further verifying the confirmation block, avoids block bifurcation, reduces the damage of malicious nodes to the block chain network, and ensures the normal and safe operation of the block chain network.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a method for realizing block chain common identification blocks.
Background
The blockchain is a growing distributed ledger, the ledger is connected together in a 'block' mode, the blocks contain metadata such as transaction, timestamp, random number and the like, each block contains a pointer pointing to the last transaction link, and the blockchain is safe in design because of good Byzantine fault tolerance. The block chain can be summarized into a distributed high-frequency transaction system, and with the increase of the service volume, public chain networks such as bit coins and the like are congested, the transaction cost is increased, and compared with a traditional financial settlement system, the speed advantage is not provided. In a distributed system, a plurality of hosts form a network cluster through asynchronous communication, and in such an asynchronous system, state replication between the hosts is required to ensure that each host achieves consistent state consensus. However, in asynchronous systems, failed hosts that cannot communicate may occur, the performance of the hosts may be degraded, and the network may be congested, which may cause error messages to propagate through the system, so that a fault tolerance protocol needs to be defined in the default unreliable asynchronous network to ensure that the hosts achieve a safe and reliable status consensus. For decentralized systems, because community members cannot reach a consensus on their own interests, it is difficult to adopt a more efficient consensus algorithm.
In the blockchain system, what each node has to do is to keep its own account consistent with accounts of other nodes, so how to keep respective data consistent by each node through a rule is a very core problem in the blockchain system, and a solution to this problem is to formulate a set of consensus algorithm to achieve consistency and correctness of account data on different account nodes. The consensus algorithm is a process for solving how independent nodes in the peer-to-peer network (P2P) achieve a resolution problem, in other words, how to maintain consistency in a distributed system. The consensus mechanism has become a key bottleneck of the performance of the blockchain system at present, and with the increase of the ledger data and the improvement of the traffic volume in the blockchain, the expandability is also a problem to be solved urgently by the blockchain system, and meanwhile, a new challenge is also provided for the consensus algorithm.
The single consensus algorithm has various problems, such as workload certification (PoW), wherein the wisdom is put forward in a thesis and uses PoW to construct a bitcoin BTC, all miners search a hash value which proves that the node spends much work, the PoW algorithm has the problems of large consumption of computing resources and low performance, and the fault tolerance is mineral 1/2. Proof of equity (PoS), i.e. the probability of each node digging into a block is proportional to the proportion of coins it holds, if this node holds 10% of coins, then the next high block has a probability of 10% being dug by this node, and its fault tolerance is 1/2 of the amount of tokens. Proof of authorized rights and interests (DPoS), i.e., a token holder can elect a witness, the authorized witness can vote to generate blocks faster than PoS, reward the witness for belonging, have no fault tolerance, but easily generate block divergence. The Byzantine fault-tolerant algorithm (BFT), a classic algorithm for solving the consistency problem in a distributed system, can ensure that the whole system keeps consistency externally through encryption and multiple rounds of message communication, and has the fault tolerance of 1/3 participating in the nodes.
At present, in many common block chain consensus methods, the security is low, the energy consumption is high, and the fault tolerance rate is high, and as the DPoS consensus does not further verify the generated block, if the node generating the block is a malicious node, the block chain is easy to generate block branching, so that the idea of fusing the advantages of multiple consensus algorithms is receiving more and more extensive attention. In addition, the method comprises a consensus algorithm for selecting a main node from a small part of trusted nodes, an asynchronous consensus algorithm for ensuring high-probability correctness, a consensus algorithm for reducing network broadcasting based on specific security premise, a consensus algorithm based on trusted hardware and the like, and is also a research hotspot of a block chain consensus algorithm in the future.
Disclosure of Invention
In view of the above, the present invention provides a method for implementing a blockchain common identification block, which provides an effective punishment mechanism and an excitation mechanism for participating nodes, avoids block bifurcation, reduces damage of malicious nodes to a blockchain network, and ensures normal and safe operation of the blockchain network.
A method for realizing block chain common identification blocks comprises the following steps:
(1) selecting a witness from the participating nodes in the block chain network;
(2) generating a block by the witness;
(3) and verifying and confirming the generated block and writing the block into a database to finish block output.
Further, the specific implementation process of the step (1) is as follows:
1.1 a voting contract is formulated, which contract comprises the logic: the qualification examination of the voter (including the registration information, the number of tokens held, the registration time, the presence or absence of malicious voting records, etc.) and the statistics and ranking of the number of votes; further broadcasting and writing the voting contract into the block chain, so that any node can read the voting contract;
1.2 the audited participating nodes call a voting contract to vote;
the participation node has the authority to vote, cancel the voting and set a voting agent, and the voting is realized by establishing a transaction, wherein the transaction comprises a function of a voting contract to be called and function participation; taking voting as an example, the address of a voting contract is needed, the called function is a voteWitnesses function, and the parameters are the voting mortgage amount and the witnesses to whom the vote is cast.
1.3 the voting contract supports the half-life of voting, namely, the vote counting is carried out in a relatively attenuated mode, and the specific formula is as follows: number of tokens 2Current time-reference time(ii) a Thereby reducing the influence of the voter no longer having the corresponding token;
1.4 according to the obtained votes, sorting the voted persons, and obtaining the first 3m +1 voted persons with the highest votes as witnesses, wherein m is a natural number larger than 0.
Furthermore, the voting contract also comprises a quality deposit mechanism, namely a certain amount of quality deposit needs to be paid before the node participates in the voting, if malicious voting (such as multi-casting, error casting and the like) occurs in the voting process, the system will not accept the quality deposit of the node, and the malicious voting is recorded on the chain, so as to ensure the safety and justice of the whole voting.
Further, the reference time is an initial unified determined time set by the voting contract.
Further, the specific implementation process of the step (2) is as follows:
2.1 setting witness updating periods according to the number of witness, wherein each period is divided into a plurality of block generation period sections, and each block generation period section is allocated with a unique witness;
the function of dynamically managing the witnesses is added, the witness updating period is set according to the number of the selected witnesses, the latest first 3m +1 witnesses are inquired and obtained every 1 period before the blocks are generated, and the witnesses have the right to generate the blocks. Generating period sections in blocks according to the number of witnesses in each period, and distributing a unique witness to each period section;
2.2, sequencing each period in turn, wherein only the witness to which the period belongs has the authority to generate blocks; after all the witnesses generate the blocks in turn, entering the step (1) to perform the next round of witness election, or determining whether to take turns again according to the actual block chain scene to update the cycle of the witness;
and 2.3, generating blocks by all witnesses in the period of the witnesses according to the turn, recording the turn of generating the blocks, and updating the system to the period of the next turn after the generated blocks are broadcasted.
Further, the specific implementation process of the step (3) is as follows:
3.1 the witness broadcasts the block information and the turns thereof to other witnesses;
3.2 after the witness receives the block information and the turns of the block, the witness verifies the block information, signs after the verification is successful, generates first verification information and sends the first verification information to other witnesses, and meanwhile receives the first verification information sent by other witnesses;
3.3 when the witness holds the number of the first verification information containing the same block information, which is more than or equal to 2m, generating second verification information by the first verification information and sending the second verification information to other witnesses, wherein m is a natural number more than 0;
if the corresponding round of the received block is not consistent with the round of the period segment of the currently generated block, discarding the block, if so, generating first verification information and sending the first verification information to other witnesses, meanwhile, receiving the first verification information sent by the other witnesses, counting the first verification information, generating second verification information from the first verification information and sending the second verification information to the other witnesses when the number of the held first verification information containing the same block information is more than or equal to 2m, and if the number of the held first verification information is less than 2m, ensuring that the witness has no authority of sending the second verification information and cannot identify the block;
3.4 when any witness in the block chain verifies that the number of second verification information which contains the same block information and is held by the witness exceeds 2m +1, the block information is written into the database, and a new block is generated by broadcasting confirmation and awarding is obtained.
Any witness in the block chain receives the second verification information in a statistical manner, so that the consistency of the generated blocks can be further ensured in the second verification stage no matter whether malicious nodes exist, when the number of the second verification information (including the second verification information generated by the witness) holding the same block information exceeds 2m +1, the block information is written into the database, a new block is generated through broadcast confirmation, and the witness can obtain rewards after the block is found out.
Further, if the turn corresponding to the block received by the witness in the step 3.2 is not in accordance with the turn of the period segment in which the block is currently generated, the block is discarded; and if the verification information is consistent with the verification information, generating first verification information and sending the first verification information to other witnesses.
Further, when the number of the first verification information containing the same block information held by the witness in the step 3.3 is less than 2m, the witness has no authority to send the second verification information; and 3.4, if the number of the second verification information containing the same block information held by the witness is less than 2m +1, determining that no new block is generated.
Based on the technical scheme, the invention provides a new consensus method for providing an effective penalty mechanism and an excitation mechanism for participating nodes, reduces the node range of the consensus block by the election of a witness, improves the safety, reduces the energy consumption of consensus, generates and selects a unique and consistent block on the height of a certain block by further verifying the confirmation block, avoids block bifurcation, reduces the damage of malicious nodes to the block chain network, and ensures the normal and safe operation of the block chain network.
Drawings
FIG. 1 is a schematic overall flow chart of the block co-recognition method of the present invention.
FIG. 2 is a schematic diagram of witness generating blocks within a cycle.
FIG. 3 is a block diagram of block verification and validation according to the present invention.
Fig. 4 is a schematic diagram of the double verification of the present invention.
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.
(1) Fig. 1 is an overall flow for realizing a block chain consensus block according to the present invention, in which a voting contract is first formulated, the voting contract is broadcasted and written into a block chain, any node can read the voting contract, and the contract includes logic: the qualification examination of voters (including registration information, the number of tokens held, registration time, whether there is a malicious vote record, etc.), and the statistics and ranking of the number of votes.
The approved participation nodes call a voting contract to vote, a quality deposit mechanism is set in the voting process, and quality deposits need to be paid before the nodes participate in the voting so as to ensure the safety and fairness of the whole voting; the participatory voting node has the right to vote, cancel the vote and set the voting agent, and is realized by creating a transaction, wherein the transaction comprises a function of a voting contract to be called and the function participation. Taking voting as an example, an address of a voting contract is needed, a called function is a voteWitnesses function, and parameters are as follows: the amount of the vote mortgage, which witnesses to cast.
The voting contract supports the voting half-life period, and the vote counting is carried out in a relative attenuation mode, wherein the relative attenuation formula is as follows: number of tokens 2Current time-reference time。
The most direct conversion is a constant ratio conversion, such as 1 token equal to 1 ticket. However, the most straightforward approach has the following problems:
for example, a initially votes for 10 tokens, and after a period of time, a sells some or all of its tokens, resulting in tokens <10 held by a, at which time a's vote should be discarded and a re-vote made. However, the system cannot pay attention to the amount of tokens in a certain node account at every moment and then revoke its vote, which is very costly.
The voting contract of the present invention supports a half-life mode which does not completely solve the influence of the voter no longer having the corresponding token, but can reduce the influence. For example, a votes for 10 tickets initially using 10 tokens, and after 1 year, the value of the ticket becomes 5 tickets and then becomes 2.5 tickets after 1 year; although a no longer has 10 tokens, as time progresses, the tickets that a cast disappear.
The half-life is normally calculated by decaying the value over time. For a huge number of votes, half-life calculation needs to be performed on the votes already cast each time, and the calculation amount is huge, so that the contract execution is very time-consuming. In a relatively attenuated manner, if 10 tokens are available, 10 tickets can be converted, and 10 tokens can be converted into 10 × 2 tickets after one year; after a further year, 10 tokens can be converted into 10 x 2 tickets.
The reference time is initial unified determined time set by the voting contract, a reference year is adopted, the service years are periods, relative attenuation is used, the reference year is needed to be used, the same reference is used, attenuation is calculated, and the years of online of a network, such as 2018, can be adopted.
Number of tokens 2Time-2018
Supporting a non-periodic multiple decay, such as now 6 months of 2018, the votes should be:
number of tokens 20.5
As shown in fig. 2, in a block chain network, a participating node votes for a certain number of witnesses of 3m +1 through a voting contract, the number of the witnesses is determined by actual requirements of a block chain scene, a service and the like, the selected witnesses generate period periods in blocks in the period according to witness update periods, and round sequencing (1-3 m +1) is performed on each period in combination with the number of the witnesses and the length of the update period, and the witnesses have the right to generate blocks. And partitioning the witnesses in each period according to the number of the witnesses to generate time intervals, distributing a unique witness to each time interval, sequentially carrying out round sequencing on each time interval, only the witness to which the witness belongs has authority to generate blocks, packaging the information such as common information, registration information, agency information and the like by the witness to which the witness belongs, generating the blocks, recording the round of generating the blocks, and broadcasting the generated block information and the round of generating the blocks to other witnesses.
And after receiving the round of the generated block information, the other witnesses verify and sign the block information and the round, if the corresponding round of the received block is not consistent with the period round of the currently generated block, discard the block, if the corresponding round of the received block is consistent with the period round of the currently generated block, generate first verification information and send the first verification information to the other witnesses, receive first verification information sent by the other witnesses, count the first verification information, generate second verification information from the first verification information and send the second verification information to the other witnesses when the number of the held first verification information containing the same block information is more than or equal to 2m, and if the number of the held first verification information is less than 2m, ensure that the witness has no authority of sending the second verification information and cannot verify the block.
Any witness in the block chain receives the second verification information in a statistical manner, when the number of the second verification information (including the second verification information generated by the witness) with the same block information exceeds 2m +1, the block information is written into the database, a new block is generated through broadcast confirmation, and the witness obtains rewards.
Block bifurcation is prevented, and consistency is maintained:
(2) as shown in fig. 3, it is assumed that in a certain blockchain network, by selecting and generating A, B, C, D four witnesses, in a block generation period T, the periods of generating blocks of the four witnesses are T1, T2, T3 and T4, respectively, and the turns are 1, 2, 3 and 4, respectively. Under normal circumstances, witness A may generate block a at time t1, such as block a, with a round of 1, likewise witness B may generate block B at time t2, with a round of 2, witness C may generate block C at time t3, with a round of 3, and witness D may generate block D at time t4, with a round of 4.
If A is a malicious node, two situations are adopted: (1) a generates tile a!at t 1! However, the block broadcast is sent at t2, since the broadcast information must include the generation block information and the turn it belongs to, at this time, all witnesses' turns have switched to: height h, round 2, when verifying the received block information and the round to which it belongs, a! The legal turn of (a) is height h, turn 1, which does not match the turn of the currently generated tile, and all witness nodes discard a! Witness B may be used to generate tile B at time t2, round 2, where bifurcation is avoided and tile consistency is maintained.
(2) A generates tiles a and a!simultaneously during period t 1! And broadcast, during which the blocks with the same height and the same turn have a! And a, thereby causing block forking, to prevent block forking, the present invention proceeds to a next block verification confirmation, as shown in FIG. 4, where A broadcasts its generation blocks a and a! Assuming that witnesses B and C receive the information for block a, witness D receives block a! The witnesses B, C and D respectively verify and sign the received block information and the corresponding turns, generate first verification information, send the first verification information to other witnesses, and receive the first verification information sent by other witnesses. At this time, the first authentication information held by the witness is as follows:
a: the first authentication information received from B and C comprises block a, the first authentication information of D comprises block a! (ii) a
B: the first authentication information received from A and C comprises block a, and the first authentication information received from D comprises block a! (ii) a
C: the first authentication information received from A and B comprises block a, and the first authentication information received from D comprises block a! (ii) a
D: the first authentication information received from B and C includes block a, and the first authentication information of A includes block a! .
At this time, as long as B, C and D can receive information from each other, whether A sends a or a! B, C, D each hold 2 pieces of first authentication information (m is 1 at this time) including a-block information, the first authentication information including a-block information can be generated into a second authentication information to be sent out, the first authentication information of B and C received by A includes a block a, and the first authentication information of D includes a block a! However, a does not have the authority to generate the first authentication information, and can only generate the second authentication information based on the received first authentication information. Entering the second verification stage, the witness A, B, C, D respectively counts the number of the same blocks a contained in the second verification information held by the witness A, B, C, D, verifies whether other witnesses select the first verification information of the same blocks, and further ensures that the consistency of the generated blocks can be ensured in the second verification stage regardless of whether a malicious node appears, in this embodiment, the witness holds the second verification information as follows:
a: b, C, D, which contains block a, and holds 4 pieces of second verification information containing block a;
b: a, C, D, which contains block a, and holds 4 pieces of second verification information containing block a;
c: a, B, D, which contains block a, and holds 4 pieces of second verification information containing block a;
d: the second verification message received A, B, C contains block a, and has a total of 4 second verification messages containing block a.
(3) In the second verification stage, no matter whether the witnesses have malicious block confirmation behaviors, only the witnesses send the verification information to each other and the second verification information is needed, if the number of the second verification information containing the same block information is ensured to be more than or equal to 2m +1, the consistent block output can be carried out, if the number of the second verification information containing the same block information is finally less than 2m +1, the authority of identifying the block is not provided, and no new block is generated in the period.
In summary, no matter whether witnesses with malicious witness nodes appear, the consistency of blocks generated by each witness can be guaranteed through periodic block output and block further verification and confirmation stages (a first verification stage and a second verification stage), block branching is prevented, and the whole block chain system either generates consistent blocks or generates no blocks. Therefore, the invention can provide a block chain consensus method with high efficiency, effective excitation mechanism, block bifurcation prevention and consistency guarantee.
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 (5)
1. A method for realizing block chain common identification blocks comprises the following steps:
(1) the witness is selected by the participating nodes in the block chain network, and the specific implementation process is as follows:
1.1 a voting contract is formulated, which contract comprises the logic: the qualification examination of the voter and the statistics and sequencing of the votes, and further broadcasting and writing the voting contract into a block chain, so that any node can read the voting contract;
1.2 the audited participating nodes call a voting contract to vote;
1.3 the voting contract supports the half-life of voting, namely, the vote counting is carried out in a relatively attenuated mode, and the specific formula is as follows: number of tokens 2Current time-reference time；
1.4, sequencing the elected persons according to the obtained votes, and obtaining the first 3m +1 elected persons with the highest votes as witnesses, wherein m is a natural number more than 0;
(2) the block is generated by the witness, and the specific implementation process is as follows:
2.1 setting witness updating periods according to the number of witness, wherein each period is divided into a plurality of block generation period sections, and each block generation period section is allocated with a unique witness;
2.2, sequencing each period in turn, wherein only the witness to which the period belongs has the authority to generate blocks;
2.3 all witnesses generate blocks in the period of each witness according to the turn in sequence, record the turn of generating the blocks, and update the system to the period of the next turn after the generated blocks are broadcasted;
(3) and verifying and confirming the generated block and writing the block into a database to finish the block output, wherein the specific implementation process is as follows:
3.1 the witness broadcasts the block information and the turns thereof to other witnesses;
3.2 after the witness receives the block information and the turns of the block, the witness verifies the block information, signs after the verification is successful, generates first verification information and sends the first verification information to other witnesses, and meanwhile receives the first verification information sent by other witnesses;
3.3 when the witness holds the number of the first verification information containing the same block information, which is more than or equal to 2m, generating second verification information by the first verification information and sending the second verification information to other witnesses, wherein m is a natural number more than 0;
3.4 when any witness in the block chain verifies that the number of second verification information which contains the same block information and is held by the witness exceeds 2m +1, the block information is written into the database, and a new block is generated by broadcasting confirmation and awarding is obtained.
2. The method of claim 1, wherein: the voting contract also comprises a quality deposit mechanism, namely a certain amount of quality deposit needs to be paid before the node participates in the voting, if malicious voting occurs in the voting process, the system will not accept the quality deposit of the node, and the malicious voting is recorded on the chain, so as to ensure the safety and justice of the whole voting.
3. The method of claim 1, wherein: the reference time is an initial unified determined time set by the voting contract.
4. The method of claim 1, wherein: if the corresponding round of the block received by the witness in the step 3.2 is not consistent with the round of the period segment of the currently generated block, discarding the block; and if the verification information is consistent with the verification information, generating first verification information and sending the first verification information to other witnesses.
5. The method of claim 1, wherein: in the step 3.3, when the number of the first verification information containing the same block information held by the witness is less than 2m, the witness has no authority to send the second verification information; and 3.4, if the number of the second verification information containing the same block information held by the witness is less than 2m +1, determining that no new block is generated.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910196533.4A CN109951474B (en) | 2019-03-15 | 2019-03-15 | Method for realizing block chain common identification block |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910196533.4A CN109951474B (en) | 2019-03-15 | 2019-03-15 | Method for realizing block chain common identification block |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109951474A CN109951474A (en) | 2019-06-28 |
| CN109951474B true CN109951474B (en) | 2021-07-30 |
Family
ID=67010050
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910196533.4A Active CN109951474B (en) | 2019-03-15 | 2019-03-15 | Method for realizing block chain common identification block |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109951474B (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110659901B (en) * | 2019-09-03 | 2022-06-17 | 北京航空航天大学 | Game model-based block chain complex transaction verification method and device |
| CN110610421B (en) * | 2019-09-03 | 2022-03-25 | 北京航空航天大学 | Guarantee fund management method and device under fragment framework |
| CN110838947B (en) * | 2019-11-21 | 2021-04-23 | 桂林电子科技大学 | Multi-block output common chain consensus mechanism based on H-Algorand |
| CN111131209B (en) * | 2019-12-16 | 2022-06-28 | 国网重庆市电力公司客户服务中心 | Improved efficient consensus method, system, computer device and storage medium |
| CN111311414B (en) * | 2020-02-27 | 2023-12-08 | 杭州云象网络技术有限公司 | Block chain multiparty consensus method based on consistent hash algorithm |
| CN111555890A (en) * | 2020-05-06 | 2020-08-18 | 昆明大棒客科技有限公司 | Method, device and equipment for preventing malicious bifurcation |
| CN111598569B (en) * | 2020-05-21 | 2023-09-08 | 昆明大棒客科技有限公司 | Tree block chain expansion method and device |
| CN112184439B (en) * | 2020-09-28 | 2024-06-18 | 北京八分量信息科技有限公司 | De-centralized transaction method and device based on node ordering and related products |
| CN112541758A (en) * | 2020-12-01 | 2021-03-23 | 鲁静 | Multi-round voting type fault-tolerant sequencing consensus mechanism and method based on block chain |
| CN112600682B (en) * | 2020-12-09 | 2022-01-18 | 四川大学 | Block chain consensus method and device based on delegation interest certification algorithm |
| CN113065960A (en) * | 2021-03-22 | 2021-07-02 | 江苏派智信息科技有限公司 | Transaction system based on block chain |
| CN112950380B (en) * | 2021-03-29 | 2022-10-21 | 中国建设银行股份有限公司 | Block chain-based transaction consistency processing method and device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107341660A (en) * | 2017-05-27 | 2017-11-10 | 唐盛（北京）物联技术有限公司 | A kind of block chain bottom common recognition mechanism and the block catenary system based on the common recognition mechanism |
| CN109039713A (en) * | 2018-07-16 | 2018-12-18 | 夸克链科技（深圳）有限公司 | A kind of block chain common recognition device and algorithm |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180331832A1 (en) * | 2015-11-05 | 2018-11-15 | Allen Pulsifer | Cryptographic Transactions System |
| CN108492103B (en) * | 2018-02-07 | 2021-04-27 | 北京大学深圳研究生院 | Joint block chain consensus method |
| CN108923929B (en) * | 2018-06-05 | 2021-07-23 | 上海和数软件有限公司 | Block link point consensus method, device and computer readable storage medium |
-
2019
- 2019-03-15 CN CN201910196533.4A patent/CN109951474B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107341660A (en) * | 2017-05-27 | 2017-11-10 | 唐盛（北京）物联技术有限公司 | A kind of block chain bottom common recognition mechanism and the block catenary system based on the common recognition mechanism |
| CN109039713A (en) * | 2018-07-16 | 2018-12-18 | 夸克链科技（深圳）有限公司 | A kind of block chain common recognition device and algorithm |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109951474A (en) | 2019-06-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109951474B (en) | Method for realizing block chain common identification block | |
| Zhou et al. | Solutions to scalability of blockchain: A survey | |
| CN108717630B (en) | Block output method and implementation system thereof | |
| CN109150972B (en) | Working method of consensus mechanism of double-layer partitioned efficient block chain | |
| CN109842606B (en) | Block chain consensus algorithm and system based on consistent Hash algorithm | |
| ES2837476T3 (en) | Methods and apparatus for a distributed database within a network | |
| CN110351133A (en) | Method and device for the host node hand-off process in block catenary system | |
| US20210266163A1 (en) | Blockchain hybrid consensus-based system for maintaining domain name information | |
| CN107464106A (en) | The method and system merchandised between block chain main chain and side chain | |
| CN111988137B (en) | DPoS (dual port service) consensus method and system based on threshold signature and fair reward | |
| CN111164626A (en) | Intelligent contract execution using distributed coordination | |
| CN110945548A (en) | Computer-implemented system and method for managing large distributed storage pools in a blockchain network | |
| CN112104482B (en) | Consensus method based on parallel voting | |
| CN110855432B (en) | Asynchronous BFT & DPOS consensus mechanism for assigning verifier rewards based on verifiable random functions | |
| CN110298754B (en) | Consensus method applied to block chain | |
| CN110445795B (en) | Block chain authentication uniqueness confirmation method | |
| CN113626875B (en) | Knowledge graph file storage method for block chain fragment enabling | |
| Nguyen et al. | Lachesis: Scalable asynchronous BFT on DAG streams | |
| TWM586416U (en) | Implementing a multi-center, distributed verification system for transactions based on blockchain technology | |
| Decker | On the scalability and security of bitcoin | |
| CN114172661B (en) | Bidirectional cross-link method, system and device for digital asset | |
| Takahashi | Proof-of-approval: A distributed consensus protocol for blockchains | |
| CN112860807A (en) | Fault-tolerant consensus method suitable for wireless block chain network | |
| Snow et al. | Factom ledger by consensus | |
| KR20210127231A (en) | Energized Identity based blockchain |
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 |