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 , and other , e.g. payment providers. exchanges, wallets, staking services, blockchain explorers third-party services 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 , 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 and . Replacing the Lisk Explorer Lisk Observer 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 , to , or to to your Lisk Core node. In addition, a process manager such as PM2 can be deployed to . start Lisk Core enable forging create and send transactions 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 for more information. Lisk Service 0.3.0 HTTP API reference 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 for more information. Lisk Service 0.3.0 RPC API reference 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 for more information. Lisk Service 0.3.0 Subscribe API reference 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 for more information. Lisk Core 3.0.0 HTTP API reference 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 can be used to conveniently connect to the Lisk Core WebSocket API. Lisk API client 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 : longer account address with checksum included. Lisk32 address . No account initialization is required for new Lisk Accounts anymore of 0.05 LSK. Accounts need to have a minimum balance Protocol Changes Related to Blocks & Transactions instead of static fees. Dynamic fees to mitigate transaction replay attacks. Added network ID of the sender account. Timestamp in transactions is replaced with the nonce need to be signed by all required signatories first before sending them to a node. Multisignature transactions . . New block ID format New transaction ID format Protocol Changes in the Consensus Algorithm (DPoS & BFT) when voting for delegates. Tokens are locked . 1 token can only be used to vote for 1 delegate can forge during each forging round. 2 random standby delegates with at least 10% of their total vote weight, otherwise, the vote weight is capped. Delegates need to self-vote The instead of 33. delegate vote transaction can include a maximum of 20 votes/unvotes by the network. Misbehavior of delegates (e.g. double forging) is punished ( ) 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 and our social media channels. Lisk.com Follow the to migrate from Lisk Core v2.1.6 to v3.0.0 and enable forging for your delegate in the new network. migration guide your delegate. Self-vote 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 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. initialize it 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 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. Lisk Betanet Delegates: Make sure to follow the in the documentation. Lisk Core migration guide 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/

Alphabet

fees

Initialized

Instantly

Lisk

Blockchain Interoperability: An Introductory Guide

Sparse Merkle Trees: The New State Model for Lisk's Interoperability

Visit us

Too Long; Didn't Read

Everything You Need To Know About Lisk Mainnet Migration

Everything You Need To Know About Lisk Mainnet Migration

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Guide on How to Build a Blockchain with Javascript

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

A Guide on How to Build a Blockchain with Javascript

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps