Complexities of Blockchain Development and the Need for OPEN


The name “Smart Contracts” is often referenced ironically by software developers because most of the time, they aren’t. Smart Contracts are inherently restricted in their utility by the limits of blockchain technologies, and that often extends into the structure of the language used to program them. Worse yet, the structure of the language is different from blockchain to blockchain, making the barrier of entry for developers impossibly high. This is why the Developer-centric APIs and SDKs that OPEN provides are so essential to achieving mainstream adoption of blockchain technologies. To best show this, in this article we will do a deep dive into how Solidity Functions and why it can be so hard to use.

Early on in the history of Ethereum, we saw the first example of flaws in Solidity that nearly destroyed the entire community. DAO stands for a Decentralized Autonomous Organization, and its purpose is to codify the rules of the organization and obsolete away bureaucracy. “The DAO” was a very special DAO that had raised $150MM in order to invest in projects with its investors serving as the voters that make the decision. Software design errors were pointed out, but were deemed to not put any of the funds at risk. A hacker used one of these bugs that had been pointed out and conducted a reentrancy attack where the method in a smart contract is called before it has finished executing. Through this he was able to drain 3.6MM ether, which was 15{e9b7b6e97581a958d2bc378a46799d644da7fe427050b58be8de8c4fdd2a2020} of the total ether supply.

A massive debate happened in the community on how to deal with such a critical hit and the price of ether dropping from $20 to $13. Ultimately, the DAO and the Ethereum Foundation elected to fork the codebase such that the DAO attack never happened. Such an attack is especially vulnerable in decentralized systems where code cannot be changed and is public. This is why the acceptable error range is zero for any application hoping to utilize the blockchain for a non-trivial amount of business. That makes it necessary for developers to become experts in Solidity before being able to build real world applications. This wasn’t a one-time issue as we saw it again with $300M worth of ether being locked away never to be used again because of a mistake accidentally done by a researcher.

There are also other lower level issues besides the above system level vulnerabilities. For example, every type is 256 bits wide, even a byte[] type which is an issue because it represents 32x more space than an average developer would expect coming in from another programming language — especially relevant because storing space in Solidity is especially constricted. Amusingly enough, the 8-bit wide byte type is called an int8 while the 256-bit byte type is called bytes32.

Ironically, despite it being primarily a language used to codify financial interactions, Solidity doesn’t support any floating point types. Integer operations can overflow and there is absolutely no way to do overflow-checked operations. Unlike most modern day programming languages, there is no garbage collector which means that dead allocations are never claimed and makes the space constriction in solidity even worse. Trying to hardcode it in is equally impossible, as there is no manual memory management.

Weird quirks exist like being able to return statically sized arrays from functions, but not variably sized (stated to be fixed in Metropolis). Some of the weirdest stylistic bugs is with arrays. Array syntax looks like C or Java, but the declaration syntax is actually written backwards. You cannot create multi-dimensional dynamic arrays and string[] is invalid because string is already a byte array.

At OPEN we handle all of these strange and dynamically changing quirks of programming languages that are inherent to blockchain so developers don’t have to. Tezos attempts to create a functional programming language for its smart contracts in order to reduce the error vector surface area, but that makes it incredibly tedious to develop in and makes the learning curve for blockchain technologies even more complicated. OPEN offers developers an API that takes away the complexities of these scripting languages not only for Ethereum and Solidity, but across all blockchains. Not only that, but we allow the Developer to withdraw their balance at any time from the Scaffold in order to control exposure. Abstraction barriers designed to optimize for security and ease of usage are critical to getting mainstream adoption of Ethereum.

The future is OPEN!

Reddit | Facebook | Twitter | White Paper | Website | Telegram | Bounty

About the Author open