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