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.
Frozen edge: 3787356
(Sinestra, 10 behind open edge)
Removal votes >5%:
Current cycle: 1320
Recent cycle changes
− v34faa38f94ekele left at block 3787011, cycle length: 1320
+ Chinade joined at block 3785894, cycle length: 1321
− cryptic_monk4 left at block 3784306, cycle length: 1320
− NYZO_CHIVAS left at block 3783854, cycle length: 1321
+ cinquenta sete joined at block 3783251, cycle length: 1322
− tightbox07 left at block 3780558, cycle length: 1321
+ NEX03 joined at block 3780554, cycle length: 1322
+ TeslaNow joined at block 3777846, cycle length: 1321
+ VinB46 joined at block 3775203, cycle length: 1320
+ UNIQUE joined at block 3772553, cycle length: 1319
Next new-verifier height: 3788539 (in 1183 blocks)
Verifiers waiting to join, ordered by nickname (7151)
Nyzo: a high-efficiency blockchain
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 blockchain, 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.
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.
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.
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.
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.
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.
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.
To ensure complete democratization, we will deactivate all of our verifiers (verifier0.nyzo.co through verifier9.nyzo.co) within 12 months of the Genesis block. We had originally planned to stop committing code to the official Nyzo repository as well, continuing our work on forks or other implementations of Nyzo without revealing our identities as original developers of Nyzo. We had planned this because we have seen too many open-source projects that start out with great ideas from a small group or an individual, only to be held back later due to deference to that group's or individual's opinions instead of the better ideas of the community at large. Open source doesn't live up to its full potential when only one team controls all the important decisions.
However, we now feel that stopping contributions the official repository so soon after the start of the blockchain would be harmful to the progress of the project and would feel like abandonment of the project on our part. We still hope that competing implementations of Nyzo will be developed, and the democratic nature of Nyzo means that we have no control over which implementation or implementations become dominant in the cycle. So, we plan to continue contributing to the official Nyzo repository indefinitely, and we will let the community decide whether they want to use our 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.
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.
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 block 3787356
previous block hash
1563308292.000 (2019-07-16 20:18:12.000 UTC)
1563308299.000 (2019-07-16 20:18:19.000 UTC)
1563308335.145 (2019-07-16 20:18:55.145 UTC)
type: 1 (seed)
timestamp: 1563308293.000 (2019-07-16 20:18:13.000 UTC)
receiver ID: 12d454a69523f739-eb5eb71c7deb8701-1804df336ae0e2c1-9e0b24a636683e31
sender ID: 12d454a69523f739-eb5eb71c7deb8701-1804df336ae0e2c1-9e0b24a636683e31
sender data: (empty)
sender signature: 24ced48c0ee7b785-63c4087eccab3e3c-154574208837b540-be5050a1e18b6522-d46df1063ff39f5d-03d01daca287e1b8-431211d50bb5ceea-80af0f10e370510e
2018-01-31 — changed the web wallet to use the server timestamp for transactions to reduce potential transaction acceptance issues due to client clock synchronization issues
2018-01-20 — added a legend to the bottom of the mesh page, linked to a detail page
2018-12-13 — added “what's next?” page
2018-12-04 — cleaned up tiles on the mesh page
2018-11-27 — released Nyzo version 477
2018-11-24 — released Nyzo version 476
2018-11-20 — released three scripts for interacting with verifiers
2018-11-14 — released Nyzo version 475
2018-10-31 — added color-coding of inactive and unhealthy verifiers in the cycle display on the mesh page
2018-10-29 — reworked display of nodes waiting in queue, split healthy from unhealthy nodes in tile section on the mesh page
2018-10-28 — temporarily closed mesh to new verifiers
2018-10-19 — add display of predicted cycle additions to the mesh page
2018-10-15 — increased mesh limit to 140
2018-10-14 — corrected a performance issue that was causing wallets with large numbers of transactions load slowly or not load a all
2018-10-11 — increased mesh limit to 120
2018-10-10 — added nickname database persistence for the web server — this will not affect nickname updates in any way; it only provides historical nickname lookups for verifiers that have left the mesh
2018-10-08 — increased mesh limit to 100
2018-10-07 — increased mesh limit to 80
2018-09-22 — improved refresh of mesh page, added warning when content is stale
2018-09-20 — added buttons on wallet to allow filtering of transactions by type
2018-09-17 — added display of frozen edge, open edge, and current cycle to the mesh page
2018-09-13 — restarted blockchain with 7-second block time and updated rapid-consensus algorithm
The following features and fixes are planned for Nyzo. Any critical security and stability issues that arise will take precedence over new features or non-critical improvements.
- Resiliency and recovery speed of verifiers will continue to be improved.
- The Micropay system will continue to be developed.
- Other integrations to increase organic transaction volume will be explored.
We want you to have coins. Seriously. This is no fun if we don't all have coins to use. But we're not doing a presale, we're not doing an ICO, and the system doesn't have mining. In too many cryptocurrencies, we have seen presales, ICOs, and easy early mining result in small numbers of people amassing large numbers of coins that they don't actually use. We want to get a lot of coins out to a lot of different people, because that's the best way to create a thriving crypto ecosystem.
If you want coins, you have two options: joining the verification cycle or helping to improve the system by finding and reporting bugs.
If you are able to join the cycle as a verifier, you get 10% of the transaction fees for each block you verify and 10% of transaction fees for each of the next 9 blocks in the chain. This is how you will earn coins at the beginning, and this is how you will continue to earn coins as more people join the system. Unlike mined currencies, we're not going to have a drop-off of profitability as time goes on. As more people join the network, more transaction fees should be generated. These fees will be split among a larger pool of people as more verifiers join, but the blockchain rules limit the growth rate of the cycle to an inverse proportion of the cycle length. With a cycle length of 500, fewer than 13 verifiers can be added each day. With a cycle length of 1000, fewer than 7 verifiers can be added each day.
Of course, until a lot of people have a lot of coins, organic transaction volume will not be high enough to make transaction verification worthwhile. To remedy this, 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 are drawn from an account for which the private key was generated, used to sign the transactions, and discarded without saving. The account is funded with ∩20 million; it will be drained to approximately ∩0.01 at the end of five years if all seed transactions are processed. Transactions in the sixth year will only process if some of the earlier transactions are omitted.
If you find bugs and report them to us, we will reward you with coins through our bounty program. The reward for stability issues starts at ∩10,000, and the reward for security issues starts at ∩50,000. Rewards increase according to the severity of issues and quality of the report. We reserve the right to determine reward amounts, and our judgment on reward amounts is final. We also reserve the right to change minimum reward amounts or discontinue this program at any time without advance notice. There is no pre-determined limit on the amount of an individual reward, but all rewards over ∩100,000 will be announced when the first payment is made and divided into weekly payments of no more than ∩100,000 each (∩100,000 is 0.1% of all coins in the system, so it is a lot of coins).