Ardor vs. the Competition, Pt. 8: Ethereum (Blockchain Bloat)

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

This article continues the previous installment’s comparison between Ardor and Ethereum. This time, I explore how each platform approaches the problem of blockchain bloat. To my surprise, the two platforms are more similar in this regard than I had initially thought, though there are certainly significant differences, too.

Key to this comparison is an understanding of how the Ethereum blockchain is organized.

Ethereum’s Structure

Like Nxt, Ethereum tracks the current state of all accounts with each new block. And like Bitcoin, Ethereum organizes the information in each block into a Merkle tree (actually, three of them) and stores its root hash in the block’s header.

How exactly does this work? The diagrams from this article help to illustrate.

 

The leaf nodes of a Merkle tree (i.e., those at the bottom) represent all of the actual data stored in it. Each node above the leaves stores a cryptographic hash of its two children. (Note that I’m using “node” here to refer to items in the tree, not computers on the network. Each computer on the network stores the entire tree.)

This design has the property that if even a single leaf node changes by a single byte, the hash of its parent changes as well, along with the hash of its parent’s parent, and so on all the way up to the topmost node, called the “Merkle root.” In a sense, the Merkle root contains a digest of all of the information in the leaf nodes.

Simply grouping all of the leaf nodes together and hashing them all at once would produce a similar result, but the tree structure has a second nice property, which is that it is possible to prove that a single leaf is in the tree without seeing the entire tree. For example, in this diagram it is possible to prove that the green transaction has been included by supplying its sibling, in yellow, their parent, in gray, and the other siblings and parents along the path back to the root. Another user can compute the relevant hashes at each level in the tree, then compare the resulting Merkle root to the one stored in the blockchain. These “Merkle proofs” are the foundation of Bitcoin’s simplified payment verification (SPV) clients, and also several of Ethereum’s scaling proposals.

Ethereum uses three separate Merkle trees to record the data in each block: one for the block’s transactions; a second for a set of “receipts” for those transactions, which represent each transaction’s effects; and a third for recording the instantaneous state of all accounts, including their balances and associated data. Storing the entire state of the system with every block sounds tremendously wasteful, but since each block modifies only a very small subset of leaf nodes, most branches of the state tree do not change from block to block, and each new state tree can refer to entire branches of the previous one with minimal overhead. There are a few technical complications with this approach, and for that reason Ethereum actually uses a slightly different data structure called a Merkle-Patricia tree, but the concept is the same.

Ethereum’s Fast-Sync Nodes

The most important fact in all of this is that the properties of cryptographic hash functions ensure that it is practically impossible to construct two different trees with the same root. As a result, the record of Merkle roots stored in Ethereum’s block headers is sufficient to establish that the network at the time validated the corresponding transactions and state transitions.

In other words, even after a node has “forgotten” the contents of old blocks, as long as it keeps the (much smaller) block headers in storage, it can query a full node for a given block’s contents and verify for itself that the full node has not tampered with any data. It does this simply by recomputing the relevant Merkle roots and comparing to the corresponding values in the block’s header. (Note that here and for the remainder of the article, I’ve switched back to using “node” to refer to a peer on the network, not an item in a Merkle tree.)

This approach is exactly how the Go Ethereum (geth) wallet’s fast-sync option works. To perform a fast-sync, a new node first downloads and verifies all block headers, starting with the genesis block (actually, only every 100th block header must be verified; see the GitHub link for details). Since the headers contain the proof-of-work, this step is sufficient to show that the network came to consensus about the Merkle roots in each header at the time the block was mined.

At some point in the recent past, say, 1024 blocks ago, the node gets a full version of the state tree from its peers and validates it against the Merkle root in the corresponding header. From that point forward, the node downloads full blocks from peers and replays all transactions until it has reached the most recent block, at which point it simply turns into an ordinary full node.

Although Go Ethereum does not currently support it, it is also possible for nodes to continuously prune the state tree as time progresses, keeping the amount of state data that must be stored to a minimum.

Child Chain Pruning on Ardor

If you have studied Ardor’s parent-chain/child-chain architecture, this strategy hopefully sounds quite familiar. Ardor takes a very similar approach with regards to its child chains.

Briefly, the Ardor platform consists of a single proof-of-stake parent chain, also called Ardor, and a set of child chains. The parent chain supports only a few transaction types, basically, just those required for transferring ARDR around and for forging with it. The child chains, in turn, handle all of the actual business conducted on the platform using the smart transactions I described in the previous article in this series.

Only the parent chain’s coin (ARDR) can be used to forge. Transactions involving only the child chains’ coins do not affect the balances of the forging coin, so they are not essential to the security of the blockchain and do not need to be stored permanently. Special “bundler” nodes on each child chain collect these transactions, group them together, hash them, and report the hash to the network using a special transaction type called ChildChainBlock. They include the full transaction data along with each ChildChainBlock transaction, so forgers and other nodes can verify that the child-chain transactions are valid and do indeed produce the reported hash, but the transaction data itself is not stored in the blockchain, and after a specified time passes it can be pruned away. All that remains in the parent blockchain is the hash of this data.

Optionally, special archival nodes on each child chain can store the full history of that child chain’s transactions. In cases where this history is needed, nodes can retrieve it, hash the original bundles of transactions, and verify that the hashes match the ones recorded on the blockchain.

Hopefully, the comparison to geth’s fast-sync option is clear at this point: in both cases, nodes do not need to store the vast majority of transaction data to be able to verify that the network approved of those transactions at the time they were made. On Ethereum, it is sufficient to verify the proof-of-work in the block headers and the accuracy of any given Merkle root to be able to trust the corresponding state tree. Ardor is slightly more complicated because it uses proof-of-stake for consensus, but storing the full record of ARDR transactions along with ChildChainBlock transactions ensures that nodes can verify, starting from the genesis block, that each block was forged by an eligible forger.

Comparing the Two Designs

At this point, I hope you agree with me that we can draw the following parallels between Ethereum and Ardor:

  • An Ethereum full node is similar to an Ardor node that also stores the full history of every child chain.
  • An Ethereum fast-sync node that continuously prunes the state tree is similar to an ordinary Ardor node, which stores the full parent chain but prunes away all child-chain data.
  • Ardor offers the ability to run a node that stores the entire parent blockchain, plus the archived transaction data for a single child chain. This option currently has no equivalent on Ethereum.

These analogies are not perfect, of course. Specifically, it is worth noting that Ethereum’s block headers are considerably smaller than full parent chain blocks on Ardor. I’ve also glossed over the mechanism that Ardor uses to track snapshots of the full state of the system and store hashes of those snapshots in the parent chain.

Still, I think this comparison is helpful. The third item in this list is especially interesting since it seems to be the biggest qualitative difference between the two designs. On Ardor, the ability to store each child chain’s transaction history in a separate set of archival nodes allows for a type of vertical partitioning of the blockchain database. Since each child chain likely supports a different business or project, partitioning the total set of all transactions along the lines defined by child chains seems like a natural choice. On Ethereum, perhaps the best analogy would be a design where a user could run a full node for a single project, like Golem, without having to simultaneously run full nodes for Augur and BAT and hundreds of other projects.

On that note, it strikes me that Ethereum’s Merkle trees might naturally accommodate such a design, where a “Golem full node” would search the full blockchain for all transactions involving GNT, store Merkle proofs for those transactions and state transitions permanently, and discard the remaining data. I admit I haven’t thought through the implications of this idea, though, so I won’t say much more about it here.

In any event, neither this hypothetical strategy for Ethereum, nor Ardor’s parent-chain/child-chain architecture, represents true sharding of the blockchain, since in both cases each node still must process all transactions from the whole network. These designs partition the storage, but not the bandwidth or computational power, required to run the blockchain. A proper scaling strategy must address all three bottlenecks.

Speaking of sharding…

Sharding

Ethereum’s long-term vision for on-chain scaling is sharding, a way of partitioning both the storage of data and the processing of transactions. The goal is for most nodes on the network to have to process transactions from only a single shard, freeing them from the burden of validating and storing transactions that affect only other shards.

I won’t even attempt to survey the Ethereum team’s proposals here, as this article is already getting long, but if you’re interested in this topic I strongly recommend their fantastic sharding FAQ on GitHub.

The reason I bring up sharding, though, is that Ardor’s developers have suggested that they are exploring ways to push child-chain transaction processing to dedicated subnets of the Ardor network. They have not offered technical details yet, and I’ll refrain from speculating here about how it might work, but to me, the idea certainly seems plausible.

