Ensuring verifiable communication between nyzo node operators by designing and deploying an authentication protocol

Published on


This article shares the motivation and goals pertaining to the development of an authentication protocol which enables nyzo network participants to communicate in a verifiable manner. It touches on how verifiable communication is established, how the protocol is defined, how it is - and should be - deployed, possible variations & concludes with a synopsis of observations in regards to the nyzo network.

Motivation

The nyzo network is a blockchain (distributed computing) network with low emissions which prospers when the governance characteristics and its benefits are given ample opportunity to become and stay reality.

The decentralized network exists since september of 2018 and has operated flawlessly, barring chain halts which do not last more than 1 day, up until 27/12/2023; proving that the protocol and its community of node operators, even in its early stages of experimental purpose, managed to provide 5 years of transactional services to balance holders.

To keep the purpose of this article succinct, and in order to provide a common ground for persons whom are unaware what nyzo entails, I'd like to refer to (just one of many) available articles about the nyzo network and its proof-of-diversity consensus protocol, and specifically an interview between Chase and others & the, now defunct, official Nyzo team; which details what Nyzo is, and what it aims to provide (archive mirror).

During december of 2023 the overall "health" of the in-cycle node operator set as a whole started to dwindle rapidly, a large amount of in-cycle nodes were intentionally not active anymore and as a result, the minimum of 75%* block votes to produce a block could no longer be achieved, resulting in a chain halt. Around the same period the seed funds were entirely depleted, leaving node operators only with transaction fees as a source of income, not an ideal situation in times of low transactional volume.

One can debate extensively about the node operators' intent and motives, yet what is certain is that these node operators have shown not to be interested in reconciliation. Communicating the need for reconciliation and discussion through the social media avenues through which early node operators were likely to be informed about the existence of the nyzo network have been proven to fall on deaf ears for months on end.

At the start of the current year, 2024, I reached out to the core nyzo team with some questions/suggestions on how to tackle the problem. They promptly responded with multiple snippets of code which lowered the required amount of block votes to >50%, and more aggressively removed in-cycle node operators with a low performance score from the cycle. These changes were accepted by construct0 (me), and made it into v644.0 on the nyzoVerifier fork of the construct0 organisation.


The changes laid out in v644 created by the construct0 organisation, which is a fork of the official core verifier codebase, resulted in a very low amount of adoption by in-cycle node operators, which is understandable for a fork of a codebase, and for an organisation without track record, yet with each additional day that passes without discussion concerning reconciliation and resolving the chain halt the need for additional enablers for potential reconciliation increases.

On January 25th a node adopting the v644 version produced a block (1 block), while the < v644 nodes did not consider this block created with < 75% of block votes as valid, resulting in a soft-fork. On the 16th of February, three (3) more blocks were produced on this fork. None of these blocks contained transactions, meaning the balance lists between both forks are the same (at the time of writing).

The GitHub repository of the core nyzo team was archived on the 15th of February and all available infra on nyzo.co went offline. Myself and others thank you for the long-lasting dedication.


Goal

First and foremost the goal is to make reconciliation easier for node operators to achieve; with the ultimate goal of agreeing on incentives, adjustments to the consensus protocol; in order to restore the network to a consistently functional state again. 

The nyzo.org platform, developed and managed by construct0, aims to provide a medium for node operators to communicate verifiably and by which means it is facilitated.


Verifiable communication

Due to the halted state of the network, on-chain communication (leveraging the available sender data space to store text permanently onchain, thus providing a verifiable and permanent means of communication) is not possible for the time being & an additional protocol had to be designed & deployed.   

The characteristics and constraints of the solution for providing a verifiable means of communication constitute:

  • A) A (nyzo) private key holder signing a message, of which the content is unambiguous and configurable
  • B) The resulting signed message being shared with the service provider (i.e. nyzo.org)
  • C) The service provider validating that the public identifier has signed this message and that it is valid and active at the point of reception
  • D) The service provider returning a session token, saving the signed message as to not result in a session token being provided more than once
  • E) The private key holder using the session token to perform actions (stored as a cookie)
  • F) The service provider making action-bound information, accompanied by the public identifier and the signed message, public
  • G) An observer verifying that the public identifier & signed message are indeed valid, proving session authenticity at the time the action was performed

