Part I: Superpowering smart contracts — Blockie’s guide to API by Contract (AbC)
At Blockie we say we superpower smart contracts. You might ask, what does that even mean? Do we infuse kryptonite into smart contracts or have spiders digitally bite them? Well to understand our magic recipe behind our primary product API by Contract (AbC), we must begin by realizing the purpose of smart contracts, the limitations they face, and how AbC removes these obstacles (in Part II).
The purpose of Smart Contracts is to decentralize applications
Decentralization and censorship resistance are features many of us long for. Replacing the role of the third party is now possible thanks to the invention of the blockchain, smart contracts, and Decentralized Autonomous Organizations (DAOs). This is not only applicable to services, but also organizations, communities and entire democratic nations.
In today’s internet, we blindly put our trust in a few centralized, siloed giants and hope that they will always act in good faith. This holds true as long as the incentive of being a “good guy” is aligned with the act of profit making. Otherwise, our good faith may be misplaced.
If we have the technology to solve consensus, what is stalling this forthcoming wave of decentralization from rewriting every application in existence right now? Why can’t we have a fully functional decentralized YouTube, decentralized Facebook, or a decentralized World of Warcraft? To explain this, let us walk through the process of creating such an application.
Introducing the imaginary service Twether
Let us run through a scenario where we build a decentralized Twitter-like service. Let’s call it Twether.
Disclaimer: This is just an example, we have nothing against Twitter. Follow our twitter @blockieorg!
First of all, it is important to understand why you would want to create Twether, why would you want to decentralize authority and censorship? Here are a few reasons:
- You dislike certain actions made by Twitter
- You feel uncomfortable that Twitter has the sole power to change anything anytime on their service for any reason they deem worthwhile.
- You wish to have full transparency of the service.
- The network can be shut down from a central point and is vulnerable to outside attacks.
- It is easier to connect to all decentralized services using one private key than having to manage separate logins for every application you use.
To put it into context, Twitter can use its power to quiet or suspend any account for any reason it sees fit. Suspension could be legitimate due to misbehaviour, and this kind of decision improves the environment unquestionably. Alternatively Twitter could abuse its power and prevent the freedom of speech for its own benefit, to please, or adhere to a more powerful third party. In Twether, this power to suspend an account would be shifted to the users that would vote on banning that misbehaving user. No one single authority could enforce an arbitrary change.
Hence, if a user with a lot of influence is on the brink of starting World War III, and the authority of the centralized system doesn’t see a problem with that, there is nothing the rest of us can do. In a decentralized system on the other hand, the users can come together and mute that user’s account for the greater good of our planet. In essence, power still exists in a decentralized system, it has just been diffused across the network.
Built using smart contracts and Decentralized Autonomous Organizations (DAO) on the Ethereum blockchain, Twether would be well equipped to solve these types of consensus problems described above. There is no need for a central authority.
Smart Contracts face severe limitations
However, when using smart contracts there are inherent trade-offs that must be taken into account. Distributed consensus-based technologies are slower, more expensive, less scalable and have poorer user experiences compared to web-based APIs.
That’s a shame.
How can smart contracts handle the enormous amounts of data which are flowing through Twitter at any given time? Well, they just can’t.
To build Twether, our smart contracts are going to need access to raw power which current blockchain technology does not provide. That is the price we pay for consensus.
Storing every tweet on the blockchain would cost a lot mostly due to data writing operations. Frankly, even with tiny volume, it would easily flood the network filling up every blockchain block with tweets. In practice, we would only want some info stored on-chain, like your profile, your pinned tweets and possibly some authorisation keys, which will help validate the authenticity of content while flowing through your feed.
So we will have to look somewhere else to get this raw power to run the actual services. We will have to look outside of the blockchain and the Ethereum Virtual Machine to our old friend cloud computing.
Off-chain services to the rescue
So if we turn to cloud computing it does beg the question: are we not re-centralizing our efforts again?
That depends on whether those cloud servers can be taken down by any single authority. If they can’t, then we have a decentralized smart contract running a decentralized cloud computing service, and we can, all of a sudden, build the decentralized Twitter.
There are four main points to all of this:
- The smart contract must be able to launch the services it depends on autonomously.
- The smart contract must be able to communicate with the services after they are launched.
- The services which the smart contract launches in the cloud must be resilient to takedown.
- Preferably, these services should not require their creators to be extremely skilled coders.
For the smart contract to be able to launch and communicate with a cloud service, there must be some cloud-based processes that handle this action for the contract. This is not a problem per se. The big challenge comes when decentralizing it so that no one can stop this from happening.
Enter Blockie: Part II