It’s naive to say something is completely un-hackable, completely impenetrable and impossible to breach. There is nuance to this and the many variables make this a complicated notion. The same goes for scaling — all you can do is try to create a system where every conceivable option (to the best of your knowledge) has been thought of long in advance, to limit attack vectors, create something that is logically sound and in turn creates a system like Elastos.
Running a dApp on the Elastos sidechain does not make it infinitely scalable. It increases the ability to scale to a large degree, but it’s not infinite. Technically, having infinite sidechains means you can achieve infinite scalability as each sidechain has its own TPS, but that does not make each individual dApp infinitely scalable. Let’s unpack this.
If you had 1000 dApps, each with 200 TPS, that would enable you to have 200,000 TPS. This in theory can go on forever. It also solves the issues with network congestion (high gas prices/slow confirmations due to the bloat caused by many dApps running on a single chain) You have to compare running 1000 dApps on one chain, vs one dApp running on that same chain.
Another reason why Elastos dApps are so scalable, is because Elastos provides such a secure runtime environment end-to-end, which enables you to safely run most of the code that isn’t directly on the sidechain/blockchain. By using hashes of dApps and storing them on the blockchain, the runtime can verify that the dApp has not been tampered with, which makes it so you do not have to run all of the dApp through consensus.
Traditional App vs dApp
A traditional app is just back-end and front-end code stored on a centralised server. The app creator can choose whether or not to share the code, and all of the data from the app is in turn owned by the app creator/company. The app creator could alter the code, or look at your data without you ever knowing, because the app creator owns all of your data and the code is not transparent.
Elastos dApp vs Ethereum dApp
An Ethereum dApp is essentially just a couple of smart-contracts. Smart-contracts are just bits of code that have to run through consensus. That means that any part of your dApp that is run on a smart-contract needs to be executed by all 10000 nodes (as an example) each time it executes. It is just simply impossible to run any dApp with any form of complexity purely through smart-contracts. A typical game app could potentially need a massive amount of input/output operations per second. Ethereum would have trouble handling a single one of these dApps, let alone thousands of them. Not to mention, each operation costs a fee, while read operations typically don’t.
Since Ethereum’s dApps still run on the old internet protocol, in order to have a secure dApp you need to run as much as you can on the blockchain. However, what usually happens is you have some code running through smart-contracts, and then the rest of the code (front-end) is run on a centralised server which is subject to attacks. Basically as soon as you come off the blockchain (example being storing a single picture, which is in the region of $1000) ETH’s dApps usually have to store their data on centralised servers, and are subject to the same privacy and ownership issues of regular apps.
Ethereum dApps don’t have a Carrier network to facilitate direct connections and account for the weakness in TCP/IP. The data is vulnerable only when it leaves the Ethereum blockchain. The blockchain protects the data, but as most of the data used in Ethereum’s dApps today are not stored on the blockchain, but instead on a centralised server – this is where the vulnerability lies.
Elastos dApps address these issues directly.
First is the sandbox nature of Trinity. Basically, by design of Trinity (C++) it can use the hardware of the underlying devices while being separated from the rest of the device. It also stops the process of sending out any data packets to unverified sources.
The Trinity Browser acts as a Virtual Machine, and each dApp opened within has process and network isolation. When you close the app in the Trinity browser, it automatically destroys the VM. This means if you somehow downloaded a virus or a hacker tried to inject some malicious code (in order to hack your phone) it would be destroyed when you closed the app inside the Trinity browser. Since the dApp runtime is separated from the device OS, the virus will never reach the device and there can be no harm done.
Each dApp has no direct access to the internet and the only way to talk to the outside world is via Elastos Carrier. Usually, devices and users of Elastos Carrier have Carrier ID’s that are tied to DID’s that are stored on the blockchain. This is what is used for proper authentication and trust utilising blockchain technology.
These are features other platforms just do not have. When a developer first makes a dApp on Elastos, a hash of the code is stored on the blockchain/sidechain. When someone goes to use the dApp, the Elastos runtime automatically hashes it and checks against the true hash stored in the blockchain. This is to see if it has been tampered with. If there are any discrepancies with the hash, the runtime will not allow it to run, because it means someone could have modified the dApp with malicious code.
Users can select where you store your data directly from the Trinity browser. The browser is tied to your DID, so you can you use it to save your personal data either on your own personal cloud drive (Dropbox, Google Drive etc) or a decentralised storage system like Elastos Hive, where everything will be encrypted. Since the code and data is distributed in an encrypted manner, it is extremely hard for hackers to steal the data. There is also little incentive, because it is not all stored in one place.
This element is also something that not many dApp platforms have, which is a decentralised carrier network. The carrier is a way for routing traffic/transferring files directly between peers. In the regular internet, traffic is routed to centralised servers first and since they know which users traffic is which, it allows them to censor, steal and look into other users’ data or websites. Since traffic on this carrier is routed peer-to-peer in a very unpredictable way through relays, it is nearly impossible to intercept data packets. Even if they did, the data is encrypted and can only be read by the user with the right private key, or users who have been given permission by the original sender or creator.
Because of all of these elements, the only reason you need smart-contracts is for very simple and important business logic that has to do with transferring funds, sales and other things that are usually achieved by implementing middlemen. The rest of the code is so secure, you do not need to run it on the blockchain.
Elastos dApps are 95% hardware/decentralised storage and only 5% smart-contracts. This is what makes them essentially just as scalable as a traditional centralised application. Other platforms are more like 30% smart-contracts and 70% centralised server (although some are aiming to use decentralised storage) A single blockchain will never be able to run all of the code of thousands of apps, for billions of users on-chain. With existing platforms, it doesn’t matter how fast your device is because the computational power of the device is not utilised at all. This is inefficient.
Elastos allows you to use the extremely powerful and ever increasing computational resources of the users own device, in a manner that aims to be nearly as secure as running on the blockchain.
All of the combined elements above enable them to work in sync and function as the flexible, scalable fortress that is the Elastos ecosystem.
Full credit to Charles Coombs (aka C00mbsie) for the source of all this information.
Written by Chris Parker