We are approaching a time where two of our largest and most significant upgrades to the ARK Core will come to life. In this blog post, we’ll go over the current plan, path, and vision on what we want to achieve in our next two major releases and give some insights on what this means for the entire ecosystem.
As some of you may have already noticed, the development life-cycle of ARK Core v2 is coming to an end with v2.6. After this major release, we will be jumping directly into Core v3. So what will happen with all of the plans to release v2.7, v2.8, and v2.9 before v3? The simple answer is… nothing changes. All of the remaining items that were scheduled to be released in the v2.x process will instead be bundled within the ARK Core v3 release, along with much more.
The reasoning behind this is pretty simple. We want to reduce the number of “hard-forks”, as each one requires special coordination, and multiple parties are affected by the upgrades — delegates, seed nodes, exchanges, peers, services, and developers of bridgechains and applications. By limiting the number of hard-forks required, we can lower the friction for our ecosystem partners while still maintaining our current goals.
ARK Core v2.6
The next Core release is v2.6 and will be the largest update by far in the Core V2 life-cycle. This update brings in numerous improvements and new transaction types that will help us complete the foundation for Core v3.
Generic Transaction Interface (GTI)
Decoupling some of the more complex functions within Core itself will make it possible for developers to make their own custom transaction types with custom logic, and plug them into the Core without touching the Core functionality. This opens up a whole new level of usability within the ecosystem and helps developers quickly adapt and build their custom solutions. All of our transaction types, old and new, have been re-implemented to be in line with the GTI specifications.
GTI will help startups and developers create custom transactions for any use-case they may be working on, including the ability to set custom fees and actions for each new transaction type.
GTI is the engine that powers the overall ARK Logic approach and can be seen as a better alternative to smart-contracts (giving you more freedom and a typescript codebase to develop your custom blockchain applications/contracts).
GTI is part of AIP-29 specifications, where you can learn more about it.
Hash-Time Lock Contracts (HTLC)
The addition of HTLC opens up a whole new world of usage within the ecosystem. A Hashed Time-Lock Contract (HTLC) is a set of transaction types that permits a designated party (sender) to LOCK funds by disclosing the pre-image (secret) of a hash. It also permits a second party (recipient) to CLAIM the funds, or after a timeout is reached to enter a REFUND situation, where a sender can claim their funds back.
HTLC transactions use hashlocks and timelocks to require that the receiver of a transaction either acknowledges receiving the transaction prior to a deadline by generating cryptographic proof of a transaction or forfeit the ability to claim the transaction, returning it to the sender.
This is going to be a first step into the ability for ARK to support cross-chain atomic swaps within the ecosystem and between all bridgechains.
HTLC is part of AIP-102 specifications, where you can learn more about it.
Schnorr’s Signature Schema
At the moment our Core is using the Elliptic Curve Digital Signature Algorithm (ECDSA) for the cryptographic part of our blockchain. While ECSDA is well known and used, there are more performant based algorithms than ECSDA, one of which is Schnorr (the patent for the Schnorr algorithm expired in 2008, after that year it can be used in public domain). With v2 of the transaction types, we will support and enable this as a default method of signing the transactions, while still retaining legacy support for ECSDA. Schnorr solves a lot of problems:
- Security proof: The security of Schnorr signatures is easily provable when an adequately random hash function is used and the elliptic curve discrete logarithm problem (ECDLP) used in the signature is hard enough. Such a proof doesn’t exist for ECDSA.
- Non-malleability: ECDSA signatures are by design malleable, which may enable an attacker to spoof an existing valid signature. Schnorr signatures are provably non-malleable.
- Linearity: Schnorr signatures have the exceptional property that multiple parties can cooperate to assemble a signature that is valid for the sum of their public keys. This is the architectural piece for a variety of constructions that improve efficiency and privacy, such as multi-signatures and other smart contracts.
- Size: Schnorr reduces the overall signature size to 65 bytes, unlike ECDSA which usually varies between 70–72 bytes.
With the implementation of the Schnorr’s signature schema, we will reintroduce the option of multi-signatures support, with Ark being one of the first DPoS coins to incorporate it using Schnorr. Schnorr signatures solve a lot of the problems exposed in ECSDA as they allow aggregation of multiple signatures and their corresponding keys into a single one. As a result, it is possible to leverage the MuSig algorithm for creating transactions that are identified as regular transactions, and therefore do not impact privacy, transaction size, and fees (as of now, this is limited to
n:n multi-sig wallets).
Multi-signature is part of AIP-18 specifications, where you can learn more about it.
As part of the upgrades related to AIP-29 and the implementation of GTI, bridgechains will now have an option to become registered on the ARK public blockchain. Bridgechains that utilize this process will greatly benefit from numerous additional integrations that are now possible due to the information provided during registration. This also opens up new collaborative possibilities and signifies the bridgechain becoming an officially registered member of the ARK ecosystem.
This will bring value to the network, the ecosystem, and the registered bridgechain in an assortment of new ways that were not previously possible. Some options are automatic inclusion of bridgechains within the upcoming marketplace, automated discovery within the desktop and mobile wallets, and the ability to build a universal explorer with information regarding all registered Bridgechains within the Ecosystem. This will give added opportunities for exposure, and a quick and easy onboarding process to the entire suite of tools and services ARK offers. More details on additional integrations will be released as we continue to build and grow our suite of ecosystem tools.
Bridgechain registration is part of AIP-103 specifications, where you can learn more about it.
Multi-payment is a special transaction type, which will allow a single transaction to send up to 400-500* different addresses within one transaction, saving in space (transaction size), and fees, as they are related to the size of the transaction. This will be extremely useful for users that want to batch send coins to multiple addresses.
*This number is not final and subject to change with testing on Devnet before releasing to Mainnet. The theoretical limit is 2259.
The IPFS transaction type will allow users to save an IPFS compliant hash of files stored using IPFS solutions. All of this will be made available with the use of GTI and by putting some logic behind the assets field of the transaction. IPFS hash has varying length but we decided to limit it to a maximum of 90 base58 characters, which should be more than enough as it is twice the size of the common IPFS SHA256 hash. Users will, for instance, be able to save hashes of documents or verify hashes of documents that are stored on IPFS within the Desktop Wallet and make sure that they weren’t tampered with.
IPFS is part of AIP-11 specifications, where you can learn more about it.
Delegates who wish to resign from being a delegate and receiving votes will be able to send a “kill command” by signing a delegate resignation transaction from the address that is associated with a registered delegate. Resignation prevents any new votes and makes the delegate permanently drop out of the 51, ending its forging. The delegate order calculation will skip any resigned delegate in the calculations.
Delegate resignation is a part of AIP-11 specifications, where you can learn more about it.
Nonces For Transactions
The goal of a nonce is to make each transaction unique by applying a sequential number to the transaction so that an attacker can’t replay it (so-called “replay attacks”). This makes the blockchain even more robust and secure as holding the transaction “hostage” will prove to be ineffective. As soon as the sender pushes another transaction from the same address, it will invalidate any prior unconfirmed transaction that has a lower nonce value than the one that was confirmed.
Rewrite Transaction Pool Processing Queue
Optimization of transaction processing by offloading it into a worker. This will make Core a lot more robust under heavy load and potentially allows for higher throughput along with better performance.
By now you are probably asking yourself, that all sounds fine, but when can we expect Core v2.6 to be available for testing and deployment? The final phases of development and internal testing are expected to hit 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).
ARK Core v3.0
Wait a second, are you are telling me you will be able to finish another major release on your roadmap by the end of this year? How will you do it if the development of v2.6 hasn’t even finished yet? The answer is pretty simple, we are doing parallel development of both major releases by having two Core teams, so our plan is to have Core v3 development completed in December so we can start to test all of the changes and features on Devnet by that time.
Core v3 will be specifically focused on following the latest development guidelines and implementing features that will make developers and all bridgechains deployment and development as simple as possible.
So let's go over the major parts of what Core v3 will bring (we won’t reveal everything in full detail yet for competitive advantages).
Core Dashboard GUI
The Dashboard GUI will be a companion application that moves the management of a node from server-side only capabilities that require knowledge of CLI to a UI based platform that is protected by authentication so that only the node maintainer and his partners can perform maintenance with it.
The Dashboard will be the main entry-point after logging into the Manager UI. It will contain all important information about the current state of the server and Core process like CPU/RAM usage, current height, number of transactions in the pool and some general metrics like blocks received in the x hour or average fees of the last x minutes.
The Dashboard will provide the node maintainer all of the tools they need to alter the Core and its surroundings without ever having to manually touch their server or any files again. You will be able to do all of the operations in a user-friendly way — updating, starting, stopping, restarting node processes, and mounting plugins will become as simple as a click of a button.
Plugin System v2
One of the biggest changes and refactors will be in the plugin system of the Core.
Currently, plugins contain an index.js file that simply exports an object with information about the plugin and how to register it.
The refactored plugin system will provide support for plugin verification and more streamlined development through provided interfaces that need to be satisfied by plugins to guarantee the same implementations throughout the Core.
core-kernel will be the central entry point for every plugin and the main application. It will be a combination of
All of those packages at the moment are split up, even though they are required to always be available and used by pretty much every plugin. Combining all of these will remove the need to maintain different packages, reducing complexity and architectural issues that currently exist during the application startup.
This also means that interfaces are always available to every package without having to require an additional package which is currently pretty much always required together with
core-container, and thus reduces the setup process for new plugins to be started.
Modular Consensus and Voting
With the focus on our modular structure of the Core, we want to apply the same logic to its two essential parts — consensus and voting. With the current implementation, it is hard to change voting or consensus mechanics without touching the heart of it. With the new plugin system, we want to move the majority of the Core to modules. That way, bridgechains will be able to easily mount and swap different voting and consensus mechanics. This gives bridgechains the option to change to different consensus mechanisms such as PoW or PoS, or instead of the ARK voting system, you could completely swap it with a module that allows more votes per address or different logic.
Fully JSON Compliant API
The JSON-API will be based on our already improved API v2 but will be extended to be 100% compatible with JSON API specifications.
By following JSON API shared conventions, we will be able to increase productivity, take advantage of generalized tooling and focus on providing a standardized format that can be easily followed by anyone who wants to implement or interact with the ARK blockchain.
The JSON API specification describes how clients should request or edit data from a server, and how the server should respond to specific requests. A main goal of the JSON API is to optimize HTTP requests; both in terms of the number of requests and the size of data packages exchanged between clients and servers; sometimes eliminating network requests entirely.
Configuration Presets And Hot Reloading
We are going to provide more preset options when starting up a Core node for things like exchange, forger, API relay, minimal relay (purely a relay, no public API or any other public surfacing endpoints) to provide faster zero-configuration setups that will exponentially help you get up and running depending on your use-case and specifications of your needs.
We’ll also be implementing “hot reloading”. When the configuration is modified, plugins that are affected by the changes will be reloaded at runtime and do not need the Core process to restart. Hot reloading will watch all relevant configuration files for changes, and if any occur, it will trigger either a full reboot or fire an event so plugins can reload.
This will be a flag that is enabled by default just in case someone doesn’t want to use hot reloading.
Better Error Handling
In Core v3, error handling will be more strict, as officially recommended by node.js. Whenever there is an unhandled error or promise rejection, the process will be terminated (on Devnet). This does two things for developers:
- If there is an unhandled error, the node will terminate and force developers to fix the issue instead of ignoring it.
- Being forced to handle all unhandled errors or promise rejections means we can be more confident in random errors being handled.
There will also be further improvements for more gracefully handling plugin crashes and general error logging to make it more clear what caused an error and why.
These are just some of the major changes coming with Core v3. We haven’t listed them all or their specifications, as we want to retain some of the technological advancement competitive advantage. Once we move closer to the deployment of each release on Development Network, we’ll fully reveal all of the specifications, and other goodies, in greater detail.
What Happens After Core v3?
Oh no! Is Core v3 the final form of the Core, and you guys will just stop developing? Of course not. When we release Core v3, we can safely say this will become a foundational pillar of the life-long journey for ARK and its ecosystem. One of the main improvements after Core v3 is to implement an improved consensus algorithm based on the Tendermint BFT algorithm.
Core v3 will receive improvements and new features, but Core things will settle down so we can focus on building enticing use cases, Core modules, custom transactions types, development kits, and much more, all of which will be revealed in due time.