Introduction to D-apps. Part #2

Understanding Ethereum architecture.

Ravi Vats

Directly digging into Ethereum architecture by referring to its documentation online can be confusing and overwhelming at times. One of the better ways to do this is to compare the Ethereum architecture with some architecture which is widely known, like client-server architecture.

Overview of the client-server architecture:

A typical client-server architecture. (Image Source: www.zastrin.com)

A typical web application generally consists of server-side code which may be written in server-side languages like Java, Python, JS etc. The front-end part (website which the users can interact to) is generally coded using HTML/CSS/JavaScript. The entire application is then hosted on any of the online providers like AWS, Hasura, Google Cloud, or a VPS like Digital Ocean.

Users can interact with the web application using a client such as web browser, curl/wget (command line) or through an API. Note that there is one web application which is centralized and all the clients interact with this one application. When a client makes a request to the server, the server processes the request, interacts with the database and/or cache, reads/writes/updates the database and returns a response to the client.

Now, let us compare this with the ethereum architecture.

Overview of the ethereum architecture:

The client-server architecture works very well most of the times. However, there are certain applications where it would be really helpful if that database was publicly and securely accessible by everyone and you don’t have to rely on this web-app owner for your data. This is where Ethereum architecture could be helpful.

Typical architecture of a Ethereum D-app. (Image Source: www.zastrin.com)

If you notice, every client (browser) communicates with it’s own instance of the application. There is no central server to which all clients connect to. This means, every person who wants to interact with a D-app will need a full copy of the blockchain running on their computer/phone etc. That means, before you can use an application, you have to download the entire blockchain and then start using the application. This gives us the advantage of not relying on a single central server which might disappear tomorrow.

In reality, you don’t need to spend lot of your hard disk and RAM downloading the entire blockchain. There are a few workarounds/optimizations to keep the application decentralized yet make the interaction quick and easy.

The main components of this architecture are:

Database: Every few transactions that occur in the Ethereum network are packaged in to blocks and each block is linked to the next block. This linked series of blocks which holds all the transaction data is the blockchain.

If we go back to the eBay example, every transaction between buyers and sellers, whether it is a sale, refund or dispute would all be recorded on the blockchain and is available for everyone to see. To make sure all the nodes in the network have same copy of the data and to insure no invalid data gets written to this database, Ethereum uses an algorithm called Proof of Work (also known as Ethereum Mining)

Code: The database aspect of blockchain just stores the data. But where is all the logic to buy, sell, cancel, refund etc. In Ethereum world, you write the application code (called contract) in a language called Solidity. You then use the solidity compiler to compile it to Ethereum Byte Code and then deploy that byte code to the blockchain. There are few other alternates to Solidity but Solidity is by far the most popular language for contract development.

So basically, the blockchain stores your data, stores the code and also runs the code in the EVM (Ethereum Virtual Machine).

To build web based d-apps, Ethereum comes with a handy javascript library called web3.js which connects to your blockchain node. So you can just include this library in your famous JS framework like reactjs, angularjs etc and start building.

Another big and important feature is the financial capabilities of the platform. As soon as you start using a d-app, you get an in built bank account. Actually, not one bank account, but you can create multiple bank accounts in a fraction of second. These bank accounts are called wallets where you store money (Ether — the currency used in the Ethereum ecosystem) and transact.

In this next part of this series, we would be looking at creating an Ethereum D-app using Solidity and JavaScript (using web3.js).

References used for this article:

  1. https://www.commonlounge.com/discussion/44509d23220a42dea228fe90ad823683
  2. https://www.zastrin.com/courses/1/
  3. http://www.ethdocs.org/en/latest/
  4. Siral Rawal’s D-app video.

I am Ravi, a senior year CS Undergrad at MSRIT, Bangalore interested about ML, Deep Learning, Data Science, Algorithms and Blockchain in general but pretty much still a beginner in all these fields.

You can connect with me on my LinkedIn profile.

Alternatively, I am also available on Twitter, Facebook, Instagram and Quora.

The source code for the later parts in this series would be uploaded on this GitHub repository.

Hope you find this series interesting. I am always open to any edits or suggestions to enhance the info provided in this series.

Cheers to learning! 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *