If you've been reading up on 'Bitcoin', I'm sure at a certain point in time you would have come across the term 'Cryptography' or 'Blockchain'. If you've been reading up on the Blockchain, you would have probably come across the term 'Crypto-Tokens' and 'Smart Contracts'. But for now, 'ÐApps' have been mostly in the domain of software developers and 'Blockchainers'; people who develop applications on the Blockchain.
ÐApps are 'Decentralized Applications' (well one can argue that it should be called Decentralized and Distributed Applications, but DDapps or DaDApps probably sounds too lame to make any kind of positive impact).
ÐApps are a new type of software which lives and operates within the Blockhain. Cool huh...
We talked a little bit previously about how certain properties of the Blockchain provides us with a platform that has embedded identity cryptography, DDoS resistant architecture and interoperability.
So does this mean that ÐApps retain these properties in its architecture too?
You bet!
The unique decentralization properties of the Blockchain applies to ÐApps in many ways. We now have an application that exists in multiple instances of multiple nodes within multiple servers and distributed across a Peer-to-Peer network. (Now try to say that again 10 times)
But how does this differ from any other old software?
Lets take a step back and talk about the history of software application architecture.
In the beginning, we actually started with distributed computing in the form of mainframe computing. A mainframe is a large and powerful computer which performs complex calculations and is connected to many users simultaneously, usually through 'dumb' terminals that don't do anything but receives instructions and displays information. Mainframes were used by banks, airlines and other large organizations to perform complex calculations and execute millions of instructions per second. Mainframe specific software were very platform dependent and does not play well with others. In the current context, we can probably term mainframe computing as centralized distributed computing, as the mainframe still exists in one location usually occupying whole rooms.
Advances in transistor and integrated circuit technology brought us the personal computer, which in turn gave rise to a slew of stand alone software applications from word processors, finance and accounting systems to computer games. However, these software were still platform dependent and can only be installed and run from one computer.
In the era of the local area networks, wide area networks and the internet, software began to be developed and run from a single computer, usually called a 'server', with more processing power and memory, and utilized via multiple other computers through a 'client' application. These were called client-server applications.
But what's the difference between a mainframe and client-server?
The difference lies within the type of applications and processing that is done. The mainframe and it's software applications are mission oriented. It is designed to perform bulk and batch processing on a specific set of transactions. The machine is dedicated to its purpose.
A client-server application can be more robust. A single server can serve multiple clients, a single client can use multiple servers. This gave rise to a multitude of dedicated server architectures such as file servers, email servers, database servers and gaming servers. In some cases these dedicated servers even run on the same machine.
However, these software applications were still mostly platform dependent.
In the mid 2000s, people began to host their servers on the internet and software were developed to run on web browsers. This gave rise to cloud computing. Organizations that provide the machines, hardware and data centers for computing via the internet were called Cloud Infrastructure Providers and they provide Infrastructure as a Service (IaaS). Organizations that provide the the virtualization architecture for others to host their servers were called Cloud Platform Providers, and they provide Platform as a Service (PaaS). Finally organizations that provide solutions on these virtual machines were called Software as a Service (SaaS) providers.
These three models make up the bulk of cloud computing today. Cloud applications that run on web browsers were one of the first truly distributed platform agnostic software. Which means that you can run them from any device with any hardware on any operating system, because the web was designed to operate that way.
And this brings us to back to ÐApps.
Decentralized applications must be able to proliferate and exist anywhere without the need for any ownership and control. Decentralization can technically exist via direct peer to peer connectivity alone, but the cloud allows for ÐApps to develop and grow more cost effectively by allowing software developers like us to get into the game.
Developers that are working on ÐApps mostly work on two main Blockchain architectures. Ethereum and Hyperledger. Now if you've been reading this blog, you know that we develop our applications on Ethereum, simply because Ethereum is more widely distributed and decentralized with over 27,000 full nodes worldwide and is growing by the day. Hyperledger is not currently being used to power any cryptocurrency application, it is used to build private Blockchain applications which serves a specific area of implementation.
ÐApps have two parts to its architecture: a backend and a front end code.
The backend code is built and deployed on the Blockchain. It utilizes the Blockchain architecture to perform transactions whatever that may be. The front end code is a set of instructions that is developed to interface with the backend code. The front end is usually a set of simple mark up languages such as Javascript that extends the backend functionality to other third party applications.
Where does the Smart Contract fit into this?
The Smart Contact, depending on what its programmed to do and where its called, can fit either as a set of instructions within the ÐApp itself or as a combination of functions at the Web API layer, or both. The Smart Contract can be thought of as what the ÐApp does, or a result of the execution of the ÐApp rather than the ÐApp itself.
The architecture and deployment of a ÐApp should not be developed as whole applications. It should be developed as a set of instructions that can be utilized by other applications to perform a set of tasks. You can think of it as a set of CRUD (Create, Read, Update, Delete) instructions to achieve a certain goal or process a certain transaction. This way we are still able to achieve decentralization without increasing the cost of transactions until the whole concepts becomes unusable in the real world. (If you remember, in the Blockchain, every transaction requires consensus, which incurs cost through some sort of proof of work algorithm).
The balance between cost of executing the ÐApp vs benefits and process improvements that the ÐApp brings, should be managed through effective use of both on-chain and off-chain software implementations.
We are building our first ÐApp in the form of our Blockchain based multi factor authentication protocol. Through this solution we are able to provide affordable login security and authentication to any solution provider, be it a web application developer, a gaming company or even IoT systems. All of these can benefit from a decentralized, Blockchain cryptography based identity authentication protocol.
Many other possibilities of solutions can be implemented within the Blockchain. Ethereum founders are imagining future ecosystems of decentralized applications and smart contracts working together to autonomously run organizations and even countries.
Dare I say that there is no implementation of a digital economy or digital ecosystem being planned today that can truly be successful without thinking of at least some parts of Blockchain based decentralization and smart contract implementations at its core foundation.
Lets take a step back and talk about the history of software application architecture.
In the beginning, we actually started with distributed computing in the form of mainframe computing. A mainframe is a large and powerful computer which performs complex calculations and is connected to many users simultaneously, usually through 'dumb' terminals that don't do anything but receives instructions and displays information. Mainframes were used by banks, airlines and other large organizations to perform complex calculations and execute millions of instructions per second. Mainframe specific software were very platform dependent and does not play well with others. In the current context, we can probably term mainframe computing as centralized distributed computing, as the mainframe still exists in one location usually occupying whole rooms.
Advances in transistor and integrated circuit technology brought us the personal computer, which in turn gave rise to a slew of stand alone software applications from word processors, finance and accounting systems to computer games. However, these software were still platform dependent and can only be installed and run from one computer.
In the era of the local area networks, wide area networks and the internet, software began to be developed and run from a single computer, usually called a 'server', with more processing power and memory, and utilized via multiple other computers through a 'client' application. These were called client-server applications.
But what's the difference between a mainframe and client-server?
The difference lies within the type of applications and processing that is done. The mainframe and it's software applications are mission oriented. It is designed to perform bulk and batch processing on a specific set of transactions. The machine is dedicated to its purpose.
A client-server application can be more robust. A single server can serve multiple clients, a single client can use multiple servers. This gave rise to a multitude of dedicated server architectures such as file servers, email servers, database servers and gaming servers. In some cases these dedicated servers even run on the same machine.
However, these software applications were still mostly platform dependent.
In the mid 2000s, people began to host their servers on the internet and software were developed to run on web browsers. This gave rise to cloud computing. Organizations that provide the machines, hardware and data centers for computing via the internet were called Cloud Infrastructure Providers and they provide Infrastructure as a Service (IaaS). Organizations that provide the the virtualization architecture for others to host their servers were called Cloud Platform Providers, and they provide Platform as a Service (PaaS). Finally organizations that provide solutions on these virtual machines were called Software as a Service (SaaS) providers.
These three models make up the bulk of cloud computing today. Cloud applications that run on web browsers were one of the first truly distributed platform agnostic software. Which means that you can run them from any device with any hardware on any operating system, because the web was designed to operate that way.
And this brings us to back to ÐApps.
Decentralized applications must be able to proliferate and exist anywhere without the need for any ownership and control. Decentralization can technically exist via direct peer to peer connectivity alone, but the cloud allows for ÐApps to develop and grow more cost effectively by allowing software developers like us to get into the game.
Developers that are working on ÐApps mostly work on two main Blockchain architectures. Ethereum and Hyperledger. Now if you've been reading this blog, you know that we develop our applications on Ethereum, simply because Ethereum is more widely distributed and decentralized with over 27,000 full nodes worldwide and is growing by the day. Hyperledger is not currently being used to power any cryptocurrency application, it is used to build private Blockchain applications which serves a specific area of implementation.
ÐApps have two parts to its architecture: a backend and a front end code.
The backend code is built and deployed on the Blockchain. It utilizes the Blockchain architecture to perform transactions whatever that may be. The front end code is a set of instructions that is developed to interface with the backend code. The front end is usually a set of simple mark up languages such as Javascript that extends the backend functionality to other third party applications.
Where does the Smart Contract fit into this?
The Smart Contact, depending on what its programmed to do and where its called, can fit either as a set of instructions within the ÐApp itself or as a combination of functions at the Web API layer, or both. The Smart Contract can be thought of as what the ÐApp does, or a result of the execution of the ÐApp rather than the ÐApp itself.
The architecture and deployment of a ÐApp should not be developed as whole applications. It should be developed as a set of instructions that can be utilized by other applications to perform a set of tasks. You can think of it as a set of CRUD (Create, Read, Update, Delete) instructions to achieve a certain goal or process a certain transaction. This way we are still able to achieve decentralization without increasing the cost of transactions until the whole concepts becomes unusable in the real world. (If you remember, in the Blockchain, every transaction requires consensus, which incurs cost through some sort of proof of work algorithm).
The balance between cost of executing the ÐApp vs benefits and process improvements that the ÐApp brings, should be managed through effective use of both on-chain and off-chain software implementations.
We are building our first ÐApp in the form of our Blockchain based multi factor authentication protocol. Through this solution we are able to provide affordable login security and authentication to any solution provider, be it a web application developer, a gaming company or even IoT systems. All of these can benefit from a decentralized, Blockchain cryptography based identity authentication protocol.
Many other possibilities of solutions can be implemented within the Blockchain. Ethereum founders are imagining future ecosystems of decentralized applications and smart contracts working together to autonomously run organizations and even countries.
Dare I say that there is no implementation of a digital economy or digital ecosystem being planned today that can truly be successful without thinking of at least some parts of Blockchain based decentralization and smart contract implementations at its core foundation.
No comments:
Post a Comment