Hyperledger Fabric

In 2018 there were 315 natural disaster events recorded with 11,804 deaths, over 68 million people negatively impacted, and US$131.7 billion in economic losses across the world. Fast forward to 2020, and we can expect regular occurrence of hurricanes, tornados, forest fires and other natural disasters but now against a backdrop of  communities strained to the limit by a global pandemic. 

Regardless of when or where they happen, the impact of natural disasters is tremendous and affected communities require time, energy and resources to rebuild. During and after these natural disasters, companies, relief agencies, and non-governmental organizations collaborate with the local, state, and national governments, along with residents in the communities to manage the relief efforts. These stakeholders often face a range of operational challenges during the disaster management efforts.

Key Challenges During Relief Efforts

The key challenges faced by organization during relief efforts include:

• Lack of trust, transparency, and auditability of the relief efforts to ensure resources are used for the intended purpose(s)
• Cumbersome registration process for volunteers 
• Lack of coordination across organizations
• Lack of single channel or process for donors and agencies
• Difficult collection and distribution efforts leading to duplication of efforts and waste
• Missing or improper recording of activities and transactions associated with the relief efforts

Miracle Joins Hands with Chainyard 

The Miracle Relief Collaboration League (MRCL) is a 501(c)3 not-for-profit corporation,  registered in the state of Texas, with a focus to serve those impacted by disaster events. MRCL was looking for ways to address the above challenges in order to connect needs with resources in natural disaster relief efforts such as hurricanes and floods.  

Through common associations, Chainyard was introduced to MRCL and its mission.  After learning more about the mission, Chainyard joined the effort to address these challenges. 

A Closer Look at the Challenges Revealed Blockchain Potential

From the point of view of enterprise architecture, relief efforts involve collaboration between various parties, meeting demands and exchanging goods – this is a classical supply chain where broken logistics hamper progress.

“Rarely does a location struck by a natural disaster lack parties willing to donate aid, in the form of food, medicine, shelter and other essential supplies. The problem is one of logistics. Effective emergency response to a natural disaster requires rapid, coordinated action among multiple parties.”

– Robert J. Bowman, Supply Chain Brain

A blockchain solution was ideal to address the above challenges. Examples include the following:

• A common platform: Blockchain brings collaboration and coordination among all stakeholders involved in relief effort by having a single, trusted ledger.
• Immutable data: Once data is recorded, it cannot be easily changed, creating an audit trail and trusted system for collection and distribution of goods and services.
• Secure sharing & management: Documents and personally identifiable information (PII) can be securely managed and shared with need-to-know parties. This enables compliance with privacy regulations across different geographic regions.
• Demand reporting: Demand (needs) from different areas can be recorded on a single network by trusted participants and met by different agencies. This can avoid duplication and wastage.
• Improve trust with 3^rd party verification: Needs can be verified by 3^rd parties to increase the trust.
• Tracking and visibility: Inventory of supplies can be tracked from receipt into the warehouses until delivery to the end receiver. This improves transparency and facilitates logistics, leading to faster responses and avoidance of duplication of efforts across relief organizations.
• Honoring volunteer effort: Volunteers hours can be captured, tracked, rewarded and audited. Incentives, even if just recognition, can lead to more community engagement.
• Future Tokenization: Potential future tokenization and linkage to stable coin can be used to incentivize volunteers to help

Designing the Hyperledger Fabric Blockchain Solution 

The Chainyard team worked with MRCL leadership and volunteers to build a blockchain-based solution that replaced the old MS Access application. The architecture is based on Hyperledger Fabric and the solution is running in pilot on Google Cloud.

Primary design considerations for using Hyperledger Fabric were:

