LISK! Very important updates LISK!!!

artsteemit (44)in #lisk • 8 years ago (edited)

Today, we want to take the opportunity to explain the different phases we intend to put Lisk through over the next few years, and the various milestones we want to achieve for our users, developers, and the ecosystem overall. In total, there are 5 phases called: Inception, Resilience, Expansion, Ascent, and Eternity; each with its own milestones, goals, and focus.

This post gives you an overview of the major changes and features; it won’t include every granular change or addition. There will be many more changes along the road, so it wouldn’t make sense to describe everything within this blog post. This means every bullet point in this roadmap isn’t a single, simple feature. It’s a milestone which might require several Lisk release cycles (versions) to be achieved.
The bullet points and plans outlined in this post, might change over the coming months and years, as development isn’t a fixed process. Ideas evolve over time, and we might even find better solutions in the future.
The given plans are intended to be long-term, and we estimate that they will take at least a few years. Due to the dynamic nature of software development, we don’t want to forecast any dates, or deadlines from now. It should also be noted, milestones within a phase might be worked on in parallel, and once we establish development speed through a constant release cycle, we will be in the position to give more accurate timelines.
During the last four phases, we are intending to work on blockchain applications, which were previously announced as Core Apps. We will give further details on these applications later on.

I. Inception
We are currently operating within the Inception phase, which contains three major milestones, and has a focus on stability and some basic groundwork. It prepares Lisk for community forging and blockchain applications development.

Mainchain stabilisation
The most important milestone for many users this year is the stabilisation of the mainchain, and the subsequent activation of community forging. With that, we will also enable forging rewards so that delegates are able to finance community projects, and foster a growing ecosystem.
Merging Lisk-CLI into the Lisk App SDK
The Lisk-CLI tool in its current form will cease to exist. We will rewrite the application, and merge its functionalities directly into the Lisk App SDK, providing a self-contained development package, and reducing our development effort from two repositories to one. The planned merge and rewrite of Lisk-CLI, will make blockchain application development easier to manage, and also lower the barrier to entry for new developers.
Lisk App SDK stabilisation
Stabilising our sidechains and making it possible for developers to start working on blockchain applications, is a major step towards achieving one of Lisk’s core goals. We shall therefore undergo major changes in our Lisk App SDK, making sidechains not only stable, but also reliable.
During this step we will split every sidechain into a single, independent database. As of writing, every installed sidechain has their own tables within the same database as the mainchain, this comes with many disadvantages. Running every sidechain in its own separate database allows developers to achieve high scalability independent of the mainchain. It also makes everyday sidechain administration easier and straight-forward.
Another important task is the implementation of a secured and protected virtual machine for blockchain applications. This way the JavaScript code of the application will run in an encapsulated environment, securing the computer from any harmful application.
Currently, sidechains also need to be verified whenever they are launched. We will implement the same quick-load feature as it exists on the mainchain, and remove the need for constant re-verification, making sidechains easier to administer and deploy.

II. Resilience
Resilience drastically improves Lisk and enables it to become a serious blockchain applications platform, with a more elegant core system, an even better Lisk App SDK, various useful features, beautiful and easy user interfaces, and a major focus on security. Resilience is definitely the biggest phase of all, with a total of six major milestones, and is intended to set Lisk apart from any other cryptocurrency on the market.
Rebranding
Lisk will go through a complete rebranding of its ecosystem, which includes the logo, website, client user interface (desktop, tablet, smartphone), blockchain explorer, and everything else. This is a major effort which will take a longer time, the different parts of our ecosystem will be redesigned and updated one-by-one. For this milestone, we will get in contact with a local Berlin design agency, and work closely with them to find Lisk a new visual identity. We are striving to create a unified experience for the website, client, and blockchain explorer. To achieve this, we intend to go new ways which have not been seen yet within the cryptocurrency space. This will allow us to provide the best user experience in the whole industry, which is one of our top priorities for the rebranding. Further details will be revealed, once we begin working on this milestone.
Lisk daemon, decoupling the UI from the back end
Currently, we have the Lisk Node client which acts as the full client for the Lisk network. It is tightly coupled with the Lisk user interface, and we believe that this is not the best possible solution. It causes a lot of duplicated work code once we have multiple clients, and many of our users (e.g. delegates or exchanges) don’t necessarily require a user interface. Therefore, we will replace the current method with a much leaner and modular approach.
The Lisk Node client will be replaced with a standalone Lisk daemon that runs from the command-line only, without the graphical user interface currently provided. The intention being, to provide a headless interface to the network, that can be attached to, using a variety of thin clients.
Users simply requiring a user-interface will able to download our Lisk Lite client, and either connect to a local or remote daemon. Upon starting the user-interface, it will detect if a local daemon is running and automatically connects to it. If this is not the case, it will automatically connect to a daemon on the network.
Through this decoupling, the user interface becomes an independent project, which can then be updated much more frequently than the Lisk daemon. This means we can deliver new user interface features and bug fixes much faster than before. Additionally, one-click clients for desktop computers can now easily be provided in the same way as Lisk Nano.
Lisk App SDK modularisation
After Inception, once we have stabilised the Lisk App SDK, so that blockchain applications can be securely deployed into production. We intend to take it a step further, and modularise the SDK structure on all fronts. This will drastically improve the necessary time and user experience of blockchain applications development.
Some planned changes are:
Encapsulation of the consensus algorithms so that new ones can easily be added afterwards.
Moving the Lisk Application SDK into a separately installed node module dependency. This will allow developers to easily update to the latest SDK, and work on their blockchain application code separately.
A config file in which you can simply decide different parameters like block time, fees, consensus algorithm, and so on.
Introducing sidechain standards, so that we can begin implementing really useful sidechain features into the Lisk client, e.g. delegate marketplace, application panel, sidechain explorer, and so on. Sidechain standards will facilitate the building of universal third party applications, that can interact with any sidechain that accords with these guidelines.
Basic application features
a. Delegate Marketplace
As every blockchain application runs in its own sidechain, it needs to be secured independently from the mainchain by individually selected delegates. Lisk therefore requires a platform to connect node operators with application developers. This platform will be the Delegate Marketplace, on which delegates can make their services available to sidechains, and in return receive payment in LSK. The ideal scenario being anyone on the Lisk network can pay delegates LSK to secure a sidechain.
b. Versioning scheme and update mechanism
Applications require constant updates in order to stay secure and up-to-date. With every update the version number also needs to be incremented.
Lisk therefore requires an internal blockchain-based versioning scheme and update mechanism. Blockchain application developers can add an update with a higher version number to the mainchain, and propose it to the sidechain delegates. If consensus is reached, it will be adopted. Through this mechanism, every blockchain application will come with a blockchain verifiable version history.
Additionally, the exact file contents of each blockchain application update will be hashed and saved to the mainchain. This way blockchain application files can be automatically validated before launch, and will only proceed successfully if its integrity has been maintained. The aim being to prevent anyone with malicious intent from distributing manipulated copies of a particular application.
An example scenario being, if a developer originally uploaded the blockchain application to location A and afterwards, secretly manipulates the files at the same location A, and then users download the manipulated blockchain application instead. With the new mechanism, the application won’t launch as the hash no longer matches.
If a blockchain application developer needs to introduce any changes, they are forced to use the update mechanism, and push a new hash to the mainchain. Essentially making the blockchain application code immutable unless the update mechanism is used.
c. Application Panel
Users and developers need to maintain an overview of their blockchain applications. Lisk therefore needs a dedicated page on which they can manage them.
Possible features for users are:
uninstalling an app
viewing sidechain statistics like height, blocks, or transactions
updating to the latest version
viewing delegates
Possible features for delegates are:
all above
removing themselves as a delegate
start/stop sidechain forging
Possible features for app owners are:
all above
adding/removing delegates
editing meta data such as: description, icon, or tags
Mobile clients
Although the rebranded user interface will be completely responsive, we also want to provide native mobile clients for mainstream users. They will be extremely simplified implementations, with an aim to eliminate any complicated blockchain terminology.
In principle, they will allow you to setup a blockchain identity, send/receive LSK, and launch any blockchain application on the network. Mobile client users won’t need to synchronise the mainchain or any sidechain, because they are simply connecting to remote Lisk daemons.
Code rewrite
During the whole Resilience phase we will port over the current JavaScript code base to the super-set called TypeScript. The core reason for this being to add support for static typing to both the Lisk core and Application SDK. This process can and will be done in gradual steps. In the same breath we will rewrite the code to the latest ECMAScript scripting-language specification.
The end goal being a dramatic increase in code quality, and a much easier code base to maintain for the long-term.

III. Expansion
The Expansion phase finalises the (trusted) blockchain applications platform by adding more advanced features, and support for smart contracts. During this phase we will also introduce support for third party technologies so that developers can easily implement them into their blockchain applications.

Advanced application features
a. Sidechain explorer
With the introduced sidechain standards in Resilience, we can now work on a sidechain explorer which allows users to inspect the blocks, transactions, and account balances of any sidechain. This will provide a consistent, transparent, and easy to access viewpoint of each sidechain to all users.
b. Sidechain security
For security reasons, we shall implement validated hashes of individual sidechain states, at configurable checkpoint intervals. This will ensure there is some basic validation of sidechain integrity, and provide payback to the parent network.
Smart contract support
Smart contracts are an interesting concept for many different use-cases, and we believe it would be extremely interesting to implement a smart contract VM natively into our Lisk App SDK. It’s up for discussion which smart contract languages we want to support, or if we even develop JavaScript smart contracts on our own.
Third party technology support
The beauty of modern software development, is that you don’t have to re-implement every piece of technology from scratch, instead we can use third party libraries and tools. Nowadays, there is already a good number of blockchain technologies available; like Bitcoin, Ethereum, Storj, or Sia. There are also many other interesting technologies available like Torrent, IPFS, and many centralised cloud/computation solutions.
We believe by offering bridges for as many technologies as possible into the Lisk App SDK, we will allow developers to build more useful and feature-rich applications.
Once we have started working on this milestone, we will ask our development community what kind of technologies they most want to leverage inside their blockchain applications.

IV. Ascent
The Ascent phase introduces truly trust-less blockchain applications to Lisk, and focuses mainly on security, optimisation, and scalability, in order to make Lisk (officially) ready for the enterprise and financial sectors.

Trust-less blockchain applications
If you have carefully read this blog post until now, you might have realised that you can build great blockchain applications of nearly any kind. However, until this point blockchain application developers are still able to exercise a large amount of control over their sidechains, possibly to the detriment of decentralization.
This kind of control is the preferred solution for startups who want to keep control of development, and build a business model around their blockchain applications, while also enjoying the other benefits of blockchain technology. However, some developers want to develop truly trust-less blockchain applications. Applications which can’t be shut down by any single entity, such as the developer, and are secured by anyone who wants to participate.
Therefore, we are currently researching possible solutions, one of them you can find below.
The reason that this milestone is in the Expansion phase and not earlier, is because it only consists of optional consensus changes. A blockchain application developer could make the necessary changes before the Expansion phase. Improving the App SDK, and sidechain ecosystem is the foremost objective. Existing trusted blockchain applications shall have the option of becoming trust-less, through a simple update.
Proof of Stake
We think that a Delegated Proof of Stake consensus algorithm is the best method to bootstrap a sidechain, as it is extremely efficient, and secured by a number of incentivized (=paid) actors, and maintains a degree of control over its development cycle in it’s early stages. Which in our view, provides the best solution for startups who want to build blockchain applications.
However, in order to achieve that, a delegate marketplace must be available, and the blockchain application developer, or its users are required to pay the delegates for securing the sidechain.
We also believe that a trust-less voting mechanism, as Lisk has on the mainchain, can’t scale effectively to hundreds of sidechains, as the lack of incentive to vote, and voter apathy would eventually hinder it’s long-term security.
Therefore, a Proof of Stake consensus algorithm, where everyone can simply plug into the sidechain, and start securing it, is the best method for truly trust-less blockchain applications, where even the developer themselves doesn’t have authority over consensus.
This would mean developers can not rent node operators on the delegate marketplace for their trust-less blockchain application. It would be the other way around, where we release a Sidechain Marketplace in which these trust-less blockchain applications can be promoted. Node operators are then able to browse and find sidechains they can secure. The incentive for doing so, would come from the potential to earn transaction fees, and optionally block rewards in the form of custom tokens.
Security, optimisation, scalability, and possible consensus changes
This phase puts a huge focus on the basics of the Lisk network. We will scale up and secure the whole network to such a level that it is enterprise and finance ready. Until now the Lisk App SDK was mainly targeting consumer applications, after this phase and the milestones are achieved, this will obviously change.

V. Eternity
The Eternity phase is the final step of this roadmap, and is all about governance. It includes a decentralised voting mechanism in order to add proposals, and gather opinions from LSK holders in a decentralised way.
We will soon announce a Lisk fund which will collect LSK from individuals and delegates. Once we are in the Eternity phase, these LSK will be controlled by 16 known curators in a multi-signature account. Until then, the Lisk team will manage the fund with the legal obligation to not use any of it.
The Lisk fund will act as a funding vehicle for new blockchain applications, and will guarantee the continued development of the Lisk core.

Decentralised Voting Mechanism
Everyone is able to add surveys (e.g. to get opinions on their ideas) and every Lisk holder can express their opinions, or vote for the different options. This way the whole Lisk community can practice decentralized decision making without any centralised entity dictating the outcome.
As another step, everyone can add proposals (e.g. for a blockchain application or core feature) and request LSK from the fund. If a proposal reaches consensus (enough yes votes) the curators get notified, and can release the necessary funds. This way the community can continue the development of the Lisk ecosystem, without any centralised team, and without any centralised decision making.
Obviously, the current team will continue their path with Lisk, and at this point we shall announce a second roadmap.