December 12, 2018
The Need for an 'Execution Layer' on Ethereum
Blockchain technology is incredibly constraining - limitations around computation and storage capabilities have stymied use-case creation and, subsequently, significant user adoption. Here, we walk you through the development lifecycle for a decentralized application and the trials and tribulations faced by their developers.
Developing Your Decentralized Application
If you’ve ever developed a decentralized application, you’re familiar with the exciting feeling you get after finally having deployed to a testnet. It’s pure ecstasy — the first step to a live deployed version of a truly unstoppable application. But the testnet doesn’t really paint an accurate picture of reality, now, does it?
Well, we only need to look to INFURA to get our answer. For those not familiar, INFURA is a spoke of ConsenSys and provides infrastructure for not only the most popular Ethereum testnets, but also IPFS — a decentralized file storage system. And while the services they provide are absolutely invaluable to the space, they willingly admit that it’s all hosted in AWS. But this is no crime, it’s testing infrastructure — it doesn’t need to perfectly match the deployment environment.
In fact, the most popular testnets (Rinkeby / Kovan) don’t even use the same consensus as the mainnet. As a tradeoff, they use a federated system in lieu of proof-of-work to mitigate high cost and low throughput. And really, this is fine given that testnets chiefly serve as a sandbox environment where smart contracts can be audited and tested before someone is ready to put their code on the mainnet. So, we turn a blind eye to our centralized “decentralized” infrastructure for the sake of providing a stepping stone to our truly decentralized mainnet.
Now, remember that ecstasy you felt earlier deploying to the testnet? I bet that feeling turned to terror (rightfully so) at the prospect of deploying to the mainnet. With no margin for error, we sextuple check things, attempting to assure ourselves that nothing in our code will be exploited for the entirety of Ethereum’s existence.
But still, it’s something we have to come to grips with, this “F**k it, ship it” attitude. So, we forge onward with our test suites and audits in hand, deploying our app to the blockchain, where it will (as far as we can tell) remain indefinitely.
Marketing your Decentralized Application
Eager to get the word out, we tell our friends outside of blockchain about our new unstoppable application and are met with skepticism and befuddlement.
“Why do I want a digital cat? Like a neopet?”
“Have you not been keeping up with Bitcoin? It’s dead!”
Nocoiners… we reproach ourselves for even attempting to get them to understand. In hopes of traction, we set our sites on greener pastures such as crypto Twitter and the Ethereum subreddit, where we are met with a few likes, comments, and retweets. And this satiates us enough to get back to coding up a few additional features and improvements to the UX, expecting to come back and see our application slowly gaining traction.
All this waiting is beginning to worry us... how can we expect to make blockchain the next big thing if some of the most devout members of the community aren’t even using the tools and apps built on it?
Well, maybe there's better number for other applications out there, so we look at DappRadar, where we see that many of the decentralized applications follow a similar hype cycle of user adoption:
The State of Blockchain
The majority of the community enjoys comparing the present state of blockchain technology to the early days of the Internet. But what we often fail to call out is the fact that we have the Internet, now; and people have gotten accustomed to the speed and user experience that have coalesced from it over the past few decades.
And it's for this reason why we're working on things like universal logins, plasma, state channels, and plenty of research. All of which are essential for being able to “cross the chasm” from early adopters to early majority.
And as we transition across the chasm, we'll find that even though we've improved on usability, businesses and individuals will be unwilling to part with the configurability of their systems that the cloud has given them. They will ask for private and permissioned ledgers, proof of authority networks shared amongst a consortium of trusted members, app-specific blockchains, etc… to suit their business’ needs.
And we'll think to ourselves
“They just don’t get it”.
“There’s no such thing as a private blockchain.”
But we have to keep in mind that many of these businesses just moved to cloud just a few years ago and want to take their time before jumping on board with another completely new technology. So, while the public blockchain might be a bit to risky for them, they do see the value in decentralization.
The Future with SKALE
It is this belief that one size does not fit all that has led us to develop SKALE, a highly modular and configurable execution layer scaling solution. Initially, we are focused on providing scalability for Ethereum-based decentralized applications with our SKALE Parallel Asynchronous Consensus (SPAC), which is based on the parallelization of a variant of Asynchronous Byzantine Binary Agreement.
And while we build alongside businesses in our SKALE Innovation Program, we are continuously dreaming up bigger and bigger plans for the future! At some point, SKALE will be integrating plug and play consensus mechanisms, interchain messaging, and a number of other requested features.
SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance SKALE Chains that run full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. Follow us here on Telegram, Twitter, Discord, and sign up for updates via this form on the SKALE website.