Centralized vs. Decentralized Apps, Part 1: The Difference

Blockchain is the new Big Data. A broad, overarching tech term that is repeated insufferably. As an engineer, you are probably getting pressure to integrate it somehow, and in an inconsiderately short timeline so the C-suite can talk about it at the next conference.

Like Big Data, or teenage sex, everyone is talking about it, yet few know what it actually is. After my first dive into building a natural gas exchange on Ethereum, I would like to share my insights, and blunders.

All applications are, fundamentally, logic. If I submit this form, my data is saved. If I click the thumbs up button, I send my approval. If I swipe left, I send my disproval.

With a centralized application, a single cluster of servers contains all logic to conduct the necessary steps. The cluster receives your request, processes it, saves what it needs, and returns the correct response. With a decentralized application (or Dapp) all nodes in the network receive the logic you have deployed within your contract. Once the contract is mined, all nodes have the exact same logic, based on the contract, saved on their copy of the blockchain. Once you interact with this contract, the same signal must be processed with the deployed logic same way, then save the same data and return the same signal.

This is a radically different architecture than Node.js, Ruby or Python centralized applications rely on, but to sum up, the logic in your application and service layer is within your contract.

The main advantage is you do not need to maintain a cluster nor keep the cluster secure. That is taken care of by the redundancy of the nodes in the network. The majority of logically functionality within applications is taken care of by decentralized Ethereum applications (user authentication, get/post requests, data storage, etc.) .

However much of the existing infrastructure that applications work with is centralized and an Ethereum contract cannot work with a centralized systems that require common API calls. If a contract was to make a conventional API call, it would require every node that it existed on to execute a call, which would cause irregularities in the API call. (Although, Oraclize is gaining strength)

This major difference of being incompatible with conventional systems required a shift in thinking while I was building my first Dapp. The next installment will be on synchronizing the two, while conserving hashing power.

If you would like to discuss Caserta building a distributed application for your company, please reach out to me at max@caserta.com