ARK Core v2 - Additional Information Before Code Release

It has been a few weeks since our last technical blog post, and as the release of ARK Core v2 approaches (keep in mind that “ARK gives no dates!”) we would like to review in depth details of the upcoming and freshly baked ARK Core v2.

In this blog post we’d like to cover what ARK Core v2 is and what it is not. The final testing phase of ARK Core v2 is underway on our internal testnet and we are very close to making the code available to the public for testing on Devnet. The amount of time testing on Devnet, and when the push to Mainnet will occur can not be predicted. Multiple factors come into play such as public testing results and bugs that may pop up. Once public, everyone is invited who likes to pentest, hack and/or code to review the core, find and report bugs, suggest improvements or anything that will help improve the code for Mainnet.

The first iteration of v2 is dedicated to be 100% compatible with the v1 protocol. In order to switch gracefully to the new code (with the ability to handle the next upgrade) a hard fork will be necessary to enable the new AIP11 based protocol. Together we will release a completely revamped ‘public’ API that will make the lives of the lite client application developers much easier. The AIP11 hard fork block height will be announced when ARK is ready to announce it. Prior to that, any date on when it will happen is pure speculation.

ARK Core v2 will be released in two stages. Stage one of the v2 release will include the new dynamic fee structure, multisig upgrade and updated transactions per second(TPS). The next stage of v2 will require a hard fork, integrating AIP11 multi payments, timelock and token swaps, and transaction expirations.

We would also like to announce that ARKVM integration will resume with corev2 release on devnet. The majority of the integration was completed for v1, now the port to v2 will begin. Again as we say, “ARK gives no dates”, so watch the roadmap for VM progress.

Now, let’s cover a few of the most talked about topics so there won’t be any misinformation floating around.

Block Times (No Changes)

There are no plans to decrease block creation times as there is no strategic interest to do so. Block times are directly linked to network latencies when establishing consensus. Decreasing block times can be done only at the price of centralization. This can be seen in some cryptocurrencies with smaller block times, achieved by reducing the number of nodes or delegates, and by optimizing (controlling) the location of well connected servers. These actions are not part of our philosophy and undermine decentralization.

Delegate Numbers (No Changes)

The number of delegates will remain at 51. Increasing the number of delegates would require extensive testing and would occur at the price of decreasing latencies (for instance by decreasing TPS and increasing blocktime) or by increasing the centralization of nodes.

Fees (No Fork)

One of the most “anticipated” requests from the community was definitely fee reduction, especially with the price of ARK increasing over the past year. ARK Core v1 already has integrated flexible fees, but this was not enabled at the client and block creation level. ARK Core v2 will activate this without the need for a hard fork (which would have been required if not yet prepared in v1).

What v2 will add over v1 is:

• ARK-JS will enable overriding fees when you create a transaction (custom fees)
• Delegates will be able to set a minimum tx fee threshold to determine the blocks they will accept when forging

It will be the sole responsibility of the active delegates to adjust fees, in a similar way as miners do in bitcoin. The formula for ARK’s new dynamic fee structure will be proportional to the size of the transaction. For instance, the addition of data into the vendorfield will result in a higher transaction fee since the total transaction byte size is increased. Since some transaction types will require more resource consumption, a minimum fee will be proposed on those transactions (ie: voting and delegate registration). Theoretically, this new fee formula could bring transaction fees down to 1 Arktoshi (0.00000001 ARK).

We will work on the clients (ark-desktop, ark-mobile and libraries) ability to estimate the fees for the transaction you will “build” once the market has stabilized. Quite surely the existing default fees in current clients will be superior to the market fees when it will be enabled so we don’t expect frictions on this side, those clients will continue to work as expected.

Here is the breakdown of the new dynamic fee structure for ARK.

The minimum acceptable fee by the network will be 0.00000001 ARK or 1 Arktoshi.

The calculation formula is: TXFee = (T+S) * C

T: minimum offset byte depending on transaction type, defined by the network (byte). Each specific value will be defined prior to devnet release(ie: voteTX=100, multiTX=5, regular TX=0)

S: size of the serialized transaction byte = 80 bytes minimum for normal TX(47 bytes header + 33 bytes normal TX). Header and TX bytes will vary specific to each TX type (ie: regular TX=33bytes + min. 47bytes for header, MultiTX=29bytes x (number of TX) + min. 47bytes for header + 2bytes for defining number of outputs). Vendorfield inputs will add to the header bytes total.

C: constant (ARK/byte) defined by the delegate including the transaction in his forged block.

C can have more than 8 decimal places, the only requirement will be that TXFee at the end needs to be more or equal to 0.00000001 ARK(1 Arktoshi).

Example:

For basic transfer we could have T = 0 byte, C = 0.0001 ARK/byte.

For a basic transfer transaction with empty VendorField S = 80 bytes, hence the TXFee= (0+80) * 0.0001 which is 0.008 ARK.

For a voting TX we could have T = 100 bytes, C=0.0001 ARK/byte, S = 82 bytes, TXFee = (100+82) * 0.0001 which is 0.0182 ARK.

Transactions Per Second (No Fork)

We’ve seen some images and comparisons floating around that ARK’s new core will have 14,000+ TPS. Let’s get this out of the way — ARK core v2 won’t have anywhere near 14,000+ TPS. We do not know where these numbers originated from, but they are false.

To put this into perspective (14,000 TPS), the size of one transaction in the ARK network has a minimum of 80 bytes (47 bytes transaction header + 33 bytes payload of transaction, more if additional data or different transfer type) meaning 1.12 MB of transactions would be processed each second if all blocks filled. The daily blockchain would increase by more than 95 GB and in a year blockchain size would be over 34 TB.

