NXTER.ORG

Ardor vs. the Competition, Closing Remarks

This is the final installment of a series of articles that compares Ardor to other blockchain projects with similar features or goals. You can find the rest of the series here:

Or you can download the complete series as a free ebook here: Ardor vs The Competition

This series started with a brief, informal reddit post with my initial reactions to the Plasma paper. I didn’t know at the time that it would launch me on a tour of half a dozen other cryptocurrency projects, ranging from sidechain platforms (Lisk, Stratis, arguably Komodo) to colored-coins platforms with unique features (NEM, Waves), to a project that eschews the blockchain altogether in favor of a completely different data structure (IOTA). Now that we have come full-circle, with the last two articles focusing once again on Ethereum, I think we have reached a good place to conclude.

This series has covered a lot of ground, and I won’t attempt to summarize everything here. Instead, I would like to share my thoughts on an overarching theme that emerged from my research on these projects.

Scaling Securely

As I’ve mentioned before, my primary interest throughout this series has been to survey various approaches to the difficult problem of scaling a blockchain. What I’ve learned is that there are many different strategies, but most involve a trade-off with security. I am certainly not the first one to make this observation, but I think it bears repeating here in the context of this series.

At one end of the spectrum, the most secure way to launch a new blockchain project is probably to issue a token on an existing blockchain that has already secured itself. This is the colored-coins approach that Nxt, NEM, Waves, and Ethereum use, for example. Transactions involving these tokens are recorded directly on the underlying blockchain and are therefore just as secure as any other transactions on it.

The obvious drawback of this approach is that it doesn’t scale particularly well: every node on the network must process all transactions involving all tokens on the blockchain, even if the projects that those tokens represent have nothing to do with one another. Moreover, all of this transaction data is stored forever on the same blockchain, bloating it at a rate proportional to the combined transaction volume of all of the projects running on it.

So-called “vertical” scaling methods, which aim to allow each node to do the same amount of work faster, or store the same amount of data more efficiently, are the natural way to scale this strategy. NEM’s Catapult project is a good example, as it focuses on optimizing the full client’s code and the communication protocol used on the network. Waves NG, an optimization of the forging protocol, is another example.

This approach to scaling ultimately runs into limits, though. At some point, adding enough users and transactions will break these designs, and the only viable option is some form of “horizontal” scaling, where each node on the network processes and stores only a subset of all transactions.

One reasonable way to scale a blockchain platform horizontally is to push each project onto its own independent blockchain, which is the approach that sidechain platforms like Lisk and Stratis are taking. This approach occupies the other end of the security-scalability spectrum: it naturally partitions both the total computational work and storage required to run the platform and allows different nodes to handle each partition, but this scaling comes at the cost of decreased security. Specifically, with N projects running on a sidechain platform, the weakest sidechain is secured by at most 1/N of the total miners or forgers, and likely far fewer than that, especially in its infancy.

Ardor partially transcends the security-scalability spectrum, successfully partitioning the storage of child chain data without sacrificing security. The price of this benefit is that the entire network must still process each transaction. It will be interesting to see the details of Jelurida’s plan to push child chain transaction processing onto dedicated subnets of the network, which would provide the missing computational and bandwidth scaling, but until then, we must refrain from speculating.

IOTA is a bit of a special case, as its design is fundamentally different from a blockchain in a couple of important ways. Without rehashing the whole mechanism of “eventual consensus” on the tangle, allow me to say that IOTA’s tangle (as it is implemented today) seems to me to be primarily a form of vertical scaling, with an element of horizontal scaling. Each node sees and stores every transaction, and although nodes can continuously prune the tangle over time, reducing the storage requirement, “permanodes” on the network must still store the entire history of the tangle in order to bootstrap new nodes trustlessly. On the other hand, nodes do not necessarily need to validate each transaction, as they can accept transactions that are sufficiently deep in the tangle as having been confirmed by other nodes on the network as long as they are referenced by all tips.

In other words, IOTA partitions the computational work required to validate transactions, but not the bandwidth required to relay them or the data that must be stored.

Eventually, IOTA plans to introduce “swarm” nodes to divide up the work of transaction validation and tangle storage. This will be a form of full horizontal partitioning, but I have not yet been able to find technical details, so in my opinion, it belongs in the same category as Ethereum’s Plasma and sharding proposals: a plausible-sounding idea that needs further development before it can be accepted as a real solution.

On that note, I’d like to make one final point about Ardor’s approach towards scaling: while it is not a panacea, at least at this early stage, it is important not to understate the value of an architecture that exists and actually works. Perhaps it goes without saying, but Ardor’s developers are not just hypothesizing about theoretical solutions to a difficult problem. They have proven that they can devise an ambitious but realistic design, implement it in a reasonable time frame, and in doing so make substantial, concrete progress towards a truly scalable blockchain. Not every team can make those claims, no matter how promising their initial ideas sound.

Final Thoughts

There is plenty more to be said about all of these projects, but this will have to suffice for now. I hope you’ve enjoyed reading these articles even half as much as I’ve enjoyed writing them. On a personal note, I would like to thank you for reading this far, and for sharing these articles with other blockchain enthusiasts. It has been immensely rewarding to see people offer their support, comments, critiques, and all manner of other reactions. I am humbled and deeply grateful that you took the time to engage with my work.

If I may leave you with a parting thought, it is this: after all is said and done, I see tremendous potential in several of these projects, but I am especially excited about Ardor. Its parent-chain/child-chain architecture simultaneously addresses two very important problems: how to cope with bloat, and how to offer a blockchain as a service to clients who do not have the resources or expertise to start their own blockchains. It is anybody’s guess what economic value markets will ultimately assign to Ardor’s solutions to these problems, but in my humble opinion, Ardor compares quite favorably to the competition on both points. I can’t wait to see what the future holds.


Try Ardor on testnet

About the latest Ardor testnet version

Ardor vs. the Competition, Pt. 4: Waves

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:

Until now, one of my main goals with this series has been to survey different approaches to scaling a distributed ledger. This week and for the next couple of posts, though, I’m shifting my focus slightly towards the business side of blockchain technology. I’ll attempt to explore the real-world problems that blockchains can solve and the ways that different projects have positioned themselves to suit their target markets.

These subjects are a bit outside my comfort zone, so I’ll thank you in advance for your patience with me in case I say something ignorant or naive. And as always, I greatly appreciate constructive criticism. 🙂

This disclaimer is especially important this week, because this week I studied Waves. As a newcomer to Nxt, I’ve read just enough about its history to know that the founder of Waves, Sasha Ivanov (a.k.a. Coinomat on nxtforum.org), had been an active member of the Nxt community until the turbulent period of early 2016, at which time he left to found Waves. I won’t attempt to rehash the debate over Ardor and the future of Nxt, which I understand ended with many asset issuers like Sasha leaving the community, but if you’re interested I’d highly recommend apenzl’s summary in SNAPSHOT and the references therein.

Instead, for this post I’ll mostly ignore the histories of Nxt and Waves, and will approach both projects with an open mind and a view towards the future. I do think there would probably be some value in a proper historical analysis, but I simply am not qualified to offer one.

With that out of the way, let’s talk about Waves.

Waves

At first glance, Waves looks a lot like a stripped-down version of Nxt. It is primarily a decentralized exchange (DEX), inspired by and conceptually similar to the Nxt Asset Exchange. Like Nxt, it uses a proof-of-stake consensus algorithm and allows users to lease their balances to other accounts in order to forge in pools. It recently added a way to associate a human-readable alias to an account number, partially replicating the functionality of Nxt’s Alias System. Even a couple features still in development–namely, a voting system and a way to send encrypted messages–duplicate functionality that Nxt already offers.

At the same time, Waves is missing many of Nxt’s most powerful features. For now, it doesn’t support anything similar to Nxt’s phased transactions or account control options, for example, though it is worth noting that both smart contracts and multisig transactions are on the agenda.

