-
Notifications
You must be signed in to change notification settings - Fork 6
ĐApps, decentralized apps
You may have noticed that software architectures evolve in a spiral fashion. We seem to inevitably revisit old ideas in a new light. Web Apps centralized client-server apps and made the management, deployment and most importantly, the sharing between users much easier. Then the mobile apps moved a lot of code and data back to the client side, yet most mobile apps are still cloud-based, and therefore are still centralized. Decentralized apps are more resilient, and most importantly, they do not require a trusted service provider, which can be hacked or coerced.
DApps talk to P2P networks, most important of them today is the blockchain. Tradle DApps are also bittorrent clients talking to each other to exchange messages and data, specifically focused on transactional data, and not the movies :-)
Tradle DApps use local DB to quickly paint the UI and they sync this DB (bidirectionally) with the blockchain and the bittorrent network. In fact Tradle integrated blockchain with the bittorrent so tightly that we usually call this combination - a chain. DApps live on a chain. Chain is robust and does not belong to any company or country. But it is also quite slow, so local DB is a buffer that compensates for that.
When a new system of beliefs or a thought framework arises, as it happened with the bitcoin blockchain today, we must revisit our old assumptions. So we start with a question, why our current system, which we heavily invested into, is bad and we must spend time and money to re-learn what we know and rewrite what we coded. So why blockchain-based, so called DApps are better than our normal web sites and mobile apps? What's wrong with them?
- Site steals the relationships. Successful marketplaces change the power structure in the industry. Stubhub.com is one example how ticket brokers lost their relationships with customers. Many marketplaces fail to grow due to the fear of this happening.
- Site creates a barrier to data portability. It is good for the site's growth, but is not good for it's users. Site can offer an API to solve this problem, but ...
- Site API is often subpar. API rarely matches all the features of the site, because the site wants to be sticky! Quite often API is just read-only.
- API creates a conflict of interest for the site. API is never a level playing field, as third-party apps become competitors:
- Facebook Platform promised a level playing field, later reversed.
- Twitter changed their API to eliminate third-party front-end apps.
- Site concentrates data. This makes life much easier for the hackers. This year we witnessed mass scale breaches. Site also creates an entity to which the governments will come with their data demands. This increases the cost of site's operations, creates a conflict with site's users, and in some countries even puts users' lives in danger.
Answers assume a blockchain extended by Tradle
- Removes the conflict of interest in accounting. Blockchain provides an independent immutable record of operations. This might be the biggest invention since double entry accounting.
- Blockchain security is highly compartmentalized. Practically every transaction has different keys. Central systems can be built this way, but usually are not, presuming they work behind the firewalls. We believe enterprises will soon use such technology as they can not rely on the perimeter defense anymore.
- Proof of uniqueness. Blockchain's global consensus mechanism is used now for proving the ownership of money. But it can be coerced into an ownership record of any property, digital or physical. For example, it can be used to know who owns an event ticket.
- Censorship resilient. Great Chinese Firewall blocks many US sites, but the blockchain is China-proof, Turkey-proof, thus creating a truly global market.
- Programmable commerce. Semantic Web failed, but in its cleaner blockchain incarnation it may very well become the foundation for global programmable commerce.
- Ownership of data. Blockchain robs the apps of their current power source and, if this model dominates, it will lead to a disruption of the biggest internet properties.
- Distributed systems are more resilient. Distributed systems are built with an assumption of dynamic membership and constant failures. Bitcoin full nodes and bittorrent are the examples.
Well, it rips the database from out of the app's belly, and using the principles of trusted computing, puts it into the open. This database is very slow (7 TPS) and sometimes reverses the last several blocks to a different sequence of transactions (re-org). So challenges for syncing with the blockchain are numerous. I am working on this chapter to identify them and offer the solutions we have developed and others we are working on. To Be Continued ...
While the blockchain creates first ever logically-centralized organizationally-decentralized database for sharing data, it presents a significant challenge of keeping data seemingly in the open. We will use strong encryption techniques to address this problem. Here are the common concerns about public storage:
-
Q. Storing data in the open allows anyone access to encrypted data, so anyone can attempt to decrypt, while only a number of agencies are capable of intercepting encrypted VPN and SSL traffic.
-
A. It is a valid concern. There is at least one factor that offset this concern though. Traffic over SSL/VPN is point to point, thus leaking the identity of both the sender and the recipient. Storage does not leak the identity of the recipient and can be enhanced to hide the identity of the sender (Ethereum Whisper has this design goal). Without knowing the identities, a large number of files in storage makes it impossible to decide what to decrypt and thus makes it much stronger than the SSL/VPN encryption. One can argue that the agencies that are able to intercept at will are with high probability the same agencies that have any chance of decrypting data in storage. SSL/VPN have a a large number of vulnerabilities that have been successfully exploited already. We plan to build on a decentralized architecture without trusted third parties, using open source community verified code to avoid problems with SSL/VPN.
-
Q. In 10 years data stored even with the strongest encryption available today will be easy to decrypt.
-
A. We will have to increase the encryption strength periodically, much like the difficulty is increasing in bitcoin's blockchain, so that what may be cracked in 10 years will be a small subset of the data. Consider that this concern is true for all the traffic that is captured by the agencies today. Consider also that the alternative of keeping data with the trusted third party is quickly evaporating. So either way you need some mechanism other than SSL. Consider that currently people don’t send things encrypted (EDI is mostly unencrypted). Sending data directly requires both parties to solve the storage problem, and many turn to the cloud, which is the place where all the hacking efforts can be concentrated.
Blockchains validate transactions by executing scripts those transactions carry or scripts uploaded upfront (i.e. Ethereum). Invalid transactions do not get into the chain. Unfortunately if transaction needs to be private and the data on it is encrypted, the script can not be written to validate it and transaction will be recorded in the block, while validation will have to be done on the edge of the network. This creates a possibility of a network split (fork). It also makes creating SPV clients almost impossible, and thus one needs to run and maintain a full node for clients offload their validation to. This makes server-less apps impossible. If we could create a generic method of confirming validation of transactions, this problem might be solved. That means if I sent you an order and you accepted it, after running validation on it, you could theoretically create the next transaction to 'mark' the validation of a prior transaction.
###Software
###Front end