Notes on cross-company business processes

Modelling business processes intern in a company might be totally different as speaking about processes between different companies. The reason for that that companies are built up based on different departments and the major challenge of a corporate business process is to describe the information flow of the department. If we speak about cross company processes however they have a little bit different characteristics. Companies working with each other mostly based on markets, either based on general free markets or some kind of a limited market. Another important difference is that information can not free flow freely, it has very strict private characteristics. As a result, if we want to define cross-company business processes we should much more concentrate and model the markets that are connecting the different enterprises. 

Generating Solidity from Hyperledger Fabric Composer: asset inheritance

Inheritance can be translated from Hyperledger Composer to Solidity almost one to one. Both frameworks define inheritance among assets or smart contracts and there is the possibility to create abstract assets or smart contracts. The only difference is that Solidity supports multiply inheritance but Fabric Composer not really. 

Creating a blockchain integrated database

Integrating blockchain seems to be pretty straightforward for the first run. We can take an exisiting blockchain solution and validate all of the CRUD operations with the help of the blockchain. As in the following example implemented with Solidity, we can be sure that as soon as the blockchain raises our event, the given operation has been already validated by Ehereum. 

contract DB {

event CRUDOperationEvent (string operation);

    function CRUDOperation (string _operation) {
        CRUDOperationEvent(_operation);
    }
}

Certainly, it is questionable if such an integration makes sense at all, because the performance of the system will be surely dependent on the consensus algorithm itself, meaning that one has to wait for the operation around 15 second. Another issue might be the fact that the database is actually an external element from blockchain, so it is questionable how a real trusted integration can be realized. 

Generating Solidity from Hyperledger Fabric Composer: related assets

One of the idea of Hyperledger Fabric Composer is to have a domain specific language to model complex assets. Besides properties of an asset, connections or relations between assets can be defined as well. Like considering the following example:

asset TestAsset identified by primaryKey{

  o String primaryKey

  o String property1

  o String property2

  --> RelatedAsset relatedAsset

}

asset RelatedAsset{

}

The structure can be translated into several smart-contracts that reference to each other like in the following example:

contract RelatedAsset{

}

contract  TestAsset{

  string primaryKey;

  string property1;

  string property2;

  RelatedAsset public relatedAsset;

  

  function setRelatedAsset(RelatedAsset _relatedAsset) {

      relatedAsset = _relatedAsset;

  }

}

Certainly it is an open question how these contracts are created. On way is that there is an external factory contract that creates and administrates such a creation and calls only the setRelatedAsset function. Another way might be that the contracts realize the CRUD (Create Read Update Delete) operations on their own. 

A totally different way might be to use structs instead of contracts which makes things certainly much cheaper from a gas consumption perspective, however all CRUD operations must be handled externally.

contract Factory{

    struct RelatedAsset{

    }

    struct  TestAsset{

        string primaryKey;

        string property1;

        string property2;

        RelatedAsset  relatedAsset;

    }

}

 

Generating Solidity from Hyperledger Fabric Composer: enums

Translating enums from Hyperledger Fabric Composer to Solidity is pretty straightforward for the first run. You can one to one associate a Fabric Composer enum to a Solidity enum:

Hyperledger Fabric Composer:

enum TestEnum {

  o one

  o two

  o three

}

Solidity:

enum TestEnum {

   one,

   two,   

   three 

}

   

However the exact functioning might be a little bit different from time to time. As an example, in Fabric Composer enums are defined on the global level and handled generally, however in solidity enums are defined on a smart contract level, meaning that if you want to use the same enum  in more variables in several contracts you should define in each of the contracts or put it into an ancestor class and precisely define smart contract inheritance.

Generating Solidity from Hyperledger Fabric Composer: simple assets

Often it is a requirement to model and implement a requirements in different smart contract systems. For such a requirements it is important to know the differences between the different languages and abstraction possibilities. In our serial, we try to investigate the possibilities how Hyperledger Fabric Composer language elements can be translated into Solidity Ethereum.

A simple asset in Hyperledger Fabric Composer has some properties and some kind of a primary key:

asset TestAsset identified by primaryKey{

  o String primaryKey

  o String property1

  o String property2

}

one way to associate it with Solidity is to implement a Solidity smart contract for that, like:

contract TestAsset {

    string primaryKey;

    string property1;

    string property2;

}

However assets are not really handled as individual contracts but rather as a set of crypto-assets that are identified by the primaryKey. As a consequence such contracts should be embedded into a factory contract that creates and administrates the assets. One example might be:

contract TestAssetFactory {

    mapping (string => TestAsset) testAssets;

    function createTestAsset(string _primaryKey) {

       testAssets[_primaryKey] = new TestAsset();  

}}

Another option can be however that instead of contracts we use rather structs and the factory token creates a new struct instead of a new smart contract. From a point of view of gas consumption the second solutions will surely be cheaper. 

Consortium blockchains and business processes

Business processes describing consortium blockchain solutions should be fundamentally different than processes describing the operation of individual companies. The reason for that is that is that companies do not really communicate with  each other in an absolutely free manner. They regard company secrets as a very strong fundamental basis and they cooperate with each other only on a special interfaces. As interface I do not necessarily mean just a technical interface, the cooperation of the two companies usually mean that one provides a service, or sell goods that the other one can buy. So the major cooperation is actually the exchanging of goods and services and not some kind of another information sharing. This implies that best consortium blockchain processes must be able to describe different kind of crypto-assets, the relation, exchange, visibility and access rights of these crypto-assets as a primary goal. They must provide the way of putting most of this logic into the blockhain itself realizing with for example smart contracts and they should provide a way to create and configure things with the help of graphical user interfaces. In this sense Hyperledger Fabric has a good direction, even if they can not provide graphical user interface at the moment.  

