Everything You Need To Know About Lisk Mainnet Migration

The Lisk Mainnet will migrate soon to the updated Lisk protocol, which includes all the Lisk Improvement Proposals (LIPs) from 0001 - 0036.

The network will migrate by updating to Lisk Core 3.0.0, which will result in a hard fork, and will be the largest network migration to occur in the Lisk network so far. The launch of the new Lisk Mainnet will introduce various substantial changes in the Lisk blockchain, more information can be found in the previous blog posts:

There are various updates and adjustments that need to be performed by the different stakeholders in the Lisk ecosystem to remain compatible with the Lisk Core 3.0.0 blockchain. This blog post explains how to prepare for the Mainnet launch of Lisk Core 3.0.0, in order to achieve a smooth and easy migration to the updated network.

Tool & Service Migration

Tools and services relying on the Lisk blockchain will need important updates to stay compatible with the Lisk network after the hard fork. This is particularly important for exchanges, wallets, staking services, blockchain explorers, and other third-party services, e.g. payment providers.

The resources mentioned below are intended to provide an overview of the most important changes and how to update your tools & services accordingly.

The Lisk community has developed a lot of helpful community tools in the past, which provided various useful services to other community members. We would like to take this opportunity to thank all of you for the variety of unique and outstanding contributions, and further to encourage you to prepare for the upcoming hard fork, and finally ensure all of your tools are upgraded to be compatible with the new protocol changes.

For everyone who developed a proof of concept blockchain application with the Lisk SDK on versions 4.0.0 and below, it is highly recommended to update your applications to version 5.1.0, to be prepared for the upcoming interoperability solution. The following proof of concept blockchain applications are great examples which were financially supported by the Lisk Foundation to be migrated to the latest version of the Lisk SDK:

• Collabolancer (GitHub)
• Lisk Ticketing  (GitHub)
• Lisk DAO (GitHub)
• LiskCrowd (GitHub)
• Nash Stablecoin (GitHub)

As already explained in the blog post Replacing the Lisk Explorer, the Lisk Explorer will be discontinued after the Mainnet launch. It is replaced by various alternatives, such as the explorer functionalities in Lisk Desktop, the dashboard plugin for the Lisk SDK, and the browser-based Lisk blockchain explorers Lisk Observer and LiskScan.

Tools & Services that run their own Lisk Core Node

Services that require running one or multiple Lisk Core nodes, will need to update their Lisk Core v2.1.6 node(s) to the latest version of Lisk Core v3.0.0. After the announced snapshot height is passed, it is recommended to stop and remove Lisk Core v2.1.6 and to perform a fresh installation of Lisk Core v3.0.0. When Lisk Core v3.0.0 is started for the first time, it will automatically start to sync with the network.

The new Lisk Core comes with a brand new command-line interface (CLI), which greatly simplifies the management of the node. For example, it can be used to start Lisk Core, to enable forging, or to create and send transactions to your Lisk Core node. In addition, a process manager such as PM2 can be deployed to run Lisk Core in the background.

Tools & Services Relying on Data from the Legacy Blockchain

The Lisk Foundation will maintain a certain set of frozen Lisk Core v2.1.6 legacy nodes, which will serve as an archive for all data present on the Lisk Mainnet previous to Lisk Core v3.0.0. A corresponding legacy version of the Lisk Explorer is also accessible for at least one year.

The final links for the Lisk Core v2.1.6 legacy nodes and the legacy version of the Lisk Explorer will be announced some time before the Lisk Mainnet v3 migration.

Tools & Services Relying on the Lisk Core API

Services that rely on the Lisk Core API will need to be updated to be compatible with the new API. As the Lisk Core HTTP API endpoints have been reduced, it is recommended to consider using the Lisk Service HTTP API and the new WebSocket-based APIs which are described in the following paragraphs below.

Lisk Service HTTP API

The Lisk Service HTTP API is intended to provide additional endpoints and enriched data about the Lisk network in addition to the Lisk Core HTTP API. To use the extended HTTP API, install Lisk Service and connect it to a Lisk Core node.

Alternatively, you can also use the Lisk Foundation’s public API.

• Public Mainnet API: http://service.lisk.io/api
• Public Testnet API: http://testnet-service.lisk.io/api/
• Check out the Lisk Service 0.3.0 HTTP API reference for more information.

Lisk Service RPC API

Lisk Service provides an RPC API that allows sending remote procedure calls via WebSockets to Lisk Service. This can be an efficient alternative to the HTTP API, especially if many requests need to be processed.

Check out the Lisk Service 0.3.0 RPC API reference for more information.

Lisk Service Subscribe API

In addition to the RPC API, which allows sending API requests actively to Lisk Service, it is also possible to subscribe to various events of Lisk Service by utilizing the Subscribe API. Once you subscribe to an event such as update.block, Lisk Service will notify you instantly if the event occurred.

Check out the Lisk Service 0.3.0 Subscribe API reference for more information.

Lisk Core HTTP API

The HTTP API received an extensive overhaul and as a result, numerous endpoints have changed or have been removed completely. Additionally, the HTTP API has become an optional plugin of Lisk Core. Set up your own Lisk Core node and enable the HTTP API plugin if you still wish to use the minimized Lisk Core HTTP API.

Check out the new Lisk Core 3.0.0 HTTP API reference for more information.

Lisk Core WebSocket API

In addition to the HTTP API, it is now possible to send API requests via WebSockets, if WebSockets are enabled on the node. Listen to network events by subscribing to events and invoking actions on a Lisk Core node. The Lisk API client can be used to conveniently connect to the Lisk Core WebSocket API.

Summary of the Most Important Protocol Changes

A list of the most important changes in the Lisk protocol that will most likely affect your tools and services is shown below. For a complete overview of the implemented changes, it is recommended to study the Lisk Improvement Proposals 0001 - 0036.

Protocol Changes Related to Accounts

• Lisk32 address: longer account address with checksum included.
• No account initialization is required for new Lisk Accounts anymore.
• Accounts need to have a minimum balance of 0.05 LSK.

Protocol Changes Related to Blocks & Transactions

• Dynamic fees instead of static fees.
• Added network ID to mitigate transaction replay attacks.
• Timestamp in transactions is replaced with the nonce of the sender account.
• Multisignature transactions need to be signed by all required signatories first before sending them to a node.
• New block ID format.New transaction ID format.

Protocol Changes in the Consensus Algorithm (DPoS & BFT)

• Tokens are locked when voting for delegates.
• 1 token can only be used to vote for 1 delegate.
• 2 random standby delegates can forge during each forging round.
• Delegates need to self-vote with at least 10% of their total vote weight, otherwise, the vote weight is capped.
• The delegate vote transaction can include a maximum of 20 votes/unvotes instead of 33.
• Misbehavior of delegates (e.g. double forging) is punished by the network.
• Verify the finality of a block via API (Average time to finality: ~155 blocks / 25min)

How to Migrate as a Delegate

Delegates who are currently in active forging positions, and other node operators who want to migrate their node(s) need to adhere to the following steps:

• Wait until the snapshot height for the network migration is announced on Lisk.com and our social media channels.
• Follow the migration guide to migrate from Lisk Core v2.1.6 to v3.0.0 and enable forging for your delegate in the new network.
• Self-vote your delegate.

All delegates who are not in the 101 active forging positions will now have the opportunity to forge blocks in the new protocol. Two random standby delegates are chosen for each forging round and can also participate in the forging process, making each round 103 blocks long. This also creates an incentive for standby delegates to run a node and enable forging on it for their delegate.

Old address format Lisk Core v2.1.6 and lower:

946075738761018629L

Corresponding public key:

0xe877c250d725ac7ca6c5d9d83b39645de7eebe6c4ae6e076da7163434d297c7d

New address format from Lisk Core v3.0.0 onwards:

lskzkfw7ofgp3uusknbetemrey4aeatgf2ntbhcds

The new address format, which is also called Lisk32 representation, is always 41 characters long, contains decimal digits and lower-case letters from the Latin alphabet, and starts with the prefix ‘lsk’.

The last 30 bits of the address represent a checksum, which allows a user to mistype up to 4 characters in the address and it is guaranteed that the application will detect it.

For more information about the new address system, read our blog post New Lisk ID system.

