Topic: Nyzo Mesh PoD - Highly efficient blockchain that actually works (Read 555 times)
Watching it
looks interesting.
any chance you guys will build a wallet for windows?
any chance you guys will build a wallet for windows?
December 27, 2018, 02:09:41 PM
Where to buy coin and whats total coin??
Total coin: 100 million https://nyzo.co/whitePaper
There’s otc on discord where people can buy and sell coins.
December 27, 2018, 01:54:11 PM
Where to buy coin and whats total coin??
December 04, 2018, 09:56:18 AM
Have a few verifiers running already. This one has that early raiblocks feeling
December 04, 2018, 08:52:34 AM
~Hello World~
December 03, 2018, 06:04:00 PM
This is an exiting new project, one that i intend to familiarize myself with and follow more closely !
Hope fr the best and i wish good luck to the dev team in overcoming any new future difficulties.
Hope fr the best and i wish good luck to the dev team in overcoming any new future difficulties.
December 03, 2018, 03:05:41 PM
Nyzo mesh: https://nyzo.co/mesh
Nyzo website: https://nyzo.co
Nyzo whitepaper: https://nyzo.co/whitePaper
Updates: https://nyzo.co/new
Update instructions: https://nyzo.co/updateInstructions
Coins: https://nyzo.co/coins
Nyzo discord: Nyzo discord: http://discord.gg/REzrUZG
The highly efficient blockchain that actually works for everyday spending.
Fast: 7-second block duration
Scalable: can support thousands of transactions per second
Sustainable: includes a plan for immunity technological obsolescence
Democratic: will be 100% community controlled within one year
Open-source: all-new, concise, readable code
Secure: blockchain is independently mathematically verifiable
About Nyzo
The blockchain is an exciting and undeniably useful technology. However, it is far from mature. While Bitcoin was a brilliant innovation, its issues are numerous, and many of the issues cannot be remedied through iterative change. Instead, a total rethinking of the blockchain — a clean slate — is necessary. Unfortunately, of the open-source, democratic blockchains in use, Bitcoin and its forks (or forks of forks) dominate the landscape, and truly novel open-source blockchain implementations are rare.
Nyzo was developed from the ground up to explore blockchain technology in an approachable, accessible manner. The source is simple and easy to read. The design of the blockchain and mesh are also simple and clearly explained in the white paper. Instead of layering complex fixes on top of a flawed design or adding elaborate features, we focused on the foundational technology of the blockchain to build a system that just works. Nyzo is also exceptionally flexible and extensible — the sender data field of Nyzo transactions allows for virtually unlimited possibilities for applications that utilize the Nyzo blockchain — but this flexibility is not obtained at the cost of reliability or stability.
The codebase does not use a single line of code from any previously existing blockchain project. We didn't fork an existing codebase and swap out one part of the process to make it seem like we created something new. We didn't duct-tape together a bunch of huge libraries to create a massive, unwieldy project. The only dependency is a small library implementing EdDSA cryptography. Transactions are fast, the system scales well to high volumes, and transaction fees are low and predictable.
Nyzo uses a collaborative verification system that requires neither proof of work nor proof of stake. There is no mining. Simply participating in the mesh gives a node the opportunity to verify transactions, and the queueing system is designed so that transaction fees are distributed equitably to all participants. Very little computational power is required of a node, and having superior computational power will not allow a node to gain a larger share of transaction fees.
We are excited to share Nyzo with the world, and we’re excited to see how this project develops. This is not an ICO. To get the system started, we have created over 27 million seed transactions: one transaction per block for the first six years that the system will be in operation. These transactions generate a total of 20 million nyzos in transaction fees in the first five years, and the sixth year contains excess transactions that will only be processed if earlier transactions are omitted. These transactions are pre-signed and downloaded automatically by the Nyzo software, and they are clearly marked as seed transactions in the blockchain. We don't want to misrepresent these transactions to anyone or give anyone the impression that organic transaction volume is higher than it really is. The only purpose of these transactions is to generate transaction fees to make verification worthwhile until suitable organic transaction volumes are established.
We also welcome contributions to the source code. The Nyzo source is licensed under the Unlicense, and the cryptography library it uses is licensed under the CC0 license. These are exceptionally permissive licenses that give as much control as possible to the community.
- / - / - / - / - /
Nyzo: a high-efficiency blockchain
Preface
Nyzo is an open-source, highly decentralized, democratic, and highly efficient blockchain. The block time is seven seconds, and the system scales well to high transaction volumes. This is not like most of the new coins you see: this is not a derivative of another project, and it is not just a few new features or a slight design change from other projects. This is all-new code, built from the ground up to be the most efficient, most democratic, easiest-to-use cryptocurrency in the world.
Terminology and symbols
Coins in this system are called “nyzo” (plural “nyzos”). The prefix for a nyzo is the mathematical intersection symbol, ∩. So, “5 nyzos” would be written as “∩5.” The smallest unit of measurement is the micronyzo. A micronyzo is 1/1,000,000 of a nyzo. The prefix for a micronyzo is the lowercase Greek letter mu, µ. So, “15 micronyzos” would be written as µ15. To avoid ambiguity and to eliminate rounding issues, all transactions are handled at the programmatic and blockchain levels in terms of micronyzos, and fractional micronyzos cannot be specified anywhere in the system.
Several “edges” are discussed in this system. The “frozen edge” is the highest block that a verifier has agreed it will never change, and the consensus mechanism is built to extend the frozen edge as quickly as possible while ensuring that no two verifiers acting in good faith ever freeze different blocks at the same level. The “trailing edge” is the lowest block that was necessary to determine the state of the frozen edge, and the “retention edge” is the lowest block for which a verifier will service normal requests. The frozen edge and trailing edge are precisely defined based on characteristics of the blockchain, while the retention edge is an arbitrary buffer behind the trailing edge that is useful in bootstrapping new verifiers.
Proof of diversity
The proof-of-diversity blockchain uses analysis of verification cycles to establish the authoritative form of the blockchain. This is not proof-of-work, and it is not proof-of-stake. It is a totally new proof system that relies on diversity of participation for strength. While proof-of-diversity has its own unique concerns that must be addressed to ensure integrity of the blockchain, it is immune to many of the attacks and problems inherent to proof-of-work and proof-of-stake systems, and it is significantly more efficient.
The basic concept of proof-of-diversity is simple. Verifiers take turns producing blocks in a circular order. Some simple rules ensure that verifiers are neither added to nor removed from that circular order too quickly. In order to produce a believable forgery of the blockchain for any meaningful amount of time, an attacker would need to obtain more than half of the private keys of verifiers currently working on the blockchain.
For any block in the blockchain, the verification cycle of that block is defined as the longest list of blocks, ending with that block, that contains no more than one instance of each verifier. Consider the following blockchain, where the number is the block height and the letter is the verifier:
20A, 21B, 22C, 23A, 24B, 25C, 26A
In this blockchain, the verification cycle of block 26 contains blocks 26, 25, and 24. The cycle does not contain block 23, because verifier A is already in the cycle at block 26. The verification cycle of block 25 contains blocks 25, 24, and 23. The cycle does not contain block 22, because verifier C is already in the cycle at block 25.
If a verifier is new to the chain, the same definition holds. To illustrate, we add verifier D at block 27:
20A, 21B, 22C, 23A, 24B, 25C, 26A, 27D
The verification cycle of block 27 is blocks 27, 26, 25, and 24. The cycle does not contain block 23, because verifier A is already present at block 26.
The previous cycle of the block is the cycle immediately before the current cycle. The previous cycle of block 27 in this example would contain blocks 23, 22, and 21, but not block 20, as verifier A is already present in that cycle at block 23.
A “new” verifier is defined as any verifier other than the last verifier of the previous cycle. An “existing” verifier is defined as the last verifier of the previous cycle. If an existing verifier misses a cycle, it will be considered a new verifier the next time it verifies a block.
Building on these definitions, we declare two rules to secure the proof-of-diversity blockchain.
Proof-of-diversity rule 1: After the first existing verifier in the block chain, a new verifier is only allowed if none of the other blocks in the cycle, the previous cycle, or the two blocks before the previous cycle were verified by new verifiers.
This rule exists to ensure that attackers cannot gain control of the chain by quickly introducing verifiers that they control. The addition of the two blocks before the previous cycle is to avoid clustering new verifiers in the chain.
Proof-of-diversity rule 2: Past the Genesis block, the cycle of a block must be longer than half of one more than the maximum of the all cycle lengths in this cycle and the previous two cycles.
This rule exists to ensure that the majority of the verifiers who are verifying the blockchain cannot be excluded by attackers who are trying to take control of the blockchain. In order to control the direction of the chain, one must control more than 50% of the current active verifiers. The blocks in this and the previous two cycles are considered to avoid divergence at opportunistic moments for verifiers that are clustered around certain parts of the chain.
The metric calculated in this rule cannot increase from one block to the next unless the cycle length also increases from one block to the next. This is important because it ensures that every block that passes this rule can be extended indefinitely.
These are the only two blockchain rules, and together they guarantee that, starting at any point in the blockchain, one must control more than half of the active verifiers to continue to produce a valid version of the blockchain. Unlike proof of work, which can be manipulated at will by anyone in possession of sufficient computational resources, proof of diversity requires active participation in a particular blockchain to have any influence on that blockchain.
Consensus techniques
Proof of diversity provides a mechanism for determining which version of the blockchain the mesh agreed to produce, but we also need a mechanism that the mesh can use to come to agreement on which version of the chain it will continue to extend.
Scoring
Each block has a score based on the verifier that signed it. A lower score is better than a higher score. At each height, an incremental score is calculated relative to the block at the previous height, and the total score of a block is the sum of all incremental scores back to the frozen edge.
For a block signed by an existing verifier, the incremental score is zero plus four times the difference between the previous block's cycle length and this block's cycle length. If the verifier is not active in the mesh, five is added to the incremental score.
For a block signed by a new verifier, the incremental score is negative six plus four times the verifier's position (zero-indexed) in the new-verifier vote total list. Twelve is added to the score of a new verifier not present in this list, which is limited to a maximum size of three.
Voting
A verifier may change its vote for a block several times. Votes are timestamped to prevent replay attacks of old votes.
If a block has a score less than 0, a verifier may vote for it immediately after freezing the previous block. Otherwise, it must wait 2 seconds minimum plus 20 seconds for each point that a block has above 0. So a block with a score of 0 can be voted for after 2 seconds, while a block with a score of 4 can be for after 82 seconds.
If the leading block in a verifier's local tabulation has more than 50% of the vote, the verifier changes its vote to that block if the verifier is allowed to vote for that block based on its score. If the leading block in a verifier's local tabulation does not have more than 50% of the vote, the verifier changes its vote to that block if the verifier was allowed to vote for that block more than 10 seconds ago.
If neither of these conditions is true, the verifier votes for the block with the lowest score if it is allowed to cast a vote based on that block's score. Until such a block exists, the verifier waits to cast a vote.
Vote tabulation and freezing of blocks
In tallying votes, only votes from verifiers in the frozen edge's verification cycle are counted. A block is frozen if the votes for that block exceed three-fourths of the size of the verification cycle in two subsequent vote tabulations calculated at least 0.5 seconds apart.
At the three-fourths threshold, more than half of the cycle would have to maliciously send different votes to honest verifiers in order to cause a divergence of the chain, assuming the worst case in which the remaining honest verifiers are split evenly on which block to freeze.
Transaction fees
All transactions incur a 0.25% fee. This fee is split evenly among the verifier of this block and the verifiers of the previous nine blocks. For blocks before block 9, the fee is split evenly among the verifier of this block and all previous blocks. Transaction fees that cannot be divided evenly are rounded down to the nearest micronyzo, and the remainder is rolled over to the next block.
Maintenance fees
Every account except 0000000000000000-0000000000000000-0000000000000000-0000000000000001 is charged a fee of µ1 every 500 blocks from its creation for as long as it has a balance greater than 0. This fee is intended to combat intentional overwhelming of verifiers through creation of many small accounts, and it is a negligible amount for legitimate accounts. The number of blocks per year is just over 4.5 million, and this results in maintenance fees of approximately ∩0.009010 per year per account.
Joining the mesh
When a Nyzo verifier is started, it asks other verifiers for information on the current state of the blockchain. The location of verifiers are specified in the file /var/lib/nyzo/production/trusted_entry_points. In the initial distribution, the Nyzo verifiers (verifier0.nyzo.co through verifier9.nyzo.co) are listed in this file, but it may be modified at any time.
Only one verifier is allowed to be run at each IPv4 address. As nodes take very little computational power, a single system could otherwise run many instances of the Nyzo software and take a disproportionate share of transaction fees. This will prevent some users from running Nyzo verifiers in situations with shared public IP addresses (dorms, offices), but that is an acceptable limitation to ensure fairness in transaction verification. Also, this limitation does not prevent multiple Nyzo clients at an address.
Two mechanisms are in place to enforce the IPv4 address restriction. First, in the list of verifiers waiting to join the verification cycle as a new verifier, any verifier changes at an address cause that address to be demoted to the end of the queue. Second, when an existing verifier produces a block, a penalty score is applied if that verifier is not currently listed as active in the mesh. To prevent shuffling of a large set of verifiers over a smaller set of IP addresses, the verifier at an IP address is only allowed to be reassigned at a time interval slightly larger than the time interval of the current verification cycle length. So, attempts to circumvent the IPv4 address restriction will result in difficulty joining the cycle as a new verifier and will risk being removed from the cycle as an existing verifier.
Genesis block
The Genesis block starts the Nyzo blockchain and generates all coins for the system. It contains a single type-0 transaction that transfers ∩100,000,000 to address 64afc20a4a4097e8-494239f2e7d1b1db-de59a9b157453138-f4716b72a0424fef.
Democratization
To ensure complete democratization, we will deactivate all of our verifiers (verifier0.nyzo.co through verifier9.nyzo.co), and we will stop committing code to the nyzoVerifier repository on GitHub, within 12 months of the Genesis block. The repository will remain as a reference, but we hope that multiple other repositories will emerge to continue to support Nyzo. If we continued to develop the codebase ourselves, or if we turned the codebase over to others, this would be a de facto authoritative implementation of Nyzo. The Nyzo protocol is so simple that we think there should be several implementations that dominate the landscape, not a single authoritative implementation.
While the proof-of-diversity blockchain has some rules that must be followed, these rules are incredibly simple, and all of the consensus rules can be modified or replaced without jeopardizing the proof of diversity. At any point in time, the decisions of the active verifiers in the current verification cycle determine the direction of the blockchain.
Sustainability
While we all want to see cryptocurrencies succeed, many investment experts think that most cryptocurrencies will eventually be completely valueless. Unlike physical assets with intrinsic scarcity or shares of companies or fiat currency with enforced scarcity, anyone can take the source code of an existing cryptocurrency, make some improvements to it, and issue a new cryptocurrency without contributing any value back to the original cryptocurrency.
Of course, as an open-source project, anyone will be able to use the Nyzo source to create a new blockchain, and we think that is a wonderful thing. However, we also want for the Nyzo cryptocurrency to have long-term, sustainable value. While a particular cryptocurrency may not typically have an intrinsic value, the community and the technology surrounding the currency do have such value. We think it is only fair to tie the value of the original currency to the value of the community and the technology, and we think this is the best way to ensure that Nyzo will maintain its value in the long run.
Our proposal is simple: if technological advancements render the current Nyzo system or blockchain obsolete, and a new blockchain needs to be released, all the coins in that system should be derived from original Nyzo coins. There should be no mining and no generation of new coins that are not tied to original Nyzo coins. This does not mean that all future generations of Nyzo will have to have the same number of coins as the current generation. For instance, if the second generation has 200 million coins instead of 100 million, then each first-generation Nyzo coin that is traded in will be rewarded with two second-generation Nyzo coins.
The sustainability program will work as follows. Any coins transferred to address 0000000000000000-0000000000000000-0000000000000000-0000000000000001 are transfers to the next blockchain. The next blockchain will periodically inspect the previous blockchain for transfers to that address and will generate appropriate coins in the next blockchain corresponding to the source identifier and amount of the transaction on the previous blockchain. Democratic processes would govern all of these decisions, with the current cycle of each generation serving also as the Genesis cycle of the next generation when the next generation of the blockchain begins.
The sustainability address (0000000000000000-0000000000000000-0000000000000000-0000000000000001) is the only address that is not charged account maintenance fees. All coins transferred to this address are permanently removed from use in this blockchain.
While this method of transferring assets to the next-generation blockchain does impose an additional implementation complexity on the next-generation blockchain, such is a small price to pay for continuation of blockchain assets beyond obsolescence of the technology that originally created those assets. Applying this transitively, we can imagine a fifteenth generation of Nyzo enabling global commerce 200 years from now, with every last coin in that system having a lineage traceable back to the Genesis block of the original Nyzo blockchain.
- / - / - / - /
Nyzo software
The Nyzo verifier is distributed as source code only. The verifier is available at https://github.com/n-y-z-o/nyzoVerifier. The repository includes instructions for setting up the verifier on a Linux AWS ec2 instance, but it has also been tested and used on Windows and macOS. The source is Java with a single small dependency for cryptography, so it is delightfully easy to build and get running properly.
The only difficulty, in some situations, will be setting up a port to allow incoming connections to the verifier. If you are on a home network with a computer behind a router and have no experience with this sort of thing, it can be frustrating. This is why our instructions are written for a cloud service — on cloud services, configuration for incoming connections is always simple, and connections to the internet tend to be fast, low-latency, and stable.
If you are running a verifier and want to use the coins you have earned from verifying transactions, we have a secure, browser-based tool for creating key and ID files that can be used in the wallet. You can also use this tool to create a new key and ID.
For those of you who already have key and ID files, we have a secure, browser-based wallet that you can use to send coins to other accounts. We only allow key and ID files to be used in the wallet to reduce copy/paste errors and typos, so if you have a text value for your private key, use the tool above to create a file that can be used in the wallet. If you have a text value for a recipient's public ID, please ask the recipient to send you an ID file instead. While this may seem tedious, it is much better than accidentally sending coins to the wrong ID and having no way to recover them.
Nyzo website: https://nyzo.co
Nyzo whitepaper: https://nyzo.co/whitePaper
Updates: https://nyzo.co/new
Update instructions: https://nyzo.co/updateInstructions
Coins: https://nyzo.co/coins
Nyzo discord: Nyzo discord: http://discord.gg/REzrUZG
The highly efficient blockchain that actually works for everyday spending.
Fast: 7-second block duration
Scalable: can support thousands of transactions per second
Sustainable: includes a plan for immunity technological obsolescence
Democratic: will be 100% community controlled within one year
Open-source: all-new, concise, readable code
Secure: blockchain is independently mathematically verifiable
About Nyzo
The blockchain is an exciting and undeniably useful technology. However, it is far from mature. While Bitcoin was a brilliant innovation, its issues are numerous, and many of the issues cannot be remedied through iterative change. Instead, a total rethinking of the blockchain — a clean slate — is necessary. Unfortunately, of the open-source, democratic blockchains in use, Bitcoin and its forks (or forks of forks) dominate the landscape, and truly novel open-source blockchain implementations are rare.
Nyzo was developed from the ground up to explore blockchain technology in an approachable, accessible manner. The source is simple and easy to read. The design of the blockchain and mesh are also simple and clearly explained in the white paper. Instead of layering complex fixes on top of a flawed design or adding elaborate features, we focused on the foundational technology of the blockchain to build a system that just works. Nyzo is also exceptionally flexible and extensible — the sender data field of Nyzo transactions allows for virtually unlimited possibilities for applications that utilize the Nyzo blockchain — but this flexibility is not obtained at the cost of reliability or stability.
The codebase does not use a single line of code from any previously existing blockchain project. We didn't fork an existing codebase and swap out one part of the process to make it seem like we created something new. We didn't duct-tape together a bunch of huge libraries to create a massive, unwieldy project. The only dependency is a small library implementing EdDSA cryptography. Transactions are fast, the system scales well to high volumes, and transaction fees are low and predictable.
Nyzo uses a collaborative verification system that requires neither proof of work nor proof of stake. There is no mining. Simply participating in the mesh gives a node the opportunity to verify transactions, and the queueing system is designed so that transaction fees are distributed equitably to all participants. Very little computational power is required of a node, and having superior computational power will not allow a node to gain a larger share of transaction fees.
We are excited to share Nyzo with the world, and we’re excited to see how this project develops. This is not an ICO. To get the system started, we have created over 27 million seed transactions: one transaction per block for the first six years that the system will be in operation. These transactions generate a total of 20 million nyzos in transaction fees in the first five years, and the sixth year contains excess transactions that will only be processed if earlier transactions are omitted. These transactions are pre-signed and downloaded automatically by the Nyzo software, and they are clearly marked as seed transactions in the blockchain. We don't want to misrepresent these transactions to anyone or give anyone the impression that organic transaction volume is higher than it really is. The only purpose of these transactions is to generate transaction fees to make verification worthwhile until suitable organic transaction volumes are established.
We also welcome contributions to the source code. The Nyzo source is licensed under the Unlicense, and the cryptography library it uses is licensed under the CC0 license. These are exceptionally permissive licenses that give as much control as possible to the community.
- / - / - / - / - /
Nyzo: a high-efficiency blockchain
Preface
Nyzo is an open-source, highly decentralized, democratic, and highly efficient blockchain. The block time is seven seconds, and the system scales well to high transaction volumes. This is not like most of the new coins you see: this is not a derivative of another project, and it is not just a few new features or a slight design change from other projects. This is all-new code, built from the ground up to be the most efficient, most democratic, easiest-to-use cryptocurrency in the world.
Terminology and symbols
Coins in this system are called “nyzo” (plural “nyzos”). The prefix for a nyzo is the mathematical intersection symbol, ∩. So, “5 nyzos” would be written as “∩5.” The smallest unit of measurement is the micronyzo. A micronyzo is 1/1,000,000 of a nyzo. The prefix for a micronyzo is the lowercase Greek letter mu, µ. So, “15 micronyzos” would be written as µ15. To avoid ambiguity and to eliminate rounding issues, all transactions are handled at the programmatic and blockchain levels in terms of micronyzos, and fractional micronyzos cannot be specified anywhere in the system.
Several “edges” are discussed in this system. The “frozen edge” is the highest block that a verifier has agreed it will never change, and the consensus mechanism is built to extend the frozen edge as quickly as possible while ensuring that no two verifiers acting in good faith ever freeze different blocks at the same level. The “trailing edge” is the lowest block that was necessary to determine the state of the frozen edge, and the “retention edge” is the lowest block for which a verifier will service normal requests. The frozen edge and trailing edge are precisely defined based on characteristics of the blockchain, while the retention edge is an arbitrary buffer behind the trailing edge that is useful in bootstrapping new verifiers.
Proof of diversity
The proof-of-diversity blockchain uses analysis of verification cycles to establish the authoritative form of the blockchain. This is not proof-of-work, and it is not proof-of-stake. It is a totally new proof system that relies on diversity of participation for strength. While proof-of-diversity has its own unique concerns that must be addressed to ensure integrity of the blockchain, it is immune to many of the attacks and problems inherent to proof-of-work and proof-of-stake systems, and it is significantly more efficient.
The basic concept of proof-of-diversity is simple. Verifiers take turns producing blocks in a circular order. Some simple rules ensure that verifiers are neither added to nor removed from that circular order too quickly. In order to produce a believable forgery of the blockchain for any meaningful amount of time, an attacker would need to obtain more than half of the private keys of verifiers currently working on the blockchain.
For any block in the blockchain, the verification cycle of that block is defined as the longest list of blocks, ending with that block, that contains no more than one instance of each verifier. Consider the following blockchain, where the number is the block height and the letter is the verifier:
20A, 21B, 22C, 23A, 24B, 25C, 26A
In this blockchain, the verification cycle of block 26 contains blocks 26, 25, and 24. The cycle does not contain block 23, because verifier A is already in the cycle at block 26. The verification cycle of block 25 contains blocks 25, 24, and 23. The cycle does not contain block 22, because verifier C is already in the cycle at block 25.
If a verifier is new to the chain, the same definition holds. To illustrate, we add verifier D at block 27:
20A, 21B, 22C, 23A, 24B, 25C, 26A, 27D
The verification cycle of block 27 is blocks 27, 26, 25, and 24. The cycle does not contain block 23, because verifier A is already present at block 26.
The previous cycle of the block is the cycle immediately before the current cycle. The previous cycle of block 27 in this example would contain blocks 23, 22, and 21, but not block 20, as verifier A is already present in that cycle at block 23.
A “new” verifier is defined as any verifier other than the last verifier of the previous cycle. An “existing” verifier is defined as the last verifier of the previous cycle. If an existing verifier misses a cycle, it will be considered a new verifier the next time it verifies a block.
Building on these definitions, we declare two rules to secure the proof-of-diversity blockchain.
Proof-of-diversity rule 1: After the first existing verifier in the block chain, a new verifier is only allowed if none of the other blocks in the cycle, the previous cycle, or the two blocks before the previous cycle were verified by new verifiers.
This rule exists to ensure that attackers cannot gain control of the chain by quickly introducing verifiers that they control. The addition of the two blocks before the previous cycle is to avoid clustering new verifiers in the chain.
Proof-of-diversity rule 2: Past the Genesis block, the cycle of a block must be longer than half of one more than the maximum of the all cycle lengths in this cycle and the previous two cycles.
This rule exists to ensure that the majority of the verifiers who are verifying the blockchain cannot be excluded by attackers who are trying to take control of the blockchain. In order to control the direction of the chain, one must control more than 50% of the current active verifiers. The blocks in this and the previous two cycles are considered to avoid divergence at opportunistic moments for verifiers that are clustered around certain parts of the chain.
The metric calculated in this rule cannot increase from one block to the next unless the cycle length also increases from one block to the next. This is important because it ensures that every block that passes this rule can be extended indefinitely.
These are the only two blockchain rules, and together they guarantee that, starting at any point in the blockchain, one must control more than half of the active verifiers to continue to produce a valid version of the blockchain. Unlike proof of work, which can be manipulated at will by anyone in possession of sufficient computational resources, proof of diversity requires active participation in a particular blockchain to have any influence on that blockchain.
Consensus techniques
Proof of diversity provides a mechanism for determining which version of the blockchain the mesh agreed to produce, but we also need a mechanism that the mesh can use to come to agreement on which version of the chain it will continue to extend.
Scoring
Each block has a score based on the verifier that signed it. A lower score is better than a higher score. At each height, an incremental score is calculated relative to the block at the previous height, and the total score of a block is the sum of all incremental scores back to the frozen edge.
For a block signed by an existing verifier, the incremental score is zero plus four times the difference between the previous block's cycle length and this block's cycle length. If the verifier is not active in the mesh, five is added to the incremental score.
For a block signed by a new verifier, the incremental score is negative six plus four times the verifier's position (zero-indexed) in the new-verifier vote total list. Twelve is added to the score of a new verifier not present in this list, which is limited to a maximum size of three.
Voting
A verifier may change its vote for a block several times. Votes are timestamped to prevent replay attacks of old votes.
If a block has a score less than 0, a verifier may vote for it immediately after freezing the previous block. Otherwise, it must wait 2 seconds minimum plus 20 seconds for each point that a block has above 0. So a block with a score of 0 can be voted for after 2 seconds, while a block with a score of 4 can be for after 82 seconds.
If the leading block in a verifier's local tabulation has more than 50% of the vote, the verifier changes its vote to that block if the verifier is allowed to vote for that block based on its score. If the leading block in a verifier's local tabulation does not have more than 50% of the vote, the verifier changes its vote to that block if the verifier was allowed to vote for that block more than 10 seconds ago.
If neither of these conditions is true, the verifier votes for the block with the lowest score if it is allowed to cast a vote based on that block's score. Until such a block exists, the verifier waits to cast a vote.
Vote tabulation and freezing of blocks
In tallying votes, only votes from verifiers in the frozen edge's verification cycle are counted. A block is frozen if the votes for that block exceed three-fourths of the size of the verification cycle in two subsequent vote tabulations calculated at least 0.5 seconds apart.
At the three-fourths threshold, more than half of the cycle would have to maliciously send different votes to honest verifiers in order to cause a divergence of the chain, assuming the worst case in which the remaining honest verifiers are split evenly on which block to freeze.
Transaction fees
All transactions incur a 0.25% fee. This fee is split evenly among the verifier of this block and the verifiers of the previous nine blocks. For blocks before block 9, the fee is split evenly among the verifier of this block and all previous blocks. Transaction fees that cannot be divided evenly are rounded down to the nearest micronyzo, and the remainder is rolled over to the next block.
Maintenance fees
Every account except 0000000000000000-0000000000000000-0000000000000000-0000000000000001 is charged a fee of µ1 every 500 blocks from its creation for as long as it has a balance greater than 0. This fee is intended to combat intentional overwhelming of verifiers through creation of many small accounts, and it is a negligible amount for legitimate accounts. The number of blocks per year is just over 4.5 million, and this results in maintenance fees of approximately ∩0.009010 per year per account.
Joining the mesh
When a Nyzo verifier is started, it asks other verifiers for information on the current state of the blockchain. The location of verifiers are specified in the file /var/lib/nyzo/production/trusted_entry_points. In the initial distribution, the Nyzo verifiers (verifier0.nyzo.co through verifier9.nyzo.co) are listed in this file, but it may be modified at any time.
Only one verifier is allowed to be run at each IPv4 address. As nodes take very little computational power, a single system could otherwise run many instances of the Nyzo software and take a disproportionate share of transaction fees. This will prevent some users from running Nyzo verifiers in situations with shared public IP addresses (dorms, offices), but that is an acceptable limitation to ensure fairness in transaction verification. Also, this limitation does not prevent multiple Nyzo clients at an address.
Two mechanisms are in place to enforce the IPv4 address restriction. First, in the list of verifiers waiting to join the verification cycle as a new verifier, any verifier changes at an address cause that address to be demoted to the end of the queue. Second, when an existing verifier produces a block, a penalty score is applied if that verifier is not currently listed as active in the mesh. To prevent shuffling of a large set of verifiers over a smaller set of IP addresses, the verifier at an IP address is only allowed to be reassigned at a time interval slightly larger than the time interval of the current verification cycle length. So, attempts to circumvent the IPv4 address restriction will result in difficulty joining the cycle as a new verifier and will risk being removed from the cycle as an existing verifier.
Genesis block
The Genesis block starts the Nyzo blockchain and generates all coins for the system. It contains a single type-0 transaction that transfers ∩100,000,000 to address 64afc20a4a4097e8-494239f2e7d1b1db-de59a9b157453138-f4716b72a0424fef.
Democratization
To ensure complete democratization, we will deactivate all of our verifiers (verifier0.nyzo.co through verifier9.nyzo.co), and we will stop committing code to the nyzoVerifier repository on GitHub, within 12 months of the Genesis block. The repository will remain as a reference, but we hope that multiple other repositories will emerge to continue to support Nyzo. If we continued to develop the codebase ourselves, or if we turned the codebase over to others, this would be a de facto authoritative implementation of Nyzo. The Nyzo protocol is so simple that we think there should be several implementations that dominate the landscape, not a single authoritative implementation.
While the proof-of-diversity blockchain has some rules that must be followed, these rules are incredibly simple, and all of the consensus rules can be modified or replaced without jeopardizing the proof of diversity. At any point in time, the decisions of the active verifiers in the current verification cycle determine the direction of the blockchain.
Sustainability
While we all want to see cryptocurrencies succeed, many investment experts think that most cryptocurrencies will eventually be completely valueless. Unlike physical assets with intrinsic scarcity or shares of companies or fiat currency with enforced scarcity, anyone can take the source code of an existing cryptocurrency, make some improvements to it, and issue a new cryptocurrency without contributing any value back to the original cryptocurrency.
Of course, as an open-source project, anyone will be able to use the Nyzo source to create a new blockchain, and we think that is a wonderful thing. However, we also want for the Nyzo cryptocurrency to have long-term, sustainable value. While a particular cryptocurrency may not typically have an intrinsic value, the community and the technology surrounding the currency do have such value. We think it is only fair to tie the value of the original currency to the value of the community and the technology, and we think this is the best way to ensure that Nyzo will maintain its value in the long run.
Our proposal is simple: if technological advancements render the current Nyzo system or blockchain obsolete, and a new blockchain needs to be released, all the coins in that system should be derived from original Nyzo coins. There should be no mining and no generation of new coins that are not tied to original Nyzo coins. This does not mean that all future generations of Nyzo will have to have the same number of coins as the current generation. For instance, if the second generation has 200 million coins instead of 100 million, then each first-generation Nyzo coin that is traded in will be rewarded with two second-generation Nyzo coins.
The sustainability program will work as follows. Any coins transferred to address 0000000000000000-0000000000000000-0000000000000000-0000000000000001 are transfers to the next blockchain. The next blockchain will periodically inspect the previous blockchain for transfers to that address and will generate appropriate coins in the next blockchain corresponding to the source identifier and amount of the transaction on the previous blockchain. Democratic processes would govern all of these decisions, with the current cycle of each generation serving also as the Genesis cycle of the next generation when the next generation of the blockchain begins.
The sustainability address (0000000000000000-0000000000000000-0000000000000000-0000000000000001) is the only address that is not charged account maintenance fees. All coins transferred to this address are permanently removed from use in this blockchain.
While this method of transferring assets to the next-generation blockchain does impose an additional implementation complexity on the next-generation blockchain, such is a small price to pay for continuation of blockchain assets beyond obsolescence of the technology that originally created those assets. Applying this transitively, we can imagine a fifteenth generation of Nyzo enabling global commerce 200 years from now, with every last coin in that system having a lineage traceable back to the Genesis block of the original Nyzo blockchain.
- / - / - / - /
Nyzo software
The Nyzo verifier is distributed as source code only. The verifier is available at https://github.com/n-y-z-o/nyzoVerifier. The repository includes instructions for setting up the verifier on a Linux AWS ec2 instance, but it has also been tested and used on Windows and macOS. The source is Java with a single small dependency for cryptography, so it is delightfully easy to build and get running properly.
The only difficulty, in some situations, will be setting up a port to allow incoming connections to the verifier. If you are on a home network with a computer behind a router and have no experience with this sort of thing, it can be frustrating. This is why our instructions are written for a cloud service — on cloud services, configuration for incoming connections is always simple, and connections to the internet tend to be fast, low-latency, and stable.
If you are running a verifier and want to use the coins you have earned from verifying transactions, we have a secure, browser-based tool for creating key and ID files that can be used in the wallet. You can also use this tool to create a new key and ID.
For those of you who already have key and ID files, we have a secure, browser-based wallet that you can use to send coins to other accounts. We only allow key and ID files to be used in the wallet to reduce copy/paste errors and typos, so if you have a text value for your private key, use the tool above to create a file that can be used in the wallet. If you have a text value for a recipient's public ID, please ask the recipient to send you an ID file instead. While this may seem tedious, it is much better than accidentally sending coins to the wrong ID and having no way to recover them.
Jump to: