Ethereum and NEM: Two Different Approaches for Blockchain Application Development
After working on Ethereum for a while, I recently got a chance to take a look into NEM. And I see two very different approaches they are taking when providing a blockchain environment for building applications. In this article I will put them down and do a quick comparison between them.
Overview of NEM
There is much more information on Ethereum in the market. Therefore here I am giving a quick overview of NEM.
NEM is a home-grown blockchain technology, which can be deployed as both public and private ledgers. Here we focus on the public ledger.
NEM comes with a native currency XEM. Like ether in Ethereum, XEM is used when one uses services on NEM. XEM is of fixed supply, and the incentive of block-building (harvesting, loosely equivalent to mining in ethereum) is the transaction fees when NEM services are consumed. NEM also comes with a different consensus algorithm called Proof of Importance, which adds certain factors when considering one’s chance to harvest. In general it is also a permissionless approach just as ethereum (and bitcoin), that everyone can participate into the block-building.
How they provide an environment to application development is of my interest. NEM is taking a different approach from Ethereum. While Ethereum is a platform which allows application developer coding on the blockchain, NEM provides certain useful and handy services that developers can access at any time.
Here are some facts when comparing these two blockchain platforms.
Let’s go further into these two approaches on application development.
Ethereum: Platform for Coding
In Ethereum, developers have flexibility to code something new. While we can only code according to what Solidity and the opcode provide, from what we have seen in the market so far, there can be many types of applications in this platform.
We can easily find sample applications and make reference to them when we code (or learn to code). There are also some libraries created for specific purposes. As an example, Open Zeppelin (link) provides libraries for token and crowdsale. Most of these codes are made open and publicly accessible, and being used in many deployed contracts.
However, this is also where problems come. When we are using the code or libraries provided by third parties, it is our responsibility to make sure they do not come with problems, and we should have the knowledge to get rid of them. The recent overflow problem in ERC20 (link) already gives us good lesson. Simply copying code somewhere may cause big trouble, and sometimes we just overlook some latest good stuff (such as the use of Safemath in Open Zeppelin to address overflow problem).
NEM: Platform for Services
NEM is taking a different approach: while the bottom is still a public ledger, NEM provides certain useful and handy services that developers can consumes when they build their applications.
NEM must have done great study on the market need of services. Besides simple fund transfer (transfer XEM from one account to another), they bring in some unique and useful services such as multi-signature accounts, message encryption, notary service (Apostille), smart assets (Mosaics), and I am sure they will come up more when they see the needs.
This article does not go into detail on how these services work. You can find more and better information in NEM’s documentation.
While these services more or less can be implemented with contract codes on Ethereum (and some have been done already), NEM makes them available immediately, either with its wallet or through API. API (application programming interface) is no stranger to developers as applications nowadays require interfacing various services through API. Developer therefore does not need to reinvent the wheels, but simply picks the service they need, and uses it.
This makes the application architecture neater: developer focuses on the business logic, and the services are called (or consumed) when needed. This much more aligns to today’s development manner. Also, as these services are now maintained by NEM, it comes with assurance “to certain extent”. At least, when problems appear, we know who to blame.
This approach, however, comes with shortcoming. Developer can use only “what it is”. While NEM is building whatever possible to meet market requirement, there are always cases that existing services cannot meet developer’s need.
There is no room for contract-like programmability on NEM blockchain currently: no Solidity-like coding language. Everything on NEM today is built by NEM themselves.
What can developers do then? To certain extent they have to wait for NEM to release new on-chain features, or they build the “off-chain” services by themselves. Anything built outside the NEM does not come with the beauty of blockchain, and the public may question the level of assurance if they are not coming from NEM.
The following diagram summarizes the two different approaches in blockchain application development.
The application code developed is orange in colour. As seen in the diagram, in Ethereum the contract code is needed when interacting with Ethereum blockchain, while in NEM, several well-built services (such as multisig account, smart assets, etc) are provided by NEM platform and application developer simply calls these services.
If you are faimliar with terminology XaaS (X-as-a-service) in cloud, I can roughly say Ethereum a Platform-as-a-Service (PaaS), while NEM is more like a Software-as-a-Service (SaaS).
I believe these two camps are not born in competing each other: they just take two different approaches when using blockchain technologies in real life. Application developers, when they build their applications with blockchain capabilities, can now have a choice: they can either build some on-chain business logic on Ethereum, or off-chain application simply leveraging the capabilities NEM is providing.