NewsBTC recent got a chance to speak with the founder and creator of eMunie, Dan Hughes. As we dwelled into discussing this young cryptocurrency, we got to know about the purposes it is meant to bring. Hughes discussed how it took him almost three years to build a truly innovative currency, and how he wishes to push it further ahead once it comes out of the beta phase.
Here are the some of key excerpts from our interview with Hughes:
Q: What is the history of eMunie?
eMunie has been in development now for around 2.5 years, with the first code cut back in March 2013.
That seems like only yesterday but a lot has happened since then, not only with the progression of the technology but also with general project dramas! This will probably be quite long….
Before starting the eMunie project, I was looking for something new to get my teeth into and had known about Bitcoin for some time. I hadn’t actually dug into Bitcoins innards at the time due to other commitments, so I decided to investigate, learn the technology, and see if I could come up with any interesting projects ideas to develop.
As my investigations took me deeper into Bitcoin and block chain technology, I realized that although this was extremely ground-breaking stuff, it was still very much a proof of concept/experiment. I feared that it could potentially trip over its limitations and short comings in the future as it grew, which ultimately made me question my decision to develop for it.
Instead I decided to take Bitcoin as inspiration, and attempt to develop a technology that complimented what was genius, and overcame what was lacking. I spent about 6 months in total forming ideas, drafting architectures and such to determine what was possible before actually starting the eMunie project.
I originally thought that I could develop the technology and have a release candidate ready in 6-8 months, which was achievable with the original scope. As I progressed with development I found myself questioning some of the initial design (as it employed a block chain) and its ability to meet the goals I had set. I decided that it wasn’t good enough and I wasn’t prepared to compromise, after all, I was self-funding and for once in my career I didn’t have a client calling me up every day for progress and setting deadlines.
It was at this point that the project took its biggest step away from Bitcoin. I spent a few weeks developing a block tree idea to replace the block chain, as it would allow for a greater throughput of transactional load and better chance of meeting the goals I’d set. I re-scheduled the planned release date and carried on development full steam ahead.
With the planned release date fast approaching and development going well, I decided that although it was viable to continue to self fund the project post launch, it made better sense to have some external financial injection which could be used to continue development and promote eMunie more efficiently. A short fundraiser was held and met with a good response, with a large majority of community members pledging financial support to the project and I was now certain that eMunie could achieve all I had planned.
Unfortunately not long after, the project met its biggest challenge to date and it surprisingly wasn’t a technical one.
A hacker had managed to get obtain access to fundraiser and personal Bitcoin wallets, along with a number of my online accounts such as email, exchanges, forums, even the damn ISP control panel for our servers was breached and subsequent havoc was caused. We had been suffering from a high amount of attacks on our servers for a couple of weeks prior to this breach, but (wrongly) assumed that sufficient security was in place both at our end and any service providers we were using.
As a result a significant amount of Bitcoin was taken and the fallout from this event was quite spectacular to say the least!
The announcement of the theft was met with gross cynicism, which was to be expected, as there were then as still today a lot of scams going on in the crypto-space. More damaging was that a lot of the project supporters who had pledged financial support also got cold feet and wanted out. In all over 900 BTC was taken in pledged and personal funds, at a time when BTC was at the top end of $600 in valuation. Unsurprisingly a lot of people didn’t expect me, nor the project to survive it and wanted off the ship with their pledges back ASAP before the project folded!
Thankfully prior to eMunie I’d had a few lucrative ventures which I’d exited at the right time, and so was privileged to have a good amount of financial security. Over the course of a couple of months, much stress, and endless juggling of assets, every single person who wanted out got their pledges back.
These events set the eMunie project back significantly! Not only in a financial manner, but also the emotional toll on myself was extreme and intensified further following the theft with constant accusations of me/eMunie being a scam/vapourware and my focus suffered for months after.
I wasn’t going to be beat though, and not once did I think about quitting. With help and support from our community I eventually got back to my focus and started to push on further. In order to continue funding the project and ensure I could do so for the foreseeable future, I sold my home and any remaining valuable assets and moved into a smaller place. The original funds I had left over from my previous good fortune after covering the theft and reimbursing over half the pledges, plus the liquidation of those assets have kept the project going up to this point almost 18 months later.
After all the noise and distraction of the previous months, I decided it was best to go under the radar, push on and adopt an “its ready when its ready” mentality. From that day until only a few weeks ago, I rarely surfaced in the crypto-community and concentrated solely on development of the project.
Moving on, towards the end of 2014 a lot of progress had been made and with most of the scope for a V1.0 complete, a launch was finally within reach and was possible in Q1 2015. However I was having some reservations about the viability of the block tree technology I’d developed, as we were having issues obtaining the VISA scale transaction loads it should (in theory) of been able to support during testing and I was concerned that these issues might cause problems later if I could not find a solution.
I continued with development while pondering solutions to the problem and what to do. This was probably the toughest decision I’d ever had to make with regards to any project. Scrap a large portion of already innovative design for something entirely new, untried, but potentially better, or compromise, continue and kick the can down the road as a possible launch was so close.
Eventually after weeks of consideration and for a 2nd time in the projects development, I decided to scrap the existing technology, now the block tree, in favour of an idea based on channels.
During December of 2014-Feb 2015 I implemented the new ‘channelled ledger’ design and rolled out the first test client to the beta testers. Results of testing locally had been impressive, but controlled test results mean nothing as the real world always throws unconsidered factors into the equation.
The gamble was worth it, even the first implementation of channels was out-performing the block tree in a number of areas, while allowing flexibility and feature possibilities that block chains or trees would be unable to provide. Today, 6 months on, scrapping block trees in favour of channels was the best decision I have made so far with regard to the project and it will allow eMunie to meet and exceed many of its original goals.
How is eMunie different from Bitcoin and other altcoins?
There are a many differences that set eMunie aside from Bitcoin and other crypto-currencies as it is intended to be a general purpose financial, communication, and storage platform covering many use cases. Ultimately the end goal is for eMunie to provide a secure and self contained eco-system where users can transact, trade and communicate.
Communication is a big part of our roadmap, and the platform will support a number of communication methods over time. The initial eMunie release will include simple inbox messaging (with attachments) and chat rooms, and be extended over time to include instant messaging, micro-blogging, social networking, voice & video calling and more.
Trade is also a big deal for us, and the initial release will include an rich eBay-esque marketplace where users can buy and sell goods of any kind and also a decentralized exchange for trading assets (the DEX is also important for economics).
That aside, perhaps the most critical of all differences are the ledger technology, consensus algorithm and the economics of the base currency EMU (electronic monetary unit) which adopts an elastic model.
Ledger
Getting to the ledger first, eMunie does not use a block chain as already mentioned. Instead we developed a technology called “ledger channelling” which affords eMunie a number of benefits both in terms of performance and flexibility.
Rather than track payment outputs, which are later used as inputs (as most block chains do) the channelled ledger tracks balances instead, with the transactions for each balance identifier residing in a channel. The philosophy is that it’s more efficient to prevent 100,000s users balances from becoming negative, than it is to check every transaction input those 100,000s of users make across the entire ledger to ensure integrity.
Bitcoin and many other crypto-currencies that adopt the input/output model, need to have a record of all unspent transaction outputs (UTXO) available at all times so that new transactions can be verified accordingly. This record is usually in RAM for performance, and as the number of users, and thus transactions, grows so does this UTXO. If a crypto-currency was to achieve even a portion of VISA scale loads, this UTXO would grow quickly to be 10s if not 100s of GB in size.
Balance tracking removes this potentially resource hungry requirement, as checking the sum of all transaction activity in a single channel to ensure enough funds for a spend is much more efficient, can utilize disc storage and so is more resource friendly.
Furthermore, the act of tracking balances and adopting channels allows eMunie to be the only platform able to support native, decentralized debit cards that can utilize existing hardware that merchants already own to process VISA/Mastercard payments. These debit cards can be issued by a trusted 3rd party in the usual manner, or, and more importantly, a user could create their own with cheap, easily purchased, off the shelf EMV reader/writer hardware and a blank card.
Another innovative feature that a channelling allows is the act of partitioning the full ledger into more manageable chunks efficiently and securely. Instead of scaling vertically like all other platforms, eMunie scales horizontally.
Due to channels being isolated from each other, a node in the network that is resource or performance limited can opt to serve only a portion of the total ledger to the network, instead of being excluded completely as the network load grows and it becomes overwhelmed.
The improved performance that balance tracking and channels provides, plus the act of partitioning allows the network to have extremely high rates of transactional processing capability.
For example, lets assume that the entire eMunie network consisted of 1000 Raspberry Pis and that each could process 20 transactions per second. Without partitioning the total network load capacity is 20 tps and no more. With partitioning, it is possible to configure the network so that the entire transactional data set is split into a number of partitions.
Say for our example we wanted 10 partitions, with each partition containing a near equal distribution of channels. Across 1000 Pis we could achieve a redundancy factor of 100, with 100 of those Pis holding partition #1, the next 100 holding partition #2, and so on.
Those 1000 Pis can now parallelize the total load, so even though each partition can still only support 20 tps, there are now 10 partitions, so the total network load capability increases to 200 tps. When considering the additional overhead of communicating and managing the partitions, the reality would be a load capacity of around 170 tps, still much improved over the original 20 tps.
If more powerful hardware is used as a measure of baseline node performance, and a larger number of partitions are adopted , it should quickly become apparent that the load scalability of the eMunie network will be second to none and could potentially exceed many 100,000 tps.
Consensus
Active consensus in eMunie is achieved by relying on an ever evolving set of signees who vote on the current state of a set of data and in the event of a conflict, the state with the majority vote wins. The signees must be service nodes (SN) which will typically take part in maintaining the ledger (or a partition of it), but may also provide other services such as messaging, marketplaces, chat, storage etc. Due to the flexibility of our consensus algorithm, this same algorithm can apply consensus not only to transactional data, but any set of data for which there are service nodes associated.
The process is really quite simple, focussing on transactions, every transaction that is created contains endorsements of one or more service node IDs (SNID) that the originating node (ON) creating the transaction is connected to. The ON takes steps to verify that these SN are really doing what they claim by presenting simple zero-knowledge proofs of work periodically, the SNs that pass these simple tests are then eligible for endorsement in transactions the ON makes.
These most recently endorsed SNs are then the next set of signers which vote to determine the correct set of transaction data making up the current ledger state. SNs who voted differently, or non-SNs that have the incorrect state, can then take measures to add/remove transactions so as to align with the majority. The process then repeats using the endorsed SNs in the next set of transactions, and so on, providing an ever changing set of signees, but a reliable and secure consensus.
Economics
Economic stability and price volatility is a key issue plaguing Bitcoin other crypto-currencies and is proving to have a detrimental effect on adoption by the mainstream.
A key catalyst of these issues faced by other currencies is the utilization of a fixed, or limited supply, in an attempt to create a deflationary currency as opposed to a static or inflationary one. There is a general stigma associated to anything labelled as inflationary and the gross perception is that inflation = bad / deflationary = good. Rarely though do I witness supporters of the deflationary model really understand the meaning of both theories in the various contexts they are used, nor do I see a common understanding of the pitfalls of both.
The root problem with deflationary economics where a currency has a limited supply and strict, constant emission policy is that the value of a currency unit is extremely sensitive to even the smallest of change in demand, and due to the fixed and regulated nature of the supply, only one of two variables of the currency, value, can change to align with supply and demand.
Compounding the problem further is that a deflationary currency is seen as a good investment vehicle, so speculation is also rife.
Finally is the distribution problem of new currency units, which is generally concentrated to less than 1% of the user base, further exacerbating the potential for volatility and manipulation.
Ultimately both inflationary (fiat) and deflationary (Bitcoin) economic models can be very destructive if not managed correctly, employ weak policies, become susceptible to human manipulation or badly implemented.
eMunie attempts to address these issues by adopting a number of innovative ideas, which when applied in unison, should ensure a stable value over time, defence against manipulation, and a fair distribution of new currency to the user base.
We looked at the currency supply first of all and decided we had to consider both variables of currency, that is value and quantity, to achieve long term stability. We adopted an elastic supply model whereby the amount of currency in circulation at any point can increase or decrease depending on a number of signals, mainly collected from the integrated decentralized exchange. The sampling of demand to supply can be frequent (per minute sampling or less), and primarily considers order price and volume over a mid-long term sampling period.
Using these and other related metrics obtained from the exchange is sufficient for the system to have consensus on the optimum amount of circulation required at any moment. The network as a whole can then take steps to increase, or decrease the supply, which switches the economic model from inflationary to deflationary and back as required. As a result, long term value stability can be obtained with up or downward trends of value becoming much smoother and more predictable.
Second on the list was short term value swings, or more specifically, manipulation via pump and dumps and other tactics. We wanted to ensure long term stability, allowing gradual trends and movements in value, but stamp out short term spikes.
This is achieved by way of a currency buffer, which the system and only the system controls and is fully automated.
Simply the mechanics are as follows: in the event of a pump, whereby a party is buying up large amounts of EMU on the internal exchange to elevate the price, the system will respond by selling a quantity of its reserves at a price more in line with the long term trend thus keeping the price down. In the opposite case and in the event of a dump, the system will buy the EMU being sold at a price more in line with the long term trend, thus keeping the price up.
The buffer is also a primary factor in reducing the currency supply in the event of excess, as reserves can be burnt.
Generally the system will attempt to maintain this buffer at an appropriate level to ensure it can quash all but the most serious of manipulation. It will itself receive a portion of newly created supply, ensuring that is always has a good means of combating short term swings and keeping volatility to a minimum.
How does one earn eMunie? Can it be mined?
The base currency unit EMU can be earned in two ways and does not involve mining. Mining is not a suitable method for new currency issuance as it cannot achieve two of eMunie’s core goals, which are efficiency and fair distribution. While the former can be achieved with Proof of Stake algorithms and other variants, the latter is much harder to achieve with current algorithms, thus eMunie takes a different approach.
The first method is simply interest on account balance, whereby an account with an EMU balance can claim a portion of any newly required supply into existence. 50% of new supply is allocated to balances on accounts, with the other 50% being allocated to the second issuing mechanism.
For example, should the total amount of EMU currently in existence be 100,000, and a total supply of 110,000 EMU is required, 5000 EMU is allocated to balance on account claims. Therefore an account with 1000 EMU can claim 50 of the 5,000 allocated from the total 10,000 EMU deficit.
These claims, or interest, can be made at any time and an account does not have to be online to be eligible. An account may be offline for a prolonged period of time, and upon that account being opened in the users client, any and all past interest claims can be made.
The second method of new currency issuance is a little more complicated and addresses the “lottery problem ” of proof of work. Unlike Bitcoin and others, in eMunie every node is paid for work done in the system, and can claim a portion of the new supply according to that work metric.
Work done by a service node is determined from the endorsements that are present in transactions. These endorsements give a fairly accurate picture of what SNs are online at what times, and how much work they are doing. A service node that is connected to a lot of nodes and doing a lot of work, will have a higher number of endorsements over a period of time than an service node that is connected to fewer nodes and doing less work.
From this information we can then apply a similar procedure as we do with balances on account, but rather than using balances, we use the quantity of endorsements.
As per the previous example, should the total amount of EMU currently in existence be 100,000, and a total supply of 110,000 EMU is required, 5000 EMU is allocated to work claims. Assuming that 10,000 endorsements have been made since the last work claim was presented, and the claiming node has 1,000 endorsements in that time, that node is therefore able to claim 500 EMU of the 5,000 allocated from the total 10,000 EMU deficit.
These two mechanisms of supply issuance ensure that new supply is distributed fairly, balance interest provides an incentive for those that do not wish to run service nodes, and an accurate work record ensures that operators of any service nodes are paid accordingly for any work that they do.
Doesn’t anonymous transaction service expose eMunie to legal threats?
This possible future threat was considered from day one, and we wanted to protect the platform as much as possible while still providing anonymous functions for users that want it. We decided to allow aspects of anonymity to be configurable to the users requirements.
In the default configuration, the first release of eMunie will be pseudo-anonymous, but offering a slight improvement over Bitcoin and other crypto currency platforms due to address decoupling and encryption of meta data.
If a user wishes his transactions to be public and identifiable, perhaps a merchant for tax return purposes, he can configure which components of the transaction should be created without encryption, and can opt to include some other identifiable information if he wishes.
In the case of the merchant receiving a payment from a customer, the customers details would comply with the settings they have selected and be protected if configured as such, whereas the merchants would comply with settings he had chosen.
Should someone then wish to audit the merchant with modified settings, they will be able to ascertain that the merchant has received a payment of 10 from party C the customer, or sent a payment of 15 to party D, but will not be able to view the address or other information of C or D unless they too have configured it to be public.
We think this is an acceptable solution to allow those that need to be identifiable for legal reasons to be so, and those that wish to be anonymous to have their needs met.
In later versions of eMunie, full anonymity features are on the road map moving forward as we wanted to concentrate on speed, scalability, economic stability and ease of use for V1.0. That said, the options highlighted above for configuration will also be present in later, improved anonymity features.
When can we expect eMunie to come out of beta phase?
Internally we have a tentative expectation that this should be sometime in Q1 2016, this is subject to change should it be required as we’d rather do it right than rush out the door and have to manage the inevitable issues. The most reliable date I can give you will be on the day it goes out the door.
However, development of the core is around 90% complete, the core being the main dictator of when a release will be possible, and as yet there is no indications that Q1 is too far out of reach.
Lots of other work is also underway such as the development of mobile clients and the team should have the first versions of these in 2-3 months, further development of the debit cards and integration, APIs, scripting tools and lots of other interesting stuff.
What are eMunie’s future plans?
Once the final stages of development are completed and eMunie is ready to launch, marketing will be a key area of focus and priority. I’ve found that this is lacking in all areas of the crypto-currency industry, and marketing is nearly always given a back seat.
We have a comprehensive roll out and marketing plan devised and ready to go, targeting multiple territories, demographics and industries which should see eMunie make fast progress on the adoption front.
Primarily we are targeting mass market users/ consumers and developing a number of major retail opportunities, both on and offline, to assist in building a large infrastructure quickly so as to allow real world use of the platform and currency.
A key component of the offline rollout is of course the native decentralized debit card, as it lowers the barrier to entry for non-technical individuals allowing them to use the platform in a familiar manner and reap the benefits. It will also allow merchants to accept EMU and other supported currencies with zero cost or additional outlay.
We’re also planning our various advertising campaigns, which will encompass modern and traditional media types and attempt to demystify digital currencies to the mass market as well as promote the eMunie brand.
Finally we will be attending a number of conferences and events such as CoinFest 2016, of which we are a global sponsor, so that we can engage with the industry, users and potential partners actively.
Funding all of the above will be interesting, but we’re now at the stage where we are comfortable to start looking at the various options available. A key advantage that we have over other projects is that the idea and technology has already been self-funded and developed to a near deployable product, whereas other projects fund the idea, then do the development. Our approach reduces the risk for potential investors and ensures that marketing can be given the attention it deserves as a large majority of the raised funds will not have been spent on research and development.
Moving on further down the roadmap, we have a number of feature extensions planned such as improved anonymity, voting, instant messaging, social networks, decentralized storage and browsing, secure content streaming, advanced scripting/DACs, programmable interfaces and much more…