• Identity of members is a critical factor for creating trust in disaster relief efforts. Fabric platform provides permissioned membership with right data protection regulations.
• Privacy and anonymity of transactions is critical for some of the stakeholders involved in relief efforts. At the same time making this information available for audit and compliance reviews is also critical. Fabric provides support to make data on a need-to-know basis.
• Immutable distributed ledger that allows all stakeholders to verify and share demand & inventory of supplies, proximity to affected areas, and coordinated communication with end to end visibility. 
• Faster development cycle that leverages widespread programming language support, mature tool set, and community of skilled resources contributing to the open source project.

Solution Highlights 

The highlights of the pilot run on the Minimum Viable Product (MVP) are as follows:

• Anytime, anywhere access with a smartphone to record a request for help or any related communication. Please note existing MVP does not offer mobile interface.
• Successful registration of all stakeholders involved in the disaster relief efforts –inclusive of relief organizations, volunteers, government agencies, medical service providers, and support infrastructure providers (e.g., transportation, shelters and warehouses). Please note existing MVP has limited organizational function support.
• Successful recording of all donations on the ledger.
• Verification and management of assistance to impacted communities
• Successful coordination of volunteer efforts. 
• Successful recording of the distribution of good and relief services.
• Successful delivery of transparency, privacy and track & trace capabilities.

Figure: A sample screen from the application

Industry Recognition

The solution has been honored by Stevie Awards with a 2019 Silver Medal International Business Award for Community Engagement. 

Kathryn Ingerly, Lee Duncan of MRCL, and Sri Nidamarty of Chainyard with Stevie Award

Development Team

Chainyard had a team of five led by Mohan Venkataraman CTO of Chainyard who closely worked with Kathryn Ingerly, Derek Harrison and  Lee Duncan, each representing MRCL. The technical development of this project was sponsored by Sai Nidamarty, Co-Founder and CEO of Chainyard, as part of Chainyard’s Corporate Social Responsibility initiative.

Authors

Gigo Joseph, Vice President International Business Development, Chainyard
Isaac Kunkel, Sr. Vice President Blockchain Services, Chainyard

Featured image by Kevin Skow, NOAA Weather in Focus Photo Contest 2015 (CC BY 2.0)

What do you think of when you hear “smart contracts”? Cryptocurrencies? Tokenization of assets? Automating financial agreements?

But what could be more critical to your business than the tools you use to get your tasks done? Whether it’s a to-do list, internal communications, or even tracking time-off, these are key processes at the heart of everyday organizations. Any application or workflow that involves collaboration — between organizations, individuals, or even software systems — can benefit from a robust and secure definition of the processes involved.

OpenWork is a suite of smart contract-powered productivity apps. Thanks to the fact that the smart contracts are written in DAML, they can run on Fabric, Sawtooth, and Besu thanks to the community integrations. For more information about OpenWork, check out our series of posts on why we did this, a dive into the apps and their features, and where we plan on taking OpenWork.

In this post, we’ll walk you through the process of getting Board, OpenWork’s Kanban-style project management app, running locally on a Hyperledger Fabric network (you can see a running version here). The final stack will look something like the following diagram.

Getting Set Up

Prerequisite services:

• Git
• Docker
• Scala with SBT
• The DAML SDK
• Python 3 with the dazl library installed (pip3 install dazl)
• Node and Yarn

Files:

• Clone the DAML on Fabric repo
• Clone the OpenWork Board repo (codename danban)

1. Running the Fabric Network

The DAML on Fabric repo comes with a test fixture for running a local 5 node deployment:

$ cd daml-on-fabric/src/test/fixture

$ ./restart_fabric.sh

Once that’s up and running, you’ll need to start the DAML service. One bit of housekeeping: you might need to update sbt.version in project/build.properties to match your local SBT version (latest is 1.3.8). Next, we’ll want to start the DAML Ledger API Server and load the ChainCode onto the endorser peers. In the root daml-on-fabric folder:

 $ sbt "run --port 6865 --role provision,time,ledger,explorer danban/quickstart/danban-upgrade-3.0.0.dar" 

2. Prime the Ledger

We’ll need some data on the ledger to get started. Some parties will need to be onboarded onto the ledger and then a new app contract will need to be instantiated. The fabric-quickstart folder contains some simple scripts to simplify this process:

