Who is the blockchain system for?
In any blockchain service, "design" plays an extremely important role in clarifying issues from actual operations and determining the scope of feasibility.
This is because if you start from the viewpoint of "first, we will use blockchain for demonstration testing," you will be swallowed into the spiral of "why do we need blockchain?”
Contents of this article
- Steps to Proceed with a Blockchain Project
- Points to keep in mind when using blockchain
- Differences between blockchain systems and general systems
At Couger, we have been involved in various enterprise blockchain projects for some time. We have witnessed many companies struggling with the process of building blockchain services, wondering what kind of hypotheses and verification is necessary, and what kind of problems they need to solve. However, it is natural to have such concerns. This is because system architecture using blockchain requires a different perspective approach than conventional services.
In the case of the telecommunications company example, for which a detailed diagram will appear later, different databases have traditionally been managed by different departments and by different subsidiaries with which they collaborate. To put this in terms of a specific issue from the consumer's perspective, a user with 100,000 influential followers on Twitter cannot divert the credibility value of Twitter on Instagram. Therefore, the purpose of this project is to take advantage of the characteristics of the blockchain to limit the scope of disclosure by isolating the data, rather than making it all public, even though each data department shares the same data. This prevents the "Galapagosization" of data that many companies face when collaborating or forming alliances, and allows for secure and scalable data operations.
We would like to outline how Couger has outlined those processes and implementations in detail in this article.
(source: NIST when do you need blockchain)
(1) UX visualization and data management
As a first step, it is important to clarify the business flow and the limitations of each entity (collection of data). While this is a natural step in defining requirements for normal system implementation, in addition to this, it is very important to ask "Who will store and guarantee the data?” is very important.
This "who?" is very different from existing system design in that it will later play a major role in determining which blockchain will be incorporated into the architecture (*2).
(2) Use Case Selection
As mentioned earlier, "Who is the system for?" and "Who runs the system?" In the project with KDDI, described in the TechCrunch article, three main elements were singled out as the most important.
- Data permanence (traceability)
- Confidentiality of information and exchange between specific vendors (access control)
- Interoperability between different blockchains (interoperability)
Traceability | Data Persistence
The first is data traceability (perhaps "immutability" is more appropriate in terms of tamper-resistance), which is a natural part of using blockchain. However, the key question is "Who will operate the nodes(*3)?"
One possible attack of traceability is that if there are less than two sets of entities (collections of data) that can be controlled by an operational node, the system fails to guarantee traceability. This is because once the blockchain is branched, the data can be tampered with. Therefore, it was first and foremost decided to operate with three or more nodes in order to maintain data tamper-resistance, which is one of the characteristics of blockchain technology.
Access Control | Information is kept confidential and exchanged between specific vendors
Public Ethereum is not a good idea for companies. Taking into consideration the design of systems that handle important personal and business information, it assumes that all information will be made public. Then there is the question of whether it is really necessary to use blockchain if the system is to be operated by a limited number of members.
So we decided to use Quorum, the Ethereum blockchain frequently featured in the Enterprise Ethereum Alliance (EEA). So why Quorum? There are two main reasons:
(1) We want to maintain Ethereum's basic block, account, and state concepts.
(2) We want to keep information confidential and exchange it between specific vendors.
The second point is particularly important: "Can we deal with the case where we want to keep a record of the transaction itself (e.g., Alice -> Bob transaction of some kind), but don't want Charlie to see the contents of the transaction? This is a case where the transaction itself (e.g., Alice -> Bob) should be kept on record, but Charlie should not see the contents of the transaction. This kind of requirement usually arises in enterprise requirements outside of blockchain, and is often handled by APIs provided by companies. However, since these APIs themselves are provided by the service's database, the reliability of the data is uncertain.
So we adopted an architecture where three different entities (collections of data) run the nodes and select the scope of publication and operation based on the type of data. (*The only blockchain that fulfills these requirements was Quorum as of 2017, so the decision was made to use this one.)
Interoperability | Interoperability between different blockchains
However, only the above two are insufficient for enterprise blockchain operations. Why is that? Because services usually need to be operated over the long term. For an enterprise to operate over the long term, a number of things need to be taken into account.
For example:
Data capacity
Failure and backup support
Fluid alliances with other vendors, etc.
Among them, this time we focused on "interoperability," which will be important in dealing with the long-term participation of other vendors in alliances.
Why is interoperability important?
Normally, different blockchain networks can only be written to and read from by entities (collections of data) participating in them. However, this alone does not allow for fluidity. In an enterprise, the number of partners and alliances will be diverse, and a blockchain that can only be used by a limited number of network participants in the design process will inevitably lack agility.
Therefore, for this project, we selected an architecture based on the assumption that various vendors will provide services utilizing blockchain, and another entity (collection of data) will operate different blockchains. Therefore, we used Hyperledger Fabric, a blockchain other than Ethereum and provided by IBM, as the requirement for the other entity (collection of data), and the Interledger Protocol (commonly known as ILP) was used for interconnection.
Architecture
The architecture for implementing these is shown in the figure below.
The first and second use cases are embodied in the "Repair Consortium Network" on the left. Although there will be no user (i.e., consumer) intervention here, the enterprise and its related companies usually have to access some database system to perform their tasks. The consortium network using Quorum is designed for this purpose.
The information shared by each entity (collection of data) participating in a consortium blockchain is shown in the leftmost figure above. As you can see in this diagram, it is clear which information is to be disclosed to which entity (data aggregate) and which information is to be kept secret.
The third architecture is an interconnection to a reused private network outside the consortium that is managed using another private blockchain (in this case, Hyperledger Fabric). The data to be shared will vary from case to case, but a good example would be the status of repairs, inventory status, or the amount of money for a mobile device.
This allows the private transaction feature of Quorum, which specializes in enterprise blockchain, to be used to limit the scope of sharing while protecting the privacy of the data.
SUMMARY
When building a blockchain system, it is clear that a variety of factors must be taken into account in selecting the architecture. These are very different from existing approaches, such as the need to consider incentives, interoperability, access control, etc., for the entities (aggregates of data) operating the nodes.
What is the the answer to the question "Why Blockchain? This will vary from case to case. This is different for each use case, and the optimal architecture must be built with the understanding that there is no "silver bullet" blockchain that can solve everything.
Companies need to build blockchain applications that take advantage of the unique characteristics of the service from various angles, including transaction speed, usability, scalability, and game theory. This article was just one of the concrete examples of such a project design, and we plan to introduce more technical and business approaches in the future.
■Glossary
*Architecture: The logical structure of a computer system.
*Node: a point of contact or junction in a network
*Interoperability: the ability to interoperate
