Development Update — Road to Core 1.0 Mainnet

lisk-official (49)in #blockchain • 6 years ago

Screen Shot 2018-07-13 at 12.21.26 PM.png

Hello Lisk Community!

It’s been over a week since we released Lisk Core 1.0.0 to Testnet! Almost all participating delegates are active and forging without any issues as we move steadily towards the release of Core 1.0.0 to Mainnet. However, there are still a few very important steps we need to take before we get there.

All Lisk products, such as Lisk Hub, Lisk Elements and Lisk Commander, need to be aligned and polished prior to Core’s release to Mainnet. Our community also needs sufficient time to adjust their tools. Exchanges will also need to migrate to our new node software.

Following the start of the Testnet migration process, we decided to add a section to the corresponding documentation regarding troubleshooting and how to respond to the most common errors that may occur upon migration. We are also monitoring occasional consensus drops on Testnet that have been reported by the community.

In the meantime, work is progressing on the next release.

Changes in Core 1.1.0 version include:

Issue #2014: Function generateDelegateList from the delegates module was previously accepting height as a parameter, but this was inconsistent since it should accept round. We have adjusted this implementation.

Issue #1797: For our cryptography, we’re using a third party library called libsodium. It’s the fastest one available and written in C, but in order to communicate with it from JavaScript, our application needs a wrapper, which provides an API we can work with. Previously, we used the node-sodium library, but because it is no longer being actively maintained, we decided to switch to sodium-native. We ran performance tests and it turns out that the new library is twice as fast as the old one. You can find the results here.

Issue #2147: We decided to update the database software used by Lisk Core, PostgreSQL, to version 10. This version is PostgreSQL’s latest release that brings security and performance gains such as declarative table partitioning, improved query parallelism, and more.

Issue #2168: Verification for vote transaction types was pretty slow as data needed to perform the verification was gathered from the database via queries which were executed one after another. We have changed the behavior to initially gather in the node’s memory the addresses of all the affected accounts and then run a single query to fetch them all. Prior to these changes, the time needed to verify a full block of transactions (each containing 33 votes) was more than two seconds. After this change, it only takes about half a second.

Issue #1716: Previously, it was not possible to request data sorted by producedBlocks from the /api/delegates endpoint. However, the support for that feature was already in the code, so we have simply enabled it and added corresponding tests.

Issue #2068: When one peer tried to connect to another peer with invalid headers, the returned error message was not very informative. We have improved the returned error message and its formatting.

Issue #2058: The API endpoint /node/status/forging was returning data in an invalid format when no delegates were enabled (i.e. there was an empty delegate list). We have fixed the response format in order to comply with the specification.

Issue #2154: Turning on SSL broke the P2P layer because peers expected the unencrypted ws:// protocol, not wss://. We fixed this by disabling SSL for the P2P layer entirely; it can only be enabled for the HTTP API now. This change is safe because data exchanged by peers do not contain any sensitive information and tampering is not a threat because everything is signed anyway. Despite this fix, if some users want to use SSL for everything, the recommended approach for that is to setup a proxy (like nginx or HAProxy) in front of the Lisk node, as it offers more flexibility.

Issue #398: This issue was already described briefly in our latest development update blog post. However, we have made many improvements to the initial implementation. The latest ones are the following:

-Ease of starting a node connected to any network while running from source

-Significant refactoring and simplification of constants/exceptions/network parameters

-Change of versioning system — Lisk Core’s version will now be independent of the network on which it is running

We still need to make our lisk-build and lisk-scripts repositories compatible with these changes and for this we’ve already opened corresponding issues.

Screen Shot 2018-07-13 at 12.22.36 PM.png

Next Steps

Core 1.1.0 is feature-frozen, therefore we’ve shifted our focus to Quality Assurance. Our goal is to keep both the development sprint and QA phase to a maximum length of two weeks each. QA will begin next week. We have also scheduled the Core 1.2.0 minor release.

You can now track the progress of every release by browsing the Projects section on the Lisk Core GitHub. We will no longer be holding weekly sprint boards and will replace them with release versions, which will essentially be the equivalent of fortnightly sprints.

As always, please stay up-to-date via the #announcements and #network channels on Lisk.Chat and please contact maciek (Lisk Core Lead), JuanG (DevOps) or Mat (Community Manager) if you have any inquiries.

Thank you again for the continued support!

-The Lisk Team

Posted by us also on