Blockchain is gaining interest widely in the technology sector as a novel method to distribute information, value, and trust across networks. The rise of blockchain technology has also resulted in a new form of application, a “Decentralized App”, or “DApp”. A DApp is powered by “Smart Contracts” which run on top of a blockchain. There is a lot of interest in these new forms of applications, and deeper analysis is needed to assess the feasibility of these applications obtaining the goals they aim to achieve.
Bartoletti et Al, in their recent paper acknowledge the fact that significant work remains for a sustainable secure platform on which to run decentralized applications:
“Despite the growing hype on blockchains and smart contracts, the understanding of the actual benefits of these technologies, and of their trustworthiness and security, has still to be assessed. In particular, the consequences of unsafe design choices for the programming languages for smart contracts can be fatal, as witnessed by the unfortunate epilogue of the DAO contract”
We, at Bitaccess, started working on Bitcoin blockchain technology in 2013. Last year, we launched a research project to build a DApp. We had tons of ideas, blockchain is currently being labelled as a solution for just about any problem.
Long story short, we started Velocity project. Velocity aimed to build a decentralized derivatives market. Through decentralization, Velocity would be a financial market with no counter party risk.
There are multiple challenges in building a DApp for financial services. Right off the bat, there are challenges even using smart contract programming languages (such as Solidity), as these programming laguages are very new, and may contain unknown attack vectors. Furthermore, there are numerous security best practices that should be followed when designing with these languages. One of the main challenges that gave us cold feet about the project was the need for real world data on a blockchain. In the push for decentralization and trust-less platforms, there remain large gaps in obtaining secure data. For a DApp to benefit from decentralization, there should not be a single point in the design in which trust is a requirement. As it stands currently, without access to financial data which is native to a blockchain, full decentralization is an impractical goal.
To come to this conclusion, we developed a proof of concept data feed on Ethereum testnet called PriceGeth. It works as follows:
In the figure, the red boxed are components which are centralized. This figure outline what is generally referred to as an “oracle”, a service which publishes real world data to a blockchain. Smart contracts which consume this published data are must trust:
- The owner of PriceGeth Server; or
- The PriceFetcher Module which basically stores the exchange API values in a database, thus the Exchange API itself
Fundamentally, one of the only ways to have a fully trust-less financial market is to have trust-less data. For the velocity project, this would require a full exchange market on the Ethereum blockchain, whose order book can be used as a data-source.
There are some other challenges and conclusions which have been explained with great details in our paper on the subject.
After significant work on the project, we elected decided to write down our experiments and what we learned in a more systematic manner. We are proud to announce that we will be presenting our peer reviewed paper at 1st Workshop on Trusted Smart Contracts In Association with Financial Cryptography 17 on April 07, 2017.
Here’s a copy of the final version of the paper: On the feasibility of decentralized derivatives markets
To summarize the conclusions, there are significant challenges to building any form of financial markets on a blockchain today. Given the popularity of centralized, counter party-backed systems, decentralized markets will have real challenges in gaining any form of traction due to their current limitations.
Conferences such as the “Workshop on Trusted Smart Contracts” are a great first step towards overcoming these challenges, but the industry likely needs to set expectations more prudently on what is truly possible.