Decentralized Storage & Hosting Solution, and New Token Utilities Coming at the End of Q3!

Dear Community,

The last few weeks have been incredibly exciting for the Shift Team. The origin of this excitement is twofold. Firstly, we have been working on various fronts to complete several integral components of Shift’s web hosting platform, that move it into the realm of publicly accessible software. Secondly, we have redistributed roles in the Shift Team and called on outside contributors in order to bring about major qualitative improvements in our community engagement. Indeed, our excitement at the prospect of sharing details of this progress with you, the community, has been difficult to contain. It is with great satisfaction, therefore, that we can now explain in detail some of our most recent achievements.

Roadmap Improvements & Site Development Plans

 

In addition to maintaining its usual diligent routine developing the tools and infrastructure necessary to make a success of the Shift platform (with more on this to follow soon), the Shift Team has recently welcomed the assistance of community members/delegates snaticMx, and TerraBellus in improving the project’s roadmap (the first new iteration of which was released several days ago) and wider website. After throwing themselves wholeheartedly into the task, and with the guidance of Heisenberg in particular, the first of their contributions to be released are the following roadmap enhancements:

  • At the top of the roadmap page, the last date on which it was updated has been added. While subtle, this is an important point as it reflects a change in the manner in which the project intends to manage its interaction with the community going forward.Following internal restructuring designed to improve community engagement and transparency, the Shift Team has made the commitment to ensure that the community will, from now on, be updated at least every two weeks. With the ongoing assistance of the above-mentioned contributors, who have freely volunteered their time and expertise, the Shift Team considers this the beginning of a new and exciting phase of the project, during which a greater degree of participation and experimentation with Shift’s evolving technology suite will become the norm.
  • Roadmap entries are now split into two distinct types. This is done in order to better illustrate the work being carried out behind the scenes on development, as well as specifically user-acquisition focused initiatives. Switching between these two categories can be achieved by using the DEVELOPMENT and PUBLIC AWARENESS buttons at the top of the page.
  • Four explanatory tags are now available and applied to relevant roadmap entries. These are:
    • *completed; if all subtasks of an objective have been completed, the circular progress bar of the milestone will read 100%. This tag will emphasize the fact that a goal has been achieved.
    • *new; this tag will highlight where a new objective has been added to the roadmap. The development or public awareness team will have already begun working on an objective at the point at which it is added with this tag attached.
    • *priority; this tag is used to emphasize where an objective has been prioritized above all others. Tasks may be prioritized for a number of reasons, such as their completion allowing work on other tasks to progress, or to meet deadlines set by events managed by outside parties.
    • *expanded; it is possible that, while an objective has been completed, new subtasks have been added by the development team that were not initially covered in the roadmap entry. Rather than create a new item and risk crowding the roadmap, this tag is used to indicate the increased scope of a task.
    • In addition, where an objective is not marked with a tag, it simply means that it continues to be a work in progress.

    Currently, these tags are visible in the desktop version of the website but not replicated when viewing it using a mobile device. Work is continuing with the objective of ensuring that both iterations of the project site fully display all pertinent information.

  • A ‘To Be Determined’ (TBD) entry has been created to indicate that, without further research, estimating an accurate completion date for an item is not currently possible. This has been introduced to avoid the confusion that may arise when deadline estimates are made without all the necessary information.
  • Lastly, an aesthetic change has been made in the presentation of items that do not contain any subtasks. Prior to this update of the roadmap code, an item with no subtasks still retained the three dots at its foot used to expand those that do possess subtasks. This meant that buttons with no function were present, potentially leading the site’s users to interpret the lack of response as a bug. Removing the three dots, where not applicable, has thus resolved this point of possible confusion.

 

While the team believes this update provides some substantial improvements in user experience, there remain some additional changes and amendments to be made to the roadmap. These, as well as other enhancements envisaged for the Shift Project’s rapidly evolving website, will be pushed in coming updates.

In summary, through greater attention to a collaborative effort able to furnish Shift with new outlooks and many rich perspectives, the team will ensure that the roadmap, as well as the Shift Project site as a whole, pushes new boundaries in demonstrating what is possible with a decentralized, IPFS-served website. This week’s changes are just the beginning of a process, with comments and suggestions from the wider community welcome and encouraged. You can help build a better internet by providing your feedback. How would you like to see the Shift Project website improved?

Please let the team know using the project’s public Ryver #website channel.

