Hello BitCar enthusiasts.
Today we present you with some of the technical challenges that we and many other blockchain projects currently face. We are looking for your innovative and clever ideas!
With this new series of blog posts, we hope not only to engage in the process of becoming more transparent about what we are doing but also to get some positive feedback from the community. Hopefully, we can then learn about, and share some clever ideas on how to solve some of these common Blockchain / Ethereum decentralized technical challenges.
Problem:
As some of you may be aware, the Car Token (tokens representing a particular Platform Car) will have a fixed supply and will be pegged to a fiat currency on a 1:1 ratio, i.e. say a Ferrari worth USD 1 million comes onto the BitCar platform, then it will get 1,000,000 of its own Car Tokens, unique to that car. This means that when these Car Tokens are bought, using some of the post 31 July 2018 token burn’s 111,485,497 circulating supply of BitCar tokens (these are different from the Car Tokens), a conversion needs to happen in order to calculate the right number of BitCar tokens per Car Token. The problem is how to cheaply and quickly get external BitCar token price data onto the Ethereum blockchain. Ideally, a solution would be available that is not only cost effective but also truly decentralized. Currently, we don’t see a strong one, do you?
Solution #1: Oraclize
By using Oraclize, one can get external data into the Ethereum blockchain, but it comes at a substantial cost (literally). Although the one-off Oraclize fee is not that expensive, our necessity of querying multiple sources of data increases the cost by a few orders of magnitude. These queries are required to do some serious calculations, in order to prevent fraud and improve price data quality. In some preliminary tests, we calculated that querying two sources of data from random exchanges would cost $5, these costs also derive from the fact that Oraclize “detaches” the workflow of the SmartContract, with the implementation done on the “callback”. This may also open unforeseen security issues and even result in no execution at all. On top of this, although Oraclize is a trustless service, it still relies heavily on centralised components. We seek to remove all centralized components, so this solution is expensive and not truly decentralized, at least for the time being…
Solution #2: Decentralized Exchanges
These days, we note most decentralized exchanges keep the order book off-chain, making it hard to get accurate real-time data about a token. Some, however, such as EtherDelta do have an on-chain order book, which is not used just due to the costs and speed involved. One could potentially keep transacting on this on-chain order book allowing a SmartContract to query the last fulfilled order and thus getting the token ticker data. But a technicality, other than the costs involved, is that two tickers would have to be maintained since it is unlikely to have a Token→FIAT pair, having to track both the Token→ETH and ETH→FIAT. This solution is still somewhat centralised, but it is likely that a decentralised approach can be taken where a SmartContract would be responsible for the trading. How would you solve this? Any ideas?
Solution #3: Decentralized Storage
With a solution such as IPFS or Ethereum Swarm (we like them!), one could potentially come up with a clever design that allows for “unlimited” resources to fetch, parse and add live pricing data to the Ethereum blockchain for use by a decentralized platform like BitCar. With Swarm the proposal is interesting but it does not yet seem simple enough to achieve our need, as private keys need to be shared across all nodes. In our view, this could leave it open to undesirable malicious activity. Swarm may have a solution for this, but we sense it is not yet mature enough to be used in our production environment. Also, with IPFS, which we have been fans of since 2015, in a way, a complete infrastructure needs to be built and put in place and maybe even an incentivisation scheme in order to help it grow. What are your ideas for moving live data onto the Ethereum Blockchain in a cost-effective manner?
Solution #4: Centralised Approach
The easiest solution is to stay centralized, it is easy to achieve, extremely resourceful, reliable and in a way the cheapest. But by relying on a centralised approach such as AWS, the weaknesses of a centralized approach remain — and there are many. They are simply not suitable for new blockchain technology products like BitCar. One can perform endless calculations in order to detect malicious behaviours from exchanges, for example, calculate the Token→FIAT and add the price to a “TickerTracker” contract. Simple but centralised (ugh).
Please let us know what you think about some of these technical challenges, what you think is the best solution to implement the above, for the upcoming BitCar.io peer-to-peer exotic car trading platform. Your feedback and support are highly appreciated. Please comment below or contact us on Telegram. Any very clever solutions we adopt may well result in some free BitCar Tokens being donated* to the responsible party! So get your thinking hats on and start testing code!
*at the sole discretion of BitCar, and for non-US residents only
As always, follow all of our social media accounts to stay up to date with the latest happenings, and join our Telegram group to speak directly to the BitCar team.