If the devs can deliver on this idea, then the Ardor platform will look a lot like the “basic design of a sharded blockchain” described in the Ethereum team’s document. That section of the paper describes a set of “collator” (bundler) nodes charged with collecting (bundling) transactions from a single shard (child chain), validating them, and recording their hash in a “collation header” (ChildChainBlock transaction) on the main (parent) blockchain. “Super-full nodes” (current parent-chain nodes) would process all transactions from all shards; “top-level nodes” (future parent-chain nodes) would process only the main chain blocks, but not the full contents of all collations; and “single-shard nodes” (future child-chain nodes) would process all transactions on the main chain and a single shard.

Almost all of the complications arise from cross-shard communication, and as a result, this design works best when the shards are largely independent. As I mentioned above, Ardor’s child chains might naturally accomplish this kind of partitioning, with each chain supporting a separate project, where interactions between projects are allowed but still less common than transactions within a project.

Conclusion

At this early stage, these ideas are quite tentative, of course. But the possibilities are exciting nonetheless. Ardor’s design already incorporates proof-of-stake consensus, a separate goal that the Ethereum team has set for itself, and a reasonable partitioning of the blockchain’s data, which is an obvious requirement for any sharded solution. Notably absent in Ardor are Merkle proofs, or some other compact way for partitions to trustlessly communicate state information to one another, but it does seem like these features could be built into the platform via a hard fork. The snapshot hashes and child-chain block hashes that would become Merkle roots are already present in the protocol, after all.

But what can we say about the current state of the two projects? Perhaps the most interesting fact I learned in researching and writing this article is that Ethereum actually scales far better than I had originally thought. Go Ethereum’s fast-sync option for full nodes affords some of the same advantages of Ardor’s design, and if it eventually incorporates state-tree pruning the analogy will be even closer.

On the other hand, the main drawback of Ethereum’s current design is that there must still be full nodes somewhere on the network, and those nodes must store all 300+ GB of the Ethereum blockchain. As it continues to grow, and the cost of running a full node grows along with it, one would expect the proportion of full nodes relative to fast-sync and light nodes to naturally decline. As a consequence, each full node will likely end up handling an increasing volume of requests from other nodes, further increasing the cost (in terms of bandwidth and computational power) of running a full node.

Even without sharding, Ardor’s design mitigates this potential problem by breaking Ethereum’s monolithic full nodes into sets of archival nodes that each store the current state of only one child chain. It will be possible to store the histories of several child chains simultaneously, if desired, but few nodes, or potentially none at all, will be required to store the full history of the entire system.

Needless to say, scaling a blockchain is a hard problem. Out of the several projects that I have surveyed for this series, Ardor and Ethereum seem to me to offer the most compelling visions for on-chain scaling. And while I am hopeful that both will succeed, I must admit that, judging solely from the concrete progress that each project has already made towards achieving its vision, Ardor seems to me to have an ever-so-slight head start.


Try Ardor on testnet

About the latest Ardor testnet version

 

 

Ardor vs. the Competition, Pt. 6: Komodo/SuperNET

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

This week I studied Komodo, the blockchain platform that forms the basis of SuperNET.

SuperNET

Like Waves, SuperNET was founded by someone who was quite active in the Nxt community in the past. And as with my article about Waves, I won’t attempt to rehash that history here.

Suffice it to say that James/jl777 was the developer behind SuperNET, the Multigateway, and several other projects on Nxt, including a number of assets on the Nxt Asset Exchange, but he left the Nxt community during the turbulent period of late 2015 and early 2016. Since then, he has created the Komodo platform, which now serves as the foundation of SuperNET.

The vision of SuperNET is to enable users to seamlessly transact with many different cryptocurrencies in order to enjoy the unique advantages of each coin. The experience is to be so seamless, in fact, that the user might not even realize that he or she is using multiple coins. For example, if I understand correctly, a SuperNET application might allow users to transact privately with Bitcoin by converting to and from a privacy coin like Komodo behind the scenes. From a user’s perspective, it would be as if Bitcoin had “borrowed” Komodo’s privacy feature.

