[EDEN DIARY_BD] Chicken or the Egg? by James Ahn

By December 14, 2018 English

Chicken or the Egg?
by James Ahn

Wikipedia describes the chicken or the egg dilemma as a causality dilemma. That’s to say, it’s a dilemma that stems from the observation that all chickens hatch from eggs and all chicken eggs are laid by chickens. These situations of infinite regress, where it is not clear which of the two events should be considered the cause and which should be considered the effect, are not only found in nature. In fact, it’s a problem seen across many blockchains today.

There are some projects which have launched their mainnets. In addition, some projects mainnets have been updated throughout the year. Whilst it’s great to see such technology develop, I can’t help but wonder to what extent performance, stability and functionality have been tested.

The term mainnet has significant meaning – as it should. Developing and launching a mainnet demands tremendous time and effort from the team. However, I do not believe that software that works well in a test environment will necessarily translate into a similarly successful product in a production environment.

Why do I say this? Because many times this newly built software, packed with new technology, is yet to be proven or tested in any environments outside of its test environment. Mainnet is supposed to  process real transactions from many different sources with acceptable performance and without any errors simply because it is, well, mainnet.

Quality Assurance

Test and production environments are by their nature very, very different. This is the main reason why so many errors are often found after software is released. In spite of the fact that the software companies undoubtedly placed a lot of emphasis on QA.

Needless to say, this is a consequence of a production environment being much tougher, more difficult and rife with the unexpected. As such, releasing new software means opening Hell’s Gate to developers because developers will ultimately deal with many problems in a very short time period,   otherwise their users will leave the service and never come back.

When we talk about the mainnet, especially blockchain mainnet, we can’t overemphasize the value of QA. If users happen to see the wrong account balance or double spending occurs, it will be surely lead to the downfall of the project – or at least major reputational damage.

Mainnet needs high traffic DApps for maturity

As a mainnet developer, we always wonder how DApp providers will use our API & SDK to build a blockchain service. This is a very crucial point to us because if we have a better understanding of how they will use the mainnet, we can create better architecture, features and error handling. With respect to mainnet developers, however, it is very difficult to ascribe a particular way in which they will use our API & SDK., as it depends on the DApp itself, the developer and other factors.

For example, if the DApp developer uses a global locking mechanism frequently, it will make the DApp slow as well as the entire mainnet. However, we cannot force these developers to use it because there are certain cases where those locks are inevitable.

Besides these issues, there is a more critical one waiting for developers: How the mainnet will handle large number of transactions. Even if developers have extensive experience and a deep understanding of the mainnet, he or she can still expect possible issues related to API & SDK, whereas the aforementioned issues are almost impossible to sense in advance. Only after running the mainnet in such environments can the developer figure out where its weaknesses and logical flaws lie.

Creating a web service handling 100 concurrent users is easy, but web service with 100,000 concurrent users is a totally different story. To handle such a large number of concurrent users, developers need to redesign entire architectures and apply many advanced techniques at the most basic levels.

Therefore, to test and determine the stability of a mainnet, developers need something utterly viable and reflective of the blockchain platform. Otherwise they might be at loss as to how to proceed. I maintain that only working DApps with high traffic can provide the valuable feedback needed for developers to build a solid and reliable mainnet.

It is a Spiral Process

I may be wrong but I firmly believe that after implementing the basic features of the mainnet, developers should change their focus from the mainnet itself to DApp development. Because real-world DApps will help developers identify errors, flaws and potential improvements.

Performance relative to expectations and reality are often very different in software development and a blockchain mainnet will suffer from the same issues. It is, therefore, of paramount importance to have actual DApps running on a preliminary mainnet for a period of time to prevent a mainnet nightmare.

To build a production level mainnet, developers must take a conservative approach, step by step and check, check, check. Developers should not trust their own codes until that codes work in various conditions and under high load.

After a period of strong verification, developers can add additional features to test. This is the way we will produce a high quality mainnet at Eden.

EdenChain & DApps

We released a testnet last Sep. Fortunately, the testnet has been working well and we did not see any major problems. No crashes, no data errors… so far at least. Soon block height will reach 1 million!

Our team came to a conclusion that to improve the testnet we need DApps which will use Eden’s API & SDK whilst generating real transactions that aren’t created by stress testing tools. If the DApps are running on top of EdenChain we can have a better understanding of our system and can find out technical problems which were previously hidden. We can only be assured quality of Edenchain when we have those actual DApps.

Since DApps and E-Garden are in their test versions, we will undoubtedly face many technical problems, however,  this is the first step to build a world class permissioned blockchain. Once we can overcome those technical issues, proving technical superiority of EdenChain will be all the more easy. So even though DApps and E-garden are in their test stages and not matured, we want to release them in order to move forward with our mainnet development.

What do you think about The chicken or The egg? Which one comes first? Platform or DApp?

In blockchain technology, I think the DApp comes first. At this stage the platform is built for DApps, not the platform itself. As such, DApps will teach us about what the platform should do.