Our Approach to Decentralization: The Transmute Platform
In this post we will explore our technical roadmap and comment on some common questions asked of our framework and our approach. But first, a disclaimer: The Transmute Platform is pre-alpha software (aka a work in progress). This roadmap may shift or change significantly before we launch our first public alpha.
Our Plight
We love Ethereum, and we wholeheartedly believe in the transformative power of decentralization. We are already observing the revolutionary impact blockchain technology is having on business and the internet.
We built the Transmute Framework to solve the problems we encountered managing decentralized application logic and dependencies for our customers.
The Transmute Framework only had Ethereum dependencies like Truffle, TestRPC, and Web3 initially. We then expanded the Framework to support IPFS as our customers demanded more complexity.
The first decentralized applications (dApps) we built required significant manual configuration in order to operate, especially when deploying smart contracts to the correct network and managing connections to IPFS [or other backend services].
We quickly realized that a key part of adopting decentralized technology was providing a friendly developer experience for complex applications — aka an experience familiar to web 2.0 developers.
Building a Bridge
When developing traditional centralized applications for customers, it’s common to have a number of services which need to communicate with each other, such as a database, api or web server and a front end.
DApps developers may wish to choose peer-to-peer solutions for these services, but are often stumped by the prohibitively difficult security and engineering challenges presented by fully decentralizing these services.
Alternatively, enterprise customers want to integrate Ethereum into existing centralized application. For example, companies that manage payments or user identities often have centralized public APIs which customers are using to develop their applications, such as Facebook, Twilio or Stripe. This raises a number of challenges for dApp developers.
Can you ever really decentralize an application built on centralized providers?
- Your user accounts are managed by Facebook.
- Your app uses Twilio for 2-Factor Authentication.
- You use Stripe for payments in your marketplace.
- You host custom APIs on AWS, Azure or Google Cloud.
- Your web application code is hosted on Github.
Do you truly want to build your app from scratch — by re-inventing each of these centralized services as a decentralized solution?
The truth is, blockchain is great business for major cloud providers. Most useful applications will need to “talk” to centralized services, and that means they will need to be developed with consideration for centralized security concepts (e.g. private api keys and trusted central servers).
We chose Google’s Firebase platform to demonstrate a proof-of-concept, but other cloud providers will be supported in the future. In doing so, we have centralized the application deployment environment. Our app, api, and database [as they exist today] are all controlled by Google. This makes development and maintenance very easy, but what about Ethereum?
Because everything is hosted by Google, they could alter our application code or network traffic in malicious ways — if they wanted to.
At this point any reader who believes in decentralization should be screaming, “What is the point of making a centralized platform for decentralized application development?!?! Does that make any sense at all?”
We’ve made “dApp” development and deployment easy, but we seem to have eliminated the whole point of blockchain technology in doing so — at least temporarily.
This was intentional, and we have a secret plan for getting back to that fully decentralized application future, but before that’s possible, we need much more adoption of blockchain technology.
The Full Stack
New Technologies generally follow this trajectory for commercial adoption:
Localized use cases are rampant (e.g. private blockchains for banks), and we are already beginning to see substitution (e.g Stripe accepting Bitcoin).
Offloading the burden of blockchain development onto centralized cloud providers will accelerate commercial adoption and transformation — by providing an easy way to migrate from centralized to decentralized, service by service.
This philosophy is the core of our product roadmap at Transmute Industries.
The Transmute Platform currently exists as a centralized application development platform where customers trust us and the centralized 3rd parties we rely on for:
- Application Hosting (Google)
- Service Hosting (Google)
- Database Hosting (Google)
- IPFS & Ethereum (Consensys)
In order to realize a fully decentralized application, each of these components must be replaced, along with any centralized application dependencies, such as Facebook, Twilio, Stripe, Amazon or Google.
Luckily IPFS and Ethereum are easy to decentralize. You can even use our framework to manage these services yourself right now, see the advanced setup process here.
Web application hosting is also solved; you can use decentralized IPFS to host your application. Here is an example. Our framework provides a convenience wrapper for this exact use case.
Regarding Database Hosting, the Transmute Framework uses IPFS and Ethereum together to store all records, but we provide an option for storing Smart Contract state in traditional Document Databases. Some customers will want to use a centralized database for this, while others will want to use a self hosted solution or a decentralized database like OrbitDB, or BigChainDB. The primary advantage of using a centralized solution for this is the “out-of-the-box” support for complex queries and analytics.
To be super clear, we do not trust any database solution: the Transmute Framework stores the result of processing the Ethereum blockchain and IPFS records in a database for convenience and speed, but not security.
We recently added support for this here.
Service hosting is the most difficult to decentralize because many desireable services need to talk to centralized services to operate [requiring developers to manage secrets or certificates to protect this access from malicious attackers]. Services that provide data to smart contracts are often referred to as “oracles”. Oracles help smart contracts answer questions with dynamic information from the internet such as:
- Was my flight delayed?
- What is the current price of ETH in USD on GDAX?
- What is the latest version of a package in npm?
To answer these questions, oracles must trust a central party! The FAA can lie about flight delays on http://www.fly.faa.gov/. (They don’t even have https on the website). Whichever internet source an oracle uses to retrieve the price of ETH on GDAX or the latest version of a package on npm, the oracle will simply have to trust that the service is telling the truth, that DNS, HTTP and most other protocols from the centralized web 2.0 world are operating correctly and securely.
If an oracle needs to authenticate in order to get the data it needs, the service operating the oracle needs to protect credentials or certificates. This makes it difficult to distribute oracle services securely. Solutions to this problem are in progress:
However, some oracles will never be decentralized. Consider a stripe application which requires a secret API key.
This secret key cannot be easily shared to decentralized workers, and even if it could, the data the oracle is providing is fundamentally tied to a centralized account managed on centralized servers by Stripe.
Oracles like this require hosting on prem or by a major cloud provider because they provide information to Smart Contracts that is fundamentally controlled by a third party. At any point, these third parties (e.g. Stripe, Facebook, etc.) can alter their database, revoke your secret API key, and your oracle will cease to function.
For cases like this, a centralized oracle provider makes a lot of sense, especially for proof-of-concepts.
Conclusion
We think solutions like TrueBit and Chainlink will allow many centralized oracles to be decentralized in the future. At the same time, we also believe that companies will continue to rely on Amazon, Microsoft and Google for enterprise software development.
We chose to make a centralized platform for decentralized application development because the challenges of cloud tech are well understood. The architecture is actively used by enterprises in every industry vertical, so our best chance as a community of expanding decentralized application development is to work from the working centralized solution towards the new decentralized one. Building oracles on trustless decentralized platforms is hard, and in some cases impossible. Building trusted oracles on centralized platforms is what cloud computing has always been about.
We think the strongest next step toward the decentralized future is going where the developers are, to the centralized providers, and offering them decentralized substitutions where possible while enabling them to leverage the centralized services which they need to build products for their customers.
Check out our latest demo app here: https://dapp.transmute.industries/
Contact:
hello@transmute.industries
The Transmute Team:
Orie Steele, Karyl Fowler & Eric Olszewski
