A Request for Decentralized Infrastructure
This article is a snapshot of problems we’re looking to co-create, invest and partner on. If you’re already working on one of these problems, or are looking to — we’d love to chat.
The bull-run of 2017 saw the meteoric rise of public interest in cryptocurrencies. The subsequent concentration of wealth, talent, investments & resources have created a flock of stakeholders waiting with bated breath for scalable value creation to blossom on the backs of blockchain protocols.
While some of the world’s best “blockchain converted” minds solve problems related to network throughput, security, identity, governance and more; technology giants are beginning to join the transition to a decentralized internet.
With the advent of protocol blockchains and “smart contracts” any developer has the ability to build “apps” that require no intermediary, are inherently trusted by all users, resistant to censorship and take downs. The majority of first wave consumer-facing decentralized apps (dApps) built on the Ethereum network fall into the following categories:
While these dApps have shone a light on what’s possible in the short term and have helped us remove obstacles in the path to delivering software that can be consumed by an end user, they have failed to go beyond this milestone. The “Killer App” that achieves success in eating market share and dethroning existing centralized alternatives in industries like healthcare, finance, and supply chain has yet to show itself.
Why aren’t we seeing breakthrough dApp experiences yet?
The reality is, building an App on centralized infrastructure is a lot easier and there are many unsolved problems at the decentralized infrastructure layer. Building a service or offering on centralized infrastructure comes pre-loaded with solutions to many problems a developer will face and decentralized alternatives do not exist yet.
So what problems are developers facing?
Network Problems are a problem domain specific to the protocol. Solving problems at the protocol layer is the main focus of the Aion Foundation. They include issues with scalability, finality, interoperability, throughput, security, governance, privacy, the tradeoffs between these attributes and more.
Once a developer has chosen a protocol blockchain network, they face challenges in building a compelling platform, application, or system that can compete with centralized alternatives. Much of the tooling, supporting infrastructure, payment rails etc. we take for granted in a centralized system requires new or re-tooled solutions in a decentralized one (many have yet to be created).
Assuming builders have a compelling application and are looking to attract daily active users, there is still insurmountable friction for mainstream users in interacting with dApps. This results in a lack of appeal to groups outside of very early adopters and crypto enthusiasts.
We’re excited to issue our first request for tooling & infrastructure(drawing on YC’s style of RFS). The list below represents a number of high potential areas where we believe will unlock the potential for developers to create the world we all seek to live in. You’ll notice we’ve purposefully left our level 1 which is perhaps better suited for another post.
Level 2 — Builder Problems
Lack of consolidation on tooling (overwhelming): Development environments for building decentralized applications are fractured and some core feature consolidation needs to happen to make the lives of developers easier. Forcing a developer to abandon their existing workflow is too big an ask long term.
Network Costs: Current smart contract blockchains can cost developers a consequential sum of the blockchain’s native currency to store and process transactions. With long-term solutions being worked on by protocols, solutions for the immediate term like GasToken can help developers now.
Minimal language support: Smart contracts lack programming language support, as a result, new developers are forced to learn and use a new language (solidity) that comes with a lot of “gotchas” and has a steep learning curve for some. This makes blockchain development less approachable. Second, to this, there is a continuum that exists for development languages between simplicity and definitive outcomes vs expressiveness. In certain applications that are perhaps “mission critical” use cases where you may want a more restricted programming language with things like formal verification so that you can reason about the correctness of the program more easily — reasoning about turing complete code is difficult however the expressiveness of other languages means a broader spectrum of use cases can be explored.
Identity Management: As we continue to interact with these systems at scale the inevitability of user identity becomes more prevalent. Some of the current challenges with identity management reside with the trade-offs associated with the costly storage data on-chain, privacy or obfuscation of sensitive data/transactions and integration with off-chain databases. Projects like uPort and Civic have both proposed solutions the identity management problem.
Smart Contract Upgradability: Over time software requirements change, however due to the immutability of the blockchain, smart contracts by their very nature cannot. Some interesting approaches to “upgrading” contracts have emerged from some great projects and we’d like to see more. A good breakdown of this problem and some potential solutions was written by Mike Calvanese and can be found here. Some projects addressing this problem are Zeppelin, and LevelK. The approaches range from proxy contracts that direct logic to executing contracts or in the case of ZeppelinOS provides a library for developers to build upgradeable contracts and a CLI to manage the upgrades. The theme here is how can we give developers reliable patterns for upgrading contracts that we all agree are best practice.
Smart Contract Security: The immutability of the blockchain means developers must be extra diligent to assure their contract acts as intended and is not vulnerable to bad actors looking to exploit a contract for nefarious, self-serving purposes. We need more solutions to help developers secure their contracts before they deploy them to a network and users engage with applications that use those contracts. Audit firms like Hosho, NCC, Chainsafe have been a good starting point for solving this problem but more needs to be done to make smart contract security available to the individual developer in their basement.
Mobile SDKs/Frameworks: Building iOS and Android applications with functionality that push and pull data from blockchains still poses many issues for developers. The end user experience for consumers leaves much to be desired however we’ve seen progress from projects like Pocket Network, Edge Wallet, Wallet Connect.
Oracles/Distributed Real world event APIs: When we reference an off chain data source in our contracts to determine it’s outcomes we expose the contract to a centralized point of failure. Oracles are trustworthy sources of data that provide the necessary inputs to trigger smart contracts to execute when the original terms of the contract are met. These conditions could be anything associated with the smart contract — temperature, prices of commodities and goods, flight or train delays etc. These oracles are the only way for smart contracts to interact with data outside of the Blockchain environment. Doug von Kohorn did a great job of breaking down oracles by describing the problem here — “Smart contracts need oracles to resolve details that cannot be precisely known at the time the contract is written.” There are a few projects worth pointing to (and likely many others) that are actively solving this problem including Oraclize, and prediction markets like Augur and Gnosis and YesBit.
NRG/GAS price estimation: Blockchain protocols often charge a fee per computational step that is executed in a contract or transaction to prevent deliberate attacks and abuse on the network. Every transaction is required to include an NRG limit and a price that it is willing to pay per NRG. Miners have the choice of including the transaction and collecting the fee or not including the transaction at all. Making your contract “just work” likely leaves area for improvement in optimizing your contract to reduce it’s computational load and thereby decreasing the cost for every node in the network to run the code. Building a sustainable and successful business requires insight and prediction into operating costs. This cost is free-floating and can be significantly impacted by network activity and congestion. This lack of prediction into “operating” costs, presents a barrier for deploying large-scale dApps and also sustainable businesses.
Reliable Storage: Storing data is expensive, computationally intensive and challenging due to privacy. However, there have been many innovative approaches to this problem from projects like IPFS, and Storj, Bluzelle.
Cryptocurrency Accounting: Good bookkeeping for businesses that hold, spend and receive cryptocurrencies in exchange for goods and services rendered is very hard. This problem will only grow as consensus is reached on accounting best practices by tax agencies. Two projects we’re actively following on this problem are Balanc3 and Softledger.
Lack of Users: We’re still early in the blockchain adoption curve and this list serves as a great reminder that we have much to do before we start to see droves of users showing up and using our compelling dApps. A scaled approach to adopting more users into decentralized systems is of particular interest to us and the next level may be the key to unlocking a solution.
Level 3- Consumer Problems
Dispute Resolution (smart contracts): Smart contracts are coded as self-executing contracts when all parameters of the contract are fulfilled. However, they do not necessarily provide effective mechanisms for enforcement if one party breaches his or her obligations. This means blockchain use cases that involve trade between two parties, off chain fulfillment, as well as concepts like returns, warranties and more become impossible to enforce. Some interesting solutions have been proposed by Wulf Kaal and practical solutions from the Oath Protocol project.
Managing Wallets/ Account ID Management: Similar to the how the chequing account is at the center of an individual's financial life, the wallet is at the center of any consumer interacting with a blockchain. Something so critical to an end user’s interaction with a blockchain should feel simple and mistake-free. However, today’s wallets are painful to use, it’s far to easy to make mistakes when sending transactions, theft is unfortunately common, and it’s too easy to get locked out of your wallet forever. Two projects worth pointing to directionally here are ENS and Tenzorum.
Full cycle key management: There are many problems facing wallets and this is perhaps the most obviously deserving of our collective attention. Keys to wallets are easy to lose, private keys can be stolen and wallets emptied if stored in a compromised system. Furthermore, funds in hardware wallets need to be stored in physical vaults in banks in order to create barriers for even the key holder themselves. The list of key management issues continues to lack a set of standardized solutions and until these and other wallet problems are solved, mainstream users will continue to be sidelined. Projects to point to here are Ledger, Trezor, Vault, Coinimi, Trust Wallet.
Reputation Management: When transacting in the real world we have systems in place to avoid working, trading or entering into transactions with bad actors. On a blockchain, however, many of the individuals we interact with are anonymized and hidden by proxy contract and public wallet addresses. Reputation as an immutable asset on a blockchain in some ways has more tangibility that any reputation system off-chain and would have the ability to power an endless number of use cases in most industries.
Easy currency conversion/purchase in-app: As a user interacting with an application, transacting should be an experience that comes to me, and doesn’t require me to go to it. Forcing users to buy ETH to interact with a dApp is like forcing someone at an ice cream stand to buy “milk credits” with their cash to then buy the ice cream. We need more decentralized applications that abstract cryptocurrency behind existing mass adopted payment vehicles (like the credit card). Hats off to Changelly and Shapeshift who have made progress in this domain.
Transactions require complicated/expensive devices: Secure read/write functionality on a blockchain, has traditionally meant downloading the “entire blockchain” — not a realistic task for IoT devices like parking meters, watches, and electric door locks. We require “lightweight” clients in these devices that can interact with blockchains in a reliably safe way with less computational requirements.
Payment processing compatibility with merchants at point of sale: For users that already hold crypto-currency, spending that currency should be as approachable as executing an e-commerce transaction on chrome with a saved credit card. (ie. enter a 3 digit CVV and voila). We’ve seen movement in the right direction from players like Shopify and Square, however, we’ve also seen moves in the other direction for stripe. An elegant solution that allows the customers of merchants to pay in their currency of choice, while not overexposing merchants to the volatility of certain tokens or coins remains to be seen. Progress is being made in this problem domain by Coinbase commerce, Globee, and CoinGate among others.
Asset custody: A problem that plagues builders at level 2 and consumers at level 3 alike is storing large amounts of cryptocurrency in a secure way that doesn’t expose you to bad people who want to take your money, but also doesn’t involve jumping endless hoops to stay secure. We’re excited to see projects launching in the next few months tackling this problem including Kn0x out of Montreal, Canada as well as Coinbase and BitGo but admittedly, more needs to be done here, specifically for the everyday coin holder.
Did we miss anyone or anything? Let us know in the responses.
If you’re building something related to any of these (or thinking of doing so), we want to help. We’d love to put our resources, connections, and capital behind these!
This post was created with love from Sam Pajot-Phipps, Erik Iglikov, Zana “Zee” Amin, Karim Zeine.