$ cd danban/quickstart

$ daml ledger allocate-parties

$ python3 setup.py

3. Running the Frontend

Finally, we’ll want to run the frontend. It’s a fairly standard client-side Web app, but as the ledger API is gRPC, we’ll need an HTTP server for the app to talk to. To start the HTTP JSON API server:

$ cd ../client

$ daml json-api --ledger-host=localhost --ledger-port=6865 --http-port=7575

$ yarn install && yarn start

The app should open in your browser on a login page. DAML ledgers are flexible regarding user authentication, but the examples here use a JWT based scheme (you can read more here). For this example, you can log in as the user “Alice” with the following JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwczovL2RhbWwuY29tL2xlZGdlci1hcGkiOnsibGVkZ2VySWQiOiJmYWJyaWMtbGVkZ2VyIiwiYXBwbGljYXRpb25JZCI6ImZvb2JhciIsImFjdEFzIjpbIkFsaWNlIl19fQ.6I3_M0PCpc3tqqFf1TbHZ84GQOkOl6KpmuVyoRYLvSg

Instructions for how to create tokens for other users are detailed in the documentation here.

What’s Next

Let’s say you’re up and running, planning your project on your Fabric-powered Kanban tool. Great! But now you want to collaborate with another team, already running a Hyperledger Besu network. You could try and agree on a common framework to use (good luck!), but DAML gives you another way — synchronizing data from the apps across running Hyperledger networks on different frameworks. This is going to be possible soon with our work on DAML interoperability, which we recently previewed at the Hyperledger Global Forum.

OpenWork is just at the start of a process to see how far smart contract-powered productivity apps can go. There are features to be built and more apps to be added to the suite. We’d love your support. If you’re a developer or a user and you want to get involved, check out the OpenWork page for our repos and contact resources.

As a consumer, you are probably familiar with the “track my package” function that most major couriers offer. Whether your package is being delivered by FedEx, UPS, or the postal service, you can punch in your tracking number and see exactly where that package is, where it’s been, and when you should expect it to arrive at your door. However, the products inside of those packages aren’t exactly an open book. The majority of goods that we consume travel hundreds, if not thousands, of miles to our doorstep or to the store down the street, but oftentimes companies can’t tell us exactly where their goods came from or where they’ve been since. Aside from those last few miles, consumers and companies are blind to the entire lifecycle of most products.

This is a common narrative at the intersection of blockchain and supply chain, and there are two main reasons why most companies can’t tell you a step-by-step story for each of their products. The first reason has to do with identity. FedEx can give you the history of your package’s final mile because each package is assigned a unique identification number. However, that ID only relates to the package, not the product inside, and outside of the FedEx ecosystem, that identity doesn’t do you a whole lot of good. Contrary to what most people think, barcodes don’t assign unique identities to each product either. Rather, they specify the type of item, like a women’s small cardigan or a 12 oz can of diet soda. Consequently, there could be millions of items that have the exact same barcode information, which makes it impossible to tell identical products apart.

Many companies have already started addressing this item-level identity issue by embedding RFID tags in product labels or printing QR codes onto product packaging. These two methods, along with other serialization solutions like NFC tags and 2D data matrices, allow companies to assign unique digital IDs, also known as Serialized Global Trade Identification Numbers (SGTINs), to every single product that they produce. As you can imagine, this degree of serialization creates massive volumes of incredibly rich data that can be used to enhance consumer experience, streamline supply chain operations, and enable more granular visibility throughout the value chain.

This brings us to our second problem, which is tied to data exchange. Data sharing between businesses today is largely limited to high-level business documentation exchanged via EDI. Furthermore, most EDI networks are not equipped to handle the billions of additional data points generated by serialized products, and even if they were capable of processing all of this data, cost would be a major concern if current pricing mechanisms were kept in place. So, for the companies who have already invested in identification technology, the only options for sharing serialized data with trade partners are managed server solutions or proprietary data pipelines, neither of which scale across an entire industry.

