CN108173658B - Block chain consistency maintenance method and device - Google Patents

Block chain consistency maintenance method and device Download PDF

Info

Publication number
CN108173658B
CN108173658B CN201711171256.9A CN201711171256A CN108173658B CN 108173658 B CN108173658 B CN 108173658B CN 201711171256 A CN201711171256 A CN 201711171256A CN 108173658 B CN108173658 B CN 108173658B
Authority
CN
China
Prior art keywords
block
voting
block chain
meets
verification
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
Application number
CN201711171256.9A
Other languages
Chinese (zh)
Other versions
CN108173658A (en
Inventor
吴腾
周琳琳
黄锴
孔宁
李晓东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Internet Network Information Center
Original Assignee
China Internet Network Information Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Internet Network Information Center filed Critical China Internet Network Information Center
Priority to CN201711171256.9A priority Critical patent/CN108173658B/en
Publication of CN108173658A publication Critical patent/CN108173658A/en
Application granted granted Critical
Publication of CN108173658B publication Critical patent/CN108173658B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30Decision processes by autonomous network management units using voting and bidding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9015Buffering arrangements for supporting a linked list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a block chain consistency maintenance method and device. The method comprises the following steps: for each node Pi in the decentralized system; when a node Pi receives a new block, verifying whether the block meets the workload, if so, voting and broadcasting each to-be-completed state transition in the block, and then verifying whether the to-be-completed state transition meets the validity verification, if the to-be-completed state transition in the block meets the validity verification, and the block length of the block is greater than that of a local block chain, adding the block as a new block into the current block chain. According to the invention, a new verification layer is introduced on the block chain, the block is generated by the bottom layer block chain, the verification of the block is completed by the verification layer, and the state change of the block chain is required to be approved by the verification layer, so that the decentralized application based on the block chain has state verification.

Description

Block chain consistency maintenance method and device
Technical Field
The invention relates to a block chain consistency maintenance method and device, and belongs to the technical field of network communication.
Background
Blockchains maintain a common general ledger in an unreliable distributed environment, maintained and extended by a series of anonymous participants. In recent years, blockchain networks have attracted more and more attention from engineers, scholars and investors. With significant capital investment, blockchains are rapidly deployed and have become a common infrastructure.
Since the blockchain has no trusted central node, it makes it practical to design and implement decentralized domain name systems, public key certificate systems and decentralized file storage.
However, in the current application based on the blockchain, global consistency needs to be maintained in an insecure distributed environment, each specific operation involves state transition, but at present, the blockchain technology does not provide validity verification of state transition, so that consistency maintenance of the blockchain cannot be realized, which may lead to various problems:
1) taking a decentralized domain name system as an example, when domain name registration conflicts, that is, an authority and an individual simultaneously apply for an authority domain name, the attribution problem of the authority domain name is determined by a single node obtaining a block writing opportunity, and once the single node makes a mistake, the authority domain name is registered by the individual and cannot be changed.
2) In a decentralized file storage system, once resources with copyright problems or not meeting regulations are uploaded successfully, other people except the uploader can hardly delete the resources. For a widely operating P2P network, a crawler network is usually deployed on the network to detect paths of illegal resources and add the paths into a blacklist, so as to achieve the purpose of protecting the network. The crawler software can only detect which resources are illegal, but cannot prevent the uploading of the resources, and the introduction of a detection method of a third party brings more problems.
Therefore, how to implement consistency maintenance of the block chain is a technical problem to be solved urgently at present.
Disclosure of Invention
The root of the technical problem in the prior art is that only proof of correct workload needs to be provided when the blockchain is written, and validity verification is not performed on state transition of the blockchain, so the invention provides a method and a device for maintaining consistency of the blockchain with state validity verification.
The blockchain protocol can achieve global consistency without relying on a central trusted node. Miners in the blockchain perform a hash algorithm based on a mathematical puzzle to verify the legitimacy of the generated blocks.
The invention introduces a new verification layer on the block chain, the block is generated by the bottom layer block chain, and the verification of the block is completed by the verification layer. The state change of the block chain needs to pass the agreement of the verification layer.
The blockchain protocol with state validity verification provides a new management idea for a series of upper-layer applications based on blockchains, such as suspicious transaction supervision of bitcoin based on blockchains, domain name rush-injection of a decentralized domain name system and resource uploading management of the decentralized file system, and ensures that each state conversion is verified.
The invention considers the whole decentralized system as n nodes which are independently configured, namely { p1,p2,...,pnAnd f, forming a decentralized system. One implementation can be thought of as a series of states and transitions: pi0,s01,s1,...,πi,si,...。
From state pi0To state pi1Passing through an intermediate state s0Each state transition corresponding to a monotonically increasing timestamp, ri<ri+1Wherein r isiIs an integer multiple of a time increment interval dr and a time stamp is called a round (round). Each node can only execute a compute instruction once per round. It is assumed that the computational power of each node for a random function oracle is given, i.e. each node calls the oracle function only once per round.
Messages are communicated between anonymous nodes through a broadcast (m) instruction. The maximum delay per message is Δ, and if the message is broadcast at time r, then each node executes the receive (m) instruction for no more than r + Δ.
Any one of the state transitions needs to satisfy the following condition:
1) state transitions are agreed upon by all nodes in the Quorum
One state transition needs to go through two stages, from state pi0To state pi1Passing through an intermediate state s0When is coming into contact withAfter a node issues a state transition message, the node receiving the message starts to broadcast the voting result of the node to the state transition, and simultaneously the node starts to collect the voting result messages of other nodes, if a Quorum (Quorum) set exists and the nodes in the set exceeding a set proportion agree, the network can be converted to the state pi1. The nodes in the set can refer to all nodes, or can be selected representative nodes, and the messages received by each voting node are the same.
2) Uncertainty
The blockchain protocol uses a published, quickly verifiable puzzle. Each process executes a coinflip instruction to generate a random number
Figure GDA0002190822900000021
H: [0,1) → [0,1) is a random one-way hash function. Process piThe voting result of one intermediate state is also random, the probability of approval is p ', then the voting result of one intermediate state d is Binom (k, n, p '), and the probability of completion of conversion is Binom (k, n, p ')
Figure GDA0002190822900000022
3) Byzantine error
There are f error processes, these byzantine error nodes can collude to send error messages to other normal nodes. The byzantine error process opposes the normal process, which may favor the byzantine process. The probability of the proposed scheme passing through the normal process is
Figure GDA0002190822900000031
The probability that the scheme proposed by the Byzantine error procedure can pass is
Figure GDA0002190822900000032
The technical scheme of the invention is as follows:
a block chain consistency maintenance method is characterized in that for each node Pi in a decentralized system, when the node Pi receives a new block, whether the block meets workload is verified, if yes, voting broadcasting is carried out on each to-be-completed state transition in the block, whether the block meets validity verification is verified by using the voting result of the received voting broadcasting, if all to-be-completed state transitions in the block meet validity verification, and the block length of the block is larger than that of a local block chain, the block is taken as a new block to be added into the current block chain; wherein the content of the first and second substances,
the method for judging whether the verification block meets the validity verification comprises the following steps: receiving the voting result fed back by other nodes to the voting broadcast, counting the received voting result, and if the counting result meets the set condition, passing the verification.
Further, the method for verifying whether the block meets the workload comprises: and calculating the solution nonces of the block chain workload proof problem, and verifying whether the block meets the workload proof according to the solution nonces.
Furthermore, a coinflip process is called to obtain the solution nonces of the block chain workload proving difficult problem.
Further, the error node ratio f in the decentralized system is less than or equal to 0.38 n; wherein n is the total number of state transitions to be completed.
Further, the node in the decentralized system has a probability of passing a state transition of at least 0.75.
Furthermore, a Quorum set of the Quorum is set in the decentralized system, and when the number of the agreed nodes in the Quorum set of the Quorum voting results reaches or exceeds half of the total number of the nodes in the Quorum set of the Quorum, the statistical results are regarded as meeting the set conditions, namely the verification is passed.
Further, the decentralized system is a decentralized domain name system, a public key certificate system or a decentralized file storage system.
A block chain consistency maintenance device is characterized by comprising a received block message processing module, a calculation process processing module, a vote broadcast module and a received vote message processing module, wherein the received block message processing module is used for calling the calculation process processing module to verify whether a block meets workload when a node receives a new block, if yes, voting broadcast is carried out on each to-be-completed state transition in the block, the received vote message processing module is called to verify whether the to-be-completed state transition meets validity verification, and if the to-be-completed state transition in the block meets validity verification and the block length of the block is larger than that of a local block chain, the block is taken as a new block to be added into a current block chain; and the received voting message processing module is used for receiving the voting result fed back by other nodes to the voting broadcast, counting the received voting result, and if the counting result meets the set condition, the verification is passed.
Further, the execution calculation process processing module is configured to calculate a solution nonce of the block chain workload proof puzzle, and verify whether the block satisfies the workload proof according to the solution nonce.
Further, the node has a probability of passing for a state transition of at least 0.75.
The process of the invention is shown in fig. 1, and the content is as follows:
each node Pi simultaneously performs the receive block message on receive, the receive vote message on receive _ op and the compute on compute process.
Receive block message on receive process when a new block is received, invoke the on computer process to verify whether the block meets the workload, execute the on receive _ op process for each to-be-completed state transition in the block, verify whether it meets the validity verification. If the above conditions are satisfied and the block length of the block is greater than the length of the local blockchain, then the block is added as a new block to the current blockchain.
For the intermediate state in the newly added block in the difference set with the original block chain, the voting broadcast is performed on the state transition.
And the received voting message on receive _ op process counts the received votes, if the number of the votes exceeds half, success is returned, and otherwise failure is returned.
And executing the calculation on computer process to execute the mining process, calling the coinflip process (namely the mining process) to obtain the solution nonces of the block chain workload proving difficulty, calling the onreceive _ op process for the received to-be-completed state conversion request, and modifying the state of the onreceive _ op process if the onreceive _ op process returns success. The on computer process is then invoked, broadcasting this block if the correct workload proof is met.
Proof of consistency
In n processes, there is f<n/2 error nodes, assuming that the probability that one process can solve a difficult problem is p, and the probability that one process approves a certain state transition is p', the probability that the normal process can complete the state transition is pc=(1-(1-p)n-f) U, u are as shown in condition 3) above. The error processes can be combined to solve the problem that the probability that one error process can be completed is converted into pfFpv, v is as shown in the above condition 3).
Through
Figure GDA0002190822900000045
The number of state transitions completed in the normal process after the round follows a binomial distribution:
the number of state transitions for which the error process is completed follows another binomial distribution:
Figure GDA0002190822900000042
when np > 5, n (1-p) > 5, fitting Binom (n, p) using Ν (np, np (1-p)) yields:
Figure GDA0002190822900000043
Figure GDA0002190822900000044
in the block chain protocol, each process only selects the longest chain, and the protocol needs to ensure
Blockc-Blockf>0
Figure GDA0002190822900000051
Whereas the following properties are distributed for a standard normal distribution:
prob=P{u-kσ<X<u+kσ}
when k is 3, prob is 99.73%, and when k is 4, prob is 99.99%.
If μ -k σ > 0, then when k is 4, there is 99.99% probability that Block is satisfiedc-Blockf>0
To make it possible to
Figure GDA0002190822900000052
Is established, needs to satisfy
Figure GDA0002190822900000053
When k is 4, when
Figure GDA0002190822900000054
When the above values are taken, there is a probability of 99.99% that the final consistency can be achieved. The terminability of the algorithm is as follows
Figure GDA0002190822900000055
And (6) determining. Thus, the final consistency of Monte Carlo is verified.
Parameter discussion
It is easy to see that, when the faulty node ratio f is larger,
Figure GDA0002190822900000056
the larger, i.e., the longer the protocol needs to run to ensure consistency.
Experiments have verified that the above protocol can be run at less time (i.e., in less time)
Figure GDA0002190822900000057
) Final consistency can be achieved, and relatively exact error section is calculated through experimental dataUpper limit of the number of dots.
1) Upper limit of error node proportion
Assuming that the scheme of the correct node and the error node is a rough probability pass, let p ≈ 1/n according to the formula:
Figure GDA0002190822900000058
when n is 1000, by adjusting f from n/4 to n/2-1, see fig. 2The condition of the error node proportion f is changed. When f is less than 0.39n, the protocol can achieve consistency in less time. When f is greater than 0.43n, the protocol can reach consistency in less time as well, but the consistency of the system is achieved by the error node at this time. Whereas at f between 0.38n and 0.43n the protocol needs to run for a long time.
The present invention needs to ensure that the conversion rate of the normal node is greater than that of the error node, which is a necessary condition for the system to correctly achieve the final consistency. p is a radical ofcAnd pfThe curve of the error node ratio f is shown in FIG. 3, and it can be seen that p is madec>pfF is less than 0.41 n.
Since the experiment assumes
Figure GDA00021908229000000510
Thus, FIG. 2 only has
Figure GDA00021908229000000511
And the part where f < 0.41n is valid, it is redrawn as shown in fig. 4. When f is 0.38n, the protocol can achieve consistency in a relatively small amount of time.
2) Selection of node voting pass probability
According to the previous experiment, f is 0.38n and is selected as a reasonable error node number. According to the previous formula:
Figure GDA0002190822900000061
Figure GDA0002190822900000062
with p' as an independent variable, u and v are plotted against it, as shown in FIG. 5. When p' > 0.75, u and v almost approach 1. Therefore, the above protocol can only operate efficiently when the node has a probability of passing a state transition of at least 0.75.
Compared with the prior art, the invention has the following positive effects:
1) according to the invention, a new verification layer is introduced on a block chain, a block is generated by a bottom layer block chain, the verification of the block is completed by the verification layer, and the state change of the block chain is required to be approved by the verification layer, so that the decentralized application based on the block chain has state verification;
2) the blockchain protocol with state validity verification provides a new management idea for a series of upper-layer applications based on blockchains, such as suspicious transaction supervision of bitcoin based on blockchains, domain name rush-injection of a decentralized domain name system and resource uploading management of the decentralized file system, and ensures that each state conversion is verified.
3) Only one-time information exchange between every two is needed, and the fault-tolerant rate of 38% can be realized.
Drawings
FIG. 1 is a flow chart of a method of the present invention;
FIG. 2 is a curve of the proportional variation of the number of execution rounds with the error node;
FIG. 3 is a graph of correct and erroneous state transition probabilities versus erroneous node ratio;
FIG. 4 is a graph of the number of execution rounds as a function of the error node ratio f (f < 0.38 n);
FIG. 5 is a graph of probability of passing votes for normal and erroneous nodes against probability of approval;
FIG. 6 is a domain name registration transaction broadcast to a blockchain;
fig. 7 is a flow chart of a node receiving a block and initiating a vote.
Detailed Description
In order to make the aforementioned and other features and advantages of the invention more comprehensible, embodiments accompanied with figures are described in detail below.
Based on the block chain method with the state validity verification, decentralized root area file management can be achieved.
The root server authority, which constitutes the blockchain, needs some policy support to select the blockchain nodes at system initialization, and can represent the opinion of most countries of the world. During system operation, a new root server authority can participate in the voting as long as it can provide the correct workload proof to produce a legal block. The honest root server administration participating in this blockchain network must accept the voting results of most nodes.
As shown in fig. 6. When a domain name applicant proposes a domain name registration application through domain name management client software, the registration application is sent to a block chain formed by root server management mechanisms, and then the block chain formed by the root server management mechanisms enables the current registration transaction to be in an unconfirmed intermediate state. The output of the transaction is set to the nulldata type, the registered domain name and registrar information is embedded in the transaction, the transaction is then signed by a key provided by the registered user, and the transaction is then broadcast to other root server authorities to begin the process of mining.
The method comprises the following steps that while the root server management mechanisms always execute a mining process, transaction broadcast messages from domain name management client software are received, and each root server management mechanism executes the following processes:
1) determining whether to add the registration transaction of the intermediate state into the block according to the strategy of the user;
2) and acquiring more than half of domain name modification requests in the previous round of voting, setting the domain name modification requests to be in a final state, and adding the final state into the current block.
When the node solves the workload proving problem, the block is then broadcast to the blockchain network. As shown in fig. 7, the other root server administrator verifies the workload proof, resolves the domain name modification request, and performs the following processes:
1) if the domain name registration is in the intermediate state, broadcasting a voting result aiming at the domain name registration to other nodes, rejecting the domain name registration and waiting for a subsequent block;
2) if the domain name is registered to be in a final state, verifying the voting result of other locally received nodes, and if the voting result exceeds half of the voting result, adding the voting result into a local block chain; otherwise, the request is denied.
After the block containing the registration request is confirmed by 6 blocks, the management organization solving the workload proving difficulty is authorized to modify the zone file in the DNS resolution system, thereby completing the domain name registration.
The above embodiments are only for illustrating the technical solution of the present invention and not for limiting the same, and a person skilled in the art can make modifications or equivalent substitutions to the technical solution of the present invention without departing from the spirit and scope of the present invention, and the scope of the present invention should be determined by the claims.

