After some time in development witness sync is now drawing to its end, over the next day or two code will be merged into github, builds released and the first phase of witness sync activation will be set to activate on testnet this weekend.

What is Witness sync

The simple version is that witness sync is a faster way for nodes (mobile especially) to sync with the network.

The more complicated version, is that as with most of the developments we do there is much more to it than that. Witness sync can essentially be broken up into two parts:

  1. A new more efficient way of tracking the “set of witnesses” internally in the software, as well as a ultra compact method of tracking what changes to the set any given block causes. Witnesses will encode this compacted information in the header of blocks that they witness.
  2. A new more efficient way of syncing. Once this additional header information is in place, nodes that are doing an initial sync or catching up with the network after being offline for some time, can do so much faster by verifying only the witness signature for every header instead of performing the very expensive SIGMA (PoW) checks that they would normally have to perform.

The bulk of the work in this case was to get 1 functioning correctly while 2 represents where the most user visible parts will be.


What impact should I expect to see

When part 1 activates there should be some permanent minor performance improvements across the network for all nodes, especially those on lower power machines but actual synchronisation will not be faster.
When part 2 activates synchronisation should be substantially faster, especially for slower machines. The exact impact is machine dependant but on slower machines synchronisation should use as much as 250x less CPU time which will be a substantial improvement for devices like pi nodes or mobile phones, but even much more powerful machines will also benefit.

Witness sync also has a very important role in ensuring our capacity for continued GPU/ASIC mining resistance in future, should the current algorithm (which has held up well to date) ever come under threat. For those interested in this and other technical details I’ll publish a medium article in the near future with more details.


When will it activate

Part 1 changes some very complex internals to the software, and affects consensus, this means it is a hard fork and introduces the risk of the network forking etc. if anything goes wrong. As such we will be deploying this first to testnet for a reasonable time period, where we can make 100% sure that everything is right.
At the same time we have two other sets of changes that also require a hard fork, the upcoming NFT developments and the reward changes that the community has requested. Forks require a fair bit of extra overhead to ensure exchanges upgrade, to monitor that they go right and so on and exchanges are generally unlikely to be happy if we approach them with a mandatory fork upgrade every few weeks.
As such it is our intention to try and combine some (if not all) of these changes into a single fork so that only 1 (or maybe 2) forks are necessary. To this end we will be monitoring how well this does on testnet as well as our own progress on NFT development and will only be able to make a final call on which fork will happen when we have more information. However it is the intention for all of this to take place in the next few months.

Part 2 will activate at some point after part 1 and not immediately, a separate software release will be put out and any users who upgrade to that release will make use of it.


Where to from here

As testing carries on as the developer I will of course have to monitor the testing a bit, and there may be some small changes that come up, so I’m not entirely done yet with witness sync. However it will no longer be consuming the bulk of my time. I will therefore be proceeding to the next items on our development agenda, which as it currently stands are NFT development and internal discussion of the reward/halving changes, not that this is not an internal debate about whether or not to make the changes at all or some kind of attempt to undermine the changes, this has already been decided by the community and GAB, but rather just internal due diligence that these changes do not represent any unexpected problems whether those might be major or minor, as the creator of witnessing I have potential insight into how it operates that nobody else might have and no matter how confident we are it would be reckless to make any changes without first properly applying our minds and knowledge to the situation.
If any concerns do come up then this will be discussed with the GAB and ultimately the community, but the idea even then would be to keep the end result as close to the original request as possible.

How can I help?

We will be requiring some users to test on testnet, the testing does not need to be very time demanding, ultimately whats needed is to run a testnet node, to create some witness accounts on testnet, and then to periodically perform a few actions (like extending or renewing witness accounts etc.) as well as some occasional regular transactions. With a decent sized group of users putting in a few hours to do this over the course of a few weeks we should get the test data we need. You do not need super advanced skills to do this, but a little bit of tech know how (running nodes etc.) is ideal, if its something you want to participate in please join #testnet and set up a basic node for now, and more details will then follow in that channel as the week progresses.

Source: Gulden Development Team / Malcolm MacLeod


Join the Gulden Community on Slack Buy Gulden