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

View this in: 简体中文 Español

5 thoughts on “Ardor vs. the Competition, Closing Remarks

  1. What is procedure of forging Ardor.. Can you please share the steps so that we will be ready to forge ardor at time of launch

    • The minimum requirements for forging are: 1) an account with at least 1000 ARDR (though this number might change in the mainnet release); 2) a full node; and, 3) a constant internet connection.

      If you want to avoid (2) or (3), you can lease your balance to a forging pool. You can find more information about leasing here:

      Alternatively, if you don’t mind doing a bit more work, you can set up a virtual private server (VPS) using a public cloud. Google Cloud offers a $300 credit that you can use for up to a year, for example. You might also try AWS and Azure. All three platforms have free tiers, which I suspect will be able to handle running an Ardor node. You can find instructions for setting up your VPS here:

      (Note that these instructions are for the Nxt client, but the process will be basically the same for Ardor.)

      Regardless of whether you run your node on your home computer or a VPS, you might consider creating a second account just to forge, and leasing your balance to that account. The reason is that a forging node must be constantly connected to the internet and must also store your secret passphrase in memory. If a hacker were to somehow get access to that machine and steal your secret passpharase, he or she could steal your coins. By setting up a separate account for forging and leasing your balance to it, the worst a hacker could do would be to steal the coins you’ve earned by forging. Your balance would be safely under control of the lessor account, whose secret passphrase would not be stored on the forging node.

      I hope that helps! I should add that you probably won’t make much money forging, at least not until the network gets busier. The real incentive to forge is to secure the blockchain. It’s easy to shrug that off, leaving forging to other accounts, but it’s really important not to let too few accounts control the forging process!

    • Thanks for the suggestion! Cardano wasn’t really on my radar while I was writing this series, but it has caught my attention lately. I still don’t know much about it, but my first impression is that it is an ambitious project that is only in its very early stages of development.

      I’d definitely like to learn more about Cardano, and it’s on my short list of blockchains to research. I have my hands full with a couple of other projects at the moment, though, so it might be a little while before I can dig into it. When I do, I’ll be sure to write up a summary of what I learn.

  2. This is a great read, I’ve learnt more not only about Ardor but also about other blockchains as well, and the great thing is that it’s very unopinionated. Keep up the good work! Also, I would love to see the comparisons to NEO and Cardano in the next articles.

Leave a Comment