NXTER.ORG

PRESS RELEASE: Free class for beginners on Lightweight Contracts!

Lightweight contracts are now live on the Ardor TestNet! But what does this mean for the average Ardor user? There are many articles about Lightweight Contracts but the information is often abstract and hard to understand.

Fortunately, a new class on Udemy has been released that makes lightweight contracts easy to understand!

The class explains lightweight contracts at the most simple and basic level. In fact, the class is made for people with no coding background!

Here are the highlights of the course:

  • Simple introduction: Even if the student has never heard of Ardor, an introduction shows users how to set up the Ardor software
  • Step-by-step instructions: Every single step of deploying a contract is shown in detail. Anyone can do it!
  • Explanation of tools: Easy-to-understand tutorials about 2 pieces of software (Java and IntelliJ) and 2 utilities (Contract Manager and Contract Runner).
  • Examples: Not just boring academic lectures, students are guided through the process of deploying your own contracts.
  • Exercises: The final challenge of the course is deploying a blockchain lottery contract, with the full solution available.

The best part? The course is completely free with code “ARDOR-CONTRACTS”!

Caption: Screenshot from the class showing part of the contract deployment process

After taking this class, users will have a clear understanding of how to deploy lightweight contracts that can be used for any purpose, whether its businesses, non-profits, or hobbyist. Using lightweight contracts will help you turn your ideas into reality! This is your first step in becoming a blockchain developer.

The class is produced by Eric Funk, who also produced the Ardor Bootcamp class. Ardor Bootcamp is the complete overview of Ardor and shows users how to effectively use the software for any purpose. It has been extremely successful, with 2,200 students from over 100 countries. Thousands of new users and developers have been introduced to Ardor thanks to this class. Eric Funk is one of the best educators in the blockchain space and is available to create instructional videos for other Ardor-related projects.

New Ardor series on YouTube

Today, Jelurida’s Youtube channel got itself a new URL. Why should you care?

The Ardor Updates and Lightweight Contract videos were the first to be uploaded to this channel, and if you have been hyperlinking to any videos on this channel lately – note the links in your posts might stop working and need to be updated. So writes CyptoDemetrius, host of both shows and so, indisputably the biggest and unparallelled contributor to the new ArdorPlatform channel.

CryptoDemetrius started off as an independent crypto YouTuber, researching blockchain technologies and sharing what he learned. After his premiere on the youtube.com/c/ardorplatform channel (yes, that’s the new URL!), I reached out to him and asked him about his vision for the Ardor and NXT shows.

Read his story in our conversation below the first episode of ‘Ardor Updates’…

Nxter:

Congrats with the premiere!

CryptoDemetrius:

Thanks!

Nxter:

Awesome start! So, what is to expect from the series in the future?

Same format? Same sofa? Weekly or more sporadic updates?

CryptoDemetrius:

It’s exciting to see the enthusiastic response to the first episode of Ardor Updates. It has taken a lot of work behind the scenes to figure out a format for the program to feel fresh – particularly since there are already so many incredible community members providing regular updates at NXTER, Ardor.World, ANG, and several others.

The idea with “Ardor Updates” is to release a 5-minute video at the end of each month with two segments: one providing rapid fire updates on noteworthy achievements, and a second segment focusing on an alternating “main topic.” I will also do my best to get comments from the team at Jelurida on progress each month.

This format should allow newcomers and more casual blockchain enthusiasts to get a sense of what’s happening and what features make the Ardor platform so special. The description of each of these videos will always be a valuable place for viewers to find resources to continue their learning.

“You can’t get to the use case and business discussions if no one knows the key benefits of your platform, or where to go to understand how to use or build using your product.”

Over time, I’m interested in finding ways to get the community and other team members at Jelurida more involved with the format of the show. Moving forward, “Ardor Updates” could also expand to include special editions of the series whenever there are particularly newsworthy announcements or events.

Nxter:

Interesting. But you also host another series, ‘Blockchain Ardor’, that you actually started off on your own channel. Is there a future for this series as well, or will the more “educational” content be for others to create?

CryptoDemetrius:

Since July, the Ardor youtube channel release schedule has been focused primarily on the technically-focused “Blockchain Ardor” series. As a complementary resource, the first 9 parts of a written version of the Blockchain Ardor video series will be launching on the Ardor Medium publication soon. Around the same time, the new Ardor wiki with extensive API and developer documentation should launch. Furthermore, I hope to see the Ardor Blockchain Bootcamp remain free on Udemy.

This collection of developer resources lays the foundation for myself and everyone else in this community to shift gears and begin having more articulate discussions around use cases and business implications. It also means more time to begin implementing a marketing strategy that goes beyond simply explaining how this thing works. “Ardor Updates” will serve an important purpose as the key tool for communicating progress and interesting discussions around each of those initiatives.

Nxter:

You have been hanging around in the Nxt and Ardor community since the beginning of this year – you created some great introductory videos, you interacted and learned, and you also put your finger on a variety of issues we have, like the lack of easy-to-understand information, marketing, and documentation for developers.

For the readers who don’t know you at all, could you please share some insight into your background, skillset, and motivation for doing all this? How long have you been into crypto, what is your main interest in blockchain and why Nxt and the Ardor platform?

“We need to lay the foundation for businesses to feel confident building their house on top of this blockchain infrastructure because that’s essentially what Ardor is.”

CryptoDemetrius:

I come from a different background from many people in crypto – while I had an initial run-in with Bitcoin back in 2010, I didn’t truly begin educating myself more deeply on the potential (and pitfalls) until January 2017. At the time, I was working at an environmental nonprofit as a grant manager focused on financial capacity building.

I started looking back into Bitcoin during a work trip to Cambodia – it started with an article about using “excess energy” at dams to power massive mining facilities. I read more about the energy demands of Bitcoin and the mining cartels dominating the Bitcoin network. Then, I read more about the underlying technology.

I quickly got excited as I began to recognize the potential value adds this technology could have for things like sustainable rice supply chain tracking, fair timber trade certifications, carbon credit exchanges, local cooperative financial structures, and more. That said, I couldn’t reconcile the resource drain of a network operating on Proof of Work.

“It was a big deal to me that there was this community that was open to critiques in the face of having actually delivered a groundbreaking product.”

After a few more months of research, I started passively hanging around this community in October or November of 2017 when I did my first review of Ardor and NXT on the CryptoDemetrius youtube channel. Around that time, I had been releasing 3-4 reviews of different cryptocurrencies each week. While many YouTubers were bounty hunting and shilling coins, I was using my channel as a space to look at the pros and the cons of each project. For obvious reasons, many projects disliked the fact I poked holes in their claims.

To my surprise, when I released a follow-up review of the Ardor mainnet launch in January 2018 – this community was receptive to the criticisms. I was already tired of reviewing whitepaper after whitepaper and pointing out the shortcomings, so it was a big deal to me that there was this community that was open to critiques in the face of having actually delivered a groundbreaking product.

After a few more days of research and engagement with the community through the Slack, I decided to commit myself to doing a series of videos and written pieces to try to help shed some attention on the Ardor platform. As I mentioned earlier, the potential use cases for blockchain technology are plentiful. That said, a major part of the problem in cryptoland is around educating people on what each platform can (and can’t) do. You can’t get to the use case and business discussions if no one knows the key benefits of your platform, or where to go to understand how to use or build using your product. And let’s be clear – most businesses still think blockchain is a technology with no use case. If you give them a reason to doubt you, they will.

We need to lay the foundation for businesses to feel confident building their house on top of this blockchain infrastructure because that’s essentially what Ardor is. If someone hears about Ardor and its features at a conference or in an online forum, we need to be certain there is a prescribed path with guideposts and checkpoints along the way to ensure a secure journey into this new land of blockchain technology. If we want businesses or developers to use our technology, we can’t allow them to get lost on their first day.

In the past two months, there has been a massive amount of progress in developing technical resources and guides – the fruits of that labor will be on display for the community in the next several days. As each of these keystones is set in place, the time is finally arriving to shift gears and begin more public engagement around the benefits of building on this platform.

To subscribe to the channel, you know what to do, and we, at NXTER, look forward to more episodes of both the ‘Ardor Updates’ and the ‘Blockchain Ardor’ series. There is plenty to look into, plenty to analyze and pass on. Our ecosystem is seeing rapid growth alongside the upgrades that Jelurida is pushing to the Nxt users and the Ardor platform. And Demetrius can think that our community is unique because we’re listening, but also, personally speaking, I’d say that it’s rare these days to see an outsider come in, who actually cares about understanding the benefits of the tech, the vision, and the future of blockchain.

Sign up to get updates and Ardor enlightenment
We will never spam you. If you're not satisfied with our service, UNSUBSCRIBE HERE.

TOKOK Exchange Platform supports IGNIS

In the process of updating Nxter.org to reflect the latest state of our ecosystem, I have been updating myself on exchanges that have IGNIS listed – not all of them are represented on CMC.

One new exchange on the block is TOKOK, launched just months ago, July 2018. NXT and ARDR are supported (due to a community vote), and now it also got IGNIS implemented. Appreciated, of course, not least because IGNIS buyers and traders currently have limited options for choosing exchange, and a wise decision from TOKOK’s side, possibly, for the same reason.

What is TOKOK?

Let’s take a look at the information available. TOKOK is Chinese based, located in the British Virgin Islands, affiliated to Kindly Keep Network Technology Limited (Registration No. 1967379 ). No fiat deposits, so if you want to trade on TOKOK, you need to own cryptocurrency already. It has ETH, BTC and USDT markets. NXT, IGNIS and ARDR trade against ETH.

It’s AML-compliant, so you have to identify yourself before using their services. Picture, social security number, all that… let’s not go into that discussion here, nothing THEY can do about THAT. Upload your full identity to a private company’s central server you must, not. their. fault.

TOKOK wants to focus on projects with a good technical background and future application scenarios in the blockchain field. They are here to contribute, they say, to make a social contribution to the industry by growing a consensus community, and by adding to the development of blockchain technology themselves. TOKOK releases development reports in English on Medium and their website, so everyone can follow the ongoing development of the platform, new listings, and promotional programs. They actually communicate well in English.

