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.

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.

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.

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.

Multi-Signatures

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.

Bridgechain Registrations

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-Payments

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.

IPFS Transactions

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.

Delegate Resignation

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.