Surprisingly enough, retail has one of the highest serialization rates of any industry, with billions of products already having unique digital IDs. Lululemon products contain RFID tags, Nike shoes have QR codes, and Hot Wheels cars have embedded NFC tags. Apparel and footwear alone are responsible for over 14 billion RFID-tagged products across the globe today, and that number is rising rapidly year over year. Consequently, retail participants are intimately aware of the sad state of serialized data sharing, so, in early 2018, twenty-three suppliers, retailers, logistics providers, and technology partners came together at the Auburn University RFID Lab to determine whether or not blockchain could be the solution to their data exchange problems.

This initiative was named CHIP (an acronym for CHain Integration Project), and it was centered around one question: “can blockchain serve as an effective means for serialized data exchange?” Corporate partners were divided into three subgroups focused on business objectives, data standards, or privacy & security, and, after several months of discussions, the collective group was able to determine the business and technical requirements for the proof-of-concept solution. Five brands and retailers chose to participate in the proof-of-concept: Nike, PVH Corp., Herman Kay, Macy’s, and Kohl’s. Each company committed to sharing serialized data streams from various points along the supply chain ranging from source to store, and these data streams had to be transformed into a common standard before being written to the blockchain. For the proof-of-concept, the group decided to build a Hyperledger Fabric-based solution and implement EPCIS as the core data standard for the network.

Each partner that participated followed a series of sequential steps. First, they had to select the serialized data systems that they wanted to plug in to the proof-of-concept and identify the solution providers that supported those systems. Secondly, they had to standardize their data, which they accomplished independently or with the help of the team at RFID Lab. Lastly, they had to integrate their standardized data streams into the blockchain solution constructed by the team at the RFID Lab, which they accomplished through a series of manual uploads or through API integration.

Within the network itself, each partner pair was organized into a channel and each supply chain node was represented by a peer. Whenever a brand shipped product to its retail partner, outbound RFID systems would trigger a series of item-level transactions that would be written to the appropriate side chain. Whenever a retailer received product from the brand, inbound RFID systems would capture item-level information from the shipment and any items that matched what the brand saw outbound would be written to the blockchain. In Nike’s case, data was provided from a manufacturing point and from a downstream distribution center, with a focus on shipments between those two facilities.

Throughout the course of the project, over 639,000 items were captured by RFID systems in partner supply chains, and 223,036 of those items were written to blockchains. The difference between these two numbers is due to the fact that retailers reported RFID data for all their inbound shipments, not just the shipments related to the brands they were partnered with. Because both retailers were receiving shipments from hundreds of brands, only a small subset of the data was actually written to the blockchains they shared with specific partners.

Additional analysis focused on finding the first product written to the blockchain for each partner pair so that the items could be purchased and put on display at the Auburn RFID Lab. After analyzing the serialized data embedded in the blockchain, the team was able to identify the first products to pass through multiple touch points in the supply chain and also track down those products for purchase. The first product to pass all the way through the Nike channel was a pair of Kid’s Air Force Ones and the first product to pass through the Macy’s/Herman-Kay channel was a Michael Kors Camo Parka Jacket. The PVH/Kohl’s channel produced a Warner’s Full Coverage T-shirt Bra.

While 639,000 out of 14,000,000,000 RFID-tagged products might seem insignificant, it is a crucial step towards the next generation of the retail supply chain. Data capture systems are being deployed constantly and products are being serialized at unprecedented levels, but in order to unite the supply chain and leverage this rich data, there must be a common mechanism for data sharing. Now that the first question of the initiative has been answered affirmatively, it’s time to determine whether or not the solution can scale and help solve actual business problems.

If you’re interested in learning more about the project or the next steps for the initiative, check out the official CHIP Proof-of-Concept whitepaper here.

Telekom Innovation Laboratories has built a solution, using Hyperledger Fabric, that simplifies and facilitates processes between telecommunications network providers for commercial use cases in the areas of wholesale roaming, wholesale voice and data on demand.