Claims (8)

1. A block chain consistency maintenance method is characterized in that for each node Pi in a decentralized system, when the node Pi receives a new block, whether the block meets workload is verified, if yes, voting broadcasting is carried out on each to-be-completed state transition in the block, whether the block meets validity verification is verified by using the voting result of the received voting broadcasting, if all to-be-completed state transitions in the block meet validity verification, and the block length of the block is larger than that of a local block chain, the block is taken as a new block to be added into the current block chain; wherein the content of the first and second substances,
the method for judging whether the verification block meets the validity verification comprises the following steps: receiving the voting result fed back by other nodes to the voting broadcast, counting the received voting result, and if the counting result meets the set condition, passing the verification;
the method for verifying whether the block meets the workload comprises the following steps: and calculating the solution nonces of the block chain workload proof problem, and verifying whether the block meets the workload proof according to the solution nonces.
2. The method of claim 1, wherein invoking the coinflip process results in a solution nonce for the blockchain workload proof puzzle.
3. A method according to claim 1 or 2, characterized in that the proportion f of faulty nodes in the decentralized system is less than or equal to 0.38 n; wherein n is the total number of state transitions to be completed.
4. A method according to claim 1 or 2, wherein the node in the decentralized system has a probability of passing a state transition of at least 0.75.
5. The method of claim 1, wherein a Quorum set of the Quorum is set in the decentralized system, and when the number of the agreed nodes in the Quorum set of the Quorum voting results reaches or exceeds half of the total number of the nodes in the Quorum set of the Quorum, the statistical result is considered to satisfy the set condition, namely the authentication is passed.
6. The method of claim 1, wherein the decentralized system is a decentralized domain name system, a public key certificate authority, or a decentralized file storage system.
7. A block chain consistency maintenance device is characterized by comprising a received block message processing module, a calculation process processing module, a vote broadcast module and a received vote message processing module, wherein the received block message processing module is used for calling the calculation process processing module to verify whether a block meets workload when a node receives a new block, if yes, voting broadcast is carried out on each to-be-completed state transition in the block, the received vote message processing module is called to verify whether the to-be-completed state transition meets validity verification, and if the to-be-completed state transition in the block meets validity verification and the block length of the block is larger than that of a local block chain, the block is taken as a new block to be added into a current block chain; the received voting message processing module is used for receiving the voting results fed back by other nodes to the voting broadcast, counting the received voting results, and if the counting results meet the set conditions, the verification is passed; and the execution calculation process processing module is used for calculating the solution nonce of the block chain workload certification puzzle, and verifying whether the block meets the workload certification or not according to the solution nonce.
8. The apparatus of claim 7, wherein the node has a probability of passing for a state transition of at least 0.75.
CN201711171256.9A 2017-11-22 2017-11-22 Block chain consistency maintenance method and device Active CN108173658B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711171256.9A CN108173658B (en) 2017-11-22 2017-11-22 Block chain consistency maintenance method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711171256.9A CN108173658B (en) 2017-11-22 2017-11-22 Block chain consistency maintenance method and device