SuperNET isn’t itself a blockchain. Rather, it is a framework comprising several parts. The main ones are:

  1. Komodo, a blockchain anchored to Bitcoin;
  2. assetchains and geckochains, independent blockchains anchored to Komodo;
  3. the Agama wallet, a multicoin wallet;
  4. BarterDEX, a decentralized exchange (DEX) that will be integrated into the Agama wallet; and,
  5. Iguana, the codebase that underlies the Agama wallet and part of Komodo.

Note that much of the literature about SuperNET refers to the Agama wallet as the “Iguana wallet,” which was its previous name.

The “anchoring” process in items 1 and 2 is Komodo’s delayed proof-of-work consensus algorithm, which I describe next. I’ll return to BarterDEX later.

Delayed Proof of Work

Komodo is a fork of zCash, which is a blockchain that uses zero-knowledge proofs (via zk-SNARKs) to allow users to transact without publicly revealing their account numbers or the amounts that they exchange. Komodo has added several features to its branch of the zCash codebase, including the delayed proof-of-work (dPoW) consensus algorithm and a mechanism for creating additional blockchains that are periodically anchored to the Komodo chain.

The dPoW white paper argues that the dPoW mechanism allows any blockchain to secure itself using Bitcoin’s hashpower by periodically notarizing itself to Bitcoin. In a nutshell, consensus on the weaker blockchain occurs in two stages: an initial consensus by normal means (e.g., PoW or PoS), and a second layer of consensus established periodically by a set of notary nodes, elected by stakeholders, that record a hash of the weaker chain’s most recent block on the Bitcoin blockchain. All nodes on the network agree that, in the event of a fork, they will not reorganize the blockchain past the last time it was notarized on Bitcoin.

In this way, the author argues, the weaker blockchain inherits some of the security of Bitcoin. Even an attacker with a large majority of the network’s hashpower won’t be able to modify the blockchain back past the most recently notarized block. Accordingly, somebody who waits for a transaction on the weaker chain to be notarized on Bitcoin can be confident that it won’t be reversed.

The white paper also proposes a mechanism to allow the network to fall back to the initial consensus mechanism in the event that the notary nodes become unavailable. The idea is that all nodes on the network are eligible to mine, but the notary nodes are assigned a lower difficulty level than normal nodes. As a result, notary nodes will normally win most or all blocks, but if an attacker were to somehow take them offline–by a DDoS attack, for example–normal nodes would be able to continue mining blocks and the blockchain would continue uninterrupted, except without the added security of Bitcoin. In this way, the dPoW chain is somewhat less centralized than it appears at first blush.

This line of reasoning does beg the question of exactly what is gained by the notarization mechanism, though. In particular, if an attacker can gain control of the notary nodes, he can prevent them from signing the Bitcoin transactions that notarize the weaker chain’s blocks, forcing the weaker blockchain to rely only on its initial consensus. So it appears that the extra security provided by the notarization process depends implicitly on an honest majority of notary nodes.

[EDIT: After talking with jl777, I learned that Komodo allows a minority of notaries, 13 out of 64, to sign each notarizing transaction. This simultaneously reduces the Bitcoin fees that must be paid and makes the proposed attack harder, since an attacker would have to control a supermajority of notaries to defeat the notarization mechanism. My original statements were based off of what he wrote in the dPoW white paper, which suggests that 33 of the 64 notaries must sign the notarizing transactions.]

This is basically the security model of delegated proof-of-stake (DPOS) blockchains like BitShares. In both dPoW and DPOS, users vote by stake for a set of “special” accounts that the rest of the network depends upon for its security. Both systems suffer the same weaknesses, too: a burden on users to keep up with the “politics” of the system to know which accounts are trustworthy enough to vote for, and the corresponding voter apathy that this burden produces.

All things considered, I’m not sure I see a strong case for dPoW over and above other alternatives. If the weaker chain’s initial consensus mechanism is strong enough to secure it, given its current economic value, then paying Bitcoin fees to notarize it seems like a waste of money. If the initial consensus is not sufficient, on the other hand, then it seems that the security of the chain rests entirely on the election of honest notaries. But in that case, why not use DPOS and take advantage of the increased transaction throughput that DPOS chains have achieved?

Setting these considerations aside, though, it is worth noting that the Komodo platform uses nested dPoW chains to help achieve SuperNET’s vision of interconnecting a variety of different blockchains. Komodo’s additional chains are called “assetchains” and “geckochains”. These chains notarize themselves to Komodo, which in turn notarizes itself to Bitcoin. Again, the claim is that all chains involved inherit the level of security of Bitcoin, but as described above, a lot depends on each chain’s notary nodes.

Unlike assets on Nxt and Ardor, or even child chains on Ardor, Komodo’s assetchains are fully independent blockchains. Their only connection to the Komodo chain is the dPoW notarization mechanism. In this way, they are perhaps closer to the sidechains that Lisk and Stratis envision than they are to Ardor’s tightly-coupled child chains.

Geckochains are like assetchains but with support for smart contracts. I haven’t found many details about geckochains, and they don’t appear to be available yet, but the Komodo client does currently support assetchains via a command-line interface.

BarterDEX

SuperNET’s decentralized exchange, called BarterDEX, allows users to atomically trade coins across supported blockchains in a trustless way. The team has not yet integrated it into the Agama wallet’s user interface, but they’re working on it now, and in the meantime BarterDEX can be used on its own.

BarterDEX consists of three main components: a designated set of nodes for matching orders; a set of “liquidity provider” nodes to act as market makers; and a protocol for users to exchange coins from two different blockchains with each other as a single, atomic operation.

The order-matching nodes serve the same role as they do in Waves: they partially centralize the task of matching buy and sell orders in order to provide a more responsive user experience. This way, traders don’t have to wait for the next blocks on the blockchains in question to know whether their orders have been filled or to cancel an order.

Liquidity provider (LP) nodes maintain balances of at least two supported coins and automatically trade them at a user-defined profit margin relative to a centralized exchange. For example, it is possible to set up an LP node that trades BTC and KMD on BarterDEX and also on Bittrex. Operators of LP nodes assume the risk associated with holding funds on a centralized exchange, and in return they profit from arbitrage opportunities between the two markets. Other BarterDEX users, for their part, get more liquidity and tighter bid-ask spreads than they would see otherwise, without having to store their coins on centralized exchanges.

After a user’s order is matched, likely to an order submitted by an LP node, BarterDEX uses an atomic cross-chain swap protocol to settle the trade on the two blockchains involved. Presumably the details vary somewhat depending on the trading pair, but conceptually the process is similar in each case. One blockchain is assumed to be compatible with Bitcoin, or at least to support the equivalent of Bitcoin’s hashed timelocked contracts (HTLCs). The other blockchain must support 2-of-2 multisig transactions.

Suppose Bob is trading his funds on the Bitcoin-compatible chain for Alice’s coins on the other chain. Alice and Bob each create a public key/private key pair and exchange public keys and hashes of the private keys. Alice sends Bob a 2-of-2 multisig transaction that he can spend once he knows both private keys, and Bob sends Alice a hashed timelocked transaction that Alice can spend by revealing her private key. Once she does, Bob uses it to unlock her multisig transaction and the trade is complete.

The protocol adds a bit of complexity to protect each party in the case that the other exits the process early. If Alice walks away without spending the transaction that Bob sent, Bob can recover his funds after the timelock on that transaction expires by using his own private key. Conversely, in order to protect Alice from the same risk, the protocol requires Bob to submit an initial “deposit” in the form of a hashed timelocked transaction. If he walks away before paying Alice, she can wait for the timelock on this deposit to expire and claim it for herself.

This is admittedly only a high-level overview of the atomic swap protocol, but hopefully it gives you an idea of how it works. The most important part is that there is no centralized exchange to facilitate the trade: Alice and Bob have exchanged coins on different blockchains without having to trust each other or some intermediary. You can find more details in the BarterDEX white paper.

Compared to Ardor

What do we make of Komodo and SuperNET, then? This question largely hinges on whether Komodo’s delayed proof-of-work algorithm offers a substantial degree of additional security to Komodo and its assetchains. In my view, it does not: it offers roughly the same degree of security as the delegated proof-of-stake algorithm, even if the notary blockchain is assumed to be perfectly immutable.

