Summer Quest

Summer Quest is part of the Nxter Puzzles series, created by madfox, sponsored by the ANG.

Welcome.

The Summer Quest will take you on an adventure as you walk across parts of the world to find very specific numbers and words. The words of each stage of the quest will give you access to an Ignis account with an encrypted message. Find all the words and reap the final reward: 1000 IGNIS.

madfox wrote:

Prepare yourself for travels!

Use Google Maps to explore some of the cities that are important to members of the Ardor/Nxt project, as we invite you on a unique tour; walk the streets and uncover hidden words on this hunt for 1000 IGNIS. You must solve all parts of all stages of the quest to win.

In the Nxter Newsly (July V), Stage I + Stage II are presented. Their 12 words in total will together form a passphrase that gives you access to a Nxt/Ardor blockchain account. The passphrase unlocks an encrypted message in this account to let you know that your solution is correct. Check the message, keep a backup of the passphrase and wait for the next stage.

New stages (and bonus puzzles) will be announced every week in the Nxter Newsletter.

After Stage 5 one word remains to complete the passphrase. It will unlock the Prize Account with 1000 Ignis, sponsored by the awesome ANG! The final word will be announced during the Hackathon / Gamejam, August 24-26th in Austria, so stay tuned.

Unannounced bonuses in the form of Nxt or Ardor based coins and tokens might be sent to the Summer Quest accounts along the way. Nxters with the Summer Quest account passphrases at hand can transfer them to their own accounts. First come first served.

Good luck as you unravel your wanderlust.

STAGE 1 /July V

The first area to search is Hadera, Israel, where Lior Yaffe (co-founder, managing director @Jelurida) lives.

Search this area (using Google maps) to uncover the hidden words in the picture below.

 

Click the image to enlarge it

STAGE 2 /July V

The second area is Lancaster, PA, home of Elizabeth Mong, Director of the Ardor and Nxt Group (ANG).

Wikipedia:

In 2009, the LCSC’s expansion from a 70 to a 165-camera network attracted national attention, including a front-page article in the Los Angeles Times: “Lancaster, Pa., keeps a close eye on itself”. The article quoted city police chief Keith Sadler as saying, “Years ago, there’s no way we could do this... It brings to mind Big Brother, George Orwell and 1984. It’s just funny how Americans have softened on these issues.”

This is especially funny if you know the history of Nxt > Ardor. Short version.

Walk through and search this area (using Google maps) to uncover the hidden words in the picture below.

 

Click the image to enlarge it

STAGE 3 /August I

The third area is Lugano, home of Jelurida's main office.

Search this area (using Google maps) to uncover the hidden words in the picture below.

When you have unlocked the Stage III account, there's a bonus puzzle for you to solve HERE.

 

Click the image to enlarge it

STAGE 4 /August II

The fourth area in our Summer Quest is Rotterdam, The Netherlands, where Dominium, one of the new upcoming Ardor child chains, is located.

Search this area (using Google maps) to uncover the hidden words in the picture below.

Click the image to enlarge it

BONUS: DOM Puzzle

When you have unlocked the Stage IV account, there's a bonus puzzle for you to solve. Combine the words from the Stage IV and the August II bonus puzzle below, then wait for the final word to be announced on Dominium's official Twitter account to get access to the bonus account - you will find a redeemable singleton asset there, which represents 1000 DOM tokens.  Read more...

Countdown to the announcement of the SECRET WORD from Dominium

Day
Hour
Minute
Second

Take it away.

All letters are lowercase, divided by spaces - exactly like the passphrase for your Ardor account.
The formula of the final passphrase is: (Stage I + Stage II) + Stage III + Stage IV + Stage V + FINAL WORD.

TIP:
It's worth watching the Summer Quest accounts as bonus tokens are occasionally sent to them along the way.
Nxter Alerts will notify you by email of any in or outgoing transactions from any Nxt or Ardor/child chain account you subscribe to.

Dear Investors, It’s Time To Face The Real Facts

Many of the existing blockchain startups that are looking to raise money are not real businesses. Yes, they have ideas, often brilliant ones that almost sound too good to be true. And then… that’s it. Nothing but ideas put on paper with no clue on how to fully execute it to make the promised prototype. So, time goes by with no real tested product and the investor’s trust starts to diminish.

“Many of the existing blockchain startups that are looking to raise money are not real businesses.”

Several business consultants and companies are out there now. Each with the determination to stand out from the crowd in what they do. They specialize in helping startup companies / dreamers craft their whitepaper and business plans in order to attract investors. Next time you see a beautiful whitepaper think of this. Endeavour not to have so much conviction in its content but also Do Your Own Research. Don’t get me wrong, whitepapers are and should be the first step, but it should be a determinant for the first 10% of the investment decision only. The real determinant goes far beyond this.

“Business consultants and companies…. specialize in helping startup companies (dreamers) craft their whitepaper and business plans in order to attract investors.”

Choosing the right blockchain token to invest in takes more than just skimming a whitepaper, a great promise, and a fancy website.  What you need is in the real details from the team to the existing product and the future expectations for its adoption. See the whitepaper as what it is, a means of coercion and the fancy websites as a possible means of deceit.

Let’s recall that investment by definition is the act of putting money or effort into something (a business) to make a profit after a scheduled time. Determining the worthwhileness of the investment for your hard-earned money is of extreme importance. Making investment decisions requires time. Time is very precious and time is what you might not feel you have. Time to learn and know more about a new industry. This could very well be associated with why many investors tend to make costly mistakes. They do not take their time to learn or they don’t have the interest to know more about a new industry.

“…determining the worthwhileness of the investment…. requires time…. to learn and know more about a new industry.”

Let me tell you a few things that you need to know about the Blockchain industry. Call it the summary of all important points, or a thousand pages in few lines. Blockchain is a public ledger in which peer-to-peer transactions are stored securely using cryptography in a verifiable and permanent way creating endless chains of data blocks that can’t be tampered with. It is a way to structure data, decentralized and secured with Cryptocurrency as one of its outstanding by-products.

It’s not up for debate anymore that an investment in Blockchain and Cryptocurrency can be very worthwhile, but it needs to be done right. As an investor, aren’t you tired of false promises and failure to deliver and market hypes with no real achievements? Failures always eventually lead to a dump and this we all know. The sad and bitter end of the few minutes of fame. This can all be averted if only we take a few minutes or even hours, weeks, months to learn about what we invest our hard-earned income of years into, for years to come.

Now that we have got the basics out of the way, let’s talk about a few investment options. Most importantly, let’s talk about the blockchain platform that can be powered by the sun. Let’s dialogue about the blockchain platform with a built-in Decentralized Exchange. With fully developed features such as voting, encrypted messaging, p2p marketplace, basic cloud storage and more. Let’s dialogue about Ardor and Nxt blockchain technologies.

“Let’s talk about the blockchain platform that can be powered by the sun.”

A worthwhile blockchain investment will satisfy some conditions if it were to be successful. Ardor satisfies these conditions:

  1. It will not be costly for the environment
  2. It is a working product not just a promise.
  3. The team is proven professionals and experienced blockchain engineers
  4. The tech solves the Blockchain bloat problem-it can scale globally
  5. Ardor brings the true nature of decentralization into effect by giving everyone the chance to participate and earn interest for securing the blockchain network.

These conditions are already fully developed and functional on the Ardor and Nxt blockchain. Below are some bullet points that can really be useful in getting to know more about these real investments opportunities and what makes them so different from the rest:

  • The Nxt asset exchange can be and has been used as a crowdfunding platform to kick-start projects and businesses.
  • Nxt also offers a classic ICO platform. It automatically returns the funds to the investors, if the fundraiser’s monetary goal isn’t met.
  • Nxt provides an authentication system that allows Nxt accounts holders to prove they are in control of the account.
  • Nxt offers a “Plugins” feature enabling third party software developers to add functionality to the Nxt client.
  • Nxt offers a bank statement similar function called the ‘account ledger’ enabling users to see what in-and outgoing transactions have been made from their account.
  • Some of the other tested features of Nxt includes but are not limited to: an asset exchange, a monetary system that allows you to create coins, voting, Data cloud and account control.
  • Nxt also offers a blockchain creation kit that allows you to easily launch a clone of Nxt, 10% of the Nxt clone’s tokens must be distributed to Nxt holders according to the JPL.
  • Ardor can be as reliable as Nxt, as it has the same years of experience in team and technology using PoS consensus algorithm eliminating mining competition and high energy usage.
  • Ardor invented the concept of child chains,  where transactions are removed from the blockchain and stored in the cloud once they are confirmed, hence solving the blockchain bloat problem, a major blockchain issue.
  • Ardor is developed in Java, same as Nxt, the most popular development language for commercial production.
  • Ardor’s parent-child chain architecture allows companies to build their products and services using ready-to-use and interconnected child chains relying on the security provided by the parent chain. Ignis being the first permissionless child chain, with all the features of Nxt and the Ardor platform.
  • Ardor offers lightweight contracts that don’t require the whole network to confirm all transactions for each dApp, and Jelurida is working on child chain subnets, decentralized storage, researching DAG implementations, and more.

In this new era of ICOs and new exchanges coming up, you will notice fake volumes, deceitful hypes, and pump-focused marketing plans. Sometimes it’s like a battle of who can fake it best and run away with billions in funds. A once great idea remains a great one but too often it is used for a selfish purpose in a short-term profit con. The resulting major problem is that blockchain startups are now being judged by biased analytics, fake adoptions and the high expectations of traders looking to get to the moon from the deep bottom of the planet in seconds.

We, as investors, need to judge right and ask the factual questions. Once again, look beyond the fancy websites, and perfected whitepapers, fake volumes, paper ideas and cunning promises. If you must judge, which you should as an investor, take a look at the founders, the team as a whole, the existing technology, future plans and their probability of success. Take, for example, a closer look at Jelurida’s projects. Look deep into Nxt, Ardor, and Ignis and rest assured you will not have to look any further.

This is a call to all investors, prospective and existing. A call to follow the voice of guidance through the dark path of deceit and choose wisely. Below are what others have to say about the company and their blockchain projects:

“For a property project with potentially millions of users and assets worldwide, blockchain bloat and functionality are of a primary concern to us”, says Dominium’s Managing Director, Mark Lloyd.

“Having closely followed several blockchain technologies from conception, including Ethereum, we strongly feel that Ardor is the platform with the best features for our business, especially the controlled trading of assets”, says Joost de Kruiff, a Dominium Blockchain Advisor.

“Ardor is doing some pretty important work thinking about new ways to structure blockchain infrastructure and security. If done correctly, the end result could be a solution that any business could implement without needing extensive technical expertise or ongoing maintenance”, says Bennett Garner, Coin Central.

“Nxt is an amazing and ambitious project. I’m truly excited to see Ardor in operation”, says Coinist.

“Ardor operates on a Blockchain-as-a-Service (BaaS) model, supporting many use cases out of the box and makes it easy for anyone to get into the blockchain space, while also allowing developers to build their own solutions on top of it”, says TROND VIDAR BJORØY, Head of Product development and Implementation- ATPI Nordics.

“Ardor is also a platform well suited for running ICOs — anyone is able to create a new currency and issue an ICO in a few minutes, making it a more accessible alternative to Ethereum”, says TROND VIDAR BJORØY, Head of Product development and Implementation- ATPI Nordics.

“Ardor is a major blockchain-as-a-service (BaaS) platform that helps companies to share digital currency with ease”, says Bitcoin Exchange Guide.

“Jelurida is not just another blockchain service provider. It has developed a customizable blockchain infrastructure that is ready for customer use”, says Cryptovest.

“Ardor solves the blockchain bloat issue with its prunable child chain infrastructure, which side chains do not solve”, says Fintech.finance.

“Ardor is the “WordPress of blockchain”, it was designed with simplicity, as such, offers a stress-free interface to users without the need for coding”, says Yusuf Olayode; Oracletimes.com.

 

Further reading?

Whitepaper

https://oracletimes.com/ethereum-eth-and-ardor-ardr-are-in-a-lifetime-war/
https://www.fintech.finance/01-news/ardor-blockchain-platform-launches-public-testing-forum/
https://cryptovest.com/reviews/private-blockchains—the-good-the-bad-and-all-the-misconceptions/
https://www.coinist.io/what-are-nxt-and-ardor-blockchain-platforms/
https://coincentral.com/what-is-ardor-blockchain-as-a-service-explained/
https://bitcoinexchangeguide.com/ardor/
https://venturebeat.com/2017/09/21/ardor-could-fix-key-blockchain-weaknesses-if-it-can-get-its-message-out/


The views, opinions and positions expressed within blog posts on Nxter.org are those of the author alone and do not (necessarily) represent those of Nxter. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations.

Ardor API | Nxt API | Developer resources

A Review of Dominium

I suspect I wasn’t the only Nxter to be caught off guard by the articles from several weeks ago describing how a company called Dominium will build a platform on Ardor for investing in, listing, and managing real estate. Here was a project that was simultaneously extremely ambitious and quite close to launch, with the first features coming online by the end of 2018, and I had never even heard of it! So you can imagine my surprise when, a couple of days later, a member of the Dominium team reached out to me to see if I would be willing to write a review of the project for you.

After several emails, three phone calls, and a few days’ worth of research, I’m happy to share with you what I’ve learned about Dominium.

Before I begin, though, I need to make a couple of disclaimers. First, Dominium has not paid me to write this article, nor will they. I hope you will find it objective and unbiased. Second, I am absolutely not an expert in real estate investing or management, and while I have tried hard to learn about some of the problems that Dominium is attempting to address, I encourage you to do your own research and think critically about the information I’m presenting here.

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

Dominium will be:

  1. a platform that allows companies to create real estate funds, bonds, and loan notes, with these assets represented by tokens on Ardor, in a way that complies with government regulations;
  2. a marketplace for investors to buy and sell those tokens in a compliant way;
  3. a set of tools to help fund managers, including templates for regulatory documents, a support ticket system, and marketing materials;
  4. a marketplace for users to list, purchase, and rent properties; and,
  5. a public database that records historical data related to properties, such as changes of ownership, payments by tenants, maintenance records, and the like.

The Dominium platform will have its own child chain on Ardor to enable these services. Users will pay transaction fees to Dominium using the child chain’s native token, DOM, which should not be confused with the tokens representing the securities and properties for sale on the platform.

At the risk of slightly oversimplifying, I’ll divide Dominium’s features into two main categories: those related to creating, managing, and trading real estate funds, and those related to managing individual properties.

A Platform for Investing in Real Estate

Traditional private real estate funds suffer from a few drawbacks: they are illiquid, typically requiring that investors tie up large sums of capital for years; they are often accessible only to institutional investors and high net worth ($1M+) individuals; and, while government regulations usually require fund managers to make certain disclosures about their funds and the assets they hold, these funds are not always as transparent as they could be.

Publicly traded real estate investment trusts (REITs) and similar instruments address some of these problems but also have their own complications: listing a fund on a large stock exchange is expensive and usually entails complying with a slew of extra regulatory requirements, and smaller funds that cannot benefit from economies of scale often charge correspondingly higher fees.

Dominium aims to address these problems by moving the creation, financing, management, and trading of real estate funds to the Ardor blockchain. Companies will be able to issue assets in Ardor’s Asset Exchange representing shares of their funds, and will sell them directly to investors to raise capital for purchasing properties (equity funds) or for making loans for the purchase or development of properties (debt funds). As these activities earn revenue, fund managers will be able to pay dividends to investors using Ardor’s dividend payment feature.

This approach has several advantages. Investors will be able to enter for as little as the price of a single share and will be able to exit whenever they wish. Fund managers will have access to a wide cross section of investors, including ordinary retail investors, on a single platform and without having to deal with brokers. Meanwhile the blockchain will automatically handle the logistics of tracking who owns shares of a fund and what dividend payments they are owed. It will also provide a liquid marketplace for investors to trade shares of funds peer-to-peer without fund managers having to incur the costs of listing on centralized exchanges.

This picture looks a lot like the fulfillment, at long last, of the Asset Exchange’s immense potential. And yet, if this were all there was to creating and trading funds on Dominium, the project would have failed before it even hit the mainnet.

I say this because governments heavily regulate securities of all kinds, and real estate funds launched on Dominium will certainly be no exception. Regulatory compliance is a difficult subject for many blockchain-based projects, but Dominium, using features of the Ardor platform built specifically for this purpose (more on that below), has been designed to accommodate the demands of securities laws.

First and foremost, the Dominium child chain will be a permissioned chain, meaning that accounts will not be able to transact on it without first registering on the platform. This allows Dominium to collect sufficient personal information to comply with know-your-customer (KYC) and anti-money laundering (AML) laws. Any user who wishes to be able to trade shares of real estate funds, for example, must provide his or her name, email address, phone number, and date of birth, plus a picture of a government-issued photo ID, a picture of the user holding the ID, a proof of the user’s current address, and a proof of the user’s tax ID number. On Dominium they classify this as Clearance Level 2 (see below for more details about clearance levels).

The purpose of collecting this information is to firmly tie each user’s real-world identity to an account authorized to transact on the Dominium child chain (though, of course, this information will not be made publicly visible on the blockchain). Fund creators thereby know exactly who is purchasing their shares, and they can demonstrate to regulators that they have taken proper precautions to prevent money laundering and the financing of crime.

Importantly, compliance with KYC and AML regulations necessitates a degree of centralization. Not only must the identities of all participants be verifiable—a problem which is quite difficult to solve in a decentralized way—but it must be possible to forbid certain users from accessing the platform, and it must be possible to revoke other users’ access if they are later determined to be involved in criminal activity. Perhaps it will one day be possible to satisfy these criteria in a decentralized way, but for now, they require a central authority who verifies users’ identities and determines who is eligible to participate.

You might be wondering, then, why Dominium is interested in using a blockchain in the first place. Many blockchain enthusiasts, myself included, tend to take a hard line on decentralization, and compromising even a little bit on this criterion in order to achieve some other goal (e.g., scaling) immediately raises our suspicions that a centralized database might be a better tool for the job. More on this question below, but for now, suffice it to say that regulatory compliance is a real issue, that Dominium is taking it seriously, and that the result will necessarily include at least some elements of centralization. This is reality, and blockchain diehards will need to accept it or else renounce our ambitions to create new financial instruments.

One other aspect of Dominium’s approach to regulatory compliance that is worth mentioning is the company’s plans for creating standardized templates for certain legal documents. Specific requirements vary by jurisdiction, but generally fund creators must produce at least a prospectus, which often contains a rather small amount of important, fund-specific information interspersed with a generous helping of legal boilerplate. Dominium will hire a law firm in each jurisdiction where funds can be created to prepare standard templates for the prospectus and other legal documents that fund creators can use to comply with local securities laws. This is one of the primary ways that Dominium aims to streamline the fund creation process and to keep fees low.

A Platform for Managing Individual Properties

Quite apart from activities related to creating and trading real estate funds, the other focus of the Dominium platform is on listing, purchasing, renting, and managing individual properties. Owners, managers, tenants, maintenance workers, real estate agents, and other parties will be able to record information about properties on the blockchain, creating an immutable historical record that could be useful in a number of different contexts.

To make this idea more concrete, consider a few examples. Tenants and managers could record rent payments and receipt of those payments. A tenant might open a maintenance ticket with the manager (Dominium will include a support ticket system), who might hire a contractor to make a repair, and all parties might acknowledge that the work was done satisfactorily. The owner or manager might record receipts of tax and insurance payments. Prospective buyers might register their bids for a property that is listed for sale. And so on.

Want to see whether tenants pay rent on time before buying a rental property? Check the blockchain. Want to know whether the current owner actually paid for a new roof last year? Check the blockchain. Want to know whether there really are three other buyers who have entered bids on this property, and what those bids are, without having to take your realtor’s word for it? Check the blockchain. You get the idea.

In the near term, of course, government registries will still maintain the legally significant records of ownership of properties. To sell a property on Dominium would therefore require two separate interactions between buyer and seller: a transaction recording the sale on the blockchain and a traditional transfer of the title as recorded in a land registry. But looking ahead a few decades, it is exciting to speculate about whether governments might begin to acknowledge tokenized titles to real-world assets as authoritative records of ownership. And meanwhile, a great deal can still be recorded on a blockchain, including the information described above that can make real estate dealings more transparent.

Why Use a Blockchain?

But surely some of these benefits can be achieved with a fully centralized database as well. And as I mentioned earlier, the platform is already partially centralized in order to comply with KYC and AML laws. So why use a blockchain at all?

One way to answer this question is to consider what the platform would look like as a fully centralized service. Dominium would effectively be a broker for the real estate funds that companies create on the platform, and would have to establish its own exchange for investors to trade those funds. It would also have to take deposits from investors and secure those deposits without making withdrawals too inconvenient. And of course, it would have to accept the massive legal liability of operating these services and comply with a host of additional regulations placed on brokers and exchanges.

Needless to say, Dominium has no interest in being a brokerage or an exchange, and I’m sure they will be quite happy to avoid that kind of liability. Instead, peer-to-peer transactions in Ardor’s decentralized Asset Exchange will perhaps more closely resemble over-the-counter trading, except with greater transparency and potentially greater liquidity.

Moreover, while Dominium will necessarily have the ability to restrict access to the platform to meet KYC and AML requirements, this process will be more transparent than in a fully centralized service. In particular, if Dominium were to revoke a user’s permission to use the blockchain, there would at least be indisputable proof of this action in the transaction history, which is, after all, public record.

It seems to me that investors, for their part, also benefit from this structure. Rather than having to trust a brand new brokerage—which might be legitimate or which might be a boiler room operation, for all they know—investors will be able to see for themselves important details about all the funds available for purchase and to verify from the blockchain that they are indeed getting genuine shares. As each account’s holdings are recorded on a public ledger, investors will also have access to information they don’t typically get with funds traded on centralized exchanges, including the distribution of shares across accounts and the other holdings and transaction histories of those accounts.

But will the funds themselves be more efficient by virtue of launching and trading on a blockchain? This is a far more complex question than I can competently answer with my very limited knowledge of investing, but I can at least speculate about potential cost savings and you can tell me where I’ve gone wrong in the comments section. 🙂

One task that all investment funds must face is keeping track of who holds their shares, not just for regulatory compliance but also to know who to pay dividends to and in what amounts. I imagine this can be a costly process for smaller funds with a large number of shareholders, but the blockchain (and Ardor in particular) makes this kind of bookkeeping trivial. Also, as I mentioned before, listing a fund on a centralized exchange is an expensive undertaking, whereas a blockchain-based decentralized exchange could still provide liquidity while saving this expense.

As for listing, purchasing, renting, and managing individual properties on Dominium, in my view the case for using a blockchain seems to rest almost entirely on how much management information users commit to the blockchain. There are already plenty of centralized real estate listing websites, and they seem to work rather well as marketplaces for connecting buyers and sellers. In contrast, the notion of storing historical information about a property in a decentralized way sounds like something new.

But does such a service really need to be decentralized? Couldn’t somebody build a “Carfax for real estate” without all of the limitations of using a blockchain? I think the answer is probably yes, but I can still see an advantage to the decentralized version, namely that no one entity will be able to selectively modify or delete historical data.

While that might sound a little paranoid, I do think there’s some precedent for concern. Look at the allegations of extortion that businesses have made against Yelp, for example. They claim that Yelp selectively filters out positive reviews of their businesses, leaving a disproportionate number of negative ones, unless businesses pay a hefty advertising fee, which makes the negative reviews disappear. Regardless of whether this is technically extortion (it appears that it isn’t, by the way) and whether Yelp is actually guilty (which they deny), it at least seems plausible that a centralized ratings service could pressure users this way. A decentralized alternative, in contrast—and especially one that establishes users’ real-world identities before allowing them to contribute information, as Dominium does—might provide a safeguard against this kind of abuse.

Finally—and this is perhaps the most exciting possibility, in my opinion—if Dominium’s users eventually record ownership and management information for enough individual properties that those properties make up a substantial fraction of the holdings of the funds listed on Dominium, then investors will have an unprecedented (as far as I know) degree of transparency about the quality of the properties those funds own.

Why Use Ardor?

I suppose the folks at Dominium could have chosen Ethereum over Ardor, but then they would have had to build a number of features themselves, including most notably a permissions layer for all transaction types and a mechanism to restrict trading of certain funds to specific subsets of accounts. On Ardor, these features are built in: permissioned child chains, coming Q3 of this year, will automatically restrict access to authorized accounts, while the Asset Control and Vote by Account Property features enable a finer degree of control over which accounts will be able to exchange certain tokens.

This latter point is especially important for Dominium, which will grant different permissions to users based on how much personal information they provide, where they live, and whether they qualify to invest in unregulated funds. Specifically, Clearance Level 1 users will provide basic identity information and will be able to buy and sell DOM utility tokens and list, purchase, or rent properties; Clearance Level 2 users will provide full KYC information and will be eligible to purchase shares of regulated real estate funds from jurisdictions where they can lawfully invest; and Clearance Level 3 users will attest that they are qualified investors (generally either high net worth individuals or professional investors) and will be eligible to invest in both regulated and unregulated funds.

Implementing these tiers is straightforward on Ardor: Clearance Level 1 is established by authorizing an account to transact on the permissioned Dominium chain, while Clearance Levels 2 and 3 are enforced using asset controls to restrict the trading of regulated and unregulated funds, respectively, to accounts that Dominium has marked as eligible. Further constraints on investors’ eligibility to purchase funds in specific countries, for example, translate rather cleanly to additional account properties establishing the countries an investor is allowed to invest in and additional asset controls to enforce those policies.

On a different note, keep in mind that Dominium’s child chain will be permissioned in the sense that only authorized accounts will be able to transact on it, but it will be public in the sense that anybody will be able to examine and verify the transaction history. This hybrid design combining permissioned transactions with public validation is more controlled than a fully public blockchain, where KYC and AML compliance would be much more difficult, and more transparent than a fully permissioned blockchain. As far as I know, this combination of traits is unique to Ardor.

Beyond issues related to permissioned access and regulatory compliance, other reasons that Dominium chose Ardor include its novel approach to combating blockchain bloat, its wide array of built-in features, and the stability and resilience of its codebase, most of which has been in production since 2013 as part of Nxt. Since I’ve written at length about these aspects of Ardor elsewhere, I won’t repeat myself here.

I would like to point out, though, that Ardor’s built-in features make it much easier to deploy a platform like Dominium securely than would be the case on a smart contract platform like Ethereum. The functionality that Dominium requires is not trivial, and coding it from scratch as a set of custom smart contracts, some of which could be fairly complex, would incur the risk that one of those contracts contains a subtle flaw that could be exploited to cause catastrophic failure. With Ardor, in contrast, predefined building blocks for on-blockchain tasks have been thoroughly peer-reviewed and battle-tested, while all custom code runs off-blockchain, where it is easier to patch as flaws are discovered.

A Word About the ITO

One additional aspect of the Dominium platform that differentiates it from other blockchain projects is its plans for its initial token offering (ITO). Dominium will invest most (>80%) of the money it raises from its ITO in real estate, and it will use the dividends from these investments primarily to fund the development of the platform. In addition, though, it will use a portion of these returns to buy back DOM tokens and burn them, thereby decreasing the total supply of DOM. As people use the platform Dominium will also collect transaction fees denominated in DOM tokens, and again it will burn them to make DOM more scarce.

In my humble opinion, Dominium’s decision to invest the proceeds from its ITO in stable, real-world assets instead of leaving those funds in hyper-volatile cryptocurrencies shows that the Dominium team is serious about the long-term development of this project. It is a refreshing change and surely lends credibility to the team.

On the other hand, I don’t think the ITO will be completely without controversy. Dominium’s legal team insists that DOM is a utility token and not a security. As it will be the sole currency for paying fees for all business conducted on the platform, there can be no doubt that DOM is a utility token. But I suspect that regulators might decide that it could also be a security, owing to Dominium’s plan to buy back tokens using the earnings of its real estate holdings. In the U.S., anyway, an investment contract is defined as “an investment of money in a common enterprise with a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others,” and all investment contracts are securities. It is at least a legal gray area, and perhaps it will take some time for governments to clarify how tokens like DOM are to be understood.

