ARDOR Implements Game-Changing Features In New TESTNET RELEASE

Do you remember, back in the day, the first time you got your mind blown? I remember fondly how that happened to me with Nxt. That blockchain bastard repeatedly blew my mind – sometimes several times a week as it implemented feature upon feature at such a frantic pace. As such, I became a part of the embracing high-level community of Nxters and eventually surmounted the steep learning curve. It was totally worth it but afterward, I became hard to impress.

Released today, a brand new Ardor testnet finally made my brain cells feel a tiny bit explosive again, and it feels great! Not just a tiny bit, actually. The client that lands today is blockchain 2.0 evolution at its finest. Let the popular experts, and all the great blockchain visionaries do their talks. Jelurida just wrote it in code. Again. Let others continue to talk about TPS, ignoring scalability and security, we covered it already. And if you don’t know about Nxt, you should read up.

Ardor 2.0.4e

The Nxt and Ardor core dev team at Jelurida presents to you: New asset control features, multiphased smart transactions, a new API for creating regulated tokens on the decentralized Asset Exchange, and a transaction type that allows asset issuers to increase the number of asset shares in existence. All of this is an addition to all the existing core features and API.

This new Ardor testnet release resets the existing testnet and publishes a new Genesis block that tests the transition of data from Nxt to Ardor, based on a snapshot made of Nxt’s mainnet at block 1558000, shortly after the last JLRDA (IGNIS) exchange offer expired.

The testnet Genesis block timestamp has been set to 00:00 (midnight) UTC time
on Monday, Nov 6th, in order to allow time for users to setup nodes check their balances, and start forging.

From the Nxt blockchain has been transferred the following:

  • Accounts (public keys)
  • Account balances
    • IGNIS balances are based on NXT balances, divided by 2, plus JLRDA asset balances. Each of those has been additionally divided by 2, in order to allocate 50% of the testnet coins to developer accounts for testing purposes. There has been a 10% BITSWIFT asset sharedrop distributed proportionately to all IGNIS shareholders.
  • Account info (name and description)
  • Account properties
  • Account control settings for account control by whitelist with no minimum balance.
  • Account aliases transferred to the IGNIS child chain.
  • Janus, JanusXT, and ComJNSXT assets have been imported.
  • Monetary system currencies have been imported to the IGNIS child chain.
    • Only currency code and name. It will be up to each currency issuer to re-issue the currency with the appropriate properties and re-distribute it to users.

Lior Yaffe kindly asks all of us to check our accounts on Ardor and make sure everything has happened correctly:

If you are only interested in checking your balances head to the Jelurida public node , login using your existing NXT Mainnet account id (no need to login using passphrase) and check your ARDR, IGNIS and BitSwift balances. In addition, check your Janus asset balances, aliases, account properties, currencies, account control and all other entities migrated from the NXT Mainnet according to the changelog.

When you check, be aware that your IGNIS and ARDR holdings have been divided by 2 in this testnet release, so 50% of the tokens can be allocated to dev accounts for testing purposes.

Read all details here.

This was to be expected. Massive work, yes, all as promised and fair for a call to shift from one platform to the N(e)XT, Ardor. Pun intended. There are API changes too, and new API, coders please (you must!) check the change-log.

What made my brain cells begin to feel explosive again then?

New features

Yes, the new features. Nxters run. Run out there and share it with the world!

The change-log for Ardor 2.0.4e presents the following new transaction types – add to them all that the Nxt blockchain’s smart transactions and Ardor’s globally scalable, energy efficient child chain platform design can do, and you will see clearly the size of this gamechanger. This is what the release implements:

Asset control

Allows an asset issuer to control her assets. That’s right. As the issuer you decide who can buy and sell them; a small group of selected people, only KYC verified accounts, perhaps. Or you could send non-transferrable assets to a board of holders and give them voting rights over the asset. How about that. Read it again and let it sink in – with this release you, the issuer, will get complete asset control.

No, it’s not the end of a free market. Ignis is free. It is a new opening that allows all new as well as old running businesses to shift their old backend to Ardor and Ignis and receive all the benefits of the blockchain as a business backend, consumer front-end, and even get it cheaply.

Example:

  • Have an ICO/crowdfunding on Ignis
    Upload contracts and legal documents to the data cloud, time-stamped, hashed, let the KYC compliant accounts of your business partners or angels digitally sign the agreements, this will be documented on the blockchain as well.
  • Issue your asset tokens
  • Decide which rights you want to give to your asset holders, and to your market.
  • Distribute assets, each with the rights attached that you assigned to them. Watch them be traded.

Selected (or all) asset holders can have voting rights. You can pay dividends in any token on the platform; IGNIS, another child chain coin, an € pegged coin, that can be withdrawn with your VISA/Mastercard or just sit in your bank account. Or in other assets, representing bonus points, tickets, whatever fits your business plan. You could even create games with this. It is here.

We welcome this Java code, the Asset Control feature, as one of the best newest addition to the already existing API.

Composite Phasing

Introduces AND, OR, and NOT to Nxt’s Phased Transactions. This, combined with the new Asset Control feature, adds whitelist control over asset holder accounts, you can choose, for example, which asset holders should have the opportunity to vote or even control an account by vote. Even control the whitelist of new accounts. Do you see the better DAO coming?

It also allows for example combining the existing by hash or by transaction approval models with by whitelist, by balance, etc, approvals, which enables doing atomic coupling of transactions (including cross-blockchain) even for multisignature accounts, or with assets subject to Asset Control.

I couldn’t say it better.

The NOT operator allows for dead-man-switch type conditions, where a transaction is executed only if some condition (e.g. revealing a secret) is NOT satisfied.

Source

Asset share increase

With this new smart transaction type, asset issuers can increase the number of assets in existence. Print new money?!!

The new shares are allocated to the asset issuer account, but can then be distributed to shareholders using a separate dividend payment transaction. This allows corporate actions such as capital increases or stock splits to be performed.

Be careful, like we all learned in Economics 101, increasing the supply of money will decrease the value. Take care not to dilute your asset into nothingness.

By-Property phasing

First, if you don’t know Nxt’s feature “Account Properties”, I should fill you in: Account Properties is a Nxt feature that adds the ability to permanently ‘tag’ any account on the blockchain with a small amount of data, like meta-information. Tags can also be deleted by the tagger.

Let’s see what By-Property phasing is:

 

The new by-property approval model allows the transaction execution to be made conditional on the sender account or the recipient account having a specific account property set. If this property is set, the transaction will be executed immediately, else, a second check whether the property is set is performed at the finish height defined. This allows, for example, enforcing KYC by asset issuers, who can define in their Asset Control settings that only KYC-verified accounts, labelled with a predefined account property by a trusted authority (or the asset issuer itself), to perform transactions with their assets.

So with this feature, the blockchain market is regulated.

With this, you can, for example, in the near future, issue an asset on any Ardor child chain, trade it on any child chain, but enforce/be enforced to only let KYC approved accounts trade it on the market. Or choose by country. Or any group. With Ignis, asset issuers and traders can choose whether or not to trade on the regulated market, but we all know: Regulation will be. The new By-Property phasing API makes it not just possible but also easy and cost-effective to develop as a user-friendly service, and yeah, remember, the main purpose for Nxt 2.0, Ardor, was actually to make it globally scalable.

Where does this leave us? Accounts can be tagged by 3rd party KYC service providers or, even better, by governments, may they ever choose to set official ID on accounts and begin using the benefits of the blockchain. Don’t get me started. Secure us, our medical records, money, ID – let us be secured by cryptography. Jelurida’s code does it for them. Give us voting rounds that cannot be interfered with as the result is public, and votes have already been counted by code, see the graph. It’s on blockchain, but energy efficient, secured by nodes all over the world, and while we’re at it – possible. And see, Ardor has, as another first, a solution to the blockchain bloat problem running in production. The first and most tested globally scalable PoS Platform. It’s here, get started.

Sure I am excited. I’m a Nxter. Aren’t you?

Come on, try it!

For newcomers, it may seem weird that scammers and developers collect millions and millions of dollars worth of ETH or BTC in ICO’s, selling their whitepaper only, describing smart contracts they want to invent, code, test, execute, and need us to trust, when old Nxt Cryptocurrency 2.0 already has the functionality that most of them seek. It’s weird that what most of all of these devs and their investors are trying to achieve already exists on Nxt, that now gets further ahead with the scalable and even more beneficent and featureful public Ardor Platform. Yes, it IS weird, that Nxt has been under the radar and ignored by, for example, the larger Bitcoin-paid media for so many years.

The Nxt core devs, Jelurida, has split Nxt into IGNIS, the transactional token of Ignis, the first and unrestricted full featured child chain on Ardor; the mother blockchain that forges all Ignis’ transactions and will give birth to a lot more and take care of all her children (child chains), as well as make sure they keep communicating with each other. This is Ardor. With Nxt being a blockchain 2.0 platform, should Ardor be called blockchain 3.0? Nxt 4.0? Who cares. If you’re just a little familiar with Bitcoin, blockchains and smart transactions, you will realize that you want to test this release.

For those who want to setup an Ardor full node, install the software as usual and start forging, the first block will be generated tonight at 00:00 (midnight) UTC time on Monday, Nov 6th (about 14 hours from now)

If you are installing on top of a previous Ardor release delete first the nxt_test_db folder from C:\Users\<username>\AppData\Roaming\Ardor on Windows, ~/.ardor on Mac and the Ardor installation folder on Linux. If you don’t do that you’ll be left on a fork.

Follow the development closely and take part in the community. Even without the awesome potential that awaits us with this momentous release, it’s always mindblowing development.

 

New public Ardor repository

Nxt and Ardor lead developer Jean-Luc (Jelurida) has announced that he will change the location of the official public Ardor repository from https://bitbucket.org/JeanLucPicard/ardor/downloads/ to https://bitbucket.org/Jelurida/ardor/downloads/

Ardor packages uploaded to the Jelurida repository will be signed with the
official Jelurida software releases signing key, 0xC654D7FCFF18FD55, already
used for signing the Private Blockchain Evaluation Kit packages.

The latest release 2.0.3e has already been uploaded to the new location.
In a few days, the old repository will be deleted, with a notice directing
users to the new one. Please update any hardcoded website links.

Source: https://nxtforum.org/nrs-releases/ardor-public-repository-migration

Ardor v2.0.3e

Ardor v2.0.3e

THIS IS THE LATEST ARDOR RELEASE

Link to all releases.

Digital signature: "Stichting NXT"

.sh Sha256:
58f5f96c189db2e77eb7dd6ae08e7c34cb4aceb4c651447241167718e6c8c3a1  ardor-client-2.0.3e.sh

Release 2.0.3e:
https://bitbucket.org/Jelurida/ardor/downloads/ardor-client-2.0.3e.zip

2.0.3e .zip Sha256:
1939865688b35c40d9c6cda160fb6f61bc2c6022e85dba4057b4deec3a81f54e  ardor-client-2.0.3e.zip

Release notes

Minor unconfirmed transaction processing improvements.

Coin Exchange UI improvements and bugfixes.

Updated jetty to version 9.3.17.

This is an experimental release for testing only.

-

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-3e/


Core development:
https://www.jelurida.com

Jelurida Q&A – Nxt core devs mean business

 

About Ardor

Ardor roadmap
Website: www.ardorplatform.org
ARDR asset: https://nxter.org/ae-ardr

Holding the ARDR token provides the ability to bundle many child chain transactions into a ChildChainBlock transaction on the main chain (i.e. become a bundler) and forge transactions on the main chain.

ARDR is trading on Nxt AE and on central exchanges.

DEVELOPERS

Using the Nxt / Ardor API
Nxt and Ardor feature comparison

Ask for test-ARDR here: Nxtforum thread

TESTNET DEMO:
https://demo.ardorplatform.org/index.html


Public testnet launched on February 11, 2017:

Ardor Testnet is Launched

Ardor-testnet

Ardor v2.0.2e

Ardor v2.0.2e

FOR THE LATEST ARDOR RELEASE CHECK HERE

Digital signature: "Stichting NXT"

.sh Sha256:
76078b6d644e0cd3c05ecdb3aede491c79194351798077ee48b3d4a7efb56434  ardor-client-2.0.2e.sh

Release 2.0.2e:
https://bitbucket.org/JeanLucPicard/ardor/downloads/ardor-client-2.0.2e.zip

2.0.2e .zip Sha256:
056e5ae312b5f2fa43d0f2269bfb4611b7df8d64f643470cae8a70b946feba0c  ardor-client-2.0.2e.zip

Release notes

This release introduces an incompatible networking change in bundler rates propagation and is, therefore, a mandatory update for all Ardor testnet nodes.

Improvements in bundler rates handling and APIs:

The GetBundlerRates API now also returns the bundler account and the remaining fee limit for each bundler as currentFeeLimitFQT.

The new GetAllBundlerRates API returns all bundler rates known to the node, for all child chains, subject to optional minBundlerBalanceFXT limit on the bundler effective Ardor balance.

The new BlacklistBundler API allows manual blacklisting of bundler accounts. Rates advertised by such accounts will not be added to the local list of known rates each node maintains. Blacklisting of bundler accounts is also possible using the new nxt.blacklistedBundlerAccounts property.

Bundler rates are now broadcasted every 30 min instead of once an hour.

The new nxt.minBundlerFeeLimitFXT property allows skipping bundler rates that are announced by bundlers with lower remaining current fee limit, default 10 Ardor.

Added peer authentication and encryption framework for the peer networking, to be used for permissioned blockchains.

Added Bundle action for child chain transactions in the UI. Added visual representation of transaction bundling and confirmation status.

Client UI and peer networking bugfixes and improvements.

Updated H2 to version 1.4.194.

-

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-2e/

About Ardor

Ardor roadmap
Website: www.ardorplatform.org
ARDR asset: https://nxter.org/ae-ardr

Holding the ARDR token provides the ability to bundle many child chain transactions into a ChildChainBlock transaction on the main chain (i.e. become a bundler) and forge transactions on the main chain.

ARDR tokens are trading on Nxt AE and on central exchanges.

Initial distribution: Nxt 2.0: Ardor child chain blockchain platform

DEVELOPERS

Ask for test-ARDR here: Nxtforum thread

TESTNET DEMO: https://demo.ardorplatform.org/index.html

Public testnet launched on February 11, 2017:

Ardor Testnet is Launched

Ardor-testnet

ardor v2.0.1e

Ardor v2.0.1e

FOR THE LATEST ARDOR RELEASE CHECK HERE

Not available yet

Digital signature: "Stichting NXT"

.sh Sha256:0e73f4b9ff9709c58cf9b54ff70f8db34841835bc39073953fef982a5daed99d  ardor-client-2.0.1e.sh

Release 2.0.1e: https://bitbucket.org/JeanLucPicard/ardor/downloads/ardor-client-2.0.1e.zip

2.0.1e .zip606d6ada92bb9bb3925442ad97c95cea8c61258c963c828e6d7629d9552df9c5  ardor-client-2.0.1e.zip

Added Node JS module

Ardor 2.0.0e is the first public release of the Ardor testnet.

With 2.0.1e several bug fixes have been added.

Also, Riker writes:

"Earlier attempts to develop robust client API library for NXT and subsequently Ardor were faced with several challenges:
1. The API library had to send the passphrase directly to a remote node in order to sign transactions, this meant that the remote node had to be trusted, this severely limited the usability of the API library.
2. Some client libraries did implement local transaction signing but still were unable to validate unsigned bytes data returned from a random remote node thus still making it somewhat insecure to submit transactions to a random remote node.
3. Client API libraries were developed by 3rd party developers which sometimes couldn't keep up with the protocol changes.

In order to address these problems, in release 2.0.1e we introduced for the first time a Node JS module which can be used for JavaScript application development using the Ardor platform APIs.
This node JS module is now integral part of the core and in fact is just a thin layer of Node JS wrapper on top of the existing Ardor Wallet JavaScript code.

Being so this node module has several advantages:
1. The Node JS module is able to work securely against any random Ardor node
2. Transaction data submitted to a remote node is validated against the returned unsigned bytes
3. Transactions are signed locally so that the account passphrase is never submitted to a remote node
4. Message encrytption can be performed client side
5. API calls work at a higher level compared to the APIs provided by the existing test page, so that for example, complex numeric conversions and various formatting functions are alreayd implemented by the API library
6. Updates to this API library will follow the standard Ardor release process and will be maintained by core developers

To quickly get started using the node JS module, see instructions in the ./html/www/js/README file which is part of the 2.0.1e release.
The ./html/www/js/sample folder contains several code examples to get you started quickly and provide a reference implementation."

Source: https://nxtforum.org/general-discussion/ardor-node-js-module/

Release notes

Change log:

This is a bugfix release, for testnet only.

Added Node JS module, see html/www/js/README.

Multiple bugs fixed and improvements added in client UI, peer networking, blockchain download.

Removed obsolete news page, added About modal.

This release will force a rescan, deleting blocks after height 11619.

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-0e/

For more information about the Ardor testnet launch, see this post. Read the release notes for Ardor v2.0.0e: https://nxter.org/ardor-v2-0-0e/

Learn more about the Ardor platform from www.ardorplatform.org.

ARDR assets representing real Ardor tokens are traded on exchanges.

Also see: Nxt 2.0: Ardor childchain blockchain platform

Ardor v2.0.0e

Ardor v2.0.0e

THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE

Not available yet

Digital signature: "Stichting NXT"

.sh Sha256: 32ed1df94300275cf8aac9966a3f26bc6cf607c646fda54f7966953cab9aa882  ardor-client-2.0.0e.sh

Release 2.0.0e: https://bitbucket.org/JeanLucPicard/ardor/downloads/ardor-client-2.0.0e.zip

2.0.0e .zip sha256:b814ec631d37e2afc1319a458525d1cfd61c583f61f1d77d8312bc7249131711  ardor-client-2.0.0e.zip

Ardor testnet is here

Ardor 2.0.0e is the first public release of the Ardor testnet.

Read more about the launch in this post.

Learn more about the Ardor platform from www.ardorplatform.org.

ARDR assets representing real Ardor tokens are traded on exchanges.

 

Release notes

This is the first release of the Ardor software, for testnet only. It represents the first milestone in the building of the Ardor platform.

New Features

The main new user-visible feature is the existence of a single forging chain, using the ARDR token, and multiple child chains, each with its own token.

Forging Chain

The Ardor chain is used to establish the proof-of-stake consensus, using ARDR balances only. It supports only a few transaction types: ordinary payments, balance leasing, and coin exchange. Prunable plain or encrypted message attachments are also supported, but not permanent or standalone arbitrary message transactions.

Child Chains

The child chains support all transaction types as previously implemented on the Nxt platform, with the exception of balance leasing which is only available on the Ardor chain, and tagged data extend transaction which has been removed as unnecessary. A child chain can optionally be configured to disable certain transaction types, which has been done for testing purposes on the EUR child chain, disabling the Asset Exchange and Digital Marketplace.

Coin Exchange

To allow trading of child chain coins to each other, and also between child chains and the Ardor chain, a new Coin Exchange module has been implemented.

For trading between child chain coins, the coin exchange transactions are submitted on the child chain of the coin being sold. For trading between a child chain coin and Ardor, the transaction is submitted on the Ardor chain regardless of whether it is a buy or sell, and the fees for such transactions are higher.

Bundling

The bundling process is used to group child chain transactions from a child chain into a transaction on the Ardor chain. Bundlers accept the fees from those child chain transactions, in the corresponding child chain coin, and pay fees in ARDR to the parent chain forgers. Bundlers can be started from the cogwheel/bundlers menu, defining the coin to ARDR exchange rate they accept, a limit on the total fees in ARDR a bundler will pay, and an optional overpay amount.

When a bundler is running, it checks the unconfirmed transactions pool every time a new transaction from the child chain being bundled arrives. If the transaction fee included by the transaction sender, in child chain coins, when converted to Ardor using the exchange rate accepted by the bundler is at least equal to the minimum Ardor fee required for this transaction, the bundler will generate a ChildBlock transaction, including in it this and all other currently unconfirmed child chain transactions satisfying this requirement.

The Ardor fee the bundler will include for the ChildBlock transaction is equal to the sum of the minimum required Ardor fees for each, plus the calculated overpay amount, if any. Such overpay amount is optional, and may be used by bundlers willing to pay more in order to have their transactions included in block instead of those of competing bundlers.

The new ChildBlock transaction will displace from the unconfirmed pool any ChildBlock transactions of the same child chain that include only a subset of the same child transactions.

When propagating through the network, ChildBlock transactions will only be accepted by peers if they either include child transactions not already included in other ChildBlock transactions the peer already has in its pool, or offer to pay a higher fee for the same transactions. This ensures the network is not flooded with ChildBlock transactions even if every node is running a bundler, and allows bundlers to compete for propagating their transactions through the network by offering to pay higher fees.

It is now possible for child transactions to be submitted with zero fees, in child chain coins. If a bundler is willing to pay the Ardor fees for those, they will be included in the blockchain in the ChildBlock created by such bundler.

To prevent the unconfirmed pool from being overfilled with such zero-fees child chain transactions, once the maxUnconfirmedTransactions limit (configured in nxt.properties, default 2000) has been exceeded, child chain transactions will be dropped unless a bundler has already submitted a ChildBlock transaction which includes them.

Bundlers advertise their accepted bundling rates to other peers, signing such rates announcements with the private key of the bundler's account. To prevent fake rates announcements, they can be filtered based on this account effective balance (default set in nxt.minBundlerBalanceFXT is 1000 ARDR).

The GetBundlerRates API can be used to retrieve known bundlers rates, again with optional filtering by minimum bundler effective balance.

Peer Networking

The peer networking has been fully re-written and optimized to use socket connections and binary messages instead of http and JSON.

Block and transaction propagation through the network has been optimized, by sharing with peers the inventory of transaction IDs in the unconfirmed pool or in recent blocks, and only propagating the missing ones, if any, when a new block is generated, or a child block is bundled.

The hallmark feature has been removed as it is not needed anymore, hallmarks are no longer supported.

New APIs

APIs of the new Coin Exchange feature:
ExchangeCoins, CancelCoinExchange, GetCoinExchangeOrder, GetCoinExchangeOrders,
GetCoinExchangeOrderIds, GetCoinExchangeTrade, GetCoinExchangeTrades,
GetExpectedCoinExchangeOrderCancellations, GetExpectedCoinExchangeOrders,
GetLastCoinExchangeTrade.

Bundling related APIs:
BundleTransactions, GetBundlers, GetBundlerRates, StartBundler, StopBundler.

Other new APIs:
GetBalances, GetEffectiveBalance, GetFxtTransaction.

API changes

All APIs that are now chain specific accept a new chain parameter. Either the chain name or the chain ID can be used.

Transaction IDs are no longer 64-bit longs but 256-bit hashes, necessitating changes in all APIs that accept transaction ID parameters or return such in the JSON fields. For transactions on the Ardor chain, 64-bit long IDs can still be used with the getFxtTransaction API, as those are enforced to be unique. For child chain transactions, the getTransaction API now requires a fullHash parameter, in addition to specifying the chain.