Accounts with a second passphrase will be converted to multisignature accounts which always require two signatures to validate transactions.

To view your new address after the migration, update Lisk Desktop to version 2.0.0 and log in as usual with your passphrase, then the new address of the account will be displayed.

After the network migration, the new protocol changes for the DPoS system will be implemented in the network. This requires all accounts in the network to reassign their votes. To guarantee a smooth transition of the new DPoS consensus algorithm, there will be a one-week transition period after the network migration, giving accounts in the network enough time to cast their votes in the new DPoS consensus algorithm.

At this point, it’s not certain that hardware wallets will be immediately supported after the migration. If users wish to access their LSK tokens immediately after the migration, they should move them to a regular Lisk account before the migration. We will collaborate with all relevant parties to bring hardware wallet support back as soon as possible. Once we have more information on when hardware wallet support will be available, we will send an update on our social media channels.

Please be also aware that Lisk Mobile will not be supported right after the migration. Support for Lisk Core 3.0.0 will be added as soon as possible afterwards. Alternative wallet implementations from third parties might also not be supported right after the migration. We recommend using the Lisk Desktop wallet until then.

How to Vote for Delegates

The voting of all delegates will be reset after the Mainnet hard fork so everyone who wants to participate in the new DPoS voting system will need to recast their votes.

There is a one week period starting from the network hard fork, whereby votes should be reassigned. After one week has passed, the new DPoS consensus algorithm will become fully active and a new top 101 delegates selection will start forging blocks.

Lisk Desktop v2.0.0 continues to provide a convenient user interface to cast votes for delegates, just as before the hard fork, however, the voting process works in a significantly different manner now. The tokens used to vote for delegates will now be locked and can be unlocked if required, by unvoting the delegate again.

For instance, let's assume you hold an account with a balance of 100 LSK. It is possible to use only a part of your tokens for voting, but let’s assume you want to vote with all 100 LSK. It is possible to split your tokens amongst multiple delegates or to use all of them to vote for only one delegate. For example, it is now possible to vote for 10 delegates with 10 LSK, or alternatively just for one delegate with the full amount of 100 LSK.

The amount of tokens used for voting is locked and cannot be used for any other transactions. This includes but is not limited to further voting, balance transfers, or transaction fees.

To use the locked tokens again, the account has to submit a delegate unvote transaction. This will start the unlocking procedure and the LSK tokens will be ready for unlocking 2,000 blocks later (approximately 5 hours and 30 minutes).

After a 2,000 block period has passed, the tokens can be unlocked. This is done with a new unlock transaction. The token unlock transaction specifies which tokens have to be unlocked and added back to the balance. This mechanism is required to allow blocks to be reverted, however, future improvements of the Lisk blockchain could remove the need for this unlock transaction.

How to Migrate an Uninitialized Account

If you have an uninitialized Lisk account, it is highly recommended to initialize it as soon as possible, by sending one outgoing transaction. If you have already initialized your account before the Mainnet migration, then no other steps are necessary.

In the case whereby an account was not initialized before the migration, the following steps need to be performed to migrate your legacy account to the new network:

• Update Lisk Desktop to the latest version 2.0.0.
• Login with your passphrase and check the new address format for your account.
• Fund your account with some LSK tokens (e.g. 1 LSK), for example by transferring the tokens from an exchange.
• Perform the reclaim transaction from within Lisk Desktop.

Summary

In short, the upcoming launch of the new Lisk Mainnet will be the largest network migration in the Lisk network so far, and if you have a service which is relying on data from the Lisk blockchain, it will be mandatory to make the corresponding updates to stay compatible with the network after the hard fork.

Developers: Ensure your services and applications will be compatible with the new protocol changes by setting up a node with the latest beta version of Lisk Core v3.0.0. The public Lisk Betanet is already running a beta version of Lisk Core v3.0.0 and it can be used for testing purposes before the Testnet and Mainnet launch.

Delegates: Make sure to follow the Lisk Core migration guide in the documentation.

Normal users: Ensure to reassign your votes in Lisk Desktop during the first week after the network migration.

Everyone: Grab some popcorn and enjoy the Lisk network entering a new era! \o/