Then again, if regulators do indeed decide that DOM qualifies as a security, Dominium will be in an excellent position compared to other ITOs as a result of the KYC controls it has implemented. To participate in the ITO, users will need to register at Clearance Level 1, so Dominium will already have satisfied some of the KYC requirements. I don’t think that a ruling that their ITO token is a security would pose the same kind of existential threat to Dominium that it would pose to the vast majority of other ITOs.

Closing Thoughts

There is much more to say about Dominium, but this article is getting quite long, and I have already trod well past the limits of my knowledge of real estate investing and securities law, so I will conclude here.

Reflecting on the structure and features of the Dominium platform, and especially on the measures that Dominium has taken to comply with government regulations, I’ve changed my opinion on permissioned blockchains with a centralized authentication service. As I wrote elsewhere, I had previously been quite skeptical of blockchains controlled in some significant way by a single entity. A private database, in my estimation, was almost always a better solution.

Dominium has shown me that I was wrong. It is possible for the power to control access to a blockchain to be quite centralized, but for other aspects of the business conducted on the blockchain to be decentralized in a meaningful way. Government regulations, legal liabilities, and other real-world concerns add to the analysis some nuances that I had failed to appreciate until I started researching Dominium. I’m glad I did so.

On that note, I’d like to sincerely thank the folks at Dominium who have taken time out of their busy schedules to answer my sometimes naive questions about real estate investing, property management, and other aspects of their platform. I truly wish them the best of luck with their launch, and I’m very excited to see what the future holds!

Ardor Contract add-on examples

Jelurida is Developing the Contract Concept

Jelurida continues to hone and further develop their Lightweight add-on contracts concept. In the second week of March, we introduced this in the Nxter Newsletter.  

Lior wrote:

You don’t need to pay gas for these contracts and you can program in Java. On the other hand the “contracts” are only executed by anyone running the addon and it’s not part of the consensus i.e. you can verify that anyone who created a transaction based on the contract did not cheat, but if they cheat or just choose not to run the contract then you cannot fix it. i.e. some trust in the contract executor is required.

Lior continues deploying example contracts to the decentralized data cloud, and we expect to see a number of blog posts from him soon going into detail about the add-ons concept. Until then, here’s the first view, as posted in the #developers channel in ArdorNxt.Slack.com.

 

Hello World 

Lior –

While we continue to develop our contracts concept, you can experiment with it by sending a message transaction, on the Ardor testnet, with text:

{ “chain”: 2, “fullHash”: “53758cc1f44a3eaf86cc187cbd2b73c2a60c0cf60adafb734fc42477bf6d29c2” }

to account ARDOR-NFAY-XYBA-SZ4G-H8SHA

In response, you should receive an automatic greeting message from the HelloWorld contract deployed to cloud data.

The contract code is:

 public void processTransaction(TransactionContext context) {
      if (!context.validateSameRecipient()) {
          return;
      }
      JO transactionJson = context.getTransactionJson();
      int chainId = transactionJson.getInt(“chain”);
      Chain chain = Chain.getChain(chainId);
      String recipientRS = transactionJson.getString(“senderRS”);
      JO params = new JO();
      params.put(“recipient”, recipientRS);
      JO message = new JO();
      message.put(“text”, “Hello ” + recipientRS);
      params.put(“message”, message.toJSONString());
      params.put(“messageIsPrunable”, “true”);
      context.createTransaction(“sendMessage”, chain, params);
  }

The contract transaction is 2:71660bdaa260d790772e3fc64470a8db465f6b395a0e134f921d57d6fd9589f0

The PingPong Lottery

Send any amount in any chain, on the Ardor testnet, with attached message text:

{ “chain”: 2, “fullHash”: “798131112caf0f417abd44eaac64f432d0dac147a0d7021b9232d726e215b4be” }

to account ARDOR-NFAY-XYBA-SZ4G-H8SHA

In response you will receive back amount between 0 and 2x your investment.

Contract code is:

public void processTransaction(TransactionContext context) {
if (!context.validateSameRecipient() || !context.validateTransactionType(PaymentTransactionType.ORDINARY, FxtTransactionType.findTransactionType((byte)-2, (byte)0))) {
return;
}
Random r = context.getRandom();
long amount = context.getAmountNQT();
long returnAmount = BigInteger.valueOf(Math.abs(r.nextLong())).multiply(BigInteger.valueOf(2)).multiply(BigInteger.valueOf(amount)).divide(BigInteger.valueOf(Long.MAX_VALUE)).longValue();
Logger.logInfoMessage(String.format(“amount paid %d amount returned %d”, amount, returnAmount));
Chain chain = context.getChain();
long recipient = context.getSenderId();
JO input = new JO();
input.put(“recipient”, recipient);
input.put(“amountNQT”, returnAmount);
context.createTransaction(“sendMoney”, chain, input);
}

The contract transaction id is, of course, the transaction id we mentioned in our message 2:798131112caf0f417abd44eaac64f432d0dac147a0d7021b9232d726e215b4be

Oracle

Here is an example for an “Oracle” contract.

Send 1 IGNIS or more with attached message:

{ “chain”: 2, “fullHash”: “409c120e6e7551927be4856389bb34cd257ccb84cfb202569327c4a3a89f0e7a” }

to account ARDOR-NFAY-XYBA-SZ4G-H8SHA

In response you will get back a message with the calculated rate of IGNIS per ARDOR from both Bittrex and the Coin Exchange to help you identify arbitrage opportunities.

Contract code:

package nxt.addons.contracts;

import nxt.addons.TransactionContext;
import nxt.blockchain.ChildChain;
import nxt.util.Logger;
import org.json.simple.JSONValue;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;
import java.math.BigDecimal;
import java.math.RoundingMode;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;

public class IgnisArdorRates extends AbstractContract {

/**
* Sample contract which receives amount from the trigger transaction and returns a random amount between 0 and twice the received amount
* @param context contract context
*/
@Override
public void processTransaction(TransactionContext context) {
JO response = new JO();
if (!(context.getChain() == ChildChain.IGNIS) || context.getAmountNQT() < ChildChain.IGNIS.ONE_COIN) {
context.setErrorResponse(10001, "Oracle requires a payment of 1 IGNIS to operate");
return;
}
// {"success":true,"message":"","result":{"Bid":0.00003072,"Ask":0.00003098,"Last":0.00003090}}
JO ignisTickerResponse = getRate("IGNIS");
if (ignisTickerResponse.get("errorCode") != null) {
context.setResponse(response);
return;
}
Double ignisLastTrade = ignisTickerResponse.getJo("result").numericToDouble("Last");
JO ardorTickerResponse = getRate("ARDR");
if (ardorTickerResponse.get("errorCode") != null) {
context.setResponse(response);
return;
}
Double ardorLastTrade = ardorTickerResponse.getJo("result").numericToDouble("Last");
long ignisNQTPerARDR = BigDecimal.valueOf(ardorLastTrade).
multiply(BigDecimal.valueOf(ChildChain.IGNIS.ONE_COIN)).
divide(BigDecimal.valueOf(ignisLastTrade), RoundingMode.HALF_EVEN).
longValue();
response.put("BittrexIgnisNQTPerARDR", ignisNQTPerARDR);
JO requestParams = new JO();
requestParams.put("chain", 2);
requestParams.put("exchange", 1);
requestParams.put("firstIndex", 0);
requestParams.put("lastIndex", 1);
JO getCoinExchangeTradesResponse = context.sendRequest("getCoinExchangeTrades", requestParams);
JA trades = getCoinExchangeTradesResponse.getArray("trades");
if (trades.size() > 0) {
JO trade = trades.get(0);
response.put("BlockchainIgnisNQTPerARDR", trade.get("priceNQTPerCoin")); // TODO test with real data
}
JO input = new JO();
input.put("recipient", context.getSenderId());
input.put("message", response.toJSONString());
input.put("messageIsPrunable", true);
context.createTransaction("sendMessage", context.getChain(), input);
}

private JO getRate(String coin) {
HttpURLConnection connection;
JO response = new JO();
String protocol = "https";
String host = "bittrex.com";
int port = 443;
String urlParams = "/api/v1.1/public/getticker?market=BTC-" + coin;
URL url;
try {
url = new URL(protocol, host, port, urlParams);
} catch (MalformedURLException e) {
response.put("errorCode", 10002);
response.put("errorDescription", e.getMessage());
return response;
}
try {
Logger.logDebugMessage("Sending request to server: " + url.toString());
connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
if (connection.getResponseCode() == HttpURLConnection.HTTP_OK) {
try (Reader reader = new BufferedReader(new InputStreamReader(connection.getInputStream(), "UTF-8"))) {
return new JO(JSONValue.parse(reader));
}
} else {
response.put("errorCode", 10003);
response.put("errorDescription", "No response");
return response;
}
} catch (RuntimeException | IOException e) {
response.put("errorCode", 10004);
response.put("errorDescription", e.getMessage());
return response;
}
}
}

Class file is deployed as cloud data txid 2:409c120e6e7551927be4856389bb34cd257ccb84cfb202569327c4a3a89f0e7a

Note that when you send a message to the contract you always use this txid in the message

ProbertyBasedLottery

And contract 2:ab2ee853bf8bf57b550d16d2ffd1bed087b79eefb8b879f8d22f9ec969960a41 is a new version of the PropertyBasedLottery contract used by Bitswift to determine the winner of their twitter campaign: https://www.nxter.org/nxter-news-april-2018-i/#Bitswift_childchain_thread

UPDATE:

Lior has published a series of articles about Lightweight Contracts on his Medium blog, since this post was written. You should check them: https://medium.com/@lyaffe/lightweight-contracts-articles-49c3032a50da

Follow Lior’s blog on Medium.

ARDOR: A TOUR THROUGH UTOPIA (II)

If you have been a follower of the biggest development in the cryptoland, Ardor, then you must have read the first episode of this article series. Well, if you haven’t read it or you haven’t been following, then I say congratulations to you for seeing this sequel. Verily, you have finally found the future; now it lies in your hands. In the first episode, we discussed some of the adorable features of Ardor. They are adorable for, with Ardor and all which it represents, Cryptocurrency becomes worthwhile and interesting. Now, we shall discuss another feature of Ardor, by discussing what it involves and basically how it works.

May 2017, Jelurida’s Co-founder and Senior Developer, Lior Yaffe, was in Spain where he presented a voting use case based on the Ardor Blockchain platform at a live broadcasted Blockchain event organized by El Pais Retina in Madrid. The demo was prepared and demonstrated in collaboration with Accenture Spain and it showed how easily our Blockchain and its voting feature can be adapted to this important real world use case.

Well, you may begin to wonder what voting has got to do with activities in the cryptoland. You are probably asking if Ardor has secured the contract to organize the next presidential elections. Fortunately, we are here for you, for everyone, and for every organization. Since we often make decisions from time to time, we have established the voting features for use by our members.

Using the Voting System, any account can create a poll with one question and up to 100 answers. The creator of the poll qualifies who can vote based on the account, the balance per voting account, an asset, or a currency. Here is a summary of how it works.

#Poll creation: This is the first step in the voting system. Here, the administrator will be eligible to create specific questions and add them in the blockchain.

#Registration/Notification: The registration will be received through a medium which shall be received by stakeholders or eligible candidates.

#Casting of Votes: While votes are being cast, counting of the votes is on, and this will be done by the Blockchain itself.

#Poll Validation: The votes are confirmed and validated.

#Poll Ends: Here, the voting is brought to an end, after which nobody will be eligible to vote.

#Poll Results: Results are instantly presented in graphics and other forms.

The voting system allows for an online database, unlike the manual voting based on paper. A consensus method is adopted in casting and the results are released instantly; so no more waiting or unnecessary delays. Also, votes can be cast from anywhere, whether browser or mobile application. The system is user-friendly and there are in-built fraud avoidance features, which make it immutable, traceable and reliable.

So do you get the idea? The Cryptoland has been hit by changes, and the only solid ground is that which is open to positive changes. Not anymore is it just about the coins or trading in them, but a whole lot more. We are glad that Jelurida, the umbrella under which these groundbreaking ideas surfaced is at the forefront of this evolution. This is just the beginning. The wonders of Utopia cannot be comprehended or experienced in few days in time or pages in tales.

NXT/ARDOR: A SKY OF CLOUDS

There is no gainsaying that information rules the world, for information is simply knowledge and knowledge, they say, is power. Come to think of it, what can we do without information? Exactly! Information is everything we need to survive, and at the heart of that surviving factor (information) lies data. Everybody has got a need to put data together, to put them into use when the need arises and to keep every detail for future reference.

Of course, information has always been gathered several decades before now. But the reality of today has shown that things have changed drastically, new ideas have emerged and developments have taken place. One of such developments is the inclusion of additional data storage features as part of the blockchain. This is possible on NXT, Ardor and its child chains, such as Ignis, with the Data Cloud feature. Data that can be saved on the cloud range from data derived from the blockchain itself, to every other kind of data, including personal data.

The Ardor platform provides more information on this great feature. It states, “The Nxt Data Cloud is a decentralized data storage system. In addition to keeping a record of Nxt transactions, the Blockchain can also be used to store user-defined data. All forms of data can be uploaded to the Nxt Blockchain, providing a secure (and, if desired, permanent) method of storing, retrieving and publishing information.

“One of the most important features of data storage on the Blockchain is that the Nxt Blockchain is a permanent and immutable record that provides a tamper-proof time stamp. This allows for legal records (such as contracts) to be embedded in the Blockchain, with absolute certainty about the time at which they were created.”

The platform, while buttressing the encompassing nature of the Data Cloud gives instances of data that can be saved therein. It includes: use cases; land titles, vehicle registries, business license, business incorporation/dissolution records, business ownership records, regulatory records, criminal records, passports, birth certificates, death certificates, voter IDs, voting, health/safety inspections, building permits, Gun permits, Forensic evidence, court records, voting records, non-profit records, government/non-profit accounting/transparency.

It can as well be used to store private records; contracts, signatures, wills, trusts, escrows, and GPS trails (personal). It may also be used for other semi-public records; degree, certifications, learning outcomes, grades, HR records (salary, performance reviews, accomplishment), medical records, accounting records, business transaction records, genome data, GPS trails (institutional), delivery records, arbitration and so on.

Take a closer look at the sky and tell me what you see. Clouds within and around which lies the wonders and gateway to the constellations. Look deeper and we get into the imaginary world that is never the same in the eyes of every observer. When the team looks at the Blockchain and its unachieved and untamed possibilities, they see what others do not. They see endless use with the tendency to change the world.

The future is here. Blockchains are no longer as rigid as blocks for, with NXT/Ardor, we make them flexible enough to improve existing processes and solutions. So, if you haven’t started moving with the train, it’s time you do. It’s time you took control of the future. What’s more, it is high time you saved those pieces of information on the Cloud, and remained as confident as a bird in the sky.

Ardor, A tour through Utopia (I)

One of the previous publications on Ardor addressed a germane issue in the Crypto-land. This issue is that which is concerned with investment, patience and ultimately, the need to make massive profit after strategically adopting the former concerns. The publication was inspired by a conversation among Crypto actors on the expected return from their investments in Ardor. Fortunately, they were later convinced that Ardor is no scam or fraudulent scheme, but a platform that has come to stay and also a platform, where the future of blockchain lies.

But let’s put that aside. Have you realized that Ardor has some adorable features which makes cryptocurenncy worthwhile and interesting? No? Ooopppsssss, you are definitely missing out.

MARKETPLACE:
Yes! You might probably refer to it as E-commerce in a new dimension, but it is certain that this is one feature which you will definitely enjoy. Buying and selling has been made easy with Ardor and members of the blockchain can easily trade goods win one another. Easy, right? Definitely. Here, two things come to play -members buy from and sell to others on the blockchain; and enterprising members are empowered to market their products to others on the Ardor platform.

So, Ardor allows you to have a blockchain marketplace where anyone can buy and sell physical and digital items. The Marketplace is already a part of the Ignis child chain and any other child chain to be established under Ardor shall possess this great feature. This is cryptocurrency renewed, this is adorable, this is Ardor.

The Ardor platform describes this feature thus; “The Marketplace enables direct peer-to-peer trading on the blockchain. It is an open decentralized store for all digital goods. You may sell or purchase software, music, video, ebooks or any other kind of digital good here. Simply browse the available products, place an order and the seller will send you information of how to download the good (usually a link) inside the blockchain system.”

The platform acknowledges a development which shows progress and commitment, thus “although Marketplace was designed for buying and selling digital merchandise, physical items have also been listed for sale”.

ACCOUNT CONTROL:
It is well known that security is key to the success of any business -online and offline. In the case of online businesses, like operations in the crypto-land, it is always of great need and emphasis with the aim of protecting online actors, avoiding exploitation and manipulation of various kinds. Therefore, it is for this reason that Ardor and it’s child chains possess the Account Control feature, which is a security measure that ensures that access is rightfully restricted and unapproved transactions are prohibited.

The Ardor platform explains the features further. It states thus; “Restrict access to a blockchain account or prohibit transactions without approval by multiple parties. Rules can be written for each account to limit the terms of a transaction. Features of Account Control include setting a lock on an account to prohibit any outgoing transactions and defining a set of rules for unlocking the account”.

It should be noted that above are just two among the several features of Ardor. While other features shall be discussed in subsequent publications, it is already evident that with Ardor, activities in the Crypto-land is interesting, enjoyable and adorable. If you want to journey to a far land, yet so near; with beauty beyond which words can describe; and have an interesting voyage same as the rest but with a different experience, then take a journey to Ardor. The Utopia of Crypto-land. The chains have gathered, the train is moving and the destination is nowhere but the future of blockchain.

The Equal Market You Ought to Explore

Equality has always been a farfetched term and only exists in the dreams. Unfairness and inequality have gone beyond the five fingers and have eaten deep into all systems. But then, this isn’t a conversation that concerns us at the moment. However, the market is. Who can survive without a market? No living man can, unless he provides everything he needs all by himself. The greatest of all markets of course is the financial market, as money is another commodity one can’t do without and a conversation everyone wants to engage in. After all, it makes the world go round. So, let’s talk about “The Market”, “The Money Market”.

Let me throw out a rhetorical question to my dear readers. “Have you ever been to a market place?” The obvious answer is that nearly everyone has – whether from the corner of our rooms through the internet windows on our mobile phones, or actually through physical interactions. It’s a place for all commodities essential to human life. Several years back before the introduction of the Financial Market system, it will be deemed a myth to forecast a future of such market. Today we have Foreign Exchange Markets and, even more, we have the Exchange for Digital currencies. Now, that’s a market everyone is talking about. A future some few are afraid of.

The idea of having a decentralized, difficult to corrupt system and a future of independent financial structure terrifies me. I am the man behind the corrupt politics, a wealthy aristocrat who wants it all for himself.  But then, the world we know has become little and encircled by the Crypto-space. Cryptocurrency is here to stay. Cheers to the common man as he at last has a fair and equal opportunity in the space.

Available materials show that Cryptocurrency came in as a side product of another invention. Satoshi Nakamoto, the unknown inventor of Bitcoin, the first Cryptocurrency, never intended to invent a currency. In his announcement in late 2008, he declared that he had developed a ‘Peer-to-Peer Electronic Cash System”. Satoshi’s invention was a successful creation of a decentralized digital cash system, which came in after several attempts had failed. Well, that was about ten years ago when Satoshi made his invention, which is still raising questions, fear, as well as optimism among the populace.

Years have passed and the rains of ideas have fallen unto the plains of execution effecting sudden germinations of several digital currencies. They rose from all directions with similar offer but only a different name and people behind it to distinguish them. Few stood out with more to offer and determination to bring that future even nearer. From BCNext came the idea of such a rare currency in 2013. A second generation of cryptos that was developed from scratch. It came with it many features that would have been thought of to be the future of digital currency such as shuffling, decentralized DNS, peer-to-peer exchange, voting system to mention a few. It emphasized on the broad nature of blockchain which was more than just a currency.

As a continued effort of the 5-year Legacy of NXT came Ardor in the earliest hours of 2018. A second iteration of NXT, a whole new exciting journey of cryptocurrency with new and interesting features. Sitting on the throne as the first parent chain, Ardor welcomed the first child chain, “Ignis”, each with individual differences and goals in the blockchain vision realization. To the team behind it, the future is all that matters. A future with a carefully laid foundation is definitely a never-ending one. Part of the features that makes the whole development more than just a currency to be traded is the Market Place. The end dream of every currency is to be spent and not just traded of. Paving the path to the future where cryptocurrency realizes its goal of being a genuine means of exchange makes it a cryptocurrency of the future.

As the Ardor Platform puts it: “The Marketplace enables direct peer-to-peer trading on the blockchain. It is an open decentralized store for all digital goods. You may sell or purchase software, music, video, ebooks or any other kind of digital good here. Simply browse the available products, place an order and the seller will send you information of how to download the good (usually a link) inside the blockchain system. Although Marketplace was designed for buying and selling digital merchandise, physical items have also been listed for sale.”

So, when the idea crossed your mind of being part of the great future in the emerging blockchain industry, think no further. It can’t get any better than the one that builds on the two greatest entities, Market and Money. This is the big thing. It is a market for you, me and every one of us. It is a market you ought to explore.

Nxt and Ardor hackaton March 22, Norway

NFEA Autonomy Conference + Ardor/Ignis Workshop and Hackaton


At the upcoming NFEA Autonomy Conference in Norway, there will be hands-on Ardor/Nxt workshops and a hackathon for developers on the 22nd. Bring your own laptop.

riker:
Developers are invited for the March 22nd hackaton.

Details:

March 20-21, The Autonomy Conference 2018, Scandic Bystranda Hotel, Kristiansand, Norway
Go to the Registration Site for the conference (in Norwegian).

Full program

March 22, Ardor Hackaton, Scandic Bystranda Hotel, Kristiansand, Norway
Go to the Registration Site for the hackaton. This event is sponsored by SFI Offshore Mechatronics and is free for the participants, but the number of seats is limited to 50.

Program for the hackaton event:
08:00 – 08:30 Coffee/tee
08:30 – 10:00 Ardor API programming, test page, account creation, node JS module, security considerations
10:00 – 10:30 Coffee/tee
10:30 – 11:30 Using the Ardor API exercises (Javascript skills recommended)
11:30 – 12:30 Lunch
12:30 – 14:00 Ardor server side add-ons, custom bundlers, dbshell
14:00 – 14:30 Coffee/tee
14:30 – 16:30 Building Ardor add-ons exercises (Java skills required)

What Good is Ignis, Anyway?

Recently there have been several posts on the Nxt and Ardor subreddits asking about Ignis: Why did Jelurida create it? What problems does it solve? Why would people want to use it?

I suspect that for a lot of longtime members of the Nxt community, the answers to these questions are self-evident. For newcomers, though, it’s a fun and helpful exercise to brainstorm interesting applications of the Nxt/Ardor tech. In that spirit, I replied to one of those posts with a few thoughts about what you can do with Ignis. I figured Nxter readers might be interested to hear them, too, so I’m posting them here for you to consider.

So what’s special about Ignis? In a nutshell, Ignis is the only child chain on the Ardor platform that is guaranteed to be permissionless and to support all available features. It will have basically all of the features that Nxt currently has, plus a few new ones (see apenzl’s excellent write-up for a survey of the new functionality). If you’re new to Nxt and Ardor and haven’t spent some time with the full client yet, I’d strongly recommend you do so. It’s quite impressive just how much you can do with the built-in features.

IGNIS

Without further ado, here are a few examples of ways you might use Ignis, most of which apply to Nxt, too.

Co-Ownership of Property

Suppose you and some friends own a rental property. You can create an asset on Ignis to represent shares of the property and distribute the shares among the co-owners. As the property earns money, you can pay dividends to the owners in proportion to the amount of the asset that they hold (this is a built-in feature). They can freely buy or sell their shares in it (another built-in feature), making it easy for them to take on as much or as little risk as they are comfortable with. If you need to make a collective decision, like whether to remodel it, you can conduct a poll of your asset holders (another built-in feature) where their votes are weighted by their share of the asset, or where each person gets an equal vote, your choice.

Decentralized Crowdfunding

Suppose you want to conduct a Kickstarter-like crowdfunding campaign, where your supporters don’t have to pay unless you meet your fundraising goal. The Monetary System on Ignis supports exactly this application, among many others. You can issue your own “currency” (token) to represent a receipt of payment from your backers, set a deadline for the fundraiser, and make the transfer of funds conditional on raising at least some minimum amount of money. All of this is built-in functionality. As your project progresses, you can send your supporters messages using the Messaging System with updates on important milestones. Finally, when your project turns out to be wildly successful, you can pay bonuses to your early backers proportional to their share of your tokens.

Retail

Suppose you own a video game store and Nintendo announces that they’re selling a Nintendo64 Classic. You know that you’ll only receive a limited quantity. To save your customers the hassle of lining up outside your store at 5 am to try to get their hands on one, you decide to offer them an opportunity to buy vouchers ahead of time, which they can exchange at their convenience for the game system. You’re worried that scalpers will buy up all of your vouchers at MSRP and resell them for a huge markup, though.

You decide to issue your voucher through the Ignis Monetary System as a controllable currency. This means that you can sell it at a fixed price and buyers can’t resell it later to anybody but you. When the account holder later visits your store, you buy back the voucher for next-to-nothing and give him or her a Nintendo64 Classic in return.

Fintech

Suppose you want to start a hedge fund like Numerai. You want to issue a token that can only be held or traded by data scientists, whose models you want to collect and evaluate.

You first solicit applications from data scientists through your website and decide whether they’re worthy to participate. The candidates you’d like to enroll send you their Ardor addresses, and you use your account to mark their accounts with a special property indicating that they are eligible to participate. Next, you issue an asset on Ignis using the new Asset Control and Vote by Account Property features, and specify that your asset can only be traded by accounts with the property you used to designate eligibility. You then make payments of your asset to each account proportional to how well the account holder’s models perform, and you pay dividends to all asset holders in proportion to their holdings. The result is that people who submit the best models get the biggest shares of your dividends.

Perhaps you charge your users a fixed quantity of your asset for each model they submit, both to ensure they have some skin in the game and to help redistribute the asset away from the users who submit the worst models. Since Ignis supports sending short messages along with payments, a user could annotate such a payment with an ID number that corresponds to the submitted model, allowing you to easily track which models’ submission fees have been paid.

Venture Capital

Suppose you want to start a crowdfunded venture capital firm. You want to sell shares of your firm to raise money, allow shareholders to vote on which projects to invest in, and pay them dividends in proportion to their holdings. You like the idea of making the investment decision somewhat decentralized, but you’re nervous about using a strict decision-by-majority investment model. As a hedge, you’d like to allow a supermajority of your board members to veto investment decisions made by your investors.

You can issue an asset on Ignis representing shares of your company, then make payments to the companies you invest in using composite phased transactions, another new feature. You can set the phasing conditions to say that each payment succeeds if at least a majority of your asset holders approve of it and less than eight out of your ten board members try to veto it. If these conditions are met, the company gets funded. Otherwise, the transaction does not occur. And how do you elect your board members? Why, the built-in voting system, of course.

Conclusion

These examples barely scratch the surface, but hopefully, they give you an idea of the kinds of things Nxt and Ignis can do.

Note that you can do any of these things using just the standard Ardor wallet. If you’re a programmer, though, and you want to make things a little easier on the people you’re interacting with, you can write an app with a custom interface that interacts with Ignis only on the backend. Your users don’t even necessarily need to know that they’re transacting on a blockchain.

Along those lines, I’d suggest that most of the things you would want to do on Ethereum can also be done on Ignis. As I’ve argued before, writing secure smart contracts on Ethereum generally requires either keeping them very simple or introducing some trust between users and developers. In the former case, Ignis’s smart transactions often substitute directly for smart contracts, and in the latter case, you might as well move most of your code off-chain and only use the blockchain for the parts that really need to be trustless. Either way, I don’t think the extra flexibility that smart contracts offer is quite as big an advantage as it appears to be at first blush.

So if you find yourself wondering what value there is in Ignis, first ask yourself what value there is in Ethereum. For each example application you come up with, try to convince yourself that you absolutely could not use Ignis to accomplish the same goal with a similar degree of decentralization. If you share my concerns about the security of complex smart contracts that are truly immutable, you might be surprised at how similar the potential applications of both platforms are.

Finally, it’s worth mentioning that there might be significant non-technical challenges to a couple of the examples I’ve given. In particular, the U.S. Securities Exchange Commission ruled several months ago that some tokens traded on blockchains can be considered securities, especially in cases where investors have “a reasonable expectation of profits derived from the managerial efforts of others.” In such cases, issuers of those tokens must register with the SEC in order to do business in the U.S. I suspect that this is not as big a deal as a lot of blockchain enthusiasts make it out to be, but that’s probably the subject of a different article. 🙂

In any event, I hope these examples help put into concrete terms just how much functionality Ignis offers. If you can think of other (better?) examples for how to use Ignis, please add them in the comments section! And as always, I’d greatly appreciate constructive criticism.

IGNIS Airdrop

The holiday season is upon us and soon free IGNIS tokens will rain down into your Nxt accounts! 500M IGNIS tokens will be airdropped on NXT coin holders at the New Year!

What is Going On?

On Dec 28, 2017: a snapshot of the Nxt blockchain will occur:

Jelurida takes a snapshot of all NXT accounts with everything in them, including the NXT you hold, your registered aliases, account properties, your NxtAE (asset exchange) portfolio, Marketplace items, Monetary System coins, etc. The state of the blockchain. Your NXT balance @ the snapshot block determines how much IGNIS you will get: 1 IGNIS per 2 NXT.

With the snapshot block, some coins and trading markets will be temporarily frozen.

These tokens will, temporarily, become untradeable: ARDR (the Nxt asset which represents ARDR tokens on the Ardor blockchain platform), JLRDA (which represents the IGNIS tokens sold during the ICO), Janus (which will be re-issued on IGNIS/Ardor), and also BITSWIFT, which will be reborn as an Ardor child chain, along with Ignis, with the Ardor Genesis block.

The Ardor platform and its first child chains will launch on 1/1-2018 0:00 ETC.

From that moment, when the Genesis Block is forged, the markets for the beforementioned tokens are open again. For every 1 NXT you have in your Nxt account on Dec 28, at the time of the snapshot, you will find an additional 0.5 IGNIS, on the Ardor blockchain. You can already log in to the Ardor testnet with you current Nxt account ID and see how it works. Also, 10% of the BITSWIFT child chain tokens will be distributed to IGNIS holders. Not because of the JPL license, but because Bitswift has decided to reward the Nxt and Ignis community, with an extra Xmas gift to holders!

NXT and IGNIS

IGNIS is the transactional token of the unrestricted open to all blockchain 2.0 Ignis child chain, spawned from Ardor, the scalable disruptive platform that Jean-Luc, Nxt lead developer since 2013, and Jelurida, have created.

Those that listened know that the Nxt platform will not become obsolete but will be taken care of, as a perfect showcase for Jelurida and a still relevant featureful public blockchain, under the JPL license. The JPL (Jelurida Public License) aims to protect investors in the NXT token, while at the same time keeping the core code open source. According to the JPL, any clone of Nxt must distribute 10% of the newly issued tokens among NXT holders, proportionally according to their stake in NXT.

Jean-Luc explained:

[With JPL], unlike the GPL, in addition to the copyright owner (Jelurida) any token holder can initiate a claim, because he has incurred a loss. It will also be much more straightforward to demonstrate the total monetary value of such losses, as 10% of the marketcap of the infringing clone.

IGNIS inherits all the features of NXT. Plus more. Much more.

Ignis is spawned from Ardor. The Ardor server software can run on a mobile phone, a Raspberry Pi or a VPS, and anyone with ARDR can earn fees from forging ChildBlocks (blocks of bundled transactions made on Ignis and other Ardor child chains). Forging is Nxt and Ardor PoS’s equivalent to PoW “mining” and secures the full Ardor network.

Other ways to support and monetize the network is (currently) Bundling or running Archival Nodes.

Child chain transactions are not forged on the child chain but are bundled and sent in blocks to the Ardor parent chain, which forges, files, and secures them. Anyone can become a Bundler, and bundle child chain transactions. It takes ARDR to be a Bundler, because the Bundler must transfer ChildBlocks (those consisting of bundled child chain transactions) to the Ardor parent chain. Ardor only accepts ARDR. Bundlers are paid in child chain tokens for their service. They set their own fee.

Archival Nodes expand the default network when it comes to storing data on the blockchain. Messages sent between accounts as well as other kinds of encrypted or public data uploaded to the network are “pruned” from child chains. Only hashes are stored, which makes the child chains scalable – unnecessary bloat is removed at regular intervals. Archival Nodes, on the other hand, store pieces of data, so they can be dug up and used. Thus, Archival Nodes provide a distributed data storage network to Ardor’s blockchain ecosystem – which, of course, also can be monetized. This is already built into the platform. The first archival node service provider will be Jelurida, but competition is welcomed.

Smart Blockchain

IGNIS lives on and communicates with this full network. It’s part of a scalable platform; Ardor, the advanced EXISTING BaaS platform, which allows transactions to be sent across the full network of child chains, globally. For example, an asset that is issued on Ignis will become instantly tradeable on all child chains that support the AE. Be they business token child chains or simple gateway child chains with tokens pegged to other cryptocurrencies or a bank/government-backed fiat coin, like DKK, EUR, USD, YAN, which you can deposit/withdraw directly to your bank account. On top of this, Asset tokens can be issued with their own unique rules set and specified- like, if they can be traded by all, or only by selected accounts, pre-approved by the issuer of the asset, or tagged in the blockchain as KYC/AML/CTF compliant accounts. Also, Ignis currency tokens (MS-coins) can be traded between child chains. Whatever you do, you can scale it. Whatever you do, it is in your control, finally.

I think that the Nxter Magazine should soon begin talking about use cases. Or about building commercial applications on the public blockchain. Maybe we could even run a contest! Describe a use case that solves a problem for you, and win!

It could be a lot of fun. Those that win the contest by vote, could get an advisory board, some initial funding, marketing and possibly a partnership arrangement with core Nxters. Nxt, IGNIS, and Ardor are supposed to solve real problems, you know, and the tech is capable of it. As IGNIS and ARDR appreciate in value, and with our sponsorship with Jelurida we *could* make this happen. Follow, learn about Nxt and Ardor, sign up for the news. Maybe we will make such a contest. Until then, feel free to post ideas for use cases in the comment field. Here’s why:

Use Cases

One of the most important aspects of Ignis is what it offers to the developer; e.g. businesses, local societies and even to national governments. All the advanced basics of connecting your use case to the blockchain are covered. Tested, reviewed and approved in the wild, Ignis (and the NXT and Ardor platforms) offers working executable secure inbuilt smart contracts, that developers can combine into the use cases he/she/the customer wants, as easy as with Lego bricks, with the API.

Right off the bat, Ardor is a well-prepared infrastructure of an entire economic system, with all its twists and turns, an infrastructure built on the blockchain, which is ready to go global on January 1st.

New GUI’s, apps and Dapps (decentralized apps) are expected to emerge:

Bitswift:

The child chain infrastructure seemed to solve all of the problems we were looking at, blockchain bloat, reducing fees, fast confirmations, everything we want it comes with to start building on.

Our rewards network is built on top of this blockchain technology which ensures stability, reliability and transparency, while maintaining exceptional performance.  

Dan Charbonneau, CEO of CBT Nuggets:

[Our] learners will buy training content with crypto and consume the content. We’re developing a cryptocurrency to be deployed as an ARDR child chain that will provide a financial incentive to learning. There are quizzes throughout the content so you can prove you learned the material. When you answer the quizzes correctly, 30% of your purchase price is returned to you. In addition, everything you learn is stored in the blockchain so we will maintain a lifelong record of learning for you.

When you interview for a job, you’ll be able to show the interviewer everything you’ve learned. The transcript will of course be private only for you and shared with the people you choose. The value of our cryptocurrency will be pegged to ARDR on a 1-to-1 basis. The initial launch will be with 50M of the new cryptocurrency paid for with 50M ARDR. The currency will be redeemable on a 1-to-1 basis for ARDR so it has value out of the gate.

I’m hoping this changes education worldwide, providing greater access to quality content and adding competition and the principles of the free market economy to education at all levels.

Alex Pfeiffer, University of Danube – Center for Applied Game Studies:

As we talk on a daily basis with Jelurida (…) at the moment I am 100% sure about doing the following “proof of concepts”. I can speak about my plans but I don’t like to reveal any partners before the ink is dry ;).

Doing my research for several months I switched all my developing plans first from Ethereum to Ethereum Classic and finally decided to fully go on Nxt and later Ardor for my plans regarding setting up new ecosystems.

I also decided to work with Ardor and Nxt for a very simple personal reason. I am economist, social scientist, game designer and conceptional developer. I am not! a “real” technican. Working with Ardor gives me the chance to understand most of the stuff the tech people are doing with it and it enables me to chance things and not crashing the system.

Adel:

Adel is built on the Nxt platform which has numerous features that will be extended to the Adel ecosystem. [Adel] will move to the Ardor platform, once it is deemed suitable. With this foundation of advanced blockchain features, the Adel ecosystem can focus on project development, best-in-class business practices, and an efficient and self-sustaining community. Adel will continue to capitalize on the features of Nxt and Ardor as both evolve.

So, What Is Next?

The “Bitcoin-thing: transferring money, is one use case of the blockchain; but Ignis and Ardor bring ALL the Blockchain 2.0 ideas to life. Ideas like running secure proven smart contracts on a scalable decentralized blockchain infrastructure, not with the old energy-wasting PoW algorithm but an energy efficient and green 100% PoS algorithm.

You can build decentralized applications with little coding experience on Ignis. Run your own business on Ignis, even create a DAO. Or with Ardor you can get your own child chain, it’s scalable, connected to the network. The impact and transformative nature of the changes to businesses and governments that the Ardor / Nxt / Ignis blockchains bring are unimaginable.

To old Nxters, this is not news. But it must be said: on January 1st, 2018, Ignis, Bitswift and Ardor will launch. Almost everything envisioned by the great, early Bitcoin (and Ethereum) blockchain visionaries will be doable and live with Ignis and Ardor. One can only hope that the launch on Jan 1st will spark a disruptive network effect. And oh yes, you can be part of it! Begin by sharing this article.

Learn about the utilities of Nxt and Ardor, and apply it to your own life and see which problems you can solve with it. Share it with us.

Exchanges

We have all seen the price of NXT and ARDR increase. I see it talked about a lot in forums, slacks, and on social media, and I spend a lot of time giving answers to folks who want to know if they will get IGNIS, ARDR and BITSWIFT if they hold their NXT on either this or that centralized exchange. Short answer: Why would you?

I have used NXT for a long time. Now Ignis and Ardor are coming. I know, for a fact, that in a not so distant future I will never have to use a centralized exchange ever again. If YOU don’t know that, you don’t know what you’re investing in. You invest in disruptive tech. Not like Jelurida is against the established system, with its taxes and governments, they will work with them all. Yet, their tech is public. Anyone can use it out of the box or build applications on top of it, change things.

Maybe NXT and ARDR exchanges like Bittrex will support the snapshot. Maybe Poloniex will, and AEX, Bitcoin Indonesia, HitBTC, Litebit, all of them – and maybe they won’t! None of these exchanges have made an official announcement about the IGNIS airdrop yet, the date is closing in, but what they all want is to get paid. By Jelurida.

UPDATE: These exchanges have announced support of the airdrop

So you ask me: Will the airdrop be supported by this or that exchange?

No one knows yet. IMHO, centralized exchanges act like they are banks, nowadays. They will list IGNIS, as well as NXT and ARDR, of course, they will, they earn millions in trading fees, but that’s not enough. Profit maximizing middlemen, some of them are, and they do not even provide an indispensable service. We do not really need them. Nxt and Ardor have inbuilt unhackable decentralized exchanges. So, to make sure you get your IGNIS and Bitswift tokens for holding NXT, and your Ardor tokens for holding ARDR, I strongly recommend you to simply claim your own private account on the network.

Create it offline, with a web client, or locally, by downloading and running the NRS client from Jelurida. The web client is the fastest and easiest, requiring only a minute or two of simple setup. Be sure to keep your passphrase safe!

Personally, I care about supporting blockchain technologies that I know will accomplish great things. I do not buy and trade shitcoins. And I do not know how many day traders, dolphins, whales, and bots manipulate the price of each coin, including NXT. That’s not my thing.

Buying cryptocurrencies seem like a (risky) get-rich scheme to a lot of people today. Even “average Joes” seem to think they know the market and that it’s probably a good time to enter. But a lot get burned. There’s no cancellation of transactions. Do your due diligence. Make your own decisions. And never invest more than you can afford to lose.

 

nxter.org/assethub

 

What is Bitcoin’s Ceiling?

Just a year ago, a post here on NXTER relayed predictions saying that Bitcoin’s value would reach or go beyond $500 by the end of 2016. True enough, it exceeded $800. This value, however, is minuscule given the fact that the cryptocurrency recently hit $16,000 per unit – a record high. The meteoric rise of Bitcoin (BTC) has also fueled massive growth in other tokens, like NXT and ARDR. Why now though? What has fueled this recent growth spurt and is Bitcoin, and the wider cryptosphere, due for a harsh correction?

NDTV indicated that the likely cause behind the surge in price is the recent announcement that CME Group Inc. and CBOE Global Markets were allowed by the main U.S. derivatives regulator to list Bitcoin futures contracts. This was seen as another step towards mainstreaming the cryptocurrency, although the rates also led to petitions for more regulations. In fact, the Nobel Prize-winning economist Joseph Stiglitz even called for Bitcoin to be outlawed. Regardless, distributed ledger technologies remain poorly understood by the average person and as a result many analysts predict Bitcoin and crypto to be a huge bubble, ready to pop at any moment.

The unfavorable view towards the cryptocurrency is understandable, considering its volatility. Just last month, Coinwire reported that the cryptocurrency breached $11,000, only for its value to drop below $10,000 just a few hours after its price surge. Nonetheless, the unpredictability of Bitcoin has not dissuaded investors from using their real-world money to purchase these virtual coins. Fortune surmises that the reason behind the continuing rise in value is largely due to increasing public awareness. The mystery surrounding it has captured the interest of many buyers, and the absence of any central regulatory body further added to its appeal.

Moreover, the increasing number of buyers caused a domino effect, which led to even more investors. It’s linked to a mindset of FOMO, or fear of missing out, with regards to trending investments. For instance, more than 100,000 people have opened new Coinbase accounts from November 22 to 24. By the end of that month, an estimated 13.1 million accounts have been created in the system.

The popularity of Bitcoin among investors lends credence to the prediction of financial adviser Tom Lee. Business Insider conveyed his forecast, stating that Bitcoin’s price will reach $25,000 within 5 years. He based this projection on Metcalfe’s Law, which estimates that the value of a network is the square of the number of users belonging to it. Lee stated that the increasing number of Bitcoin investors will also lead to an increase in the value of the cryptocurrency. He likened Bitcoin to Facebook’s growth in market value, which is now more than double the number of its users.

Still, even financial experts have made mistakes in forecasting the value of Bitcoin. Although, economist Yves Lamoreux, whose sentiments echo that of Lee’s, also pointed out the times when analysts were wrong. Tim Draper’s 2014 price forecast was mentioned as an example. Back then the analyst predicted that the cryptocurrency would have reached $10,000 by 2018, an estimation that was proven wrong recently.

The bottom line is while Bitcoin’s value and that of proven technologies like Ethereum, Litecoin, and Nxt / Ardor are looking good right now, there is no way to tell if this trend will continue in the coming months. A lot of analysts say that it’s a double-edged sword – an assumption that still remains to this day.

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. 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. 7: Ethereum (Smart Contracts)

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 Ethereum, which probably needs no introduction.

For several of the projects I’ve surveyed throughout this series, it has been rather difficult to find detailed, technical information. Ethereum has exactly the opposite problem: there is so much information available that it is difficult to distill it into a reasonable-length article without oversimplifying important ideas.

For this reason, I have chosen only two aspects of Ethereum to compare to Ardor. This installment compares its smart contracts to Ardor’s smart transactions, and the next article will compare the approaches that the two platforms take to managing blockchain bloat. There are many more topics I would have liked to cover–its plans to move to Proof-of-Stake (Casper), its state-channel strategies (Raiden and Plasma), its partnerships with large companies through the Enterprise Ethereum Alliance, and a sampling of the projects running on it, for example–but discussing even a couple of these topics in satisfactory depth is a daunting enough task. Besides, the two topics I chose offer the most interesting comparisons between the two platforms, in my opinion (but see the Ardor vs. Plasma post, linked above, for some thoughts on Plasma).

Without further ado, let’s talk about smart contracts.

Smart Contracts and “Rich Statefulness”

Ethereum’s design combines elements of Bitcoin and Nxt, and adds several novel features. Like Bitcoin, Ethereum uses a low-level scripting language to encode transactions, and it stores the contents of each block in Merkle trees whose root hashes are recorded in the block headers (more on this in the next article). And like Nxt, it tracks the current state of account balances and other account-specific data directly instead of using Bitcoin’s unspent transaction output (UTXO) model.

The most important innovations that Ethereum adds to this mixture are twofold: the ability to store scripts (contracts) in so-called “contract accounts,” which transact autonomously instead of being controlled by a user; and the ability to persist data in an account from one transaction to the next. Ethereum’s scripting language is also somewhat more powerful than Bitcoin’s language, allowing contracts to include loops and to invoke other contracts.

Combining these ideas, it is possible to create stateful “smart contracts,” which are bits of code and data that live in contract accounts and act as autonomous agents, listening for input from users and other contracts and transacting with them according to the rules defined in their contract code. The “stateful” modifier in the previous sentence is crucial: because a smart contract can have its own internal state, it is possible for one transaction to affect how subsequent transactions are processed. This is a significant departure from Bitcoin’s model, where transaction scripts only execute a single time and where the notion of the “state” available to a script is essentially limited to whether a given output is spent or unspent.

(You might have noticed that I haven’t said anything about Turing completeness. Depending on how pedantic you’re feeling, you could argue either side of the question of whether Ethereum’s scripting language is actually Turing complete. As the speaker in this excellent video explains, though, Turing completeness is a bit of a red herring anyway. Much more important is the fact that smart contracts are stateful and can transact with one another and with users in interesting ways.)

The potential applications of smart contracts extend far beyond setting conditions on the transfer of money from one account to another. Even the original white paper (which is a great read, by the way) proposed a handful of non-financial uses, including file storage, voting, distributed computing, governance of decentralized organizations, and decentralized marketplaces. Since then, developers have found plenty of other applications, too, such as decentralized messaging. And of course, the most common application of Ethereum so far, seemingly by an overwhelming margin, has been to conduct token sales for various projects.

Ardor’s “Smart Transactions”

If that list of applications sounds familiar, it might be because all but one of them have already been implemented in Nxt and Ardor as prepackaged “smart transactions.” Pioneered by Ardor’s predecessor, Nxt, smart transactions are bits of “blockchain 2.0” functionality that the Nxt and Ardor developers have made available as part of the protocol itself. They allow developers to create blockchain applications without having to write and test their own smart contracts.

In order to enable ordinary users (i.e., non-developers) to take advantage of this functionality, too, the official Nxt and Ardor wallets include a handful of features built from smart transactions. These include:

  • the Asset Exchange, where users can issue assets, trade them, and pay dividends to asset holders;
  • the Monetary System, where users can issue currencies and conduct several different types of crowdfunding campaigns;
  • a messaging system, which allows users to send each other plain-text or encrypted messages;
  • a voting system, which allows users to conduct polls by account, account balance, asset balance, or currency balance;
  • an integrated coin shuffler, which can afford users a degree of privacy by obscuring their transaction histories;
  • a decentralized data store, which can record the hash of a file permanently on the blockchain and, optionally, record the file itself permanently in special archival nodes;
  • a decentralized marketplace, where users can buy and sell goods and services peer-to-peer;
  • a new Coin Exchange (Ardor only), where users can trade child-chain coins directly for one another; and,
  • a number of advanced features, such as phased transactions, which allow users to set constraints on when and how other transactions are executed, and account properties, which can be used to associate arbitrary data with an account.

These are not the only applications that can be built from smart transactions, of course, but they do illustrate the breadth of what can be achieved with them. All of these features, plus a few more, will be available on Ignis, Ardor’s first child chain. Creators of other child chains will have the option to implement as many of these features as needed to suit their projects.

I’ve heard several analogies to describe smart transactions, but my favorite is that they are like Legos, while smart contracts are like clay: the former don’t provide the same degree of control over the finer details, but they are quicker and easier to use than the latter, and can still be combined to form some quite impressive final products.

The analogy isn’t perfect, of course. A strong argument for smart contracts is that it is possible for potentially all of the business logic of a decentralized application (Dapp) to be recorded permanently and immutably on the blockchain, for example, whereas a Dapp built from a combination of smart transactions likely includes some external code. In the latter case, using the Dapp might require some degree of trust in the developer not to change the rules in later versions of it.

Viewed from another angle, though, this comparison hints at arguably the biggest drawback of smart contracts: the ease with which they allow programmers to make multimillion-dollar mistakes that cannot be corrected.

Security Considerations

Just about all software that is even modestly complex contains flaws, and too often these flaws make the software vulnerable to exploitation by an attacker. Smart contract developers face a particularly difficult task because the code they write is immutable, and as a result its vulnerabilities are permanent.

Unfortunately, catastrophic failures of buggy smart contracts have not been rare. The attack that froze $150 M worth of ether stored in multisig Parity wallets and the $30 M hack of that same wallet several months prior are the most recent examples to grab headlines, but they are not the first and almost certainly not the last. For an overview of some common vulnerabilities and analysis of several real attacks, including the infamous DAO hack, I strongly recommend this excellent paper by three researchers from the University of Cagliari.

It is worth noting that the Ethereum protocol and the Ethereum Virtual Machine (EVM) were not responsible for any of these attacks. Ethereum’s supporters sometimes point this out, arguing that Ethereum itself is quite secure, and all that is needed is for developers to write better smart contracts. In a literal sense they’re right, of course: in all cases, Ethereum did what it was supposed to do, and ultimately the blame lies with smart contract developers.

But personally, I wonder whether this assessment is too quick to absolve Ethereum, and whether the problem might run a bit deeper than just a few buggy smart contracts. For now, anyway, it seems to me that Ethereum’s fundamental predicament is that it gives programmers tremendous power, but insufficient tools to use that power safely.

Developers’ ambitions almost always exceed the level of complexity that they can achieve while keeping their code perfectly bug-free, and there will therefore be a constant temptation to make functionality a higher priority than security (this is nearly universal in software development, by the way). Immortalizing the buggy code that they produce by storing it in the blockchain, Ethereum brutally and mercilessly holds them to account for their sins.

Thankfully, there are certainly ways to mitigate the risk of writing vulnerable smart contracts. For example, it is possible to design a smart contract that can be updated by having it delegate its responsibilities to a second contract, commonly called a “library contract,” at an address that can be changed to point to a different library contract later.

This approach allows developers to patch vulnerabilities, but as a consequence, it introduces the thorny question of who is allowed to switch to a new library contract. If it is a single third-party account, then the design reintroduces some degree of trust between that account and users. On the other hand, if the developers take another approach, such as allowing a majority of users to vote in order to approve each new library contract, then there are potentially further problems to solve, such as writing a secure voting mechanism, making sure that users are sufficiently informed and engaged to vote, and preventing an attacker from doing significant damage in the time it takes to organize a vote.

Another very promising approach towards securing smart contracts is to use techniques of formal verification borrowed from mathematics. I do not know much about formal methods, so please take what I write here with a grain of salt, but I do know that it is easiest (or indeed, feasible at all) with simple programs whose proper functioning can be expressed as a set of short, simple rules. In such cases, it can be possible to prove with certainty that the program contains no bugs. Even straightforward techniques like looping and recursion can complicate the analysis significantly, though, so it is best if the program under test is as simple as possible.

Why am I droning on and on about all this? Putting these thoughts together, it would seem that the best way to write smart contracts might involve: 1) keeping them as short and as simple as possible; 2) delegating the core business logic to library contracts that can be updated if necessary; and 3) reusing libraries that have been thoroughly vetted, so as to keep the amount of new code to a minimum. If the second of these points requires that users trust the contract’s author to some degree, as is often the case, then contracts designed according to these three guidelines start to look a lot like Ardor’s smart transactions: bits of stable, thoroughly tested code that expose the most commonly needed functionality, which developers can assemble into more complex programs.

Trade-offs between Security and Flexibility

I am not suggesting that Ardor’s smart transactions can accomplish all of what Ethereum’s smart contracts can securely accomplish, nor am I even arguing that combinations of smart transactions can always emulate smart contracts. What I am saying, though, is that I think there is a natural tension between the flexibility that a platform offers and the security of the code that developers inevitably write for it.

In this view, blockchain platforms can be located on a security-flexibility continuum. Near the “security” extreme is Bitcoin, whose scripting language is deliberately quite limited in order to prevent users from locking their coins with vulnerable scripts (though this is still possible, of course). Nxt and Ardor occupy a position somewhere toward the middle of the spectrum, limiting developers to a set of predefined transaction types but including an awful lot of functionality in those types.

Ethereum’s smart contracts, on the other hand, occupy the entire spectrum. It is possible to write extremely simple, trivially secure scripts on Ethereum, and it is also possible to write more complicated scripts that contain very subtle vulnerabilities. Perhaps just as importantly, it is difficult for users to tell the difference between these cases–and unreasonable, in any event, to expect them to try. Using Ethereum safely necessarily means avoiding the “flexibility” end of the spectrum, even if it comes at the cost of introducing some extra trust between users and developers.

Finally, it is worth mentioning that Ardor offers a new feature, not previously available in Nxt, that helps it inch towards the “flexibility” end of the continuum: the ability to combine phasing conditions using Boolean AND, OR, and NOT operators to achieve primitive smart-contract-like behavior.

Briefly, phased transactions allow users to condition an underlying transaction on some event, such as approval by a certain number of specific accounts (m-of-n multisig), a vote by accounts holding a particular asset, the expiration of some amount of time (timelock), or the revelation of a secret (e.g., a hashlock). On Ardor, combinations of these phasing types can encode more complex conditions, such as, “transaction X is valid if a majority of ABC Corp.’s asset holders approve of it by date Y, unless it is vetoed by a supermajority of ABC Corp.’s board members.”

It will no doubt be possible to combine phasing conditions in ways that allow for unexpected outcomes, possibly including theft or loss of funds. But the advantage over smart contracts in terms of security is still there, I would argue, since developers can focus on making sure the business logic of the transaction is sound, without having to worry about low-level bugs like race conditions. And of course, the drawback of offering less flexibility than a smart contract is still there, too.

Conclusion

With a protocol defined by a set of prepackaged smart transactions instead of a low-level scripting language, Ardor will probably never be able to offer developers as wide a range of possibilities as Ethereum does, at least in cases where everything must be done on-chain for minimal trust between parties. On the other hand, writing nontrivial contracts that follow security best practices might well require additional trust between users and developers anyway. And of course, Ethereum users ultimately have to trust the authors of smart contracts not to have made any mistakes and to have duly scrutinized and tested their code in order to make sure of it.

Naturally, you might say the same thing about any software, including Ardor’s smart transactions, but there is a key difference: there is simply so much more code running on Ethereum. Nxt has been open-source since its inception, providing ample opportunity for peer review, and Ardor’s code, which builds on the Nxt codebase, will be opened soon. Moreover, each new change to the protocol has been vetted thoroughly on a public testnet before being officially released. The same ought to be true of each and every smart contract, but with so much code being written, it seems like there are inevitably more opportunities for bugs to slip through into production.

In any event, I suspect that the degree to which most successful Dapps will rely on immutable code is still an open question. If access to an immutable database and a handful of simple operations on that data are sufficient for most applications, then Ardor’s smart transactions seem to me to have an obvious advantage over smart contracts. If, in contrast, the notion that “code is law” turns out to be essential to the viability of most Dapps, with each Dapp requiring most of its unique code to be recorded on the blockchain in order to be truly trustless, then Ethereum’s approach is probably superior.

I expect that there will be real-world applications that suit each platform. But I also wonder whether it will eventually become clear that one of the two approaches best handles a sizable majority of applications. Which approach will ultimately “win” is not at all clear to me, but I suspect that the deciding factor will be users’ judgments of the degree of trust that each case requires. And since the entire appeal of blockchain technology is that it allows users to transact with minimal trust, I’d say that outcome would be quite appropriate.

Thanks for reading! If you enjoyed this article, be sure to read the next part of the series, which compares the ways that Ardor and Ethereum cope with blockchain bloat.


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

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.

 

Ardor vs. the Competition, Pt. 5: Stratis

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 Stratis, a blockchain-as-a-service platform based on the Bitcoin protocol.

Stratis

The goal of the Stratis project is to enable businesses to create their own customizable blockchains, choosing from a set of prepackaged features. Additionally, the Stratis Group, which guides the development of Stratis, will offer consulting services to help businesses find ways to use blockchain technology effectively, and presumably will also help them configure and deploy custom blockchains on the Stratis platform.

Put this way, Stratis sounds an awful lot like Ardor. But in most of the details–to the extent that details about Stratis are available, anyway–the two platforms are quite different. More on those differences in a bit.

Currently, the Stratis platform comprises several parts:

  • NBitcoin, a comprehensive Bitcoin implementation in C# inspired by Bitcoin Core;
  • NStratis, a fork of NBitcoin that adds a proof-of-stake mining algorithm and an alternative proof-of-work algorithm;
  • the Stratis Bitcoin Full Node, which can run on either the Bitcoin network or the Stratis network, and which serves as the basis for the rest of the platform;
  • the Breeze Wallet, a simplified payment verification (SPV) wallet for both Bitcoin and Stratis that implements TumbleBit to make transactions private; and,
  • the Stratis Identity module, which allows third parties to attest to the identity of the person controlling a Stratis account.

Note that most of these components are currently in alpha.

Particularly noteworthy in this list is the integration of TumbleBit into the Breeze Wallet. The TumbleBit paper is rather dense; if you’re interested in the details, I recommend instead this excellent presentation by two of the authors. In a nutshell, TumbleBit uses one-way payment channels to transfer funds from a set of payers to an intermediary called the Tumbler, and from the Tumbler to a set of payees, without any of the parties having to trust one another. The key innovation over other payment channel implementations is that TumbleBit uses blind RSA signatures in a clever way to prevent the Tumbler from knowing which incoming transaction maps to a given outgoing transaction. If many accounts are transacting through the Tumbler, then it is impossible to trace the funds in an output account back to the input account that sent them. Not even the Tumbler can link the two accounts.

Stratis’s Breeze Wallet provides TumbleBit functionality for both Bitcoin and Stratis, making it useful to a much larger audience than would be the case if it worked only on the Stratis network. Moreover, since the TumbleBit protocol uses off-blockchain payment channels, it is possible to make many payments through the Tumbler in approximately the same amount of time as it takes to make a single payment.

The Stratis Identity module is still at the proof-of-concept stage, but it is functional nevertheless. Users can log into their Microsoft, Google, or LinkedIn accounts using the Stratis Identity mobile app, and these services will notify Stratis of the successful login. A special account owned by Stratis then records an attestation to the successful login by hashing the corresponding personally identifiable information (e.g., name and email address) and storing it on the Stratis blockchain.

An attestation by Google that a person owns a particular Gmail account is perhaps not the most useful identity service, but it is easy to see how the same mechanism could be used to prove ownership of some piece of information that is much more difficult to verify. For example, a government agent might attest that somebody presented a valid photo ID, together with a name and address. If a user can provide the name and address that match the hash on the blockchain, that would probably convince a service provider that the user also owned the corroborating photo ID, since the government agent attested to all three pieces of information together.

TumbleBit integration in the Breeze Wallet and the Stratis Identity module are two examples of the kinds of features that Stratis intends to offer on their platform. I’m not completely sure I’ve grasped the overall architecture of Stratis, but from what I can understand, the idea is for the Stratis blockchain to delegate the backend processing for each new feature, such as TumbleBit and Stratis Identity, to a dedicated set of masternodes. For example, the upcoming Breeze Node–not to be confused with the Breeze Wallet, which uses SPV instead of requiring a full node–will be a masternode that serves as a Tumbler. Similarly, there are plans to build masternodes that process Stratis Identity transactions, though I don’t really know what that means and can’t find any details.

Finally, it is worth mentioning that the Stratis team has planned several other features, most notably a way to deploy sidechains anchored to the Stratis chain. My understanding is that this will be the main mechanism that Stratis uses to provide customizable, private blockchains to clients.

Unfortunately, I haven’t been able to find any details about how sidechains on Stratis will work. The Stratis white paper refers to Blockstream’s sidechain paper, but that is the only hint I have found so far about Stratis’s design. In particular, it is not so easy to securely and trustlessly transfer value between two blockchains without having at least some of the miners on each chain validate all transactions on both chains. The details, including how the sidechain protocol handles forks and reorginzations, are crucial in order to evaluate how secure the mechanism is.

Even supposing that transfers between the Stratis chain and sidechains are secure, there is also the matter of the security of the sidechains themselves. The Stratis white paper says in several places that the Stratis chain will somehow provide security for its sidechains, but it doesn’t explain how that will work. Typically, sidechains are completely independent and must secure themselves.

Compared to Ardor

With Ardor, on the other hand, the parent chain does provide security for each child chain.

In fact, this is one of the most important differences between Ardor’s parent-chain/child-chain architecture and typical sidechain implementations. Unfortunately, without more technical details from the Stratis team, it is impossible to do a proper comparison between their design and Ardor’s approach.

One comparison that we can do is between Stratis’s TumbleBit feature and Ardor’s Coin Shuffling feature. (Note that Coin Shuffling will not be available on the Ardor chain itself, but it will be available on Ignis, the first child chain, and other child chains can also choose to support it.) This feature is Nxt’s implementation of the CoinShuffle algorithm, which allows a group of users to trustlessly agree to transfer a fixed quantity of coins from their (input) accounts to a set of output accounts, one per input, without any user being able to know which of the other users controls each of the other output accounts. The algorithm is not very complicated, and section 4.2 of the CoinShuffle paper gives a good overview of how it works.

I don’t claim to be an expert on either algorithm, but the TumbleBit approach seems to me to have a couple of advantages over CoinShuffle. Because it uses off-blockchain payment channels, it is potentially capable of scaling to a high transaction rate in addition to adding a measure of privacy to payments, addressing two problems at once. Also, if the goal is to prevent an observer from noticing correlations between several payments–which might leak information about a business’s customers or supply chain, for example–it would probably be more convenient to make the payments back-to-back from the same account via TumbleBit instead of having to first shuffle each payment to a new account.

On the subject of identity verification, I think the Stratis Identity module is an interesting proof of concept, but in my opinion Ardor provides a much richer set of tools for identity-related services. While a service like Stratis Identity can be built relatively easily on any blockchain, Ardor offers a couple of unique features that could extend such a service for some interesting applications.

On Ardor, identity validators will be able to attest to the identities of account owners using Account Properties. These are arbitrary bits of data that can be permanently associated with an account on the blockchain, rather like attestations in Stratis Identity. One novel feature that Ardor will add, though, is the ability to issue assets that can only be traded by accounts that have a specific property set.

In cases where government regulations require that asset issuers know who is purchasing their assets, this feature will allow issuers to restrict trading of their assets to accounts whose owners’ identities have been verified by compliant identity providers. This level of control will hopefully help put blockchain-based securities on a firmer legal foundation, and will make it easier for asset issuers to comply with the law.

Even apart from regulatory compliance, asset issuers will probably find other uses for this feature. For example, a club or other private organization could express eligibility requirements for membership as a set of required account properties, issue an asset that only eligible accounts could obtain, and then use the asset to pay dividends to or conduct polls of members.

Some Thoughts on Marketing

Even having read this far, you might still be wondering what exactly the Stratis platform is and how it works. To be frank, I have found myself asking these questions too, even after many hours of reading about Stratis. At the risk of speaking perhaps a bit too close to the edge of my knowledge, I think it might be helpful to compare and contrast the marketing efforts of Jelurida and the Stratis Group in order to shed some light on why it is hard for me to answer these very basic questions.

Reading the Stratis website and the white paper (linked above), I got the distinct impression that, to be blunt, those resources weren’t really written for me. The language they use reminds me of how the salespeople at my company talk, and I learned a while ago that engineers and salespeople tend not to understand each other very well.

I read that Stratis offers “simple and affordable end-to-end solutions” to “streamline and accelerate [my] blockchain project development”; that it is a “powerful and flexible blockchain development platform designed for the needs of real-world financial services businesses and other organizations that want to develop, test and deploy applications on the blockchain”; and that its “one-click process means that new chains can be launched with unprecedented speed, tailored for the needs of the organization”; but I still don’t really understand what any of this means, much less how Stratis will accomplish these things.

This type of language conveys precisely zero information to me. Without technical details, I am completely, hopelessly lost. I know that there are plenty of people who are fluent in business-speak, though, and those people can probably read the Stratis white paper and come away with a decent, if very high-level, understanding of what the company plans to do. In contrast, it took me multiple passes through the white paper before I began to grasp the big picture, and I’m still not sure I have it right.

The Ardor white paper, on the other hand, contains substantial technical detail about how Ardor works and what distinguishes it from other blockchain platforms. It is obvious, both from its content and how that content is organized, that engineers played a significant role in writing it. Upon completing my first pass through it, I understood pretty well what problems Ardor solves and how it solves them.

The point I’m trying to make with this comparison is that business-minded people and technically-minded people often speak different languages, and the marketing materials that the Stratis Group and Jelurida have created seem to reflect this difference. Personally, I found it extremely frustrating to find so little technical substance in Stratis’s resources, and this frustration has probably prevented me from really understanding Stratis.

Conclusion

Is my assessment of Stratis too harsh? Maybe. I do think that TumbleBit is an interesting piece of technology, and it seems smart for the Breeze Wallet to implement it for both Stratis and Bitcoin. Moreover, if we drop the white paper’s contention that the Stratis chain will secure its sidechains, and instead assume that sidechains will be responsible for their own security, then I can use my imagination to fill in enough of the gaps to come up with at least a rough mental image of what Stratis will look like when it is complete.

This mental image, though, is basically a direct competitor to Lisk. Sure, Stratis is based on .NET and the Bitcoin protocol instead of JavaScript and Lisk’s predefined transaction types, and the feature sets that the two teams intend to offer don’t overlap perfectly, but essentially both projects aim to provide a central, public blockchain and a set of tools for easily creating sidechains on it. Both projects are in rather early stages of development, too, and for this reason it can be difficult to find technical details about them.

Ardor is quite different. Built on the Nxt codebase, it is already far more mature than Stratis, despite not having launched on its mainnet yet. Its parent-chain/child-chain architecture achieves the goal described in the Stratis white paper–a means for businesses to create customizable blockchains without having to worry about securing them–better than existing sidechain architectures. And the rich variety of features that Ardor already supports will take quite some time for Stratis to emulate.

Perhaps just as importantly, Jelurida and the Nxt community have done a great job of making technical information about Ardor and Nxt publicly available. This information lends credibility to the Ardor project and strengthens the community. In my opinion, it is what separates true marketing from hype.


Try Ardor on testnet

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.

Ardor vs. the Competition, Pt. 3: IOTA

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 IOTA, a distributed ledger that doesn’t use a blockchain.

Why Compare Ardor and IOTA?

At first blush, IOTA is about as different from Ardor as a distributed ledger can be. It uses a directed acyclic graph (DAG), which its developers call “the tangle,” to represent the history of transactions, instead of storing transactions on a blockchain. It is intended to be used primarily for machine-to-machine microtransactions on the Internet of Things (IoT), a vision enabled by the fact that IOTA requires no transaction fees. And it doesn’t (yet) support the “blockchain 2.0” features that form a core part of Ardor’s appeal. On the surface, it doesn’t really look like a competitor to Ardor.

So why include IOTA in a series entitled “Ardor vs. the Competition”?

As I’ve mentioned before, my main interest with this series is in exploring different distributed ledgers’ approaches to scaling, and this is where the IOTA community has made some extraordinary claims. As I learned more about IOTA to better understand how it scales, I eventually came to the conclusion that IOTA and Ardor offer complementary (or more bluntly, opposite) solutions to the scaling problem:

Ardor dramatically reduces blockchain bloat but requires all nodes of the network to agree about the strict ordering of transactions; whereas IOTA achieves potentially higher throughput by relaxing the consensus rules a bit, allowing temporary discrepancies between transactions, but faces a significant challenge in coping with the growth of the tangle. These tradeoffs, plus what I learned about the security of the tangle, seemed interesting enough to warrant a post in this series.

If you aren’t convinced, though, please still check in next week!

After this post, I plan to shift my focus away from scalability and towards features and market fit. Stratis, Ark, and Waves are on the agenda, but I’m not sure of the order, yet.

The Tangle

Without a doubt, the key distinguishing feature of IOTA is the tangle.

IOTA’s other unique features, such as its lack of transaction fees, the fact that transactions are not strictly ordered but still eventually consistent, and the notion that (some) spam actually increases the throughput of the network, all stem directly from the way the tangle works.

For this reason, and also because I want to sidestep at least some of the recent controversy surrounding the IOTA project, I will try to focus primarily on understanding and evaluating the tangle itself, rather than picking apart the details of IOTA’s specific implemetation of it.

The tangle is a directed acyclic graph whose vertices represent individual transactions, and whose edges represent “approvals” of previous transactions. Each time a node submits a new transaction to the network it must choose two previous transactions to validate, which it references in the new transaction it submits. As the new transaction permeates the network, each node adds it to its local copy of the tangle, with one edge pointed to each transaction that the new transaction approved.

I tried my best, but this description is probably confusing. This diagram should help. Each square represents a transaction, and the arrows that point from each transaction to two others represent that transaction’s approval of the two earlier ones. The genesis transaction is somewhere far off the left side of the diagram, and the newest transactions, called “tips” in the white paper, are on the right side, shaded in gray.

What does it mean to validate, and hence approve, a transaction? Conceptually, the node doing the validation must start at the two transactions that it is validating and walk all paths back to the genesis transaction, ensuring that it never encounters a contradiction (e.g., double-spend, insufficient balance, or the like). If there is a contradiction, it chooses another pair of transactions to approve, knowing that no other node would ever approve the transaction it is submitting if it had approved a set of inconsistent transactions.

Notice that this means that each new transaction not only directly approves each of the two transactions it has chosen to validate, but also indirectly approves the transactions that those two approve, and the transactions that those transactions approve, and so on all the way back to the genesis. This is part of the basis for “eventual consensus” on the tangle.

In case you’re wondering about the computational burden of doing this validation, in practice it can be optimized substantially. Notice from the figures on this page that as you walk the tangle from the tips (far right) towards the genesis, you eventually reach a point past which all transactions are (indirectly) approved by all tips. In these figures, transactions approved by all tips are colored green. You could, therefore, cut the tangle across arrows that point to green transactions, validate the paths from those particular green transactions to the genesis a single time, cache the results, and from that point forward only validate from your new transaction back to those green transactions. This optimization saves you the time of validating the entire tangle every time you submit a transaction, and also allows the tangle to be pruned. More on that below.

Consensus

One very interesting feature of a tangle-based ledger like IOTA is that nodes that receive new transactions from their peers don’t have to immediately validate them. In fact, the tangle can temporarily contain contradictory transactions. Eventually, though, a node must decide which of the contradictory transactions to approve (possibly indirectly) as it adds a new transaction.

How does it choose between conflicting transactions? Assuming that each transaction is valid if considered separately, then the short answer is that a node could choose to approve either one. It has an incentive to approve the one that the rest of the network will build on, though, so that its own transaction will eventually be approved, too. Most of the nodes on the network are assumed to run the reference algorithm for selecting transactions to approve, so in the event of a conflict, a node has an incentive to choose the transaction that the reference algorithm selects.

In order to understand the reference algorithm, it is important to first understand the concept of the cumulative weight of a transaction.

Each node that submits a new transaction must do some proof-of-work (PoW), which determines the “own weight” of the transaction. The cumulative weight of a transaction is then its own weight plus the own weights of all transactions that have directly or indirectly approved it. In a general tangle the node can decide how much work to do for a transaction, but in IOTA all transactions require the same PoW and thus have the same own weight. As a result, the cumulative weight of a transaction is proportional to the number of other transactions that directly or indirectly approve it.

What, then, is the reference algorithm? The author of the white paper calls it Markov-Chain Monte Carlo (MCMC, see section 4.1), which is a fancy way of saying that it is a random walk along the tangle that favors paths with greater cumulative weight. This post is already getting long, so I’ll skip the details. Suffice it to say that, when there are conflicting transactions, the MCMC algorithm resolves the conflict by tending to choose whichever transaction has the greater cumulative weight behind it. Eventually, one subtangle becomes dominant and the other is orphaned. This is analogous to the mechanism that blockchains use to resolve forks, and the cumulative weight of a transaction in IOTA is a rough measure of its finality in the same way that adding blocks to a blockchain confirms previous transactions with greater and greater certainty.

By the way, the fact that nodes don’t immediately need to validate each new transaction received from their peers has big implications for performance. Each node does less work this way, validating transactions only when it submits a new transaction, and taking for granted that transactions that are indirectly approved by all tips have already been validated by the rest of the network. Also, validations run in parallel across the network, as different nodes choose different subsets of transactions to approve.

Security

So far I have mostly just regurgitated the information found in the IOTA white paper. The issue of the security of the tangle, on the other hand, is where things get a lot more interesting. While I definitely recommend reading the analysis in the white paper of different attacks on the tangle–and the rest of the white paper, for that matter, because it is very well written–I won’t discuss most of that analysis here.

Instead, I want to focus on the most obvious threat, which is a 51% attack. The IOTA devs actually refer to it as a 34% attack, for reasons that I’m not sure I understand. I suspect it’s because an attacker who waits for a fork to occur naturally only needs enough hashpower to out-compute the nodes on each branch of the fork–i.e., more than 50% of the rest of the network’s hashpower. Anyway, the exact number isn’t important, and for the remainder of this article I will use the term “34% attack.”

With IOTA, a 34% attack would look roughly like this. An attacker issues a transaction that spends some funds, represented by the rightmost red dot, then computes (or perhaps has precomputed) his own “parasitic” subtangle, which anchors to the main tangle somewhere upstream of his transaction and which contains a double-spend transaction, represented by the leftmost red dot. His goal is to add enough cumulative weight to his parasitic tangle to convince the MCMC algorithm to orphan the main tangle and follow the parasitic one.

Hopefully, the analogies to the blockchain are clear so far, because there is one more important one. Like a PoW blockchain, the tangle is secured by the current hashpower of the network, since this hashpower is what adds cumulative weight to the legitimate tangle. Unlike a PoW blockchain, though, nodes on IOTA only do PoW when they submit transactions. The security of the tangle, therefore, depends only on the transaction rate and the amount of PoW per transaction. Take a second to let that idea sink in because it is absolutely central to understanding the security of the tangle.

Because the IOTA network is currently small and the transaction rate is low, the IOTA team has established a single trusted node, called the Coordinator, that is ultimately responsible for deciding the current state of the tangle. Its purpose is to protect against 34% attacks, among other attacks. I’m not going to spend any more time on it, but I encourage you to read this critique and the devs’ responses, and draw your own conclusions about whether IOTA can be called decentralized while running under the supervision of the Coordinator.

Let’s see if we can come up with an order-of-magnitude estimate of how secure the network could be without the Coordinator. A recent stress test achieved well over 100 transactions per second (tps) on a small test network. The team suggested that 1,000 tps is achievable. To be generous, let’s assume that IOTA will eventually scale to 10,000 tps. I don’t know what the current PoW requirement on IOTA is, but let’s suppose that the average IoT device is approximately a Raspberry Pi and it runs at 100% CPU for 10 seconds to do the required PoW. Again, I’m trying to be generous; many IoT devices are considerably less powerful than a Raspberry Pi, and pegging the CPU for 10 seconds for each transaction would probably be a dealbreaker.

With these assumptions, we conclude that the average computational power securing the network is roughly 10,000 x (# of computations by Raspberry Pi in 10 s) per second, or equivalently, 100,000 times the computational power of a single Raspberry Pi. There are a lot of nuances to properly benchmarking computers, but we’re not concerned about factors of two or three–we’re just going for an order-of-magnitude estimate–so we’ll use some numbers I found on the internet.

A Raspberry Pi3 can achieve hundreds of MFLOPS (megaflops, or millions of floating-point operations per second), while high-end GPUs clock in at thousands of GFLOPS (gigaflops, or billions of FLOPS), a factor of 10,000 greater computing power. So in our hypothetical scenario, an attacker with ~10 GPUs could out-compute the entire network. Throw in another factor of 10 because I was being sloppy–maybe integer operations are a bit slower on the GPUs than floating-point operations, for example–and you still only need 100 GPUs to execute the attack.

I’m sure there are plenty of holes to poke in this analysis. Perhaps IOTA won’t run on devices all the way at the edge of the network, for example. Instead, it might run on the gateways and routers that those IoT devices connect to, which are typically much more powerful.

Still, the point I’m trying to make is that PoW successfully secures blockchains like Bitcoin and Ethereum because it isn’t tied to the transaction rate, or any other factor besides the economic value of the network. As the value of the mining reward (in fiat currency) increases with the price of Bitcoin, miners add more hardware and consume more electricity to mine it. The economic incentive to mine ensures that the amount of hashpower securing the network increases with the network’s monetary value.

With IOTA, in contrast, there is no economic incentive to secure the network. Moreover, the hashpower securing the network is tied directly to the transaction rate, which naturally has some upper limit dependent on bandwidth and network topology.

On this last point, the IOTA developers have made a creative argument, not included in the white paper, that bandwidth limitations and network topology actually improve the security of the network. I haven’t found an official statement of it anywhere, but after some digging I stumbled upon this Slack conversation, which is the most complete defense I could find.

Essentially, one of the IOTA developers (specifically Come-from-Beyond, a.k.a. Sergey Ivancheglo, possibly a.k.a. BCNext, also one of the original creators of Nxt), argues that the IOTA network will consist of IoT devices peered exclusively with their nearest neighbors in a meshnet topology, and that an attacker will not even have the option of peering with more than a very small number of devices on each such mesh. That is, the vast majority of devices will not be accessible from the internet or some other “backbone” of the network, and the only way to send messages to them will be through the mesh of other devices.

The general idea is that the mesh as a whole will be capable of achieving a high throughput, but each individual link in the mesh has a low enough bandwidth that an attacker would easily saturate it by trying to add enough transactions to convince the network to follow his parasitic subtangle. Since the attacker only has a few entry points into the mesh, he saturates all of them before his parasitic tangle accumulates enough weight for his attack to succeed.

I’ll let you draw your own conclusions about this argument. I personally don’t think the IOTA team has made enough details public to thoroughly evaluate it.

Speaking of bandwidth limitations, let’s talk about scaling.

Scalability

Because each node must validate two other transactions before submitting its own transaction, the IOTA team likes to point out that spam actually tends to make the network more efficient. Other members of the IOTA community get carried away with this point, sometimes even making the absurd claim that IOTA is “infinitely scalable.”

Every node on the IOTA network must eventually receive every transaction in order to maintain a globally consistent tangle. Broadcasting transactions to remote nodes takes time, though, and if the transaction rate is high enough that a node receives a lot of transactions from nearby nodes before it receives the next transactions from distant nodes, the MCMC algorithm will continue to select tips submitted by nearby nodes. Eventually the tangle splits, with only nearby nodes transacting on the local copy of the tangle and remote nodes transacting on their own, divergent copy.

So bandwidth and network topology must place some limitations on the transaction rate of IOTA if the tangle is to be consistent across the entire network. We will have to wait for more stress tests to learn what these limitations are.

Additionally, like all distributed ledgers, IOTA must grapple with bloat. Each transaction on IOTA is approximately 1.6 kB in size, so a transaction rate of 100 tps would grow the tangle at a rate of 160 kB per second, or about 14 GB per day. Needless to say, that’s an unrealistic storage requirement for an IoT device.

IOTA currently solves this problem by taking periodic snapshots of the tangle, which map its current state into a new genesis transaction, allowing the transaction history to be pruned away. In the limit of very frequent pruning, a node would only have to store enough of the tangle to be able to run the MCMC algorithm.

Syncing a new node with the network is a different story, though. Either the node must download the latest snapshot from a trusted peer, or it must start at the original genesis transaction and work its way forward through the entire tangle. There is no way to trustlessly and efficiently join the network.

Finally, it’s worth noting that the IOTA team has proposed a type of horizontal partitioning of the tangle that they call a “swarm,” where many nodes together store the complete tangle but no one node stores all of it. Unfortunately, there aren’t many details yet on how this works.

Compared to Ardor

So what does any of this have to do with Ardor?

In my opinion, there are two main comparisons to draw, namely on the issues of security and scalability.

Regarding security, it isn’t clear to me that IOTA could possibly reach a high enough transaction rate to be considered secure without the Coordinator, given the monetary value of even the current network, without choosing a very high PoW requirement.

Ardor, in contrast, has the advantage that its child chains are all secured by the single parent chain.

A “small” child chain wouldn’t need a trusted node like IOTA’s Coordinator to protect it because consensus is established by the entire network and recorded (via hashes of child chain blocks) by forgers on the parent chain.

On scalability, IOTA and Ardor both currently share the requirement that each node of the network process all transactions. With IOTA, this simply means adding transactions to the tangle, which is computationally cheap, whereas, with Ardor, every node must validate every transaction. Moreover, the clever design of the tangle ensures that the confirmation time for a transaction actually decreases as the network gets busier. I would not be surprised to see IOTA achieve higher throughput than Ardor as both networks grow.

On the other hand, IOTA faces a tremendous challenge in combating tangle bloat if it is ever to achieve hundreds of transactions per second, whereas Ardor has largely solved this problem.

Finally, it’s worth noting that a proposal on the Ardor roadmap would delegate child chain transaction processing to dedicated subnets of the network. This would potentially achieve a computational gain similar to IOTA’s “swarming” proposal, possibly allowing similarly high throughput.

Final Thoughts

If you’ve read this far (thank you!!) and were already familiar with IOTA, then you’ve undoubtedly noticed that I left out a lot of details, including its homebuilt hashing algorithm, the deliberate flaw in this algorithm that Come-from-Beyond included as a copy-protection mechanism, the use of ternary encoding, and the mysterious Jinn processor that will provide hardware support for IOTA in IoT devices. In the course of my research, I’ve formed fairly strong opinions on all of these things, but I was reluctant to share them here for two reasons.

First, I don’t have sufficient information to make objective statements on these issues. I’m not a cryptographer, and I know next to nothing about ternary computing or Jinn. The best I could do would be to offer subjective judgments of the design decisions the IOTA team made, but that would have simultaneously weakened the focus of this article and opened it to criticism from people who have made different subjective judgments.

Secondly, and more importantly, I’m more interested in the fundamental concepts behind the tangle than IOTA’s specific implementation of it. Regardless of whether IOTA succeeds or fails, the tangle is a beautiful idea and deserves all the attention we can muster.

So what can we say about the tangle, then? While I’m positively enamored with the elegance of its design and the nuances of its consensus mechanism, at the end of the day I’m afraid I’m quite skeptical of its suitability for the Internet of Things. Drop that aspect, increase the PoW requirement by several orders of magnitude, and find a way to tie the PoW threshold to the monetary value of the network without cutting ordinary users off from their funds, and I think the tangle has tremendous potential as a distributed ledger.

The last missing piece is how to cope trustlessly and efficiently with bloat, a problem that Ardor have solved extremely well. Perhaps somebody will find a way to combine the best elements of both designs at some point in the future. A lot could happen by then, especially in cryptoland.

P.S. – I promise the next article will be shorter. 🙂