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 https://ark.io/roadmap
).

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.

---

Follow us on social media ( Twitter | Facebook | Reddit | YouTube), join our community ( Slack | Discord ) and stay tuned to our blog on Medium. | Read the ARK Whitepaper Here