ARK Public Network update to Core v2.6 has been successfully accepted and updated by the delegates! This eagerly-awaited release is packed full of new features and transaction types to enable Developers, Wallet Users and Bridgechains to get more out of the ARK Blockchain Platform. Here’s everything you need to know …
A few months ago we finished up development and released ARK Core v2.6 for public testing on the ARK Development Network. Now, with the final tweaks in place and major testing complete, it’s time for us to roll out the full release to the ARK Public Network. As of today, ARK Core v2.6 is live, and with it comes a whole host of new developer-friendly features and improvements to help you do more and build more with ARK’s blockchain technology.
What’s new in Core v2.6
So what’s new? Well, quite a lot actually… In the most exciting feature-packed release since Core v2.0, we’re introducing a ton of new features and transaction types including:
**Multipayments **— You can now save time, effort and transaction fees when sending ARK to multiple addresses using the Multipayments feature in ARK Desktop Wallet. Add up to 64 addresses that you want to send to, customize the amount and send just one transaction, all in a few seconds.
**IPFS **— With the IPFS feature now enabled, you’ll be able to save an IPFS compliant hash for data saved on an IPFS solution.
Multisignatures — By utilizing Schnorr Signature Schema we’ve reintroduced Multisignatures. This means you can set up a Multisignature wallet where transactions from the wallet must be authorized by a minimum number of participants that you choose while registering it for the first time.
Business Registrations — Any business can now register on-chain and when they become verified, get all of the benefits that are coming in the following months including Deployer, Marketplace and much more!
**Bridgechain Registration **— Bridgechains running on ARK can now officially register on-chain (Business Registration is required beforehand). By registering, bridgechains become a registered member of the ARK Ecosystem. In the future, this registration will enable bridgechains to benefit from inclusion in new initiatives, programs and more.
Delegate Resignation — With the new Delegate resignation transaction type, Delegates who wish to retire can send a “Kill Command” to stop the Delegate from being able to receive new votes. By implementing this new feature, we’ve created a much more simple and efficient way of retiring a delegate.
**Generic Transaction Interface (GTI) **— Developers can use the GTI to create custom transaction types tailored to their exact needs using custom logic. An alternative to smart contracts, the GTI on ARK Core gives developers an incredibly simple way to build their own applications using ARK’s blockchain technology — simple, clean and very effective.
**Nonces for Transactions **— We’ve added nonces for transactions, which means adding a sequential number to transactions to make them unique. This helps mitigate the risk of replay attacks and makes the blockchain even more secure.
By adding all these helpful new features, with Core v2.6 we’re making everything from sending payments to resigning a Delegate better, easier, faster and much more streamlined.
Migrating to Core v2.6
During the time of migration, there could be a period of slower block times as all delegates update. Most of the exchanges will disable deposits and withdrawals as they update their infrastructure to be compatible with Core v2.6.
Node Operators
To get started using Core v2.6 node operators will need to migrate by following the migration instructions found here at **https://guides.ark.dev/core-releases/versions/v2.6**.
End Users
Wallet users will need to download the latest version of the ARK Desktop or Mobile Wallets, which can be download from **https://ark.io/wallet**.
IMPORTANT NOTE: Ledger users (Nano S or X) have to update their Ledger’s ARK App version to the latest release (v2.0.1) via Ledger Live once Core v2.6 is live on the Public Network if they wish to keep using it uninterrupted.
What’s next for Core? Moving towards Core 3.0!
With Core v2.6’s new features now in place, we’ve made it easier for Developers to use the ARK Blockchain platform to build their own decentralized applications, run their own blockchains and more. As most of you already know ARK Core v3.0 has been in parallel development alongside Core v2.6. We’ve made huge progress on the new codebase and don’t want to spoil it too much, but Core v3.0 codebase will become public soon for initial input! While we are still a few months out until Core v3.0 goes live on the Development Network, we are in a development state that we soon want to share with everyone and show what we have been up to.
With Core v3.0, we’ve gone back to basics, improving the quality of codebase and making it easier for developers to jump in. We’ll be introducing common services, a new plugin system for ease of development, new bootstrapping mechanism, taking full advantage of TypeScript by enabling strict mode — with all of this plus more, we’ve opened up the internal architecture and worked hard on providing world-class documentation to aid developers to get into Core much quicker and easier. All this means an incredibly robust blockchain development toolkit that vastly outperforms others in the industry. With Core v3.0 we’re setting the standard for others to follow.
If you’d like to learn more about Core v3.0, then stay tuned, as we’ll be putting out a series of blog posts that goes deep into all the new features, changes, and architecture introduced with v3.0.
Make sure you stay updated by following this blog (by clicking the little icon up to the left of the page), joining our **Slack, or following us on **Twitter, **Reddit **and more.
Changes In Numbers from v2.5 to v2.6
**19 different developers **contributing to the ARK Core v2.6.
441 new commits to the ARK Core v2.6.
867 files changed in the ARK Core v2.6.
455,396 lines of code added to the ARK Core v2.6.
15,783 lines of code deleted from the ARK Core v2.6.
Changes from Core v2.5 to v2.6
Moving from v2.5 to v2.6 these are changes that were introduced:
Added
Expose isValidPeer via ajv format rule (#2960)
Implement AIP 102 (#2773)
Implement AIP 103 (#2858)
Implement MultiPayment (AIP11) (#2669)
Implement nonces (#2573)
Multi Signature support for WIF (#2979)
Transaction type dependencies (#2859)
Add nonce to wallet transformer (#2760)
Allow easy retrieval of first and last block (#2641)
Allow retrieval of raw blocks and transactions (#2616)
Endpoints for locks/businesses/bridgechains (#2940)
Find HTLC unlock transactions (#2976)
Include core version in node/configuration (#2855)
Search transactions by asset (#2618)
Enforce transactions’ nonce order from blockProcessor (#2873)
Change minimum version via milestone (#2869)
Use compression on the p2p level (#2886)
Add support for transaction nonces (#2925)
Attributes getter/setter for wallet (#2839)
Wallet Manager indexes (#2845)
Register wallet attributes before accessing them (#2867)
Allow CLI command configurations (#2972)
Allow passing height to configManager.isNewMilestone (#3001)
Expose transaction height, blockId and generatorPublicKey during bootstrap (#3096)
Add /transactions/schemas endpoint (#3083)
Implement businesses/bridgechains endpoint (#3119)
Implement throttling on outgoing p2p communication (#3170)
Implement Address.fromWIF method (#3228)
Fixed
Always deserialize vendor field
Basic validation on incoming p2p data + terminate socket on error (#3037)
Clone webhook before mutating it (#2863)
Delete existing payload processor db (#2864)
Do not sort transactions in forger / update purgeByBlock logic for handling nonces (#2678)
HTLC refund handler to use performGenericWalletChecks (#2944)
Move wallet manager “zero balance” check to transaction handlers (#2896)
Multipayment balance / vote balance (#2838)
Range selection in pool’s getTransactions() (#2952)
/wallets/{id}/transactions search parameters (#2923)
Return block timestamp for v2 transactions (#2906)
Return count of filtered peers (#2814)
Clear queue on invalid block (#2897)
Do not reset noBlockCounter when downloadBlocks succeeds (#2968)
Only shift milestoneHeights[] if at that height (#2904)
Round deletion during rollback (#2970)
Prefix table names with schema (#2830)
Store vendor field in bytea (#3048)
Add missing typeGroup and emit StateStarting (#2932)
Use correct IV length for encryption (#3036)
Disconnect if api reports different network (#2909)
Don’t cause suspensions for unresponsive plugins ([34749bf84bcec3fecd0098c0d42f52deb1f6ba4a])
Fix the genesis block id during verify (#2809)
Export/import transactions type_group (#2996)
Remove bogus skipRoundRows (#2973)
buildDelegateRanking called too early (#2921)
buildVoteBalances called too early (#2920)
Differentiate between wallets and delegates (#2854)
Index recipient wallets during bootstrap (#2947)
Copy vote target into temp wallet manager ([1209a36366c8fd3ba31fab2463011b7ce1a7d844])
Sort by fee, nonce (#2937)
Implement Delegate resignation (#3045)
Reject delegate resignation if not enough active delegates (#2919)
Update wallet nonce when applying v1 transaction (#2959)
Use supply calculator in delegate approval calculation (#2918)
Cast params in condition checks (#2887)
Add legacy multisignature schema (#3040)
Ensure only one signature per participant (#2889)
Handle mainnet address exceptions (#3055)
HTLC lock buffer allocation (#2936)
Legacy multi signature verification (#2898)
Run ajv validator again when encountering exceptions (#3008)
Use anyOf for transactions schema (#2894)
Use 2 bytes to store number of payments (#2928)
Use strict comparison to decide if a transaction should be enabled (#3087)
Include typeGroup in /transactions/fees and /node/fees endpoints (#3193)
Add missing offset handling to /api/peers (#3075)
Use numerics for typeGroups in /transactions/types (#3112)
Add transactions back to pool only after reverting all blocks (#3138)
Pass IBlockData to processBlocks instead of IBlock (#3426)
Don’t assume blocksInCurrentRound is defined (#3341)
Set last height before initializing last block to use correct milestones (#3109)
Don’t swallow BIP38 errors (#3271)
Use the request origin to avoid 404s (#3071)
Raise getCommonBlocks rate limit (#3069)
Return error when app is not ready (#3171)
Uncaught IPC timeout (#3140)
Support nonces and chunk transactions before broadcast (#3081)
Create new wallet if not found (#3086)
Wallet-manager fallback to database wallet manager findByIndex() when no “local” match (#3256)
Throw if transaction key is already taken (#3095)
Update sender’s wallet after validation (#3291)
Prevent snapshot commands from running if core is running (#3196)
Remove password flag constraint for core:forger command (#3270)
Properly implement block size limit (#3154)
Strengthen schema validation checks (#3062)
Changed
Log the reason for discarding a block (#2903)
Accept prerelease version (#2911)
Add round.missed event (#3011)
Do not temporary increment/decrement nonce when checking transaction validity (#2587)
Increase transaction type size (#2861)
Reject V1 transactions after milestone (#2879)
Remove vendorFieldHex (#3014)
Remove asset migration heuristic (#2999)
Return all registered transaction types (#2878)
Strengthen a nonce check in performGenericWalletChecks() (#2949)
Add default transaction fees (#2842)
Add vendorField and timestamp to /locks endpoint (#3005)
Integrate hapi-pagination to replace fork (#2994)
Use pagination configuration limit ([032caa1b990e91937e4bc1561bc1aeaeca9e37d9])
Break loop if block contains v1 transaction (#2914)
Add nonce column (#2844)
Emit forging.missing earlier (#2893)
Emit missing transaction.reverted event and remove obsolete ones (#2895)
Cleanup socket errors (#3056)
Increase network timeouts (#2828)
Make peer reply errors less verbose (#2962)
Share rate limiter between workers (#2912)
Expose current block for transaction handlers (#2856)
Clear cached transaction ids after accepting block (#2916)
Don’t accept expired v1 transactions (#2948)
Bootstrap transactions in batches (#2997)
Elaborate the unexpected nonce error (#2943)
HTLC implementation (#2915)
Make handler functions asynchronous (#2865)
Use default heap size regardless of available memory (#2998)
Change maximum recipients of multipayment via milestone (#2961)
Export abstract builder for use by plugins (#2721)
Fallback to ECDSA signature for version 2 transactions (#2584)
Make error more verbose (#2938)
Move base58 functions to utils (#2675)
ECDSA Signature deserialization for v2 transactions (#2877)
Remove unnecessary check from validateTransactions() (#2951)
Fallback to core typegroup if querying by type (#3147)
Integrate hapi-pagination to replace fork (#3034)
Sort peers by height, latency (#3078)
Add stateBuilder.finished to ApplicationEvents (#3084)
Make deserializers static (#3234)
Fix genesis and exception transactions cache (#3296)
Overwrite arrays when merging milestones (#3108)
Performance
Avoid O(m*n) when filtering pool txs and simplify the code (#2941)
Ditch unnecessary reindex() in multi-payment bootstrap (#3022)
Keep genesis block instance in-memory ([7a73aef8b29d40572d1524cf8b1bafbffa3b0964])
Use lodash to efficiently remove forged transactions (#2942)
Add index on transactions.type (#3043)
Speed up nonce checks at DB level (#2910)
Make address network byte check part of serde (#3000)
Memoize base58 de/encoding (#3015)
Replace bignumber.js with native BigInt (#3010)
Replace bs58check with bstring (#2673)
A Big Thanks
Finally, we want to say a big thank you to the ARK Community! Thanks to each and every person that explored, tested and suggested improvements or reported issues relating to Core v2.6 while running on the Development Network— your help was invaluable!
Plus, we’d like to give a special shout out to the winners of the Core v2.6 Bounty Challenge, Dated, Alessio and Lemii each earning a bonus reward for topping the **official leaderboard**.
1st place: Dated — 48 reported issues = $2045
**2nd place: **Lemii — 12 reported issues =$810
3rd place: Alessiodf — 5 reported issues = $415
Although the 2.6 Bounty Challenge is now closed, you can still earn ARK for reporting issues or suggesting improvements. Take a look at our **GitHub Development Bounty, or even take on a **custom (Tier 0) project to start earning.
Reporting Issues
For those who experience an error or issue while running your own servers with ARK Core v2.6, please open a Github issue using the link below so that we can review and help resolve the issue as quickly as possible: **https://github.com/ArkEcosystem/core/issues**.
Read our new whitepaper, follow us on social media ( Twitter | Facebook|Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.