Security

Safety first. To protect its trading platform and customers against bad things, TOKOK has partnered with John Wick Security (JWC), a Beijing based security service solution for Blockchain. It’s founded by core members of the security team from Baidu (one of the largest AI and internet companies in the world), 360 Enterprise Security Group, which – according to their website – has provided “security capabilities for companies such as Microsoft, Google, 360, Facebook” with JWC being on a mission to provide comprehensive and in-depth security solutions for blockchain companies and ecosystems.

Not bad, cryptocurrency exchanges should, after all, ALWAYS be safeguarded professionally – unfortunately, unbelievably, and as proven by too many exchange hacks, it just isn’t so! Centralised exchanges are by far the greatest danger to people’s blockchain tokens, so good to know that TOKOK is alert and takes their security measures. TOKOK also keeps a so-called “Risk Reserve” of frozen funds, for further customer protection, and promise that if any user’s assets on their platform “suffer abnormal losses, such as system failure loss, hacker attack loss, etc., [TOKOK] will make corresponding compensation for them after investigation, evidence collection and elimination of the user’s personal reasons”.

Fees for trading

The transaction fee is 0.1% of purchased assets. If you hold their token, TOK, you can use the equivalent value in TOK to deduct the fee. When using TOK, the transaction fee is reduced by 50%, to 0.05%.

No fee for Withdrawal

Withdrawing is free, except for the necessary transaction fee to blockchain forgers/miners.

Interest for hodling?

On September 7, 2018, TOKOK announced a “Deposit With Interest Program”.

What they want is to hold your coins in cold storage and pay you 0.005% in daily interest. The platform scans all coin balances daily at 0:00 (UTC+8) and generates the interest between 0:00-1:00. Users must actively claim their interest (daily) before it expires after 23:59 (UTC+8) or it will not be accumulated.

The money to pay for the Interest Program comes from the 6% of TOK total supply that has been set aside by the team for promotion. As interest is paid in the corresponding currency, TOK is used to buy up these currencies from the market. I asked my contact, June Chen, about this and got this information but no further details, as this is handled by another part of the team. The idea is clear though – “promotion” isn’t just buying ads, sponsored articles and going to blockchain events, but also creating benefits for users, rewarding and building community. Give and thou shall get more in return.

What is the TOK token?

You should know Binance, the world’s largest crypto exchange. And if you do, you probably also know about Binancecoin, BNB. It’s their ICO token and gold calve, giving traders a 50% discount on fees when they pay fees with BNB or trade other cryptocurrencies against it. Oh, and it just so happened to become a Top20 coin by marketcap within less than a year after its ICO in July 2017. Early investors saw a high return, and as a loyalty/utility token, it must be considered as nothing short of a success. And like any success (take NXT, as an example), others will want to follow in its footsteps.

TOK does smell like BNB. You can choose to pay fees on the TOKOK exchange with TOK, and you’ll get a 50% discount on the trading fees. 1 billion TOK were issued. Some gets burned (destroyed) weekly. No more will ever be created. TOK currently can be traded on the exchange against ETH, BTC, and USDT.

Tongue in cheek, let’s take a look at what else is offered TOK holders:

TOK fees:

70% of the TOK that are paid as trading fees are re-distributed equally as a dividend to each TOK on the platform. Holding is like mining, we get it. The remaining 30% is burned weekly (destroyed) and because no new TOK tokens will ever be issued, this is supposed to push up the value of the remaining TOK (and be reflected in its price), as the amount of TOK tokens decrease with every burn.

The non-TOK fees:

Then we have the non-TOK transaction fees. 80% of the non-TOK transaction fees is used to repurchase TOK, which is also distributed to users (TOK holders). The more TOK you hold, and the more trading orders you execute – the more TOK rewards you get. Hold TOK, spend TOK – get TOK.

Other rewards…

25% of the profit earned by the platform (which is of course not just fees) will be equally distributed to each TOK on the platform in the form of BTC, ETH or other currencies. When TOKOK cooperates with crypto teams about their coins, some of the tokens obtained from project cooperation will also be equally distributed as a reward to each TOK. TOK holders have other exclusive privileges, in proportion to their holding percentage – these are announced on the TOKOK blog and include lucky draws (for example, TOKOK recently gave away 100 iPhone X). 

TPS Rewards Points

Finally, TOKOK has TPS points.

These cannot be withdrawn or traded, but are awarded to users that participate in certain activities on the exchange. I couldn’t find much information about this and reached out to June again. He got back to me almost instantly: “A fairly large number of our users hold TPS and we are considering to prepare a gift exchange but for now the platform development shall prevail”.

If you want to buy or trade IGNIS, NXT or ARDR on the TOKOK platform, you can SIGN UP HERE. That’s an affiliate link. By using it, you will be supporting Nxter’s work. Remember – the blockchain wasn’t invented for you to keep your funds in 3rd party wallets – your tokens are safest in a blockchain wallet you control, and our security advice is always to keep them there, use them there, trade on the platform. But when you want to buy tokens with BTC, ETH or trade against them, you can’t do that on Nxt or the Ardor platform (yet), and also, daytraders do prefer the speed of centralized exchanges. The further incentives pushed forward by TOKOK in the form of interest, TOK fee discounts and dividends will likely help them to establish the liquidity and community they need to grow from here. We’ll follow them, as an interesting token use case to watch and not least, a place to buy and trade IGNIS, NXT and ARDR.

Source

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 Blockchain Bootcamp Reviewed or: How I Learned to Stop Worrying and Master Ardor

Ardor

What a great feeling it is to challenge yourself and accomplish something that you have been meaning to do so for a long time. As an editor of Nxter for the past year, I have written much about the advanced functionality of Ardor and yet my dark secret until last week was that I had never truly explored the advanced functionality of Ardor. Sure I could parrot the concept of Phased Transactions but I have never created my own approval model. I could highlight the Asset Exchange functionality of child chains like Ignis, yet I have never issued my own asset or even bothered to see what assets are out there.

I acted like this guy:

But I really was like this:

I have that exact shirt!

But the plot twist here is that I decided to change all of this. I conquered my fear and my inadequacy and dammit I sat down and went to the Ardor Blockchain Bootcamp. Herein lies my review, and my experience.

SPOILER ALERT: the course is very well designed and has something to offer anyone, no matter their experience level and I highly recommend it to anyone who desires or wishes to be able to explore the advanced functionality of Ardor in a structured and guided manner. Yes, this course costs actual cash money, but I fervently believe that this course is a bargain for anyone who completes it as they are going to have a very solid understanding of many, but not all, of the functionality of the Ardor client.

 

What is Udemy?

For the uninitiated, Udemy is a website full of online courses, designed by knowledgeable and passionate people that are structured to teach you about specific courses. I needed to register an account with them to take this class.

Once I had passed the paywall I was in. It was comforting to read that this course ASSUMES NO PRIOR KNOWLEDGE. Nothing about Nxt, the Airdrop or anything like that. No special programming knowledge is required is plastered in the course description. While I personally enjoy programming, I get how the average plebian might be relieved to read this. This entire course is just using the Ardor client and the Ardor testnet. Oh yeah, I learned how to use the Ardor testnet too! #Exciting

 

Part 1: the Basics

The headphones are on, the calming lights are activated and I am ready to do this. The very first thing I am treated to is a calming video of the creator, Eric Funk, explaining to me what I am about to learn and what the objectives of this course are. I am excited to gain real-world, hands-on experience with the advanced features of Ardor.

What lies ahead of me is creating my own cryptocurrency, setting up my own poll using the Voting System, creating my own Asset on the Asset Exchange, issuing my own currency and more. I am actually knowledgeable about everything in part one, as is likely the average user. The first videos are likely very skippable for most Nxters – chances are that most everyone already has the Ardor client installed and an account created. No worries if this does not apply to you.

Like many Nxters my Ardor account is the same address as my Nxt account, but you know, with ARDOR prefixing it and not NXT. It was a little odd seeing an account creation process from scratch.

One thing that I heard that bears repeating, nay, tattooing onto your forehead, is that THERE IS NO CUSTOMER SUPPORT for Ardor. If you lose your PRIVATE KEY you have lost access to your account. This is the 21st century people – take some responsibility!

An interesting note is how US-centric these videos are. As our American audience knows, about the only real way to access the crypto world is through Coinbase. Oh, the horrors, the PTSD-like flashback of my account registration process with them last year. Shivers descend down my spine. Yet I persevere, I am not afraid. A critique I have is how hand-wavey the “Obtaining Ardor” video is for those who are truly beginners. The course recommends buying Bitcoin and converting it to ARDR on third-party exchanges. It reminded me of those cooking shows you see on TV: the host just magically has a pre-made version of the recipe just below the counter while you are struggling and making a mess of your kitchen trying to mix all the ingredients together. The video abstracts away A LOT of the frustration many users will experience as they try and convert fiat currency to crypto. Alas, us Americans do not have access to MisterTango accounts so the convenience of AEUR is unavailable to us. Regardless, the videos do a decent job of explaining how to fund your account with ARDR.

Now I am watching how to declare your public key by completing my first transaction. I want to nitpick how he does not explain the difference between Ardor, the blockchain, and ARDR the token of the blockchain. I am a perfectionist and such things bug me to no end. But again, I am here to learn and not to complain.

Overall the first part was very informative and complete – it exposes the core important concepts of blockchain without going into unnecessary detail. Simple and easy to follow along and all-in-all a pleasant experience. Videos around an hour.

Wow, an hour of my time has passed. I felt like I deserved something and so do you for reading this far. I present you with fuzzy kittens!

D’awww

 

Part 2: Advanced Placement

Part two of the course gets you down and dirty with the Ardor. For those only interested in trading crypto, Part 1 is enough. For those wishing to truly use and appreciate the future that is the blockchain, part two is for you. This is also where casual users of the Ardor platform can jump in and begin dabbling with the advanced functionality of the client.

Here I begin to explore the functionality of Ardor by using the Ardor testnet! Essentially I am using a real copy of the Ardor blockchain with FAKE tokens that have no real value. This way you can experiment without fear of losing tokens. From here on out the course takes place in the Ardor testnet in your browser and not in the Ardor client.

A shout out to Ardor.World – man this a great resource for anyone. In order to proceed in the course and become adroit at Ardor, I need to fund my testnet account. Luckily, you can get FREE testnet coins from the faucet links on the landing page!

It seems odd to me that FAKE testnet ARDR and IGNIS tokens are scarce – like why can I not have infinitely many fake ARDR tokens? I suspect that has something to do with how Ardor.world is set up. If I am wrong, please correct me in the comments.

Interesting to note that all the exercises for this section make use of the creator’s testnet accounts. There is no reason not to use your own, but I wanted to see if I could exactly use the same testnet accounts as Eric, the presenter, and I totally can. I feel like this does not scale with increased user activity, but hey, it works.

I finally get to experience conditional transactions. Not sure why they are called “Phased” transactions – I am ignorant of that distinction, I suspect it an esoteric computer science term. I created my first Approval Model and I saved it! Yet WTF am I limited to FIVE characters to naming things. Arbitrary limit is arbitrary, yo.

Random stock photo woman agrees with me

Continuing on now I am experiencing the Asset Exchange part of Ignis. I get it now, Ardor does not have an Asset Exchange. You and I cannot issue assets on Ardor but we can on Ignis because it is permissionless! That is sweet and totally makes sense now. This is coming from a guy who has written about this for a while now and yet it did not click until I actually created my own asset! The importance of asset control is mentioned many times here – the ability to control who can trade the asset.

Issuing assets and creating dividends is fun, it makes me feel like my own CEO. It is annoying how you need to search for assets by IDs so I hope you have handy the long string of numbers that represents the assets you wish to buy. A poorly optimized piece of UI for the Ardor client, but hey, it is what it is. Disclaimer, I understand that asset names are non-unique and that during the Ignis ICO there were many scammers out there selling assets named JLRDA. The only way to be sure you have the correct asset is by the asset ID. I just wish that there were a UI mechanism that would allow for verification of proper asset names such that I did not need to keep an ID string around.

I also get what Singleton assets are – nondivisible assets; like those absurdly popular crypto kitties on Ethereum.

Oh, for anyone who diligently does the exercises using the same testnet accounts you will need to copy and paste the passphrase like literally a million times.

Now for some real unknown waters for me: the Currency System. I have no idea how to create a currency, let alone do I know how they are different and distinct from assets. My understanding of Ardor continues to grow, as does my hair but that is not the point. The point is that I am deep in the course now, over two hours, and I am continuing to comprehend and appreciate the advanced features of Ardor.

Issuing my own currency is a little weird for me, but hey I can say that I have done it. The nuances of whether or not you want your issued currency to be “Reservable” and/or “Claimable” are subtle but powerful. Luckily the Ardor client (testnet and mainnet) are smart enough to not allow you to issue a currency with conditions that make it inoperable, but I sure wish that there was more documentation on what the significance of the categories are. I know the nxtwiki has documentation on this but it is not easy to grasp everything fully. It was fun to learn that, in essence, you can create “mineable” PoS coins and that you can enact conditions that only release the currency when they are fully met. There are many different currency types and different use cases for all of them. Admittedly this part was a little hard to follow.

The last few sections covered the many topics briefly. I created a poll whose only participants were the holders of my fake Ignis asset. Sweet – I see the usefulness of these polls. Why do I personally not use polls more often? Nxter needs polls – they drive engagement and are very easy to use. My only doubt is how can you link to them? This question is going to keep me up at night. But boy, are they useful!

The Data Cloud is cool, but documents are limited to 40K of space, good for hashes and code snippets. I understand that I can pay for more but man that seems small. Also, kudos to whoever listed Top Secret as a tag in the Data Cloud. I salute you, sir, or madam.

The Marketplace functionality of Ardor is great. I am guided through the Marketplace. The ability to list and sell things is great, but I wonder what guarantees I have of receiving the product? The same question exists on Craigslist and eBay but with them, the company can intervene on my behalf if a seller does not ship the product. On the testnet the products are fake – 5 IGNIS for a sailboat is too good to be true. LOL on whoever listed cocaine on the testnet Marketplace. The creativity and dark humor of people amuses me to no end.

Messages are the last section on my journey and it is mostly as advertised, but with an important distinction that I am probably the last person to appreciate: Shared Keys allow for third-parties to see encrypted messages to me without me giving up my Private Key/ Passphrase. That is a great point to understand and one that was here-to-before lost upon me – with them you can share sensitive data like identity documents, medical journals, certificates, whatever. Again, I am probably the last person to get this, but hey, better late than never!

And that is it, I put my headphones down. My 3.5-hour long journey is over. Before I was but a padawan, but now I am an advanced user! I am pumped and want to sell this exciting and exhilarating feeling of completing the course and gaining a much better understanding and intuition of the powerful functionality of Ardor.

I am no master of Ardor, but I am a sufficiently advanced user who now has the foundation to continue to explore and build my knowledge base. My journey is not over – it is only beginning.  It is a little deceptive to claim that anyone is a “Master” of Ardor after completing this course, but you definitely will be an advanced user.

The hands-on structure and constant manipulation of the Ardor testnet account were a great asset to me, and likely will be to anyone interested in exploring and mastering Ardor as well. A few minor gripes aside, (more on Forging and Bundlers please) and a complete lack of any mention to Lightweight Contracts, Multisig Transactions, and Cold Storage and proof-of account-ownership tokens, the course was engaging and methodical.

Nonetheless, believe that this course is very thorough and well-paced if not a little brief infrequently. The nuances of the many restrictions possible for currency and asset creation requires more of my time to fully appreciate all the different use cases for them.

Kudos to the creator for making this course. The material is accessible to all and well presented. The beauty of Udemy is that you do not need to watch every single video. You have access to all the content from the beginning and can immediately jump to the sections that interest you. Manipulating the exercises in Part 2 requires nothing from Part 1 if you already have the Ardor client installed and running.

The blockchain is the future people, experience it! Long series of sequentially hashed files are the future and now I am an advanced user of Ardor. I am prepared. My Private Key is secure, my high fives are for sale and I am ready to broadcast on Ardor, and to the world, that I am truly appreciative of the advanced blockchain features that are standard on Ardor.

Conclusion

I feel accomplished and I experienced, hands-on, much of the great functionality of Ardor. What are you afraid of when it comes to learning and personally exploring Ardor? Here, let me incline you to begin the same journey as me by offering this Nxter code course discount!

To many, a blockchain is a scary thing, an abstract concept that is hard to connect to. This is patently absurd – overcome your fear by practicing with it – it exists right now. Wonderful functionality already exists that is immediately usable for most anyone and this is just the beginning of what is to come!  There are many great features of Ardor: the Coin Exchange, the Monetary System, the Voting System, the ability to add conditions to transactions, Aliases, Currency creation, the Marketplace, all of it. But it is nothing more than words unless you experience it – dabble with it. Make it your own! With the release of this course, I believe that the time of being hesitant is over. Take the course and learn the advanced topics and concepts of Ardor. Now it is May and soon it will be June and then it will be summer and then you will be dead! Act now and learn the joys of using Ardor, you will be filled with regret of not taking a small amount of time to appreciate just how powerful a tool we have at our fingertips right now.

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. 🙂

Ardor vs. the Competition, Pt. 2: NEM/Mijin/Catapult

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 NEM, a public blockchain similar to Nxt in many ways. As I’m primarily interested in each blockchain project’s approach to scaling, I also researched Mijin, a version of NEM for private blockchains, and Catapult, a rewrite of Mijin which promises large performance gains and which will also be incorporated into future releases of NEM.

NEM

Although NEM’s core developers abandoned their initial plan to start NEM as a fork of Nxt, choosing instead to start the project from scratch, NEM and Nxt are still fairly similar. Like Nxt, the NEM platform provides a predefined set of allowed transactions which applications can use as building blocks to create more complex features, as opposed to using a low-level scripting language to construct transactions, like Bitcoin or Ethereum.

Both platforms support a variety of “blockchain 2.0” features, like sending messages, creating and transfering assets, and sending transactions requiring the approval of multiple accounts (m-of-n multisig). And both platforms expose their functionality through HTTP-based APIs, so developers can use virtually any language to write applications for them.

Despite these similarities, NEM also has some notable differences compared to Nxt.

Perhaps the most fundamental one is its novel consensus algorithm, called proof-of-importance. This algorithm is similar to proof-of-stake, except the probability that an account may harvest (i.e., forge) the next block depends not only on its stake of XEM, which is the native coin on NEM, but also on how recently it has transacted with other accounts and how much XEM was exchanged. Accounts that hold a large stake of XEM and which transact frequently and in high volume harvest more blocks than accounts with less XEM or accounts which only rarely transact.

The authors of the NEM Technical Reference argue that, compared to proof-of-stake, the proof-of-importance algorithm gives somewhat less weight to the wealthiest accounts when determining the right to forge/harvest the next block (Section 7.8). Proof-of-importance is also central to NEM’s spam filter, which requires that an attacker not only control a lot of accounts, which is easy to do, in order to spam the network with a large number of unconfirmed transactions, but also to hold a large stake in each account and transact frequently with other high-importance accounts.

In my view, another main difference between NEM and Nxt is the extent to which each platform’s “blockchain 2.0” features are integrated directly into the API. For example, NEM’s assets, called “mosaics,” share several features with the Nxt Monetary System’s currencies, but NEM does not have a built-in decentralized exchange for mosaics. (As a side note, the NEM Foundation has contracted with Blockchain Global to create a traditional, centralized exchange featuring mosaic-based ICO tokens.) Similarly, while you could certainly build a decentralized marketplace on top of NEM where users could buy and sell goods and services, NEM does not have such a marketplace built into its API the way that Nxt does.

Finally, one subtle but very important difference between NEM and most other blockchains, including Nxt, is the way that it handles multisignature transactions. Instead of allowing any account to generate a multisig transaction, NEM introduces the concept of a multisig account and requires that all multisig transactions originate from such accounts. Any co-signatory on the account can initiate a transaction from it, and the transaction is only executed if a sufficient number of the other co-signatories approve it.

At first this might appear to be a limitation, since it requires a separate multisig account for each set of co-signatories a user wants to cosign with, but it has two key advantages: the multisig account is a full account, capable of receiving payments, messages, and mosaics, for example; and co-signatories can be added and removed, so custody of the multisig account can be transferred. It is possible to create a “1-of-1” multisig account, i.e., an account with a single custodian who can transfer it to a different custodian if desired. In this way, multisig accounts on NEM can act like transferable containers for XEM, mosaics, and messages.

One particularly impressive application of this concept is a notary service built on NEM called Apostille. With Apostille, the process of notarizing a document looks like this:

  1. Hash and sign the name of the document.
  2. Create a multisig account for the document derived from the resulting signature.
  3. Hash and sign the contents of the document.
  4. Send a message containing the result to the document’s multisig account.

Note that the last step also attaches a timestamp to the document, since the transaction that transfers the document’s signed hash to the multisig account is recorded on the blockchain.

As an example of a potential application of Apostille, the authors of the white paper consider a case where the notarized document is a car title. Ownership of the car can be transferred by changing co-signatories on the multisig account that contains the title; messages describing maintenance and repairs can be sent to the multisig account to record the car’s service history; and mosaics issued by governments or insurers could attest to payment of fees. In this way, the multisig account represents both the car itself and the history of other accounts’ interactions with it.

Anyway, that’s quite enough about NEM. Next, Mijin.

Mijin

At a high level, Mijin is a version of NEM that three of the core NEM developers and a company called Tech Bureau developed as a private, permissioned blockchain product. Like any private blockchain–and in contrast to NEM, which is public–a Mijin blockchain is owned and controlled by a central authority, such as a company.

This isn’t the place for a full debate about the utility of private blockchains, but as Mijin and Catapult are an important part of the NEM ecosystem, please indulge me for a minute. In my opinion, the more “private” a private blockchain becomes, the less useful it is. While I can see a case to be made for “consortium” blockchains, where a handful of independent organizations who don’t necessarily trust each other cooperate to secure the network against abuses by any one member of the group, I have trouble seeing the value in a blockchain controlled by a single authority. In my view, a blockchain without trustless consensus is basically just an extremely slow, extremely inefficient database.

I know there are plenty of people who disagree with me, though, so for the remainder of this post I’m going to assume private blockchains have value and that there is a market for them, especially in financial services, which seems to be the main industry that Tech Bureau intends for Mijin to serve.

There is not nearly as much information about Mijin available on the internet as there is about NEM, but I did learn some interesting facts that hint at its potential. For one thing, although Mijin and NEM are completely separate projects, Mijin does share the NEM API (or at least the two APIs overlap substantially), which suggests that it will be relatively easy for developers to write applications that run on either platform. The common API might also facilitate interactions between Mijin chains and the public NEM chain, but I haven’t found any information about the details of those interactions.

Additionally, the Mijin website states that Mijin will support smart contracts, though the Catapult white paper seems to slightly contradict that statement when it says, “the approach here is to make the smart contract an external component, whether centralized (i.e., status quo with existing systems) or decentralized. The outputs of these smart contracts will then enter their transactions into the ledger through a secure transaction process.” To me, this implies that the contracts themselves will be neither stored on the blockchain nor executed by all nodes on the network.

Speaking of Catapult…

Catapult

Catapult is a rewrite of Mijin with a focus on increasing the rate at which transactions can be confirmed. Judging from the white paper (linked above), the first deployments of Catapult will be at banks and other financial institutions, where the author envisions it will replace patchworks of “disjointed monolithic systems” that he says are commonly used today. Eventually, the developers also plan to integrate Catapult into NEM to facilitate scaling the public blockchain as well.

Like Mijin, Catapult is currently closed-source and many technical details are not public. I was able to find some good information digging around the NEM blog, though, especially in this thread by one of the developers.

Catapult divides the work that the network does among three types of nodes:

  • P2P nodes, which add new blocks to the blockchain and maintain consensus about its state;
  • REST nodes, which present client applications with all the features they can use from the Catapult API; and
  • API nodes, which, like P2P nodes, store the blockchain and can read directly from it (I think), but which do not add blocks to it. These nodes serve data to the REST nodes to fulfill client applications’ requests.

This breakdown appears to roughly correspond to the three-tier architecture commonly used for web applications, where the blockchain (P2P nodes) is the database, the REST nodes are the front-end, and the API nodes handle the business logic of interpreting and interacting with data in the database.

If this analogy is correct, then presumably the goal of this architecture is to allow each tier to scale independently. Especially for a private blockchain, the optimal number of P2P nodes used to establish consensus might be much smaller than the number of REST and API nodes required to handle all of the requests that applications send to the network. Delegating these responsibilities to separate nodes on the network should allow nodes of each type to be added or removed as needed to optimize performance.

Apart from this new architecture, Catapult also makes some other optimizations to improve performance. Whereas Mijin and NEM are written in Java and use HTTP for communicating with full nodes, Catapult is being written in C++, and communication between at least the API nodes and REST nodes uses full-duplex sockets (via ZeroMQ), potentially allowing for lower latency than HTTP.

A performance test of three Catapult nodes located in the same datacenter and configured to service requests from 10.8 million accounts showed that the network was able to process just over 3,000 transactions per second. It isn’t completely clear from the press release, but it sounds like each of the three nodes in this test played all three roles: P2P, API, and REST. Confusingly, the accompanying diagram appears to refer to API nodes as “blockchain data ingestion servers” and to REST nodes as “API gateway” servers.

Compared to Ardor

How does NEM compare to Ardor, then?

Really, there are (at least) two separate questions: how do NEM’s features compare to Ardor’s features? And how does NEM’s approach to scaling compare to Ardor’s approach?

Since Ardor (the platform, not the parent chain) will support all of Nxt’s current features, the comparisons I noted above between NEM and Nxt apply equally well to Ardor.

In particular, Ardor’s child chains will have at their disposal a somewhat larger variety of built-in transaction types that support a richer set of features.

For example, NEM does not natively support a peer-to-peer exchange for mosaics, dividend payments to mosaic holders, transactions conditioned on votes by mosaic holders (or most of Nxt’s phased transaction types, for that matter), account properties, a decentralized marketplace, or anything like Nxt’s shuffling and alias systems.

Ardor’s parent-chain/child-chain architecture will add some extra functionality, too.

In particular, users will be able to exchange different child chain tokens for one another directly, without first converting to ARDR. This will be especially useful on pegged child chains, where users will be able to trade dollar-pegged coins directly for bitcoin-pegged coins (for example), whereas on NEM, somebody holding a dollar-pegged mosaic would have to sell it for XEM, then buy a bitcoin-pegged mosaic.

These differences notwithstanding, NEM still offers a rich set of features that application developers can use in interesting ways. Perhaps the best example is Apostille’s creative use of NEM’s unique multisig accounts. I’m not sure how easy it would be to replicate that kind of functionality on Ardor.

[EDIT]: Lior Yaffe, core dev and co-founder of Jelurida, has the following comment:

With NXT this can be achieved by issuing a singleton asset for each license registration and sending it between accounts.

On the question of how to scale, the two platforms differ much more dramatically.

Catapult’s approach, which NEM will eventually incorporate, is twofold: a new three-tier architecture to distribute the network’s responsibilities among three specialized types of nodes; and a series of application-level optimizations, e.g., using C++ instead of Java. We will need to defer judgment of the latter approach until additional benchmarking tests are available, but we can still cautiously speculate about the implications of the new architecture.

The biggest advantage seems to be for private blockchains, where the owner can fine-tune the quantities of the three types of nodes and the topology of the network to optimize throughput. Moreover, in such a context, blockchain bloat isn’t as severe a problem as it is for a public blockchain since companies can easily dedicate terabytes of storage on their servers to storing the blockchain.

The improvement in NEM’s performance with this new architecture, on the other hand, is much harder to predict. It is not clear whether each peer on the network would have to run all three services (P2P, API, REST) or just one of the three. In the former case, the scaling advantage to the new architecture would presumably be lost. In the latter case, the classic trade-off between speed (fewer P2P nodes, more API and REST nodes) and security (greater fraction of P2P nodes) would remain. And since nobody could control the number of each type of node on a public network, the question of what the optimal balance is would be moot.

In contrast, Ardor’s design does not try to achieve the highest possible throughput, at least initially. Rather, Ardor’s main scaling goal is to greatly reduce the size and rate of growth of the blockchain. It does this using a unique parent-chain/child-chain architecture, where all nodes on the network validate all transactions, but only those belonging to accounts holding the parent chain coin (ARDR) forge. Since the child chain coins can’t be used to forge, the child chains’ transaction history is irrelevant to the security of the network and can be pruned away.

It is worth noting, however, that computational scaling is on the Ardor roadmap.

Specifically, it is possible that child chain transaction processing will be delegated to separate subnets of the Ardor network in the future, allowing most nodes to ignore most transactions.

Conclusion

Ardor and NEM both offer rich, largely overlapping sets of features.

Overall, my impression is that developers will probably be able to build similarly complex applications on either blockchain with comparable ease. In that sense, the two platforms are direct competitors.

In their approaches to scaling, though, Ardor and NEM are quite different.

While Catapult will likely achieve a significant improvement in the rate that private blockchains can confirm transactions, I am somewhat more skeptical of the performance improvement that can be achieved on a public blockchain like NEM using the same approach.

Ardor, on the other hand, does not attempt to address the computational scaling problem (for now), but has found a very effective solution to the problem of blockchain bloat.

I suppose time will tell whether computational scaling or blockchain bloat is ultimately going to pose the biggest long-term problem for blockchain tech, and time will also tell whether either platform has found an adequate solution.

IGNIS ICO Report 7

Today the 3rd batch of Round 3, with 25 M JLRDA tokens, became available for sale. At the time of writing, there were still JLRDA tokens available.

Finally – some would say – the IGNIS ICO hype calmed down a little. Finally, it is possible to attend the ICO and buy JLRDA without running a full node client, placing several buy-orders in advance, or having to figure out the most advantageous peer settings and transaction fees in order to get a chance to win the over-participated lottery for future IGNIS tokens on the Ardor Blockchain Platform.

ICO: Jelurida [ID 823491988455668070]

Live data from the Nxt blockchain

peter2615

As someone said on the forum in the ICO thread:
In round one 1 NXT = 4500 Sat. 1 JLRDA = 0.4 NXT = 1800 Sat.
In round [three] 1 NXT = 2000 Sat. 1 JLRDA = 0.76 NXT = 1520 Sat.

So, the guy who ran away with all the JLRDA in the first few rounds did not get such a great deal afterall …

Live data from the Nxt blockchain

Either the whale investors

  1. Gave up (as they attended on equal terms with everyone else)
  2. Believe that 1 IGNIS token will be worth less than 0.76 NXT at the current NXT price
    (0.76 NXT = 0.07 USD or 0.0000162252 BTC)
  3. Believe that the price of NXT will rise a lot in the future – keep in mind that by holding NXT you get 0.5 IGNIS per NXT that you own at the snapshot (Q4 2017) and you get to keep your NXT
  4. Decided to invest in ARDR instead of JLRDA
  5. Do not even know about Jelurida’s work and the IGNIS ICO

Let us take a look at the three tokens in play, and you can choose your path to success by choosing which one best suits your interests and needs.

NXT

Nxt launched in 2013 as the first 100% Proof-of-Stake (PoS) blockchain ever and has run stable ever since. Over the years Nxt was optimized with built-in smart contracts that anyone can use “as is” or use them to build their decentralized applications with – without risking their investors’ money or the security of the blockchain, as no 3rd party code is added to the blockchain. Nxt’s smart transactions are rigorously tested in production and can be accessed using the Nxt API, which supports over 200 request types. Nxt is coded in Java, the leading industry standard language for corporate applications. The Nxt platform is open source for its open and supportive community. Nxt is called the “Swiss army-knife” of crypto, undervalued in the markets, and technically ahead of the competition.

With the new JPL license, owners of NXT are entitled to receive 10% of tokens from clones of Nxt.

https://nxt.org
https://nxter.org/tutorials
https://nxter.org/newsletters

IGNIS

Ignis will be the first child chain on Ardor. Ignis will have all of the features of Nxt, except for forging – it will be secured instead by Ardor’s main chain. Users of Ignis get UNRESTRICTED ACCESS to all existing and future Ardor child chain features. Do not expect unrestricted access from any other child chain in the ecosystem, as their creators may restrict those. Ignis will constantly be pruned (no blockchain bloat – means: globally scalable) and will feature cross-chain transactions, e.g., token and asset trading, and access to custom features on any other child chain. JLRDA, the non-transferable token sold in the ICO, represents the monetary unit and transactional token of Ignis, IGNIS, 1:1. JLRDA tokens will convert to IGNIS automatically at the Ardor Genesis Snapshot.

https://jelurida.com/ico
https://www.nxter.org/tag/ignis-ico/
https://www.jelurida.com/ardor-nxt-feature-comparison

ARDOR

Ardor is Nxt 2.0 and is best described as a Blockchain-as-a-Service (BaaS) platform, currently running on testnet. Ardor is the main chain that will secure, bundle and forge all transactions on the network of child chains. Ardor will make the features of Ignis available to other child chain creators, but restrictions can be placed if certain features are not desired, such as shuffling of tokens, the unrestricted decentralized marketplace or the unregulated asset exchange. Child chains will have their own operational token so users will not have to buy “gateway tokens” such as NXT, ARDR or ETH to use them. Child chains will be prunable and will not have to be bootstrapped, as they are secured by Ardor. Child chains can be spawned and customised with help from Jelurida, but the ability to create new chains will eventually be integrated into the software as a DIY module. For those that like account and ID regulations and restrictions – Ardor is the place to be. For those that like to forge all child chain fees – Ardor is the place to be.

https://www.ardorplatform.org
https://nxter.org/ardor-blockchain
https://www.jelurida.com/sites/default/files/JeluridaWhitepaper.pdf


 

 

Live data from the Nxt blockchain

ARDOR introduction video

Q4 2017

  • Ardor mainnet launch
  • Migration of ARDR balances from the Nxt blockchain asset to the Ardor Genesis block
  • Spawn of the IGNIS child chain based on NXT and JLRDA balances
  • Spawn of Bitswift child chain with 10% share drop to IGNIS holders
  • Spawn of BTC, EUR, and USD pegged child chains backed by 3rd party business entities

ICO’s are hot right now, and the choice is hard if you have money to invest. The choice is entirely up to you – supporting any chain supports Jelurida, the company that owns the IP for the above tokens.

Right now, the JLRDA tokens are for sale on the Nxt blockchain and will be automatically swapped for IGNIS tokens on the Ignis child chain when Ardor and Ignis are launched together in Q4 2017.

#nofomo

You need NXT to buy JLRDA. The most secure and the recommended way to buy JLRDA is from the IGNIS Token Sale link in the NRS Client, currently running V1.11.9.

You can use Jelurida’s online Nxt node or download and run the client locally – as light (no blockchain download) or full node. You can also use Nxt OFFLINE to create cold storage accounts to buy IGNIS.

JLRDA tokens cannot be transferred or traded until Ardor is launched – do not fall for scams.

Stay tuned for more up-to-date coverage on the ICO. We will explain in more detail about Jelurida, Ignis, Ardor, and everything else that is pertinent to this ICO. We won’t give trading advice.

Follow us on Twitter for breaking updates. And please help us grow as we continue to provide our readers with excellent and focused coverage on the ever growing blockchain space by rewarding us for our efforts – Donation address: NXT-TK9J-MEKH-MUP9-HFCH2.

This article is for educational purposes only. It is advisable never to invest more than you can afford to lose.

IGNIS ICO Report 6

Round 3 of the IGNIS ICO is underway, and the first batch has already sold out. Interest is high in this ICO, and that is good news for Jelurida and the entire Nxt community. The third round of the crowdsale is divided up into four offers of 25 M JLRDA each, all priced at 1 JLRDA for 0.76 NXT.

JLRDA batches will be sold according to the following schedule:

Sat, Sep 9th between 06:45 - 07:15 UTC
Sun, Sep 10th between 18:45 - 19:15 UTC
Tue, Sep 12th between 06:45 - 07:15 UTC
Thu, Sep 14th between 18:45 - 19:15 UTC

The exact time within each 30-minute interval is randomly determined. Jelurida reserves the right to modify the above schedule in case of circumstances beyond its control.

The IGNIS ICO is, in essence, a barometer of the public's interest in the Nxt and Ardor Platforms. With Ardor due to launch in Q4 of this year, Jelurida needs to know how to split up their limited dev resources. The funding raised by Jelurida, which owns the IP for Nxt / Ardor / Ignis is directly going towards actively developing Nxt. So far Jelurida has procured enough funding to actively support Nxt for, at least, the next three years.

The ICO so Far

The highlights of Round 1 in early August were the whale "MAAC" eating up the entirety of the first couple of batches. He accomplished this through clever use of the Nxt blockchain protocols. Within 48 hours Jelurida senior developer, Lior Yaffe, released a patch to prevent similar occurrences: NRS client V1.11. 7. The Nxt platform now allowed for scheduling transactions up to 24 hours in advance.

Like the first round, Round 2 sold out in seconds. The current and most stable NRS client is V1.11.9.

So far every round of the ICO has sold out before the JLRDA sell offers had posted! Since the demand for the IGNIS ICO is still higher than the supply, the way to have a shot at getting JLRDA is to schedule your buy transaction in the NRS client 24 hours before the batch is officially for sale.

REMEMBER - Jelurida is the ONLY source of official information about the IGNIS ICO. All info here is directly provided by Jelurida. 


Ignis ICO Report 8

By apenzl | 03/11/2017

BTC is on a bull run, to put it gently. Anyone watching crypto charts and price indexes these days see the value of BTC (Bitcoin) skyrocketing up up up; resulting in most altcoins declining in value when pegged against BTC. This story also applies to NXT and ARDR, yet ARDR does extremely well in terms of … Read more

IGNIS ICO Report 7

By apenzl | 13/09/2017

Today the 3rd batch of Round 3, with 25 M JLRDA tokens, became available for sale. At the time of writing, there were still JLRDA tokens available. Finally – some would say – the IGNIS ICO hype calmed down a little. Finally, it is possible to attend the ICO and buy JLRDA without running a … Read more

IGNIS ICO Report 5

By apenzl | 30/08/2017

Is your bid order in place? Popcorn ready? Tomorrow, on Thursday, Aug 31st between 18:45 – 19:15 UTC, the last batch of Round 2 in the IGNIS ICO is offered. That’s the last of 4 batches, each counting 20M JLRDA tokens. The price is 0.55 NXT per JLRDA – the token that will swap 1:1 … Read more

IGNIS ICO Report 4

By apenzl | 24/08/2017

And so, the hunt for JLRDA is about to resume. Round 2 of the IGNIS ICO will kick off Aug 26 between 06:45 – 07:15 UTC The price will be 0.55 NXT per JLRDA, with 80M JLRDA tokens for sale in this round. Anyone who did their due diligence will know: Ignis will be launched with … Read more

IGNIS ICO Report 3

By apenzl | 10/08/2017

Only 1 batch left of Round 1! UPDATE: no JLRDA left from Round 1!  Round 2 will begin on August 26. And so, here’s a re-cap, as the hunt for cheap JLRDA continues… Early NXT investor ‘MAAC‘ has taken much of the limelight as he overruled “normal” participants by using the advanced features of the … Read more

IGNIS ICO Report 2

By apenzl | 07/08/2017

Did you hold your breath? Never mind, the second 5M batch of the IGNIS ICO got snatched by MAAC the Whale. And also most of the third. But look at this now: Live data from the Nxt blockchain 69 new buyers got their hands on JLRDA  – no ninja tricks, no bots, just by using … Read more

IGNIS ICO Report 1

By apenzl | 05/08/2017

The long awaited crowd sale of the IGNIS token has begun. For sale are 440,000,000 Jelurida tokens (JLRDA) out of 1,000,000,000 total. The Nxtchat.slack has been buzzing for weeks with anticipation and discussions of how to get your hands on these JLRDA tokens and this article contains some important information pertinent to your investing decisions. … Read more

Ardor is about to launch, and the revolutionary parent - child architecture will solve many blockchain problems. Follow us on Twitter for important breaking updates during the week as they happen. Learn more every Monday with the release of the weekly Nxter Newsletter. We explain in more detail about Jelurida, Ignis, Ardor, and everything else that is pertinent to this ICO. Stay tuned and stay informed, dear readers. See you back here next week!

Help us grow and help us continue to provide excellent and focused coverage on the ever growing blockchain space by rewarding us for our efforts. Donation address: NXT-TK9J-MEKH-MUP9-HFCH2.

Thanks to https://twitter.com/lepych10 for beach art / NXT>ARDR img  🙂

Ardor vs. the Competition, Pt. 1: Lisk

I recently decided to start a series of posts that compare and contrast Ardor with other blockchain projects that appear to have similar goals or features. Roughly each week, I'll pick a project whose scope overlaps at least a little with Ardor's, study its technical documentation, and post a summary of my findings here for you to critique.

This week, I've been reading about Lisk.

Lisk

In a nutshell, Lisk is a platform for developing decentralized applications (dapps) that run on sidechains anchored to the Lisk mainchain. It uses a delegated proof-of-stake (DPOS) consensus mechanism to secure the mainchain, while sidechains are each responsible for their own security (sort of, but see the description of the delegate marketplace below). The protocol uses a set of predefined transactions, rather like Nxt and Ardor, as opposed to a low-level scripting language like Bitcoin or Ethereum.

Before I get into the details, I should start by saying that Lisk is definitely in an early stage of development. The team is currently in the middle of rewriting the Lisk SDK, which will support sidechain development, and is continuously refactoring Lisk Core, which is the full node.

With the code in flux, some important architectural questions, particularly about sidechains and how they will interact with one another and with the mainchain, do not appear to have been settled yet. On the other hand, I had some difficulty finding a current, authoritative source of technical information about Lisk, so what I present here might be out of date. The best information I could find was in the wikithis article by one of the co-founders, the roadmap, and these YouTube videos. None of the first three sources are recent, unfortunately, and even the videos don't go into much depth (though I admit I haven't watched all 6+ hours of them). If you've found better references, I'd be grateful if you could send them my way.

The marketing buzz surrounding Lisk seems to focus on the SDK, the goal of which is to make it easy to build, deploy, and secure a dapp running on a customizable blockchain. The devs wrote the SDK in JavaScript because they want to make Lisk accessible to as wide an audience as possible, and they also wrote the backend in JavaScript (Node.js) because...well, I guess I'll never understand why people insist on using JavaScript on the backend. 🙂

But clearly, ease of developing and deploying a custom blockchain is not the only goal of Lisk. If it were, then what purpose would the mainchain serve? You might as well clone Bitcoin or Nxt if all you want is a good starting point for building your own blockchain.

The mainchain/sidechain architecture is the real distinguishing feature of this platform. As far as I can tell, the mainchain serves at least three important functions:

  1. The Lisk API will allow deposits of LSK on the mainchain to be transferred to and from sidechains. With two such transactions, it will be possible to send LSK from one sidechain through the mainchain and to another sidechain. Unfortunately, according to the article by one of the co-founders linked above, it sounds like transferring LSK onto a sidechain will require sending it to the sidechain's owner, which obviously requires some degree of trust. To avoid this problem, it will be possible to create sidechains that use their own forging tokens instead of LSK. This token would then need to be traded for LSK in order to transact through the mainchain with another sidechain. Alternatively, it might be possible for one sidechain to transact directly with another sidechain without going through the mainchain, but the developers are still researching how this would work.
  2. Eventually, the team plans to build a "delegate marketplace" where delegates who are not securing the mainchain can offer to secure sidechains and are paid "either by the [sidechain] application owner or its users." Again, the details are a little fuzzy, but there seems to be a lot of value here: presumably the Lisk network is already far larger than a typical brand new blockchain network, and the delegate marketplace gives sidechains an "off-the-shelf" set of nodes that they can use to secure themselves in their infancy.
  3. Some nodes on the network (not sure which ones) will periodically hash sidechains and store the hashes on the mainchain as a "basic validation of sidechain integrity." I haven't been able to find any details about how this mechanism will work, though.

Apart from these functions, and from the obvious role it plays in transferring LSK between accounts, the mainchain itself doesn't seem to have any other intended uses. All of the business activity is supposed to occur on the sidechains.

Compared to Ardor

How does this architecture compare with Ardor's parent chain and child chains?

Maybe the most obvious difference is that each sidechain must have its own set of nodes to secure it, whether these are provided by the sidechain creator, the users, or eventually the delegate marketplace.

With Ardor, in contrast, every node on the network validates child chain transactions, but only accounts holding ARDR forge. The fact that accounts holding child chain tokens don't forge with them means that it doesn't matter how small child chains are or how unequal the distribution of tokens on them is; they are all just as secure as the parent chain.

One additional note about Lisk is that, until the delegate marketplace opens, sidechain creators choose the nodes that forge on their chains, which seems to require that users place a great deal of trust in them. On the other hand, the team has also suggested that Lisk will be flexible enough to allow sidechains to use an entirely different consensus algorithm, like proof-of-work, so it seems that sidechain creators wouldn't determine which nodes secure the chain in that case.

There are also plans to allow existing sidechains to switch consensus mechanisms even after they launch, but again I haven't been able to find details.

Clearly, both Lisk and Ardor intend to offer scaling advantages over traditional blockchains. With Lisk, the computational scaling advantage is obvious, since each forging node validates only the transactions on a single blockchain, either the mainchain or a sidechain. The reduction in required storage space (i.e., blockchain bloat) is less clear, though. Compared to Ethereum, say, it's obvious that for a similar level of total activity, the many chains in the Lisk ecosystem will each grow more slowly than the single Ethereum chain, simply because sidechains will not store each other's data.

Compared to Ardor, though, the storage savings would be modest. Ardor's parent chain will grow at a similar rate to the Lisk mainchain--as both will store only hashes of sidechain or child chain data instead of the data itself--but on Ardor the child chain data will be pruned away, eliminating the blockchain bloat problem that Lisk will still have on each sidechain.

Conclusion

What, then, should we make of Lisk? Honestly--and I'm very disappointed to write this--I think it's simply too early to tell. Too many important details have yet to materialize:

  • Will it be possible to convert one sidechain's token directly to another sidechain's token without converting to and from LSK? How?
  • When the delegate marketplace opens, will it be possible for users to elect delegates using sidechain tokens? Or will they have to use LSK? Or will sidechain owners maintain control over which delegates forge?
  • What will Lisk do with the hashes of sidechains that are stored on the mainchain? Will it be possible to roll back recent transactions on a sidechain to "restore" it to the state it had when it was hashed? If so, will there be some time after which this will not be possible, so that the sidechain can still be considered immutable?
  • Will the Lisk SDK provide some clean mechanism for changing the consensus algorithm on an existing sidechain? I'm not sure what this would look like.
  • What happens if a sidechain that uses LSK forks? Obviously, the LSK tokens on both resulting sidechains cannot be simultaneously backed by the same LSK reserves on the mainchain. I would assume the sidechain creator effectively gets to choose which chain is the "real" one, since he or she is the one holding the reserves on the mainchain, but I don't know for sure that this is correct.
  • Depending on how Lisk will support transactions directly between sidechains, this same concern could require additional trust between sidechain creators. In particular, if sidechain creators must hold reserves of each other's tokens to enable cross-chain transactions, which seems like one plausible way to do it, then a fork in one sidechain could give the other sidechain's creator some influence over which branch of the fork is honored. Moreover, if the forking sidechain transacts with several other sidechains, each of which hold reserves of the split token, then the situation could get ugly pretty quickly.

In my opinion, the most important advantage Lisk has over most blockchain platforms, including Ardor, is that it will accomplish a natural computational scaling by segregating each dapp onto its own blockchain. If, in addition, sidechains will be able to transact seamlessly and trustlessly with one another, then it seems like the design has immense potential.

If we're making the assumption that the Lisk team will successfully implement all the features required to make this happen, though, then we ought to grant Jelurida the same courtesy and assume that they'll be able to carry out their own scaling plans. In particular, one potential improvement on the Ardor roadmap is to confine child chain transaction processing to dedicated subnets of the Ardor network. It seems to me that this would accomplish a similar computational scaling to Lisk, while preserving Ardor's substantial advantage in reducing blockchain bloat.

In conclusion, Lisk's mainchain/sidechain architecture could potentially help it scale to accommodate a large number of dapps that could interact in interesting ways, but right now there seems to be a lot of uncertainty in the technical details. Ardor's approach is technically quite different but solves some of the same problems, namely blockchain bloat, potentially computational scaling, and the ability to transact easily between separate chains.

It will be very interesting to see how Lisk develops in the next two or three years, but then again, by that time Ardor will have been live for a long time already.

- segfaultsteve

IGNIS ICO Report 5

Is your bid order in place? Popcorn ready?

Tomorrow, on Thursday, Aug 31st between 18:45 – 19:15 UTC, the last batch of Round 2 in the IGNIS ICO is offered. That’s the last of 4 batches, each counting 20M JLRDA tokens. The price is 0.55 NXT per JLRDA – the token that will swap 1:1 for IGNIS tokens when the Ardor Genesis block is created in November 2017. Each and every single batch until now has been sold out in 1 block.

For your reading pleasure, fellow Nxters, let’s quickly touch base with the nxtchat.slack Round 2 experience:

1st batch:

amsi [8:53 AM]
now !!!!!!!!!!!!!!!

martis [8:53 AM]
now!!!!!

gabriel [8:53 AM]
woooo

strophy [8:55 AM]
lol that went fast

josenxt [8:56 AM]
39,703.93 fee in that block? :scream:

lordcameltoe [8:57 AM]
how will I know if my transaction worked?

peter2615 [8:57 AM]
you wait… until next block, to see which offers got filled

As demand is a lot higher than the supply of JLRDA, and as the crowdsale is being held on a decentralized platform, executed under the rules of the blockchain, there were investors that didn’t get lucky. The rules are clear though and people’s different attempts to take advantage of them in the lottery, are transparent as well.

Logan summarizes:

You have to be in the same block, as the JLRDA TX. The capacity of one block is 255 TX. Higher fees are priorized to get in the block and the JLRDA TX will have a fee of 5 NXT. Thats the information you need to make a decision. But there is no right or wrong. Depends on what other people are doing.

riker [10:43 PM]

What happened in practice today was that one account NXT-GJE7-KWDJ-SFWJ-APQ6S tried to game the system by submitting many transactions with 5.2 NXT fee. I’m not sure what was his calculation. What it did is that it delayed the Jelurida transaction to the next block. But we anticipated this in advance and double checked that this does not provide any advantage to anyone.

bitcoinpaul [3:36 PM]

what can we learn from that?
dont bloat the chain with high fees, guys.

Riker

It’s a game theory problem; if everyone submits their transactions with 4 NXT fee, and a single guy with 6 NXT, this guy has an advantage. His transaction, the offer, and as many as can fit from the rest will fit in the block.

If everyone thinks this way and submits their offer with a fee of 6 NXT, all will lose, since their transactions will be included in a block before the sell offer.

forkedchain [5:33 PM]

For the latest JLRDA sell offer, there were 4 completely full blocks, each with 233 TXs, and an additional one with 58 TXs. There were 484 unique accounts that sent TXs in those 5 blocks.

2nd batch:

logan [9:01 PM]
dingdingdingding

vintash [9:08 PM]
yyyyeeees
im in!!!!

mroenne [9:08 PM]
Finally :sunglasses:

vintash [9:09 PM]
yeeeees

gabriel [9:09 PM]
YEAAAAAAH

marenkar [9:10 PM]
Whoa that’s a lot of people who got in this time.

peanut [9:12 PM]
Finally I’m in. I also noticed odd fee sizes, so I used one too just for good luck hehe

eu58 [9:14 PM]
I put 4 NXT for the fee and succeeded!

martis [9:18 PM]
I put 2 scheduled orders and both were filled. Fee was 4.9. No bot, no API, just used “Ignis token sale” link. Previous rounds were unsuccessful for me. As I reached my limit for buying Ignis, I will not participate in other rounds, so more chance for others.

forkedchain [9:53 PM]
I sacrificed a ton of ants just yesterday. ran over a huge ant bed with my mower while cutting grass, AND IT WORKED I GOT SOME JLRDA TODAY!!

logan [10:54 PM]

If i use a node with a comparatively bad connection and you use one which is a few milliseconds faster to publish the Offer TX, the chance that my orders will be filled is nearly zero, isnt it? or at least much worse compared to others

riker [10:55 PM]

Assuming you did everything else right, the more central and well connected your node is you’ll have better chance.

If you are the forger, even better, since then you have no latency.

forkedchain [11:47 PM]

well, it looks like some of my forging pool members were big winners today – all of a sudden my pools forging power has dropped by 5M.

My pool forged the golden block again. I wonder if some pool members had set up my pool as a well-known peer, and that’s why they won.

In lots of my previous attempts, my transaction was in the same block as the SELL, but at an earlier index position in the block. So I didn’t get anything. That means my latency to the forger was really good, but the forger’s latency to the p2p network (network as a whole) whereby that SELL transaction eventually found its way to the forger, was high – its all luck.

Batch 3:

jesus [8:54 AM]
woohhaaaa

thewiremaster [8:54 AM]
Go! https://nxtportal.org/monitor/

josenxt [8:55 AM]
269 unconfirmed transactions!

peter2615 [8:56 AM]
wow… NXT-3CJT-YF6A-VJ5D-DNSWR

gabriel [8:58 AM]
LOL, who was complaining about there not begin enough small transactions

mikevanegan [8:58 AM]
Booya worth getting up 2am. 295,000 JLRDA

peter2615 [8:58 AM]
lol @ NXT-GJE7-KWDJ-SFWJ-APQ6S

shugo [9:02 AM]
omg I finally got in, 4.9 fee
@all with no luck, dont give up (I almost did…)

vizanto [9:03 AM]
Your JLRDA balance 47,840 !!!!!!!!
this was my 3rd try

yelth [9:07 AM]
this was my 15th 🙁

winiusty [12:07 PM]
Hi guys, I bought while sleeping lol
strange feeling

gabriel [3:20 PM]
only problem is the people who couldn’t get in until now and are frustrated, which is totally understandable, but as time goes by, more and more of these people are getting their orders fulfilled, so it will eventually work out just fine, imo

yelth [3:22 PM]
Potentially, but I can just as easily see there as being huge problems with it later on.

potshot-rsa [3:45 PM]
I got my IGNIS at 2017/08/09 8:59:12. I’m in South Africa with a 4Mb/s ADSL connection.

jesus [3:23 PM]

@yelth, i stopped worrying about it. it´s what it is. every other setup would have been stretched to the limit as well. I can see the jelurida marketing machine start working, that´s my main concern. looking at my ARDR and NXT investment, the ICO is a good thing. if i can´t get in cheap, so be it.

And so…. 1 batch left of Round 2. Join nxtchat.slack to ask questions and take part in the discussion. And if you wonder what all the fuzz is about – oh man. The IGNIS whitepaper, and all ICO details can be found here.

These are the stats from the ICO so far:


Live data from the Nxt blockchain

Jelurida AMA on Cryptocopia

For those of you who do not know, a semi-private AMA (Ask Me Anything) session with Jelurida occurred on the Cryptocopia Slack last Wednesday, August 23rd at 22:00 CEST. Jelurida spoke at length with the community, answering many questions about the now-in-progress, IGNIS ICO, Nxt, the blockchain, and much more. Only registered members of the Cryptocopia community could participate, but since we are so well connected we have you covered!

Cryptocopia’s registration-page has been offline ever since they made the AMA announcement, but here we give you an abbreviated, “best of” version that has all the relevant information and highlights that you need to know.

myco [10:02 PM]

Hello, and welcome! The Jelurida AMA is starting now!

Our guests from the official Jelurida team are:

petko

Hi! My name is Petko Petkov. I am a software developer. I’m contributing to NXT since Jan 2015. Then participated in the design and the development of the Ardor platform.

tomi

I am also a software developer, with more than 15 years of experience. I survived the dot-com crash, worked for a few companies in the Silicon Valley, then for a small startup, then became interested in crypto and Nxt in particular a few years ago. Now I am a part of the core Nxt development team.

The other core developer, Lior Yaffe, unfortunately couldn’t attend this AMA tonight as he is not feeling well. Lior Yaffe is a very talented developer and also lately doing a big part of the project management.

kristina

I am not a developer and before becoming interested in cryptocurrencies and blockchain technology I have been working as a legal advisor. I have been following Nxt from its very beginning and when Jelurida was created last year I became an official part of the team because the developers were looking for somebody to take care of organizational, administrative and legal tasks. Now, with the company growing bigger and the upcoming launch of Ardor, I am fully occupied with work and 100% devoted to it.

What will happen with NXT?

Q

myco

I know that we’ve gone through several stages in the transition of NXT to IGNIS and ARDOR.

Could you explain at a high level what is happening with NXT for those who do not know much about it?

kristina

Ardor can be considered Nxt 2.0, because it is being built using proven Nxt technology. The Nxt public blockchain, and software, will continue to exist and be maintained by Jelurida.

There were quite a few technical reasons why Ardor had to be started as a separate platform, and it wasn’t possible to just upgrade Nxt to it.

petko

NXT is an open-source project and POS-based cryptocurrency. We are planning to continue maintaining it, but after all, its the NXT stakeholders who decide whether to use the software we develop. So, there is no actual transition – we had the idea about Ardor and decided to work on it. NXT will continue to exist one way or another. As @kristina explained, there are technical reasons that prevent us from upgrading NXT to Ardor. But we distributed the Ardor tokens to the NXT stakeholders at 1:1 ratio.

Q

dereje

With the development of ardor and jlrda, do you see nxt eventually dying out from lack of support and development?

tomi

We have promised to support Nxt for at least a year, or longer, depending on the funding level obtained in the ICO, and depending on the demand for it. We will also backport features from Ardor to Nxt, if we can hire enough developers to dedicate to that. We expect that Nxt will stay as the stable, well tested and reliable platform. And not all use cases need Ardor with its multiple child chains (which also brings complexity).

kristina

please remember that Nxt is a proven and stable blockchain with a large variety of features, a platform well suited for ICOs for example which is a functionality we plan to further enhance.

Jelurida

Q

myco

What is the development like for Jelurida?

Do you work remotely, or do you have an office where you meet?

tomi

We don’t have an office, working remotely all the time. We do plan to establish a physical office however, depending on the success level of our ICO.

Q

myco

What are the upcoming tasks that the Jelurida team is focusing on in the short term?

kristina

After our ICO is over the snapshot will follow and of course the launch of the Ardor platform.

Q

sanchopansa

How many people are working full-time on the project?

kristina

4 (3 developers and myself) + 2 part time developers.

Q

sanchopansa

How do you plan to generate revenue and when do you foresee to become profitable?

Kristina

We have several possible sources of revenue – licensing of the software for private blockchains, child chain creation, and revenue sharing with businesses that run child chains, consulting, custom wallet creation. Other minor revenue sources are listed in the whitepaper.

We aim to become profitable and self sustainable by the end of 2018.

Q

doubleqp

How much funds do you expect to need until the end of 2018 to survive?

kristina

what we have collected already is enough to survive until the end of 2018.

Q

doubleqp

So what’s your reason to collect even more money?

Kristina

For two reasons: we have a detailed plan how we can utilize the funds up to €50M.

And because we exist in a very fast growing field where our competitors raise/have raised millions which they are using for marketing and because we cannot allow a technology with such a great potential not to succeed.

marenkar

In section V3 of the white paper, (https://www.jelurida.com/sites/default/files/JeluridaWhitepaper.pdf) Jelurida goes over their plan with regards to the amount that they raise (starting on page 36). More funds raised generally means a larger team, more projects, and more business activity.

tomi

Jelurida was established last year as a corporate entity to manage the development of Nxt and later Ardor. Before that, Nxt was developed as a volunteer open source project, without a legal entity behind it. This was problematic when trying for example to license the Nxt software for commercial purposes, and when having to protect the IP behind it.

IGNIS ICO < > NXT ?

Q

myco

When will the IGNIS snapshot take place?

vanbreuk

From https://www.jelurida.com/ico, “The Ardor Genesis Snapshot will be performed at least two weeks after the end of the last JLRDA sale round”. But no exact date has been announced yet.

Q

myco

What happens to the NXT collected in the ICO for IGNIS?

tomi

We will be selling most of the NXT for BTC and fiat, because the purpose of collecting it is to provide funding for the company. We have been very clear about that in the whitepaper. Some amount of NXT, up to 40 M, will be kept by the company.

Q

myco

It seems like selling the NXT you receive in the ICO for BTC and fiat will make the NXT have a much lower value.

Who will be buying the NXT from you? people who want to hold for the IGNIS snapshot?

tomi

We have already sold most of the 24 M NXT collected in the first round, it didn’t crash the price. We expect people who want to participate in the next rounds, or didn’t have a chance to buy in the previous, to be buying this NXT. And at the end, indeed those who want to hold for the snapshot. But even after the snapshot, we believe NXT will continue to have value, and this value will probably become stable, as no major disruptions will happen to it anymore.

kristina

People believed that NXT will lose value after the Ardor asset was launched too, but it didn’t happen… It indeed dropped temporarily but after that it went back up again…

Q

myco

What new functionality is present in IGNIS that was not present in NXT?

tomi

We have a feature comparison table on the website, few things I can think of: asset dividend payments using other assets, or MS currencies, or other child chain coins; asset share increase transaction; smart phasing (a boolean composite of phasing conditions); asset control…

About Ardor

Q

myco

What is the current status of development on ARDOR? When will that be a useable technology in production?

tomi

It is running on testnet now. The multiple child chains framework is implemented and working, you can try it. We are planning a new testnet release some time before the snapshot, which will introduce some innovative features – smart phasing and asset control for example.

The pruning and snapshotting parts of the Ardor design are currently being worked on, and will not be part of the initial release, they will be ready later. See the roadmap on our website for all details.

Q

myco

What mechanisms would cause the rise in price of Ardor? What is Ardor used for?

tomi

Ardor will only be used to provide security for the whole system, it is the token used in the proof-of-stake algorithm. It intentionally has very limited other functionality, as Ardor transactions by design must remain in the blockchain (and cannot be pruned like child chain ones). Having significant Ardor stake will allow users to run forging nodes, and collect fees from all child chain transactions (converted from native tokens to ARDR by their bundlers).

myco

I can understand that value if you get native tokens from staking ardor… but why would I want to get more ardor for staking ardor if there is no additional utility to it besides getting more ardor? It seems circular. what am I missing?

petko

Ardor is like the mining hardware in bitcoin, minus all the wasted electricity

marenkar

For child chains to run, bundlers will need to exist to collect child chain tokens and then pay ARDR to the forgers to process the transactions. Any account can opt to be a bundler as long as they have ARDR and set the rate they want for accepting child chain coins relative to the ARDR paid out to forgers. Transaction fees paid out to forgers will be fixed based on the amount of data processed and/or the type of transaction and have a similar fee structure as that with Nxt ( `https://nxtwiki.org/wiki/Transaction_Fees` ).

In terms of value, assuming all other things held constant, the more child chains on Ardor and the more activity on the child chains on Ardor, the higher the demand for ARDR as the need for it increases to handle the increased demand for transaction processing.

Q

oojacoboo

So Jurlidia needs money to develop Ardor so it can try and sell sidechains to companies?  That the tldr; ?

tomi

Child chains can be useful not only for companies, but for the general public, even when there is a company behind a particular child chain. For example a pegged child chain, with token value fixed to fiat currency, maintained by a 3rd party business who charges commission on entry and exit from the system – but all users than can transact with this currency on the blockchain, denominating their transactions in it. And the Ignis child chain, for which the ICO is being conducted, will always remain decentralized and accessible to everyone.

kristina

not only creating child chains, but also private blockchains – it depends on the use case

and please note that the Ardor child chains are not side chains. The difference between them is explained in our Whitepaper.

Link to white paper – `https://www.jelurida.com/sites/default/files/JeluridaWhitepaper.pdf`

Link to page about side chains vs child chains – `https://www.jelurida.com/child-chains-and-side-chains`

Q

sanchopansa

What are the major industries/verticals that you are hoping would be using NXT?

tomi

Banking and financial sectors, asset issuance and trading, voting (including shareholder meeting voting), crowdfunding. We have been in talks to several banks that are testing internally our technology, but since this is under NDA I can’t mention names until it becomes publicly known.

Q

sanchopansa

Do you have any commercial partnerships/deals that you can talk about?

kristina

The ones not covered by NDAs – we have partnerships with companies/projects like TLVC, Beecrypt, Bitswift, Sigwo Technologies and quite a few others to be announced soon…

Q

sanchopansa

If I understand correctly, you’re in the blockchain-as-a-service space so that would make Stratis, Lisk, Ark and maybe to some extent Ripple your competitors. Why would any business use Ardor instead of these other options?

tomi

We believe that our parent – child chain architecture is currently unique in the blockchain space, and it opens the door for even more use cases and a greater interoperability between child chains. It also solves the blockchain bloat problem – which I don’t believe those other platforms have a solution for. Ardor is based on the tested and stable Nxt codebase, and has a very rich feature set which will be carried over to it from Nxt.

Price speculation

Q

myco

Why do you think that NXT has been left behind in price, relative to new coins coming out in the past year?

marenkar

There’s quite a lot of reasons because Nxt has existed for quite a long time, such as a lack of a proper team, which Jelurida now fills, a lack of funds, which this ICO now aims to address. Also it being the first Proof of Stake platform during a time when everyone wanted to mine held things back a bit. I made a long post about it if anyone’s interested – `https://www.reddit.com/r/NXT/comments/6m2tyd/why_did_nxt_never_catch_on/djyjxa6/`

Q

myco

What are you going to do differently with IGNIS to make a token that people want to hold?

Or will you focus on making money through corporate consulting use cases?

Petko

My personal opinion is that there is no need to do something special with IGNIS in order to differentiate it from the other child chain tokens. Same like NXT – everyone is free to clone NXT and start another blockchain and token (and there are many clones existing), but the NXT token only one

Q

oojacoboo

And why would I want to own any JLRDA tokens?  What value do they have, since this is a funding model for Ardor…

thewiremaster

The JLRDA MS tokens represent the IGNIS tokens you will get at Ardor launch.

vanbreuk

If a company is funded for developing the platform where your tokens are used, there is a much bigger chance that tokens will appreciate in value. I don’t understand the question.

kristina

Yes, we are selling tokens, that’s right. You may want to fund the development of Ardor because it will be a scalable PoS multi chain ecosystem – it will be the next big step in the blockchain industry

marenkar

Ignis will be the first child chain on Ardor. The Ardor main chain will not have substantial features as it is intended to secure the Ardor network and not be a regularly-used chain. Ignis provides an unrestricted way for users and organizations to utilize the features of Ardor, such as creating an asset or setting up a decentralized poll. Transaction fees to do these transactions will be in IGNIS not ARDR. Other child chains will also have these capabilities but they may set restrictions on them.

The JLRDA > IGNIS ICO

Q

myco

Where can we find the best instructions for how to participate in the ICO? The software used for the ICO is different than the BTC/ETH icos we’ve been participating in lately

tomi

Since we are running our ICO on our own blockchain, it is using the Nxt wallet. It may indeed look different from the BTC and ETH client, but shouldn’t take long to figure out, and especially for the purposes of the ICO we added a separate page – accessible from the Ignis Token Sale link in the header, which really makes it easy.

But do read the instructions on our jelurida.com/ico page, there is also a video showing how to do it, and we plan to post more instructions in a video or pdf too. And remember, only use the IGNIS Token Sale link from the header – do not buy any similarly named tokens/assets/marketplace goods, as unfortunately there have been scammers selling fake JLRDA or Ignis tokens.

Q

myco

What does it mean that IGNIS is “fully permissionless” compared to other child chains

kristina

It means that it is open for everybody to use freely. Other child chains will be associated with a specific use case, a company or an organization behind them. Some of them may want to implement restrictions such as KYC for example….

tomi

Permissioned blockchains is something our enterprise customers ask for, as they want to be able to control who can connect to the blockchain (read access), who can send transactions (write access), and who can give or take such permissions (admin access). Some of this functionality will also be added to child chains that may need it.

Q

lordcameltoe

How will the next IGNIS sale be handled to avoid having whales scoop up the majority of coins before everyone else?

tomi

Everyone has equal chance to participate in the Ignis sale, using our scheduled transaction feature which automatically submits their purchase transaction as soon as the sale offer is posted. And the batch will be split into 4 rounds of 20 M each, again to give users multiple chances to participate.

lordcameltoe

So the technique one person used last time to get most of the tokens has been patched?

vanbreuk

Rather than patched, the Nxt Client now allows for everyone to place a buy order in advance, before the next batch of tokens is effectively placed for sale. So the tactical advantage of that person in the first few batches is not there anymore, since anyone can do it from the client.

marenkar

I’m not 100% sure how it works but it ends up being a lottery of sorts. Some users couldn’t get in, others could. A few users were able to get in even without the scheduler though, but that was rare. Well, at least from what people claimed on Slack.

Thanks for tuning in, dear readers. That was an interesting and informative AMA from Jelurida. They clarified a lot of their plans and continued to bring attention to the IGNIS ICO.

For our ongoing coverage of the ICO, we have our special report series and a weekly Nxter Newsletter, that follows blockchain trends and reports on the last week in the ever growing world of the blockchain. Follow us on Twitter for important breaking updates as they occur. Stay informed and keep reading.

Help us grow and help us continue to provide excellent and focused coverage on the ever growing blockchain space by rewarding us for our efforts: Donation address NXT-TK9J-MEKH-MUP9-HFCH2.