Publications (2)

Publication Number Publication Date
CN108173658A CN108173658A (en) 2018-06-15
CN108173658B true CN108173658B (en) 2020-01-21

Family

ID=62527297

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711171256.9A Active CN108173658B (en) 2017-11-22 2017-11-22 Block chain consistency maintenance method and device

Country Status (1)

Country Link
CN (1) CN108173658B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020042933A1 (en) * 2018-08-28 2020-03-05 白杰 Blockchain network access method and system
WO2020042927A1 (en) * 2018-08-28 2020-03-05 白杰 Blockchain public chain
CN109409749A (en) * 2018-10-30 2019-03-01 四川长虹电器股份有限公司 A kind of IT assets management method based on block chain

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106447311A (en) * 2016-09-26 2017-02-22 北京天德科技有限公司 Block chain block building method for Byzantine fault tolerant algorithm of quartic communication
CN106651332A (en) * 2016-12-29 2017-05-10 先锋支付有限公司 Block chain and method for generating new block in block chain
CN106878071A (en) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 A kind of block chain common recognition mechanism based on Raft algorithms
WO2017109140A1 (en) * 2015-12-22 2017-06-29 Bigchaindb Gmbh Decentralized, tamper-resistant, asset-oriented database system and method of recording a transaction

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10713654B2 (en) * 2016-01-21 2020-07-14 International Business Machines Corporation Enterprise blockchains and transactional systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017109140A1 (en) * 2015-12-22 2017-06-29 Bigchaindb Gmbh Decentralized, tamper-resistant, asset-oriented database system and method of recording a transaction
CN106447311A (en) * 2016-09-26 2017-02-22 北京天德科技有限公司 Block chain block building method for Byzantine fault tolerant algorithm of quartic communication
CN106651332A (en) * 2016-12-29 2017-05-10 先锋支付有限公司 Block chain and method for generating new block in block chain
CN106878071A (en) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 A kind of block chain common recognition mechanism based on Raft algorithms

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
. "HQ replication: A hybrid quorum protocol for Byzantine fault tolerance";Cowling, James, et al.;《Proceedings of the 7th symposium on Operating systems design and implementation. USENIX Association》;20061231;第177-190页 *
"基于动态授权的拜占庭容错共识算法的区块链性能改进研究";刘肖飞;《万方数据在线出版》;20170926;正文第35-44页 *

Also Published As

Publication number Publication date
CN108173658A (en) 2018-06-15

Similar Documents

Publication Publication Date Title
EP3281115B1 (en) Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
US11128522B2 (en) Changing a master node in a blockchain system
US10581615B2 (en) Blockchain-based identity authentication method, device, node and system
CN112055025B (en) Privacy data protection method based on block chain
CN113194469B (en) 5G unmanned aerial vehicle cross-domain identity authentication method, system and terminal based on block chain
WO2018112947A1 (en) Block of blockchain generation method, device, node, and signature device and system
US11296873B2 (en) Methods and systems to establish trusted peer-to-peer communications between nodes in a blockchain network
CN110999204A (en) Method and system for block chain implemented event lock encryption
CN115001706A (en) Consensus based on secure blockchains
CN108769230B (en) Transaction data storage method, device, server and storage medium
CN112583596B (en) Complete cross-domain identity authentication method based on block chain technology
CN108173658B (en) Block chain consistency maintenance method and device
WO2019004480A1 (en) Consensus-forming method in network, and node for configuring network
CN112152778B (en) Node management method and device and electronic equipment
CN109685505B (en) Byzantine fault-tolerant consensus optimization method based on association ring signature
KR20200081533A (en) Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment
CN115378604A (en) Identity authentication method of edge computing terminal equipment based on credit value mechanism
Le et al. A lightweight block validation method for resource-constrained iot devices in blockchain-based applications
CN114463009B (en) Method for improving transaction security of large-scale energy nodes
CN113010872A (en) Identity authentication method and device, computer equipment and storage medium
CN110990790B (en) Data processing method and equipment
CN115174570A (en) Cross-chain consensus method and system based on dynamic committee
CN112039837B (en) Electronic evidence preservation method based on block chain and secret sharing
Liu et al. A blockchain-based cross-domain authentication management system for IoT devices
Chen et al. Threshold identity authentication signature: Impersonation prevention in social network services

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