Home | Blog | ARK Core v2.5 — Deprecation of API v1 & Making a Leaner Codebase
Rok Černec
Blockchain
Reading time: 8 min
Date: 11th Jul 2019

ARK Core v2.5 — Deprecation of API v1 & Making a Leaner Codebase

A little less than a month after our Core v2.4 release we are happy to announce the successful upgrade to Core v2.5 on our ARK Public Network. The new Core is now even leaner with the removal of the legacy API v1 code base. This upgrade paves the way for ARK Core v2.6 which will be the biggest single upgrade of our Core to date.

The new ARK Core is now even cleaner and easier to maintain due to the deprecation of legacy API v1 code. With this release we are beginning a series of improvements to the current codebase in preparation for the major updates with Core v2.6 and Core v3. Numerous performance tweaks have also been made to the newly used Websockets P2P layer using SocketCluster library.

We have also added the following new features and improvements:

  • Easy retrieval of first and last block as often user wants the last forged block or the genesis block to check something. We have added two new endpoints to the block resource that retrieves those from in-memory instead of hitting the database, which also helps with performance.
  • Possibility to retrieve raw blocks and transactions data in the same format as @arkecosystem/crypto uses them via ?transform=false. This is enabled on all endpoints that serve blocks or transactions.
  • New configurable option that lets you choose whether to use estimates for the total number of rows if it is true (fast) or use the precise COUNT(*) if the option is false (slow) for Core API. It is up to the node operator to configure their node for accuracy vs speed.
  • Search of transactions by asset as the /transactions/search endpoint now accepts an asset object.
  • Improved rate limiting by introducing a new RateLimiterclass which also allows for different rate limits per endpoint.
  • Exit on unexpected PostgreSQL error which enables Core to recover from it by exiting the process so pm2 can restart it and not corrupt it.
  • Improved peer block header check by removing the need to perform the expensive signature check if we already have the same block.
  • Download serialized blocks endpoint now returns blocks with serialized transactions. The reason is that it drastically improves the responsiveness since it removes all of the strain from a node that it is downloaded from, performance increase can be up to 10x depending on the size of the block.

If you want to learn more about all of the changes, here is the list of all of them:

