There has been discussion recently about making BitShares more accessible to dapp (decentralized application) developers. This discussion has been primarily focused around creating additional documentation to help developers understand how BitShares works today, how it is implemented, and how they could utilize the blockchain infrastructure for their dapps.
Unfortunately, however, BitShares, as it exists today, was designed as a decentralized financial services platform, and is not well-suited to general dapp development. While it is theoretically possible to develop dapps that leverage BitShares infrastructure for decentralization, the blockchain lacks major facilities for decentralized application development, leaving developers to invent these solutions for themselves. In light of this fact, mere documentation is not sufficient to make BitShares an inviting platform for decentralized application development.
It is worthwhile to note that this does not mean that BitShares is behind the curve. Other blockchain platforms that are specifically billed as dapp platforms also neglect to provide facilities to make dapp development quick, easy, and painless. These platforms provide turing complete smart contract virtual machines, which allow any computable algorithm to be evaluated in a decentralized manner. While this is a useful feature, as it allows dapps to pass arbitrary logic to a blockchain for decentralized evaluation, it is neither a silver bullet that makes arbitrary dapp development simple nor is it an adequate facility for dapp deployment.
In fact, turing complete virtualization of smart contracts is, perhaps, overpowered for most dapp use cases. Turing completeness provides arbitrary support for any possible smart contract; however, with great power comes great responsibility... and complexity. These platforms can support any possible contract developed in any possible way but provide little or no guidance as to the best way to develop any particular contract. This open-endedness makes the dapp developer's life difficult: there are infinite ways to develop his application, but he is given few clues as to what ways are best, or even what ways there are at all.
Resultantly, there is a substantial opportunity in the dapp platform market. While it may appear, at a casual glance, that the major players are already established, the reality is that no platform has yet succeeded. Dapp development is currently sluggish, requiring teams of highly competent developers and enormous planning to develop even trivial dapps. New projects are announced most every day, yet roadmaps stretch on for years and few to none of these projects are reaching even a functional alpha stage. The industry is ripe for disruption, and a platform that provides readily-usable facilities and demos for all of the fundamentals of dapp development could realistically take the market by storm.
Existing blockchain platforms provide some rudimentary fundamentals for dapp development, including a decentralized timestamping service and message posting board, decentralized indexing and database management, trustless token contracts of various descriptions, and some platforms even provide an identity system available for dapps to leverage. These are all important components of dapps, and while they make dapp development possible, they lack some crucial functionalities necessary to deploy a successful decentralized application, leaving dapp developers to resolve these issues for themselves.
To launch a successful decentralized application, the developer needs access to secure, but off-chain solutions for communication. This particularly includes bulk data storage, such as for app code and resources, as well as real-time communications, which is to say, sockets. The ideal dapp platform will provide trivial API access to solutions for both of these concerns, and fully support signing and/or encryption with keys associated with the on-chain identity system. The platform should also provide decentralized deployment strategies for the off-chain dapp user interface(s), supporting both delivery of the application code and code signing/verification against the developer's on-chain identity. Existing dapp platforms do not provide adequate infrastructure for these concerns.
In addition to communication frameworks, existing dapp platforms have neglected to provide viable models for financial applications. The platforms provide models for token creation and transfer, but developers are left to develop their own models for storing and managing tokens during the intermediate stages of ownership when tokens are managed by the dapp and do not belong solely to any particular user. During intermediate stages of ownership, existing platforms provide neither models nor infrastructure to facilitate the secure control of tokens, nor for the representation of the status of contract-controlled tokens to contract parties. Perhaps more alarmingly, smart contracting platforms make little or no provision for emergency protocols in the event that real-world conditions evolve outside the bounds predicted and provided for by smart contracts, for instance, due to the death or incapacitation of a key party to the contract. Naively developed smart contracts may make no provision for such circumstances, leaving remaining parties to the contract no secure option to ever recover assets controlled by contract code.
Existing blockchain platforms, even ones which aim to be decentralized application platforms, provide inadequate support for the communication needs of dapps and for the needs of financial dapps to securely store tokens in intermediate phases of ownership and represent the status of these tokens to users. These shortcomings constitute an opportunity for BitShares to overtake competing platforms as a target platform for the development and deployment of successful smart contract applications.
To fully provide for the needs of real-world decentralized applications, BitShares must provide facilities for the following concerns:
- Encrypted P2P communication between dapp nodes
- Indexing and database management
- Secure off-chain storage of bulk data
- Smart contract asset management framework
- Dapp user interface deployment strategy
We now examine each of these concerns in detail and describe solutions for addressing them in the BitShares ecosystem.
The P2P networking layer utilized by BitShares today is the single most aged module in the entire project. Heralding back to BitSharesX, the network code is the only module that was preserved through the upgrade to the Graphene blockchain framework and BitShares 2.0. Replacing the networking layer has been extensively discussed within BitShares development channels, and is considered a priority for future BitShares evolution.
The libp2p protocol from Protocol Labs has been suggested as the basis for an alternative networking layer for BitShares. This protocol supports a rich, heterogeneous ecosystem of subprotocols within a single P2P network, allowing many different node types utilizing an assortment of protocols to exchange messages over a shared P2P network. If BitShares adopted such a networking solution, BitShares-based dapps could easily leverage this network layer as well to provide for their real-time communication needs.
A full description of a new P2P network solution for BitShares is outside the scope of this document; nevertheless, a brief overview is appropriate. A blockchain network is primarily a broadcast network, as nearly all blockchain communications are broadcasts (i.e. new transactions and blocks, which should be disseminated among all nodes as quickly as possible). Other communication types, such as fetching historical block data, can be carried over direct peer-to-peer connections. Therefore, the main P2P network should emphasize efficient broadcast delivery of transactions and blocks, and discovery of peers and services. Nodes seeking particular services such as API access or historical blocks may utilize the main network for service discovery, but then carry out further communications in direct peer-to-peer connections. Likewise, dapps may utilize the peer and service discovery aspects of the main network, then establish direct connections for further communications.
Indexing dapp data records into a database is necessary for dapp user interfaces to rapidly retrieve up-to-date records and display them to users. Graphene blockchains utilize an in-memory relational database to provide for the database requirements of core consensus dapps, however, BitShares provides no mechanism to make these facilities available to third-party dapps. Moreover, attempting to provide for all third-party dapps' database requirements in a single, memory-resident database is not a scalable solution: the EOS blockchain, a Graphene-based turing complete smart contract platform, utilizes such a solution for dapp database management, and even at its young stage of development, is running low on memory space to support all of these dapps, driving memory prices up and making dapp deployment an expensive proposition. An alternative solution is necessary.
One of the main difficulties of decentralizing third-party dapp databases is that decentralization hinges upon replication of effort: many nodes must redundantly track the blockchain and construct indexes of relevant data. This replication of effort is expensive and therefore is only worthwhile for widely applicable indexes; however, most dapps are, at least initially, niche concerns, and the cost of redundantly storing indexes for them is greater than the benefit to most participants in a blockchain ecosystem. Accordingly, an ideal database solution for third-party dapps should scale in redundancy: low-usage, niche dapps require less database redundancy than popular dapps with wide exposure.
Consequently, one way to provide for the database management needs of dapps is the addition of a plugin to BitShares to build indexes for selected dapps and expose these indexes over the API. Node operators wishing to provide support for a particular dapp would configure their nodes with this plugin to track and expose the dapp's database. Dapp instances could then use the P2P network's service discovery functionality to find and connect to these providers. This model is lean and versatile, able to provide for the needs of young dapps with small user bases. As each particular dapp's exposure grows and more nodes begin tracking its database, these nodes can organize into a side-chain with its own consensus protocol, publishing database hashes to the main BitShares chain to fully decentralize the dapp's database tracking.
Real-world dapps will require significant storage space to host user interface code and resources, user-generated content, cat gifs, etc. This data is too large to store on-chain, but still must be secured against tampering. One convenient solution is the Inter-Planetary FileSystem (IPFS). IPFS is a DHT-based protocol that facilitates the lookup of arbitrary data by its hash, connecting requesting nodes to providing nodes so that if the requested data is stored by any node on the network, it can be located for the requester. Dapp developers can expose bulk data for retrieval over IPFS, and store the data hashes on the blockchain where dapp instances find them and can look up the full data over IPFS. Retrieved data can then be compared against the hash from the blockchain to verify its authenticity and integrity.
It is important to consider the issue of who hosts this data. IPFS is merely a discovery protocol, it does not itself provide data storage. It is up to the dapp developer to ensure some node exists which provides data relevant to his dapp over IPFS. As the dapp gains exposure, more nodes may opt to host its data, reducing individual server load and retrieval times. If the dapp developer is the only provider of dapp data in the IPFS network, he has the power to censor user-generated data within his dapp by refusing to host it; however, anyone else could then host the particular censored records (without needing to host any other data), making them available once more and leaving the censorer no further recourse to remove the data.
Transferrable tokens are the single most widely supported blockchain application today. It was the application of Bitcoin, the first blockchain. These apps support the censorship-resistant transfer of tokens between users, and sometimes even the private transfer of said tokens. More advanced smart contracts which take control of tokens away from any particular user and distribute tokens according to some predetermined algorithm are widely discussed, but less widely implemented, and frameworks for managing assets under contract control are virtually nonexistent.
To make realistic financial dapps viable, a well-understood and battle-tested framework which makes the definition of secure, stable financial smart contracts straightforward must be devised. Furthermore, these contracts must be readily scrutable to non-technical users. As a financial services blockchain, the provision of such a framework sits squarely within BitShares's wheelhouse. To this end, the Tanks and Taps framework has been proposed as a feature for a future BitShares upgrade.
Tanks and Taps defines modular, composable structures for asset storage and control which are anticipated to be suitable for a wide range of financial smart contract applications. Furthermore, these structures are readily visualized, making straightforward the development of user interfaces that give users a technically sound understanding of the status of contract controlled funds and what options they have for managing these funds under contract.
Blockchains are the domain of smart contracts, but smart contracts are only one aspect of decentralized applications. A usable dapp must feature a graphical user interface application, but current blockchains provide little in the way of a deployment strategy for these interfaces, leaving dapp developers to invent their own. This fragments the ecosystem and inhibits the growth of network effect on a particular dapp platform.
The capstone of this vision of BitShares as a dapp platform is a blockchain-based dapp browser application, inspired by the application architecture of the world-wide web, but where the web utilizes trustful infrastructure for the lookup and delivery of application code and resources, the dapp browser would utilize fully trustless infrastructure. Dapps will center around named BitShares accounts which publish on their account object an IPFS hash of the dapp interface bundle. The browser would feature an "address bar" where users would type the name of the dapp they wish to access, triggering the browser to look up the dapp account's published interface bundle hash on IPFS, then fetch the bundle, verify it matches the hash, and render the dapp interface to the user.
The dapp browser would be a node on the BitShares P2P network, using the network for service discovery to look up API nodes capable of resolving the dapp names to blockchain accounts. The browser would also provide to loaded applications with high-level APIs for all of the concerns relevant to decentralized applications, including P2P communications, database API service discovery, IPFS lookups of bulk data, and the creation of and interaction with tank-and-tap structures and the visualization thereof.
Interfaces for all other BitShares services, including the BitShares reference GUI, could then be implemented as dapps accessible through the dapp browser, and their functionalities exposed to other dapps, allowing the construction of a dapp ecosystem to rival the world-wide web, fully integrated with trustless BitShares infrastructure for identity and finance. Publishing a Hello World dapp within this ecosystem would be as simple as registering a BitShares account and publishing an app bundle on IPFS, but facilities for more advanced dapps including powerful networking APIs, identity-based cryptography, widely applicable financial smart contract creation and visualization tools, and access to an ever-expanding ecosystem of other dapps, would all be readily available from within the dapp browser execution environment.
There is a major push in the blockchain industry to provide general platforms for decentralized applications and smart contracts, however, the blockchains whose target use case is to be a dapp platform have not made the development nor deployment of decentralized applications quick or easy. These platforms require enormous investment to install and configure, learn to use, and develop for. They provide little or no infrastructure to facilitate the deployment of dapps, nor for many of the other concerns of realistic dapps.
This leaves an opportunity for other platforms to seize the market by providing a platform that facilitates the rapid development and deployment of powerful decentralized applications. It is possible to develop BitShares into an ideal dapp platform by adding some key features, including a general smart contract asset management framework and an extensible P2P networking layer, and developing a dapp browser with APIs for dapp networking, identity-based cryptography, IPFS data storage, and financial smart contract management. With these features, BitShares would provide a dapp platform that rivals the world-wide web for ease of application development and deployment, and surpasses it for trustless security.