Founder Rong Chen took the time to answer another round of community questions gathered by our Community Manager.


1. Although the main chain-sidechain architecture move native DApp token transactions away from the ELA mainchain, how will the ELA mainchain prevent congestion for ELA transactions? If the Elastos ecosystem becomes robust, there will be a major surge in ELA transactions, just as there might be for BTC or ETH transactions on their respective blockchains. Will the implementation of a DEX prevent main chain congestion in any way?

I see the congestion issue being comprised of four aspects:

(1) Blockchain technology serves to establish trust between different parties over the Internet. It is not particularly useful for financial transaction efficiency, very much the way gold is not particularly useful as a currency in daily, physical transactions.  In fact, I don’t believe that blockchains should in any way directly interact with consumers at all. Blockchain is only one of the underpinnings of the Internet. Consumers use apps and DApps to interact with the internet, and the blockchains are hidden below and behind the internet.

(2) Most people trust clearinghouses today to provide clearing services on the Internet. The real issue is not rooted in the clearinghouses, but in the governments that flood the M2 market.  Of course, clearing houses for remittance are too costly, and so we see blockchain projects like Stellar working to resolve such issues. Still, people use fiat currency and XLM, Stellar’s native token, works behind the scenes to facilitate transactions. Good old caching techniques in computer science always work like a charm if you can trust the source.  Another example would be an autonomous credit-card sidechain, where a user deposits 100 ELA as collateral to receive 100 dollars credit for shopping, which only needs to be cleared once per day (or hour), as opposed to after every transaction. I could imagine that the credit-card transaction software services would be very similar to today’s high speed and fault tolerant ones, except that they would not be executed on a credit-card company’s website, but rather on the decentralized Elastos Carrier.

(3) Decentralized accounting issues could adopt different blockchain ledgering techniques, e.g., TOP network is designed for tele-communications and VPN and streaming services, where vast amounts of transactions occur in parallel.  However, if you miscount a unit of billing (say 6 seconds per unit in the telecommunication industry), it’s not a catastrophic disaster. So their blockchain is different from the Elastos mainchain, where all transactions are cast in stone forever, like the BTC blockchain – different designs serve different needs. Whether or not DEXs stand to resolve any congestion problems, I have yet to determine.

(4) The most important principle here is that virtual machines (virtual phones) run peer to peer on Elastos Carrier in a decentralized manner, which is agnostic to underlying transactions or communications.  Say AT&T, a telecom carrier, could route connections between two phones via satellite or under-the-sea cables, without letting users knowing anything. Still, even if a satellite network is run by a centralized company, to the two people making peer to peer encrypted calls on Elastos Carrier, the calls still represent a DECENTRALIZED interaction, because the carrier can randomly switch between several centralized services and the Elastos Carrier itself is therefore decentralized.

To design a commercial airplane, every critical component must have failsafes so that there is not a single point of failure.  A common practice is to hire three different outsourcers and write code independently according to the same tech specs. In effect, three centralized components execute in a decentralized way.  Now, do you see performance issues for mission critical machineries? Trust, fault tolerance and decentralization are not synonyms.

Elastos side-chains are mostly internal to the Elastos SmartWeb. We ARE concerned with scalability and performance, but we adopt different technologies for different scenarios.  Please keep in mind that Elastos is a network of computers. A single blockchain (one ledger) is only one special purpose computer, and no one computer can solve all problems.


2. Some community members are concerned that Cyber Republic will not be mature enough to take the lead of the Elastos project as a whole when the time comes. Can you elaborate on the respective timelines of Elastos and CR and discuss how CR needs to grow in order to  ensure a smooth transition of responsibilities?

I see that many community members still think of the Elastos SmartWeb as being built by a company or an organization.  Indeed, there are not too many people that really understand what’s required to build the Elastos SmartWeb. I see that we are wrapping up the first version of the following projects: the Blockchain, the Carrier (SmartWeb equivalent of http/https), and the Trinity Browser (scripting Runtime) in August, 2019.  We are yet to start the Digital Capsule (SmartWeb equivalent of URL), Personal Cloud Computer (PCC, SmartWeb equivalent of website), and the Native Runtime (native CPU instruction runtime, the ultimate SmartWeb virtual machine for DApps). The Elastos core team can’t even find enough talents to implement the above projects in parallel.  How can we trust CR to take over building the Elastos SmartWeb infrastructure in August? We can’t. The Elastos core team will finish what they started – hopefully in the next year and a half. For the time being, there won’t be any transition of responsibilities, period.