In and of itself this approach is not an infallible guarantee of verifiability, namely the following characteristics are exhibited:

  • 1) The service provider can alter the history and future by misappropriating a (previously) valid session to an action of choice
  • 2) The maximum session token validity may last too long, increasing the risks associated and brought forth by cookie/session hijacking 
  • 3) The action itself is not signed, providing only an indicator of intent in regards to the aim of performing an action on the service provider's domain

These problems could be combated, namely by:

  • Having the private key holder sign a message for each action performed

Yet this is not how modern-day authentication systems work, and would result in more friction for the end user. It requires repeat exposure of your private key to an environment, to perform an operation (signing), which must be performed as diligently as possible (content validity; i.e. do I wish to sign this content, compatibility with a service provider's constraints and policies; e.g. delivering the signed message within a certain time window).

As a service provider, the implementation which nyzo.org abides by is one of a session being created as a result of a verifiable signed message (A-G). Should this approach not garner the desired adoption, the development of per-action signing, and tools in order to do so, will be considered for development. 

When creating sessions using your public identifier and signed message, you can manually configure the lifetime your session should have, with a maximum of 7 days on nyzo.org. It is possible to create a session for, e.g. only one minute, and to perform an action in that minute.

To further alleviate any possible concerns regarding the aforementioned session implementation; should this approach not garner the desired adoption, and before per-action signing is considered; it will be considered to relay new sessions and actions performed using that session to a third-party provider, i.e. each session creation and action performance event results in a new issue within a new and dedicated construct0 GitHub repository. 

With that in mind, a middle-ground rebuttals repository has been created on GitHub, users may create issues, forks, and pull requests containing signed messages to create a rebuttal against the information provided by nyzo.org. These must be well-founded and just. Both open & closed issues are publicly accessible on GitHub.

To conclude:

  • The decision to work session-oriented is mainly due to common session authentication practices, the user-friendliness it offers, and the need to handle your private key (used to sign) less frequent than necessary.
  • An approach similar to that of the nyzo micropay chrome extension was considered, but was determined to be unsuitable due to the above-average value which an (in-cycle) private key holds. Micropay operations using the extension and the private key associated with it should/do not contain a significant balance and should not be the private key of an in-cycle verifier.
    • Consider such a hypothetical browser extension which handles (in-cycle) private keys and action signing, it is not desirable to store said private key in the extension's browser/local storage unencrypted; neither is it desirable to encrypt it using a password as you would be unnecessarily relying on the extension's encryption logic and the browser's security.
  • In any case, this approach is an improvement compared to having no communication medium with verifier verifiability. 
  • The actions concerning the chat on the Discuss page of nyzo.org result in a new public message being sent while signed in (session is active), and self-authored message updates (spoiler-hide, report). All messages are incorporated into the message view without gaps id-wise. An endpoint is available which returns an individual message content and associated session & user details, one could automatically archive these using e.g. archive.today or web.archive.org to prove that a particular message id had a particular content. The appropriate response headers are present to allow cross-origin requests.
  • A session may be ended by the user before the message expiration timestamp embedded within the signed message content has been surpassed. This does not invalidate the signed message itself but is an additional feature nyzo.org offers to end users.

Apart from the possibility of per-action signing, an element of trust is present, which can be alleviated by the additional developments mentioned, or by relying on the established third-party to provide accountability and verifiability timeline-wise.

Should the network process transactions at a reasonable interval again in the future, the development of the infrastructure required for accepting on-chain transactional messages using the sender data could commence & the off-chain session-creating approach as explained above will become dormant and inactive.

Protocol

This short section explains the rules & formatting pertaining to the message itself or the handling thereof, said message is signed by the private key holder in order to obtain a session token from a service provider (preset for nyzo.org).

In any case the message signer is expected not to share the public identifier and signed message with anyone, nyzo.org creates a new token for a new and valid pair of public identifier and signed message and returns said token once to the user.

Subsequent attempts to obtain a token using the same public identifier and signed message fail. A token can still be obtained should the pair be rejected, if the signed message itself is valid and the message content proves message validity.

At the time of writing the only endpoint through which your pair is shared by the nyzo.org platform is when chat messages are queried by others, and which have been sent using a session for which you have obtained a token, indicating that the pair has been accepted and incorporated and that the token for this pair can not be issued to anyone else.

To avoid user error, never share your public identifier and signed message pair.

The format of the message which the private key holder signs is:

  • [SESSION::domain::publicIdentifier::FROM::timestampSeconds::UNTIL::timestampSeconds::END] 
    •  whereby
      • domain (fqdn)
        • e.g. 
          nyzo.org
      • publicIdentifier
        • e.g. 
          3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c
      • FROM timestampSeconds
        • e.g.
          1715536472
      • UNTIL timestampSeconds
        • e.g. 
          2015536472

Resulting in:

  • [SESSION::nyzo.org::3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c::FROM::1715536472::UNTIL::2015536472::END]

The message content is as unambiguous as possible, necessitated by the fact that signed messages are valid indefinitely. Not only must the public identifier used to sign and the signed message correspond, the public identifier must also match the one embedded in the message itself.

The domain clarifies where this session grant is valid, and the FROM and UNTIL unix timestamps (in seconds) depict the start and end of the signed message's validity. It is possible to create a valid session whereby the FROM timestamp predates the current time, a service provider is expected to handle this correctly.


 

Furthermore

In regards to verifiable communication, there are worthwhile alternatives on the table should this approach not result in a reasonable amount of adoption by node operators.

I'd like to highlight that the upcoming nyzo.org off-chain poll system, to be situated on the discuss page, will be in development given a reasonable amount of community interest and that this feat will uphold & enforce a more stringent approach which corresponds with its importance, it being:

  • instead of relying on an existing session, in order to cast an off-chain vote, a distinct message destined to resemble a vote must be signed by the private key holder

This guarantees that each vote has been explicitly cast by the private key holder. It is important to mention that even this approach does not meet the standards which would be the result of conducting these operations on-chain, as a previous vote may be invalidated or conflict with one created & cast at a later point in time. 

Thus:

  • due to the operation being off-chain, a private key holder can (should) only relay a particular vote once, and can not deviate from it, as that would invalidate any and all votes for that private key holder pertaining to the specific poll at hand

Thus:

  • a) a vote is final, so long as no other votes exist
  • b) a new poll can be created, purportedly identical in its intent, & which allows (and expects) for, and of, private key holders to cast a singular vote, which may or may not differ from a previously cast vote for the poll of which the new poll derives of

Should the nyzo.org platform witness any private key holder casting more than one vote for a particular poll (by receiving it through the appropriate endpoint), it will nullify the significance of all votes of that private key holder for that particular poll.

The same principle explained in the previous section of this article applies; should any node operator or otherwise nyzo private key holder have the desire of creating a rebuttal which purportedly conflicts with the information or its representation made available by the nyzo.org platform, and in particular but not limited to those pertaining to off-chain message signing and provisioning operations; one can use the repository on GitHub to create a rebuttal; and this by opening an issue, fork, or pull request and providing it with a valid signed message containing a well-founded and just rebuttal.

Deployment

A rough overview of the backend implementation on nyzo.org:

  • the signed message must be cryptographically verifiable, the public identifier must be the signer of the signed message & the content must adhere to the formatting as defined in the Protocol section
  • the platform determines the earliest validity associated with the signed message, it being the moment in time when the pair was accepted and a token was returned to the requester
  • the session must be valid and active at the time the token is requested, if not, the session token request (=signing in) will be rejected
  • a session may be ended prematurely by using an active session token (logged in session), ending either the current session or all active sessions for that public identifier at once 
  • a maximum amount of active sessions per public identifier is enforced  

The session token generation & storage aspects are closed-source and withheld.

Looking forward

Future of the nyzo network

There are multiple observations worth mentioning
  1. Uncertainty about which entity controls the most in-cycle verifiers, both in absolute figures as percentages compared to other in cycle node operators
  2. Uncertainty about why the core nyzo team withdrew
  3. The lack of current short-term incentives due to low transactional activity & the depletion of the seed account and the additional seed transactions
  4. Uncertainty about what needs to happen to be relevant within the industry & adjacent industries 
  5. Uncertainty about the motive of the node operator(s) whom intentionally stopped voting and producing blocks (i.e. no verifier instance)

(1) "Uncertainty about which entity controls the most in-cycle verifiers, both in absolute figures as well as percentage wise compared to other incycle node operators"

The consensus mechanism of the network is dubbed "Proof of diversity", yet it was revealed that, presumably due to the conditions of the bear market and multiple events occurring during that period, one of which was the publication of observations made by the core nyzo team, that it became feasible for an entity to control a substantial share of in cycle verifiers.

The diversity of the network remains uncertain, and it always will be, yet we have a >5 year history of node operators joining and leaving the cycle which we can leverage in the sense that we have the ability to give these individuals the opportunity to join the cycle again with priority.

A month before the network halted, I shared 3 JSON schemas and a small amount of commentary about their purpose, which would enable the aforementioned.

(2) "Uncertainty about why the core nyzo team withdrew"

(3) "The lack of current short-term incentives due to low transactional activity & the depletion of the seed account and additional seed transactions"

I can accept that once there is no longer an incentive for in cycle verifier node operators to maintain their instances, that they may choose to not care about the network anymore.

What is hard to accept is that the cycle was capable of approving additional seed transactions within 1-2 days after the n-y-z-o team proposed this extension of native incentives - while at the same time, once those transactions were depleted as well, stopped caring altogether and don't even bother to sustain the network.

What you do with your coins is your business - but the flagrant display of greed, as demonstrated by the quick consensus to distribute 100,000 extra nyzos - and subsequent withdrawal when the network health is having rainy days is disappointing.

The current in cycle verifiers want to be rewarded for keeping the instances up and running, and that is normal. But with a consensus mechanism which deviates from the standard PoW and PoS attitude whereby the network doesn't actually care or need you beyond the compute which you can provide - the responsibilities are greater but so are the benefits.

What was historically considered a solution for:

  • PoW's inability to reach consensus on anything governance related, as is proven by cash-grab bitcoin forks propping up, profiting from entities dissatisfied about the direction of the bitcoin network.
  • PoW's inability to fix its slow transaction speed
  • PoW's inability to make the Lightning network the standard, and thus maintaining their toxic pollution and ever-growing share of global electricity consumption just to validate transactions at snail pace, exacerbated by speculation, leading to even more pollution
  • PoS's inability to be democratic

Is now labelled a failure because the in cycle verifiers are dissatisfied by incentives or purported errors which lasted long enough to warrant not even communicating about it.

(4) "Uncertainty about what needs to happen to be relevant within the industry & adjacent industries "

It has been mentioned in the early days that the period in time during which the democratic community fund is available to be distributed to further development of the nyzo ecosystem, is of importance because of and in the following ways:

  • should the cycle transactions distributing coins go towards endeavors which aren't substantiated and founded enough, then there is no impact on people involved, developers involved, price point and no "drive for competition"
  • should the aforementioned bullet point reoccur over and over again for an extended period of time, and the aforementioned individuals and entities - price point - and drive/need for competition stagnate or even result in the opposite effect, then the opportunity to leverage said community fund diminishes
    • and this until we see a scenario like at the current moment in time, the price point has dropped and the community fund has less leverage to make things happen in the future, cycle transactions are thus likely to distribute a higher amount of coins - which may be met with more resistance as it inflates the coins in circulation at a faster pace
 What could/should have happened is:


When it comes to being relevant in different industries beyond the investment and emerging technologies' speculative sectors, embracing the fast transaction speed of the network and combining it with existing platforms which thrive on real-time interactions appears to me to be of the most importance.
Due to the network being halted and the communicative channels falling silent, elaborating further about this at the current point in time is of no interest to me. 

(5) "Uncertainty about the motive of the node operator(s) whom intentionally stopped voting and producing blocks (i.e. no verifier instance)" 

 
Thanks for reading.
Benjamin

Comments

Post a Comment

Popular posts from this blog