Additionally, the white paper suggests that crowdfunding will be one of the main uses of the Waves platform, but tokens on Waves lack the customizable properties that make Nxt’s Monetary System currencies so useful for this application. For example, the Monetary System offers the ability to condition the transfer of funds on meeting a fundraising goal, a la Kickstarter, and also the option to restrict trading so as to prevent scalpers from creating a secondary market. Using this latter feature, called a “Controllable” currency in Nxt’s terminology, it is even possible for issuers to dictate both a fixed asking price and a fixed bid for the currency, enabling them to offer buyers full or partial refunds for their tokens. Crowdfunding on Waves, in contrast, is limited to issuing a token essentially at the market rate.

These observations notwithstanding, in my opinion it would be a terrible mistake to dismiss Waves as just another Nxt copycat with fewer features. For one thing, Waves offers several key features that Nxt and other platforms do not have, which I’ll describe next. Perhaps even more importantly, though, the Waves team has built a strong brand and has offered a clear and consistent vision since the platform’s inception. The field is currently so crowded, and innovation so rapid, that the combination of a simple, clear message, a strong marketing effort, and a demonstrated ability to deliver on those promises might be even more important to the long-term success of a project than the richness or novelty of its underlying technology.

Unique Features

One interesting feature that distinguishes Waves from many other platforms is the design of its DEX. It is a hybrid approach that combines a centralized order-matching engine, called the Matcher, with decentralized settlement on the Waves blockchain.

When users place orders on Waves, the Waves client sends those orders to central Matcher nodes, which maintain the order books for all tradeable pairs. Each new order is either matched against existing orders or added to the order book for the pair in question, but either way the user who submitted the new order is notified immediately whether the order was filled. It is still necessary to wait for the next block(s) to be added to the blockchain to fully confirm the transaction, but in the meantime, the user knows with high confidence the result of the order.

This might not seem like a big improvement over a fully decentralized exchange, but from the handful of transactions I made on Waves, I must say I was quite impressed by the user experience. The ability to see real-time updates to the order book, and to know immediately whether my orders were filled, made a bigger difference than I had expected.

In principle, any full node can become a Matcher. The lite client currently only connects to Matchers at nodes.wavesnodes.com by default, though, so Matchers on the rest of the network probably do not see much volume. With new orders transmitted directly to these centralized nodes, and only broadcast to the whole network once they have been filled (I think), this design allows the order books to remain anonymous. I don’t know for sure how important it is for open orders to be anonymous, but it certainly seems like a feature that traders might value highly.

Another distinguishing feature of Waves is the ability to trade any token against any other token without first converting to WAVES. Combined with the integrated gateways that issue tokens pegged to U.S. dollars, euros, and several cryptocurrencies, this feature enables Waves to function as a decentralized foreign exchange market. It also allows token issuers to conduct an initial offering directly in fiat-pegged tokens. With the full client, it is even possible to pay fees in tokens instead of WAVES.

Additionally, it is worth noting that there are several features in development or on the roadmap that also distinguish Waves from other platforms. One is a reputation system that will score accounts by their age, transaction history, and other factors. There are not many details yet, but the goal is to provide users with at least a rough indication of how trustworthy a given token issuer is. The white paper even goes so far as to suggest that the reputation system will serve as “some form of decentralized KYC/AML” (know your customer/anti-money laundering) system. While it’s difficult to see how a decentralized reputation system could help issuers actually comply with KYC and AML laws, it’s not unreasonable to suppose that it could serve some analogous purpose in a blockchain community.

Speaking of compliance issues, Waves has also announced a new project, Tokenomica, that will provide a “100% compliant legal framework for different types of token crowdsales, including private equity crowdsales.” Unfortunately, that quote from the 2017 roadmap is just about the full extent of information I’ve been able to find about Tokenomica. My impression is that the project is still in its early stages, but it shows that the team is taking regulatory compliance seriously.

For completeness, I should probably mention that the Waves team is also planning to incorporate smart contracts into Waves. The scripting language will not be Turing complete, and there will be no equivalent to Ethereum’s concept of “gas,” presumably because there will be no loops. Beyond these details, there isn’t much other information available yet.

Finally, I must mention the approach that the Waves team has outlined for scaling. It consists primarily of two parts: a redesign of the forging process that breaks large blocks into “microblocks” to optimize bandwidth usage; and an optimization to how account balances are stored–or rather, not stored–that reduces memory requirements for full nodes.

The first of these two proposals, called Waves NG, is based on Bitcoin NG. In a nutshell, once a node has won the right to forge the next block, it immediately issues a key block, which is usually empty, and then broadcasts microblocks containing transactions every few seconds. The motivation for this design is that broadcasting one large block each block interval is a much less efficient way to use the network’s bandwidth, and the corresponding spikes in network activity place an artificially low bound on the number of transactions that the network can handle. By spreading transactions out over a sequence of microblocks, it is possible to increase the average data rate over the network but decrease the peak data rate, lessening the constraints that bandwidth and latency impose on the maximum transaction rate.

The second component of the scaling plan is to implement the ideas described in this paper by Leonid Reyzin, Dmitry Meshkov, Alexander Chepurnoy, and Sasha Ivanov. I admit I haven’t spent very much time with it, but the gist is that full nodes will not all be required to store every account’s balance of every token in memory in order to validate transactions. Instead, they will store a compact digest of this information, and forgers that do store it in full–or some subset of it, if they choose to only forge transactions involving specific tokens–will generate cryptographic proofs that they have updated the account balances correctly. The forgers will then include the proofs and an updated digest in the header of each new block. Nodes that have chosen not to record the balances of all tokens involved in those transactions will still be able to validate them by using their current digest and the forger’s proofs to compute an updated digest, which they can compare to the one the forger reported.

The authors argue that this approach can reduce the amount of memory required for a full node under realistic conditions by about a factor of four. Moreover, if this optimization is able to keep all required information in memory in cases where it would otherwise have to be stored on disk, the performance improvement could be far greater–about a factor of 20, the authors suggest.

Comparison with Ardor

Although a couple of the features described were not present in Nxt, there will be similar features available in Ardor.

Specifically, Ardor’s parent-chain/child-chain architecture will allow users to trade all pairs of child chain coins, some of which could be pegged to fiat currencies and other cryptocurrencies. It will also be possible to price assets in any of the child chain coins, and to pay fees in the child chain coin when transacting on a given child chain. It will not be possible to trade assets against each other directly, but most of those trading pairs would probably have such low volume that it wouldn’t really be worthwhile to add this feature anyway.

As for the improvements that the Waves team has made to their DEX by partially centralizing it, it should be possible to mimic this functionality pretty closely by building a centralized order matcher on top of Nxt/Ardor. Indeed, the InstantDEX project accomplished something similar in the past, using Nxt to settle transactions in a decentralized manner.

On the subject of scaling, the proposal to reduce in-memory storage requirements for full nodes is intriguing, but I wonder whether there might be a small trade-off with security. (If you’ve read the previous articles in this series, then you have probably figured out by now that I always suspect that performance improvements entail reductions in security.) In particular, if nodes are not required to store the current state of every account, and must use the proofs and digest in each new block’s header to validate the transactions contained in it, then I assume that means that nodes will not be required, nor even will they be able, to validate unconfirmed transactions before broadcasting them to their peers. I don’t know the consequences of allowing nodes to propagate potentially invalid transactions across the network, but the thought makes me a bit uneasy.

Ardor’s approach to scaling is for all nodes to validate all transactions, but for only the minimum possible amount of information to be permanently recorded on the Ardor blockchain. In particular, only those transactions that change the balances of ARDR, the forging token, need to be stored on the blockchain in order for other nodes to trustlessly verify that each block was forged by an account that was eligible to do so. In contrast, the whole history of transactions involving only child chain coins and the assets and currencies traded on those child chains does not need to be stored on the blockchain, and hence can be pruned away, leaving only cryptographic hashes of that information behind. The result is that the blockchain stays much smaller and grows more slowly than would be the case if it stored all of this extra information.