In this light, Komodo’s assetchains look a lot like the user-deployable sidechains that Lisk and Stratis aim to offer. In all three projects, and in contrast to Ardor’s child chains, each assetchain or sidechain is responsible for its own security. Komodo seems to have a head start on both Lisk and Stratis in terms of functionality, though, as users can already deploy their own assetchains and conduct atomic swaps on some pairs.

Note that Ardor’s child chains store hashes of their blocks on the Ardor chain, rather like Komodo stores hashes of its blocks on Bitcoin, but there is a crucial difference: Ardor’s forging nodes validate all child chain transactions. Each child chain effectively inherits all of the forging power of the Ardor chain, rendering it just as secure as Ardor and obviating the need for separate miners or forgers.

With regard to cross-chain atomic swaps, Ardor and Komodo are perhaps a bit more comparable. Ardor natively supports transactions among child chains and also between each child chain and the parent chain. Moreover, it supports a phased transaction type that is equivalent to 2-of-2 multisig, enabling the same kinds of atomic swaps with Bitcoin-compatible blockchains that BarterDEX uses. Ardor even adds the ability to combine multiple phasing conditions with Boolean AND, OR, and NOT operators, potentially allowing users to create the equivalent of a hashed timelocked transaction. Using BarterDEX’s approach, this feature could enable atomic cross-chain swaps to any blockchain that supports 2-of-2 multisig.

Conclusion

SuperNET’s vision of independent but interconnected blockchains is quite compelling, and between the Komodo platform, the Agama wallet, and the BarterDEX exchange, SuperNET has made real progress towards realizing that vision. While I am skeptical that the delayed proof-of-work algorithm provides substantial additional security to Komodo and its assetchains, the ability to quickly deploy an assetchain at least puts Komodo ahead of Lisk and Stratis in the race to build a functioning sidechain platform. Also, I see a lot of value in the ability to easily conduct cross-chain atomic swaps using BarterDEX.

Even so, I have to wonder whether there exists at the heart of SuperNET a fundamental tension between two of its goals. On the one hand, it aims to integrate the best features of many disparate blockchains, providing users and developers a seamless way to enjoy the unique advantages that each chain offers. On the other hand, it has offered Komodo as a single platform to solve most problems, supporting as it does private transactions, user-provisioned sidechains, and, in the future, smart contracts. Success at either of these goals seems to undermine efforts to achieve the other.

Ardor, for its part, also has a compelling vision, and one that is perhaps a bit more coherent: to support a multitude of businesses and projects on its child chains, making available to each a set of prepackaged features, allowing each to interact with the others, and requiring none to provide for its own security or to store forever the histories of the others. Ardor already offers most of the technology required to realize this vision; what remains is for businesses, developers, and users to put that technology to good use.


Try Ardor on testnet

IGNIS ICO Report 4

And so, the hunt for JLRDA is about to resume.

Round 2 of the IGNIS ICO will kick off Aug 26 between 06:45 – 07:15 UTC

The price will be 0.55 NXT per JLRDA, with 80M JLRDA tokens for sale in this round.

Anyone who did their due diligence will know:

Ignis will be launched with all of the features of Nxt, plus more, and it will be created with no restrictions. When Ardor launches, hopefully, November 2017, each JLRDA token on the Nxt blockchain will be swapped for one IGNIS coin in the Ignis Genesis block. 

First child chain, so what? Well, take notice that Ignis will be unrestricted. Ardor child chain creators may choose to disable certain features or set overall rules that not everyone may agree with, as well as possibly control the supply or future distribution of coins used on their child chain. Permissioned child chains can impose restrictions on their users such as KYC/ AML, personal data protection, time-limited data retention, local securities trading laws for asset issuers, etc. But the Ignis child chain will be permissionless, available to the general public, with no restrictions on who can transact with it.

Nxt’s features are described here.
The differences between Nxt and Ardor is available here.

Ignis holders will have easy access to other child chains and benefit from services they provide. Assets, for example, are global, so assets issued using the Ignis child chain can be traded on all other child chains and vice versa. IGNIS can also be traded for any other child chain coin or even ARDR using the inbuilt, decentralized Coin Exchange.

NXT > IGNIS

You need NXT to buy JLRDA, and the NXT price has taken a good beating since Round 1.