To be clear, any decentralized blockchain claiming such ridiculously high TPS numbers is claiming them falsely. Handling such a high number of transactions is at the price of a complete centralization of the block creators/validators. Each transaction on the network has a byte size. Handling that many MB per second in bandwidth with low latencies to keep consensus is not currently viable in a decentralised environment. Not to mention the needed disk space and RAM to validate and process each and every transaction that hits the node.

ARK Core v2 will of course offer much better handling of transactions (serialization and deserialization of transactions will reduce byte size which will increase speed as well). This can increase TPS and provide better scalability options for the future with leaner transactions. TPS can easily be increased with a soft fork (changing a value in the config file and updating nodes to the newest code).

ARK core v2 will initially be capped at around 150 transactions per block (ARK core v1 is currently set to 50 transactions per block). This brings TPS to around 19. Much higher numbers are possible, but currently a need for maximum TPS does not exist. Along with reduced fees, we need to find a happy medium to prevent transaction spam and blockchain bloat. Of course, testing the upper limits of TPS will be great fun on Devnet, and extensive testing would be required prior to making any drastic changes on Mainnet.

These numbers are just for Devnet release, Final v2 Mainnet TPS numbers will be determined after Devnet testing is complete.

Multi-signatures (Soft Fork)

A multi-signature transaction is a special transaction type that is associated with more than one private key. The simplest scheme is an m-of-n address, where n represents total number of private keys associated with an address, and sending ARK from this address requires signatures from at least m keys. A multi-signature transaction is one that sends funds from a multi-signature address.

The primary use of multi-signatures is to increase the difficulty of getting access to coins associated with a specific private key. With a 2-of-2 address, you can keep the two keys on totally separate machines, and as such theft will require compromising both private keys, which is a much more difficult task than getting your hands on one key — especially if the machines are completely different (e.g., one PC and one dedicated device, or two hosted machines with a different host and OS). ARK’s second signature (2nd passphrase) will be replaced by multisignature support (second signature will still work as it is basically a 2 out of 2 multisignature type).

It can also be used for redundancy to protect against loss — with a 2-of-3 address, not only does theft / moving of coins require obtaining 2 different keys, but you can still use the coins if you forget any single key. This allows for more flexible options than just backups. It can also be used for more advanced scenarios such as an address shared by multiple people, where a majority vote is required to use the funds(ie: escrow wallet).

Multi-payments (Hard Fork — AIP11)

In order to decrease the payload on the blockchain to account for large amounts of tx, you can combine(batch) those payments into multi-payment transactions. This will also help to decrease the fees per payment. (ie: sending 16 tx in a batched payment at once only incurs one single tx fee instead of 16 different fees.)

Multi-payment transactions will offer up to 65546 bytes in size (2 bytes for number of outputs and 29 bytes per multi-payment TX output = 2260 tx per multi-payment maximum) to be included in a multi-payment transaction type. This will definitely come in handy for delegates that are running daily payouts to numerous voting addresses.

At the start we’ll limit this to 16 possible outputs (16 payments per transaction) and increase by need with further testing.

Timelocks and Token Swaps (Hard Fork — AIP11)

Note this feature is still under review and many details will likely change on the AIP11 specifications.

There were talks that bridgechains/ARKchains will be required to run ARK relay nodes in order to achieve swap capabilities within the ARK ecosystem and have a certain amount of ARK coins to be held by those chains. We don’t want any bridgechain to have to rely on ARK mainchain for it to run. Achieving swaps within the ARK ecosystem will be done with timelock combining multisignature tx types. We are going to develop easily understandable and usable swapping capabilities right within our ARK desktop wallet (later on mobile and web as well). Exchanging should be as easy as inputting a few values and waiting on both parties to accept the terms (ie: exchanging 5 ARK for 100 Persona tokens or vice versa in a trustless manner). We’ll focus our development on this after initial v2 release.

Timelocked transactions combined with multi-signature support provide a stable base for the ARKchain swapping capabilities and offchain payment channels. In order to deliver this functionality, a hard fork will be needed. Timelock transactions will introduce two new fields to the transaction structure:

Timelock type defines different types for timelock value field. Current supported types will be:

• 0 — for timestamp type timelock (if timelock type=0, timelock value shall be specified with timestamp).
• 1 — for blockheight type timelock value (if timelock type=1, timelock value shall be specified with blockheight).
• TimeLockType=0, timelock value=timestamp: transaction will be forged when timestamp is passed.
• TimeLockType=1, timelock value=blockHeight: transaction will be forged when blockchain reaches height specified at timelock value for blockHeight.

Expiration (Hard Fork — AIP11)

To mitigate double spending attacks when the transaction signer does not control the communication channel to send/check the transaction on the blockchain, we need to provide a guarantee that the third party cannot hold the transactions because the validity time is currently infinite in v1. That is the point of expiration field.

Expiration will also be a new field in the transaction structure. Expiration is the timestamp after which the transaction cannot be included in a block. In other words, if the block timestamp is strictly superior to the transaction expiration timestamp, the block is invalid. Practically, this means that expired transactions will not be forged and will be removed from the transaction pool when they expire, and the transaction will have to be resent again.

Summary

To sum everything up — ARK Core v2 will bring in a LOT of new features, following the best and proven programming practices. It will also be 100% backwards compatible for easier transition to the new codebase, modularized, faster and easier for programmers to understand and contribute.

ARK Core v2 will be a totally new chapter in ARK’s vision and we are very excited to get this out in the open. With v2 we will completely sever with our legacy Crypti/Lisk code, and at the same time establish ourselves as pioneers, innovators and leaders in the blockchain space.