Updated Roadmap Items

 

A project’s roadmap is, first and foremost, a means of demonstrating how the goals a project sets itself can and are being accomplished. It is no coincidence, therefore, that the Shift Team chose now to instigate improvements in the design and layout of the roadmap. Two pairs of items, in particular, represent landmark achievements that usher in breakthroughs in Shift’s development. These are:

  • Sidechains and Cross-Chain Automation

As was announced in the April 7th community update, sidechains are now running successfully on Shift’s private network. In order to show the community its active sidechain API, the team had expected to be able to demonstrate it running in a testing environment shortly after the announcement. However, while sidechain functionalities were proven to work in isolation, there were some instances found where, once combined with other functions, they ceased to behave correctly. It took Ralf a great deal of time and effort to optimize the interactions between processes and ensure that they operate smoothly, but, thanks to his hard work, the team is now incredibly happy to announce that it is producing a screencast demonstrating an operational sidechain, complete with cross-chain atomic swaps!

Though this means a sidechain could be pushed to the testnet and work begun immediately on the process of building a user interface for token transfers and a custom-built sidechain explorer, there is one last challenge the team considers it wise to tackle first: That is, determining how to best manage the deposit and withdrawal of tokens between chains for the sake of optimized user experience and security.

To fully understand the importance of this decision, it is useful to consider how the current system works. At the moment, all funds moved to a sidechain will, by default, first go to a wallet under the jurisdiction of the dApp owner (a digital escrow wallet). This prevents these tokens from being transacted on the mainchain until/unless they are withdrawn back out from the sidechain. In this instance, mitigation of the risk of double spending is achieved by maintaining a one-to-one ratio between the number of tokens withdrawn from the mainchain and the number present on the sidechain.

While the above approach offers simplicity, it does possess drawbacks. The most serious of these is arguably the fact that it results in a dApp owner having a high degree of responsibility for all the tokens present on the sidechain. This creates a situation in which they have to be trusted to properly secure their own private keys or risk the integrity of their dApp. If, for example, their keys were to be lost or stolen, it could very easily mean that all funds on a sidechain become either stuck or at risk of exploitation. The Shift development team is therefore committed to exploring alternative approaches, two of which are briefly outlined here:

    • Multi-signature escrow wallets: One potential means of more securely managing the transfer of tokens to and from sidechains would be the introduction of specially designed, digital escrow wallets: automated, multi-signature wallets that require both the user and dApp owner to sign specific transaction types. These intermediary wallets would differ from regular third-party wallets in that they would require an automated signature from the dApp owner to instigate user-signed, out_tranfers (from sidechain back to mainchain). This transaction type could only be instigated manually by a sidechain dApp user/account holder (granting them increased custody over their tokens), but, for the purpose of maintaining coherence between chains, would require the corroboration of the dApp owner.The advantage of this solution is that the dApp owner (or a malicious actor with their private key) cannot take control of funds and withdraw them from the sidechain. This makes the relationship between a dApp owner and their dApp users more trustless, but is nevertheless still a system with two distinct downsides:
      1. The dApp owner remains responsible for the signing of out_transfers, meaning that if their keys were lost, funds could no longer be withdrawn from the sidechain.
      2. The mainchain, owing to it being a separate ledger with no record of a sidechain’s internal transactions, could potentially misinterpret changes in the balance of account holders as ‘double spends’ at the point at which they attempt out_transfers.
    • Locking tokens: Another avenue to explore in the search for efficient and secure cross-chain deposits and withdrawals, is the possibility of combining the depositing of tokens to a sidechain account with the locking of a corresponding number of tokens held within your account on the mainchain. The advantage of this approach is that it eliminates the necessity of a dApp owner or other middleman being involved in token transfers to and from the sidechain, while also making multi-signing unnecessary. On the other hand, downsides include the need to find an effective means of preventing double spending (e.g. the mainchain balance should always be the total number of tokens minus the sum of all transactions sent to sidechains) and the obvious disadvantage of limiting the types of token transfers available on the sidechain (internal transfers should be forbidden).

In summary, the creation of a mainchain/sidechain token transfer system that is both secure and flexible enough to grant developers the optimal environment for deploying their dApps is an ongoing process. However, as one of the first blockchain projects to have developed working sidechains, Shift is excellently placed to accomplish this goal. Once accomplished, the team will be ready to progress with the design and implementation of a wallet UI and sidechain explorer. What is more, Shift’s progress in the field of decentralized storage and website hosting will soon afford it the ability to demonstrate to a wider audience the technological breakthroughs being made, and subsequently grant access to a broader pool of resources during ongoing dApp infrastructure development.

  • Shift IPFS Cluster Pin Manager & Blockchain Integration with IPFS Cluster

