April 20, 2018
Although the concept of smart contracts was introduced in the late 1990s by Nick Szabo, it remained an abstract concept until the Frontier release of Ethereum in 2015. That release was the first implementation of smart contracts and was enough to move them from a concept to a reality. However, as the community experimented with the technology, it became clear that new requirements would need to be met before they could be deployed at scale.
A Brief History of Architectures
It’s easiest to understand the evolution of smart contracts by seeing their development in the context of how software development paradigms have shifted over time.
In the 1990s, the PC revolution led enterprises to move to client/server applications, and away from mainframe-based, dumb terminal or single-tiered applications. Enterprise developers started building 2-tiered applications where data was separate from the client or business logic.
Initially, client applications held the business logic and UI code. Tools like PowerBuilder and Visual Basic raced to have the best UI frameworks, control libraries, and developer experiences so enterprise developers could create the best-looking, most performant experiences. As developers added more business logic, control presentation, input and application interoperability functionality, the client installation footprint on PC hard disks grew tremendously. That bloat led to them being called “fat clients” because of their deployment requirement to fully install all the code and libraries.
Minimizing the use of network bandwidth between the data and logic tiers was an important design objective. Clients that requested too much data could timeout, crash the server, or clog the network. Optimizing database performance became a critical part of application design. Stored Procedures helped improve performance by allowing data access and validation logic to run on the data tier. They also simplified development by exposing logic for clients to perform create, read, update and delete (CRUD) operations without hand-writing SQL statements.
The tiers represented actual hardware components, servers, and networking devices that supported software layers defined by the type of logic that ran in them. The presentation layer contained user interface logic such as input validation, control focus to guide users through application input flow, data presentation and data binding. The business logic layer defined the API for the presentation or any other system that wanted to interact with the application. Eventually, this layer became stateless, which allowed it to scale horizontally using network load balancers. It also allowed for the complete abstraction of the data layer and provided composite interfaces across multiple backends for better integration.
The data logic layer contained logic for creating, reading, updating and deleting data for the underlying data platform. That was primarily written in SQL-based stored procedures, but newer big data, No-SQL and blockchain were also included.
With this architecture, deployment was much simpler; a developer could simply map the logic layer on top of the physical tiers based on the scale, security and performance that was needed. This separation of concerns let layers scale horizontally, by adding more computers in the tier, or vertically, by upgrading the amount of resources for single computers. This approach removed brittle, tight couplings between systems, making modularity, versioning, (.dll hell) and client deployment much easier. Not surprisingly, Separation of Concerns became a best practice. It continues to be an important paradigm today in modern micro-service architectures.
The Initial Smart Contract Implementation
Seeing the initial development of smart contracts in a historical context highlights the limitations of the initial implementation, and provides guidance on how smart contracts will need to evolve.
The initial release of smart contracts in Ethereum was designed to give parties that don’t trust each other a way to enter into an agreement, where they can be confident that the transaction will unfold as they intend, and where they can verify the status of the contract or transaction at any time.
To achieve these design goals, the initial smart contracts implementation didn’t follow the typical patterns for application development. Specifically, it included the logic, properties, and data in a single package, essentially collapsing the business and data logic layers into a single layer, which are then written to the blockchain. That provides the immutability, deterministic execution and transparency required in untrusted environments.
You can speak with our specialists on +918884944494 or mail us at email@example.com for any of your query related to smart contracts.