Blockchain @ GFT: Project Jupiter
12 February 2016 // SmartContracts for SmartPhones
Since launching Project Jupiter, we have made some great success in a relatively short space of time. Having already built a working Blockchain prototype – in this case to manage identity, provenance and location for physical commodity assets – we are delighted to now showcase the convergence of technologies across mobile and blockchain.
GFT is able to showcase our prototype business process driven from a mobile app running on a SmartPhone.
This new mobile version enables users to capture physical commodities assets through a mobile phone and update blockchain records using this integrated technology solution.
A blueprint for initiating business change using Blockchain
We are also very pleased to publish our new blueprint for success in developing and scrutinising potential use-cases for Blockchain. Our paper demonstrates the experiences we have had, and provides a best-practice blueprint for Blockchain success. We also examine how the financial services industry is looking at solutions around Blockchain concepts to disrupt traditional modes of working more widely and realise the potential of distributed ledger technologies. We aim to help clients understand the distributed ledger phenomenon and potentially create a paradigm shift in traditional markets.
To save a copy of our latest paper, click here to visit the point-of-view page for our paper entitled ‘A blueprint for initiating business change using Blockchain’.
We look forward to bringing you more Blockchain news and developments as they happen!
Author: Julian Eyre
18 January 2016 // The next step!
Having reached the end of our latest sprint, we are delighted to now be launching our commodities consensus computing prototype. And what a rapid journey it has been! The prototype demonstrates how it is possible to track physical commodities assets through the use of a distributed ledger-based business model. The whole team are really pleased to have reached this stage of the project in such a short space of time, so congratulations to all those involved!
At GFT, we have recognised for some time that whilst Blockchain has the potential to transform how people do business and co-operate with one another, such improvements cannot be made with technology alone. The current Blockchain phenomenon has encouraged traditional industries with rigid and established legacy processes to look at how they do business through a new lens, promoting some truly disruptive thinking. The launch of our prototype for commodities is a testament to this new way of thinking – using the practical application cutting edge frameworks and technologies to solve real-world, practical problems.
The learning experience for all those involved in the Project Jupiter incubator team has been tremendous – and we are already thinking about the next application of Blockchain solutions for other markets. By facilitating the rapid prototyping of potential Blockchain solutions, we can quickly demonstrate the opportunity for market evolution or ensure that the project is allowed to fail fast. With this innovative environment, we are able to provide our clients with some truly transformational insights.
We look forward to bring your more news on these developements as they happen!
Watch out for our soon to be published „Blueprint for a Successful Blockchain Project“.
Author: Nick Weisfeld
15 December 2015 // An essential read
Great post from Ayad Hindi who is the Lead Business Analyst on Project Jupiter. In his post he gives some real practical insights into some of the issues you will face when developing a Blockchain based application. If you are considering getting into this space it is an essential read.
Author: Nick Weisfeld
11 December 2015 // A design consideration
A vital design consideration we have made during this project is how to cache the data between the Ethereum nodes and the application. The nodes themselves have slow read latency so we have implemented a simple write-through caching mechanism to speed up the read access without introducing a synchronization problem by using a separate database.
Author: Jon Cooke
09 December 2015 // Our architecture solution
It has been very exciting to be part of GFT’s Project Jupiter and work on such an innovative leading edge disruptive technology as Blockchain. As the team’s BA, I will be sharing interesting Blockchain insights we encounter along the way. Further thoughts will also be provided by the Heads of the GFT Data Practice, Nick Weisfeld and Jon Cooke.
One of the technical objectives of Project Jupiter is to explore the use of smart contracts. Smart contracts are of particular interest to the financial services industry because they allow the coding of contract terms so that the obligations of the contract are settled automatically when the coded conditions are met. And being programmatically enforced, you can be sure that the smart contract will be executed exactly as agreed.
That’s the reason we chose Ethereum for our private Blockchain implementation. It’s the most mature smart contract platform, with the first Turing complete smart contract programming language out there – Solidity.
One of the first questions that came up when talking contract during our sprint planning session was: how big is a smart contract? Well, it seems like the answer is surprisingly small – 20 fields might already be pushing the envelope!
The reason behind this is perfectly logical. Since we are talking Blockchain, every participant/node takes on all the work of every other node – and as Ethereum is designed as a public Blockchain, anyone can join the network and send work to all the other nodes. Therefore there needs to be restrictions on the size of smart contracts (which are compiled into byte code with their data stored as state) as otherwise you could have a single transaction node placing too much load on all the other nodes – potentially grinding the whole network to a halt. In other words, a kind off Blockchain denial of service attack!
Of course this is not an issue with private Blockchain where all participants are known and trusted – which is the Project Jupiter case, but as we are using the Ethereum implementation, we bring these restrictions with us.
Ideally we’d create a branch off the main Etherum code specific for private Blockchains and remove these limitations. Not a trivial task, but given the amount of people and organisation working on Ethereum variants, we wouldn’t be surprised if someone does this fairly soon.
In the meantime, a successfully workaround has been implemented by GFT Blockchain developer Ivo Zielinski. In short, we’ve created a hierarchy of container contracts holding subsets of the overall data and referenced these in the original top level smart contract- which could be a nice way to structure data into a logical form.
We could have architected the solution in such a way to store the data in a database outside the Blockchain and reference it from our smart contracts, but that would have defeated the whole point of distributed trusted ledgers. This, we therefore decided, was a compromise we were not prepared to accept.
Author: Ayad Hindi
03 December 2015 // Mission launch complete!
Great news – We recently finished the first Jupiter sprint and held our first show-and-tell. A big thank you goes out to our development team who have delivered all sprint 1 story points and have even started delivering functionality from the sprint 2.
In one week we managed to deploy a smart contract and use it to publish and update a block on our Geth (Go Etherium) based private Blockchain. The design team have also finished the first version of the wireframes for the UX.
Shortly we will start on sprint 2 which includes a base UX that “gets” data from our private Blockchain through a REST API. This is quite a stretch target but the development team, fresh from the success that they experienced this week, feel that this is achievable.
This will ultimately prove to be a pivotal sprint in the project as it will prove UX to Blockchain interoperability. The good news is that there were no surprises so far.
We will keep you posted on how the project progresses!
Author: Nick Weisfeld
Find more information here: The leading distributed ledger and Blockchain business and technology advisory organisation.
