Migration to the new ARK Core v2 has been successfully completed on Mainnet. With this milestone, we begin a new era of ARK development and have a foundation for a more stable & efficient network. ARK Core v2 will empower developers to build new modular features and customizations. Allowing the ARK Ecosystem team to work on a more iterative release cycle moving forward. ARK Core v1 is now deprecated.

Today is the day that our new ship takes sail and we could not be any more excited.

At block 6,600,000, the network will officially raise the transaction cap from 50 to 150 transactions per block. After the first block is forged with over 50 transactions, all v1 nodes still running on the network will fork and get banned by v2.0.0 Core nodes.

Ark Core is a totally rewritten back-end that runs our blockchain. If you’d like to learn more about the all encompassing changes and extent of the re-write, make sure to read the previously released blog post HERE.

If you are an ARK user, just download the new Wallet v2 (will be available in few hours, also completely re-written). This wallet will work with the new Core v2 mainnet and allow you to utilize the new dynamic fees system along with several other quality of life enhancements. The new wallet will be available later today after we have had time to monitor performance. We will post a link when the new wallet is available.

A reminder, we are not in control of exchanges and they will re-open deposits and withdraws on their own schedule. If you have any questions about their time frames please contact the exchange as we cannot answer these questions.

What is next for Core?

We have already started to code some of the features we are aiming to incorporate in the next major release — v2.1. Due to v2 being much more modular, some of the features and improvements will be released prior to the final v2.1 (which should have all tasks described below implemented). So let’s go over the features you can anticipate in the future:

Upgrade of transaction protocol ( AIP 11 ) —much anticipated AIP 11 will bring in new transaction types (multipayments, IPFS, timelock)and much more.

—much anticipated AIP 11 will bring in new transaction types (multipayments, IPFS, timelock)and much more. Upgrade the multisignature protocol ( AIP 18 ) — The proposed improvement tries to solve some of the limitations of the current multisignature implementation and make multisig transactions much more than the current legacy system. There is also a discussion to integrate “Simple Schnorr Multi-Signatures”.

— The proposed improvement tries to solve some of the limitations of the current multisignature implementation and make multisig transactions much more than the current legacy system. There is also a discussion to integrate “Simple Schnorr Multi-Signatures”. TypeScript migration — there has been talk to either stick with JS and use flow definitions to check for types or we’ll go straight for TypeScript and get all the benefits of a language that has built-in static type checks and allows us to use the latest features of ECMAScript since TS files get transpiled.

— there has been talk to either stick with JS and use flow definitions to check for types or we’ll go straight for TypeScript and get all the benefits of a language that has built-in static type checks and allows us to use the latest features of ECMAScript since TS files get transpiled. P2P API improvements — there are a few options available here to make P2P even more resilient to attacks and speed. Currently we are leaning either to go for web-sockets or for something like a torrent based protocol, which will in both cases drastically improve the performance of communication and downloading data.

— there are a few options available here to make P2P even more resilient to attacks and speed. Currently we are leaning either to go for web-sockets or for something like a torrent based protocol, which will in both cases drastically improve the performance of communication and downloading data. Parallel block downloading — goes in hand with P2P API improvements described in previous point as those changes will already provide performance improvements. Implementing threaded/parallel downloads will provide another boost in performance and most likely cut down the time of sync by several hours.

— goes in hand with P2P API improvements described in previous point as those changes will already provide performance improvements. Implementing threaded/parallel downloads will provide another boost in performance and most likely cut down the time of sync by several hours. Implement API v2.1 with full JSON-API compliance — we will implement the 2.1 API which will be based on the 2.0 API, but will be fully compliant with the specifications according to JSON-API specifications.

— we will implement the 2.1 API which will be based on the 2.0 API, but will be fully compliant with the specifications according to JSON-API specifications. Add configuration presets — this will include presets for the plugins.js file. Those presets should cover things like exchange relays, minimal relays, full nodes with forger, etc.

— this will include presets for the plugins.js file. Those presets should cover things like exchange relays, minimal relays, full nodes with forger, etc. Implement a system to sign and verify plugins — system will be responsible for verification of 3rd party plugins to bring additional security to people that want to run custom plugins on top of Core.

— system will be responsible for verification of 3rd party plugins to bring additional security to people that want to run custom plugins on top of Core. Implement plugin and config hot-reloading — will make it possible to reload configuration and plugin files without restarting the node process (updating configuration on the-go without node interruptions).

— will make it possible to reload configuration and plugin files without restarting the node process (updating configuration on the-go without node interruptions). Integrate profiling with New Relic — currently there was no profiling in core as it didn’t make sense while code changed a lot every single day. Now that things are settled we’ll integrate New Relic to get a better understanding about which parts of core need to be further improved for speed and performance.