Which approach is better depends on whether permanent storage of the blockchain or in-memory storage of current account balances presents a bigger problem as the two platforms grow. I don’t know the answer to this question, but there are a couple of related points that are probably worth making. One is that the timescales of the two problems could be quite different: I could see an explosion of new assets on the Ardor platform placing an immediate strain on memory, whereas blockchain bloat would likely pose a severe long-term problem for Waves, especially if it reaches hundreds or thousands of transactions per second, which is the current goal. My other thought is that Ardor required an entirely new architecture to implement its scaling solution, whereas Waves’s approach will not. It would no doubt be easier for Ardor to incorporate Waves’s solution at some point in the future than for Waves to implement Ardor’s solution.

Finally, perhaps the most interesting subject in this comparison is the issue of regulatory compliance. Waves has positioned itself as a platform for creating and issuing tokens, with a special focus on crowdfunding. To that end, the Waves team has indicated that they are taking a serious look at the regulatory complications that go along with crowdfunding–which might involve selling securities, for example–in order to help users comply with the law. While the suggestion that a decentralized reputation system might eventually replace traditional KYC/AML requirements strains credulity, it could at least help suppress scams and reduce the opportunities for bad actors to take advantage of others. In that sense, it might accomplish some of the same goals that regulators aim to achieve.

Ardor, for its part, will offer a couple of enhancements over Nxt that will be quite valuable for regulatory compliance. One is the ability to issue assets that can only be traded with a certain type of phased transaction, and the other is the addition of a new phased transaction type, which allows an account to approve a transaction only if the account has a certain specific property. Combining these two features, a user can issue an asset which can only be purchased by accounts that have a property that, for example, a KYC/AML-compliant identity provider has added to designate that it has verified the owner’s identity.

If your asset represents shares of a company, or a mutual fund, or some other type of security, this feature would enable you to prove to regulators that you know who is purchasing your tokens. Moreover, if you are a user interested in purchasing those types of tokens, recording a proof of your identity on the blockchain via your account’s properties will hopefully allow you to spend less time trying to convince businesses that you are who you say you are and that you aren’t laundering money.

In addition, it will be possible to create child chains that support only a subset of the features that the Ardor platform offers. This will allow child chain creators to disable certain features, such as coin shuffling, that might raise red flags with regulators in some jurisdictions.

Conclusion

What, then, do we make of Waves? There is definitely something to be said for choosing one problem and trying to solve it better than anybody else can do. Abandoning Nxt’s “Swiss Army knife” approach and focusing instead on the single goal of building a great token-trading platform no doubt made it easier to pitch, develop, and market Waves. There is also a lot to be said for starting off well-funded, as Waves did with a $16M ICO.

At the same time, though, I’m not sure that an objective comparison of Waves and Ardor could conclude that Waves is as technologically mature as Ardor is. (For the record, I have tried to do a fair and objective comparison in this article, but I am not claiming that I succeeded. That’s ultimately your call.) Nxt is already capable of almost all of what Waves can do, not to mention all of the things that Waves cannot do, and Ardor is adding new functionality, too.

Perhaps Ardor’s biggest remaining challenge is to truly sell its vision the way that the Bitcoin community and the Ethereum Foundation have sold their visions, and this is where Waves has a sizable head start. Being capable of so many different things, but not purpose-built for anything in particular, Ardor faces a very difficult task here. The worst possible outcome would be for users and businesses to see it as “just another platform,” or perhaps to fail to grasp the full range of what it can do, and to simply ignore it as a result.

As for Waves, I’m excited to see what the future holds. The improvements that it has made to the Nxt Asset Exchange, though modest in my opinion, have nonetheless distinguished it as a formidable DEX. If the Waves team can follow through on their roadmap, Waves will be a fierce competitor among exchanges–centralized and decentralized alike.