Smart Contracts & Blockchains

Smart Contracts and Blockchains

Smart contracts have proven to be the gateway for developers to create a diverse and fastgrowing collection of applications. However, the original smart contract was designed as an instrument of the blockchain, enabling programs stored on a blockchain to execute when certain on-chain conditions are met. This leads to an important issue with smart contracts - that they are built upon and thus inherit all of the inefficiency and issues of the chains they are hosted on.

Infeasible to Fix – For example, blockchains are immutable, append-only ledgers, and their contracts are designed with this same principle. While this design might be acceptable for very specific use cases, over time it has proven to be a substantial design flaw. Case in point, the Parity wallet hack of 2017. Parity is a wallet software company created by Ethereum co-founder Gavin Andresen. Despite nearly unlimited expertise and resources, Parity shipped with a bug that was eventually exploited by a hacker, effectively preventing all multi-sig wallets on the platform from transacting, blocking over one hundred thousand ETH from being transferred. An editable and updatable contract could have this issue resolved and patched within minutes.

Expensive to Run – Over the course of time, the popularity of the cryptocurrency industry sparked new innovation that has tested the limits of current smart contract technologies. On blockchains such as Ethereum, transaction fees are a function of the size of the smart contract itself, meaning, more complicated contracts such as NFT minting contracts, cost more to execute. As the number and complexity of contracts in each application increased, so too did their operating costs. Not all smart contracts are as expensive as others. Contracts run on BNB Smart Chain are an order of magnitude less expensive to run compared with Ethereum, despite being an EVM monologue. But BNB Smart Chain gives up distribution and decentralisation to achieve this and operates at a far lower volume. Solana is yet another order of magnitude less expensive to run on, however, the artificially low transaction fees have led to bot-induced congestion, leading to outages.

Inability to Scale – The scaling debate is often poorly understood by developers. Some point to Solana's high transaction throughput as evidence that chains can be built to scale. But one must understand that scalability is inversely correlated with the need for a public, trustless, and consensus-driven model. Non-public ledgers that run on centralised databases such as those operated by credit card companies, can scale without issue, as they do not rely on a bulky and inefficient consensus mechanism, or need an immutable ledger the public can scrutinise. Even though Solana can handle more transactions and process them faster than most public chains, it has its own issues that are correlated with design compromises to achieve this goal. Smart contracts built on current public blockchains simply cannot scale sufficiently to the needs of all applications, especially those involving a high number of transactions such as global payment gateways. Thus, they are ultimately limited in their capability, handicapping developers.

Difficult to Learn – Currently, no language standard exists for which smart contracts are developed and built. As a result, fragmentation is prevalent in the industry, making the already difficult task of learning an entirely new development paradigm more complicated. Developers creating smart contract code on Ethereum will note that the base language is Solidity, a coding standard that is similar to Javascript. But those creating program libraries on Solana need to be proficient in Rust, an entirely different language, while developers experimenting with smart contracts on Cardano (one of the biggest contract-enabled chain by market cap) must be knowledgeable in Haskell, an infrequently used development language. Since the public knowledge-base of Solidity is so vast, developers naturally gravitate towards learning to build on the Ethereum Virtual Machine (EVM), oftentimes without really knowing how vulnerable such contracts are to exploits, how costly inefficient contracts can be, and the ultimate limitations of smart contracts for most applications.

While the intent of the smart contract is with merit, it was designed for a specific purpose, however with today’s varied applications and use cases, the original architecture is simply unsuitable for current needs, let alone, the next generation of blockchain applications and technologies.