Prices and rates are now defined relative to a whole unit of the holding being bought or sold (asset, currency, coin), not to a QNT indivisible unit.

All priceNQT and rateNQT parameters and JSON fields have been renamed where appropriate to priceNQTPerCoin, priceNQTPerShare, rateNQTPerUnit, etc., to reflect their changed meaning of price per whole unit of each holding rather than per QNT.

All "units" parameters in the Monetary System APIs have been renamed to unitsQNT.

DividendPayment API accepts holding and holdingType parameters to allow paying dividends in another asset or MS currency. The amountNQTPerQNT parameter has been renamed to amountNQTPerShare and now refers to dividend amount in NQT per
a whole share of the asset rather than per QNT.

The GetAccount API no longer returns balanceNQT and unconfirmedBalanceNQT, as balances are now chain specific. The GetBalance API should be used to get chain balances instead, or GetBalances for querying multiple chains.

APIs which accept holding and holdingType parameters now require holding to be set to the chain ID when holdingType=0 (coin).

Since 0 is now a valid fee value for child chains, all CreateTransaction APIs will accept it, instead of using it as a request for the server to calculate and use the minimum fee. To let the server calculate the child transaction fee, a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must be supplied, to indicate the exchange rate to use when calculating the fee (since minimum fees can only be calculated in ARDR). If feeRateNQTPerFXT is also set to -1, the server will query the currently known bundlers rates for this child chain, also subject to the minBundlerBalanceFXT limit on effective bundler account balance, and use the best one for the fee calculation. As bundlers rates cannot be trusted blindly, the transaction will not be broadcasted in this case, the returned transaction JSON including the fees calculated should be reviewed by the user. The bundler rate used will be returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for the chain.

The following APIs have been removed: ExtendTaggedData, GetPhasingPolls, GetTaggedDataExtendTransactions, GetInboundPeers, MarkHost, DecodeHallmark.

Transaction types and bytes format

The numbering of some transaction types has changed, due to the internal reorganizations of the TransactionType classes. Transaction types on the Ardor chain use negative numbers, e.g. -1 for ChildChainBlock, -2 for Ardor ordinary payment. Some transaction subtypes have been moved to a separate type, e.g. voting and phasing related transactions have been moved out of Messaging to a new Voting transaction type. The output of getConstants should be consulted for a full list of the current transaction types and subtypes.

The transaction bytes format has also changed, adding a chain ID, reorganizing the ordering of attachment and appendix bytes, and allowing prunable attachment parts to also optionally be represented in the bytes format, for the purpose of sending them more efficiently over the peer to peer network.

The JSON transaction representation is still supported, even though it is no longer used in the peer networking. Some attachment fields have been renamed for consistency with the API changes - units to unitsQNT, priceNQT to priceNQTPerShare, rateNQT to rateNQTPerUnit, amountNQT for dividend payments to amountNQTPerShare, etc.

Entity IDs

As part of designing child chain transactions to be prunable, it is no longer possible to enforce uniqueness of the 64-bit transaction IDs for child chains. This affects the IDs of derived entities such as Assets, MS Currencies, Polls, Digital Goods, Shufflings, etc.

For global derived entities such as Assets or Currencies, the 64-bit long IDs are still unique and used in the corresponding APIs. Note however that this uniqueness is now only within the same object type, i.e. it is not guaranteed that an Asset and a Currency will not happen to have the same 64-bit long ID.

For child chain local entities, such as Polls and Digital Goods, the 64-bit IDs are still unique, but within the same child chain only, and still used in their APIs. Again, there is no uniqueness guarantee across different entity types anymore.

For entities that are prunable, such as prunable messages, tagged data, and shufflings, the full 256-bit hash must be used as an ID now, and the appropriate APIs have been changed.

Phasing and Account control

