Making Secure Decentralized Apps (DApps) Easy - to drive Blockchain adoption
By: Sudhakar Kaushik
Tags: Decentralized Apps, Ethereum, Fintech, Blockchain, Dapps

Second, developers need to figure out which of these evolving technologies they want to invest in: which platform, what protocol, what interoperabilities would be needed, and how to anticipate what these technologies would evolve to? Third, DApp development has to be secure, since real money can be lost. This is perhaps the most daunting of hurdles.

Practical Model: Blockchain Usability for Developers

So how can we make blockchain development more practical? We do need to ease developers into blockchain more readily. Blockchain development cannot be transformed overnight by a switch to a different programming language, or by getting a resolution passed in the “computing senate,” as it were to make things easy. Admittedly, there are still fundamental problems of latency and scalability, but these are being worked on by a number of projects and alternative solutions like Celer, Loom, Plasma or side-chain and Mutual Knowledge Base approaches. But the immediate, pressing problem is to get the mainstream developers into blockchain. For this, even if a good majority, say 75 to 80 percent of the blockchain complexity is rendered accessible somehow, it will become more developer-friendly. Sure, certain protocol-specific lower-level syntax, cryptography magic and, or, intricate economic theories may still be needed, especially to get a complex DApp into production, but blockchain development would become less daunting to the millions of traditional full-stack developers.

Sifting through the challenges discussed, there are at least six practical components to make it easy for any full-stack developer to start working on blockchain. (Diagram 3)

A single Domain Specific Language (DSL) based platform that just takes a few lines of code as input and auto-generates the entire DApp, not just the “smart contract.”

(DSL) based platform that just takes a few lines of code as input and auto-generates the entire DApp, not just the “smart contract.” An Automated End-Point Projection system to both automate production of sub-programs (Clients, Contracts) in native binaries, as well as optimize them.

system to both automate production of sub-programs (Clients, Contracts) in native binaries, as well as optimize them. Abstraction for generalizing Layer 1 and Layer 2 protocols so developers stay at high-enough level and write once, but be able to use on any blockchain.

for generalizing Layer 1 and Layer 2 protocols so developers stay at high-enough level and write once, but be able to use on any blockchain. Services/Primitives for use as building blocks to accelerate development.

for use as building blocks to accelerate development. Formal Verification that can verify and produce secure DApps, automatically

that can verify and produce secure DApps, automatically An Easy Onramp that includes all the above capabilities without a cost burden or a big learning curve.

Domain Specific Language: This is the basic, foundational environment for productive, bug-free DApp development where comprehensive design and built-in safeguards allows traditional developers to dive in with assurance. Here, the DApp developers use a few lines of code to explicitly express the logic and purpose for the particular application they need to build. The DSL platform then does progressive compiling, generating the rest of the code for the entire DApp automatically and uses a suite of built-in tools — mathematical proofs such as Z3 shown in the diagram, other different types of Logic and Game Theory — to verify the program execution, logic, efficiency, protocol compliance and overall correctness against the application goals and specifications, including economic criteria. The method ensures issues are contained and effectively verified by breaking the problems down into smaller, manageable steps, sealing against “security” leaks and tackling the errors — i.e. bugs, security risks, etc- within these steps rather than letting them balloon into intractable, complex errors across the entire program. These steps are repeated in a cascading manner (technical details here and here) without the developer intervention all the way from the low, base-layer level code to the higher-level applications. Fundamentally, a well-designed DSL is a powerful development alternative, especially in the context of a complex distributed application, such as the DApp, and overcomes limitations of general purpose languages, SDKs, and Libraries by removing the need to do manual verifications and checks while providing guarantees on program performance, efficiency and correctness.

A good DSL should have built-in protection for bug-free development by what is considered “correct by construction” approach. This is a paradigm where the platform will not let developers write code that will result in errors. For example, the client-side code will not send a message to the Smart Contract in a format that will fail. This makes DApp development productive, correct and bug-free even as the development progresses, as opposed to having to test for errors after finishing the code that may result in re-tracing and re-writing and re-checking for errors.

The DSL needs to generate the entire DApp, not just the Smart Contracts, and from one set of specifications. This is critical for a distributed application where there are interactions — not all synchronous — between and among all programs and subprograms of the DApp. This is important to ensure the program logic and constraints are set up and enforced consistently across all interacting components for the DApp, not just Smart Contracts, because for an application to work, it has to work well for all participants across all conditions.

There are of course the usual, but still important, considerations for a good DSL. For example, an easy-to-use popular syntax such as JavaScript to remove the extra hurdle of learning yet another syntax. Compilers and testing tools also help developers to easily build distributed applications.

Automated DApp Production using End-Point Projection: It is not enough that we have a DSL that provides an environment for development. Developers also need the tools for ultimately producing the end programs in native binaries that need to execute in production per the design. Automated DApp production is the module that does this and completes the overall platform, thereby making on-boarding of traditional developers easy.

Starting with a relatively small source code, the DSL allows for compiling through various steps of (a) Parsing, into easily verifiable mathematical expressions (b) Expansion, into virtual machine code as preparation for running on various points of the distributed network and (c ) Analysis, into a logical model that is verifiable using different techniques such as the Z3 prover.

From this point, using a technique called End-Point Projection, (EPP, diagram 4) the multiple programs needed can be automatically produced. Here, for illustration, we see end programs such as the client code in JavaScript, the Server Code in OCaml or similar language and Smart Contracts in Solidity, or a similar language. End-Point-Projection could produce all programs needed for the particular DApp — Oracles, other servers etc., all from the small DSL source code. (some background here and here and here)

This is a very powerful paradigm shift in development towards making development easy, as well as, dependable compared to the traditional development platform. In distributed applications that naturally involve many programs or actors, it is essential that all actors agree on the interaction rules. Under these circumstances, a general purpose language would have required programs to maintain multiple copies of a program and ensure their consistency, which is both expensive and error-prone. Also, the source code writing — the real effort for the developer — is just a fraction, by a factor of 40 to 80 or more, depending on output length of some of the machine generated executables produced through this process. This certainly saves valuable time relative to hand-writing the code, but more importantly, machine-generated code produces logically and functionally correct code by design, by construction.

Abstraction: There are basic services, such as plug-ins for portability and interoperability, that are likely to be used often by most DApps. However, each of them involves subtle, yet crucial, issues and security considerations, better known to the blockchain specialist than a traditional developer. By generalizing these Layer 1 and 2 protocols and providing these services through easy-to-use language and environment, the platform allows the traditional developer to focus on creating their high-value applications for end users rather than the intricacies of low-level blockchain technology. It is essential to have the right level of abstraction to balance ease-of-use of underlying protocols vs. flexibility to adapt and develop for the use cases being solved.

Services & Primitives: Re-using well-known, good code snippets is known to developers as a productivity shortcut. In the blockchain context, this is a bucket category that includes code libraries, compiler backends, cryptographic primitives etc,. In essence, these are building blocks that can help developers integrate into base layers, include new functionalities, and such. We could envision compiler backends for side-chains, for Mutual Knowledge Base, or for interoperating with another protocol or libraries for gas estimation, and so on. With this Lego-like modular functionality, applications could stack one or more of these services and build around them, using other code, resulting in very rapid development. In a community-driven, open-sourced environment, primitives could be an effective approach to kickstart a number of cross-chain projects.

Formal Verification (FV): This method can help cover the logical, economic correctness, as well as, the security safeguards. Fundamentally, the formal verification can start with a single spec for the entire DApp and subsequent modeling of the DApp programs mathematical objects. The FV process then — in combination with the DSL approach of creating manageable chunks of problem spaces — can run a series of mathematical checks and proofs to ensure logic, semantic accuracy, and correctness of protocol usage to guarantee overall correctness. Knowing that blockchains have unbounded inputs and run on infinite domains, on a mix of private or public networks and clouds, testing software correctness using traditional methods will just not suffice. And, the challenges in blockchain that deter mass adoption are that tolerance for bugs in blockchain development is zero. Notwithstanding the fact that blockchain apps provide automatic, unsupervised access to billions of dollars in assets. So FV is core to the approach of creating an easy on-ramp for developers by overcoming one of the most disconcerting and critical challenges.

FV techniques, in conjunction with how the DSL can be set up across the DApp, ensures correctness at various levels of development — lower, closer to the Base Layer or higher, closer to the Application layer, and can be built into the development process, taking away the potential risks or eliminating them. These FV methods, however, are hard, if not impossible, to implement after the code is developed. Hence, the need to incorporate right along with the specifications.

Various theories and methods could be used to drive FV techniques. Some are listed below and more details including papers are cited under references.

Type Theory

Theorem Proving

Model Checking

Strand Spaces and

Dynamical Systems Simulation

Easy Onramp: The final component to the Practical Model is establishing a framework to make sure the rest of the components, the DSL, the Formal Verification, the EPP, and such, are all accessible. This is important as these techniques and design, while sound, reliable and productive, are not easy to learn, and clearly not easy to implement in practice. Bringing these methods of using DSL, the automated code generation, and even the Formal Verification into a pre-built platform that any traditional developer can use is powerful. So, the truly practical Blockchain DApp development model will have an Easy Onramp, where these powerful features are built into the platform and makes them accessible and transparent to any traditional developer at no cost and with minimal learning.

Building and Sustaining the Momentum

The practical model outlined above discusses six components that taken together could provide a sound, cohesive platform for on-ramping traditional developers into blockchain development. Would such a platform be sufficient to trigger adoption of blockchain development by the mainstream developer community? In my opinion, for sure, this would solve the first step for market fit. But as discussed in the Platform-Ecosystem model, we still need to address the need for community development and the concept of a whole product. Those are essential to sustain the momentum of getting more and more mainstream developers into Blockchain. The ecosystem needs to also deliver a good experience for end users. Today’s mobile apps don’t impose the learning curve or friction that the blockchain apps do. But, as a model of practical DApp development, this addresses the key challenges. Indeed, a very big chunk of developer resistance to use blockchain technologies would fall away, especially with the assurance of Formal Verification across the whole DApp. Combined with the thousands of blockchain specialists, there could now be the full force of software engineering behind creating new apps to materialize the blockchain promise.

References for the technically inclined: