Development

GitHub metrics

Last commits on public GitHub were made on April 16th, 2019 in shift-js repository (JavaScript library for sending Shift transactions from the client or server).

A lot of the information is private at present. Shift has also private GitHub repositories.

Developer activity (from Coinlib.io)

Changelog:

Allow to save and manage multiple accounts in local storage

Add support for message encryption and decryption

QR code from address

Shift-js update to meet client minVersion v7

Upgrade vulnerable dependencies

Various bug fixes

by Shift Team in Newsletter on April 23, 2019:

The team is currently carrying out an upgrade of the testnet version of Shift Core in order to allow the activation of functionalities that fully integrates the blockchain with the Phoenix IPFS cluster. They are now at an intermediary stage in this process, with the majority of forging testnet delegates having upgraded their nodes to version 6.9t and the cluster having been joined by peers run on systems owned by a number of members of the community. This intermediary stage was begun by switching to Shift Core v6.9t from v6.8.4t, a version that was not designed to support a major version upgrade. Following the resolution of this step, they planned to proceed with the activation of the new LOCK and PIN functions on this new cluster, by releasing the major upgrade of Shift Core v7.0t and making it mandatory for forging delegates to be running it by a particular block height.

An issue has emerged in the running of the Phoenix Cluster, sufficient enough to lead the team to conclude that their initial rollout schedule will need to be amended. In order to keep you fully informed of their progress, the team outlines the nature of the issue encountered.

The Issue

The LOCK mechanism used for the claiming of storage capacity within the Shift storage network uses a real time value in order to complete its pricing formula, with the pricing formula providing the system a means of determining the amount of SHIFT tokens required to stake a claim to a given number of bytes on the network at any given time. The process of collecting cluster statistics in order to reach that real time value is conducted in such a way as to ensure decentralization, with all blockchain peers gathering a figure for clusterSize (representing the total amount of disk space being offered by all storage node operators) from a randomly assigned Phoenix peer every 10th block. Once they each have a figure, consensus on the appropriate figure is reached by majority and subsequently written to the chain. As you may be able to imagine, in order to reach an accurate figure and do so consistently, it is necessary that all Phoenix peers are able see each other and ascertain accurate information on capacity. If this is not the case, the correct running of the pricing formula and the economic system that manages the network is compromised.

The issue the team is currently facing is that large differences in the peer lists held by some Phoenix peers have emerged. At the point of receiving a request for the clusterSize, each Phoenix peer will gather the data from the participants they see in the network, pinging the other Phoenix peers to see both how many are part of the network, and how much disk space each peer is offering: Blockchain peer A pings Phoenix peer C, while at the same time blockchain peer B pings Phoenix peer D. Following this, both Phoenix peers C and D start pinging the Phoenix peers they see and ask each peer on their peer list what diskSize they are offering in order to reach a total figure for clusterSize. Now, ideally, both Phoenix peers C and D should see exactly same peers in the network. If not, they could potentially communicate very different values for the clusterSize to their relevant blockchain peer. Technically this is not always a problem, as some tolerance for minor differences is permitted. However, it becomes a big problem when the differences occur too often and at too great a scale.

Different Phoenix peers are seeing different numbers of peers online in the network. The end result of this, is that were they to move forward with the upgrade to v7.0t or continue in the current version, as soon as the blockchain peers began receiving the differing values for the total clusterSize forks would result due to the clusterSize values now being included in the data written to blocks.

Therefore, if on Thursday, April 25th, they preceded with the activation scheduled for block 2,725,930 and commenced with writing this new and impermissibly inconsistent data, the chain would soon start forking and eventually stop. That is something they very much want to avoid.

In light of the current situation and due to the small time frame the team presently has in which to resolve the issue, they have decided it is in the best interests of the integrity of the chain to postpone the activation of Shift Core v7.0t until they are comfortable an eventuality such as that outlined above should not occur. As all peers detecting each other and correctly communicating is fundamental to the health of a peer-to-peer network that, resolving this issue definitively has now become their top priority.

What’s next?

The team will postpone the activation of Shift Core v7.0t by releasing v6.9.1t. This version, like the current v6.9.0t, runs the exact same source code as Shift Core v7.0t. Unlike these others, however, it will not include a set activation by block height. Once this is done, they will then proceed with diagnosing the issue and, when a solution is found, patch Phoenix. Following this, as soon as it is established that the majority of the Phoenix Cluster peers are running the new version, they will be able to proceed with the release of Shift Core v7.0t, which will include new code for triggering the activation according to a newly established block height.

When?

The team already has several theories that could explain what is causing the online/offline peers issue, and they are doing all that is necessary to test these theories for the purpose of getting to its root. As they are dealing with an unanticipated eventuality, it is conceivable that the issue could be resolved relatively quickly. Estimating a time frame without knowing the precise origin is inherently difficult. It is thus not out of the realm of possibility that creating a patch that fixes the issue could take several weeks. The team is asking that everyone currently running a Phoenix node remain on standby and be prepared for us to issue diagnostic patches during the troubleshooting process. Updating quickly when one of these patches is ready could help them find the root of the issue more quickly and restart the transition to Shift Core v7.0t. In addition, since the source code of Shift Core v7.0t has now been made public, they do also want to encourage any willing and able members of the community to help the team reviewing the code of the blockchain integration.

From Official Discord channel:

Ralf S (Shift President and Lead Developer) on February 1st, 2019:

“In response to the market downturn, we began minimizing team expenses a good deal of time ago. This is perhaps something that has been evident in our decision to focus on development rather than marketing. In light of that decision, we have been able to sustain progress on the Shift Project, and have the funds necessary to continue in this manner long term, if necessary.”

From Official Ryver chat:

Ralf S (Shift President and Lead Developer) on December 20th, 2018:

“Still making progress on the backend every day. But I admit it’s an awful lot of work. We’ve received various request in DM to show something to the public. But it’s mainly code work we’re doing now, no eye candy. But I guess I can share a bit of what we’re working on right now. I will paste some screens in our Discord channel.”