Breaking

  • Treat and return BigInt values as strings (affects core-api) (#2739) —

NOTE: If you are running any apps that use numerical values without any bigInt handling you should ensure to always work with bigInts and not numbers/strings.

Added

  • Allow retrieval of raw blocks and transactions via API (#2616)
  • Search transactions by asset via API (#2618)
  • Allow easy retrieval of first and last block (#2641)
  • Make it configurable whether to use estimates for core-api (#2772)
  • Let the user choose if they want to use @next release (#2789)

Fixed

  • Impose the same rate limit as the public API (#2717)
  • Add option to configure request timeouts for webhooks(#2710)
  • Use CORE_API_DISABLED variable in defaults (#2711)
  • Always attempt to download blocks after start (#2746)
  • Possible database corruption when writing and deleting blocks (#2707)
  • Forget peer when socket is disconnected (#2720)
  • Off-by-one error when fetching blocks from peer (#2733)
  • Check for user confirmation in snapshot commands (#2734)
  • Grant access if the whitelist is empty (#2748)
  • Do not purge transactions when a block is not accepted (#2751)
  • Previous round order calculation (#2754)
  • Revert accepted blocks when saveBlocks fails (#2761)
  • Do not restore genesis block with wrong id (#2759)
  • Avoid iterating on non-iterable peerBlocks (#2763)
  • Correct estimate if less than limit rows (#2764)
  • Try harder to return the requested number of transactions (#2765)
  • Reject future and expired transaction timestamps (#2757)
  • Delete last block if deserialization fails (#2770)
  • Raise bignumber maximum (#2777)
  • Allow future timestamps up to 3600 + blocktime seconds (#2787)

Changed

  • Download serialized blocks to improve performance (#2743)
  • Better peer block header check to improve performance (#2719)
  • Exit on unexpected database errors (#2744, [#2755])
  • Block peers when the rate limit is exceeded (#2745)
  • Delay peer discovery until after state initialization is done (#2727)
  • Improved P2P rate limiting (#2729)
  • Only fetch block headers when verifying peers (#2728)
  • Only look for new peers when below minimum peers (#2714)
  • Always keep the Wallet API enabled (#2715)
  • Respect the whitelist of the public API (#2718)
  • Add foreign key on transactions block id (#2671)
  • Remove the id column from rounds (#2723)
  • Discover new peers sooner (#2771)
  • Enforce chained blocks at database level (#2753)
  • Increase timeout, check time left in slot (#2788)
  • Refresh peer ports (#2784)
  • Remove blockSender (#2756)

Removed

  • Removed the ark-node legacy API known as v1 (#2577)

What’s Next for Core?

Next Core release (v2.6) will be the biggest Core release as of yet, not just feature wise, but impact as well. Core v2.6 brings us closer to our goal of interoperabillity, adds customization of transaction types with the integration of AIP-29(making new tx types a breeze), the introduction of nonces and much more.

The main features of Core v2.6 will be:

  • Schnorr’s signature schema — reduces the overall signature size to 65 bytes unlike ECDSA which usually varies between 70–72 bytes. Additionally, it allows us to make use of public key aggregation (multi-signature) and overall better performance.
  • Nonces for transactions — the goal of a nonce is to make each transaction unique by applying a sequential number to the tx so that an attacker can’t replay a transaction (so called “replay attacks”), making the blockchain even more robust and secure.
  • Generic Transaction Interface (GTI) — by decoupling some of the tedious functions from Core we’ll make it a possibility for developers to make their own custom transaction types with their own logic with ease.
  • Multisignature transaction type—based on AIP18 we’ll reintroduce the option of multisignatures, being one of the first DPoS coins to incorporate the much more robust and faster Schnorr algorithm.
  • Hash-Time Lock Contracts — will be a first step into the ability for ARK to support Atomic Swaps. Users will be able to “lock” funds according to a set of predefined rules.
  • Bridgechain registration type— as part of the upcoming Powered by ARK program, Bridgechains will have an option to become registered on our ARK blockchain and become part of the ARK ecosystem family that will give them special perks, features and promotional options.
  • Multipayment transaction type — you will be able to bulk your transactions and send them inside one transaction to save on fees and space.
  • IPFS transaction type — will allow users to save IPFS compliant hash of the files stored on IPFS solutions.
  • Delegate resignation — delegates who wish to forfeit from being a delegate (and being voted for) will be able to send a “kill command”, which will make it impossible to vote for that delegate.

Core v2.6 is in the final phases of development and internal testing is expected to go on-to our Development Network (Devnet) sometime in the month of September, where it will be thoroughly tested by others before going live on the Public Network (Mainnet).

Core v2.6 will also be the last release in the Core v2.x era. The next release after v2.6 will go straight to Core v3 and will feature all of the remaining Core v2.x items (hot reloading, API-JSON, new plugin system) and even more items that will be introduced and explained more in-depth in the revisited Core blog post coming out soon ( you can already see some tasks that will be part of the Core v3 on the new website at ).

Changes From v2.4 to v2.5

For node operators of the current ARK Core, in order to update, please follow these migration instructions (v2.4 to v2.5) before you do the update: *https://docs.ark.io/releases/v2.5/migrating_2.4_2.5.html

Changes In Numbers

  • 6 different developers contributing to the Core.
  • 76 new commits to the Core.
  • 355 files changed in the Core.
  • 7,078 code additions to the Core.
  • 10,293 code deletions in the Core.

ARK.io

Stay up to date
By submitting this form you agree to receive email updates. Find out how we process your data here.
Download
Visit our download page to learn more about our latest releases
2021 © ARK.io | All rights reserved An ARK.io Product