The two most important items found within the new roadmap concern work being carried out on the Shift IPFS cluster and its interaction with the blockchain. As mentioned in the community update of June 30th, the code of the native IPFS-cluster is in alpha and still suffers from design inefficiencies. It has proven to be unreliable in some instances and therefore not suitable for blockchain integration. Thus, the Shift Team has recently been working on its own method of handling cluster pinning, designing its very own Shift IPFS Cluster Pin Manager.

However, while great progress has already been made on the cluster manager, marketing Shift’s own dApp, Phantom, as the consumer-ready product the team wishes to build requires integration with a decentralized governance system: the blockchain. The Shift blockchain provides the crucial ability to record transactions, and its integration empowers these transactions to trigger storage functions on the cluster necessary to save user data and host website content. While in the test environment it is possible to pin content and receive the data hash necessary to point others to it, the IPFS daemon has been unable to call on the blockchain to determine the content owner and how it should be dispersed. As a result, a rogue operator could feasibly unpin content on their own node and see this command executed across the cluster, resulting in it being wiped from the system.

The IPFS daemon will now be modified to obey the blockchain in the regulation and verification of cluster storage through token locking, and of cluster pinning through token usage. Though a good deal of work remains to see this task complete, the Shift Team believes that they will shortly be able to introduce these two new token utilities to the testnet in the form of four blockchain transaction types. The introduction of these token functions will have a radical effect on the extent to which token holders will be able to interact with the Shift blockchain and IPFS storage cluster. These transactions types are:

  1. A LOCK transaction that sends a designated amount of Shift tokens to a virtual wallet where they are stored as a form of collateral, guaranteeing the corresponding amount of storage space is available to the account/wallet owner.
  2. An UNLOCK transaction that returns the debited tokens and releases storage space back to the IPFS cluster’s data pool.
  3. A PIN transaction. This creates a record on the mainchain containing the asset hash and asset size as data entries. A pin request simultaneously records on the blockchain the individual who sent the transaction (rendering them the only one capable of dictating its distribution across the cluster). It is necessary to have locked enough Shift to the account for the asset size contained in the PIN request.
  4. An UNPIN transaction. This creates a record on the mainchain that is read by the cluster as a cancelation of the relevant PIN transaction, and instructs it to free the user’s storage space, allowing them to grant it to other assets.

Information on the fees necessary to carry out these transaction types will be revealed in more detail at a later date. Regarding storage usage, at least initially, locking disk space will require a quantity of Shift equivalent to the amount of space used at a fixed, predetermined rate. Eventually, however, the team envisages introducing a smart tokenomic system for dynamically calculating the stake required to secure storage space.

These four transaction types, in granting users the power to carry out vital services on a blockchain integrated platform, has brought the project to an important juncture. Due to the significance of the development of these new token utilities, the Shift Team believes it is now ready to make a major announcement.

Q3 Announcement: The Upcoming Testnet Release of Shift’s Decentralized Storage & Hosting Solution

We, the Shift Team, are proud to announce that we expect to have a functioning, decentralized storage solution complete and deployed on the testnet by the conclusion of Q3, 2018. Shift, through its Phantom dApp, is achieving what many projects within the blockchain space have not managed to do, the development of an ecosystem in which its token has a legitimate and compelling use case. In order to increase the speed of this development, we have decided to incorporate all the transaction types necessary for our Phantom dApp to function into the mainchain. This removes a major hurdle in the process of getting Shift’s decentralized storage and web hosting platform into the hands of our users. What is more, in order to demonstrate the simplicity of using the Phantom dApp to host content, we will shortly be releasing a video that shows it in action and demonstrates how you too can have a taste of the decentralized Web.

It has been a long road bringing us to this point and much work remains yet to be done, but we believe we have come to a major turning point in our journey towards implementing a decentralized internet. Ahead of us lies numerous hours of testing, as well as the addition of many more functions and initiatives necessary to bring our technology to a mass market, but we are extremely optimistic about the future of the Shift Project.

Sincerely,
The Shift Team

Leave a Reply

Your email address will not be published. Required fields are marked *