— currently there was no profiling in core as it didn’t make sense while code changed a lot every single day. Now that things are settled we’ll integrate New Relic to get a better understanding about which parts of core need to be further improved for speed and performance. Revisit Core database structure and expandability — right now the core-database and core-database-postgresql packages have a lot of shared logic that should only be in core-database and never be overwritten or touched unless someone really knows what they are doing. We’ll revisit these pieces of code and refactor where needed to reduce complexity.

— right now the core-database and core-database-postgresql packages have a lot of shared logic that should only be in core-database and never be overwritten or touched unless someone really knows what they are doing. We’ll revisit these pieces of code and refactor where needed to reduce complexity. Revisit core API structure and expandability — we will revisit some core API structure that will allow better expandability. Things like delegate specific or webhook APIs could be add-ons that add new endpoints on top of the existing ones instead of their own packages.

— we will revisit some core API structure that will allow better expandability. Things like delegate specific or webhook APIs could be add-ons that add new endpoints on top of the existing ones instead of their own packages. Expand available CLI flags for core to handle certain options —

some things are in the .env file right now which would be better suited as CLI arguments.

All of this will keep us busy for the upcoming months and we are excited to start working on it and you can be sure we’ll keep you updated with our progress.

What is next for ARK?

Apart from on-going work on Core we’ll be releasing ARK Pay in the next few weeks, which will be a simple open-source library that will provide an easy to use merchant plugin to easily start accepting ARK as means of payment, with QR and ARK’s URI scheme support (meaning you can scan QR via mobile and it pre-populates fields so you just sign the transaction) and URI scheme for ARK Desktop wallet where you’ll be able to click on Pay with ARK and it will open send model in ARK Desktop Wallet so you’ll have to sign the TX — you will get confirmation on when the payment completes. Vendor will receive information of the payment and will do action according to what they are selling or offering. Repository and documentation will become available soon after v2 is on MainNet as it will take advantage of v2 API capabilities.

Whitepaper v2 and website v2 are being worked on in parallel and are expected to be available in the Q1 of 2019. The whitepaper was initially scheduled for the end of this year, but we have expanded our technical roadmap and with that, the topics that need to be covered in the whitepaper. We are using this time to refine the specifications so that when the whitepaper is released, it will properly present the way we intend to build the systems.

Ark Desktop wallet v2 has been released, but will get more features and upgrades in the upcoming months as well. One of the first major upgrades to the wallet with be custom plugin support that will make the desktop wallet extensible and easily customizable. There will be many upgrades and addons coming soon, along with changelly integration for v2.

Since v2 has now been deployed on Mainnet, we will shift our focus to migrating our ARK Deployer to be v2 compatible as well. This migration will also be the foundation for our GUI based Push Button Blockchain system (which will feature more of Olegs amazing designs). You can expect to hear a lot more about PBB as we move into next year.

Also, we didn’t forget ARKVM. We know many are patiently awaiting this module. ARKVM will be getting a lot of love in early 2019 as we finalize the specification and begin dedicated development. You will hear a lot more about ARKVM in early 2019.

There are several other ideas floating around that we will discuss more as we solidify the details.

How long will the old v1 API and old RPC still be available?

EOL or End of Life for API v1 will be done with the hardfork to v2.1 with AIP11 next year. This means that after that update, API v1 calls will no longer be working. If your applications still use API v1 we urge you to migrate to API v2 as soon as possible.

API v2 docs : https://docs.ark.io/api/public/v2/

EOL for old ARK RPC will also be available till v2.1 of ARK . We urge you to migrate to new JSON-RPC as soon as possible. JSON-RPC is now part of our Core.

I have found an issue what should I do?

As with all new software there is bound to be a bit of starting hiccups (we of course hope there won’t be any or at most minimal).

If you notice any please report them via GitHub issues :

https://github.com/ArkEcosystem/core/issues

If you find any security vulnerability that can pose a problem to the network that is code related (double spending, vector attacks, anything to do with funds at risk, …) please follow instructions here : https://bounty.ark.io (Security Bounty section).

I want to help with development of the Core what should I do?

If you’d like to get involved with development you can tackle issues already reported here https://github.com/ArkEcosystem/core/issues or provide your own pull-requests and as part of our Github development program be rewarded for your efforts. You can learn more here: https://bounty.ark.io

A big thank you

We’d like to thank our awesome community who helped improve our codebase, reported bugs, helped with testing, was there to motivate and helped other members in times of need — THANK YOU ALL. We can’t wait to continue this adventure with you as we set sail towards new unexplored territory in 2019 and beyond!