Patent Application
20200059369
The present disclosure relates generally to communication network and more particularly to determining consensus by Parallel Proof of Voting (PPoV) in a consortium blockchain.
After years of development through the Internet, the domain name system has become an important part of the Internet. The domain name system also has real world implications on issues such as censorship, domain name confiscation, and user privacy.
The domain name system for the Internet is sometimes referred to as the Internet Domain Name System (INDS). INDS serves as a distributed database that maps domain names and IP addresses and vice versa, making it easier for users to access the Internet. The primary role of a domain name system is resolving domain names, for example, mapping a human-friendly (e.g., human-readable) name of a computer or a group of computers on the Internet into a corresponding machine-readable IP address. A domain name system may be a distributed hierarchical system that includes a root domain; the next level under the root domain is called the top-level domain. For example, the top-level domain for the country of the People's Republic of China is “.cn.”
Various technical challenges exit, however. For example, the current domain name system is a fully centralized system. The domain name root servers are managed by the Internet Corporation for Assigned Names and Numbers (ICANN) authorized by the United States. In order to improve the efficiency of domain name resolution, ICANN has deployed many root servers and mirror servers globally; the world's only primary root server is located in the United States.
The centralized control of the domain name system has also resulted in various technical difficulties and communication outages. The failure of the top-level domain name server in Iraq and the failure of the top-level domain name server in Libya are typical examples of such outages. Due to the lack of control over the root domain name server and the vulnerability of the domain name system itself, security risks are also present.
A decentralized domain name system may reduce or eliminate these technical problems.
The present disclosure provides systems and methods for determining consensus by Parallel Proof of Voting (PPoV) in a consortium blockchain to address the technical problems described in the present disclosure.
In some implementations, a method for determining consensus in a decentralized domain name system, comprising:
A. using blockchain technology to form a consortium blockchain network of a plurality of domain network nodes and select a plurality of committee members from domain network nodes included in top-level domain to generate;
B. in the consortium blockchain network, requesting a committee member who receives most votes from other consortium members to pack a genesis block of the consortium blockchain and to generate a first random number. The first random number is used to select a housekeeper to pack a next block;
C. requesting, among all on-duty housekeepers in a duty cycle, a housekeeper that is assigned a same number as the first random number to pack a current block and to generate a second random number. The second random number is used to select a second housekeeper to pack a second next block; each block must be verified and signed by more than half of the committee members before it can be added to the consortium blockchain network;
D. requesting, during the duty cycle, each housekeeper in a plurality of housekeepers to take turns packing blocks and generating random numbers, which may include: when a block is not approved by more than half of the committee members or when the block is not successfully packed within a predefined time period, requesting a subsequent house keeper in the plurality of housekeepers repack the block;
E. selecting, based on the last random number generated by a housekeeper before the duty cycle ends, a third next housekeep to pack a first block of a next duty cycle, and repeating Step C to Step E. Information identifying all housekeepers assigned to each duty cycle is packed into the first block of each cycle.
In some implementations, the method further comprises: requesting a new node applying to become a committee member in the consortium blockchain to go through the committee's new member approval process; determining that more than 51% of the committee members approve the node's application; responsive to the determining, admitting the new applicant as a new committee member of the top-level domain committee.
In some implementations, the method further comprises admitting a node in the consortium blockchain to become a housekeeper, including:
determining that the node is recommended by a committee member and is applying to become a housekeeper candidate;
selecting a predefined number of housekeepers from all housekeeper candidates in accordance with votes on each housekeeper candidate by committee members.
In some implementations, all committee members may have a first dual status as a committee member and a housekeeper or a second dual status as a committee member and a housekeeper candidate.
In some implementations, regular nodes, in the consortium blockchain network, are capable of joining or exiting the consortium blockchain network at any time, discarding messages, forging messages, and ceasing working. Additionally, regular nodes are not allowed to participate in block generation, but only block distribution and sharing, as well as consuming services provided by the consortium blockchain network.
In some implementations, the method further comprises admitting a node in the consortium blockchain to become a housekeeper candidate. The admission process includes: (1) determining that the node has registered a user account in the decentralized domain name system and submitted a housekeeper candidate application; (2) determining that the node has submitted a letter of recommendation signed by at least one member of the domain name committee; and (3) determining that the node has been approved by more than half of the committee members and has submitted a deposit, admitting the node to become a housekeeper candidate,
In some implementations, the method further comprises F. requesting the top-level domain name committee members to vote and score all housekeeper candidates after each duty cycle.
In some implementations, a vote is either a default vote of confidence or a designated vote of confidence.
In some implementations, the method further comprises G. requesting committee members to determine whether or not each housekeeper is working and completing tasks timely when they are on duty.
When so, causing the committee to return the deposit when a housekeeper voluntary withdraws. When not so, deeming the housekeeper as having not signed a block as agreed or misbehaved, and causing the committee to do one or more of: dismissing the housekeeper, withhold the deposit submitted by the house keep, blacklisting the housekeeper, and preventing the housekeep from ever becoming a housekeep again.
In some implementations, when a housekeeper's misbehavior is observed by a committee member, the housekeeper will be immediately reported, with more than one-third of the committee members agree to deprive the node's housekeeper status, the node's deposit will be forfeited and the node will be relegated to an ordinary account.
When the housekeeper's misbehavior is determined as having a predefined severity, with approval of two-thirds of the committee members, the node will be added to a blacklist, its account will be canceled, and the node will not be allowed to join the system.
The committee members who wrote the recommendation letters for the blacklisted housekeeper will be voted again by the committee to determine whether they can retain their membership.
The implementations disclosed herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. Like reference numerals refer to corresponding parts throughout the drawings.
The blockchain technology was first proposed by Nakamoto Satoshi in 2008. It is a relatively new distributed technology and has excellent prospects in future applications. Bitcoin-derived blockchain is an intelligent Peer-to-Peer (P2P) network that uses distributed databases to process, transmit, and store data. A blockchain includes a series of data blocks generated using cryptographic methods. Each data block stores data concerning a number of Bitcoin network transactions, which may be used to verify the validity of the transactions (anti-counterfeiting) and to generate the next data block. The consensus mechanism of the blockchain includes a mathematical algorithm for building trust and assigning rights between different nodes in a blockchain system. Example consensus mechanisms used in the blockchain include the proof-of-work mechanism and the proof-of-stake mechanism. Both methods have their own pros and cons and have been widely used in blockchain applications.
The application of blockchain technology to a domain name system is relatively new. Example applications include Namecoin and Blockstack. Currently, similar technology has not been applied in China.
Namecoin was first proposed by bitdns. Dissatisfied with the current centralized Domain Name System (DNS), Namecoin attempts to establish a distributed domain name system using blockchain. Namecoin uses a separate blockchain that is independent from the blockchain associated with the Bitcoin.
Blockstack is a blockchain-based naming and storage system. It is a new system that has been transplanted from the Namecoin network to the Bitcoin network. Domain name resolution is also one of the functions of a Blockstack system.
These two applications are different due to their underlying blockchains. Although Namecoin rebuilds a blockchain, the consensus method implemented by Namecoin is the same as that of the Bitcoin—the proof-of-work mechanism. On the other hand, Blockstack is built directly on Bitcoin's blockchain and does not have its own blockchain. Blockstack also uses the proof-of-work mechanism to determine consensus. The proof-of-work function used in the Bitcoin system is SHA256. SHA is the abbreviation for Secure Hash Algorithm. SHA includes a family of cryptographic hash functions, which was designed by the National Security Agency (NSA) and released by the National Institute of Standards and Technology (NIST). SHA has been mainly applied to creating and verifying digital signatures. SHA256 is a hash algorithm within this family and has an output value of 256-bit. So far, there has been no effective attack on the SHA256 algorithm. Existing blockchain-based domain name systems have produced slow growths, because they are based on a fully decentralized proof-of-work consensus, small in size, and have refused maintenance by any professional organizations.
Blockstack is a blockchain-based naming and storage system built by San Francisco-based blockchain startups. Blockstack's underlying blockchain is the Bitcoin's blockchain and thus also implements the proof-of-work mechanism for determining consensus.
Bitcoin's blockchain is collaboratively maintained by anonymous nodes on a computer network. Proof is required that that enough work has been done when each block is generated. This ensures untrustworthy nodes attempting to tamper with the historical data stored in a block do more work than trustworthy nodes which merely add one or more new blocks to the blockchain. Chaining the blocks together makes it impossible to modify a previous transaction without modifying all subsequent transactions. As new blocks are added to a blockchain, therefore, the cost of modifying transaction records in a block increases. The longest blockchain on the Internet is the main chain. Unless the attacker's computing power exceeds 50% of the total computing power of all nodes on the main chain, the attacker will be unable to alter a block or to create a longer chain to replace the main chain. In order to demonstrate the amount of work required to create a block, a mining node must compute a random number, so that the hash value of the block header does not exceed a predefined value set according to the difficulty.
A Bitcoin block includes a block header and a transaction list. The size of the block header may be 80 bytes, which may include: the hash value of the previous block, a random number, and the difficulty level of calculating the current hash value. The random number in the block header serves as input for verifying a Bitcoin's workload. SHA256 hash operations are performed by constantly changing the block header as input (e.g., changing different random numbers) to identify a specific random number so that the hash value satisfies the requirements. A satisfactory hash value consists of one or more leading zeros, the total number of which is determined based on the difficulty level of the network. After computing a hash value, a node packs (e.g., generates or creates) the block and broadcasts the newly generated block to other nodes. After verification, the other nodes will link themselves to the newly generated block. The block height increases, and then the nodes will start to work on the next block. The block height refers to the total number of blocks linked between the newly generated block and the very first block of the Bitcoin chain, which is also referred to as the genesis block or the number 0 block.
Different blocks may have the same height, e.g., when two or more miners try to create the same block at the same time. This is why a blockchain may split. The general consensus is that when two branches are of different heights, the higher (or longer) branch is always accepted; when two branches are of the same height, the branch with the greater difficulty level is accepted; and when two branches are of the same height and difficulty level, the branch that has been created earlier in time is accepted. If none of these conditions distinguishes, the two branches will be processed in the order of being accepted by the network. This process ensures that the blockchain is unique. Only when the attacker's computing power exceeds 50% of the entire network, the attacker can he control the blockchain, which is commonly referred to as a 51% attack.
The proof-of-work mechanism may, therefore, provide the following advantages: first, the decentralized design provides a good reference for developing a domain name system; second, relying on the strong computing power of the entire network, it has at least partially solved the 51% attack problem.
The proof-of-work mechanism also has certain drawbacks. First, few modifications have been made for applying the proof-of-work mechanism to a domain name system. The proof-of-work mechanism uses Bitcoin-related technologies, but does not address the potential issues unique to resolving domain names. Second, computing power may be wasted. Some studies have shown, conservatively, that the energy consumption rate by the current overall operation of Bitcoin has reached 3 GW, approximately the total amount of energy consumption by the country of Ireland. If the Bitcoin network continues to expand at its current pace, the total amount of energy consumption will equal to that of the country of Denmark in 2020. The development of Bitcoin technology may therefore appear to be environmentally un-friendly.
While most current systems for determining consensus in a domain name system implement the proof-of-work mechanism, the proof-of-stake mechanism may also be used to determine consensus in a blockchain network. Peercoin may be the first digital currency system implementing the proof-of-stake mechanism. In a Peercoin system, a coin's age is important, which is generally defined as the length of time a coin holder has been holding the coin. For example, Li Ming accumulates a coin age of 900-coin days after receiving 10 coins from Han Mei and holding them for 90 days. Here, the process for generating a block is a special transaction called an interest-paying transaction. In an interest-paying transaction, a block holder can consume his coin age for interest and at the same time obtain the priorities for generating a block in network and for invoking the proof-of-stake mechanism when generating the blocks. Each block generated may include a primary input and one or more equity inputs; the primary input needs to comply with a hash target protocol. The method here involves performing a random hash function in a limited space, instead of searching a hash value in an unlimited space similar to what happens in a Bitcoin system. This process thus does not consume a large amount of energy. The random hash target that the primary and equity need to meet are related to the coin age; thus, the more coin age the primary input consumes, the easier it is to meet the target protocol.
In these implementations, blocks are also randomly generated; thus, chain splitting is almost inevitable. Unlike Bitcoin's implementation, Peercoin selects the main blockchain based on coin age. Each transaction in a block submits its consumed coin age to the block to increase the block's score; the block with the greater consumed coin age is then added to the main chain.
The main advantages of this proof-of-stake mechanism are as follows: first, it consumes less energy and is thus more environment-friendly. Blocks are generated without consuming enormous computing power and maintaining the operation of such a network is also inexpensive; second, the decentralized design based on the stake provides a good reference for the further development of the domain name system.
The proof-of-stake mechanism also has certain drawback. First, this mechanism is not as related to and thus difficult to be applied to a domain name system. Second, the use of coin age as a factor may negatively affect the decentralization. The greater the coin age, the faster a block may be generated, and the higher chance the block is added to the main chain. As a result, block generation may become controlled by a small number of users who hold a large number of coins, negatively affecting the decentralization.
Consensus determination may be used to determine which computer is responsible for generating a block and for maintaining the consistency of a distributed ledger. Existing consensus determination mechanisms compete for the right to generate blocks based on the amount of computing power a node is equipped, leading to significant waste of energy, greater chance of chain splitting, and lower transaction per second, and lower throughput.
The present disclosure provides systems and methods for determining consensus in a decentralized domain name system, reducing or eliminating the above-identified technical problems.
An example method for determining consensus in a decentralized domain name system may comprise the following steps:
In some implementations, the method further comprises adding a new node to the committee as a new committee member, when more than 51% of the committee members approve the addition; the new node may join the top-level domain committee.
In some implementations, the method further comprises identifying a housekeeper in the consortium blockchain, which may comprise the following steps:
In some implementations, committee members may have the dual status as a committee member and a housekeeper or the dual status as a committee member and a housekeeper candidate.
In some implementations, in the consortium blockchain network, regular nodes may join or exit a network at any time, discard messages, forge messages, and stop working; regular nodes may not generate blocks; regular nodes may only participate in block distribution and sharing and enjoy the services provided by she consortium blockchain.
In some implementations, the method further comprises identifying a housekeeper candidate from domain nodes within the consortium blockchain, which may comprise the following steps:
In some implementations, the method further comprises:
In some implementations: the vote in Step F may be a default vote of confidence or a designated vote of confidence.
In some implementations, the method further comprises:
In some implementations, if a housekeeper's misbehavior is observed by a committee member, the housekeeper will be immediately reported. If more than one-third of the committee members vote to deprive the node's housekeeper status, the node's deposit will be forfeited and the node will be demoted to a regular account. If the housekeeper's misbehavior is deemed severe, with the approvals of two-thirds of the committee members, the node will be added to a blacklist, have its account canceled, and disallowed to join the system. Committee members who wrote a recommendation letter for a blacklisted housekeeper will be voted by the committee to determine whether they can retain their committee membership.
The systems and methods described in the present disclosure may provide one or more of the following technical advantages: the committee member nodes and the housekeeper nodes often have high credibility and high participation. A top-level domain name committee is introduced to decentralize the domain name systems and domain name institutions. Committee members conduct compliance supervisions on nodes and data within an entire network. The housekeepers verify the validity of the transactions and pack the valid transactions into a block. In addition to verifying the validity of the transactions, the committee members also review and decide whether the block containing the transactions may be added to the blockchain. This process also indicates whether the committee members approve the transactions, which may be used to ensure transaction compliance in the entire network.
Separating the decision-making entities from the execution entities makes the distribution of rights and responsibilities clear. Packed blocks are signed by specialized record-keeping housekeepers, which reduces the number of nodes needed for verification and record-keeping. This in turn increases the efficiency for consensus verification and reduces the cost of election and voting among domain name nodes. A consensus process may not require the participation of the entire network. The consensus process consumes significantly less power and is done with low overhead, resulting in higher system performance and efficiency.
Record-keeping (or ledgering) nodes are elected by trusted committee member nodes. Record-keeping is done though by the record-keeping nodes collaborating with each other. Each block needs to be verified and approved by more than half of the committee member nodes. Each block is final and does not split.
Fault tolerance wise, a network can continue operating, even when 50% of all committee members of the entire network have erred. The entire decentralized domain name system errs when more than half of the committee members are maliciously controlled, taken over, or malfunctioning at the same time. However, because each committee member node representing a professional organization in a different part of the world, it is almost impossible to have more than half of the committee members maliciously controlled, taken over, or malfunction at the same time.
The scoring process, the voting process, the rewards and penalties may constitute positive feedback, which will guide housekeepers in the network towards being honest, reliable and providing long-term online services. Rewards encourage nodes to compete for the housekeeper positions. The committee members' votes reflect their trust level of each housekeeper. The random assignment of numbers increases the liquidity of the housekeepers and prevents a single organization from continuously occupying as housekeeper role by controlling a large number of housekeeper candidates. The random assignment of numbers reduces the likelihood that a particular housekeeper is constantly elected, increasing the safety and reliability of the system.
With the development of blockchain technology, applications for a decentralized domain name system have emerged. However, a fully decentralized domain name system implementing existing consensus mechanisms also excludes ICANN, domain name registration agencies, and domain name registration companies, limiting the development of the decentralized domain name systems. It also hinders the transitioning of the domain name system from a centralized structure to a decentralized structure.
The systems and methods for determining consensus in a decentralized domain name system as described in the present disclosure focus on a decentralized computer system for resolving global domain names. The system may be formed and maintained by a group of professional organizations around the world. Separating the decision-making entities from the executions entities and adopting a collaborative record-keeping mechanism enable professional organizations to conduct compliance supervision of nodes and transaction data stored thereon within the entire network, smoothing the relationships between the supervision and management of professional organizations and the operation of a decentralized domain name system. After a decentralized domain name system generates a block, the consensus method requests transactions to be verified by more than 51% of the professional organizations in the network before being stored in a block. The 51% represents an agreement of a majority of the professional organizations in the network. Blocks are generated by specialized entities; each block is verified by 51% or more professional organizations, effectively avoiding blockchain splitting.
In a distributed system, multiple host nodes may form a network cluster. Since data are transmitted through asynchronous communications, it may be necessary to reach consensus among the host nodes. The blockchain architecture is a distributed architecture; all nodes within this peer-to-peer network adhere to a consensus mechanism and use the blockchain architecture to maintain a decentralized public ledger.
When determining consensus using technologies described in the present disclosure, each node may have a different role depending on the functions it is about to perform. As shown in
Members of the top-level domain committee, a coalition formed by professional organizations and industries around the world A region or an industrial agency can become a member of the committee as a legal entity. Each legal entity either desires to independently manage its own second-level domain names or expects to contribute and improve the management and implementation of committee protocol. But the common goals of the legal entities are forming a global peer-to-peer network while their second-level domain names are managed independently, jointly supervising and deciding the top-level domain name registration and domain name resolution and sharing distributed databases with nodes globally. Members have the right to recommend, vote, evaluate housekeepers, verify blocks, verify transactions, and supervise the operations of a domain name node. Committee members also have the responsibilities to maintain distributed shared databases and resolve domain names. Each member has the same rights and responsibilities, equal status. Any new member must be approved by the majority of the existing members.
Professional record-keeping—“housekeepers.” Housekeepers are entities that have been authorized to generate blocks; the number of housekeepers is limited. The implementation of the housekeeper status separates decision-making entities from execution entities. Regular nodes are not authorized to generate blocks, only housekeepers are. Blocks are generated by gathering and packing transaction information. Housekeepers are required to sign the blocks they pack. Housekeepers are elected from a list of housekeeper candidates by committee members through voting. The housekeepers randomly take turns to keep the record during the duty cycle. Housekeepers are re-selected by voting after each duty cycle ends. Members can have the dual status as a member and a housekeeper at the same time.
Record-keeping candidates—“housekeeper candidates.” Because the total number of housekeepers is limited, the housekeeper candidates that were not elected as housekeepers may retain their candidate status, maintain their online time, and wait for the next round of voting. To become a housekeeper candidate, an applicant must be recommended by a committee member and approved by more than half of the committee members. Members can have the dual status as a member and a housekeeper candidate.
Regular nodes. The three types of nodes identified above are considered trusted nodes, because they are verified through voting. Regular nodes are generally untrustworthy. The behavior of regular nodes can be unpredictable: regular nodes can join or exit network at any time; regular nodes may discard messages, forge messages, and stop working. Regular nodes may not participate in generating blocks; instead, regular nodes may only participate in block distribution and sharing. They can also execute domain name queries. The existence of a large number of regular nodes provides fast query abilities a domain name system. As shown in
The members of the top-level domain committee are similar to the members of the board of directors in a company. They may rate managers' executive skills, and collaboratively vote on managerial appointments, rewards, and penalties. The housekeeper nodes are similar to the managers in a company. They rely on their own professional competence to carry out tasks.
At step S1 (102), using blockchain technology to form consortium blockchain network among network nodes in a domain, and using network nodes in top-level domain to generate committee members; a coalition formed by professional organizations and industries around the world, a region or an industrial agency may become a member of the committee as a legal entity. Each legal entity either desires to independently manage its own second-level domain names or expects to research the managing and implementation of the technology and improve the protocol. But the common goals of the legal entities are forming a global peer-to-peer network while their second-level domain names are managed independently, jointly supervising and deciding the top-level domain name registration and domain name resolution and sharing distributed databases with nodes globally. Members have the right to recommend, vote, evaluate housekeepers and verify blocks, verify transactions and supervise domain name operations cooperatively. Members also have the responsibilities to maintain distributed shared databases and resolve domain names. Each member has the same rights and responsibilities, equal status. A new member must be approved by the majority of the existing members.
At step S2 (104), after the consortium blockchain network is formed, the committee members recommend others or themselves as housekeeper candidates. The predefined number of housekeepers is Nc; the predefined time period for a duty cycle is Tc; and the predefined block packing period is Tb (e.g., the amount of time needed to generate a block). In a consortium blockchain network, the committee member who received the most votes from the other committee members packs the genesis block of the consortium blockchain network and generates a random number which is used to pick a housekeeper to pack the next block.
At step S3 (106), at the beginning of each duty cycle, the committee votes on the housekeeper candidates. The top Nc most voted candidates become housekeepers during the instant duty cycle to generate blocks.
The housekeeper for packing the first block in each duty cycle is selected according to the number randomly generated by the housekeeper that generated the last block during the previous duty cycle. Especially, in a consortium blockchain network, the committee member who received the most votes from the other committee members will pack the genesis block of the consortium blockchain network and generates a random number which is used to pick a housekeeper to pack the next block.
At step S4 (108), among all the on-duty housekeepers in a duty cycle, the housekeeper that has been assigned the same number as the random number generated in the previous block packs (or generates) the current block and generates a random number for selecting another housekeeper to pack the next block. Each block must be reviewed and signed by more than half of the committee members before it can be added to the blockchain. This process serves to supervise the housekeepers.
One of the many technical advantages provided by the example system is the separation of the decision-making entities from the execution entities. The separation creates roles such as “committee”, “housekeeper”, and “housekeeper candidate” based on different functions. Housekeepers are elected from the housekeeper candidates. They are specialized nodes for packing transactions of the domain name system operation into blocks. The housekeepers are regularly (every other duty cycle) reelected together with housekeeper candidates. During the duty cycle, a housekeeper is randomly selected to sign a block in each block packing period.
In order to become housekeepers through recommendation and competition, to obtain record-keeping authorization, and to receive the corresponding rewards, the housekeeper nodes must maintain the maximum online time, work honestly, and timely complete the task of packing blocks. The housekeepers must also strictly comply with the protocol implemented by the top-level domain committee, including changes to the protocol. At the same time, housekeepers are scored by the committee members. According to the housekeepers' performance, the committee members will cast votes of confidence on the housekeepers to decide whether they can retain their status for the next duty cycle. The housekeepers are randomly picked to sign the block. If a housekeeper misses the block signing, the system will automatically deduct the housekeeper's points. A housekeeper may lose most of the committee's default votes of confidence in the next reelection and may lose its housekeeper status.
At step S5 (110), during a duty cycle, the housekeepers take turns packing blocks and generating random numbers to repeat the process.
The housekeepers randomly take turns to keep the record during the duty cycle. Each housekeeper has the same chance for record-keeping. The housekeeper needs to pack a block in the given record-keeping period. Each block must be verified by more than half of the domain name committee members, otherwise the block is invalid, and the block will be repacked by the housekeeper with the next number. The housekeepers verify the validity of the transactions and pack the valid transactions into a block. In addition to verifying the validity of the transactions, the committee members also review and decide whether the block containing the transactions can be added to the blockchain. This process shows whether the committee members approve the transactions, it is also another way of verifying the validity of the transactions.
The members are generally professional organizations and industries around the world. The applicant organization will be examined according to the self-determined protocol by the coalition. Under the conditions of the protocol, the node will join as a top-level domain committee member after being approved by the majority of the committee members. The top-level committee members are considered to be trusted nodes in the system.
There are two steps to become a housekeeper: (1) applying to become a housekeeper candidate with a recommendation; (2) the housekeeper candidates are eligible to be voted after the end of each duty cycle; unelected housekeepers retire to become housekeeper candidates. A certain number of housekeepers are selected from all housekeeper candidates through committee members' votes.
(1) Becoming a Housekeeper Candidate
A node needs to register a user account in the domain name system and submit a housekeeper candidate application. This can be implemented as a function. The applicants submit a letter of recommendation signed by at least one member of the domain names committee. A secret key, similar to an invitation code, is generated by a member of the domain name committee on a client device by invoking the function. The implementation mode is asymmetric encryption. The private key is used to encrypt the content of the recommendation letter. After the public key is decrypted, it can use to determine whether a recommendation letter is forged. An applicant may become a housekeeper candidate after being approved by more than half of the committee members and submitting a deposit.
If a node has a user account, it can become a housekeeper candidate after submitting a letter of recommendation signed by at least one member of the domain names committee, being approved by more than half of the committee members and submitting a deposit.
If a node is a member of the committee, it can submit the application directly to the committee without a letter of recommendation by another committee member. The node may become a housekeeper candidate after being approved by more than half of the committee members and submitting a deposit. A node may have the dual status as a committee member and a housekeeper candidate. If a node is elected as a housekeeper, the node will have the dual status as a committee member and a housekeeper.
(2) Becoming a Housekeeper
Record-keeping period: also referred to the block packing period, a record-keep period is determined by the system protocol. If a housekeeper cannot generate a block within the predefined record-keeping period, the authorization to generate a block is passed to the housekeeper with the next number.
Duty cycle: during a duty cycle, housekeepers are responsible for record-keeping and packing the blocks. After the end of a duty cycle, housekeepers go through another round of election based on popular votes by committee members. Discharged housekeepers will automatically become housekeeper candidates, and together with other housekeeper candidates, be voted on by the committee members of the top-level domain committee. A predefined number of housekeeper candidates will be accepted as housekeepers according to the votes.
At step S6 (112), the last random number generated by a housekeeper before the duty cycle ends is used to select the housekeeper to pack the first block of the next duty cycle.
At step S7 (114), at the end of each duty cycle, the top-level domain committee will score and vote all housekeeper candidates and repeat Steps S3 to Step S7.
Vote of Confidence: after the end of each duty cycle, members of the top-level domain name committee cast votes on all housekeeper candidates. The number of votes that each member is allowed to cast does not exceed half the number of housekeeper candidates.
Default vote of confidence: committee members score each housekeeper in a duty cycle; the committee members will vote for a predefined number of the top-scored housekeeper candidates.
Designated vote of confidence: a professional organization can designate a trusted housekeeper candidate to cast the vote on its behalf.
When a duty cycle restarts, the list of all housekeepers stored on each committee member node is updated and the score is reset. A housekeeper gains points every time a block passes a committee member's verification. A housekeeper loses points if the verification fails. A housekeeper will lose points or even have the score reset, if the housekeeper fails to timely pack a block (e.g., fails to pack the block within a predefined time period). After the end of a duty cycle, the committee's scores reflect its trust level of each housekeeper, and the scores also serve as the basis for the default vote of confidence. Committee members will also cast a small portion of their default votes of confidence to the housekeeping candidates who failed to become housekeepers in the last duty cycle. The default votes of confidences will be given to the housekeeper candidates that have no bad records and stayed online the longest.
After the end of a duty cycle, housekeepers may receive rewards based on their scores for their work performance. Housekeepers that missed block signing will lose their rewards, in part or in full, for this instant duty cycle.
At step S8 (116), the committee members determine whether or not the housekeepers are working honestly and completing tasks on time when they are on duty. If so, the committee will return the deposit when a housekeeper voluntarily withdraws; If not, it means the housekeepers have not signed the block as agreed or have misbehaved, the housekeepers will be dismissed by the committee, lose their deposit, or even be blacklisted, and will never be allowed to apply to become a housekeeper again.
A regular node must pay a deposit to the committee when applying to become a housekeeper candidate. If a housekeeper works honestly and completes tasks on time, the committee will return the deposit when the housekeeper voluntarily withdraws or retires. If a housekeeper fails to sign a block as agreed or has misbehaved, the housekeepers will be dismissed by the committee, lose their deposit, or even be blacklisted, and will never be allowed to apply to become a housekeeper again.
If a housekeeper's misbehavior is observed by a committee member, the housekeeper will be immediately reported, with more than one-third of the committee members agree to deprive the node's housekeeper status, the node's deposit will be forfeited and the node will be relegated to an ordinary account.
If the housekeeper's misbehavior is severe, with approval of two-thirds of the committee members, the node will be added to a blacklist, its account will be canceled, and the node will not be allowed to join the system.
The committee members who wrote the recommendation letters for the blacklisted housekeeper will be voted again by the committee to determine whether they can retain their membership.
In some implementations, one or more of the above identified elements are stored in one or more of the previously mentioned memory devices and correspond to a set of instructions for performing a function described above. The above identified modules or programs (e.g., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various implementations. In some implementations, the memory 606 optionally stores a subset of the modules and data structures identified above. Furthermore, the memory 606 may store additional modules and data structures not described above.
Although
Example Algorithms for Determining Consensus in a Consortium Blockchain
The present disclosure also provide implementation for determining consensus using PPoV (Parallel Proof of Vote), which is a non-forking consensus algorithm for consortium blockchain. The core lies in the separation of voting rights and bookkeeping rights. The bookkeeping nodes work in a joint effort to conduct decentralized arbitration according to the votes of the consortium nodes.
PPoV defines that data on the blockchain is stored in block groups. A block group consists of a block group header and a block group body. Each block group header contains the height and voting result. The block group body includes blocks approved by the majority of consortium nodes. Where, each block consists of the hash value of the previous block group, the Merkle root, the public key of the bookkeeping node, the timestamp, and the set of transactions.
The PPoV consensus divides the blockchain nodes into three identities: consortium node, bookkeeping node, and leader node.
The consortium node is responsible for voting on the generated blocks and potential bookkeeping nodes. The number of consortium nodes in each round is a fixed constant, denoted as n_c. Based on the principle of “the minority is subordinate to the majority”, the voting results are regarded as proof of the validity of the block and the identity of the bookkeeping node.
The bookkeeping node is responsible for generating blocks in the current consensus round. The number of bookkeeping nodes is n_b. At the end of the term, the consortium nodes vote on the potential bookkeeping nodes to produce the next bookkeeping nodes.
The leader node is responsible for counting votes and writing the voting result into the block group header as proof. Each consensus round has a different leader node, whose number is recorded in the previous block group header.
There are two types of voting messages in PPoV for the transactions of identifiers and election: confidence vote and verification vote.
The validation vote is a validation of the block group. The consortium node votes for the blocks they agree to generate. Each block must obtain more than half of the votes to be considered as a legal block. Similarly, to correct a result, more than half of the consortium nodes must agree.
The confidence vote is a successful proof for the next bookkeeping nodes. Before the end of the current bookkeeping nodes' term, each potential bookkeeping node proposes a transaction of election and receives votes from consortium nodes. The voting result indicates the trust of consortium nodes in these nodes competing for bookkeeping rights, thus can also be considered as the reliability of them. The nodes with higher reliability ranking are deemed successful in the election, with bookkeeping rights from the next consensus round until the end of their term.
Example Processes for Determining Consensus
S1: Each bookkeeping node generates a block and publishes it to the network. Each blockchain node collects all the blocks in this step.
S2: When the consortium node collects all the block generated in S1, it votes for each block and sends a total voting message to the leader node. The voting message contains the hash value of each block, as well as the agreed opinion and signature.
S3: The leader node collects the voting messages sent in S2 and counts the voting results. Statistical results and all voting messages will be stored in the block group header when the approval or disapproval of each block is more than half of the number of consortium nodes. The leader node then generates a random number as the number of the next leader node and writes it into the block group header. Finally, the leader node publishes the block group header to the network.
S4: When the blockchain node receives the block generated by the bookkeeping nodes and the block group header generated by the leader node, it will store them in the database as a block group.
Performance Analysis of PPoV Consensus Determination
This section calculates the throughput of the PPoV consensus. Since a new round of consensus can start only after the end of the current one, we calculate throughput through the time spent on each round of consensus. Consensus time consists of computation time and transmission time, that is,
t_cons=t_comp+t_tran (1)
1) Calculation of the Transmission Time t_tran
According to the consensus steps of PPoV, in S1, the communication traffic of each bookkeeping node is the sum of block messages sent by it, and the communication traffic of each consortium node is all the block messages it receives. The communication pressure of the bookkeeping node is higher than that of the consortium node, so the transmission time in S1 is the communication time of the bookkeeping node,
t_tran{circumflex over ( )}1=(n_b+n_c−n_bc−1)·(M+H+T·K)/band (2)
where n_b, n_c and n_bc are the number of bookkeeping nodes, consortium nodes and nodes concurrently holding these two identities respectively. M, H and T are the size of the message header, the block header, and the transaction, respectively. K is the maximum number of transactions that can be placed within each block. band is the bandwidth of each node (assuming the same uplink and downlink bandwidth).
To balance the computing power between nodes, we assume that the leader node does not concurrently serve as the consortium node. In this case, the transmission time in S2 is
t_tran{circumflex over ( )}2=n_c·(M+H_v+n_b·V_b)/band (3)
where H_v and V_b are the size of the vote header and the single vote, respectively.
Similarly, the transmission time in S3 is
where Hr and Rb are respectively the size of the voting result header and the voting result of a single block.
According to Equations (2)-(4), the transmission time is
t
tran
=t
tran
1
+t
tran
2
+t
tran
3 (5)
2) Calculation of the Computation Time tcomp
Consider a simple network scenario of consortium blockchain with two servers, where Server A runs a blockchain node, and Server B runs multiple blockchain nodes. To reduce the waste of computing power, we set each node as both bookkeeping node and consortium node. We make the node on Server A the leader node.
Since the bandwidth in Server B is much larger than that between A and B, the transmission time of nodes on Server B can be regarded as 0, and the transmission time of Server A still follows the conclusion above. The advantage of this scenario is that it eliminates the impact of asynchronous transmission on performance in distributed networks, and only analyzes computational factors.
The blockchain parameters of the prototype are K=10000, M=266 Byte, H=692 Byte, T=40 Byte, Hv=400 Byte, Vb=100 Byte, Hr=170 Byte, Rb=400 Byte, band=1 Gbps=125 MB/s, and the CPU of the server is Intel Xeon Silver 4114@2.20 GHz. From the perspective of server A, the states of the single blockchain node and the whole blockchain network can be observed simultaneously. We run 10 rounds of consensus at different scales. The time consumption of each step and each round is measured on Server A and averaged, as shown in Table 1.
According to the consensus steps of PPoV, the relationship between the time consumption of S1, S2 and S4 and the number of nodes n is linear. In S3, when n increases, the number of blocks that each consortium node needs to vote increases, so its time consumption can be described by a quadratic function. The time consumption of each step in Table 1 is fitted to
t
comp
1=0.0041n+0.0174
t
comp
2=0.0130n+0.0229
t
comp
3=0.0012n2−0.0082n+0.0415
t
comp
4=0.0052n+0.0062 (6)
Further understanding of Equation (6) is that, tcomp1 is reflected in the computation of the bookkeeping node, tcomp2 in the computation of the consortium node, tcomp3 in the computation of the leader node, and tcomp4 in the computation of each node.
According to Equations (2)-(5), the transmission time ttran is a cubic function of the number of nodes n, so the consensus time tcons can be described by a cubic function. The consensus time in Table 1 is fitted to
t
cons=(0.0312n3−0.1920n2+2.0714n+11.2500)/125 (7)
Substitute the parameter value of the prototype into Equations (2)-(5) to get the transmission time is
t
tran
=t
tran
1
+t
tran
2
+t
tran
3=(0.0001n3+0.0008n2+0.3213n−0.3214)/125 (8)
According to Equation (1), the computation time is
t
comp
=t
cons
−t
tran=(0.0311n3−0.1928n2+1.7501n+11.5714)/125 (9)
Consider the further understanding of Equation (6). Take the computing power of the servers in the prototype as the standard. For a blockchain network with computing power a, that is, the maximum computing power used by all nodes for consensus is a times of the standard computing power, then the minimum computation time is
According to Equations (5) and (10), the minimum consensus time in the network is
t
cons
′=t
comp
′+t
tran (11)
To sum up, the upper limit of throughput within the blockchain network is
Based on Equation (12), it is possible to estimate the upper limit of performance in the real blockchain network composed of servers and switches using PPoV consensus algorithm. In the consortium blockchain network, each server typically runs only one node. Assuming that the other configurations of nodes are the same, when their CPUs are Intel Xeon Silver 4114@2.20 GHz, Intel Xeon Silver 4116@2.10 GHz, and Intel Xeon Gold 5118@2.30 GHz respectively 1, the upper limit of throughput is affected by n and band, as shown in
When the number of nodes is small (generally less than 10), the computing power used for consensus is not fully utilized, so the number of nodes is the main factor affecting the throughput. When the number of nodes increases, the performance can be approximately increased with the improvement of computing power and bandwidth.
Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the implementation(s). In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the implementation(s).
It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first node could be termed a second node, and, similarly, a second node could be termed a first node, without changing the meaning of the description, so long as all occurrences of the “first node” are renamed consistently and all occurrences of the “second node” are renamed consistently. The first node and the second node are both nodes, but they are not the same node.
The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the claims. As used in the description of the implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context. Similarly, the phrase “if it is determined (that a stated condition precedent is true)” or “if (a stated condition precedent is true)” or “when (a stated condition precedent is true)” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.
The foregoing description included example systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative implementations. For purposes of explanation, numerous specific details were set forth in order to provide an understanding of various implementations of the inventive subject matter. It will be evident, however, to those skilled in the art that implementations of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures and techniques have not been shown in detail.
This application is a continuation-in-part of U.S. patent application Ser. No. 15/997,710, filed Jun. 5, 2018, entitled “determining consensus in a decentralized domain name system,” and now U.S. Pat. No. 10,382,388, on Aug. 13, 2018, which is a continuation of PCT patent application no. PCT/CN2017/084431, filed May 16, 2017, entitled “determining consensus in a decentralized domain name system.” All above-identified patents and patent applications are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2017/084431 | May 2017 | US |
| Child | 15997710 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15997710 | Jun 2018 | US |
| Child | 16540012 | US |