Network operators are facing big problems in handling increasing volumes of roaming traffic. They have hundreds of roaming agreements with other operators in place that need to be updated, implemented and settled, mostly on a yearly basis.

Due to lack of automation of interconnection agreements and complexity of current processes, operations are slow and require a lot of manual work. This leads to financial losses due to roaming transactions that cannot be properly tracked and charged. These days, agreements are to a large part analogue contracts on paper that need to be proofread multiple times by many people. The agreed commercial terms then need to be implemented into the software systems manually later on. Some network operators exploit the current process to their financial benefit by not implementing agreements at all or only with delays, leading to financial losses and disputes. Typos can also lead to disputes and financial losses. A holistic, analytic view on all agreements is impossible. At the end of the contract period, the contracts need to be settled, which means that volumes need to be compared, discrepancies clarified and fraud deducted, which is another lengthy and cumbersome undertaking

The processes in place are dated and are not fit for expected increase of roaming traffic, especially when IoT roaming and 5G will become more widespread. Current systems are hard to scale and lack flexibility.

We at Telekom Innovation Laboratories believe that, in the future, automated processes need to be in place in order to enable telecommunications providers to deliver even better services to customers and be ready for new technologies and services that are already evolving, for example 5G and IOT. The current processes are simply not suitable for handling the technologies of the future.

Using Hyperledger Fabric at its core, our solution will optimize the process and, more importantly, enhance the trust between telecommunications providers.

The solution has two main layers:

The application layer provides interfaces for the many different processes mentioned above (e.g.,  enabling commercial roaming teams to create, sign and implement wholesale roaming agreements in a fully digitized way). It also has a UI for the commercial managers to interact with.

The network layer provides a solution that enables telcos to install nodes in their own IT infrastructure and join the main network in a semi-automated and effortless way.

Between these layers, an API enables the flow of data and transactions.

The current version focuses on the digital creation and signing of wholesale roaming discount agreements. A digital solution immediately leads to more transparency across internal teams (e.g., finance, legal, commercial), reduction of third party dependencies, reduction of bad debts and a better cash flow situation and therefore increases the profitability of telecommunications providers.

One of the reasons to pick Hyperledger Fabric was the integrated certification authority (CA). With this component, we can ensure that transactions are linked to the legitimate actors, which is very important from a legal perspective. All network operators have signing regulations and processes in place, which ensure that only certain persons inside the organization can sign contracts, while others can only create or edit them. Being able to mirror this process in our solution was a key requirement.

Another reason for our choice was the fact that Hyperledger Fabric is a reliable open source solution backed by a large developer community. We at Telekom Innovation Laboratories believe that the decentralization of blockchain cannot just be a functional aspect but needs to extend to licensing as well. This is the only way to  ensure that code can be reviewed, changed, and improved by all participating parties in a blockchain network without having to tackle complex licensing issues. Licensing is challenging already when it comes to bilateral relationships, but is almost impossible to handle if there is a multitude of parties involved in the same system.

In order to ensure maximum control for each network operator joining our system, each operator runs its own full organization on the Hyperledger network. Every organisation entity consists of the following components: peer, frontend, database, certificate authority (CA). The components are packaged as docker components and groups as Pods in Kubernetes and can be installed on the premises of each client organisation that joins the network. There are several reasons for choosing this approach:

• Each participant in the network can have control over its data (contracts) as well as administrative rights to the technical components. Sensitive data can therefore be stored on premise or on private cloud or even dedicated hardware, managed by the organisation.
• Using the distributed blockchain architecture, a copy of the ledger is located on multiple organisations at the same time. Transactions flow is implemented by the orderer in the core network, where the consensus algorithm is implemented. This allows for much higher security, as there is no single point of failure and each organisation participates in the networks at the same level as all other organisations.
• Private certificate authority (CA) allows each organisation to issue cryptographic materials needed  to connect to the network, sign contracts and manage transactions. This allows for higher security and flexibility compared to a single centralized CA.

The system currently uses a single blockchain channel, which contains all transactions by all organisations. This means that all transactions are visible by all participants in the channel. However, no contractual data is stored on the ledger. It contains metadata for each transaction that has been executed (e.g., signing a contract by the other party and agreeing to its terms). The hash can be computed based on the raw contract data and therefore can be used as proof in case of dispute that the actual parameters in the contract have been agreed by both parties. A copy of the ledger is distributed in all organisations, but the actual sensitive data is located only at each of the organisations’ respective databases and is not visible to other parties in the network. This ensures that there is a high level of security due to the large amount of participating actors in each transaction, while at the same time keeping up the required confidentiality when it comes to actual commercial data.

The contract data is stored on MySQL server running within the bounds of each individual organisation. This database stores data only related to its own contracts, so there is no distributed contract storage within the network.

Contract data are synchronized only between participating organizations when a transaction occurs (e.g., when a new contract is being created). This synchronization takes place between the frontend components of each organisation. They use a separate API that uses TLS encryption and mutual authentication to secure the transport of data.

A major feature of our solution are installation packages and scripts that allow an easy on-premise creation of a new organization. Through this, we already managed to add major operators to our blockchain network.

Currently, we are also working on integrating the end of period settlements into our solution. As we approach production, we will move to using a RAFT ordering service.

In recent years, a number of economic sectors have seen the great promise of blockchain and are already using or piloting it in different use cases. But proof-of-concept projects are often led by evangelists, developed in R&D, and always in controlled environments. Moving to production requires stakeholder buy-in and can be a real challenge, especially at the current time with blockchain.

The Hyperledger Hyderabad Meetup organized a meetup to demonstrate the potential of Hyperledger technologies and discussed the challenges related to the production deployment of Hyperledger Fabric. This session was headed by a startup team out of the Hyperledger Hyderabad community itself, called ChitMonks, who have set a benchmark in their use case in the chit fund industry. 

The chit fund industry, with estimated assets under management (AUM) of ₹1.50 lakh crore, involves a great deal of paperwork. In some instances, it forms the backbone of the informal economy in developing countries like India. This results in drudgery for both the foremen (who organizes the chits) and the regulators (the State governments). 

Administration of chit funds through companies are happening manually. Every time a company wants to start a chit, they have to submit a huge pile of documentation on a monthly basis to the registration and stamps department, which is the regulator. Consequently, there is a lack of transparency for subscribers, and audits need to be done to ensure the government and chit fund company have matching documentation. The information gap between the chit fund company and the regulators produces a loophole for frauds, which are hard to trace back.

The approach of ChitMonks is to place a private blockchain-based, consortium-driven infrastructure and establish a process-based trust, by bringing all the stakeholders involved in the process to the same platform of blockchain.

Actors and Key activities

Technical Architecture 

The three major entities involved in the process are:

• Foremen: it’s a consortium of all the chit fund companies.
• Regulators: it’s a consortium for all the regulatory entities (generally the local government bodies). 
• Subscribers: they are the end beneficiaries of the chit fund companies.

The foremen and regulators act as the two organizations in the network. And each of the organizations has two peers each. The organizations also have their respective C.A. (Certificate Authority) for letting any new member join the consortium.

• A channel is established between the two organizations to keep data in synch between regulators and the foremen.
• The chaincode is framed around the Chit Funds Act, 1982, passed by Indian legislative. This chaincode takes care of all the guidelines like commissions by foremen, a form of chit agreement, filing of chit agreement, minimum capital requirements for the commencement of a chit, creation of a reserve fund by a company and many more aspects of chit fund.
• The orderers follow Raft ordering service, after being maintained on Kafka ordering service for quite some-time.
• The state DB chosen here is couch DB, after testing it with Go level DB, which can handle complex data and adds rich querying practices. 
• Here the ledger holds only relevant data for both the organization’s, keeping a separate off-chain database for specific purposes.
• The infrastructure is designed as such where a foremen organization can own and maintain organization nodes. Typically, a big organization can own the infrastructure, medium and small organization can be part of consortium org/nodes. This makes the blockchain network more self-sustaining and more decentralized.  