The bright side is that the current NXT price makes 0.55 NXT per JLRDA a mighty favorable buy, also compared to the price in Round 1. Not investment advice, just saying, if you’re eager to own JLRDA, now is not a bad time to get in. Long term investors may see every round as a bargain, but do your own due diligence, read the white paper, try Nxt in production, try IGNIS and Ardor on the testnet, and draw your own conclusions. We mean it – you should ask for testnet coins here.

NXT can be bought on exchanges with fiat or BTC or with most cryptocurrencies directly in the NRS Client, using Changelly or Shapeshift.

80M JLRDA in Round 2

In Round 2, 80M JLRDA will be released, divided into 4 batches.
The 4 sell offers will be placed randomly within these 30-minute time frames:

Sat, Aug 26th between 06:45 – 07:15 UTC
Sun, Aug 27th between 18:45 – 19:15 UTC
Tue, Aug 29th between 06:45 – 07:15 UTC
Thu, Aug 31st between 18:45 – 19:15 UTC

To get a fair shot at getting in, ICO participants are recommended to place their orders using Jelurida’s official ICO sales page in the latest client release, NRS 1.11.8. Install, wait for the blockchain to download, place your order and keep the client running until the sale is over. Run the client in full mode.

As many buyers missed out on getting tokens in Round 1, we foresee another battle for tokens coming up. If you miss out on a batch, try the next one. Due to much higher demand than supply, the ICO is set up to run like a lottery to give equal chances for all.

Here’s how to attend:

https://youtu.be/NsRs0vpeNHE

The NXT to invest

When should you get in? Jelurida cashes out their NXT on Bittrex, and also the late BTC rally has been too tempting for some traders to stay in NXT. If you want to crystal ball the NXT market movements, at least be aware of this >

https://nxtportal.org/accounts/9419511406156481100

That is Jelurida’s ICO account. 3M NXT only, out of the first 24M (from Round 1), is left at the time of writing, the rest has been liquidated.

gabriel [8:35 AM]

Jelurida sells the NXT that was raised to fund the future development of Ardor/Ignis/Nxt, so while there is a strong demand for NXT, it is partly offset by the sell pressure from the ICO itself.

This is however great news for the future of all 3 platforms since they will have strong funding.

Jelurida sells the collected funds in batches on the market, to avoid a big dump, which so far seems to work according to the plan.

Plus, as summarised by Riker in nxtchat.slack:

riker [8:54 AM]

Jelurida now has more than enough resources for PR and marketing and we chose Blonde 2.0 and TLVC as our partners since they have a lot of experience in promoting the crypto/crowdsale business.

In addition we are now running full scale marketing campaigns on CMC, Google, Facebook and with anyone who is willing to cooperate and market us. If marketing and PR was indeed our problem for all these years, this problem has been solved.

Afraid of whales?

Sure, the first batches of Round were eaten by MAAC The Whale and rightfully so, due to his study of the Nxt blockchain and tests done beforehand. That said – you should stop worrying.

In case it went over your head, Jelurida solved the problem within 24 hours and released a version of the NRS Client, which not only hacked the hacker but also allowed ICO participants to place their JLRDA orders in advance of the scheduled sales windows.

Use that to buy in, and you’re good. But still, be aware not to place your order more than 24 hrs ahead of time;

When running as a full node, the Nxt software allows you to schedule the JLRDA currency buy transaction in advance, before the JLRDA tokens are offered for sale.

Since transactions by default expire in 24 h, such scheduled transactions must be submitted not earlier than 24 h before the expected time of the offer. Scheduled transactions are kept in memory, therefore restarting the node will also clear them and will require you to re-schedule them again.

Good luck. We will keep you informed.

Want to share your IGNIS ICO experience with us? Leave or comment or email us! Stay tuned and happy hunting!

Ardor GUI screenshots

Damelon, of the Jelurida, has shared some previews with us regarding the Ardor platform.

This time a screenshot of the Coin Exchange, which allows users to exchange tokens in one child chain against tokens in another child chain, or against Ardor.

Here it is:

A preview of the dialog windows for bundlers has also been shared.

“Bundlers” will bundle child chain transactions and send them to the Ardor main chain where they will be “forged”. This operation costs ARDR. You can read more about how bundling will work in this newsletter.

Source: https://nxtforum.org/general-discussion/(ardor)-coin-exchange-and-bundlers’-screenies/