After months of hard work from the ARK Development team, ARK Core v2.6 is now live on Devnet. Packed with a ton of new features, 2.6 is the biggest core update since the complete rework of 2.0. With v2.6, developers can build more, do more, and even earn more with ARK.

Core v2.6 is here, and with it are a number of new features to help developers, wallet users, and bridgechains get more out of ARK. Currently, v2.6 is in the public testing phase and you can now familiarize yourself with the new transaction types, improvements, and new features; and have the opportunity to test them out before the update goes live on Mainnet. Here’s everything you need to know about the Core v2.6 network upgrade, including how it works and an overview of all the new features and their meanings.

Why the update?

Core v2.6 is an important network update that paves the way to v3.0. By implementing new transaction types and features, we’re laying the groundwork for Core v3. We’ll be able to build upon these new features, providing more modularity and enabling a cleaner, smoother and more effective development experience for all.

What’s included in Core v2.6?

So what’s in the new release? Over the next few weeks, we’ll be breaking down each new feature in detail. We’ll go over why we implemented each feature, why it’s important, how it works and what it means for you. We’ll guide you through each new component with helpful diagrams, screenshots, and explanations to ensure you get up to speed with everything you need to know. Make sure you stay tuned to the blog or follow us on Slack, for more information. But for now, here are the basics…

New Transaction Types

We’ve implemented a number of new transaction types such as Multipayments, IPFS, Multisignatures, Delegate Resignation, Business and Bridgechain Registration, and Hash Time-Locked Contracts (HTLCs).

With Multipayments you’ll be able to send ARK tokens to multiple addresses in one transaction. For users, this means a quicker and easier way to send ARK to multiple people at once, not to mention lower fees for doing so.

Core v2.6 brings the reintroduction of Multisignatures. By utilizing Schnorr Signatures (more info below) multiple signatures and their corresponding keys can be aggregated into one. This enables the creation of transactions that must be authorized by a minimum number of participants (signatures).

With 2.6, delegates will now be able to sign a Delegate Resignation. This new transaction acts as a “kill command” for delegates who wish to resign or retire their delegate. Activating a delegate resignation will mean delegates will no longer be able to receive any new votes. Plus, for actively forging delegates, enabling delegate resignation will mean they permanently drop out of the top 51. This provides a clean and simple way to retire a delegate.

Bridgechain Registrations will also be available with the Core v2.6 update. This new transaction type gives bridgechains the ability to officially register on-chain. Not only does this open up new possibilities for collaboration (for inclusion in upcoming projects, products and more) but it allows the bridgechain to become an official member of the ARK ecosystem. For a bridgechain, being registered means closer ties with the ecosystem and more opportunities for exposure. New business and bridgechain registration transaction types set the identity of a bridgechain provider by registering the project/business onchain.

By building in a new IPFS Transaction Type into Core v2.6 we’re enabling users to store a hash relating to their stored files (via IPFS solutions). Hashes of documents (that are stored on IPFS) can be saved or verified by a user.

We’ll also be including an experimental version of HTLC. Hash Time-Lock Contracts is a feature that will enable a sender to lock funds and a receiver to unlock funds before the pre-set time limit is reached. Funds not claimed prior to this time limit will be refunded to the sender by initiating a refund function. This is the first step towards supporting cross-chain atomic swaps. We’re still evaluating whether or not to release HTLC on Mainnet (as part of the Core v2.6 update) at this time. For now, you can help by testing the HTLC function on Devnet. We’ll go into more detail about HTLC in an upcoming blog.

Additional Features and Improvements

Generic Transaction Interface (GTI) : A streamlined process for developers to make their own custom transaction types with custom logic tailored to their exact needs and requirements. By decoupling complex functions from Core, but enabling them to be “plugged” in, we protect the Core functionality. For developers, this means an alternative to smart contracts, and an incredibly simple approach to building their own use-case (applications, etc.) using ARK’s blockchain technology.

: A streamlined process for developers to make their own custom transaction types with custom logic tailored to their exact needs and requirements. By decoupling complex functions from Core, but enabling them to be “plugged” in, we protect the Core functionality. For developers, this means an alternative to smart contracts, and an incredibly simple approach to building their own use-case (applications, etc.) using ARK’s blockchain technology. Schnorr’s Signature Scheme: Moving away from our current ECDSA algorithm, v2.6 implements and uses Schnorr’s Signature Scheme by default; solving the problems related to security proof, non-malleability, linearity, and size.

Moving away from our current ECDSA algorithm, v2.6 implements and uses Schnorr’s Signature Scheme by default; solving the problems related to security proof, non-malleability, linearity, and size. Nonces: Core v2.6 introduces nonces for transactions, mitigating the risk of replay attacks. By adding a sequential number to make the transaction unique the blockchain is now even more secure.

Migration Process