So, here the blockchain system is used in a very optimized way by keeping only the shared data over the system. To make this complex system easily accessible for both organizations, each of the entities has different applications for their purposes.

As already mentioned, ChitMonks serves its platform to more than 700+ chit fund companies. Data privacy was the biggest concern for them, since the consortium of all the chit fund companies are structured as an organization here, and they all have access to the same state DB. To ensure data privacy, ChitMonks used private data collection introduced by Hyperledger Fabric in its 1.4 release. In this case, each transaction is encrypted, and the keys to check data are shared between the regulator and chit fund company over the private data collection provided by Hyperledger Fabric’s latest release.    

Challenges Encountered

Asset Modeling – Asset modeling helps to define the entities and assets involved in the process of business.  Challenges include the incipient regulatory framework and the relatively limited experience of managing large amounts of data with respect to entities (i.e., who will own what data and hierarchy involved each level of the process). While there haven’t been verifiable data breaches of blockchain backbones to date, there have been deficiencies in the implementation of smart contracts, mostly due to failures in coding. But a well-defined set of terms and conditions from the government authorities (which is also the regulatory and one of the organizations in our Blockchain infrastructure) for  the chit fund business helped ChitMonks to encode an ultimate and sustainable asset modeling. 

Testing chain code – Hyperledger Fabric provides us an immutable infrastructure. So, it’s important to test the chaincode well before deploying it. ChitMonks took the approach to perform unit testing at every change to follow up on potential bugs.   

Docker infrastructure – Containers might thus move from one host to another, especially while scaling the number of containers up or down or during container redeployments. There is no static relation between hosts and services they are running anymore! For troubleshooting, this means one must first figure out which host is running which containers. And, vice versa, when a host exhibits poor performance, it’s highly valuable to be able to isolate which container is the source of the problem and if any containers suffer from the performance issue.

Continuous Integration tools (CI) such as Jenkins can build and deploy Docker images across application environments very easily. Builds can be automated and also can be monitored efficiently using CI administrator console.

Maintaining the Kafka cluster – Initially, ChitMonks established its Hyperledger infrastructure with Kafka-based ordering services. Kafka provides a scalable multi-orderer infrastructure and poses a viable fault-tolerant solution for Hyperlуdger Fabric infrastructure, but it required us to maintain zookeepers along with it in production, which added a layer of complexity. So, ChitMonks have shifted to Hyperledger Fabric 1.4, which allows raft ordering services.  

The Raft consensus is a mature consensus algorithm and is easier to implement on a large scale than Kafka. It can extend a network with new organizations, as we don’t need to rely on a third-party Kafka cluster. In the previous versions of the platform, it was impossible to change a consensus type of a blockchain network without full redeployment. However, Hyperledger Fabric v1.4.2 introduced a mechanism that makes it possible to migrate a network from a Kafka consensus to a Raft-based one. And Hyperledger has provided a very easy step-by-step guide for migrating from Kafka to raft consensus.

Conclusion

The meetup was received with a very enthusiastic response. Many of the attendees were very happy to see a local startup deploying production-grade applications. The ChitMonks engaged well with the audience to help them understand the difference between a POC and production level applications and shared their perspective on scaling a blockchain-based product!

Kartikey is a co-organizer of the Hyperledger Hydrabad Meetup and works as a Software Engineer at MSR Cosmos and is a team member of TEDxHyderabad. You can reach out to me via Twitter,  Facebook or LinkedIn.

The hidden costs of raw materials

How much do you know about the making of your phone? How important is it for you to know where all the materials came from?

