Smart Contracts — What’s Next?

Nick Szabo coined the term “smart contract” in his 1996 essay. The ICO boom of 2017 was not only an explosion in unregistered security issuance, but also a an experiment in mass implementation of smart contract concept on top of Ethereum platform.

The reality of this experiment is that current blockchain networks cannot support any serious application that uses significant resources or requires high performance and throughput. There are ongoing serious efforts by smart and dedicated people to solve this problem.

Build The Business Layer First

We have a successful implementation of a “smart-like” contract in the wild-

I propose going a step further: creation of a smart contract OS, which abstracts the lowest blockchain layer away from both the developer/issuer of the contract and its final user. In this implementation, there are the following building blocks:

1. Low Level Protocol
2. Smart Contract API

The low level protocol can be thought of as the base layer that executes the OS. It could be AWS Lambda, Ethereum WASM VM, Tezos, DFINITY or some other system, swappable or configurable as needed.

Smart Contract users and designers would interact strictly with the OS, which would completely abstract away the base layer and/or support multiple base layers, depending on the needs of the system. For example, an application which requires high degree of decentralization would be configurable to tweak the decentralization knob in the desired direction, at the very extreme executing everything on a blockchain, even if that is not the most efficient solution. If a scalable blockchain based solution appears, it could be swapped in under the hood.

Developers of apps, whose users simply don’t care about trusting a central party or even prefer to have a trusted gatekeeper, could build their smart contracts using the same standard API.

Note that this OS could implement immutable or auditable smart contracts even for the applications relying on fast execution through the centralized base layer. Some degree of trust in this case would still result in a less trusted, more decentralized behavior than in a typical application.

What’s the Point?

Let’s take CryptoKitties. It’s a great game that allows users to

1. breed digital cats and create unique cats
2. trade these cats for money ( crypto )
3. keep an inventory of these cats in a wallet

CryptoKitties is nothing but a great, creative and viral game at its core. Watch this video. In it, Dieter Shirley, the creator of Cryptokitties talks about several interesting aspects of building blockchain applications, both positive and negative.

On the Plus Side:

1. users get permanence value from decentralization
2. smart contract interface enables apps on top of apps, with creators of original app unable to shut down or delete their creation.
3. developers get built in money.

On the Downside:

1. development interface is a real pain the ass
2. User interface / UX is also a pain the ass. (“onboarding flow is really brutal”)
3. Scalability

Note that there is *almost* nothing on this list of pluses that fundamentally, at the lowest layer requires execution in the Ethereum Virtual Machine. We could execute all the same things in AWS Lamba without incurring the pain points of terrible developer and UX experience. If CryptoKitties is just a smart contract, it could be checked in upon creation into a public repo of smart contracts, which will persist in one form or another on the internet indefinitely, ensuring some form of permanence. It could also be checkpointed onto Ethereum or Bitcoin blockchains to ensure the code doesn’t disappear, but there is no reason CryptoKitties themselves absolutely must execute on every node in the Eth VM, when we are thinking about the lowest execution layer.

Conclusion

It would be an awesome idea to create a smart contract execution framework, an OS, that abstracts away low level protocol completely from both end users and developers and supports a variety of different types of smart contracts via standardized smart contract APIs.