ARK Core v2.6: Testing & Progress Update
Just a little over a month after the release of Core v2.6 on Devnet and we’re now deep into the testing phase. For those of you who have not yet participated in this testing cycle, we’ve prepared a short recap of the progress to date, along with some additional goodies that have been introduced as we move closer to the release of Core v2.6.
Since the release, we’ve been hard at work resolving issues and implementing new features and improvements to the codebase, but we’re not the only ones, the community has been hard at work testing, reporting issues and suggesting improvements too. In fact, the dedication and support shown by the community have been overwhelming. So thank you!
We cannot express how grateful we are for your support and dedication. The amount of community interaction and participation in this beta phase has resulted in one of the most fruitful testing cycles since the inception of ARK.
Here is a quick look at just what we have been able to accomplish with your help.
Crunching Numbers
Since the initial release of Core v2.6 on Devnet (few weeks) we have had:
**15 **contributors to Core.
**96 **issues opened in Core (out of those only 6 are still open, all others resolved!).
**148 **commits to Core.
**258 **pull requests to Core.
**312 **files changed in Core.
**2,189 **code line deletions in Core.
5,382 code line additions in Core.
Help and Earn
We are currently running a** special Core v2.6 bounty** that lets you participate in helping to improve the ARK Core by reporting issues or by simply making suggestions for improvements. Each accepted issue can earn you up to $100. At the moment we have (as seen on our **leaderboard**):
50 valid issues reported (or suggestions) by participants
**$2,000+ **will be paid out in bounties (will increase per each accepted valid issue).
We will be running this bounty until the Release Candidate phase that will begin around mid-December.
Learn more on how to earn up to $100 per reported issue: https://blog.ark.io/76d776fa55f
What should be tested?
If you are interested in helping out but aren’t quite sure where to start, we would like to provide some focus areas that we think deserve your attention.
Some areas where you can help:
Trying to force funds from existing wallets
Overloading or stopping a node with bad transactions or blocks (self-forged or not)
Using HTLC and other new transaction types in unexpected ways to wreak havoc on the network and delay blocks.
We would also love to see plugin and script authors from the community update their tools to 2.6 and share with us their experiences. This will help to let us know if there are any issues in regards to nonces or other new additions that make things more complex than they need to be or outright break any systems. This can also help us to improve our documentation.
Recent Improvements
Your feedback has allowed us to make key improvements to Core v2.6. Here are some examples of the improvements we have been able to make since the launch of our Devnet campaign:
**Add command to clear transaction pool — Adds a CLI command to delete the files belonging to the transaction pool as an easy to remember alternative to manually deleting the files ( usage: ark pool:clear **)
**Add ports to bridgechain registration/update **— adds a ports property to the bridgechain transaction types. This property holds an object with plugin names as keys, and port numbers as values like the port's property on peers. For the time being the only allowed plugin to be included is arkecosystem/core-api.
Find HTLC unlock transactions — adds a new endpoint */locks/unlocked *which returns the corresponding claim/refund transactions for a given set of lock ids.
Allow CLI command configurations — allows changing the default CLI command configuration.
**Adding endpoints for locks/businesses/bridgechains **— add new API endpoints for 3 new transaction types to the schema
Performance increase in HTLC bootstrap — optimizes the HTLC bootstrap by excluding claimed/refunded locks and ensuring that each wallet is only indexed once.
Ditch unnecessary reindex() in multi-payment bootstrap — this change boosts the apply phase of the multi-payment bootstrap from ~9sec to ~6sec.
Make address network byte check part of serde — the ajv address schema calls Base58.decodeCheck to validate the network byte. But during transaction serialization, the address is also decoded, so we end up doing it again. By performing the network byte validation during transaction serialization we can get rid of the decode call during schema validation. This makes multipayment processing approx. 25% faster.
**Replace bignumber.js with native BigInt **— Replaces bignumber.js with our own thin wrapper around the native BigInt type. With native BigInts the memory usage of the node is on average 10% less after bootstrap (depends on a server).
Emit round.missed for each active delegate that didn’t forge — emit round.missed at the end of a round for each active delegate that didn’t forge a block.
Allow passing height to configManager.isNewMilestone — Before one had to call *setHeight *before to check an explicit height, but now the height can be passed directly.
**Add multiSignWif to transaction builder **— complements *signWif *and *secondSignWif *by adding *multiSignWif *to the transaction builder.
Add /transactions/schemas endpoint — add new API endpoint to expose schemas of each transaction type in ARK.
**Uniqueness of bridgechain names for the same business **— ensure unique bridgechain name per business.
**Implement throttling on outgoing p2p communication **— use the rate limiter in reverse to stop ourselves from sending too many requests to a given peer that could possibly trigger their protection and result in banning us.
**Log process errors **— The container can now optionally enable log-process-errors for better diagnostics.
Add index on transactions.type — improves performance (during bootstrap — no index 22 sec, with index 20 sec).
**Filter locks by expiration status **— add API support for filtering locks by their status in the wallets/{id}/locks and various locks endpoints.
**Make roundInfo optional **— *roundInfo *was needed to be supplied to getActiveDelegates(roundInfo). We have changed it so that *roundInfo *can be optional.
**Ensure unique genesisHash per bridgechain **— adds validation that disallows duplicate genesisHash values for bridgechain registrations.
We have also updated the TypeScript dependency in the Core to the latest v3.7 version.
These are just some of the new features and performance improvements we have been able to make during this testing cycle. There were also numerous smaller fixes and alterations that vastly improve Core v2.6 and we couldn’t have found them without your help.
When Will ARK Core v2.6 Move To Mainnet?
We have made significant progress since the initial release of Core v2.6 on Devnet and want to keep this momentum going as we move into December. Our primary goal is to use the Core v2.6 launch to build a solid and stable foundation for our future developments and that means we have to ensure that this release is our best to date.
The current beta testing phase is scheduled to end on the 19th of December 2019 (subject to change based on bug reporting). This will also mark the end of our special bounty period. We will announce winners shortly after the end of the beta period so if you would like to be considered and have a chance at earning a considerable bonus, you still have time.
Once the beta period is concluded, we will enter the “Release Candidate” (RC) phase. This means we believe that the current build of Core v2.6 is a production-ready release. The RC phase will last approximately 2 weeks. Due to the extended beta testing period and the upcoming holidays, our current projection is that Core v2.6 will release at the beginning of January. We do not believe it is in the best interest of the team, the delegates, or the community to make a major release during the holiday season and have adjusted our dates accordingly.
Our current plan is to move Core v2.6 onto Mainnet in the second week of January (6th-10th January 2019, subject to change of course).
Desktop Wallet Core v2.6 Compatibility Progress
The ARK Desktop Wallet has been in a constant state of improvement during the Core v2.6 development cycle, adding new features to be ready for the new transaction types that are coming in v2.6. With the launch of v2.6, the Desktop Wallet will see the following improvements:
Nonce support
Signing transactions with Schnorr schema (version 2 of transactions) by default
Multisignatures (creating multisignature address, collecting signatures from other co-signers via Multisignature Server and using actual multisignature address)
Multi-payments (sending to multiple addresses inside one transaction for smoother “bulk” payments)
IPFS (storing of IPFS compliant hash-data on the blockchain)
Delegate resignation (delegates will be able to resign their delegacy by signing a special transaction)
Business & bridgechain registrations (bridgechains will be able to register their business and bridgechain inside the Desktop Wallet)
**Mobile Wallet Core v2.6 Compatibility **Progress
The current Mobile Wallet has also been receiving an upgrade and we have recently completed the development of ‘nonce’ support, which is a requirement for signing transactions once the AIP 11 milestone goes active on Mainnet. In the next few days, we will be releasing a new version of the mobile wallet that will be fully compatible with the v2.6 release.
At this stage, the Mobile Wallet will not support all of the new transaction types as we feel the mobile version of our wallet should be clean, simple and easy to use for everyday users. This means new transaction types such as business and bridgechain registration will stay exclusive to the desktop wallet to avoid over-complicating the mobile user experience.
SDK’s Core v2.6 Compatibility Progress
ARK takes great pride in providing a plethora of options for developers interested in building on top of ARK Core. Updating our SDK’s is a top priority in our development cycle and the majority of our most used SDK’s will be ready and updated for the launch of ARK Core v2.6.
The following SDK’s will be fully compatible at launch:
TypeScript (JS)
Java
Python
PHP
Go
Rust
C++
Our .NET SDK will also be updated for full compatibility with Core v2.6 but will not be available immediately at launch.
Following the release of ARK Core 2.6, we are temporarily pausing the development of the following SDK’s due to low demand:
Swift
Ruby
Elixir
The ARK development team will commence updating the aforementioned SDK’s after the release of ARK Core 3.1. In the interim, if the above SDK’s are required then community support is encouraged. For further information, contact [email protected].
Get Ready!
We hope this blog post has provided greater insight into the ARK Core v2.6 Devnet testing process, what progress we have made, and what you can expect for the official release of v2.6. Again, a huge thank you to our community, our developers and our partners in the ecosystem who have helped to make this our most successful testing cycle to date. We truly are blessed to have such great supporters and we hope that Core v2.6 can make you all proud to be a part of the ARK Community.
If you aren’t sure what new features are included in Core v2.6 or what this update is all about, we welcome you to read all of our Core v2.6 blog posts that cover a variety of new transaction types and features:
Read our new whitepaper! Follow us on social media ( Twitter|Facebook|Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.