The migration of ARK Core v2.6 on Devnet has been successfully completed. All seed nodes are already running Core v2.6, along with most current Devnet delegates. Since this isn’t an initial hard-fork (there will be two milestones, one for increasing the minimum version to 2.6 and one for the new tx types) node runners have some time to update before the first milestone hits.

The first milestone will occur at block 3,963,000 on Thursday, 17th of October 2019 at around 15:30 UTC (3:30 pm UTC) when all peers running below version 2.6 will start to get banned.

on when all peers running below version 2.6 will start to get banned. The second milestone will occur at block 4,006,000 which translates to Monday, 21st of October 2019 at around 16:30 UTC (4:30 pm UTC). After that time you will be able to start using and testing the new transaction types introduced in v2.6. For that, we have prepared a Core TX Tester script, which enables you to work with the new transaction types.

All who are already running Devnet node will need to do these two things:

Open plugins.js with the editor:

nano ~/.config/ark-core/devnet/plugins.js

Add "@arkecosystem/core-magistrate-transactions": {},

after "@arkecosystem/core-state": {},

So that this:

module.exports = {

"@arkecosystem/core-event-emitter": {},

"@arkecosystem/core-logger-pino": {},

"@arkecosystem/core-state": {},

"@arkecosystem/core-database-postgres": {

connection: {

host: process.env.CORE_DB_HOST || "localhost",

port: process.env.CORE_DB_PORT || 5432,

database: process.env.CORE_DB_DATABASE || `${process.env.CORE_TOKEN}_${process.env.CORE_NETWORK_NAME}`,

user: process.env.CORE_DB_USERNAME || process.env.CORE_TOKEN,

password: process.env.CORE_DB_PASSWORD || "password",

},

},

...

becomes this:

module.exports = {

"@arkecosystem/core-event-emitter": {},

"@arkecosystem/core-logger-pino": {},

"@arkecosystem/core-state": {},

"@arkecosystem/core-magistrate-transactions": {},

"@arkecosystem/core-database-postgres": {

connection: {

host: process.env.CORE_DB_HOST || "localhost",

port: process.env.CORE_DB_PORT || 5432,

database: process.env.CORE_DB_DATABASE || `${process.env.CORE_TOKEN}_${process.env.CORE_NETWORK_NAME}`,

user: process.env.CORE_DB_USERNAME || process.env.CORE_TOKEN,

password: process.env.CORE_DB_PASSWORD || "password",

},

},

...

After you are done with the change press ctrl+x to save changes and press y and enter to close the file.

2. Run ark update the command to start the update process and after its done restart process(es) when asked at the end and you are all set!

Note: Core v2.6 performs a database migration which can take between 10–20 minutes depending on the hardware.

If you want to get involved with testing and don’t yet have your own Devnet node, please follow this guide to set it up: https://blog.ark.io/ark-core-how-to-setup-a-new-server-running-ark-core-e27a64230802.

Known Issues

2.6 installation may fail if Python 2 is not used by default due to one of our dependencies.

Core TX Tester Script

We have prepared a simple script that is able to generate, sign and broadcast all of the newest transaction types. The aim of the script is to make it as easy as possible to create and send transactions to our Devnet. It provides 100 test wallets with 450 DARK each (you can find them at the bottom of the script). By default, it will use these wallets to create and sign transactions. However, you can change the config which is part of the script to customize the payloads and make transactions more deterministic by using a passphrase of your choice for example.

While all of the new transaction types aren’t available until block 4,006,000 it makes sense to familiarize yourself with the script and start using it by modifying parameters and finding flaws/bugs that shouldn’t happen before that milestone kicks in (eg. accepting new tx types in a block, turning on Schnorr’s default schema, nonces, …). Reporting issues here will qualify you for our special v2.6 bounty rewards. So let’s go over the script, how to run it and how to use it ….

The script and more in-depth details can be found here: https://github.com/ArkEcosystem/core-tx-tester

To get started:

git clone https://github.com/ArkEcosystem/core-tx-tester.git cd core-tx-tester npm install

Afterward, you can simply start it by running (a prompt will appear after you run it):

node index.js

To create and broadcast a transfer transaction you just have to type 0 for Transfer and hit enter . It will use the aforementioned wallets to sign and send a small amount to a random recipient. All types have defaults so that you can simply send them by the press of a button!

However, to make the most out of the script you have to get familiar with the provided configuration options. Open the index.js in your editor of choice eg. by running nano index.js .

For example, here is an excerpt of the configuration found at the top of the script:

If you are only interested in the payload and don’t want to broadcast, you can simply set coldrun to true. Or if you want to “steal” funds from the Devnet test wallets, you may find it useful to change the recipientId to your own. This is just a fraction of the available options, even more, fine-grained control is possible.

After saving your changes, just run node index.js again and it will pick up your configuration.

Here are current options in the script after you start it for different tx types (of course new tx types should fail before block 4,006,000):