Web 2.0 and Web 3.0
Using Modern Web Frameworks With Ethereum
Even with the recent explosion of growth in both value and number of projects built on the Ethereum protocol, the current state of the Mist Browser and Web3 in general is not adequate for the normal user. Requiring specialised knowledge of the various technologies in order to even begin interacting with dApps (distributed applications) means that they remain inaccessible except to the most dedicated of users. The speed in which recent ICOs (initial coin offerings) are currently experiencing funding belies the very narrow appeal of these projects.
Using web 2.0 in conjuction with web 3.0 technologies means we can leverage the power of the Ethereum protocol while still having an app accessible by all users. Users should be able to continue using their favourite web browsers, and not have to install work arounds, such as the metaMask Chrome extension, in order to interact with dApps. Further, there is no need for the user to be even aware of the underlying technologies that make up the Ethereum protocol, and ergo the blockchain. Our aim should be to build a web application, like any other web application, but one that has access to the benefits of the immutable, decentralised, trustlessness of the blockchain.
There is another reason to keep Ethereum hidden away on the back-end: It is slow and expensive. The need to wait for a new block to be mined after every transaction (read: most interactions requiring updating the state) means application performance is both highly dependent on network load as well as the current block hashing difficulty. Every transaction also incurs a transaction cost, required to pay the miner for verifying the transaction and mining the block in which it is contained. With Eth hovering around US$250 and rapidly climbing, these transaction costs are not insignificant. A fully decentralised application is bound to the rules laid out by the protocol, whereas a hybrid application is bound only by the choices made by its developers.
The biggest strength in the hybrid approach is application response time. Distributed applications are not real-time, nor responsive precisely because they are decentralised — every node in the network has to be updated with the application’s current state. Further, as every interaction involving a transaction requires the user to sign it off with their password, there is even more friction before the user receives the expected response to their actions. Web frameworks such as Meteor have been steadily removing these exact frictions, and have become real time. The hybrid approach means that the user has the benefit of a responsive, real-time application on the front end, and the slower but immutable blockchain hidden away on the back-end.
The aim, ultimately, is to have an application that sits in the middle of all of these technologies, picking and choosing what each has to offer. The diagram above provides one such example, leveraging Meteor and MongoDB in order to create a responsive, real time application for both the front-end and for all user-state interactions. In parallel, the Ethereum blockchain is harnessed for all interactions that require immutability. Ultimately, the optimum for today’s users is to be in the middle, neither entirely web 2.0 nor web 3.0.
How do you go about this hybrid approach?
A number of methods exist to integrate web 3 with a web application — Oracles, APIs and metaMask being options. The key tying all of these methods together is web3.js and solc.js. With both of these Javascript libraries, both smart contracts and calls to the Ethereum protocol can be made within a web application environment. Solc.js is particularly important, as it allows Solidity to be written, deployed and executed from a web backend such as Node.js. The upshot ultimately is that everything that a dApp can do is doable via a web application.
Isn’t this approach quite centralised though?
This approach is both centralised in terms of the web infrastructure, and decentralised in the data stored on the blockchain. Like all web applications, if the web server crashes, then the whole application goes down. Further, all the data is stored in a central location, where a malicious attacker could gain access. Finally, all data is changeable (read: mutable) and hence trust is required in the web application’s owners. All of these issues do not exist with a distributed application, and hence is motivation why these apps should exist. However, the advantages borne out by using web frameworks like Meteor means that such a compromise must be struck.
What are the other downsides of this hybrid approach?
The other main disadvantage lies with the approach to integrating the blockchain, where the keys used to unlock accounts are stored on the servers where the application is found. While this allows for complete abstraction of the blockchain away from the user, it does mean should a malicious user gain access to the keys, they could find a way to drain the wallets held by the web application in order to pay transaction fees. In addition, there is a degree of data duplication between MongoDB and the data stored on the blockchain itself. Whether or not that is an issue though heavily depends on the design decisions made by the developers.
While having a fully decentralised application entirely contained within the Ethereum eco-system is a noble goal, it is not something that normal users can access at this time. Rather than limiting the potential audience of the application, a better approach is to compromise between the blockchain technologies offered by Ethereum, and real-time web frameworks such as Meteor. This way, users can still enjoy the benefits brought by the blockchain, while still being able to use existing browsers such as Chrome or Safari.