There are now over 3 billion smartphones in the world and the growth in numbers is expected to continue. This, along with demand for other electronics like tablets, laptops, electric vehicles, even vacuum cleaners, is driving a huge need for raw materials such as cobalt, tin, tungsten and tantalum. Cobalt is used in every lithium-ion rechargeable battery on the planet, while the 3 Ts, also known as conflict minerals, are found in all manner of electronic goods.

Conflict minerals have been classed as such due to their sourcing in conflict areas such as the Democratic Republic of the Congo. Militias will frequently seize control of a mine and force people to work in dangerous conditions for minimal or zero pay. With weak law enforcement in these areas there are many examples of slavery, theft of natural resources, environmental damage and human rights abuses.

The other issue that is rife here is child labour. The Guardian estimates there are more than 255,000 creuseurs (diggers) mining cobalt in the DRC, at least 35,000 of whom are children, some as young as six. These children will spend an entire day digging up enough cobalt-containing heterogenite stone to fill a sack, which they will then try to sell to Chinese traders for about $0.65.

Traceability-as-a-Service

For a long time. people have been talking about blockchain and how it is a technology looking for a problem to solve. Circulor is one of the first companies to build a solution using Hyperledger blockchain and artificial intelligence that provides traceability and transparency across the supply chain where it is really needed – conflict minerals, rare earth minerals, toxic and polluting waste, child labour-based production, to name a few. 

Responsible companies need to know the answers to the questions:

• To what extent is your supply chain traceable?
• Are you confident in the provenance of your raw material?
• Can you prove the provenance?
• What impact are you having on people and nature?

With extractive industries, true traceability requires reaching far upstream and being able to track material flows through refining, amalgamation and manufacture. Circulor addresses two core challenges – reliably creating a digital identity for a physical commodity at its source in the field, as well as connecting the inputs and outputs from a manufacturing process to enable that identity to be inherited. 

In order to make the identity reliable and digital, Circulor’s solution gives a commodity a dynamic identity, or dynamic twin, so that it can be tracked along the supply chain journey, from source to consumer, even if the commodity changes on the way. Then through the material journey, we use machine learning tools to identify anomalies or fraudulent activity.

With their entire supply chains mapped out for the first time, manufacturers are able to definitively prove responsible sourcing and sustainable production. In relation to conflict minerals and child mining, there are a number of controls in place to enable this. Artificial Intelligence is utilised for facial recognition, ensuring only authorised people are involved in the process, while anti-GPS spoofing measures guarantee that transactions are only done at accredited facilities.

One of these measures is tags that can only be used in a specified geo-fenced area, such as a mine site or production facility. This is an important safeguard because, especially with the case of tin and tungsten mining in Rwanda, the current tagging system is insecure, and tags are frequently traded on the black market. If a commodity has one of these tags, even though it holds no real information on location or identity, that is often enough for it to pass any security checks. Circulor’s tags are linked to specific locations and individuals.

Enabling better business

In partnership with Kumi, Circulor recently completed a successful project with Volvo Cars, using Hyperledger Fabric blockchain technology to trace the cobalt in the company’s forthcoming electric vehicles. Volvo Cars is leading the way in its industry to conduct responsible production, not just in its own operations but now in all of its suppliers as well. It recognised the importance of being able to prove to its consumers that it sources raw materials ethically and sustainably.

There is no doubting a current consumer trend towards a greater concern for our impact on people and the environment. Last year, the UK spent over £83bn on ethical goods with the continued growth driven by increased environmental concern, showing that more consumers than ever are looking for ways to shop that help people and the planet. Businesses are taking note – Circulor has just signed on with another automotive company to conduct a similar project and there are various examples of opportunities in other industries, such as waste, recycling, agriculture and more. In partnership with Kumi and other forward-thinking organisations, traceability provides huge potential to enable better business.

Sources:
https://www.techrepublic.com/article/how-conflict-minerals-funded-a-war-that-killed-millions/
https://www.washingtonpost.com/news/theworldpost/wp/2018/04/19/conflict-free/

Cover image courtesy of Circulor