Update 21062020: Fixed broken links pointing to old release note directory.
A lot has happened in the last year and the Nyzo developers have not stood still. The Nyzo network has been up and running for over a year now. It’s time to take a step back and relive the developments that have been released, which hurdles were conquered and what can be expected next.
While this article goes into detail about the challenges which have been tackled successfully and the enormous amount of effort that went into developing the chain from the launch date onward, it merely shines a small light on what really went into developing and architecting the blockchain into what it is today, a fully functional and highly efficient blockchain system ready for ‘its battle with time’.
Counting from the launch date onwards, the work stretches over a period of 15 months (at the time of writing) and is truly something to behold when watching back its track record of release notes and community interactions.
For the anonymous team behind Nyzo the work started at the end of 2017.
It started as an extension of a programming language / operating environment they were developing, the name which was chosen was Nyzo.
What the team was initially working on was
‘a computer that has 100s or 1000s of low-power processors that interact through one another through message passing’
Nyzo continues,
‘Some of the basic networking ideas were in there, but the actual blockchain side of things did not appear until the last day of 2017. Almost immediately, that became the primary focus of the codebase’.
Launch — 13/09/18 — Day 1
The Nyzo network has produced its first block on the 13th of September 2018 with the chain officially up and running. This, after many hours of work had been spent on the initial version of the network, by its team of anonymous developers. Later that week the frozen edge, open edge and cycle length were added to the Nyzo website to track the network.
The following week the mesh page was improved and nodes could be individually tracked on the web page.
With the launch came the release of the white paper and its github repository.
Mesh limit increases
In the month following the launch the first group of miners popped up and were able to join the cycle. In this period the mesh limit was gradually increased by the developers, carefully watching over network and individual node states. (Day 0 → Day 45). The web call to the meshLimit web page was removed as to not stand in the way of proper network decentralization, but its existence was necessary to steer the network into the right direction in the first stages of existence and optimization.
Release 471 — 01/10/18 — Day 18
Two weeks after launching the first release note had been published, it is 2 pages long and details a minor update improving density of connections in the mesh. An in-cycle node does no longer “lose sight” of another in-cycle node due to this update.
Website updates — 14/10/18 — Day 31
The website was further refined and historical node nicknames were from now on actively tracked. An issue in regards to wallets not loading large amount of transactions was resolved.
Release 472 — 17/10/18 — Day 34
This release note details a fix in regards to votes. Under ideal conditions all verifiers in the mesh receive all votes from all other verifiers. If a node has temporary network connection issues, it might miss some votes. This update resolves this problem by making the node request any missing votes from in-cycle network participants.
Queue overview— 19/10/18 — Day 36
At this point in time new nodes joined the network in FIFO based on their first-seen timestamp. To give an idea to new entrants as to when they can expect to join the network a predictive list was added to the website.
Release 473 — 21/10/18 — Day 38
This release note added an override option for the new-verifier vote, in response to a significant enough number of problematic nodes joining the mesh. These nodes were preventing new, fully functional nodes from joining the network and a vote override was called in to existence to steer the network into the right direction.
Release 474 — 23/10/18 — Day 40
This release note fixes two issues which caused the verifier initialization process to be unnecessary slow. A file read issue was resolved which caused unnecessary load due to a variable not being assigned properly. In a similar fashion an issue in regards to the consolidated block reading procedure was corrected.
New additions temporarily halted — 28/10/18 — Day 45
Due to concerns about network scalability new network participants were not allowed to enter for two weeks, this allowed for optimizations to be developed in the meantime.
Web updates — 14/11/18 — Day 62
The website was refined to split healthy from unhealthy nodes on the mesh page. Additional color coding was added to quickly identify nodes which require attention.
Release 475 allows the mesh to be reopened for new verifiers. Shortly after launch, interest in the project resulted in very rapid growth of the list of verifiers in queue. Due to design limitations back then this caused the computational demand of in-cycle verifiers to grow proportionally to the size of the queue, the magnitude of this burden was unacceptable for in-cycle verifiers.
The decentralized nature of Nyzo prevented the developer team from truly closing the mesh to new verifiers, and were instead able to instruct official Nyzo verifiers to ignore messages from those joining after the cutoff date.
Scripts released for interacting with verifiers — 20/11/18 — Day 68
Three scripts have been added to the verifier.
- HashVoteOverrideRequestScript
This allows you to manually vote for a different block hash.
- NewVerifierTallyStatusRequestScript
This allows you to export a list with the current votes for new entrants. (At time of writing this switches every 50 blocks as default behavior and uses the 50-block incremented block hash to derive the queue verifier to vote for)
- NewVerifierVoteOverrideRequestScript
This allows you to manually vote for a verifier.
Release 476 — 24/11/18 — Day 72
The blacklist function was introduced in version 476 due to concerns of DDoS attacks.
Back when a sentinel didn’t exist yet, there was no fault protection for in-cycle verifiers. Missing one block production meant being kicked out of the cycle by the other nodes.
A smaller cycle and therefore a smaller interval between when your node is expected to produce a block meant that nodes got kicked at a faster rate due to no redundancy being in place.
Other changes were implemented in this update to cut down on the heavy load which verifiers were under. This update improved bandwidth consumption and overall load managing of the processes. In this update the blacklist and whitelist functionality were added to the codebase.
Release 477– 27/11/18 — Day 75
Release 477 changes how votes are broadcasted to the network by the verifier. If the counter has exceeded more than 50 more than the minimum new-verifier interval, the identifier is demoted so a new vote can be cast in the next verifier iteration. This process has been revisited in a later release note.
Web wallet update — 02/12/18 — Day 80
This update changed how transactions were displayed on the Nyzo web wallet page. Reward transactions are now consolidated together for easy viewing purposes.
Mesh page updated — 04/12/18 — Day 82
Due to a large influx of new members the way the verifiers are displayed on the website has been revisited.
Added “what’s next” page — 13/12/18 — Day 91
This page gave information about upcoming updates. This page does no longer exist due to the team switching over to Nyzo Team Technology proposals (NTTPs) in a later stage of the project.
Added verifier status page — 17/12/18 — Day 95
This adds the verifier status tile on a seperate page for each verifier, allowing for a clean overview on the website and individual diagnostics of a node upon request.
Added cycle events — 18/12/18 — Day 96
A link was added to view a list of all the cycle changes.
Sentinel release — 24/12/18 — Day 102
With the christmas period the network has been up and running for just over 100 days. The sentinel was released and immediately started playing an important role in protecting verifiers. A much anticipated update which every in-cycle verifier holder welcomed with open arms.
A sentinel is a shadow node watching over your in-cycle verifiers. In the case of DDoS attacks the sentinel will stealthily produce a block and propagate it to the network. This feature makes the network robust and ensures that no bad actor can cause verifiers to leave the cycle. The integrity of the network is (aside from the consensus rules) ensured by the sentinel.
Seed-funding protection — 30/12/18 — Day 108
Release 479 adds protection to the seed-funding wallet. All signed transactions are stored by the in-cycle verifiers and claimed on a per-block basis by including its transaction in the block. This update ensures that no other transactions originating from the seed wallet can be included by the network.
Seed-funding wallet : id__81bkmarm8_tXYTYV77VIyN4p1d-RrL3zNqWb9apUr3WP-ys.NG-H
Release 480 — 02/01/19 —Day 111
This release updates the scripts to handle verifiers with multiple IP addresses or whose IP addresses have changed.
Monitoring update — 03/01/19–05/01/19 — Day 112–114
Version 481 and 483 serves monitoring purposes only, in preparation of future upgrades to memory usage, the memory usage of the instance is added to the status response. Some other improvements were also made to the status response.
Sentinel block file consolidation process — 04/01/19 — Day 113
Version 482 adds the block file consolidation process to the sentinel. The block file consolidator is necessary because individual block files, while very efficient for processing, are quite inefficient in terms of both storage and number of inodes on the system. The production of 12300 blocks every 24 hours can quickly exhaust a small virtual server.
This adds the initialization of the block file consolidator to the sentinel and resolves this problem.
Improved node management for verifier — 10/01/19 — Day 119
Due to network growth, managing network traffic efficiently becomes a necessity. Several changes were made to ensure that anti-DDoS protection of cloud providers does not raise a false flag for Nyzo related communications.
Release v484 changed the process for sending node-join messages, replacing most of the short bursts of activity with a small number of messages; just after the block has been frozen.
Subsequent release version v485 addressed a minor issue with the status response of the verifier.
An important whitepaper update — 13/01/19 — Day 122
The whitepaper has been updated, read the update here.
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.
Version 486 — 17/01/19 — Day 126
This release removes dormant verifier functionality to eliminate concerns about centralization. The mesh limit was removed from the codebase entirely.
Verifier initialization process update — 19/01/19 — Day 128
This update reduces peak network traffic by changing the way node-join messages are sent. This update also ensures that a verifier has connections to at least 75% of the mesh before starting.
Security patch 1 — 24/01/19 — Day 133
A member of the community contacted the developer team after reviewing the Nyzo code. This update is a security patch and fixes an unintentional oversight in the code.
While the omission of this method in the code path for incoming blocks was a serious mistake, there are no practical avenues of attack enabled by it. Other checks in the code, intended as redundancies, were protecting against malicious transactions that might have been injected into blocks produced by other verifiers.
In version 489, unintentional overhead caused by this update was reduced to a negligible level.
Sentinel data fetching — 29/01/19 — Day 138
From this version onward, all verifiers managed by the sentinel should be protected as long as one managed verifier and one sentinel are functioning properly.
In the original sentinel, fetching of data from managed verifiers was fully serial.
Web wallet synchronization — 31/01/19 — Day 140
The web wallet now uses the server timestamp for transactions instead of relying on the client. This mitigates client clock synchronization issues.
On the same day version 491 was released which removes a small part of debugging code.
Genesis block script — 10/02/19 — Day 150
Release 492 corrects an issue with the creation of the first cycle of a new blockchain (for example, a testnet). It adds a script for generating a new Genesis block to start a new blockchain.
It is only of interest to those wishing to start a testnet or a new blockchain.
Spam protection — 21/02/19 — Day 161
The next release adds mechanisms for eliminating transactions that could be used to add many small accounts to the balance list (and thus inflating the computational stress which the network is under). To limit the balance list to a reasonable size, rules are added to filter out transactions that might be used to create many small accounts in the system.
Subsequent version 494 places additional limits on the size of the transaction pool.
Stability improvements — 22/02/19 — Day 162
Version 495 improves the stability of the verifier through improvements to the mesh listener, which was too lenient with incoming connections. This update ensures that connections are closed in a timely manner as to mitigate the risk of an attacker disabling a verifier.
Blacklist update — 26/02/19 — Day 166
Next up is a small update which affects the dynamic blacklisting process. The maximum concurrent amount of connections originating from an IP has been increased.
Subsequent version 497 adds whitelisting to the concurrent-connections check.
Transaction deduplication & validation — 02/03/19 — Day 170
Release 498 improves transaction deduplication and initial validation.
Nyzo uses Ed25519 for digital signatures, while this is a modern and well-understood digital signature system, its signatures are malleable and malleability presents potential concerns that a valid transaction can be duplicated in the system.
Secure systems should not be engineered with the minimum required for security. Secure systems are engineered with layer upon layer of assurances to reduce the probability that unforeseen issues in one layer compromise the integrity of the system.
With that in mind the process for deduplicating transactions now considers every byte of signing input in addition to the signature itself.
Block-file consolidation — 03/03/19 — Day 171
Release 499 corrects issues with the block-file consolidation process.
The issue was causing some transactions in historical blocks to be removed from those blocks, thereby corrupting the blocks during the consolidation process.
Despite this bug there are multiple complete, valid, independently verifiable copies of every block and every transaction since the beginning of the Nyzo blockchain.
Nickname manager update — 07/03/19 — Day 175
The next release corrects a minor stability issue with the nickname manager. A maximum size has been implemented to keep verifiers from stuffing the nickname field with large amounts of data and potentially causing memory management issues.
Subsequent version 501 corrects additional blacklist issues in the mesh listener class.
Lottery entrance mechanism — 17/03/19 — Day 185
The automatic-voting logic in this version is a lottery based on a recent hash in the blockchain. While it still uses node-join timestamps to protect against the equivalent of buying a lottery ticket after numbers have been drawn, the relatively short timescale involved in the new calculation virtually eliminates vote scattering.
The process for determining which new verifier to admit remains democratic in this version, but the default logic for calculating a verifier’s vote has changed. Previously, the default logic attempted to establish a first-in, first-out system, but this was problematic for multiple reasons. Inconsistencies among verifiers’ long-maintained timestamp lists resulted in vote scattering, making it easy for blocks of manual votes to influence the outcome of the voting process. Also, a true first-in, first-out process is vulnerable to a single entity starting many verifiers at once and clogging the queue.
Signature handling — 19/03/19 — Day 187
A member of the community, while reviewing the codebase, found an issue with signature handling. While this issue is small in terms of the number of lines of code affected, it introduced a number of potential stability issues and opportunities for attack due to the frequency of use of this code path in Nyzo.
Consensus monitoring — 22/03/19 — Day 190
Release 504 improves visibility into consensus issues. At the time, the Nyzo blockchain had stalled three times when a new verifier was added during periods of exceptional stress for the cycle. The data we collected during the stalls was insufficient for explaining these stalls, and they do not appear to have been the result of direct failures in the consensus algorithm. In all three cases, the consensus algorithm was able to identify a clear winner with more than 50% of the vote, but the natural progression from 50% to over 75% did not occur.
Verifier performance rating — 26/03/19 — Day 194
Version 505 introduces the verifier-performance rating. A verifier scoring system is necessary to ensure that verifiers that continually under-perform to the detriment of the cycle are eventually removed from the cycle. Actual removal based on these performance scores was implemented at a later stage.
Verification timestamps — 27/03/19 — Day 195
This release adds a protection against future verification timestamps that could stall blockchain processing. If a malicious verifier or a verifier with an incorrect clock produced a block with a timestamp far in the future, this could cause the blockchain to stall until the timestamp of that block. While remedies exist for this problem, this now no longer presents an issue for the network.
In-cycle node identifier updates — 01/04/19 — Day 200
Version 507 corrects an issue with in-cycle node identifier updates.
When a node at an existing IP address is updated, the identifier-change timestamp is updated.
Removal voting system — 06/04/19 — Day 205
Version 508 begins to apply block-score penalties based on performance scores. This utilizes the code released in version 505 and generates a performance score for each verifier it stands in contact with, broadcasting votes to remove an ill-functioning verifier from the cycle after enough leniency has been given.
In addition to that an important message-replay issue was addressed and fixed.
MeshResponse update — 09/04/19 — Day 208
Version 509 limits the mesh response to in-cycle nodes only.
Future versions address the unpredictable nature of the out-of-cycle node list more thoroughly. To improve the stability and performance of the verifier, this version changes the message to return only in-cycle nodes, and it places a limit on the size of the node list.
Preliminary for UDP implementation — 18/04/19 — Day 217
This release adds inactive-by-default UDP messaging for block votes.
In the case of TCP, a new connection was established for each message. This results in significant computational, networking, and memory overhead. To improve verifier performance and stability, this version adds the option of using UDP for sending of block votes. Sending just this one message over UDP minimizes the complexity of changes while providing a significant reduction in network traffic and the local computing resources required to support that traffic.
UDP activation, performance-score tabulation delay — 21/04/19 — Day 220
Subsequent release activates UDP messaging for block votes by default and improves the accuracy of the scoring system by introducing a one-block delay between freezing blocks and counting votes.
New-verifier voting mechanism updates — 30/04/19 — Day 229
Both version 512 and 513 improve the new-verifier voting system.
Instead of a single block hash, a new hash based on a full cycle is used as a lottery reference. This reduces the influence that any one verifier can have on the lottery.
In addition to that are timestamps now linked solely to IP addresses, not identifiers. A 30-day waiting period is now enforced for any verifier wishing to join the lottery.
Version 514 corrects a vulnerability related to node-join messages and UDP.
It contains several inconsequential changes to eliminate clutter in the code.
Verifier performance and recovery — 09/05/19 — Day 238
This update improves performance of the verifier and reduces the time required to resynchronize with the blockchain after a verifier outage has occurred.
Release 516 drastically reduces the time required to resynchronize with the blockchain after a verifier outage. In testing, a verifier shut down for 100 blocks would consistently reinitialize and resynchronize within 60 seconds on a t3.small AWS instance.
Balance-list request optimizations — 12/05/19 — Day 241
Version 517 reduces the workload for servicing requests for balance lists. It adds a new request and response for providing the balance list of the verifier’s current frozen edge.
Transaction-validation for incoming blocks — 14/05/19 — Day 243
This update corrects a transaction-validation issue that could cause a chain-freezing process of version 517 to fail.
Sentinel fallback — 16/05/19 — Day 245
Version 519 adds the full mesh as a fallback data source for the sentinel.
UDP tracking — 17/05/19 — Day 246
In version 520 a field has been added to the public status response to indicate whether any UDP messages have been received. To limit the usefulness this field might have to an attacker, it is a simple yes/no value, and it does not expose any information about UDP performance of a verifier.
Node-join process, out-of-cycle performance — 20/05/19 — Day 249
Version 521 improves the node-join process and out-of-cycle performance.
It also adds another field to the private version of the status response to further aid in debugging UDP block-vote issues.
Reworking the balance-list — 23/05/19 — Day 252
The BalanceManager has been reworked in this update to be more efficient, robust and easier to understand.
Nyzo client release — 28/05/19 — Day 257
Version 523 and v525 bring the much anticipated launch of the Nyzo CLI client.
While in your home directory, run this command to start the Nyzo client:
sudo java -jar build/libs/nyzoVerifier-1.0.jar co.nyzo.verifier.client.Client
Version 525 and 526 add the ability for the client to send transactions and add the Micropay commands which are utilized at a later stage of the project’s lifetime.
Nyzo string objects — 01/06/19 — Day 261
Version 524 brings Nyzo string objects for private seeds, public identifiers and Nyzo Micropay transactions.
Nyzo strings are typed, error-protected encodings of data used by Nyzo.
The public identifier starting with id__ and the private seed starting with key__, for easy identification by wallets or other applications.
Nyzo web server for client & verifier — 13/06/19 — Day 273
In an effort to promote decentralization and to provide a foundation for future improvements, this version adds a basic web server that can be activated in both the client and verifier.
Sentinel initialization & block freezing — 14/06/19 — Day 274
Version 528 corrects an issue with the block-freezing process, and it also corrects a separate sentinel initialization issue.
Performance improvements in the balance-list manager caused two different initialization issues. One of these issues potentially affected all three run modes. The other issue only affected new sentinels or sentinels that had been offline for more than 4 cycles.
Sentinel web monitoring — 18/06/19 — Day 278
In its next release web monitoring for the sentinel has been added.
It also adds a small change to the page-refresh mechanism that affects the behavior of the verifier and client web monitoring.
Micropay Server and client — 01/07/19 — Day 290
Version 530 is a good candidate for one of the longest release notes to date, rightfully so. This update comes with a Micropay authorization server and a client, which both utilize the MicropayController endpoints made available by this update.
An example of a Micropay authorization page looks as follows. This page is served by the client and not by the remote server, this has several advantages for implementation.
Blacklisting update — 03/07/19 — Day 292
This update eliminates blacklisting for blocks received from unexpected verifiers. This change is necessary to allow the sentinel to broadcast blocks for new verifiers. This will help to avoid manipulation of the entry process with denial-of-service attacks. This change reduces the possibility of a sentinel being temporarily blacklisted due to a timing issue in block transmission.
Micropay flow, blockchain tracking — 07/07/19 — Day 296
Version 532 improves the Micropay flow and blockchain tracking.
This update improves the user experience of using the Micropay client.
The Micropay approval page now appears as follows:
Building a sustainable blockchain — 11/07/19 — Day 300
This day marks the 300 day lifespan of the network. On this day part 1 of ‘Building a sustainable blockchain’ was published. This writing however has been largely revised on 18/09/19 (more below).
Script update — 20/07/19 — Day 309
Version 533 and 534 update the HashVoteOverrideRequestScript for easier local operation.
Fallback vote source — 20/07/19 — Day 309
Version 535 adds a fallback vote source for verifiers with insufficient blockchain history for calculating their own votes.
Node mesh maintenance — 21/07/19 — Day 310
Version 536 changes mesh maintenance performed by the verifier to a timed interval.
Consensus process, transitioning preparation— 27/07/19 — Day 316
Version 537 improves the consensus process and prepares for the transition from version 0 to version 1 of the blockchain. This version does not yet attempt to correct the memory-pressure issues that initially caused verifiers to become unresponsive and slow down cycle processing.
It does attempt to correct, from multiple angles, the stalls and ultimate one-block fork that caused so many verifiers and sentinels to fail. While slowdowns in block processing are undesirable, they are of little consequence as long as they do not lead to full stalls. These memory-pressure issues were addressed in a future update.
Block file consolidator options — 28/07/19 — Day 317
This release implements the block file consolidator options. When blocks are frozen, they are written to files to ensure that they are available on restart. To make these file writes as fast as possible, each block is initially written to its own file. These individual block files each contain both the balance list for the block and the actual block.
Based upon the observations made by the developer team, the BlockFileConsolidator class was believed to be responsible for many of the verifier failures that ultimately resulted in the then relevant blockchain stall.
The consolidation process has been improved in a future version to allow it to consume significantly lower compute resources than it does now while performing all the operations it currently performs. This version provides control over which parts of the consolidation process are performed.
This will allow operators of verifiers to decide, based on their personal preferences and situations, how to best use the resources they have available to keep their verifiers as healthy as possible.
TCP-management — 01/08/19 — Day 321
Version 539 improves management of TCP connections to better constrain memory usage. Nyzo is a communication-heavy system. To eliminate the potential problems associated with maintaining open connections within the mesh, a new connection is established for every message.
Some of these connections were not closing properly and this update resolved that by using a queue and methods of removal from the queue to accurately close connections.
Sentinel monitoring and performance — 06/08/19 — Day 326
Version 540 improves sentinel monitoring and performance.
Join process and bug fixes— 13/08/19 — Day 333
Version 541 includes improvements to the join process and some minor bug fixes. This update ensures that the new-verifier entry requires the majority of votes to succeed.
Blockchain transitioning, cycle transactions — 31/08/19 — Day 351
Version 542 completes the version 1 blockchain changes and basic cycle-transaction functionality. This is by far the largest update so far and details the framework for cycle transaction generation, voting, listing and processing.
Consensus tracking, sentinel monitoring — 03/09/19 — Day 354
Version 543 adds optional consensus tracking and a small sentinel-monitoring change.
Version 544 corrected an issue that caused a sentinel to fail. The problem that caused sentinels to fail was simple. In order to avoid blacklisting, many sentinels on 541 or later were not transmitting blocks. The errant code was introduced in version 476, but it did not cause improper behavior until version 541.
Version 545 adds a small sentinel monitoring improvement and minor changes to the way consensus is tracked. An active sentinel running the monitoring interface is accessible at quark.nyzo.co
Performance score and client transaction improvements — 15/09/19 — Day 366
The Nyzo blockchain now exists for one year, 99 updates have been rolled out and 360 pages worth of release notes have been written. Right around this time another updated was rolled out which added a maximum performance score and improved the process that the client and Micropay server use to send transactions to the cycle.
On September 18th, ‘Building a sustainable blockchain — part 2’ was published to the website, rewriting what was previously written two months prior in part 1. This announcement details how the developer’s funds are forfeited in the hands of the cycle (77,120,397 nyzo) and is later followed up by said announced deposit to the cycle fund address.
Relevant release notes down below detail how those coins are locked up.
Sentinel broadcasting — 22/09/19 — Day 373
Version 547 gives the sentinel the ability to send blocks for verifiers joining the cycle.
In order to maintain robust protection for in-cycle verifiers, the sentinel must have a separate process for determining which out-of-cycle verifier to assist. However, knowing which verifier to assist requires knowledge of new-verifier voting, which is only available to in-cycle verifiers.
While many users trying to join the cycle already have in-cycle verifiers, many others do not, so this raises concerns about potentially more-effective behavior for sentinels that have access to in-cycle verifiers. Such behavior would hurt cycle diversity, which makes it unacceptable.
The solution contained in this version is, fundamentally, a brute-force solution. At appropriate times, the sentinel sends blocks for every out-of-cycle verifier it manages. However, these transmissions occur selectively, efficiently, and at a time when cycle messaging activity is at a relatively low level. So, they will not adversely affect cycle performance now, and they will not adversely affect cycle performance even if the queue grows to be substantially larger than it is now.
Completed funding of the cycle account — 30/09/19 — Day 381
On this date, all developers’ coins were forfeited into the hands of the cycle.
Queue verifier update— 02/10/19 — Day 383
Version 548 eliminates the use of queue verifiers as data sources. This update will improve the health of the queue and provide a basis for further improvements.
In-cycle verifier recovery procedure — 11/10/19 — Day 392
Version 549 adds retrieval of blocks behind the frozen edge to enable faster recovery for in-cycle verifiers. It substantially reduces the network usage of out-of-cycle verifiers as well.
On the 18th of October 2019, Nyzo string support was added to the wallet and key tool web page.
Variable per-block transaction limit — 28/10/19 — Day 409
Version 550 adds a variable per-block transaction limit to the block-assembly process. The baseline rate is 10 transactions per second, which is 70 transactions per block. Each additional Nyzo in standard transactions, on average over the previous cycle, increases the block capacity by one transaction.
At this point, it is worth noting that Nyzo was tested before release to support exceptionally high transaction rates — more than a hundred times the baseline rate. A larger cycle does tend to place higher computational demands on verifiers, but those demands are not proportional to block size. In fact, the predictable nature of which verifier will likely be responsible for each block makes a larger cycle an asset with respect to sustained transaction throughput.
The baseline rate is simply a protection to keep verification profitable for verifiers. Do not misinterpret the low baseline rate as a sign that Nyzo cannot support significantly higher transaction rates.
The ability to support larger blocks and higher transaction rates is mostly dependent on the computing capacity of verifiers, and this ensures that verifiers will not be forced to upgrade to more robust hardware to deal with huge, brief spikes in transactions or sustained periods of miniscule transactions.
Cycle transaction signing — 07/11/19 — Day 419
A web-based interface was added to the website for signing cycle transactions. This, in addition to the interface available through the client and the signing script released in version 552.
Additionally, version 551 corrects an issue with cycle transaction registration.
Documentation server — 24/11/19 — Day 436
Version 553 adds the documentation server, which was prioritized due to the need of instructions for cycle transactions and a desire to avoid adding yet another instruction page on the main website.
This documentation server also aids decentralization as all nodes have the documentation and server at hand to host the content themselves. Instructions for running your own documentation server are available here.
Cycle transaction handling — 27/11/19 — Day 439
Version 554 improves cycle transaction handling.
Configuration scripts — 29/11/19 — Day 441
In version 555 the configuration scripts were updated and a handy list is now accessible here.
Client initialization improvements — 02/12/19 — Day 444
Version 556 improves the client initialization process.
Subsequent version 557 adds support for the icon file extension (.ico) and improves handling of stylesheets on the documentation server.
Browser-based client user interface — 12/12/19 — Day 454
In version 558 a web based user interface has been released for the client.
This version introduces a large volume of code, but the code does not affect the core operation of the blockchain, so it does not need to be held to the same standards of scrutiny and testing as such code would. Please be aware that, while this interface is accessible in a web browser, it should not be run on a remote server.
NTTP sender data generation — 20/12/19 — Day 462
Version 559 adds NTTP sender data generation to the client. It also introduces the normalized sender-data string.
Per-block transaction limit — 22/12/19 — Day 464
Version 560 adds a per-block transaction limit to the consensus voting process.
In version 550, a per-block transaction limit was added to the block-assembly process. However, verifiers that have not upgraded will still produce blocks without regard for that limit. Block 5745501 contained 101 transactions, which was 31 transactions over the specified limit at the time.
As long as even a single verifier is producing blocks that do not respect the transaction limit, and as long as the cycle is accepting those blocks, the cycle is vulnerable to spikes in transaction volume.
This version eliminates that vulnerability by adding a transaction-limit calculation to the consensus vote calculation.
This update is a wonderful opportunity to observe how Nyzo’s consensus process operates. Unlike the blockchain rules that strictly define valid and invalid blocks, the consensus scoring process operates on preference and time. A verifier generates a score to rank preferences. This score is used to choose a most-preferred option independently, and it is also used to decide whether an emerging consensus deserves this verifier’s support at the current moment. These rules allow the blockchain to move forward as new consensus rules are introduced, gradually applying and strengthening the rules over time as the cycle adopts them.
Client API endpoints — 31/12/19 — Day 474
Version 561 adds API endpoints to the client.
Supervisor script — 01/01/20 — Day 475
Happy new year! 2020 brings a script to generate a supervisor configuration file for the client.
Version 561 introduced the client API for Nyzo, and an instance of the client was started at client.nyzo.co. This version adds a script that is necessary for creating an instance that is identical in function to the client.nyzo.co instance.
HTML rendering of client results — 08/01/20 — Day 482
Version 563 brings proper rendering of client results to enhance the user experience.
Version 564 brings a transaction search command to the client to further enhance user experience.
Today
As you can see, the development of Nyzo is ongoing, and that is not an overstatement. The underdog of the bear market is here, and it’s here to claim its market share. If you like what you see and you want to get in touch with the people behind this project, feel free to join the Discord community or follow nyzo_currency on Twitter.
Qtrade.io is currently the most popular exchange used today to trade Nyzo.
More information down below.
Stay tuned for more on:
Nyzo.co — official website, made by the anonymous developers
Nyzo.net — unofficial website, made by a community member
Nyzo.io — unofficial website, made by a community member
Nyzo.today — unofficial website, made by a community member
@nyzo_currency — Twitter, unofficial
@nyzogang — Twitter, unofficial
@nyzo_io — Twitter, unofficial
