Insights into the Blockchain Summer School 2017
A short essay on one of the results of the Blockchain Summer School in 2017 in Copenhagen.
The Blockchain Summer School was first held in 2016 by the IT University of Copenhagen and was held again in 2017 from 14th until 18th of August, this time from the University of Copenhagen. Around 70 students participated in the summer school, supported by about 20 advisors consisting out of professors, research associates and experts from enterprises and start-ups. To get accepted into the school, the students were required to write a proposal about a Blockchain idea to provide a common baseline knowledge. Additionally, a “Required Readings” list was published, consisting out of various papers and books about Blockchain and surrounding topics as design science, cryptography, and innovation.
The organizers divided the week into three parts. The first part, starting on Monday, consisted out of lectures about different areas and aspects of Blockchain technology and gave a good introduction to the topic. The second part, taking place on Wednesday and Thursday, was a Hackathon, where predefined groups were assigned to certain use cases. These use cases were not generated out of the submissions of the students but came from the participating enterprises, start-ups, and NGOs. The third part, taking place on Friday, contained the presentation of all results and the second Nordic Blockchain Summit. The best eight teams (out of 16) were allowed to present their prototypes to the audience, which afterward had the opportunity to vote for their favorite Blockchain use case for two categories: Startup and Enterprise.
Overall, several experts presented on the first three days of the Summer School. As all documents are available here, presentations are not discussed in full depth.
Omri Ross held the introductory session. He talked about two possible applications of Blockchain: KYC (know your customer) / AML (anti-money-laundering) with BC technology and Automated execution of financial contracts on Blockchains. The second session this day was held by Prof. Fritz Henglein, who gave an introduction to Blockchain technology and smart contracts. He talked about where the Blockchain technology has its strengths, about different applications and different theoretical foundations as the Cap theorem, the Byzantine consensus, and Sybil attacks. Boris Düdder held the third session on the first day and talked about the technological foundation of Bitcoin and Blockchain. The last two sessions on Monday included an introduction to the development of Ethereum/Solidity and R3/Corda.
On the second day, two lectures took part. The first one was held by Prof. Michel Avital from Copenhagen Business School who talked about the sweet spots of Blockchain. He proposes that the sweet spot lies where the technology push meets the radical change in business. Additionally, he thinks that the Blockchain should be considered as a black box (“trust machine”) to generate useful ideas. The second talk was held by Roman Beck who talked about the standardization of Blockchain Technology. First, he described some technology his chair is working on in cooperation with different external enterprises. Second, he presented the results of the first ISO meeting in Sydney, where countries were assigned to work on various resorts of future standardization of Blockchain. At last, Martin von Haller Grønbæk talked about the Blockchain from a lawyers’ perspective and where he sees problems.
As the general talks were over, different enterprises and startups presented their use cases for the Blockchain Summer School. In total, there were nine different use cases, four in the enterprise category and five in the startup category.
Nordea – Repos
Repos are so-called repurchase agreements (or collateralized deposit) between two single entities. An owner of a bond (a title of a country) gives it to the buyer of the collateral and receives money for it. Later, the original seller repurchases the bond for the same money plus interest. These businesses are facilitated over three different venues: bilateral, tri-party and CCP. However, all these three venues require the filling of the GMRA (global master repurchase agreement), which is a paper-based document answering different kinds of questions regarding the repo. The participants should transfer this process to a Blockchain-based solution.
Maersk – Indirect Tax
Maersk is interested in an overall computation of their net tax liabilities /assets. However, they have many different IT systems (approx. 30) in use. As of that, they have to export different information out of the different systems to combine them manually. These processes are costly, error prone and take a long time. Therefore, they want to automate this somehow. For this, they think about a Blockchain-based approach.
Maersk / Nordea / Nets – Swift
Maersk has many accounts by different banks and their subsidiaries over the world. All these banks support one specific standard of communication, the SWIFT network. However, onboarding a new account or payment type is very costly and takes up to three months. These processes should be simplified and executed via Blockchain based technology. It is possible for the participants to replace the current SWIFT system.
Nets – Asset Lifecycle Management
Rather than describing a problem, Nets described a complete use case. Nets wants the participants to create a Blockchain enabled Marketplace for asset life cycle management. They want the possibility to place assets on the Blockchain, let them verify via an asset verification agency and create a market for these assets.
Bloc – Solar Shares
As Nets, Bloc proposed a use-case themselves. Mainly, they want to sell shares of a project which invests in solar energy on buildings. The idea is that an owner of a building can offer his roof to install solar power. Private investors can participate by buying a share for 5.000 kr (approx. 670€). After the money is collected, the building is equipped with solar panels bought from the 800 shares. Each token has a 5.9% ROI per year. The use case should be built using Blockchain technology.
Densou – Preventing Advertisement Fraud
Densou is interested in preventing advertisement fraud in online marketing. Fraudsters act as they would be a regular site (e.g., CNN) and place adds on their “fake” website. Instead of the advertisement being shown on the real CNN web page, the fraudster claims to have shown the advertisement to a user. Because of this fraud, more than 10% of all advertising goes to fraudsters. This problem should be solved with Blockchain technology.
Chainalysis – Evaluation of ICOs
The use case of Chainalysis is different to the other use cases as they do not work with Blockchain technology, but only with the data. The main goal is the investigation of so called ICOs (initial coin offerings). The participants should answer questions as: How are the tokens distributed amongst investors and issuers? What are the origins and destinations of all funds regarding Anti-Money-Laundering? How are investors protected? What are legal aspects? What are economic aspects of continuing the work after receiving the funds for the founders?
A deep dive into NepCon - TimberTrack Use Case
As one use case was not described previously, we take a deep dive into the use case that the author was working on with his team.
NepCon is an NGO that deals with the environmental issues of deforestation. They are one out of many certifiers which talk to forest owners about their forest, the nature in the forest and the possible timber cutting volume per year. If everything is alright, they certify the forest and the owners are allowed to sell the wood as certified. However, as there is no continuous control of the supply, it is easily possible for anyone in the supply chain to sell uncertified wood as certified. This problem increases because many steps of manufacturing are involved in the supply chain. For example, wood gets cut down in the forest, then again it is cut-up in smaller pieces, sold to different places, is rearranged, combined, built into furniture, burnt into coal or used in other products. Therefore, it is tough to keep an overview about the complete supply chain and to monitor possible intrusion of uncertified wood. Not only for the environment but also for the wood-processing industry is this a big issue, because the allegedly certified wood is sold for the same price as real certified wood. While they lose money, they also harm the environment. With a Blockchain-based approach, a solution should be accomplished.
Searching for a solution
The problem with this scenario is that we cannot track each tree individually, because the virtue of the tree changes in every manufacturing step, such that even DNA-tests cannot be done, as the information gets destroyed if the wood is burnt. Therefore, we are not able to represent every single piece of wood (or products out of it) in the form of some token on a Blockchain. However, that seemed not to be the major issue in this problem space, as the overall volume is the issue. We cannot prevent the selling of uncertified wood at all, as we do not have any influence on that. However, we can prevent that any participant can sell more certified wood as he bought or produced.
The idea is to control the volume: With every piece of certified wood or sold products thereof, the equal number of tokens represented on the Blockchain is sent to the receiver. With that and the simple rule “If you buy certified wood, it has to be accompanied by the same amount of tokens.” it can guaranteed that the overall volume of sold certified wood stays the same. By that, as only the producers are able to create tokens, the certified wood can be swapped for uncertified wood, but then later on the seller is only able to sell its certified wood as uncertified, because he doesn’t have any tokens left. With that, the volume is restricted to the overall volume of certified wood, and no illegal increase can happen.
The technical solution
With the approach of volume restriction, we are able to create a prototype with a Blockchain. From a software-technical point, we had to decide between Ethereum or R3 Corda. We decided to use Ethereum and Solidity, as Ethereum ensures a single global state whereas Corda only ensures a state within a transaction, such that we are not able to guarantee the compliance of the volume restriction.
After this decision, we have to think about the design of the smart contracts. We have to keep the restraints given by the supply chain in mind, which are following: 1) There are many different types of wood and products resulting out of the manufacturing of wood which all have to be traced. 2) There are clear “exchange rates” for the manufacturing processes: For example, 1m3 of burned wood would result in 0,8 m3 coal. 3) Many certifiers should be able to “certify” (allow) forest owners to create new tokens. 4) New tokens and exchange rates have to be added “on-the-fly”. There are three technical approaches: 1) One Smart Contract (SC) which contains everything, 2) For every new issued wood an own smart contract where all information is traced or 3) a middle ground between these two solutions.
We chose approach 3 and came up with a basic solution consisting out of three different types of SC, a central authority SC (CA), an exchange SC and a Template SC for Tokens. The idea is that we use the CA SC to register all participants with their rights: What are they allowed to do, who is allowed to issue new tokens and other restrictions. For every new asset, we create a new Token SC which is registered in the CA SC and in the exchange SC. The Token SC keeps track of every token, who owns it and allows transactions to other participants. With the exchange SC (which contains the exchange rates) we are able to facilitate atomic transactions, where one token is exchanged for another. It works the following way: A user wants to exchange token #0 for token #1 and sends a request to the exchange to execute the rule where this exchange is described. The exchange SC asks the token #0 SC if enough funds are available. If that is the case, the exchange deletes tokens from token #0 SC and adds the amount to the token #1 SC. Because all the exchange SC is registered in the token SC, no one else is able to act as exchange and possibly manipulate the volumes of tokens. As all functions are executed atomic, a user is not able to transfer the token to another participant while at the same time exchanging it for another token. In that case, one of the two actions will fail, and the overall volume stays the same.
Possible Issues with this approach
However, this approach has some drawbacks. First, we are not able to track any meta data, because we cannot embed any information to a single token. This form of lookup has to be implemented differently: Instead of accessing meta data, one should access the history of the token (who owned it, what was it converted of) to “generate” meta-data. However, this approach seems feasible, but is only possible with lots of manual work, as Ethereum does not provide an interface for that kind of operation. Second, again we have a central authority which “owns” the system and has the possibility to manipulate the system. It remains unclear, which “real world” entity should take this position, as it would have very high power. It also would be the one to define new exchange rates and tokens. Third, every participant of the supply chain has to use the system, otherwise, the transaction chain “breaks” and participants are not able to receive their coins. Therefore, an adoption rate of 100% has to be facilitated.
As to every negative aspect, there are some possibilities to overcome this. Regarding the central authority with a lot of power, it would be possible that this single entity could be replaced with a DAO (decentralized autonomous organization), where decisions are made in a democratic way amongst all participants (or certifiers). With that, fair decisions could be made.
To get to the 100% adoption rate, it should be the goal to convince major buyers (e.g., IKEA) of certified wood to adopt to the system. They are able to force their suppliers onto the system, as they would only buy certified wood when it is accompanied by the same amount of tokens on the Blockchain. With that, the system would be “forced” from the end to the beginning of the tokens, which could be a reasonable way to introduce the system.
From an educational point of view, the Summer School was very instructive. I personally, took a lot out of the week working on the NepCon use case, thinking about possible solutions and putting them into practice. However, thinking about the other use cases, I noticed that we are still not in a position where we can decide beforehand, if a use case is suited for Blockchain technology or not. Sure, there are lots of rules or approaches to that problem, but nothing that would answer this question once and for all. In my humble opinion, many solutions to the use cases do not require a Blockchain at all, but more or less sophisticated traditional software engineering. That’s where research has to find answers.