Last week I shared with the 101Blockchains community of professionals and digital innovators the Blockchain vision we have at Telefónica and how companies can create value by adopting this technology. If you are curious you can check the full presentation at this link.
But in addition, in the debate with the attendees the common challenges faced by companies when adopting Blockchain were raised again. I had the opportunity to confirm them with the audience by launching two questions. The results, without claiming to have any statistical validity, do point to certain trends that we can analyse. But above all, they suggest the first of the priorities that we must address in our Blockchain project.
The technology
On the type of blockchain preferred for business applications, the majority options were private and licensed networks. Bearing in mind that the options were not exclusive, we could even conclude that the majority of participants prefer this type of network. The third option chosen by a third of the audience was the public Ethereum network.
With the second question we tried to find out the main concerns of the attendees when adopting blockchain in their operations. Again the answer left no doubt. In this case we were presented with the business version of the blockchain trilemma, that is to choose:
- the traceability and transparency of public or licensed networks to the detriment of scalability and performance
- the scalability and performance of private networks while renouncing a certain transparency.
We can easily relate the two answers. A minimum transparency of the operations that are recorded on the network is guaranteed by the technology itself. The more participants, the more transparency and guarantees about the immutability of the recorded information.
In those use cases that are intrinsically connected to the business or with exigent performance requirements, the preferred technologies are those that offer the possibility of having more control and trust between the network participants. Especially Hyperledger Fabric is the de facto standard in these cases. We are talking about environments with few known participants, for example supply chains or data reconciliation platforms. However, for those cases where transparency is the key, companies find in the public Ethereum network, with thousands of independent participants, the perfect ecosystem to trace their operations and allow third party verification.
The importance of a PoC and Minimum Viable Ecosystem
We have already chosen the technology that best suits the requirements of our use case. Now we must ensure that once the solution is deployed it will help solve the challenges of the case. To do this, the best option is to design a proof of concept and validate as soon as possible which minimum functionalities will allow us to create value for the business. Their scope is limited, and they are usually limited also to quickly demonstrate that this minimum functionality can be implemented. We place ourselves in the field of technology and technology always works. However, although it is very important, a proof of concept is not sufficient in most cases.
We need to relativise the functional level and analyse which attributes or components of the project will actually determine its feasibility. This is what we call not the minimum viable product, but the minimum viable ecosystem. The value of a blockchain project is in the value captured by all the participants. We have to identify the right participants to create sufficient value and understand the relationships between them, the governance, the operating model and how new participants can easily join, the systems with which they must interact and the integration interfaces with them. In short, it is a question of mapping out the interactions and the chain of creation and transmission of value: where, how and when it is created and who, how and when it is captured.
However, identifying all these components and relationships does not mean implementing them. For example, let’s think of systems that record, process and make decisions based on information collected by IoT devices. That input information can be simulated. Exactly the same with the information that can be received from information systems.
The important thing about the minimum viable ecosystem is to understand what information our solution is going to deliver, to whom, how and when. And furthermore, to assess whether this scenario is sufficient to approve the project.
A minimum viable ecosystem is never functional. It offers a complete vision of the impact that the solution will have on the processes on which it acts. We are not simulating the solution, we are presenting in the greatest possible detail all the potential scenarios and opportunities for the participants to capture part of the value created.
We can think of that minimum viable ecosystem as the intermediate step between a proof of concept and a pilot. The first is a conceptual approach and the second is already a functional exercise. A pilot can be made productive and scaled up to a productive system. The ecosystem must be implemented.
Return on investment
As a result of the minimum viable ecosystem we talked about the value captured by the participants. In any evaluation committee where the continuity of a project is to be decided upon, this value must be estimated. In blockchain projects we talk about a network and decisions are more complicated. The viability of the project may depend on the decisions on continuity taken by another of the participants. If one does not go ahead, the rest may not be able to generate enough value to make the necessary investments viable.
Therefore, the parameters of profitability and return on investment have more than one dimension in these projects. As part of the exercise of building the minimum viable ecosystem, it is necessary to understand the motivations of each participant and to value the benefits that each one of them will obtain from the project. In addition, it is frequent that in the same project, the different participants play a different role. It is typical for example a supply chain where distributors and suppliers are involved. Each one can obtain benefits of different nature and even in different exercises.
The benefit generated can be translated directly or indirectly into book value for the different participants. For example, let’s think about a food traceability project designed to convey greater confidence to the final consumer. In the medium term, this confidence may both retain the customer and justify a price premium. However, imagine a small producer. Perhaps the project allows them to demonstrate their excellence by meeting delivery deadlines or quality parameters. Thanks to this evidence, he could renegotiate his contracts and obtain direct benefits in the short term.
This variability and asymmetry in the benefits obtained determines that each project, depending on the specific use case and the participants involved, combines different returns and even different levels of investment to achieve the expected results. Characterising this benefits map in as much detail as possible should be a priority before entering on costly integration projects or migrating from legacy systems and applications to a new blockchain-based solution.
Interoperability between networks
The development of business projects based on blockchain is accelerating in parallel with cryptoeconomics. Use cases such as bitcoin or crypto currencies have developed a centralized ecosystem in a few public networks. However, when a company decides to launch a blockchain project it thinks about creating its own private network. The result is a multitude of networks deployed independently as silos, although many of them can share technology.
There is an ongoing debate about the interoperability of blockchain networks. How is interoperability ensured between different blockchain networks? Before answering this question, it is necessary to ask what we mean by interoperability and whether it is necessary for our specific case of use.
A priori, two blockchain networks can interoperate at different levels. They could share data or allow a smart contract deployed on one network to write or interact with another. They could also validate transactions and reach consensus between them. However, what use cases need these levels of interoperability? Let’s think of two business applications, one for payroll management and one for expense management. Both probably need to be aware of employee data. These could be replicated in each application or available in a common repository. However, they do not talk to each other. They do not interoperate.
Each application simply uses the information it obtains from available sources. The same happens with Blockchain. The information stored in a network or the tasks (smart contracts) are self-contained. They do not need to interact with another network. In any case, it will be the application that integrates with two networks simultaneously. From each of them it will retrieve or register information of different nature that allows the implementation of the use case.
Reuse of components or ad-hoc developments?
Many of the business applications based on blockchain make use of the same basic functionality of the technology. At least two out of three use cases are based on the immutability of the information stored or exchanged. The rest are split between asset tokenisation (rights of use, intangible assets, digital twins, etc.) and information source reconciliation.
Let’s analyse the most common case of blockchain projects, traceability and certification. Thanks to immutability, we can create irrefutable digital evidence that we can also date and attribute accurately. With this evidence we can leave a trace of an information or an event so that it can be verified by a third party. Now let’s think about a specific case of document certification. If we atomize the necessary operations we can create a catalogue of actions that we could reuse in another case.
These actions would include creating the digital asset that the document represents, associating the intrinsic data of the document with it, signing it digitally to attribute it to the holder, creating a unique fingerprint that allows subsequent verifications, etc. These same operations could be applied in an industrial traceability project to monitor the condition of a specific piece. In this case we would create the asset, assign it to an operator responsible for the part and we can assign intrinsic data to identify it.
We have therefore managed to reuse components in projects of a different nature. If we think about the implementation, surely each operation can be translated into a generic smart contract that can be parameterized according to the specific process that we monitor and trace. These generic smart contracts are the reusable components that make it possible to significantly minimise the development times of blockchain solutions. In some cases we will need to develop specific components (i.e. new smart contracts). However, the majority of use cases can be made with these reusable components.
Need for decentralisation
Another recurrent debate among blockchain advocates raises the extent to which it is necessary to decentralise the operation of a network. In fact, many experts claim that a private network does not respect the underlying value of having a decentralised platform. From this position only public networks with thousands of independent nodes would be true blockchain networks. Mass replication in thousands of nodes without any one node being able to influence the rest guarantees immutability and integrity.
In cases of consortia where several partners operate the network, a minimum of decentralisation is guaranteed. However, we were saying that each company is deploying its own private network. How do we guarantee immutability and integrity in these cases? As long as there is cryptographically recorded evidences that can be verified by unrelated third parties, both attributes can be guaranteed. T
he basic cryptography that links the blocks of stored information makes it unfeasible for historical information to be altered without invalidating the distributed verification evidence. In any case, the use of public networks to record snapshots or images of the system at a time as evidence is a common procedure to guarantee the integrity and verifiability required by blockchain defenders.
Veracity of the IIOT
Finally, we can reflect on what the immutability of information means. In essence, the information we record on a network cannot be altered and we can guarantee its integrity. What happens if that information is false? We are effectively “building” a lie that people will be able to verify. Therefore, we have to be careful with the information we store in blockchain. We must never believe something recorded in the blockchain without having a guarantee of how that information is being recorded.
The easiest way to guarantee not only the integrity but the veracity of that information is to record it as close to the source as possible. In many of the business processes that we can consider, that place is a reliable IoT device as an interface to automatically load the information in the blockchain. But still the parties must ensure that the devices have not been tampered with and trust them.
TrustOS: Quick and easy Blockchain
From Telefónica we have been working for several years so that our customers can implement Blockhain without worrying about all these challenges. Our proposal is TrustOS, a simple network service that allows to invoke in a simple way the most demanded functionality of blockchain. Following the thesis we explained before, TrustOS would be those reusable components of any Blockchain project, which we have packaged and made available to our clients. Thanks to TrustOS, a company can:
- Add blockchain to its systems, services and applications at a low cost in time and resources. It can divest itself of the underlying blockchain technology and use the TrustOS APIs to combine the best of the public and private blockchain networks.
- Simulate your minimum viable ecosystem without paying attention to the network topology or develop complex integrations of your systems with Blockchain.
- Present the managers with positive business cases from the very beginning, since the investment in network deployment is minimized and the service starts to be used immediately.
- Develop applications that can simultaneously interact with several blockchain networks even when they are based on different technologies.
- Reuse the basic components of TrustOS to implement traceability or certification use cases with very few lines of code.
- To trust in the real decentralisation of the solution thanks to the federation of networks, a novel concept that allows the creation of meshes of different networks that act as verifiers of the integrity of the information exchanged in the other networks of the mesh.
- Guarantee the data exchanged and its integrity, thanks to the IoT modules that natively register information and evidence in blockchain through TrustOS.