Combining conveyor belt with artificial intelligence

Combining a conveyor belt with artificial intelligence is a dream that sounds for the first run pretty much as science fiction. However there a realistic chance of realizing such an algorithms. Let we imagine a configuration space with CU = {cu1,cu2,cu3 ... cuN} different configuration units where each cui configuration unit has a cui = {c1,c2 ... cki} set of different configuration possibilities. General software architectures can be regarded for instance to such systems, they provide many functionalities and which can be configured and put together in many different ways. In this example, we consider the configuration space as independent elements, however in general case they might be dependent from each other. 

A configurable conveyor belt is a subset of subsets of the whole configuration space CB =  {cb1,cb2,cb3 ... cuK}, where each cbi is a subset of a given cui. The cbi elements can be regarded as different steps of the conveyor belt and the elements in each cbi contains the different choices for each step. We can say that the conveyor belt is not configurable if each cbi step contains only one choice. We can say that the conveyor belt is human configurable if it contains 7 plus minus 2 steps and each step contain 7 plus minus 2  configuration choice. A conveyor belt might be hierarchical if each cbi configuration step can be regarded as a whole configuration space with configuration steps and sub-choices.

The major task of a conveyor belt learning algorithm is to analyse different choices of the configuration space and create or estimate a human configurable conveyor belt automatically with the help of statistical analysis or machine learning in order to capture the choice pattern that can be used in most of the situations.  

Domain specific languages can be also regarded in a way as special conveyor belts that are capable of realizing only parts of a theoretical configuration space. Unfortunately there is know known method to integrate with the artificial intelligence or machine learning. Perhaps such a theory could provide the basis for the integration. 

Another open question if conveyor belts can be built up a modular or even modular and hierarchical fashion and if they can be supported by efficient machine learning algorithms. 

Blockchain as a decentralized communication channel

From a practical perspective blockchain can be regarded as a decentralized highly available and reliable communication channel between different actors. It is served at the moment rather to transfer value between the different actors without the primary goal to transfer information, however applications could also be imagined where instead besides of value rather information is exchanged. In this sense applications that should be based on a global decentralized event bus can be also imagined based on blockchain. 

Certainly, performance is still an issue, with the current speed of bitcoin or ethereum such an event bus can not be considered to be too performant. However with technologies as Hashgraph such an applications might be easily imagined. With that the question is which use-cases could be considered to be implemented on a distributed ledger technology that focus not only on value exchange, but somehow on information and value exchange ? 

Blockchain: the new trust layer of the internet

Cryptocurrencies and blockchain technologies are among the best hyped technologies all around the world. Although the technology first appeared in 2009 first as an initiative of a mysterious person called Satoshi Nakamoto the real strengths of the technology hasn't been recognized for a while. The major reason for the recent hype is that the world is getting aware of the technology and trying to understand which use-cases can be efficiently covered by blockchain apart from cryptocurrencies and Bitcoin.  

To understand the real potential of blockhain, the best was is to compare with an old classical protocol internet protocol, like TCP / IP.. Although it sounds technical pretty technical, the TCP / IP protocol is nothing more than a technical cooperation way between different computers for reliable  data transfer. The protocol appeared around fifty years ago, got a little bit more widespread thirty years ago. At first sight it seemed to be a pure technical game for scientific people or tech geeks to exchange information. However nowadays we can already conclude that the TCP/IP protocol has basically changed the world. It is the basic backbone of the internet itself, practically everything that is regard currently as internet or web is based on this technology. It is important to note from a business or marketing perspective that there are many applications of the technology wasn't foreseen thirty years ago. Examples are Facebook or Twitter that are based on this protocol but no-one could predict previously that the become million dollar industries.

From a practical point of view blockchain or distributed ledger technologies are similar to the TCP/IP. They are simply IT, collaboration protocols but instead of reliable data transfer, they realize a trust protocol between different actors. Let we just imagine the situation that there are several actors throughout the world who want to collaborate with each others and exchange value. As an examples, they want to exchange or transfer a currency. These actors are geographically decentralized, they do not know each other, they do not trust each other and actually they do not want to trust each other. Hence they are not necessarily humans, but for examples different IoT devices communication and transferring value with each other. blockchain protocols simply guarantee from an algorithmic level that these actors can exchange value with each other even with such a circumstances.

Traditionally, trust based services were provided by centralized institutes like banks or insurance companies. They provided a working model for many years, however they suffered from many problems, like inefficiency, slowness or sometimes from censorship. Blockchain technology simply disrupts this institutional business model and provides a much faster, cheaper and fairer way for exchanging value or to realize trust based services on the internet.  

There are two major, a little bit controversy applications of blockchain nowadays: cryptocurrencies and token based platform funding (called ICO at the moment) that are disrupting traditional money transfer and corporate funding. It is important to note however, that they are just applications on the protocol. One of the major reason of the Hype that the world is experimenting currently which other classical trust based services can be realized in a more efficient way with the technology.

Certainly, we are pretty much at the dawn of distributed ledger technologies: there are still many technological drawbacks, due to the lack of regulation many scams, and of course classical institutional trust based industries managing billions of dollars won't adapt so easily. Which fields and use-cases will reach the real mainstream adaptation is something that we will probably see in ten-twenty years.