Only child chain transactions can be phased. Therefore, when account control is set for an account, it can no longer submit Ardor chain transactions.

Phasing parameters which refer to transaction IDs must now use transaction full hashes instead, prefixed with the chain ID separated with ':'. It is possible to refer to transactions on other chains when approving a phased transaction, or setting up a by-transaction phasing voting model.

The controlMaxFees parameter when setting mandatory approval now accepts multiple values, each fee being prefixed with the child chain ID and ':', to indicate which child chain the limit applies to. If no max fee has been set for a child chain, there is no phasing transactions fees total limit on it for the controlled account.

Transaction selection, sorting, limits and fees

An Ardor chain block can contain up to 10 (ten) transactions, this including both native Ardor transactions and ChildBlock transactions. There is no total payload size limit.

A ChildBlock can contain up to 100 (one hundred) child transactions, subject to a total payload limit of 128 kbytes. Prunable child transaction parts are also counted towards the payload size limit.

There is a limit of one ChildBlock per Ardor block for each child chain.

As in Nxt, it is up to a block forger which transactions to include in a block and how to sort them. The default forger behaviour is to select transactions ordered by Ardor fee (not fee per byte as in Nxt, since there is no block payload limit), and then sort them based on arrival timestamp.

It is also up to the ChildBlock bundler which child transactions to include in a ChildBlock, and this selection can be customized by defining a custom filter in the nxt.bundlingFilter property. The default bundler behaviour is to select child transactions ordered by fee per byte, up to the count and payload limits of a child block, creating several child blocks if necessary. Within a child block, child transactions are sorted based on their full hash, but executed based on sorting them after adding the block hash to the child transaction hash, i.e. the execution order of child transactions within a block is deterministic but not predictable and not controllable by the bundler or by the forger. This is in order to prevent front-running of asset exchange and other trading orders.

Ardor fees from ChildBlock transactions paid to the block forger are shared with the previous three block forgers in 1:1:1:1 ratio. Other Ardor chain fees are fully kept by the block forger, and child block transaction fees (in child chain coins) are fully kept by the ChildBlock bundler.

The back fees sharing which was applied in Nxt for some other transactions types such as currency or asset issuance has been removed, however the limitations of one such transaction per block for scarce blockchain resources are preserved.

Default fee for Ardor chain transactions is 10 ARDR. Default fee for child chain transactions is 0.1 ARDR. A ChildBlock must contain at least one child chain transaction, but there is no minimum ChildBlock fee requirement, i.e. such a ChildBlock with a single transaction in it would require only 0.1 ARDR fee if this is the minimum fee for the child transaction it contains.

Fees for child chain transaction types have been scaled depending on their impact on the blockchain, e.g. asset issuance fees are still 1000 ARDR as assets are global and kept permanently. There is a 1 ARDR extra fee added to transactions that create a new account.

The above fees and limits are set for the current testnet only and are subject to change before the production mainnet release.

Testnet accounts

The testnet genesis block has been created based on account balances from the Nxt testnet, as of 2017/01/01 (block height 1061208). Users who had testnet accounts as of that height should find their ARDR and NXT testnet balances imported into this testnet, to ARDR and IGNIS tokens respectively, plus an approximately equivalent amount of BTC, USD, and EUR child chain coins for testing. To allow for developers testing and running forging and bundling nodes, account holdings have been reduced by 50% which have been allocated to developers accounts.

Upgrading from Nxt

The Ardor release is not an upgrade and does not in any way affect your existing Nxt account or client installation. Both Ardor and Nxt should be possible to run simultaneously on the same machine, as long as the hardware capacity allows it.

The included ArdorNxtComparison.pdf document summarizes the major differences between the Nxt and Ardor platforms, for those deciding which one is a better fit for their use case, or considering a migration from Nxt to Ardor. More documentation should be added as Ardor development and features mature and stabilize.

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-0e/

Also see: Nxt 2.0: Ardor childchain blockchain platform