However, building an ecosystem is a completely different story from building a platform.  People should always remember and respect that Netscape was the pioneer in building the www web.  Netscape’s extinction a few years later did not prevent Google and Facebook from prospering. The ecosystem of the new Elastos SmartWeb will be a jungle where only the fittest survive. Cyber Republic Consensus will put everything under sunlight, so to speak.  I think it is time that we take a leap of faith for the future of mankind.

Right now, I don’t expect CR to design the network OS; I expect CR to grow the ecosystem and design DApps and create projects for specific markets. Each market has a different strategy and needs different projects. Anytime CR funds a project, or an ELA is transacted, we need to see contracts and have articles so that everything is transparent and open to public scrutiny. That is why – for right now – the core development team and EF will continue to develop the network OS and gradually transition more and more infrastructure related projects to CR as the platform progresses and becomes fully functional.


3. There have already been several suggestions in CR and two of them have been turned into proposals by the CR Council. Are you happy with the progress of CR thus far? Do you have any personal suggestions at this stage to support the work and vision of the Elastos Foundation?

So far so good, although a bit on the slow side to launch new projects. I could see that the CR process has improved a lot, especially after the second attempt at CRC becoming CR Consensus. The talent pool is too small right now. We also need more individuals with the technical proficiencies necessary to assess the strength and validity of proposals. The thumbs up and thumbs down function is good for non-technical input, but we may also need a function for technical input. The institution of multiple sections – some dedicated to technical ideas, while others are dedicated to broader considerations – may present the entire CR with a better system to interpret and understand incoming proposals. Should it remain one vote per person, one vote per ELA, or should voting power be weighted in a meritocratic fashion? Is there a way to determine the intent of a participating individual, so as to keep highly technical holders of large amounts of ELA from having excessive influence on voting outcomes? We are still at the beginning – this is more or less of the second incarnation of CR. These are just a few of the questions which continue to play out in my mind.

I was happy to see the first two proposals – ReactNative and Hyper – pass; they were very deserving of the funding they received.  Still, by this August, with a new council in place, I would like to see significantly more proposals and more progress from CR. The culture and mentality are certainly moving in the right direction. There are many encouraging signs that this culture will be well received and adapted. I also consider that in the future, it is possible we may have a deep learning algorithm to decide on matters such as inflation. This is a new society collectively governed by a robot, a sort of “democracy on rails.”

4. Regarding the upcoming supernode elections, everyone wants to know if you will run a node yourself and what criteria you will use in casting your votes. Have you made up your mind?

I might, but I feel sorry to say that I don’t quite know how at this moment.  Bitcoin miners behave much like a group of lemmings blindly following one another. This group of merged-miners represents our first tier: a robust crowd pursuing a very simple-minded goal:  maximizing rewards. Although these merged-miners are selfish, they provide the hashpower we need to secure our network. Our second group is made up of interest groups running DPoS nodes, they should be fully committed to the integrity of the Elastos ecosystem.

My votes will be cast in the direction of the nodes which prioritize network locale distributions and the diversity of software implementations, e.g., some hosted on Linux, some hosted on Ubuntu subsystem running on Windows, to improve the robustness and efficiency of the Elastos SmartWeb network.


5. The partnership with TOP Network, which was announced in the EOY Report, is still unclear for many community members. How does the Elastos ecosystem benefit if TOP Network is using its own P2P network technology instead of Elastos Carrier?

Elastos Carrier and TOP Network position themselves at different levels. Think about the telco carriers which provide unique IDs and consumer oriented services, while other telco networks offer infrastructure like satellites, under the sea cables, 4G mobile, etc. Elastos Carrier is a decentralized P2P carrier of virtual machines (instead of hardware phones), and TOP Network is a decentralized P2P network. Satellite companies can sell their networks to multiple carriers, and carriers may choose from different network providers.

Feng Han’s fund, which is independent of Elastos Foundation, invested in TOP. EF also has its own collaboration with TOP. Somewhat like AT&T, Elastos is a Carrier, and we will have routing options like Titan (CDN), TOP, and Viewchain (P2P, multiple devices). Because different networks have different strengths, TOP provides great benefits to Elastos because it improves and broadens our portfolio of providers. Elastos issues DIDs (Decentralized IDentifiers) and we will use TOP for its routing services. We see no problem in Top having its own blockchain and native token. One of TOP’s strengths lies in its ability to secure Internet communications. In fact, TOP Network is one of the most popular VPN service providers to small businesses and schools in the US.

For us at Elastos, every addition to our ecosystem is focused on creating a robust smart web.  As TOP is a routing option which makes the Modern Internet that much more robust, we are excited in bringing it into our rotation of routing service providers. Eventually, we want every home to have its own VPN, both for smart homes and for individual protection.


6. Many community members have asked about learning to code and what is most relevant as far as the success of the Elastos ecosystem is concerned. With all your experience in computer science, what is your advice for them? Is there a particular resource that serves as a strong starting point?

One of the key Elastos programming technologies is called the Component Assembly Runtime (CAR), which was inspired by Microsoft COM – Component Object Model. Elastos, at the C/C++ native level,  mandates a ubiquitous metadata driven programming paradigm, which simply put, prohibits applications (foreground tasks), services (background daemons), and IoT devices (peripherals) from directly accessing the network communication layer.  In fact, application programming would be much easier than Linux native code programming. The future of programming should be like assembling building blocks, rather than laying brick and mortar. Unfortunately, we tentatively put Elastos native programming support on halt, due to lack of resources.  We used to let programmers write in C/C++ in Android JAVA programming styles, but this code and capability is still collecting dust in the graveyard somewhere. I can’t help but say: it’s a pathetic world after all these (twenty) years!

People say DApps are the future – and perhaps they are. But before we can realize such a future, we must reach consensus for the following two conditions:

(1) DApps cannot be shutdown by a third party.

(2) DApps, as digital assets, should preserve their value for 10 years or more, i.e., they should still run after 10 years or more.

Taking Crypto Kitties for example, if the website is down, can you run your kitty? Are you sure that the kitty client app would run on a host OS in ten years? The BTC blockchain has been running for more than ten years.  How about Ethereum smart contracts? Asking the right questions is the first step in solving these problems. Elastos is not there yet, but we are moving in the right direction to answer the above questions.

At the higher level, Elastos tries to adopt mainstream programming languages and frameworks while preventing applications from interfacing directly with the internet itself. I would recommend beginners start with Trinity Browser or ReactNative to build DApps when they are available.

Our DevStudio Lead, Kiran Pachhai, also offered his advice for this question:

For those learning to code, it is best to begin with basic computer science and programming concepts. Only with that foundational knowledge base established is it appropriate to advance to software engineering principles and ultimately, to developing actual software and tools. All in all, the life cycle of a software product involves not only developing and coding but also designing, testing, and ensuring that everything runs as autonomously as possible. As with anything, there is no perfect programming language; what’s most important is learning to use the programming language perfect for the particular job you’re trying to do. A software engineering project may involve multiple languages, which is why learning the fundamentals should be the primary focus.

Elastos is an infrastructural project and as such, it is not written in any one programming language. Although the blockchain and sidechain code is written in Go, proficiency in Go is not required to understand the Elastos blockchain nor to communicate with it. Rather, a developer will most likely be communicating with the framework level APIs that are exposed through the blockchain code. Likewise, while Elastos Carrier is written in C, proficiency in C is not required to integrate Carrier into a product. On top of this infrastructure, a developer can extend any code underneath it to any programming language and to any platforms. This is how a developer is able to utilize various SDKs such as Java, Android, and Swift SDK for Elastos Carrier while targeting all platforms – PC and mobile. And then there is Trinity. On Trinity, all the heavy lifting is already taken care of, and all the APIs are exposed via the Cordova plugin. The developer must only learn a JavaScript framework called Ionic in order to communicate with the blockchain, Carrier, Hive, or any other component of Elastos’ core technologies.

All in all, it’s not the language, but the concepts– decentralized architecture, security and scalability– that stand at the forefront of an infrastructure project like Elastos. If you can understand the Elastos ecosystem well, developing a DApp on Elastos is fairly easy, as intended by its design.

If you are a developer, please tune in for our first livestream Developer Workshop: Running Elastos Private Net on April 18. Here is the link:

I hope to see you all there.


Please enter your comment!
Please enter your name here